From bugzilla at redhat.com Wed Feb 1 00:40:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 31 Jan 2006 19:40:20 -0500 Subject: [Bug 171640] Review Request: perl-Log-Dispatch-FileRotate - Log to files that archive/rotate themselves In-Reply-To: Message-ID: <200602010040.k110eKk6030814@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Log-Dispatch-FileRotate - Log to files that archive/rotate themselves https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171640 ------- Additional Comments From jpo at di.uminho.pt 2006-01-31 19:40 EST ------- I haven't receive any answer until now. I used the email listed in the author's CPAN page (http://search.cpan.org/~markpf/). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 1 00:55:55 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 31 Jan 2006 19:55:55 -0500 Subject: [Bug 175198] Review Request: perl-Math-Pari In-Reply-To: Message-ID: <200602010055.k110ttXh032651@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Math-Pari https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175198 jpo at di.uminho.pt changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From jpo at di.uminho.pt 2006-01-31 19:55 EST ------- Paul, 1) Would you mind just hardcoding the pari version? The current construct appears to be error prone: for example, it doesn't handle the current pari development version - 2.2.12 - or any other version component with more than 1 digit. If I assume the Math::Pari version as 2.021201 it will output 2.212 as the pari version (it should output 2.2.12). $ echo 2.021201 | perl -pi -e 'tr/0/./;s/\.+/./;s/\.[^.]*$//' 2.212 2) There is also a new version available. Could you update? Diff from Math-Pari-2.010702 to Math-Pari-2.010703 http://search.cpan.org/diff?from=Math-Pari-2.010702&to=Math-Pari-2.010703 jpo -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 1 00:59:51 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 31 Jan 2006 19:59:51 -0500 Subject: [Bug 179439] Review Request: linux-libertine-fonts - TrueType serif fonts In-Reply-To: Message-ID: <200602010059.k110xpCG000601@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: linux-libertine-fonts - TrueType serif fonts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179439 ------- Additional Comments From frank at scirocco-5v-turbo.de 2006-01-31 19:59 EST ------- Just nuked the separate script file. It's now in %build. Spec: http://www.scirocco-5v-turbo.de/fedora/font-linux-libertine.spec SRPM: http://www.scirocco-5v-turbo.de/fedora/font-linux-libertine-2.0.1-3.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From buildsys at fedoraproject.org Wed Feb 1 01:29:47 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 31 Jan 2006 20:29:47 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060201012947.02EF0808B@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 16 dvdisaster-0.65-1.fc5 feh-1.3.4-2.fc5 foobillard-3.0a-3 gramps-2.0.9-4.fc5 gtk-gnutella-0.96-1.fc5 gtkwave-1.3.83-1.fc5 jasper-1.701.0-9.fc5 kdocker-1.3-4.fc5.1 overgod-1.0-2.fc5 perl-DBD-CSV-0.22-2.fc5 perl-Net-Patricia-1.014-1.fc5 perl-Text-Unidecode-0.04-1.fc5 perl-UNIVERSAL-isa-0.05-2.fc5 rxvt-unicode-7.5-1.fc5 spicctrl-1.9-2.fc5 tkcvs-8.0.2-1.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed Feb 1 01:29:31 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 31 Jan 2006 20:29:31 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060201012931.56827808B@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 7 asa-1.2-1.fc3 dvdisaster-0.65-1.fc3 gtk-gnutella-0.96-1.fc3 gtkwave-1.3.83-1.fc3 jasper-1.701.0-9.fc3 rxvt-unicode-7.5-1.fc3 tkcvs-8.0.2-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed Feb 1 01:29:37 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 31 Jan 2006 20:29:37 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060201012937.593F6808B@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 11 asa-1.2-1.fc4 dvdisaster-0.65-1.fc4 enchant-1.2.1-1.fc4 gtk-gnutella-0.96-1.fc4 gtkwave-1.3.83-1.fc4 jasper-1.701.0-9.fc4 lagan-1.21-1.fc4 perl-DBD-CSV-0.22-2.fc4 perl-UNIVERSAL-isa-0.05-2.fc4 rxvt-unicode-7.5-1.fc4 tkcvs-8.0.2-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From jamatos at fc.up.pt Wed Feb 1 01:54:36 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Wed, 1 Feb 2006 01:54:36 +0000 Subject: Bunch of newly orphaned packages up for grabs In-Reply-To: <43DFBBEE.2020408@ieee.org> References: <1137482111.28950.99.camel@bobcat.mine.nu> <200601311918.21837.jamatos@fc.up.pt> <43DFBBEE.2020408@ieee.org> Message-ID: <200602010154.36702.jamatos@fc.up.pt> On Tuesday 31 January 2006 19:35, Quentin Spencer wrote: > > ?I will import the last srpm to extras and I will require the creation of > >branch FC4 Done. > >and the removal of fftw3 from development and FC4. I will let this step for you after your changes. :-) > > ?Does this sounds like a plan? :-) > > ? > > This sounds like a plan. Then I am surprised. ;-) > -Quentin PS: A serious question, is there any reason why we are not shipping the long double version of the library. This is relevant for both versions, with 64-bit machines available long double is becoming an interesting option for some problems. The change in the spec files is trivial... -- Jos? Ab?lio From bugzilla at redhat.com Wed Feb 1 02:45:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 31 Jan 2006 21:45:10 -0500 Subject: [Bug 176374] Review Request: nagios-plugins In-Reply-To: Message-ID: <200602010245.k112jAch013281@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: nagios-plugins https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176374 ------- Additional Comments From imlinux at gmail.com 2006-01-31 21:45 EST ------- SPEC: http://mmcgrath.net/~mmcgrath/nagios/nagios-plugins.spec SRPM: http://mmcgrath.net/~mmcgrath/nagios/nagios-plugins-1.4.2-5.src.rpm Big change here, I've split all the plugins into separate packages. My reasoning for this is the following: if someone wants to install a plugin that allows them to check how many users are logged in (check_users). By having them all packaged together he'd also have to install all other plugins.... and their prereq's which are many. I think the end user will like the ability to install only plugins they need. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 1 03:41:06 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 31 Jan 2006 22:41:06 -0500 Subject: [Bug 172267] Review Request: srtp - An implementation of the Secure Real-time Transport Protocol (SRTP) In-Reply-To: Message-ID: <200602010341.k113f6dG022772@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: srtp - An implementation of the Secure Real-time Transport Protocol (SRTP) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172267 jeff at ollie.clive.ia.us changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |WONTFIX ------- Additional Comments From jeff at ollie.clive.ia.us 2006-01-31 22:40 EST ------- Sorry it's taken me so long to get back to this... If I were to move the headers and development libraries to a -devel package, there wouldn't be anything left in the main package! Unfortunately, the package only builds a static library. Yeah, I know, but without some serious Makefile hackery that would go above any beyond what a packager should do to get a package built there won't be any shared libs. Anyway, I think that I'm just going to close this bug since I no longer have a need for this particular package. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 1 03:49:14 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 31 Jan 2006 22:49:14 -0500 Subject: [Bug 177658] Review Request: mediawiki - The PHP-based wiki software behind Wikipedia In-Reply-To: Message-ID: <200602010349.k113nEkq024361@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mediawiki - The PHP-based wiki software behind Wikipedia https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177658 ------- Additional Comments From imlinux at gmail.com 2006-01-31 22:49 EST ------- -You could condense your %files section into: %config(noreplace) %{_sysconfdir}/httpd/conf.d/mediawiki.conf %attr(770,root,apache) %dir %{wikidir}/config %{wikidir}/config/index.php %dir %{wikidir} %{wikidir}/[^c]*[^h] with a chmod for %{wikidir}/maintenance/*.pl in %install. -Replace instances of "etc" with %{_sysconfdir} -Also, including doc's in the main package wouldn't increase the package size much. Just don't delete doc's, install them, use %doc to mark them and change [^c] to ^[cd] I don't know 100% what best practice is on consolidating %files other than I was asked to do it for Nagios (#176613), If no one else comments on it I'll ask IRC. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rc040203 at freenet.de Wed Feb 1 06:09:49 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 01 Feb 2006 07:09:49 +0100 Subject: buildsys broked again: Job ID was provided in the time required Message-ID: <1138774189.5149.80.camel@mccallum.corsepiu.local> # make plague .. Package xxxx enqueued. (However, no Job ID was provided in the time required) # date -u Wed Feb 1 06:09:32 UTC 2006 Ralf From bugzilla at redhat.com Wed Feb 1 06:46:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 01:46:09 -0500 Subject: [Bug 177204] Review Request: translate-toolkit - A collection of tools to assist software localization In-Reply-To: Message-ID: <200602010646.k116k955015625@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: translate-toolkit - A collection of tools to assist software localization https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177204 ------- Additional Comments From wart at kobold.org 2006-02-01 01:46 EST ------- I notice that rc6 was released yesterday. Have you thought about upgrading? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 1 07:13:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 02:13:08 -0500 Subject: [Bug 177204] Review Request: translate-toolkit - A collection of tools to assist software localization In-Reply-To: Message-ID: <200602010713.k117D8T0018619@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: translate-toolkit - A collection of tools to assist software localization https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177204 wart at kobold.org changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From wart at kobold.org 2006-02-01 02:12 EST ------- MUST items: * rpmlint produces many warnings of the type: E: translate-toolkit non-executable-script /usr/lib/python2.4/site-packages/translate/convert/pot2po.py 0644 These can be ignored as explained in the initial bug report. * Package name matches upstream * Source matches upstream * License acceptible (GPL), text included * Spec file is readable in Am. English. * Compiles and rpm builds correctly on FC4 x86_64 and FC5 i386 * Not relocatable * 0wns all directories it creates. * No duplicate files * buildroot cleaned during %clean and %install * macro usage consistent * Contains code, not content * No shared libraries * No need for -devel package * No desktop file needed * Builds cleanly in mock-FC4 CONSIDER: * rc6 was released yesterday. upgrade? rc5 APPROVED. Feel free to upgrade to rc6 after importing. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From dcbw at redhat.com Wed Feb 1 07:50:51 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 01 Feb 2006 02:50:51 -0500 Subject: buildsys broked again: Job ID was provided in the time required In-Reply-To: <1138774189.5149.80.camel@mccallum.corsepiu.local> References: <1138774189.5149.80.camel@mccallum.corsepiu.local> Message-ID: <1138780252.11434.0.camel@localhost.localdomain> On Wed, 2006-02-01 at 07:09 +0100, Ralf Corsepius wrote: > # make plague > .. > Package xxxx enqueued. (However, no Job ID was provided in the time > required) > > # date -u > Wed Feb 1 06:09:32 UTC 2006 Kicked. Dan From bugzilla at redhat.com Wed Feb 1 07:50:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 02:50:35 -0500 Subject: [Bug 179541] New: Review Request: tinyfugue: A MU* client Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179541 Summary: Review Request: tinyfugue: A MU* client Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: gdk at redhat.com ReportedBy: seg at haxxed.com QAContact: dkl at redhat.com CC: fedora-extras-list at redhat.com Spec Name or Url: http://www.haxxed.com/rpms/tinyfugue.spec SRPM Name or Url: http://www.haxxed.com/rpms/tinyfugue-5.0-0.1.b7.src.rpm Description: Hello, I have been making my own packages for many years, and it appears I can finally get them submitted somewhere. This is my first package, I will need a sponsor. I figure I'll start with something easy. TinyFugue is the ubiquitous MUD/MOO/MUSH/MUCK/etc client for UNIX. This client allows you to interact with multiple worlds simultaneously, create command macros, and create hooks and triggers for automated responses to game messages. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 1 08:52:23 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 03:52:23 -0500 Subject: [Bug 171040] Review Request: postgis In-Reply-To: Message-ID: <200602010852.k118qN5G002218@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: postgis https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171040 ------- Additional Comments From silke at intevation.de 2006-02-01 03:52 EST ------- Sorry for my late answer. I am currently working on preparing the package for FC 5 as well. I don't expect any grave problems but I just need some time to do it. Are there any other tasks that I am supposed to do? So far I didn't really get any other comments on this bug. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 1 09:07:04 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 04:07:04 -0500 Subject: [Bug 176200] Review Request: Mud Magic Client In-Reply-To: Message-ID: <200602010907.k11974a3004555@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Mud Magic Client https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176200 ------- Additional Comments From kyndig at mudmagic.com 2006-02-01 04:07 EST ------- The ready for release version is completed. Documentation, Themes, Network bugfixes were implemented. No changes to the Fedora spec file were performed. Final build prior to 1.8 release ( pending any bugs ) spec: http://www.mudmagic.com/mud-client/downloads/mudmagic.spec srpm: http://www.mudmagic.com/mud-client/downloads/mudmagic-1.8-0.6.src.rpm tarball: http://www.mudmagic.com/mud-client/downloads/mudmagic-1.8.tar.gz Thank you all again for the tremendous support. Calvin -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 1 09:53:51 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 04:53:51 -0500 Subject: [Bug 179444] Review Request: perl-Class-Loader In-Reply-To: Message-ID: <200602010953.k119rpJC010973@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Class-Loader https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179444 paul at city-fan.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From paul at city-fan.org 2006-02-01 04:53 EST ------- Build on target fedora-development-extras succeeded. FC-4 branch requested. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From fedora at adslpipe.co.uk Wed Feb 1 10:22:16 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Wed, 01 Feb 2006 10:22:16 +0000 Subject: Best way to help a maintainer? Message-ID: <43E08BD8.7080407@adslpipe.co.uk> For a few packages in extras I've filed bugs, made patches and build rpms locally to fix bugs, upgrade versions or see if rebuilds are all that is required to get packages working again. It is obvious that some (all!) maintainers are busy, that is fair enough, we all have "day jobs" that will get priority, but sometimes it's frustrating to have helped out (only a tiny bit) and yet it doesn't lead to an updated package becoming available. I'm not talking about situations where a packages needs "rescuing" by having a new maintainer, A) who's to say that new is better, B) I don't want to seem ungrateful for the work of the maintainers. In general, what is the best way to see if any patch/upgrades that I think are beneficial, are really the whole story, i.e. will work on multiple arches, won't confuse the build system and are not retrograde changes? As a non-maintainer, is it possible to do this all locally, is plague required, can we have access to the build system, just to be able to test out patches up to the point where it possible to hand it back to the maintainer, as a hopefully simple option for them to verify and commit it? I suppose I'm asking is the situation, one package, one maintainer, one bottleneck? Thanks, Andy "I only want to help, don't take this as a complaint" Burns. From ivazquez at ivazquez.net Wed Feb 1 10:39:13 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 01 Feb 2006 05:39:13 -0500 Subject: Best way to help a maintainer? In-Reply-To: <43E08BD8.7080407@adslpipe.co.uk> References: <43E08BD8.7080407@adslpipe.co.uk> Message-ID: <1138790354.5102.7.camel@ignacio.lan> On Wed, 2006-02-01 at 10:22 +0000, Andy Burns wrote: > I suppose I'm asking is the situation, one package, one maintainer, one > bottleneck? Every Extras contributor can maintain every package (time notwithstanding), but there's also the reluctance to step on other people's toes since there is a loosely-defined concept of "package ownership" in Extras. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at adslpipe.co.uk Wed Feb 1 10:57:37 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Wed, 01 Feb 2006 10:57:37 +0000 Subject: Best way to help a maintainer? In-Reply-To: <1138790354.5102.7.camel@ignacio.lan> References: <43E08BD8.7080407@adslpipe.co.uk> <1138790354.5102.7.camel@ignacio.lan> Message-ID: <43E09421.4000304@adslpipe.co.uk> Ignacio Vazquez-Abrams wrote: > Every Extras contributor can maintain every package (time > notwithstanding), but there's also the reluctance to step on other > people's toes since there is a loosely-defined concept of "package > ownership" in Extras. OK, so a good approach would by trying to get the blessing of the "owners" in question? 2nd question, as I'm not an existing maintainer, and not bringing a new package to the party, and therefore have no "normal" route via fedotra account, cvs access, sponsorship, reviews etc, does this make it difficult to become a maintainer? Or should I try to find "an easy" package to bring into extras and do it that way? From bugzilla at redhat.com Wed Feb 1 11:03:57 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 06:03:57 -0500 Subject: [Bug 175198] Review Request: perl-Math-Pari In-Reply-To: Message-ID: <200602011103.k11B3v2I022474@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Math-Pari https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175198 ------- Additional Comments From paul at city-fan.org 2006-02-01 06:03 EST ------- (In reply to comment #1) > 1) Would you mind just hardcoding the pari version? The current construct > appears to be error prone: for example, it doesn't handle the current pari > development version - 2.2.12 - or any other version component with more > than 1 digit. > > If I assume the Math::Pari version as 2.021201 it will output 2.212 as > the pari version (it should output 2.2.12). > > $ echo 2.021201 | perl -pi -e 'tr/0/./;s/\.+/./;s/\.[^.]*$//' > 2.212 I'd really prefer to only have to change the one version number in the spec if possible, since (a) it makes the spec easier to maintain, and (b) it should ensure that I'm always using the "supported" version of the pari library. I've updated the expression, which should get it right in all cases now I think. > 2) There is also a new version available. Could you update? > > Diff from Math-Pari-2.010702 to Math-Pari-2.010703 > http://search.cpan.org/diff?from=Math-Pari-2.010702&to=Math-Pari-2.010703 Done: http://www.city-fan.org/~paul/extras/perl-Math-Pari/perl-Math-Pari-2.010703-1.src.rpm Spec URL unchanged. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugs.michael at gmx.net Wed Feb 1 11:22:27 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 1 Feb 2006 12:22:27 +0100 Subject: Best way to help a maintainer? In-Reply-To: <43E08BD8.7080407@adslpipe.co.uk> References: <43E08BD8.7080407@adslpipe.co.uk> Message-ID: <20060201122227.699a5b3b.bugs.michael@gmx.net> On Wed, 01 Feb 2006 10:22:16 +0000, Andy Burns wrote: > For a few packages in extras I've filed bugs, made patches and build > rpms locally to fix bugs, upgrade versions or see if rebuilds are all > that is required to get packages working again. > > It is obvious that some (all!) maintainers are busy, that is fair > enough, we all have "day jobs" that will get priority, but sometimes > it's frustrating to have helped out (only a tiny bit) and yet it doesn't > lead to an updated package becoming available. > > I'm not talking about situations where a packages needs "rescuing" by > having a new maintainer, A) who's to say that new is better, B) I don't > want to seem ungrateful for the work of the maintainers. > > In general, what is the best way to see if any patch/upgrades that I > think are beneficial, are really the whole story, i.e. will work on > multiple arches, won't confuse the build system and are not retrograde > changes? In theory, any well-made package that builds locally for you, _should_ also build in the FE build system (provided that build dependencies are complete). Testing the binaries at run-time is the other side of the story, however. Many packagers don't have access to more than a single platform. They rely on the upstream projects and on feedback which they get for upgrades published in Fedora Extras Development some time before they perform upgrades for older FC versions. > As a non-maintainer, is it possible to do this all locally, is plague > required, can we have access to the build system, just to be able to > test out patches up to the point where it possible to hand it back to > the maintainer, as a hopefully simple option for them to verify and > commit it? Running test-builds in "mock" should suffice. For many packages, running ordinary rpmbuilds should be enough. > I suppose I'm asking is the situation, one package, one maintainer, one > bottleneck? I cannot repeat it often enough. There is always the opportunity to build small teams of people who maintain a package together, provided they share thoughts and common ways of packaging up things. If different people only stepped on eachother's feet by reformatting spec files and by applying lots of other unimportant changes, a team would not become possible. Just talk to the current official package owner and find out. Also, it may be that the owner might give away a package if he gets the impression that a dedicated new package owner would be beneficial. The current "owners.list" in CVS already has the possbility to enter multiple people to CC in new bugzilla tickets. From Christian.Iseli at licr.org Wed Feb 1 11:51:06 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 01 Feb 2006 12:51:06 +0100 Subject: Some status and questions about owners file Message-ID: <200602011151.k11BpAWv030373@mx1.redhat.com> Hi folks, I've added some more checks to my package and BZ ticket checking script, and now have some questions: - what happens when a package goes from extras to core ? Should the "product" column be changed ? The matter is a bit compilcated by the fact that the package usually remains in extras for the previous/current releases - what's the general feeling about orphaned packages. Shouldn't they be removed from the devel repo until a maintainer steps up ? - there seems to be a sizeable amount of entries in owners file that have no corresponding package in the devel repo. Should BZ tickets be filed ? The matter here is a bit complicated because some packages might have been discontinued for devel but are still provided for older releases. Maybe there should be a way to indicate this in the owners file... I guess that's enough questions for now :-) Below is the current output of the script. Cheers, Christian --- === About owners file === We have 1410 extras packages in owners file. There are 65 orphans. Top 10 package owners: tcallawa at redhat dot com : 88 jpo at di dot uminho dot pt : 83 ville dot skytta at iki dot fi : 82 matthias at rpmforge dot net : 70 andreas dot bierfert at lowlatency dot de : 54 rc040203 at freenet dot de : 50 ivazquez at ivazquez dot net : 41 rdieter at math dot unl dot edu : 41 gauret at free dot fr : 40 steve at silug dot org : 35 We have 58 orphaned packages available in extras devel: abe anjuta apg apt arc at-poke bochs camstream cgoban cksfv conglomerate duplicity freedroidrpg galculator gdeskcal gkrellm-themes gnofract4d gnome-password-generator gnome-telnet gnome-themes-extras gnugo gonvert gpa gtkglarea2 gurlchecker hping2 libnet10 libzvt lincvs lua manedit meld mknbi netdiag nget ots p0f parchive perl-Net-SCP perl-Net-SSH perl-Parse-Yapp prozilla putty rpmproc scorched3d screem sirius synaptic tdl tetex-arabtex tetex-armtex tetex-font-tipa tetex-lgrind tla wbxml2 wesnoth xmms-cdread xtide We have 93 packages not available in extras devel: GiNaC R-RScaLAPACK R-hdf5 alsa-firmware amavisd-new apmud aqhbci-qt-tools buildsystem cdiff cdo compat-wxPythonGTK2 comps configure-thinkpad cryptplug dd_rescue drscheme ebtables fftw2 fillets-ng-data-cs freenx gcdmaster gcl gconfmm20 general gnome-applet-netmon gnome-cpufreq-applet gnome-theme-clearlooks gpredict gtkmm20 iiimf-le-simplehangul initng inti juk k3b-ape kiosktool kxdocker kxdocker-resources libgcrypt1 libglademm20 libgnomecanvasmm20 libgnomemm20 libgnomeuimm20 libgsf113 libmatchbox libsafe lirc-kmod lirc-kmod-common lout nabi newpg nx openbox opendap openoffice-extras osiv pam_pkcs11 perl-CPAN-DistnameInfo perl-Class-Loader perl-Convert-ASCII-Armour perl-Convert-PEM perl-Crypt-DES_EDE3 perl-GD-SVG perl-Graph perl-Heap perl-Parse-CPAN-Packages perl-SOAP-Lite perl-SVG perl-Text-Levenshtein perl-Text-Shellwords perl-XML-Writer perl-bioperl php-pear-DB php-pecl-sqlite qemu rsnapshot sblim-cmpi-base scrub smb4k squidGuard stripesnoop superkaramba swish-e tetex-beamer tetex-pgf tetex-xcolor thinkpad-kmod thinkpad-kmod-common tpctl wmweather+ wp_tray wxPython xaliclock yakuake We have 27 packages that moved to core: anthy firefox gmime kasumi libchewing libevent m17n-db m17n-lib nautilus-sendto perl-Archive-Zip perl-IO-String perl-IO-Zlib perl-Net-IP perl-String-CRC32 perl-XML-Simple python-elementtree python-sqlite scim scim-anthy scim-chewing scim-hangul scim-m17n scim-pinyin scim-qtimm scim-tables sqlite thunderbird === About FE-ACCEPT packages === We have 10 accepted, closed packages where I'm unable to find the package in the development repo: https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165488,168185,171601,172136,172144,172150,172151,173216,174266,179444 We have 5 accepted, closed packages where I'm unable to find the package in the owners file: https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165992,167863,168185,168920,171801 We have 464 accepted, closed package reviews Top 10 BZ review requests submitters: tcallawa at redhat dot com : 43 rc040203 at freenet dot de : 41 andreas dot bierfert at lowlatency dot de : 29 fedora dot wickert at arcor dot de : 28 jpo at di dot uminho dot pt : 24 rdieter at math dot unl dot edu : 18 pertusus at free dot fr : 14 orion at cora dot nwra dot com : 13 paul at city-fan dot org : 12 ivazquez at ivazquez dot net : 12 Top 10 BZ review requests reviewers: paul at city-fan dot org : 64 gauret at free dot fr : 63 gdk at redhat dot com : 34 jpmahowald at gmail dot com : 28 tcallawa at redhat dot com : 26 rc040203 at freenet dot de : 22 jpo at di dot uminho dot pt : 20 ed at eh3 dot com : 19 adrian at lisas dot de : 18 ville dot skytta at iki dot fi : 13 We have 11 accepted, open package reviews where the package appears to already be in the repo... All open packages already available: https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=166207,166251,166252,166253,166254,168905,176618,177038,177083,177166,179263 === About FE-NEW packages === We have 9 closed tickets still blocking FE-NEW https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=167621,168906,177272,177274,177662,177859,178141,178902,179039 === About FE-REVIEW packages === We have 1 closed tickets still blocking FE-REVIEW https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=172267 From bugzilla at redhat.com Wed Feb 1 12:11:57 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 07:11:57 -0500 Subject: [Bug 179439] Review Request: linux-libertine-fonts - TrueType serif fonts In-Reply-To: Message-ID: <200602011211.k11CBvhH001509@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: linux-libertine-fonts - TrueType serif fonts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179439 gajownik at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gajownik at gmail.com ------- Additional Comments From gajownik at gmail.com 2006-02-01 07:11 EST ------- (In reply to comment #1) > - Rename package to font-linux-libertine Are you shure? I was told that it shoud be fontname-fonts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165900#c6 (In reply to comment #6) > Just nuked the separate script file. It's now in %build. > > Spec: http://www.scirocco-5v-turbo.de/fedora/font-linux-libertine.spec # "touch" all files we've got flagged as %ghost but which are not # present in the RPM_BUILD_ROOT when RPM looks for files touch $RPM_BUILD_ROOT%{fontdir}/fonts.cache-1 touch $RPM_BUILD_ROOT%{fontdir}/fonts.cache-2 It's not necessary in FC5 ? http://www.redhat.com/archives/fedora-extras-list/2006-January/msg00918.html -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From jamatos at fc.up.pt Wed Feb 1 12:28:19 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Wed, 1 Feb 2006 12:28:19 +0000 Subject: Some status and questions about owners file In-Reply-To: <200602011151.k11BpAWv030373@mx1.redhat.com> References: <200602011151.k11BpAWv030373@mx1.redhat.com> Message-ID: <200602011228.19979.jamatos@fc.up.pt> On Wednesday 01 February 2006 11:51, Christian.Iseli at licr.org wrote: > tetex-beamer tetex-pgf tetex-xcolor Those packages are not available in extras since they have been absorbed by tetex-latex that belongs to Core, so in a sense they have moved to Core. :-) -- Jos? Ab?lio From bugzilla at redhat.com Wed Feb 1 13:05:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 08:05:13 -0500 Subject: [Bug 179439] Review Request: linux-libertine-fonts - TrueType serif fonts In-Reply-To: Message-ID: <200602011305.k11D5DCJ010139@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: linux-libertine-fonts - TrueType serif fonts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179439 frank at scirocco-5v-turbo.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From frank at scirocco-5v-turbo.de 2006-02-01 08:05 EST ------- (In reply to comment #7) > # "touch" all files we've got flagged as %ghost but which are not > # present in the RPM_BUILD_ROOT when RPM looks for files > touch $RPM_BUILD_ROOT%{fontdir}/fonts.cache-1 > touch $RPM_BUILD_ROOT%{fontdir}/fonts.cache-2 > > It's not necessary in FC5 ? > http://www.redhat.com/archives/fedora-extras-list/2006-January/msg00918.html Thanks for the link. I will remove touching and ghosting fonts.cache-2, but continue to handle fonts.cache-1 for FC4 as it doesn't hurt on FC5. Just waiting for a final naming decision. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 1 13:18:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 08:18:49 -0500 Subject: [Bug 179439] Review Request: linux-libertine-fonts - TrueType serif fonts In-Reply-To: Message-ID: <200602011318.k11DInfd011904@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: linux-libertine-fonts - TrueType serif fonts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179439 ------- Additional Comments From frank at scirocco-5v-turbo.de 2006-02-01 08:18 EST ------- > frank scirocco-5v-turbo de changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |ASSIGNED I swear I haven't played with this field. Just was not logged in while typing and was asked for login afterwards. Can someone set it back to NEW please? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 1 15:27:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 10:27:18 -0500 Subject: [Bug 177204] Review Request: translate-toolkit - A collection of tools to assist software localization In-Reply-To: Message-ID: <200602011527.k11FRIUK004121@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: translate-toolkit - A collection of tools to assist software localization https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177204 roozbeh at farsiweb.info changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From roozbeh at farsiweb.info 2006-02-01 10:27 EST ------- Thanks a lot for the review. Imported and built. Filed rc6 enhancement request as bug 179577. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 1 15:36:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 10:36:20 -0500 Subject: [Bug 177658] Review Request: mediawiki - The PHP-based wiki software behind Wikipedia In-Reply-To: Message-ID: <200602011536.k11FaKhG006502@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mediawiki - The PHP-based wiki software behind Wikipedia https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177658 ------- Additional Comments From imlinux at gmail.com 2006-02-01 10:36 EST ------- Forgot something, replace PreReq with plain old Requires, soon the difference between Requires and PreReq will be phased out: http://fedoraproject.org/wiki/Packaging/Guidelines#tags -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From meme at DaughtersOfTiresias.org Wed Feb 1 15:51:48 2006 From: meme at DaughtersOfTiresias.org (Karen Pease) Date: Wed, 1 Feb 2006 09:51:48 -0600 Subject: Retrying: magic file / invalid type 20 in mconvert()? Message-ID: <200602010951.48560.meme@DaughtersOfTiresias.org> I sent this to the list before and it didn't get a response. Does anyone have a clue what is going on here? - Karen ---------- Forwarded Message ---------- Subject: magic file / invalid type 20 in mconvert()? Date: Monday 30 January 2006 02:08 pm From: Karen Pease To: fedora-extras-list at redhat.com I have absolutely no clue what this means. Doing a local "make i386" while attempting to solve a problem that used to just manifest on the plague servers: Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.77844 + umask 022 + cd /home/meme/code/fedora/nethack-vultures/FC-3 + cd vultures-1.11.2 + DOCDIR=/var/tmp/nethack-vultures-1.11.2-3-root-meme/usr/share/doc/nethack-vul tures-1.11.2 + export DOCDIR + rm -rf /var/tmp/nethack-vultures-1.11.2-3-root-meme/usr/share/doc/nethack-vultures-1 .11.2 + /bin/mkdir -p /var/tmp/nethack-vultures-1.11.2-3-root-meme/usr/share/doc/nethack-vultures-1 .11.2 + cp -pr nethack/README nethack/dat/license nethack/dat/history nethack/dat/cmdhelp nethack/dat/help nethack/dat/opthelp nethack/dat/wizhelp /var/tmp/nethack-vultures-1.11.2-3-root-meme/usr/share/doc/nethack-vultures-1 .11.2 + cp -pr slashem/readme.txt slashem/history.txt slashem/slamfaq.txt vultures/gamedata/manual/ /var/tmp/nethack-vultures-1.11.2-3-root-meme/usr/share/doc/nethack-vultures-1 .11.2 + exit 0 error: magic_file(ms, "/var/tmp/nethack-vultures-1.11.2-3-root-meme/usr/games/vulturesclaw/Guideboo k.txt") failed: invalid type 20 in mconvert() rpmbuild: rpmfc.c:1229: rpmfcClassify: Assertion `ftype != ((void *)0)' failed. make: *** [i386] Aborted I'm fairly new to the process of building RPMs for Fedora Extras. What does this even mean? - Karen -- fedora-extras-list mailing list fedora-extras-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-extras-list ------------------------------------------------------- From paul at cypherpunks.ca Wed Feb 1 15:59:21 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Wed, 1 Feb 2006 16:59:21 +0100 (CET) Subject: Some status and questions about owners file In-Reply-To: <200602011151.k11BpAWv030373@mx1.redhat.com> References: <200602011151.k11BpAWv030373@mx1.redhat.com> Message-ID: On Wed, 1 Feb 2006, Christian.Iseli at licr.org wrote: > There are 65 orphans. > We have 58 orphaned packages available in extras devel: What happened to 7 orphans? > abe anjuta apg apt arc at-poke bochs camstream cgoban cksfv conglomerate > duplicity freedroidrpg galculator gdeskcal gkrellm-themes gnofract4d > gnome-password-generator gnome-telnet gnome-themes-extras gnugo gonvert gpa > gtkglarea2 gurlchecker hping2 libnet10 libzvt lincvs lua manedit meld mknbi > netdiag nget ots p0f parchive perl-Net-SCP perl-Net-SSH perl-Parse-Yapp > prozilla putty rpmproc scorched3d screem sirius synaptic tdl tetex-arabtex > tetex-armtex tetex-font-tipa tetex-lgrind tla wbxml2 wesnoth xmms-cdread xtide I would not mind taking on putty and hping2/hping3 if they are really orphaned. > We have 93 packages not available in extras devel: Are these approved, but not yet created? Or have some of these been waiting for a very long time? If the original submitter of these packages are lost, I wouldn't mind taking on dd_rescue and xdaliclock. > We have 9 closed tickets still blocking FE-NEW > https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=167621,168906,177272,177274,177662,177859,178141,178902,179039 How are they still blocking when they are closed? One of those (179039) was a misfire from my browser and I closed it as duplicate for my proper request. Is there any action that should be taken on my side? Paul -- "Happiness is never grand" --- Mustapha Mond, World Controller (Brave New World) From Christian.Iseli at licr.org Wed Feb 1 16:15:08 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 01 Feb 2006 17:15:08 +0100 Subject: Some status and questions about owners file In-Reply-To: Your message of "Wed, 01 Feb 2006 16:59:21 +0100." Message-ID: <200602011615.k11GF89n025225@ludwig-alpha.unil.ch> paul at cypherpunks.ca said: > > We have 58 orphaned packages available in extras devel: > What happened to 7 orphans? The 7 others simply have no longer a package in the devel repo. > I would not mind taking on putty and hping2/hping3 if they are really > orphaned. Yes, according to http://fedoraproject.org/wiki/Extras/OrphanedPackages (though only hping2 is listed in my list and on the wiki). > Are these approved, but not yet created? Or have some of these been waiting > for a very long time? If the original submitter of these packages are lost, I > wouldn't mind taking on dd_rescue and xdaliclock. They are listed in the owners file and have a maintainer. If you want details, you could email the maintainer or open a BZ ticket for the component. > How are they still blocking when they are closed? One of those (179039) was a > misfire from my browser and I closed it as duplicate for my proper request. > Is there any action that should be taken on my side? Closing a bug does not automatically remove the blocker. It needs to be done manualy (clear the "Bug 179039 blocks" field, which appears to have been done now :-) ) Cheers, Christian From fedora at leemhuis.info Wed Feb 1 16:24:44 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 01 Feb 2006 17:24:44 +0100 Subject: Some status and questions about owners file In-Reply-To: References: <200602011151.k11BpAWv030373@mx1.redhat.com> Message-ID: <1138811084.3202.78.camel@localhost.localdomain> Am Mittwoch, den 01.02.2006, 16:59 +0100 schrieb Paul Wouters: > On Wed, 1 Feb 2006, Christian.Iseli at licr.org wrote: > > We have 93 packages not available in extras devel: > > Are these approved, but not yet created? Don't know about all of those, but I know the details of some: alsa-firmware -- outstanding legal review (my package) buildsystem general -- these don't sound like real packages, but they are needed in bugzilla lirc-kmod lirc-kmod-common thinkpad-kmod thinkpad-kmod-common -- in progress, wait for the kmod work in the buildsys gconfmm20 gtkmm20 libglademm20 libgnomecanvasmm20 libgnomemm20 libgnomeuimm20 -- probably all obsoleted by newer versions with different names qemu - some people recently talked in #fedora-devel to bring it back to live (che, ignacio, dwmw2 iirc) wxPython -- not sure, but I think wxPythonGTK2 does the same job fine today -- Thorsten Leemhuis From bugzilla at redhat.com Wed Feb 1 16:30:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 11:30:21 -0500 Subject: [Bug 177315] Review Request: python-enchant - Python bindings for Enchant spellchecking library In-Reply-To: Message-ID: <200602011630.k11GULTV020298@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: python-enchant - Python bindings for Enchant spellchecking library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177315 roozbeh at farsiweb.info changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From roozbeh at farsiweb.info 2006-02-01 11:30 EST ------- Thanks a lot for the review. Import and built. I filed the 1.1.5 update request as bug 179593. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From paul at city-fan.org Wed Feb 1 17:12:31 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 01 Feb 2006 17:12:31 +0000 Subject: Retrying: magic file / invalid type 20 in mconvert()? In-Reply-To: <200602010951.48560.meme@DaughtersOfTiresias.org> References: <200602010951.48560.meme@DaughtersOfTiresias.org> Message-ID: <43E0EBFF.1090909@city-fan.org> Karen Pease wrote: > I sent this to the list before and it didn't get a response. Does anyone have > a clue what is going on here? > > - Karen > > ---------- Forwarded Message ---------- > > Subject: magic file / invalid type 20 in mconvert()? > Date: Monday 30 January 2006 02:08 pm > From: Karen Pease > To: fedora-extras-list at redhat.com > > I have absolutely no clue what this means. Doing a local "make i386" while > attempting to solve a problem that used to just manifest on the plague > servers: > > Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.77844 > + umask 022 > + cd /home/meme/code/fedora/nethack-vultures/FC-3 > + cd vultures-1.11.2 > + > DOCDIR=/var/tmp/nethack-vultures-1.11.2-3-root-meme/usr/share/doc/nethack-vul > tures-1.11.2 + export DOCDIR > + rm -rf > /var/tmp/nethack-vultures-1.11.2-3-root-meme/usr/share/doc/nethack-vultures-1 > .11.2 + /bin/mkdir -p > /var/tmp/nethack-vultures-1.11.2-3-root-meme/usr/share/doc/nethack-vultures-1 > .11.2 + cp -pr nethack/README nethack/dat/license nethack/dat/history > nethack/dat/cmdhelp nethack/dat/help nethack/dat/opthelp nethack/dat/wizhelp > /var/tmp/nethack-vultures-1.11.2-3-root-meme/usr/share/doc/nethack-vultures-1 > .11.2 + cp -pr slashem/readme.txt slashem/history.txt slashem/slamfaq.txt > vultures/gamedata/manual/ > /var/tmp/nethack-vultures-1.11.2-3-root-meme/usr/share/doc/nethack-vultures-1 > .11.2 + exit 0 > error: magic_file(ms, > "/var/tmp/nethack-vultures-1.11.2-3-root-meme/usr/games/vulturesclaw/Guideboo > k.txt") failed: invalid type 20 in mconvert() > rpmbuild: rpmfc.c:1229: rpmfcClassify: Assertion `ftype != ((void *)0)' > failed. > make: *** [i386] Aborted > > I'm fairly new to the process of building RPMs for Fedora Extras. What does > this even mean? Is this repeatable? The current nethack-vultures package in cvs for FC-3 builds OK in mock for FC-3 i386 for me. Paul. From rdieter at math.unl.edu Wed Feb 1 17:21:25 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 01 Feb 2006 11:21:25 -0600 Subject: Broken dependencies in Fedora Extras 5 In-Reply-To: <200602011705.k11H5l86029368@mathstat.unl.edu> References: <200602011705.k11H5l86029368@mathstat.unl.edu> Message-ID: <43E0EE15.5090208@math.unl.edu> Michael Schwendt wrote: > This is an automated mail. > Your following packages in the repository have broken dependencies: > > package: geomview-plugins - 1.8.1-11.i386 from fedora-extras-development-i386 > unresolved deps: > geomview = 0:1.8.1 geomview-plugins is deprecated (Obsoleted by newer geomview pkgs), so it can go away. -- Rex From bugzilla at redhat.com Wed Feb 1 17:16:58 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 12:16:58 -0500 Subject: [Bug 174377] Review Request:gnu-smalltalk - GNU Smalltalk In-Reply-To: Message-ID: <200602011716.k11HGwsp031867@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request:gnu-smalltalk - GNU Smalltalk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174377 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-01 12:16 EST ------- Thank you for your respone. For the first point, I need more input. Did you get any error message for the failed test? For the seconed point, I have done some fixed but I will get the following error messages from rpmlint E: gnu-smalltalk binary-or-shlib-defines-rpath /usr/bin/gst ['/home/pclinux/redhat/BUILD/smalltalk-2.2/libgst/.libs'] E: gnu-smalltalk shlib-with-non-pic-code /usr/lib/libgst.so.4.1. It will be nice if you have any hint to solve this problem. For testing I have uploaded a current version at: SrPM: http://www.herr-schmitt.de/pub/gnu-smalltalk/gnu-smalltalk-2.2-7.src.rpm SPEC: http://www.herr-schmitt.de/pub/gnu-smalltalk/gnu-smalltalk.spec Best Regards: Jochen Schmitt -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From pertusus at free.fr Wed Feb 1 17:35:57 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 1 Feb 2006 18:35:57 +0100 Subject: taking perl-Parse-Yapp Message-ID: <20060201173557.GD2688@free.fr> Hello, If nobody is interested, I am volunteering to maintain perl-Parse-Yapp. -- Pat From meme at DaughtersOfTiresias.org Wed Feb 1 18:01:21 2006 From: meme at DaughtersOfTiresias.org (Karen Pease) Date: Wed, 1 Feb 2006 12:01:21 -0600 Subject: Retrying: magic file / invalid type 20 in mconvert()? Message-ID: <200602011201.21222.meme@DaughtersOfTiresias.org> > Is this repeatable? The current nethack-vultures package in cvs for FC-3 > builds OK in mock for FC-3 i386 for me. > > Paul. Yes, it is. The FC-3 version builds on the plague server, but the FC-4 and devel versions don't (even though they're essentially identical specfiles apart from the changelogs). None of them build locally on my FC5t2 system. - Karen On Wednesday 01 February 2006 11:12 am, Paul Howarth wrote: > Karen Pease wrote: > > I sent this to the list before and it didn't get a response. Does anyone > > have a clue what is going on here? > > > > - Karen > > > > ---------- Forwarded Message ---------- > > > > Subject: magic file / invalid type 20 in mconvert()? > > Date: Monday 30 January 2006 02:08 pm > > From: Karen Pease > > To: fedora-extras-list at redhat.com > > > > I have absolutely no clue what this means. Doing a local "make i386" > > while attempting to solve a problem that used to just manifest on the > > plague servers: > > > > Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.77844 > > + umask 022 > > + cd /home/meme/code/fedora/nethack-vultures/FC-3 > > + cd vultures-1.11.2 > > + > > DOCDIR=/var/tmp/nethack-vultures-1.11.2-3-root-meme/usr/share/doc/nethack > >-vul tures-1.11.2 + export DOCDIR > > + rm -rf > > /var/tmp/nethack-vultures-1.11.2-3-root-meme/usr/share/doc/nethack-vultur > >es-1 .11.2 + /bin/mkdir -p > > /var/tmp/nethack-vultures-1.11.2-3-root-meme/usr/share/doc/nethack-vultur > >es-1 .11.2 + cp -pr nethack/README nethack/dat/license nethack/dat/history > > nethack/dat/cmdhelp nethack/dat/help nethack/dat/opthelp > > nethack/dat/wizhelp > > /var/tmp/nethack-vultures-1.11.2-3-root-meme/usr/share/doc/nethack-vultur > >es-1 .11.2 + cp -pr slashem/readme.txt slashem/history.txt > > slashem/slamfaq.txt vultures/gamedata/manual/ > > /var/tmp/nethack-vultures-1.11.2-3-root-meme/usr/share/doc/nethack-vultur > >es-1 .11.2 + exit 0 > > error: magic_file(ms, > > "/var/tmp/nethack-vultures-1.11.2-3-root-meme/usr/games/vulturesclaw/Guid > >eboo k.txt") failed: invalid type 20 in mconvert() > > rpmbuild: rpmfc.c:1229: rpmfcClassify: Assertion `ftype != ((void *)0)' > > failed. > > make: *** [i386] Aborted > > > > I'm fairly new to the process of building RPMs for Fedora Extras. What > > does this even mean? ------------------------------------------------------- From bugzilla at redhat.com Wed Feb 1 18:09:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 13:09:33 -0500 Subject: [Bug 177096] Review Request: fonttools: A tool to convert True/OpenType fonts to XML and back In-Reply-To: Message-ID: <200602011809.k11I9XOC010809@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: fonttools: A tool to convert True/OpenType fonts to XML and back https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177096 ------- Additional Comments From roozbeh at farsiweb.info 2006-02-01 13:09 EST ------- (In reply to comment #2) > Needs work: > * Encoding should be UTF-8 Encoding of which file is not UTF-8?! > * No downloadable source. Please give the full URL in the Source tag. > I know the source from cvs are not downloadable but it is a MUST item. Maybe you > can ask maintainer to make a snapshot ? It seems that the developer has created snapshots not long before stopping the development. Updated version: Spec Url: http://guava.farsiweb.info/~roozbeh/fonttools.spec SRPM Url: http://guava.farsiweb.info/~roozbeh/fonttools-2.0-0.3.20050624cvs.src.rpm %changelog - Use upstream snapshots, moving the difference into a patch - Change alphatag time to the latest change in CVS - Use %%{python_sitearch} instead of %%{python_sitelib} (for x86_86) - Use sed instead of a patch to remove shebang -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From paul at city-fan.org Wed Feb 1 18:37:01 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 01 Feb 2006 18:37:01 +0000 Subject: Retrying: magic file / invalid type 20 in mconvert()? In-Reply-To: <200602011201.21222.meme@DaughtersOfTiresias.org> References: <200602011201.21222.meme@DaughtersOfTiresias.org> Message-ID: <1138819021.17403.5.camel@laurel.intra.city-fan.org> On Wed, 2006-02-01 at 12:01 -0600, Karen Pease wrote: > > Is this repeatable? The current nethack-vultures package in cvs for FC-3 > > builds OK in mock for FC-3 i386 for me. > > > > Paul. > > Yes, it is. The FC-3 version builds on the plague server, but the FC-4 and > devel versions don't (even though they're essentially identical specfiles > apart from the changelogs). None of them build locally on my FC5t2 system. Ah, I tried an FC-3 build because that appeared to be what the "fail" log was from. I'll have a try building for FC-4 tomorrow if the problem hasn't been resolved by then, Paul. From paul at cypherpunks.ca Wed Feb 1 18:48:56 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Wed, 1 Feb 2006 19:48:56 +0100 (CET) Subject: perl-IO-stringy vs perl-IO-Stringy ? In-Reply-To: <20060201173557.GD2688@free.fr> References: <20060201173557.GD2688@free.fr> Message-ID: Hi, Sholdn't the package perl-IO-stringy be called perl-IO-Stringy? That makes it more consistent with the other perl modules. Paul From ianburrell at gmail.com Wed Feb 1 19:27:08 2006 From: ianburrell at gmail.com (Ian Burrell) Date: Wed, 1 Feb 2006 11:27:08 -0800 Subject: perl-IO-stringy vs perl-IO-Stringy ? In-Reply-To: References: <20060201173557.GD2688@free.fr> Message-ID: On 2/1/06, Paul Wouters wrote: > > Sholdn't the package perl-IO-stringy be called perl-IO-Stringy? > > That makes it more consistent with the other perl modules. > The standard naming conversion for Perl modules is to name them after the CPAN package. For most things on CPAN, the package is named after the primary module. So HTML::Mason is in HTML-Mason cpan package which becomes perl-HTML-Mason RPM. Some older modules have packages which are named differently. For example, LWP module is in perl-libwww-perl. IO-stringy is the name of the CPAN package; there is an IO::Stringy module but it is just documentation. - Ian From kevin-fedora-extras at scrye.com Wed Feb 1 20:21:56 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Wed, 01 Feb 2006 13:21:56 -0700 (MST) Subject: non building packages list Message-ID: <20060201.132156.628631317.kevin@scrye.com> Greetings. As I mentioned a while ago, I was doing a mass rebuild on all the extras packages against current devel/fc5 with mock to try and spot packages that wouldn't rebuild correctly. (Not only because it's nice to have packages that build and work, but it would be nice if most packages built before any mass rebuild effort.). In the end I identified 182 packages that didn't build. Of those, 23 are now fixed. That leaves 159 packages that need to get fixed up. The list is available at: http://www.scrye.com/~kevin/mock-broken.html It has a section sorted by owners name, and a section by package name. (Although perl-Imager is in cvs, but not owners and doesn't build, so it can't be sorted by owner name. :) I am also attaching the owner sorted list to this email. I am going through and filing bugs on them, but I only have the first block of them filed so far. If I have filed a bug and you fixed the build issues, please remember to close the bug. Links to the bugs are available at the above web page. If you see one of your packages there, please do try and fix it up to build. If you would like more information from my mock run, you can find me on #fedora-extras on irc.freenode.net, nick: nirik. Or feel free to email me. kevin -- aaron.bennett at olin.edu ifplugd adrian at lisas.de cvsup adrian at lisas.de kover adrian at lisas.de uudeview adrian at lisas.de xdesktopwaves andreas at bawue.net mod_suphp andreas.bierfert at lowlatency.de fbdesk andreas.bierfert at lowlatency.de fluxbox andreas.bierfert at lowlatency.de wmweather+ aportal at univ-montp2.fr gpsim bressers at redhat.com nmh bugs.michael at gmx.net gai-temp colin at fedoraproject.org MagicPoint dakingun at gmail.com qalculate-kde denis at poolshark.org galeon denis at poolshark.org gcdmaster dennis at ausil.us kphone dmitry at butskoy.name gnome-translate dwmw2 at redhat.com apmud dwmw2 at redhat.com qemu eric.tanguy at univ-nantes.fr qucs extras-orphan at fedoraproject.org camstream extras-orphan at fedoraproject.org cgoban extras-orphan at fedoraproject.org gnofract4d extras-orphan at fedoraproject.org gnome-telnet extras-orphan at fedoraproject.org hula extras-orphan at fedoraproject.org libzvt extras-orphan at fedoraproject.org lincvs extras-orphan at fedoraproject.org mknbi extras-orphan at fedoraproject.org monkey-bubble extras-orphan at fedoraproject.org scorched3d extras-orphan at fedoraproject.org screem extras-orphan at fedoraproject.org snort extras-orphan at fedoraproject.org synaptic extras-orphan at fedoraproject.org xtide fedora at leemhuis.info alsa-firmware gajownik at gmail.com python-sqlite2 gauret at free.fr amarok gauret at free.fr amaya gauret at free.fr libvisual gauret at free.fr pdftohtml gauret at free.fr stow gauret at free.fr wv gauret at free.fr xbindkeys gemi at bluewin.ch audacity gemi at bluewin.ch gcl gemi at bluewin.ch GtkAda gemi at bluewin.ch lablgl gemi at bluewin.ch lablgtk gemi at bluewin.ch skencil gemi at bluewin.ch TeXmacs gemi at bluewin.ch unison ghenry at suretecsystems.com john ghenry at suretecsystems.com pgadmin3 ghenry at suretecsystems.com rsnapshot green at redhat.com jogl green at redhat.com kawa icon at fedoraproject.org python-logilab-common ivazquez at ivazquez.net deskbar-applet ivazquez at ivazquez.net eet ivazquez at ivazquez.net gpredict ivazquez at ivazquez.net hamlib ivazquez at ivazquez.net leafpad ivazquez at ivazquez.net notecase ivazquez at ivazquez.net python-formencode jcarpenter at condell.org tpb jeff at ultimateevil.org up-imapproxy jfontain at free.fr tktable Jochen at herr-schmitt.de stellarium jpo at di.uminho.pt perl-GD jspaleta at gmail.com istanbul jylitalo at iki.fi python-imaging jylitalo at iki.fi xplanet kaboom at oobleck.net qgo kaboom at oobleck.net xboard kaboom at oobleck.net xdaliclock liljencrantz at gmail.com fish llch at redhat.com libtabe llch at redhat.com xcin lmacken at redhat.com nethack lmacken at redhat.com python-myghty lmacken at redhat.com valknut markmc at redhat.com sabayon mattdm at mattdm.org wxGTK mattdm at mattdm.org wxPythonGTK2 matthias at rpmforge.net djvulibre matthias at rpmforge.net Gtk-Perl matthias at rpmforge.net gtktalog matthias at rpmforge.net hackedbox matthias at rpmforge.net metakit matthias at rpmforge.net p7zip matthias at rpmforge.net php-eaccelerator matthias at rpmforge.net php-mmcache matthias at rpmforge.net php-pecl-sqlite matthias at rpmforge.net plib matthias at rpmforge.net plib16 matthias at rpmforge.net powermanga matthias at rpmforge.net proftpd matthias at rpmforge.net torcs matthias at rpmforge.net xvattr meme at daughtersoftiresias.org nethack-vultures michel.salim at gmail.com gai michel.salim at gmail.com gai-pal nos at utelsystems.com neverball notting at redhat.com jed orion at cora.nwra.com gv orion at cora.nwra.com plplot pertusus at free.fr libdap pertusus at free.fr libnc-dap petersen at redhat.com ghc pjones at redhat.com python-goopy qspencer at ieee.org fftw3 qspencer at ieee.org ginac qspencer at ieee.org octave-forge rdieter at math.unl.edu factory rdieter at math.unl.edu gc rdieter at math.unl.edu kipi-plugins rdieter at math.unl.edu libfac rdieter at math.unl.edu lyx rdieter at math.unl.edu Macaulay2 rdieter at math.unl.edu superkaramba redhat-bugzilla at camperquake.de fwbuilder redhat-bugzilla at camperquake.de libfwbuilder redhat at flyn.org linkchecker redhat at flyn.org pam_mount rpm at timj.co.uk php-pear-DB shahms at shahms.com python-psycopg skvidal at phy.duke.edu seahorse steve at silug.org celestia steve at silug.org cone steve at silug.org gl-117 steve at silug.org supertux steve at silug.org tuxpaint tagoh at redhat.com Canna tagoh at redhat.com kinput2 tcallawa at redhat.com compat-wxGTK tcallawa at redhat.com compat-wxPythonGTK2 tcallawa at redhat.com libgdamm tcallawa at redhat.com opendap tcallawa at redhat.com rocksndiamonds tcallawa at redhat.com R-RScaLAPACK tcallawa at redhat.com scalapack tcallawa at redhat.com wlassistant tcallawa at redhat.com xbase tcallawa at redhat.com xbsql thm at duke.edu perl-bioperl thm at duke.edu perl-GD-SVG thm at duke.edu perl-Graph thomas at apestaart.org flumotion thomas at apestaart.org ladspa tmraz at redhat.com workrave toniw at iki.fi libmatchbox toshio at tiki-lounge.com gnotime tripwire-devel at genesis-x.nildram.co.uk tripwire ville.skytta at iki.fi fedora-rpmdevtools ville.skytta at iki.fi w3c-markup-validator wtogami at redhat.com iiimf-le-simplehangul zipsonic at gmail.com nx -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugzilla at redhat.com Wed Feb 1 20:26:42 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 15:26:42 -0500 Subject: [Bug 177865] Review Request: adplay In-Reply-To: Message-ID: <200602012026.k11KQgaY009325@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: adplay https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177865 ------- Additional Comments From triad at df.lth.se 2006-02-01 15:26 EST ------- Spec Name or Url: http://www.df.lth.se/~triad/krad/fc/adplay.spec SRPM Name or Url: http://www.df.lth.se/~triad/krad/fc/adplay-1.4-4.src.rpm Fixes for the stuff pointed out by Michael. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From toshio at tiki-lounge.com Wed Feb 1 20:32:42 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 01 Feb 2006 12:32:42 -0800 Subject: non building packages list In-Reply-To: <20060201.132156.628631317.kevin@scrye.com> References: <20060201.132156.628631317.kevin@scrye.com> Message-ID: <1138825962.3359.5.camel@localhost> On Wed, 2006-02-01 at 13:21 -0700, Kevin Fenzi wrote: > I am going through and filing bugs on them, but I only have the first > block of them filed so far. If I have filed a bug and you fixed the > build issues, please remember to close the bug. Links to the bugs are > available at the above web page. > > If you see one of your packages there, please do try and fix it up to > build. If you would like more information from my mock run, you can > find me on #fedora-extras on irc.freenode.net, nick: nirik. Or feel > free to email me. Hi Kevin -- If you have the config.log from the gnotime failure that might be of help to me. (Or even better -- if you have the ability to tar the gnotime build directory and put it on the web where I can download it...) I know that gnotime is failing due to changes to modular X and the configure check but I'm neither running devel nor have a rawhide mirror so running I'm unable to run a local build and find out what's wrong. If you don't have that, I'll fix it after I upgrade to FC5. -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 bugzilla at redhat.com Wed Feb 1 20:28:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 15:28:13 -0500 Subject: [Bug 178360] Review Request: xmms-adplug In-Reply-To: Message-ID: <200602012028.k11KSDfF009692@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xmms-adplug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178360 ------- Additional Comments From triad at df.lth.se 2006-02-01 15:28 EST ------- Spec Name or Url: http://www.df.lth.se/~triad/krad/fc/xmms-adplug.spec SRPM Name or Url: http://www.df.lth.se/~triad/krad/fc/xmms-adplug-1.1-5.src.rpm Fixes for the problems pointed out by Michael in bug 177865. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 1 21:01:46 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 16:01:46 -0500 Subject: [Bug 177567] Review Request: smb4k - The SMB/CIFS Share Browser for KDE In-Reply-To: Message-ID: <200602012101.k11L1ksN017154@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: smb4k - The SMB/CIFS Share Browser for KDE https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177567 mgarski at post.pl changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From mgarski at post.pl 2006-02-01 16:01 EST ------- - Fix GCC warnings - Don't own KDE directories -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From caillon at redhat.com Wed Feb 1 21:29:37 2006 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 01 Feb 2006 16:29:37 -0500 Subject: Fedora Extras RPMs should have Vendor and Packager? Message-ID: <43E12841.1030402@redhat.com> I just was doing rpm -qi on a few packages, and noticed that packages built in Extras don't have a vendor associated with them. Not that anybody ever really looks at these things, but we should probably set up the extras build system so that it prefills the vendor pertaining to Fedora somehow. We might also want to add "Packager" `rpm -qi` is not that uncommon a task, and it would be subtle self-advertising. Push that brand, push it hard! Output for a package from Core vs Extras: % rpm -qi NetworkManager Name : NetworkManager Relocations: (not relocatable) Version : 0.5.1 Vendor: Red Hat, Inc. Release : 8.cvs20060131 Build Date: Tue 31 Jan 2006 02:54:22 PM EST Install Date: Wed 01 Feb 2006 01:10:20 PM EST Build Host: ls20-bc1-13.build.redhat.com Group : System Environment/Base Source RPM: NetworkManager-0.5.1-8.cvs20060131.src.rpm Size : 1035776 License: GPL Signature : (none) Packager : Red Hat, Inc. URL : http://www.gnome.org/projects/NetworkManager/ Summary : Network connection manager and user applications Description : NetworkManager attempts to keep an active network connection available at all times. It is intended only for the desktop use-case, and is not intended for usage on servers. The point of NetworkManager is to make networking configuration and setup as painless and automatic as possible. If using DHCP, NetworkManager is _intended_ to replace default routes, obtain IP addresses from a DHCP server, and change nameservers whenever it sees fit. % rpm -qi NetworkManager-vpnc Name : NetworkManager-vpnc Relocations: (not relocatable) Version : 0.5.0 Vendor: (none) Release : 1 Build Date: Sun 29 Jan 2006 10:22:36 PM EST Install Date: Tue 31 Jan 2006 02:16:55 PM EST Build Host: hammer1.fedora.redhat.com Group : System Environment/Base Source RPM: NetworkManager-vpnc-0.5.0-1.src.rpm Size : 124687 License: GPL Signature : DSA/SHA1, Mon 30 Jan 2006 09:51:57 PM EST, Key ID 82ed95041ac70ce6 Summary : NetworkManager VPN integration for vpnc Description : This package contains software for integrating the vpnc VPN software with NetworkManager and the GNOME desktop From mmcgrath at fedoraproject.org Wed Feb 1 21:45:12 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 01 Feb 2006 15:45:12 -0600 Subject: Fedora Extras RPMs should have Vendor and Packager? In-Reply-To: <43E12841.1030402@redhat.com> References: <43E12841.1030402@redhat.com> Message-ID: <43E12BE8.2020300@fedoraproject.org> > > Name : NetworkManager-vpnc Relocations: (not relocatable) > Version : 0.5.0 Vendor: (none) > Release : 1 Build Date: Sun 29 Jan > 2006 10:22:36 PM EST > Install Date: Tue 31 Jan 2006 02:16:55 PM EST Build Host: > hammer1.fedora.redhat.com > Group : System Environment/Base Source RPM: > NetworkManager-vpnc-0.5.0-1.src.rpm > Size : 124687 License: GPL > Signature : DSA/SHA1, Mon 30 Jan 2006 09:51:57 PM EST, Key ID > 82ed95041ac70ce6 > Summary : NetworkManager VPN integration for vpnc > Description : > This package contains software for integrating the vpnc VPN software > with NetworkManager and the GNOME desktop > At present its policy not to include these tags: http://www.fedoraproject.org/wiki/Packaging/Guidelines#tags -Mike From bugzilla at redhat.com Wed Feb 1 21:44:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 16:44:59 -0500 Subject: [Bug 177096] Review Request: fonttools: A tool to convert True/OpenType fonts to XML and back In-Reply-To: Message-ID: <200602012144.k11LixQ6026068@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: fonttools: A tool to convert True/OpenType fonts to XML and back https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177096 eric.tanguy at univ-nantes.fr changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From eric.tanguy at univ-nantes.fr 2006-02-01 16:44 EST ------- (In reply to comment #3) > (In reply to comment #2) > > Needs work: > > * Encoding should be UTF-8 > > Encoding of which file is not UTF-8?! Sorry it was a mistake! > > > * No downloadable source. Please give the full URL in the Source tag. > > I know the source from cvs are not downloadable but it is a MUST item. Maybe you > > can ask maintainer to make a snapshot ? > > It seems that the developer has created snapshots not long before stopping the > development. > > Updated version: > > Spec Url: http://guava.farsiweb.info/~roozbeh/fonttools.spec > SRPM Url: http://guava.farsiweb.info/~roozbeh/fonttools-2.0-0.3.20050624cvs.src.rpm > > %changelog > - Use upstream snapshots, moving the difference into a patch > - Change alphatag time to the latest change in CVS > - Use %%{python_sitearch} instead of %%{python_sitelib} (for x86_86) > - Use sed instead of a patch to remove shebang > Review for release 0.3.20050624cvs: * RPM name is OK * Source fonttools-2005-03-15.210812.tar.bz2 is the same as upstream * Builds fine in mock * rpmlint of fonttools looks OK * File list of fonttools looks OK APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From ivazquez at ivazquez.net Wed Feb 1 21:51:11 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 01 Feb 2006 16:51:11 -0500 Subject: Fedora Extras RPMs should have Vendor and Packager? In-Reply-To: <43E12841.1030402@redhat.com> References: <43E12841.1030402@redhat.com> Message-ID: <1138830671.5102.10.camel@ignacio.lan> On Wed, 2006-02-01 at 16:29 -0500, Christopher Aillon wrote: > I just was doing rpm -qi on a few packages, and noticed that packages > built in Extras don't have a vendor associated with them. > > Not that anybody ever really looks at these things, but we should > probably set up the extras build system so that it prefills the vendor > pertaining to Fedora somehow. We might also want to add "Packager" You're not wrong, but currently mock and plague don't have the ability to define Packager dynamically. Fortunately Vendor is a lot easier and should require only a small change in the mock configuration files in order to set it to "Fedora Extras". -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From caillon at redhat.com Wed Feb 1 21:51:27 2006 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 01 Feb 2006 16:51:27 -0500 Subject: Fedora Extras RPMs should have Vendor and Packager? In-Reply-To: <43E12BE8.2020300@fedoraproject.org> References: <43E12841.1030402@redhat.com> <43E12BE8.2020300@fedoraproject.org> Message-ID: <43E12D5F.7010602@redhat.com> On 02/01/2006 04:45 PM, Mike McGrath wrote: > At present its policy not to include these tags: > > http://www.fedoraproject.org/wiki/Packaging/Guidelines#tags > > -Mike > No. I meant for the build system to auto add them. Core packages do not specify them in the spec either. From ivazquez at ivazquez.net Wed Feb 1 21:52:37 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 01 Feb 2006 16:52:37 -0500 Subject: non building packages list In-Reply-To: <20060201.132156.628631317.kevin@scrye.com> References: <20060201.132156.628631317.kevin@scrye.com> Message-ID: <1138830757.5102.12.camel@ignacio.lan> On Wed, 2006-02-01 at 13:21 -0700, Kevin Fenzi wrote: > I am going through and filing bugs on them, but I only have the first > block of them filed so far. If I have filed a bug and you fixed the > build issues, please remember to close the bug. Links to the bugs are > available at the above web page. > ivazquez at ivazquez.net gpredict > ivazquez at ivazquez.net hamlib Don't bother filing against these. I know that they are currently very broken. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From caillon at redhat.com Wed Feb 1 21:57:17 2006 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 01 Feb 2006 16:57:17 -0500 Subject: Fedora Extras RPMs should have Vendor and Packager? In-Reply-To: <43E12D5F.7010602@redhat.com> References: <43E12841.1030402@redhat.com> <43E12BE8.2020300@fedoraproject.org> <43E12D5F.7010602@redhat.com> Message-ID: <43E12EBD.6020006@redhat.com> On 02/01/2006 04:51 PM, Christopher Aillon wrote: > On 02/01/2006 04:45 PM, Mike McGrath wrote: >> At present its policy not to include these tags: >> >> http://www.fedoraproject.org/wiki/Packaging/Guidelines#tags >> >> -Mike >> Also, the packaging link you provided notes that: > The Vendor tag should not be used. It is set automatically by the build system. which it isn't currently, and is what I'm complaining about :-) > > No. I meant for the build system to auto add them. Core packages do > not specify them in the spec either. > From michael at knox.net.nz Wed Feb 1 21:58:17 2006 From: michael at knox.net.nz (Michael J Knox) Date: Thu, 02 Feb 2006 10:57:17 +1259 Subject: Fedora Extras RPMs should have Vendor and Packager? In-Reply-To: <43E12BE8.2020300@fedoraproject.org> References: <43E12841.1030402@redhat.com> <43E12BE8.2020300@fedoraproject.org> Message-ID: <43E12ED4.3060603@knox.net.nz> Mike McGrath wrote: >> Name : NetworkManager-vpnc Relocations: (not relocatable) >> Version : 0.5.0 Vendor: (none) >> Release : 1 Build Date: Sun 29 Jan >> 2006 10:22:36 PM EST >> Install Date: Tue 31 Jan 2006 02:16:55 PM EST Build Host: >> hammer1.fedora.redhat.com >> Group : System Environment/Base Source RPM: >> NetworkManager-vpnc-0.5.0-1.src.rpm >> Size : 124687 License: GPL >> Signature : DSA/SHA1, Mon 30 Jan 2006 09:51:57 PM EST, Key ID >> 82ed95041ac70ce6 >> Summary : NetworkManager VPN integration for vpnc >> Description : >> This package contains software for integrating the vpnc VPN software >> with NetworkManager and the GNOME desktop >> > > At present its policy not to include these tags: > > http://www.fedoraproject.org/wiki/Packaging/Guidelines#tags > > -Mike > Why can't mock use "%vendor Fedora Extras" and "%package fedora-extras at fedoraproject.org" (or whatever generic email) in its rpmmacros file to define these fields? Michael From toshio at tiki-lounge.com Wed Feb 1 22:10:15 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 01 Feb 2006 14:10:15 -0800 Subject: Fedora Extras RPMs should have Vendor and Packager? In-Reply-To: <1138830671.5102.10.camel@ignacio.lan> References: <43E12841.1030402@redhat.com> <1138830671.5102.10.camel@ignacio.lan> Message-ID: <1138831815.3359.11.camel@localhost> On Wed, 2006-02-01 at 16:51 -0500, Ignacio Vazquez-Abrams wrote: > You're not wrong, but currently mock and plague don't have the ability > to define Packager dynamically. Fortunately Vendor is a lot easier and > should require only a small change in the mock configuration files in > order to set it to "Fedora Extras". > We don't necessarily need to set Packager to be the maintainer of the package. It could be more akin to the tags on Core Packages: Packager: Red Hat, Inc. So, something like: %packager Fedora Extras should be okay. -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 kevin-fedora-extras at scrye.com Wed Feb 1 22:14:15 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Wed, 01 Feb 2006 15:14:15 -0700 (MST) Subject: non building packages list References: <20060201.132156.628631317.kevin@scrye.com> <1138825962.3359.5.camel@localhost> Message-ID: <20060201.151415.668598140.kevin@scrye.com> >>>>> "Toshio" == Toshio Kuratomi writes: Toshio> On Wed, 2006-02-01 at 13:21 -0700, Kevin Fenzi wrote: >> I am going through and filing bugs on them, but I only have the >> first block of them filed so far. If I have filed a bug and you >> fixed the build issues, please remember to close the bug. Links to >> the bugs are available at the above web page. >> >> If you see one of your packages there, please do try and fix it up >> to build. If you would like more information from my mock run, you >> can find me on #fedora-extras on irc.freenode.net, nick: nirik. Or >> feel free to email me. Toshio> Hi Kevin -- If you have the config.log from the gnotime Toshio> failure that might be of help to me. (Or even better -- if Toshio> you have the ability to tar the gnotime build directory and Toshio> put it on the web where I can download it...) I know that Toshio> gnotime is failing due to changes to modular X and the Toshio> configure check but I'm neither running devel nor have a Toshio> rawhide mirror so running I'm unable to run a local build and Toshio> find out what's wrong. Toshio> If you don't have that, I'll fix it after I upgrade to FC5. I can probibly get that for you in a while. All I have left from the mock run is the build.log, it doesn't keep the build directories around (ie, no config.log). I tried to re-run mock on my test machine, but it's running into the current sqlite breaking yum, and it doesn't build. ;( The build.log has: checking for localtime_r... yes configure: error: X development libraries not found error: Bad exit status from /var/tmp/rpm-tmp.41009 (%build) You might look at the configure script and see what tests it's doing there. What headers it's looking for? what libs it's looking for? I can try and get you the config.log in the next few days. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Wed Feb 1 22:27:49 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 01 Feb 2006 17:27:49 -0500 Subject: non building packages list In-Reply-To: <20060201.151415.668598140.kevin@scrye.com> References: <20060201.132156.628631317.kevin@scrye.com> <1138825962.3359.5.camel@localhost> <20060201.151415.668598140.kevin@scrye.com> Message-ID: <1138832869.8430.1.camel@orodruin.boston.redhat.com> On Wed, 2006-02-01 at 15:14 -0700, Kevin Fenzi wrote: > The build.log has: > > checking for localtime_r... yes > configure: error: X development libraries not found > error: Bad exit status from /var/tmp/rpm-tmp.41009 (%build) > > You might look at the configure script and see what tests it's doing > there. What headers it's looking for? what libs it's looking for? In many cases, this is due to buildrequires not being fully updated for the change to modular X Jeremy From ville.skytta at iki.fi Wed Feb 1 22:58:37 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 02 Feb 2006 00:58:37 +0200 Subject: taking perl-Parse-Yapp In-Reply-To: <20060201173557.GD2688@free.fr> References: <20060201173557.GD2688@free.fr> Message-ID: <1138834717.12245.34.camel@bobcat.mine.nu> On Wed, 2006-02-01 at 18:35 +0100, Patrice Dumas wrote: > If nobody is interested, I am volunteering to maintain perl-Parse-Yapp. Great, thanks. Would you mind taking over the dependent perl-XML-XQL too? ...and perl-XML-DOM, perl-XML-RegExp and perl-XML-XPath. These packages are pretty intertwined and would benefit from being maintained by someone who actually uses them (unlike yours truly). Just go ahead and grab them if you're interested. From gajownik at fedora.pl Wed Feb 1 23:12:46 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Thu, 02 Feb 2006 00:12:46 +0100 Subject: non building packages list In-Reply-To: <20060201.132156.628631317.kevin@scrye.com> References: <20060201.132156.628631317.kevin@scrye.com> Message-ID: <43E1406E.8050902@fedora.pl> Dnia 02/01/2006 09:22 PM, U?ytkownik Kevin Fenzi napisa?: > gajownik at gmail.com python-sqlite2 Yes, I know about it. It's caused by some changes in python-setuptools. It's an easy fix but python-sqlite2 stopped working after sqlite update to version 3.3.3 and I'll need to contact with upstream first before releasing new package. Regards, Dawid -- ^_* From toshio at tiki-lounge.com Wed Feb 1 23:19:36 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 01 Feb 2006 15:19:36 -0800 Subject: non building packages list In-Reply-To: <1138832869.8430.1.camel@orodruin.boston.redhat.com> References: <20060201.132156.628631317.kevin@scrye.com> <1138825962.3359.5.camel@localhost> <20060201.151415.668598140.kevin@scrye.com> <1138832869.8430.1.camel@orodruin.boston.redhat.com> Message-ID: <1138835976.3359.16.camel@localhost> On Wed, 2006-02-01 at 17:27 -0500, Jeremy Katz wrote: > On Wed, 2006-02-01 at 15:14 -0700, Kevin Fenzi wrote: > > The build.log has: > > > > checking for localtime_r... yes > > configure: error: X development libraries not found > > error: Bad exit status from /var/tmp/rpm-tmp.41009 (%build) > > > > You might look at the configure script and see what tests it's doing > > there. What headers it's looking for? what libs it's looking for? > > In many cases, this is due to buildrequires not being fully updated for > the change to modular X > Yeah -- I added the X libraries that gnotime actually links against to the BuildRequires but it looks like configure is bombing out because it's searching for unnecessary X libraries. AC_PATH_XTRA is the autconf macro that's generating the check but without a little more info, about what the check is failing to link against, I'm shooting in the dark. -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 katzj at redhat.com Wed Feb 1 23:35:12 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 01 Feb 2006 18:35:12 -0500 Subject: non building packages list In-Reply-To: <1138835976.3359.16.camel@localhost> References: <20060201.132156.628631317.kevin@scrye.com> <1138825962.3359.5.camel@localhost> <20060201.151415.668598140.kevin@scrye.com> <1138832869.8430.1.camel@orodruin.boston.redhat.com> <1138835976.3359.16.camel@localhost> Message-ID: <1138836913.5164.7.camel@bree.local.net> On Wed, 2006-02-01 at 15:19 -0800, Toshio Kuratomi wrote: > Yeah -- I added the X libraries that gnotime actually links against to > the BuildRequires but it looks like configure is bombing out because > it's searching for unnecessary X libraries. AC_PATH_XTRA is the autconf > macro that's generating the check but without a little more info, about > what the check is failing to link against, I'm shooting in the dark. Looking at /usr/share/autoconf/autoconf/libs.m4 (where AC_PATH_XTRA is defined), it seems that AC_PATH_XTRA looks for libICE and libSM, so adding libICE-devel and libSM-devel to the buildrequires should do it Jeremy From ville.skytta at iki.fi Wed Feb 1 23:46:08 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 02 Feb 2006 01:46:08 +0200 Subject: non building packages list In-Reply-To: <20060201.132156.628631317.kevin@scrye.com> References: <20060201.132156.628631317.kevin@scrye.com> Message-ID: <1138837568.12245.41.camel@bobcat.mine.nu> On Wed, 2006-02-01 at 13:21 -0700, Kevin Fenzi wrote: > I am going through and filing bugs on them, [...] > ville.skytta at iki.fi fedora-rpmdevtools https://bugzilla.redhat.com/178636 > ville.skytta at iki.fi w3c-markup-validator https://bugzilla.redhat.com/149454 , build explicitly made to fail in %prep, see specfile for more info. From orion at cora.nwra.com Wed Feb 1 23:51:14 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 01 Feb 2006 16:51:14 -0700 Subject: non building packages list In-Reply-To: <20060201.132156.628631317.kevin@scrye.com> References: <20060201.132156.628631317.kevin@scrye.com> Message-ID: <43E14972.4060802@cora.nwra.com> Kevin Fenzi wrote: > orion at cora.nwra.com gv > orion at cora.nwra.com plplot Fixed. They were being flagged by the fixed mock for having unpackaged files. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From frank at scirocco-5v-turbo.de Wed Feb 1 23:55:19 2006 From: frank at scirocco-5v-turbo.de (Frank Arnold) Date: Thu, 02 Feb 2006 00:55:19 +0100 Subject: Retrying: magic file / invalid type 20 in mconvert()? In-Reply-To: <200602010951.48560.meme@DaughtersOfTiresias.org> References: <200602010951.48560.meme@DaughtersOfTiresias.org> Message-ID: <1138838119.23183.34.camel@localhost> Am Mittwoch, den 01.02.2006, 09:51 -0600 schrieb Karen Pease: > error: magic_file(ms, > "/var/tmp/nethack-vultures-1.11.2-3-root-meme/usr/games/vulturesclaw/Guideboo > k.txt") failed: invalid type 20 in mconvert() > rpmbuild: rpmfc.c:1229: rpmfcClassify: Assertion `ftype != ((void *)0)' > failed. > make: *** [i386] Aborted rpmbuild tries to determine the file type of Guidebook.txt, which seems to fail. You should be able to reproduce this with $ file -m /usr/lib/rpm/magic /path/to/Guidebook.txt If not, I have no clue what's going on. I tried to build nethack-vultures-1.11.1-3 through mock with FC4 setup. This failed with another error. The following command failed inside BUILD/vultures-1.11.1/slashem/doc: tbl tmac.n Guidebook.mn | nroff -c -Tascii | col -bx > Guidebook.txt The problem here is that col returns 1, although the output looks usable to me. This might be related to a patch in util-linux (util-linux-2.12p-col-EILSEQ.patch, Bug 176441) which is only applied to FC4 and FC5. Workaround is quite easy. With the following change inside your nethack-vultures-1.10.1-clawguide.patch I was able to build the package: Current: +GUIDECMD = tbl tmac.n Guidebook.mn | nroff -c -Tascii | $(COLCMD) New: +GUIDECMD = tbl tmac.n Guidebook.mn | nroff -c -Tascii | $(COLCMD) | cat Now 'cat' is the last command and it returns 0. HTH, Frank From bugzilla at redhat.com Thu Feb 2 00:22:04 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 19:22:04 -0500 Subject: [Bug 168838] Review Request: cpanspec In-Reply-To: Message-ID: <200602020022.k120M40m021452@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cpanspec https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168838 ------- Additional Comments From steve at silug.org 2006-02-01 19:21 EST ------- http://ftp.kspei.com/pub/steve/rpms/cpanspec-1.59-2.src.rpm * Wed Feb 01 2006 Steven Pritchard 1.59-2 - URL/Source0 on SourceForge. - Use a more appropriate Group. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From toshio at tiki-lounge.com Thu Feb 2 00:59:40 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 01 Feb 2006 16:59:40 -0800 Subject: non building packages list In-Reply-To: <1138836913.5164.7.camel@bree.local.net> References: <20060201.132156.628631317.kevin@scrye.com> <1138825962.3359.5.camel@localhost> <20060201.151415.668598140.kevin@scrye.com> <1138832869.8430.1.camel@orodruin.boston.redhat.com> <1138835976.3359.16.camel@localhost> <1138836913.5164.7.camel@bree.local.net> Message-ID: <1138841980.3359.27.camel@localhost> On Wed, 2006-02-01 at 18:35 -0500, Jeremy Katz wrote: > On Wed, 2006-02-01 at 15:19 -0800, Toshio Kuratomi wrote: > > Yeah -- I added the X libraries that gnotime actually links against to > > the BuildRequires but it looks like configure is bombing out because > > it's searching for unnecessary X libraries. AC_PATH_XTRA is the autconf > > macro that's generating the check but without a little more info, about > > what the check is failing to link against, I'm shooting in the dark. > > Looking at /usr/share/autoconf/autoconf/libs.m4 (where AC_PATH_XTRA is > defined), it seems that AC_PATH_XTRA looks for libICE and libSM, so > adding libICE-devel and libSM-devel to the buildrequires should do it > > Jeremy > Yep. That was my first thought:: [devel]$ grep libSM-devel gnotime.spec BuildRequires: libSM-devel [devel]$ repoquery --repoid=development --requires libSM-devel libICE-devel libSM = 1.0.0-2 xorg-x11-filesystem >= 0.99.2-3 So unless yum isn't picking up on the libSM-devel -> libICE-devel dependency, this isn't the problem.... Hmm... From:: http://buildsys.fedoraproject.org/logs/fedora-development-extras/3430-gnotime-2.2.2-2.fc5/i386/root.log [...] Install: libSM-devel.i386 0:1.0.0-2 - core [...] Install: libICE-devel.i386 0:1.0.0-2 - core [...] So there's something else that's missing. -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 bugzilla at redhat.com Thu Feb 2 01:01:58 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 1 Feb 2006 20:01:58 -0500 Subject: [Bug 176374] Review Request: nagios-plugins In-Reply-To: Message-ID: <200602020101.k1211waL027173@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: nagios-plugins https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176374 jkeating at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jkeating at redhat.com ------- Additional Comments From jkeating at redhat.com 2006-02-01 20:01 EST ------- The attached srpm in comment #7 does not compile well on an x86_64 system. The configure run does not find the required mysql libs to create the check_mysql. I'm looking into it to see why this is happening. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From buildsys at fedoraproject.org Thu Feb 2 01:38:49 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 1 Feb 2006 20:38:49 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060202013849.043708078@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 5 git-1.1.6-1.fc3 js-1.5-2.fc3 nethack-vultures-1.11.2-3.fc3 perl-File-Slurp-9999.11-1.fc3 perl-Text-Unidecode-0.04-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu Feb 2 01:39:02 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 1 Feb 2006 20:39:02 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060202013902.70D9C8078@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 11 fftw2-2.1.5-11.fc4 fontforge-20060125-1.fc4 gazpacho-0.6.5-1.fc4 git-1.1.6-1.fc4 grace-5.1.19-2.fc4 js-1.5-2.fc4 perl-Class-Autouse-1.21-2.fc4 perl-File-Slurp-9999.11-1.fc4 perl-Params-Validate-0.80-1.fc4 perl-Text-Unidecode-0.04-1.fc4 spicctrl-1.9-2.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu Feb 2 01:43:31 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 1 Feb 2006 20:43:31 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060202014331.A928B8078@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 33 GtkAda-2.4.0-10.fc5 bazaar-1.4.2-4.fc5 diction-1.08-1.1.fc5 fftw2-2.1.5-11.fc5 fontforge-20060125-3.fc5 fontforge-20060125-4.fc5 gazpacho-0.6.5-1.fc5 git-1.1.6-1.fc5 gv-3.6.1-6.fc5 gwget-0.97-1.fc5 kdesvn-0.7.3-1.fc5 libnet10-1.0.2a-9.fc5 libopensync-plugin-evolution2-0.18-5.fc5 liferea-1.0.3-2.fc5 mgopen-fonts-0.20050515-3.fc5 perl-Class-Autouse-1.21-2.fc5 perl-Class-Loader-2.03-1.fc5 perl-File-Slurp-9999.11-1.fc5 perl-Params-Validate-0.80-1.fc5 plplot-5.5.3-11.fc5 python-enchant-1.1.3-3.fc5 python-sqlite2-2.1.3-1.fc5 qscintilla-1.6-3.1.fc5 smb4k-0.6.5-5.fc5 tla-1.3.3-4.fc5 translate-toolkit-0.8-0.5.rc5.fc5 xfce-mcs-plugins-4.2.3-2.fc5 xfce-utils-4.2.3-2.fc5 xfce4-iconbox-4.2.3-2.fc5 xfce4-panel-4.2.3-2.fc5 xfce4-session-4.2.3-2.fc5 xfdesktop-4.2.3-2.fc5 xffm-4.2.3-2.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From kevin-fedora-extras at scrye.com Thu Feb 2 02:47:30 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Wed, 01 Feb 2006 19:47:30 -0700 (MST) Subject: non building packages list References: <20060201.132156.628631317.kevin@scrye.com> <1138825962.3359.5.camel@localhost> <20060201.151415.668598140.kevin@scrye.com> <1138832869.8430.1.camel@orodruin.boston.redhat.com> <1138835976.3359.16.camel@localhost> <1138836913.5164.7.camel@bree.local.net> Message-ID: <20060201.194730.944183415.kevin@scrye.com> >>>>> "Toshio" == Toshio Kuratomi writes: Toshio> On Wed, 2006-02-01 at 18:35 -0500, Jeremy Katz wrote: >> On Wed, 2006-02-01 at 15:19 -0800, Toshio Kuratomi wrote: > Yeah -- >> I added the X libraries that gnotime actually links against to > >> the BuildRequires but it looks like configure is bombing out >> because > it's searching for unnecessary X libraries. AC_PATH_XTRA >> is the autconf > macro that's generating the check but without a >> little more info, about > what the check is failing to link >> against, I'm shooting in the dark. >> >> Looking at /usr/share/autoconf/autoconf/libs.m4 (where AC_PATH_XTRA >> is defined), it seems that AC_PATH_XTRA looks for libICE and libSM, >> so adding libICE-devel and libSM-devel to the buildrequires should >> do it >> >> Jeremy >> Toshio> Yep. That was my first thought:: [devel]$ grep libSM-devel Toshio> gnotime.spec BuildRequires: libSM-devel Toshio> [devel]$ repoquery --repoid=development --requires libSM-devel Toshio> libICE-devel libSM = 1.0.0-2 xorg-x11-filesystem >= 0.99.2-3 Toshio> So unless yum isn't picking up on the libSM-devel -> Toshio> libICE-devel dependency, this isn't the Toshio> problem.... Hmm... From:: Toshio> http://buildsys.fedoraproject.org/logs/fedora-development-extras/3430-gnotime-2.2.2-2.fc5/i386/root.log Toshio> [...] Install: libSM-devel.i386 0:1.0.0-2 - core [...] Toshio> Install: libICE-devel.i386 0:1.0.0-2 - core [...] Toshio> So there's something else that's missing. I have a config.log from a mock build for you. http://www.scrye.com/~kevin/config.log Hopefully that will help. If you would like access to a devel box, I can set you up with access to my test machine. Just drop me an email off list if you would be interested. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Thu Feb 2 02:59:32 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 02 Feb 2006 03:59:32 +0100 Subject: non building packages list In-Reply-To: <20060201.194730.944183415.kevin@scrye.com> References: <20060201.132156.628631317.kevin@scrye.com> <1138825962.3359.5.camel@localhost> <20060201.151415.668598140.kevin@scrye.com> <1138832869.8430.1.camel@orodruin.boston.redhat.com> <1138835976.3359.16.camel@localhost> <1138836913.5164.7.camel@bree.local.net> <20060201.194730.944183415.kevin@scrye.com> Message-ID: <1138849173.31136.21.camel@mccallum.corsepiu.local> On Wed, 2006-02-01 at 19:47 -0700, Kevin Fenzi wrote: > http://www.scrye.com/~kevin/config.log Probably a broken configure script: The X11 check this configure script uses, checks for libXt (cf. X11/Intrinsic.h) instead of libX. BR: libXt-devel inside of the spec should be applicalbe to work around this issue. The actual fix would be to fix the configure script to not look for Xt header (X11/Intrinsic.h) but for an X-header. Ralf From ankit644 at yahoo.com Thu Feb 2 06:46:00 2006 From: ankit644 at yahoo.com (Ankit Patel) Date: Wed, 1 Feb 2006 22:46:00 -0800 (PST) Subject: Wiki-Update (Was: Re: How to update the package?) In-Reply-To: <52055.192.54.193.25.1138288170.squirrel@rousalka.dyndns.org> Message-ID: <20060202064600.8060.qmail@web34612.mail.mud.yahoo.com> --- Nicolas Mailhot wrote: > > Le Jeu 26 janvier 2006 13:44, Ankit Patel a ???crit : > > > So, > > > > Here are the Final steps :- > > 1 ./cvs-import.sh -b -m "import > Joe's > > update" ~/bar-2.1-1.src.rpm > > 2 cd ../ > > 3 make plague > > > > Correct me if i am wrong again ! > > That's what works for me. > You have to use dist carefully to avoid collisions > though > > -- > Nicolas Mailhot > > -- Finally, i have updated the fedoraproject wiki page. Here is the link for that:- http://fedoraproject.org/wiki/Extras/UsingCvsFaq#head-c4a59abbe737f54d05eecdce17583c5547fee73d Can somebody please look at it and modify if there is any mistake? Thank You! Ankit Patel __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From eric.tanguy at univ-nantes.fr Thu Feb 2 07:28:47 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Thu, 02 Feb 2006 08:28:47 +0100 Subject: Mock question Message-ID: <1138865327.3207.2.camel@bureau.maison> I have a fc4 box. Is it possible with a special configuration to try to build a package against the devel version ? I see in /etc/mock : default.cfg fedora-5-i386-core.cfg fedora-3-i386-core.cfg fedora-5-ppc-core.cfg fedora-3-x86_64-core.cfg fedora-5-x86_64-core.cfg fedora-4-i386-core.cfg fedora-development-i386-core.cfg fedora-4-i386-core.cfg~ fedora-development-ppc-core.cfg fedora-4-ppc-core.cfg fedora-development-x86_64-core.cfg fedora-4-x86_64-core.cfg why there is fedora-5 and fedora-development Eric From paul at city-fan.org Thu Feb 2 07:29:04 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 02 Feb 2006 07:29:04 +0000 Subject: Wiki-Update (Was: Re: How to update the package?) In-Reply-To: <20060202064600.8060.qmail@web34612.mail.mud.yahoo.com> References: <20060202064600.8060.qmail@web34612.mail.mud.yahoo.com> Message-ID: <1138865344.17403.8.camel@laurel.intra.city-fan.org> On Wed, 2006-02-01 at 22:46 -0800, Ankit Patel wrote: > --- Nicolas Mailhot > wrote: > > > > > Le Jeu 26 janvier 2006 13:44, Ankit Patel a ???crit > : > > > > > So, > > > > > > Here are the Final steps :- > > > 1 ./cvs-import.sh -b -m "import > > Joe's > > > update" ~/bar-2.1-1.src.rpm > > > 2 cd ../ > > > 3 make plague > > > > > > Correct me if i am wrong again ! > > > > That's what works for me. > > You have to use dist carefully to avoid collisions > > though > > > > -- > > Nicolas Mailhot > > > > -- > > Finally, i have updated the fedoraproject wiki page. > Here is the link for that:- > http://fedoraproject.org/wiki/Extras/UsingCvsFaq#head-c4a59abbe737f54d05eecdce17583c5547fee73d > > Can somebody please look at it and modify if there is > any mistake? Isn't "make tag" still needed before "make plague", and isn't "make build" preferred to "make plague"? Paul. From paul at city-fan.org Thu Feb 2 07:33:35 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 02 Feb 2006 07:33:35 +0000 Subject: Mock question In-Reply-To: <1138865327.3207.2.camel@bureau.maison> References: <1138865327.3207.2.camel@bureau.maison> Message-ID: <1138865615.17403.11.camel@laurel.intra.city-fan.org> On Thu, 2006-02-02 at 08:28 +0100, Eric Tanguy wrote: > I have a fc4 box. Is it possible with a special configuration to try to > build a package against the devel version ? > > I see in /etc/mock : > default.cfg fedora-5-i386-core.cfg > fedora-3-i386-core.cfg fedora-5-ppc-core.cfg > fedora-3-x86_64-core.cfg fedora-5-x86_64-core.cfg > fedora-4-i386-core.cfg fedora-development-i386-core.cfg > fedora-4-i386-core.cfg~ fedora-development-ppc-core.cfg > fedora-4-ppc-core.cfg fedora-development-x86_64-core.cfg > fedora-4-x86_64-core.cfg > why there is fedora-5 and fedora-development One is a symlink to the other. "mock -r fedora-5-i386-core your.src.rpm" will build a development i386 package. Since I don't run rawhide myself, this is the only way I have of checking that packages build on rawhide. Paul. From ankit644 at yahoo.com Thu Feb 2 07:40:43 2006 From: ankit644 at yahoo.com (Ankit Patel) Date: Wed, 1 Feb 2006 23:40:43 -0800 (PST) Subject: Wiki-Update (Was: Re: How to update the package?) In-Reply-To: <1138865344.17403.8.camel@laurel.intra.city-fan.org> Message-ID: <20060202074043.24419.qmail@web34612.mail.mud.yahoo.com> --- Paul Howarth wrote: > On Wed, 2006-02-01 at 22:46 -0800, Ankit Patel > wrote: > > --- Nicolas Mailhot > > wrote: > > > > > > > > Le Jeu 26 janvier 2006 13:44, Ankit Patel a > ???crit > > : > > > > > > > So, > > > > > > > > Here are the Final steps :- > > > > 1 ./cvs-import.sh -b -m "import > > > Joe's > > > > update" ~/bar-2.1-1.src.rpm > > > > 2 cd ../ > > > > 3 make plague > > > > > > > > Correct me if i am wrong again ! > > > > > > That's what works for me. > > > You have to use dist carefully to avoid > collisions > > > though > > > > > > -- > > > Nicolas Mailhot > > > > > > -- > > > > Finally, i have updated the fedoraproject wiki > page. > > Here is the link for that:- > > > http://fedoraproject.org/wiki/Extras/UsingCvsFaq#head-c4a59abbe737f54d05eecdce17583c5547fee73d > > > > Can somebody please look at it and modify if there > is > > any mistake? > > Isn't "make tag" still needed before "make plague", > and isn't "make > build" preferred to "make plague"? > > Paul. > > -- After reading http://www.redhat.com/archives/fedora-extras-list/2006-January/msg01701.html and trying this way only i thought to add them into CVS-FAQ section of fedoraproject.org! Regards, Ankit Patel __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From ivazquez at ivazquez.net Thu Feb 2 07:41:51 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 02 Feb 2006 02:41:51 -0500 Subject: Mock question In-Reply-To: <1138865327.3207.2.camel@bureau.maison> References: <1138865327.3207.2.camel@bureau.maison> Message-ID: <1138866111.23767.15.camel@ignacio.lan> On Thu, 2006-02-02 at 08:28 +0100, Eric Tanguy wrote: > why there is fedora-5 and fedora-development Because when 5 stable is out development can be pointed to 6 instead and no scripts will need to be changed (except for the silly ones that use 5 when they actually mean devel, of course). -- 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 gajownik at fedora.pl Thu Feb 2 09:24:23 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Thu, 02 Feb 2006 10:24:23 +0100 Subject: non building packages list In-Reply-To: <43E1406E.8050902@fedora.pl> References: <20060201.132156.628631317.kevin@scrye.com> <43E1406E.8050902@fedora.pl> Message-ID: <43E1CFC7.5030307@fedora.pl> Dnia 02/02/2006 12:10 AM, U?ytkownik Dawid Gajownik napisa?: > It's an easy fix but python-sqlite2 stopped working after sqlite update > to version 3.3.3 Should be fixed now. -- ^_* From pertusus at free.fr Thu Feb 2 09:28:41 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 2 Feb 2006 10:28:41 +0100 Subject: non building packages list In-Reply-To: <20060201.132156.628631317.kevin@scrye.com> References: <20060201.132156.628631317.kevin@scrye.com> Message-ID: <20060202092841.GA31807@free.fr> > pertusus at free.fr libdap > pertusus at free.fr libnc-dap I am aware of that. This seems to be a non conformance in C++ code revealed by newer g++. I reported it upstream, hopefully it will be fixed there, then I'll update. -- Pat From bugzilla at redhat.com Thu Feb 2 09:59:14 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 04:59:14 -0500 Subject: [Bug 179707] New: Review Request: dap-server - Basic request handling for DAP servers Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179707 Summary: Review Request: dap-server - Basic request handling for DAP servers Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: gdk at redhat.com ReportedBy: pertusus at free.fr QAContact: dkl at redhat.com CC: fedora-extras-list at redhat.com SRPM Name or Url: http://www.environnement.ens.fr/perso/dumas/fc-srpms/dap-server-3.5.3-1.src.rpm Description: This is base software for our workhorse server. Written using the DAP++ C++ library and Perl, this handles processing compressed files and arranging for the correct server module to process the file. The base software also provides support for the ASCII response and HTML data-request form. Use this in combination with one or more of the format-specific handlers. This package contains all the executable and perl modules. The scripts and config files that should be installed in a cgi directory are in the documentation directory with -sample appended. If you want a package that is usable without manual configuration, install dap-server-cgi. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 2 10:01:26 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 05:01:26 -0500 Subject: [Bug 179708] New: Review Request: freeform_handler - FreeForm data handler for the OPeNDAP Data server Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179708 Summary: Review Request: freeform_handler - FreeForm data handler for the OPeNDAP Data server Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: gdk at redhat.com ReportedBy: pertusus at free.fr QAContact: dkl at redhat.com CC: fedora-extras-list at redhat.com SRPM Name or Url: Description: http://www.environnement.ens.fr/perso/dumas/fc-srpms/freeform_handler-3.5.0-1.src.rpm This is the foreeform data handler for our data server. It reads ASCII, binary and DB4 files which have been described using FreeForm and returns DAP responses that are compatible with DAP2 and the dap-server 3.5 software. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 2 10:03:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 05:03:15 -0500 Subject: [Bug 179709] New: Review Request: hdf4_handler - HDF4 data handler for the OPeNDAP Data server Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179709 Summary: Review Request: hdf4_handler - HDF4 data handler for the OPeNDAP Data server Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: gdk at redhat.com ReportedBy: pertusus at free.fr QAContact: dkl at redhat.com CC: fedora-extras-list at redhat.com SRPM Name or Url: http://www.environnement.ens.fr/perso/dumas/fc-srpms/hdf4_handler-3.5.0-1.src.rpm Description: This is the hdf4 data handler for our data server. It reads HDF4 and HDF-EOS files and returns DAP responses that are compatible with DAP2 and the dap-server 3.5 software. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 2 10:04:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 05:04:49 -0500 Subject: [Bug 179710] New: Review Request: netcdf_handler - NetCDF 3 data handler for the OPeNDAP Data server Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179710 Summary: Review Request: netcdf_handler - NetCDF 3 data handler for the OPeNDAP Data server Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: gdk at redhat.com ReportedBy: pertusus at free.fr QAContact: dkl at redhat.com CC: fedora-extras-list at redhat.com SRPM Name or Url: http://www.environnement.ens.fr/perso/dumas/fc-srpms/netcdf_handler-3.5.2-1.src.rpm Description: This is the netcdf data handler for our data server. It reads netcdf 3 files and returns DAP responses that are compatible with DAP2 and the dap-server 3.5 software. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From fedora at leemhuis.info Thu Feb 2 10:13:22 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 02 Feb 2006 11:13:22 +0100 Subject: Wiki-Update (Was: Re: How to update the package?) In-Reply-To: <20060202064600.8060.qmail@web34612.mail.mud.yahoo.com> References: <20060202064600.8060.qmail@web34612.mail.mud.yahoo.com> Message-ID: <1138875202.2802.13.camel@localhost.localdomain> Am Mittwoch, den 01.02.2006, 22:46 -0800 schrieb Ankit Patel: > --- Nicolas Mailhot > wrote: > > > > > Le Jeu 26 janvier 2006 13:44, Ankit Patel a ???crit > : > > > > > So, > > > > > > Here are the Final steps :- > > > 1 ./cvs-import.sh -b -m "import > > Joe's > > > update" ~/bar-2.1-1.src.rpm > > > 2 cd ../ > > > 3 make plague > > > > > > Correct me if i am wrong again ! > > > > That's what works for me. > > You have to use dist carefully to avoid collisions > > though > > > > Finally, i have updated the fedoraproject wiki page. > Here is the link for that:- > http://fedoraproject.org/wiki/Extras/UsingCvsFaq#head-c4a59abbe737f54d05eecdce17583c5547fee73d > > Can somebody please look at it and modify if there is > any mistake? Ankit, I modified this part a bit, added a warning why I think this method is wrong and created a better example for the IMHO correct way to handle updates. Note: I added one thing to your example (besides some minor changes). You should make a fresh checkout with "make srpm", that you install, modify and commit. If you only update your local version and commit that one it might happen that you accidentally delete modifications or updates of your package that someone else did in cvs. That does not happen often, but happened in the past now and then. CU thl -- Thorsten Leemhuis From bugzilla at redhat.com Thu Feb 2 10:08:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 05:08:21 -0500 Subject: [Bug 179708] Review Request: freeform_handler - FreeForm data handler for the OPeNDAP Data server In-Reply-To: Message-ID: <200602021008.k12A8LbL015402@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: freeform_handler - FreeForm data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179708 ------- Additional Comments From pertusus at free.fr 2006-02-02 05:08 EST ------- This bug depends on #179707, but circular dependencies are not allowed. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 2 10:08:45 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 05:08:45 -0500 Subject: [Bug 179709] Review Request: hdf4_handler - HDF4 data handler for the OPeNDAP Data server In-Reply-To: Message-ID: <200602021008.k12A8jYn015559@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: hdf4_handler - HDF4 data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179709 ------- Additional Comments From pertusus at free.fr 2006-02-02 05:08 EST ------- This bug depends on #179707, but circular dependencies are not allowed. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 2 10:08:55 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 05:08:55 -0500 Subject: [Bug 179710] Review Request: netcdf_handler - NetCDF 3 data handler for the OPeNDAP Data server In-Reply-To: Message-ID: <200602021008.k12A8tqE015615@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: netcdf_handler - NetCDF 3 data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179710 ------- Additional Comments From pertusus at free.fr 2006-02-02 05:08 EST ------- This bug depends on #179707, but circular dependencies are not allowed. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From ankit644 at yahoo.com Thu Feb 2 10:42:51 2006 From: ankit644 at yahoo.com (Ankit Patel) Date: Thu, 2 Feb 2006 02:42:51 -0800 (PST) Subject: Wiki-Update (Was: Re: How to update the package?) In-Reply-To: <1138875202.2802.13.camel@localhost.localdomain> Message-ID: <20060202104251.26014.qmail@web34601.mail.mud.yahoo.com> --- Thorsten Leemhuis wrote: > Am Mittwoch, den 01.02.2006, 22:46 -0800 schrieb > Ankit Patel: > > --- Nicolas Mailhot > > wrote: > > > > > > > > Le Jeu 26 janvier 2006 13:44, Ankit Patel a > ???crit > > : > > > > > > > So, > > > > > > > > Here are the Final steps :- > > > > 1 ./cvs-import.sh -b -m "import > > > Joe's > > > > update" ~/bar-2.1-1.src.rpm > > > > 2 cd ../ > > > > 3 make plague > > > > > > > > Correct me if i am wrong again ! > > > > > > That's what works for me. > > > You have to use dist carefully to avoid > collisions > > > though > > > > > > > Finally, i have updated the fedoraproject wiki > page. > > Here is the link for that:- > > > http://fedoraproject.org/wiki/Extras/UsingCvsFaq#head-c4a59abbe737f54d05eecdce17583c5547fee73d > > > > Can somebody please look at it and modify if there > is > > any mistake? > > Ankit, I modified this part a bit, added a warning > why I think this > method is wrong and created a better example for the > IMHO correct way to > handle updates. > > Note: I added one thing to your example (besides > some minor changes). > You should make a fresh checkout with "make srpm", > that you install, > modify and commit. > > If you only update your local version and commit > that one it might > happen that you accidentally delete modifications or > updates of your > package that someone else did in cvs. That does not > happen often, but > happened in the past now and then. > > CU > thl > -- > Thorsten Leemhuis > Thanks Thorsten ! Now, the wiki page looks better then the earlier. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From andreas.bierfert at lowlatency.de Thu Feb 2 11:01:44 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 02 Feb 2006 12:01:44 +0100 Subject: non building packages list In-Reply-To: <20060201.132156.628631317.kevin@scrye.com> References: <20060201.132156.628631317.kevin@scrye.com> Message-ID: <43E1E698.10609@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just as a lillte status update on these... Kevin Fenzi wrote: > andreas.bierfert at lowlatency.de fbdesk Waiting for upstream to fix gcc 4.1 cpp issues > andreas.bierfert at lowlatency.de fluxbox Waiting for upstream to fix gcc 4.1 cpp issues (upstream #1409775) > andreas.bierfert at lowlatency.de wmweather+ Waiting for bug #178310... - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFD4eaYQEQyPsWM8csRArSHAJ4gwi4kYtzJGGSWew+IukKBL0lm/ACdGyNB fyW1Kuf8jbWa/BMmu6u3wRM= =VMlo -----END PGP SIGNATURE----- From bugzilla at redhat.com Thu Feb 2 11:50:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 06:50:07 -0500 Subject: [Bug 178310] Review Request: w3c-libwww - An HTTP library of common code In-Reply-To: Message-ID: <200602021150.k12Bo72g030590@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: w3c-libwww - An HTTP library of common code https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178310 ------- Additional Comments From andreas.bierfert at lowlatency.de 2006-02-02 06:49 EST ------- Ok... fixed the description... www works just fine (from what I can tell...) http://fedora.lowlatency.de/review/w3c-libwww.spec http://fedora.lowlatency.de/review/w3c-libwww-5.4.0-17.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 2 12:08:12 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 07:08:12 -0500 Subject: [Bug 179276] Request for kernel-module-ntfs inclusion in fedora extras In-Reply-To: Message-ID: <200602021208.k12C8C10032757@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Request for kernel-module-ntfs inclusion in fedora extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179276 snecklifter at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|WONTFIX | ------- Additional Comments From snecklifter at gmail.com 2006-02-02 07:07 EST ------- In reply to Comment #1 I was hoping that instead of an outright "no this wont work" people would be willing to re-visit the possibility of the inclusion of ntfs support. Also remember mono was also listed under forbidden items until recently so I do not consider it a be all and end all. I am of course aware of third party repos such as livna and the excellent job they do etc etc. however my hope is that by NOT shipping with core and instead using a kernel module in extras we could compromise a little. Remember, the code is not a wrapper for some ntfs driver, it is GPL'd and written and available due to the damn hard work of some fine developers. If we are to reject inclusion of NTFS support in the kernel then by dint we should also be removing FAT support (see recently upheld patents on this baby) and SAMBA should also give us cause for concern as it was developed using similar methods. Regards Chris -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 2 12:16:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 07:16:35 -0500 Subject: [Bug 179276] Request for kernel-module-ntfs inclusion in fedora extras In-Reply-To: Message-ID: <200602021216.k12CGZGC001468@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Request for kernel-module-ntfs inclusion in fedora extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179276 sundaram at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |CLOSED Resolution| |WONTFIX ------- Additional Comments From sundaram at redhat.com 2006-02-02 07:16 EST ------- (In reply to comment #4) > In reply to Comment #1 I was hoping that instead of an outright "no this wont > work" people would be willing to re-visit the possibility of the inclusion of > ntfs support. > > Also remember mono was also listed under forbidden items until recently so I do > not consider it a be all and end all. I am of course aware of third party repos > such as livna and the excellent job they do etc etc. however my hope is that by > NOT shipping with core and instead using a kernel module in extras we could > compromise a little. > > Remember, the code is not a wrapper for some ntfs driver, it is GPL'd and > written and available due to the damn hard work of some fine developers. If we > are to reject inclusion of NTFS support in the kernel then by dint we should > also be removing FAT support (see recently upheld patents on this baby) and > SAMBA should also give us cause for concern as it was developed using similar > methods. > > Regards > Chris ForbiddenItems mentioned mono as a open issue which has now been resolved. NTFS has already been excluded by the counsel. Apparently FAT, Samba etc are different from the legal standpoint.Refer to http://fedoraproject.org/wiki/ForbiddenItems and http://fedoraproject.org/wiki/FedoraLegalIssues for some of the details. If you wish to discuss this further kindly bring it to the fedora-extras list or contact the legal gateway http://fedora.redhat.com/About/contact.html gdk AT fedoraproject.org -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 2 12:24:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 07:24:50 -0500 Subject: [Bug 179276] Request for kernel-module-ntfs inclusion in fedora extras In-Reply-To: Message-ID: <200602021224.k12COoRl002828@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Request for kernel-module-ntfs inclusion in fedora extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179276 ------- Additional Comments From alexl at users.sourceforge.net 2006-02-02 07:24 EST ------- (In reply to comment #4) > In reply to Comment #1 I was hoping that instead of an outright "no this wont > work" people would be willing to re-visit the possibility of the inclusion of > ntfs support. For what it's worth, I agree, I would prefer to see ntfs in Extras, for convenience. However bugzilla entry is probably not the best place to have a discussion in general (even though this is posted to the fedora-extras-list) unless it specifically about packaging related methods. http://producingoss.com/html-chunk/bug-tracker.html#bug-tracker-mailing-list-interaction I would leave open this bug post your spec file/SRPM, open up a new thread on fedora-extras-list discussing reconsidering ntfs support in Extras and post a link back here to the bug pointing out the Package Review submission. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 2 12:31:06 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 07:31:06 -0500 Subject: [Bug 179276] Request for kernel-module-ntfs inclusion in fedora extras In-Reply-To: Message-ID: <200602021231.k12CV64H003703@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Request for kernel-module-ntfs inclusion in fedora extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179276 ------- Additional Comments From alexl at users.sourceforge.net 2006-02-02 07:30 EST ------- (In reply to comment #5) > ForbiddenItems mentioned mono as a open issue which has now been resolved. NTFS > has already been excluded by the counsel. Apparently FAT, Samba etc are > different from the legal standpoint.Refer to > http://fedoraproject.org/wiki/ForbiddenItems and > http://fedoraproject.org/wiki/FedoraLegalIssues for some of the details. (Running the risk of not following my own advice and avoiding discussion). Nevertheless it would be nice to have a more detail rationale from the Red Hat legal counsel about exactly how NTFS is in and FAT than the note there now: "Microsoft has a number of patents around NTFS. Because of these issues, counsel feels that adding ntfs support runs the risk of significantly endangering the project." Anyway last post from me (will followup on the mailing list). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 2 12:45:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 07:45:20 -0500 Subject: [Bug 179276] Request for kernel-module-ntfs inclusion in fedora extras In-Reply-To: Message-ID: <200602021245.k12CjKbk005892@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Request for kernel-module-ntfs inclusion in fedora extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179276 ------- Additional Comments From fedora at leemhuis.info 2006-02-02 07:45 EST ------- (In reply to comment #4) > [...] > however my hope is that by > NOT shipping with core and instead using a kernel module in extras we could > compromise a little. Well, normally the same rules apply for Fedora Extras and Fedora Core. For that reason a "compromise" like that makes no real sense afaics. Either it is allowed (then it's easier for everyone to enable it in the .config in the kernel from Core) or not (then it is forbidden in both Core and Extras). Rahul said all the other important things in #5 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From buc at odusz.so-cdu.ru Thu Feb 2 12:54:56 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Thu, 02 Feb 2006 15:54:56 +0300 Subject: non building packages list In-Reply-To: <20060201.132156.628631317.kevin@scrye.com> References: <20060201.132156.628631317.kevin@scrye.com> Message-ID: <43E20120.5090409@odu.neva.ru> >dmitry at butskoy.name gnome-translate > > Fixed. (Reason: eel2 library has changed some its function prototypes) ~buc From bugzilla at redhat.com Thu Feb 2 13:57:05 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 08:57:05 -0500 Subject: [Bug 177658] Review Request: mediawiki - The PHP-based wiki software behind Wikipedia In-Reply-To: Message-ID: <200602021357.k12Dv5jL016912@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mediawiki - The PHP-based wiki software behind Wikipedia https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177658 ------- Additional Comments From roozbeh at farsiweb.info 2006-02-02 08:56 EST ------- (In reply to comment #12) > -You could condense your %files section into [...] Makes real sense. Thanks a lot. > -Replace instances of "etc" with %{_sysconfdir} Done. > -Also, including doc's in the main package wouldn't increase the package size > much. Just don't delete doc's, install them [...] OK, but I put them under /usr/share/doc/mediawiki-x.y.z/internals, since they are internal documents. (In reply to comment #12) > replace PreReq with plain old Requires, soon the difference > between Requires and PreReq will be phased out I somehow need to make sure httpd is installed before mediawiki, or RPM won't recognize the user "apache". Any other way to do this? (Not fixing this for the moment.) Will post new version soon. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 2 14:04:26 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 09:04:26 -0500 Subject: [Bug 168831] Review Request: perl-Parse-CPAN-Packages In-Reply-To: Message-ID: <200602021404.k12E4Q3L018118@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Parse-CPAN-Packages https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168831 Bug 168831 depends on bug 168830, which changed state. Bug 168830 Summary: Review Request: perl-CPAN-DistnameInfo https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168830 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NEXTRELEASE Status|ASSIGNED |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 2 14:10:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 09:10:18 -0500 Subject: [Bug 168831] Review Request: perl-Parse-CPAN-Packages In-Reply-To: Message-ID: <200602021410.k12EAImg018996@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Parse-CPAN-Packages https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168831 steve at silug.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From steve at silug.org 2006-02-02 09:10 EST ------- Change made in CVS. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 2 14:10:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 09:10:30 -0500 Subject: [Bug 168838] Review Request: cpanspec In-Reply-To: Message-ID: <200602021410.k12EAU0g019034@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cpanspec https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168838 Bug 168838 depends on bug 168831, which changed state. Bug 168831 Summary: Review Request: perl-Parse-CPAN-Packages https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168831 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NEXTRELEASE Status|ASSIGNED |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 2 14:17:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 09:17:08 -0500 Subject: [Bug 168610] Review Request: perl-Convert-ASCII-Armour In-Reply-To: Message-ID: <200602021417.k12EH8fQ019855@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Convert-ASCII-Armour https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168610 steve at silug.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From steve at silug.org 2006-02-02 09:17 EST ------- Summary changed. Thanks. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From ndbecker2 at gmail.com Thu Feb 2 14:21:46 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 02 Feb 2006 09:21:46 -0500 Subject: numpy-0.9.4 + scipy-0.4.4 Message-ID: I have built/installed numpy-0.9.4 and scipy-0.4.4 on develop/x86_64. It did need a bit of work on the spec file. I know it's not ready for release, but I'd like to post my work so far. Maybe someone would like to pick it up? The patch needs a little work. The issue is, that gfortran has changed the format of it's --version message, which broke the regex matching. I supplied one that will work for gcc4.1.0, but isn't backward compat. Someone should really come up with a compatible regex. Also, I didn't put in buildrequires. It expects fftw, blas, lapack for the build. -------------- next part -------------- A non-text attachment was scrubbed... Name: numpy-gnu95.patch Type: text/x-diff Size: 1422 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: numpy.spec URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: scipy.spec URL: From pertusus at free.fr Thu Feb 2 14:34:39 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 2 Feb 2006 15:34:39 +0100 Subject: taking perl-Parse-Yapp In-Reply-To: <1138834717.12245.34.camel@bobcat.mine.nu> References: <20060201173557.GD2688@free.fr> <1138834717.12245.34.camel@bobcat.mine.nu> Message-ID: <20060202143439.GB2668@free.fr> > Great, thanks. Would you mind taking over the dependent perl-XML-XQL > too? ...and perl-XML-DOM, perl-XML-RegExp and perl-XML-XPath. These > packages are pretty intertwined and would benefit from being maintained > by someone who actually uses them (unlike yours truly). Just go ahead > and grab them if you're interested. Unfortunately, I don't use them, nor do I follow theur development, so I prefer not to take them. -- Pat From rdieter at math.unl.edu Thu Feb 2 14:36:10 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 02 Feb 2006 08:36:10 -0600 Subject: ScriptletSnippets: desktop-database,mimeinfo Message-ID: Per http://fedoraproject.org/wiki/ScriptletSnippets in the desktop-database and mimeinfo sections says to add Requires(post): desktop-file-utils Requires(postun): desktop-file-utils and Requires(post): shared-mime-info Requires(postun): shared-mime-info respectively, but the "GTK+ icon cache" section says (rightfully) "Note that no dependencies should be added for this". Couldn't the same argument for this latter statement be applied to both desktop-database and mimeinfo as well? Shouldn't desktop-file-utils and shared-mime-info be Req'd (only) by the desktop environments that use/require them (AFAIK, only gnome at the moment). -- Rex From bugzilla at redhat.com Thu Feb 2 14:50:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 09:50:49 -0500 Subject: [Bug 168580] Review Request: perl-Crypt-DES In-Reply-To: Message-ID: <200602021450.k12EonjH026837@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Crypt-DES https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168580 ------- Additional Comments From steve at silug.org 2006-02-02 09:50 EST ------- http://ftp.kspei.com/pub/steve/rpms/perl-Crypt-DES-2.05-1.src.rpm * Thu Feb 02 2006 Steven Pritchard 2.05-1 - Update to 2.05. - Drop explicit Requires: perl(Crypt::CBC). - LD_RUN_PATH hack shouldn't be needed now. - Trim file list a bit. - License is BSD, more or less. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 2 15:23:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 10:23:21 -0500 Subject: [Bug 176528] Review Request: MochiKit: A lightweight JavaScript library In-Reply-To: Message-ID: <200602021523.k12FNL6v001508@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: MochiKit: A lightweight JavaScript library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176528 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tibbs at math.uh.edu ------- Additional Comments From tibbs at math.uh.edu 2006-02-02 10:23 EST ------- FYI, 1.2 is out. rpmlint says: W: MochiKit invalid-license MIT/Academic The code is indeed under both MIT and the Academic Free license ( http://www.opensource.org/licenses/afl-2.1.php ) and so meets the packaging guidelines but I don't know how to satisfy rpmlint. Are there selinux isues with pointing the web server into /usr/share? Perhaps /var/www would be a better location? (It kind of gives me indigestion to put such things under /var, but there is precedent in httpd-manual.) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 2 15:33:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 10:33:33 -0500 Subject: [Bug 176528] Review Request: MochiKit: A lightweight JavaScript library In-Reply-To: Message-ID: <200602021533.k12FXX94003860@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: MochiKit: A lightweight JavaScript library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176528 ------- Additional Comments From ivazquez at ivazquez.net 2006-02-02 10:33 EST ------- (In reply to comment #1) > Are there selinux isues with pointing the web server into /usr/share? Perhaps > /var/www would be a better location? (It kind of gives me indigestion to put > such things under /var, but there is precedent in httpd-manual.) Something I discovered (which gives *me* indigestion...) is that httpd has full read access to usr_t. Yes, that's right, Apache can read almost anything under /usr. I will update the package to 1.2 when I get a chance. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 2 16:08:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 11:08:36 -0500 Subject: [Bug 168580] Review Request: perl-Crypt-DES In-Reply-To: Message-ID: <200602021608.k12G8ahh012762@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Crypt-DES https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168580 paul at city-fan.org changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From paul at city-fan.org 2006-02-02 11:08 EST ------- OK: - still rpmlint clean - package builds OK in mock for FC5 (i386) - all queries raised in Comment #2 now addressed Approved. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 2 16:08:37 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 11:08:37 -0500 Subject: [Bug 177658] Review Request: mediawiki - The PHP-based wiki software behind Wikipedia In-Reply-To: Message-ID: <200602021608.k12G8b6O012769@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mediawiki - The PHP-based wiki software behind Wikipedia https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177658 ------- Additional Comments From roozbeh at farsiweb.info 2006-02-02 11:08 EST ------- New version: Spec Url: http://guava.farsiweb.info/~roozbeh/mediawiki.spec SRPM Url: http://guava.farsiweb.info/~roozbeh/mediawiki-1.5.6-3.src.rpm %changelog - Refactor the %%files section (Mike McGrath) - Replace "/etc" with macro - Package docs under %%{_defaultdocdir}/internals - Minor change in description -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rdieter at math.unl.edu Thu Feb 2 16:14:47 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 02 Feb 2006 10:14:47 -0600 Subject: rpms/koffice/devel koffice.spec,1.22,1.23 In-Reply-To: <200602021458.k12Ew9UV026217@cvs-int.fedora.redhat.com> References: <200602021458.k12Ew9UV026217@cvs-int.fedora.redhat.com> Message-ID: Andreas Bierfert (awjb) wrote: > Index: koffice.spec > =================================================================== > RCS file: /cvs/extras/rpms/koffice/devel/koffice.spec,v > retrieving revision 1.22 > retrieving revision 1.23 > diff -u -r1.22 -r1.23 > --- koffice.spec 2 Feb 2006 12:47:27 -0000 1.22 > +++ koffice.spec 2 Feb 2006 14:57:36 -0000 1.23 > @@ -53,7 +53,13 @@ ... > +BuildRequires: mesa-libGL-devel mesa-libGLU-devel ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this probably should be: BR: libGL-devel libGLU-devel -- Rex From andreas.bierfert at lowlatency.de Thu Feb 2 16:20:43 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 02 Feb 2006 17:20:43 +0100 Subject: rpms/koffice/devel koffice.spec,1.22,1.23 In-Reply-To: References: <200602021458.k12Ew9UV026217@cvs-int.fedora.redhat.com> Message-ID: <43E2315B.6000303@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes... probably should ^^ Thanks for telling. - - Andreas Rex Dieter wrote: > Andreas Bierfert (awjb) wrote: > >> Index: koffice.spec >> =================================================================== >> RCS file: /cvs/extras/rpms/koffice/devel/koffice.spec,v >> retrieving revision 1.22 >> retrieving revision 1.23 >> diff -u -r1.22 -r1.23 >> --- koffice.spec 2 Feb 2006 12:47:27 -0000 1.22 >> +++ koffice.spec 2 Feb 2006 14:57:36 -0000 1.23 >> @@ -53,7 +53,13 @@ > > ... > >> +BuildRequires: mesa-libGL-devel mesa-libGLU-devel > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > this probably should be: > BR: libGL-devel libGLU-devel > > > -- Rex > - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFD4jFbQEQyPsWM8csRAsvdAKCyLM4rxo9fAIwI3FJyz1agxtaTOQCggGxk nrtwoYQVb07duBf/P3HhXqs= =z8kh -----END PGP SIGNATURE----- From liljencrantz at gmail.com Thu Feb 2 16:20:48 2006 From: liljencrantz at gmail.com (Axel Liljencrantz) Date: Thu, 2 Feb 2006 17:20:48 +0100 Subject: non building packages list In-Reply-To: <1138832869.8430.1.camel@orodruin.boston.redhat.com> References: <20060201.132156.628631317.kevin@scrye.com> <1138825962.3359.5.camel@localhost> <20060201.151415.668598140.kevin@scrye.com> <1138832869.8430.1.camel@orodruin.boston.redhat.com> Message-ID: <7dad0d770602020820u2c7f0fdfj@mail.gmail.com> 2006/2/1, Jeremy Katz : > On Wed, 2006-02-01 at 15:14 -0700, Kevin Fenzi wrote: > > The build.log has: > > > > checking for localtime_r... yes > > configure: error: X development libraries not found > > error: Bad exit status from /var/tmp/rpm-tmp.41009 (%build) > > > > You might look at the configure script and see what tests it's doing > > there. What headers it's looking for? what libs it's looking for? > > In many cases, this is due to buildrequires not being fully updated for > the change to modular X This is what is causing the problems for the fish package. What are the names of the packages replacing xorg-x11-devel? > > Jeremy > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- Axel From ivazquez at ivazquez.net Thu Feb 2 16:27:11 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 02 Feb 2006 11:27:11 -0500 Subject: numpy-0.9.4 + scipy-0.4.4 In-Reply-To: References: Message-ID: <1138897631.23767.17.camel@ignacio.lan> On Thu, 2006-02-02 at 09:21 -0500, Neal Becker wrote: > The patch needs a little work. The issue is, that gfortran has changed the > format of it's --version message, which broke the regex matching. I > supplied one that will work for gcc4.1.0, but isn't backward compat. > Someone should really come up with a compatible regex. You were close. r'GNU Fortran 95 \(GCC\)?\s*(?P[0-9.]+)' -- 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 bugzilla at redhat.com Thu Feb 2 16:32:31 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 11:32:31 -0500 Subject: [Bug 178263] Review Request: ncarg - A Fortran and C based software package for scientific visualization In-Reply-To: Message-ID: <200602021632.k12GWVgJ018147@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ncarg - A Fortran and C based software package for scientific visualization https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178263 ------- Additional Comments From orion at cora.nwra.com 2006-02-02 11:32 EST ------- Thanks for the reviews: - I prefer to list binaries explicitly - it has alerted me to problems before. - Moved tutorial to -devel - Moved .a to %{_libdir}/ncarg/ (and other stuff to %{_libdir}/ncarg/ncarg/ - Added devel Requires. - Moveg ncargex to -devel - aed.a is a text graphcad file, not a library. http://www.cora.nwra.com/~orion/fedora/ncarg-4.4.1-2.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rc040203 at freenet.de Thu Feb 2 16:39:19 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 02 Feb 2006 17:39:19 +0100 Subject: rpms/ginac/devel ginac.spec,1.2,1.3 In-Reply-To: <200602021634.k12GYSpJ030644@cvs-int.fedora.redhat.com> References: <200602021634.k12GYSpJ030644@cvs-int.fedora.redhat.com> Message-ID: <1138898359.31136.167.camel@mccallum.corsepiu.local> On Thu, 2006-02-02 at 11:33 -0500, Quentin Spencer wrote: > Author: qspencer > > Update of /cvs/extras/rpms/ginac/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv30627 > > Modified Files: > ginac.spec > Log Message: > Update URL and fix unpackaged files. > > > Index: ginac.spec > =================================================================== > RCS file: /cvs/extras/rpms/ginac/devel/ginac.spec,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -u -r1.2 -r1.3 > --- ginac.spec 31 Oct 2005 23:23:57 -0000 1.2 > +++ ginac.spec 2 Feb 2006 16:33:55 -0000 1.3 > @@ -6,7 +6,7 @@ > Group: System Environment/Libraries > License: GPL > URL: http://www.ginac.de/ > -Source0: ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC/%{name}-%{version}.tar.bz2 > +Source0: http://www.ginac.de/%{name}-%{version}.tar.bz2 > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > > Requires(post): /sbin/install-info > @@ -86,24 +86,29 @@ > > %files devel > %defattr(-,root,root) > +%doc %{_infodir}/*.info* > +%doc %{_mandir}/man?/ginac-config.1* These %doc are redundant, please remove them. > %{_libdir}/*.a Why are you shipping static libs? Ralf From qspencer at ieee.org Thu Feb 2 16:46:33 2006 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 02 Feb 2006 10:46:33 -0600 Subject: rpms/ginac/devel ginac.spec,1.2,1.3 In-Reply-To: <1138898359.31136.167.camel@mccallum.corsepiu.local> References: <200602021634.k12GYSpJ030644@cvs-int.fedora.redhat.com> <1138898359.31136.167.camel@mccallum.corsepiu.local> Message-ID: <43E23769.7040604@ieee.org> Ralf Corsepius wrote: >On Thu, 2006-02-02 at 11:33 -0500, Quentin Spencer wrote: > > >>Author: qspencer >> >>Update of /cvs/extras/rpms/ginac/devel >>In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv30627 >> >>Modified Files: >> ginac.spec >>Log Message: >>Update URL and fix unpackaged files. >> >> >>Index: ginac.spec >>=================================================================== >>RCS file: /cvs/extras/rpms/ginac/devel/ginac.spec,v >>retrieving revision 1.2 >>retrieving revision 1.3 >>diff -u -r1.2 -r1.3 >>--- ginac.spec 31 Oct 2005 23:23:57 -0000 1.2 >>+++ ginac.spec 2 Feb 2006 16:33:55 -0000 1.3 >>@@ -6,7 +6,7 @@ >> Group: System Environment/Libraries >> License: GPL >> URL: http://www.ginac.de/ >>-Source0: ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC/%{name}-%{version}.tar.bz2 >>+Source0: http://www.ginac.de/%{name}-%{version}.tar.bz2 >> BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) >> >> Requires(post): /sbin/install-info >>@@ -86,24 +86,29 @@ >> >> %files devel >> %defattr(-,root,root) >>+%doc %{_infodir}/*.info* >>+%doc %{_mandir}/man?/ginac-config.1* >> >> >These %doc are redundant, please remove them. > > > Redundant how? >> %{_libdir}/*.a >> >> >Why are you shipping static libs? > > I don't know. I modeled my first spec files that included libraries after others that were already in Extras, and have just done things that way all along (including a few other packages I maintain), but this was all before people started preaching the evils of static libs. I guess I can remove them. -Quentin From Christian.Iseli at licr.org Thu Feb 2 16:55:19 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 02 Feb 2006 17:55:19 +0100 Subject: FE package status Thu Feb 2 2006 Message-ID: <200602021655.k12GtJYb003950@ludwig-alpha.unil.ch> Hi folks, I added some more checks to the script, and am sorta happy with the current output. I'll put the latest version on the wiki (Extras/UsefulScripts) shortly. I started a list of "retired" packages that I'll upload along the script. My plan is to post the output of this script to the list about once a week or so (time permitting... :-) )... One thing I haven't implemented is a kind of statistic thing, where we would have a weekly count of submitted/reviewed packages... I tried to get a list of tickets which have had no activity in a long (4 and 8 weeks) time, but seem to have hit a snag: one of the columns of a bugzilla report is named "Changed Date" but I can't figure out exactly when that value gets updated. I still use it, but sometimes the mentioned tickets will have received comments after the "Changed Date" date. Comments welcome... Cheers, Christian --- === About owners file === We have 1403 extras packages in owners file. There are 64 orphans. Top 10 package owners: tcallawa at redhat dot com : 88 ville dot skytta at iki dot fi : 82 jpo at di dot uminho dot pt : 80 matthias at rpmforge dot net : 70 andreas dot bierfert at lowlatency dot de : 54 rc040203 at freenet dot de : 50 ivazquez at ivazquez dot net : 41 rdieter at math dot unl dot edu : 41 gauret at free dot fr : 40 steve at silug dot org : 35 We have 57 orphaned packages available in extras devel: abe anjuta apg apt arc at-poke bochs camstream cgoban cksfv conglomerate duplicity freedroidrpg galculator gdeskcal gkrellm-themes gnofract4d gnome-password-generator gnome-telnet gnome-themes-extras gnugo gonvert gpa gtkglarea2 gurlchecker hping2 libzvt lincvs lua manedit meld mknbi netdiag nget ots p0f parchive perl-Net-SCP perl-Net-SSH perl-Parse-Yapp prozilla putty rpmproc scorched3d screem sirius synaptic tdl tetex-arabtex tetex-armtex tetex-font-tipa tetex-lgrind tla wbxml2 wesnoth xmms-cdread xtide We have 80 packages not available in extras devel: GiNaC R-RScaLAPACK R-hdf5 alsa-firmware amavisd-new apmud aqhbci-qt-tools cdiff cdo compat-wxPythonGTK2 comps configure-thinkpad cryptplug dd_rescue drscheme ebtables fillets-ng-data-cs fonttools freenx gcdmaster gcl gnome-applet-netmon gnome-cpufreq-applet gnome-theme-clearlooks gpredict iiimf-le-simplehangul initng inti juk k3b-ape kiosktool kxdocker kxdocker-resources libgcrypt1 libgsf113 libmatchbox libsafe lirc-kmod lirc-kmod-common lout nabi newpg nx openbox opendap openoffice-extras osiv pam_pkcs11 perl-CPAN-DistnameInfo perl-Convert-ASCII-Armour perl-Convert-PEM perl-Crypt-DES_EDE3 perl-GD-SVG perl-Graph perl-Heap perl-Parse-CPAN-Packages perl-SOAP-Lite perl-SVG perl-Text-Levenshtein perl-Text-Shellwords perl-XML-Writer perl-bioperl php-pear-DB php-pecl-sqlite qemu rsnapshot sblim-cmpi-base scrub squidGuard stripesnoop superkaramba swish-e thinkpad-kmod thinkpad-kmod-common tpctl wmweather+ wp_tray wxPython xaliclock yakuake We have 28 packages that moved to core: anthy firefox gmime kasumi libchewing libevent m17n-db m17n-lib nautilus-sendto perl-Archive-Zip perl-IO-String perl-IO-Zlib perl-Net-IP perl-String-CRC32 perl-XML-Simple python-elementtree python-sqlite scim scim-anthy scim-chewing scim-hangul scim-m17n scim-pinyin scim-qtimm scim-tables sqlite thunderbird tog-pegasus === About FE-ACCEPT packages === We have 9 accepted, closed packages where I'm unable to find the package in the development repo: https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165488,168185,171601,172136,172144,172150,172151,173216,174266 We have 5 accepted, closed packages where I'm unable to find the package in the owners file: https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165992,167863,168185,168920,171801 We have 470 accepted, closed package reviews Top 10 BZ review requests submitters: tcallawa at redhat dot com : 43 rc040203 at freenet dot de : 41 andreas dot bierfert at lowlatency dot de : 29 fedora dot wickert at arcor dot de : 28 jpo at di dot uminho dot pt : 24 rdieter at math dot unl dot edu : 18 steve at silug dot org : 14 pertusus at free dot fr : 14 orion at cora dot nwra dot com : 13 paul at city-fan dot org : 12 Top 10 BZ review requests reviewers: paul at city-fan dot org : 65 gauret at free dot fr : 64 gdk at redhat dot com : 34 jpmahowald at gmail dot com : 28 tcallawa at redhat dot com : 26 rc040203 at freenet dot de : 22 jpo at di dot uminho dot pt : 20 ed at eh3 dot com : 19 adrian at lisas dot de : 18 ville dot skytta at iki dot fi : 13 We have 11 accepted, open package reviews where the package appears to already be in the repo... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=166207,166251,166252,166253,166254,168905,176618,177038,177083,177166,179263 We have 15 accepted, open package reviews older than 4 weeks https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165688,165899,165932,166207,166251,166252,166253,166254,166255,168583,168607,168905,170309,172871,175201 === About FE-NEW packages === We have 124 open tickets in FE-NEW We have 6 closed tickets still blocking FE-NEW https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=167621,168906,176434,177859,178141,178902 We have 11 FE-NEW tickets with no activity in eight weeks https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=166427,169703,169717,172803,173790,174021,174368,174440,174588,174952,175281 We have 19 FE-NEW tickets with no activity in four weeks https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165666,171314,172755,172872,174325,174866,175473,175623,176021,176137,176523,176526,176528,176579,176581,176582,176697,176712,176855 === About FE-REVIEW packages === We have 56 open tickets in FE-REVIEW We have 2 closed tickets still blocking FE-REVIEW https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=172267,177567 We have 8 FE-REVIEW tickets with no activity in eight weeks https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165689,166205,166470,166919,167525,167974,169210,174063 We have 11 FE-REVIEW tickets with no activity in four weeks https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165230,165985,166547,169704,169731,173028,173388,174495,174783,175168,175278 From rc040203 at freenet.de Thu Feb 2 16:55:55 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 02 Feb 2006 17:55:55 +0100 Subject: rpms/ginac/devel ginac.spec,1.2,1.3 In-Reply-To: <43E23769.7040604@ieee.org> References: <200602021634.k12GYSpJ030644@cvs-int.fedora.redhat.com> <1138898359.31136.167.camel@mccallum.corsepiu.local> <43E23769.7040604@ieee.org> Message-ID: <1138899355.31136.174.camel@mccallum.corsepiu.local> On Thu, 2006-02-02 at 10:46 -0600, Quentin Spencer wrote: > Ralf Corsepius wrote: > > >On Thu, 2006-02-02 at 11:33 -0500, Quentin Spencer wrote: > >> %files devel > >> %defattr(-,root,root) > >>+%doc %{_infodir}/*.info* > >>+%doc %{_mandir}/man?/ginac-config.1* > >> > >> > >These %doc are redundant, please remove them. > Redundant how? The "%doc"'s there are superfluous. These files are automatically tagged %doc. Ralf From bugzilla at redhat.com Thu Feb 2 16:53:54 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 11:53:54 -0500 Subject: [Bug 178951] Review Request: modules - Provides dynamic modification of a user's environment In-Reply-To: Message-ID: <200602021653.k12GrsYC022352@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: modules - Provides dynamic modification of a user's environment https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178951 ------- Additional Comments From orion at cora.nwra.com 2006-02-02 11:53 EST ------- (In reply to comment #2) > Hi Orion, I really don't know what to say in regards to the default > initialization of modules. Some may view it as helpful while others > may think its an annoyance. Since you're packaging it, I think you > should get some leeway in deciding whats appropriate. I'm going with initialization by default. Seems to go with the extras idea - if you install the software you want to use it. > nits: > - Why the "--disable-versioning" flag? IMHO, its a pretty > cool and useful feature. configuring for Modules 3.2.0 2006-01-17 configure: error: You can not have versioning if --exec-prefix is specified must disable with --disable-versioning What is versioning useful for with modules? Note that this is not the standard --enable-versioning configure option stuff (I think). > - Please consider naming the package "environment-modules" > instead of just "modules" since it is the upstream project > name (the "Environment Modules Project") and its a lot less > ambiguous. The name "modules" gets used for all sorts of > stuff including kernel modules and perhaps a more descriptive > name can help avoid some confusion for new users? Its just > a suggestion, though. But "modules" seems to be the accepted shorthand and that is what the tar file is called. > - Please consider either adding the paper: > > http://modules.sourceforge.net/docs/MC2_whitney_paper.pdf > > to the documentation or adding a brief REAME-style link to > the homepage and the paper since its very helpful and well- > written document. Exactly the sort of thing new users should > read! > I'd rather keep the package size down. It's on the project home page. http://www.cora.nwra.com/~orion/fedora/modules-3.2.0-2.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rdieter at math.unl.edu Thu Feb 2 16:57:41 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 02 Feb 2006 10:57:41 -0600 Subject: rpms/ginac/devel ginac.spec,1.2,1.3 In-Reply-To: <43E23769.7040604@ieee.org> References: <200602021634.k12GYSpJ030644@cvs-int.fedora.redhat.com> <1138898359.31136.167.camel@mccallum.corsepiu.local> <43E23769.7040604@ieee.org> Message-ID: Quentin Spencer wrote: > Ralf Corsepius wrote: >>> Modified Files: >>> ginac.spec Log Message: >>> %files devel >>> %defattr(-,root,root) >>> +%doc %{_infodir}/*.info* >>> +%doc %{_mandir}/man?/ginac-config.1* >> These %doc are redundant, please remove them. > Redundant how? %files under %_infodir and %_mandir are automatically marked %doc. -- Rex From paul at city-fan.org Thu Feb 2 17:03:56 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 02 Feb 2006 17:03:56 +0000 Subject: FE package status Thu Feb 2 2006 In-Reply-To: <200602021655.k12GtJYb003950@ludwig-alpha.unil.ch> References: <200602021655.k12GtJYb003950@ludwig-alpha.unil.ch> Message-ID: <43E23B7C.1070109@city-fan.org> Christian.Iseli at licr.org wrote: > Hi folks, > > I added some more checks to the script, and am sorta happy with the current > output. I'll put the latest version on the wiki (Extras/UsefulScripts) > shortly. > > I started a list of "retired" packages that I'll upload along the script. > > My plan is to post the output of this script to the list about once a week or > so (time permitting... :-) )... Could the bug lists include the names of the packages (or the bug title) as well as providing the link to bugzilla? I find it much easier to remember package names than bugzilla ticket numbers. As it stands, I need to visit each of the bugzilla links provided in the email to see if any of the bugs are "mine". Paul. From dragoran at feuerpokemon.de Thu Feb 2 17:07:24 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 02 Feb 2006 18:07:24 +0100 Subject: extras package that require changes in selinux-policy (initng) In-Reply-To: <43DF869C.1090700@feuerpokemon.de> References: <43DE4707.9010900@feuerpokemon.de> <43DE6A09.2040602@redhat.com> <43DF869C.1090700@feuerpokemon.de> Message-ID: <43E23C4C.4070203@feuerpokemon.de> dragoran schrieb: > Daniel J Walsh wrote: > >> dragoran wrote: >> >>> Hello. >>> I am working on selinux support in initng, which is in review for >>> extras now [1]. >>> But it seems that initng requires a policy to work (just tested in >>> targeted mode) >>> Using the default context (sbin_t) lets all apps that are started >>> from initng run as kernel_t. >> >> >> What is the path? We can set it up in policy. > > >>> Relabling /sbin/initng to init_exec_t (same as init) fixes this and >>> the processes run as init_t and udev_t for udev, but some issues >>> still remain. >> >> >> I will add to policy. > > > ok thx > >>> hald,httpd, etc. also run as init_t which is *wrong* they have to >>> get into their own domain. How is this handled in sysvinit? >>> After reading the code I havn't found anything about it. >> >> >> Are the startup scripts marked initrc_exec_t? >> >> > yes I did chcon -t initrc_exec_t on all files in /etc/initng/system > and /etc/initng/daemons > checked this and found out that initng does not execute any scripts. the "scripts" are just files that contain infos about which daemon should be started and which deps it has. this results in hald beeing started directly from initng using execv(). This results in hald (and other services) run as init_t. If I put /sbin/service hald start into the exec line hald runs as hald_t. Why is a script required to get into the correct domain? Is there any way to fix this without adding setexeccon() for every daemon? From Christian.Iseli at licr.org Thu Feb 2 17:09:45 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 02 Feb 2006 18:09:45 +0100 Subject: FE package status Thu Feb 2 2006 In-Reply-To: Your message of "Thu, 02 Feb 2006 17:03:56 GMT." <43E23B7C.1070109@city-fan.org> Message-ID: <200602021709.k12H9jX1004185@ludwig-alpha.unil.ch> paul at city-fan.org said: > Could the bug lists include the names of the packages (or the bug title) as > well as providing the link to bugzilla? Ok, will do. Thanks, Christian From bugzilla at redhat.com Thu Feb 2 17:06:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 12:06:33 -0500 Subject: [Bug 177096] Review Request: fonttools: A tool to convert True/OpenType fonts to XML and back In-Reply-To: Message-ID: <200602021706.k12H6XPb024653@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: fonttools: A tool to convert True/OpenType fonts to XML and back https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177096 roozbeh at farsiweb.info changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From roozbeh at farsiweb.info 2006-02-02 12:06 EST ------- Thanks a lot for the review. Imported and built. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From jamatos at fc.up.pt Thu Feb 2 17:10:29 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Thu, 2 Feb 2006 17:10:29 +0000 Subject: FE package status Thu Feb 2 2006 In-Reply-To: <43E23B7C.1070109@city-fan.org> References: <200602021655.k12GtJYb003950@ludwig-alpha.unil.ch> <43E23B7C.1070109@city-fan.org> Message-ID: <200602021710.29270.jamatos@fc.up.pt> On Thursday 02 February 2006 17:03, Paul Howarth wrote: > > Could the bug lists include the names of the packages (or the bug title) > as well as providing the link to bugzilla? I find it much easier to > remember package names than bugzilla ticket numbers. As it stands, I > need to visit each of the bugzilla links provided in the email to see if > any of the bugs are "mine". +1 Even if that implies that you have some kind of table of contents in the begin as the report is becoming long... Thanks. > Paul. -- Jos? Ab?lio From jamatos at fc.up.pt Thu Feb 2 17:16:00 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Thu, 2 Feb 2006 17:16:00 +0000 Subject: numpy-0.9.4 + scipy-0.4.4 In-Reply-To: References: Message-ID: <200602021716.00872.jamatos@fc.up.pt> On Thursday 02 February 2006 14:21, Neal Becker wrote: > I have built/installed numpy-0.9.4 and scipy-0.4.4 on develop/x86_64. ?It > did need a bit of work on the spec file. ?I know it's not ready for > release, but I'd like to post my work so far. ?Maybe someone would like to > pick it up? I am interested. As soon as this is declared stable matplotlib can be linked with it as the last version 0.86.2 already supports it. :-) Even it is not stable we could import it placing a note in description regarding its state... -- Jos? Ab?lio From Christian.Iseli at licr.org Thu Feb 2 17:20:02 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 02 Feb 2006 18:20:02 +0100 Subject: FE package status Thu Feb 2 2006 In-Reply-To: Your message of "Thu, 02 Feb 2006 17:10:29 GMT." <200602021710.29270.jamatos@fc.up.pt> Message-ID: <200602021720.k12HK2FX004395@ludwig-alpha.unil.ch> jamatos at fc.up.pt said: > Even if that implies that you have some kind of table of contents in the > begin as the report is becoming long... I rather like the idea of a table of content, but I'm really unsure what it would/should look like in such a plain text file. Or maybe I should prepare a wiki page version ? Thanks for the feedback :) Christian From j.w.r.degoede at hhs.nl Thu Feb 2 17:32:55 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 02 Feb 2006 18:32:55 +0100 Subject: Taking ownership of 2 orphaned packages Message-ID: <43E24247.3090501@hhs.nl> HI, I would like to take ownership of bochs and scorched3d, any objections? Regards, Hans From toshio at tiki-lounge.com Thu Feb 2 17:30:36 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 02 Feb 2006 09:30:36 -0800 Subject: non building packages list In-Reply-To: <20060201.194730.944183415.kevin@scrye.com> References: <20060201.132156.628631317.kevin@scrye.com> <1138825962.3359.5.camel@localhost> <20060201.151415.668598140.kevin@scrye.com> <1138832869.8430.1.camel@orodruin.boston.redhat.com> <1138835976.3359.16.camel@localhost> <1138836913.5164.7.camel@bree.local.net> <20060201.194730.944183415.kevin@scrye.com> Message-ID: <1138901436.3411.4.camel@localhost> On Wed, 2006-02-01 at 19:47 -0700, Kevin Fenzi wrote: > I have a config.log from a mock build for you. > > http://www.scrye.com/~kevin/config.log > > Hopefully that will help. > > If you would like access to a devel box, I can set you up with access > to my test machine. Just drop me an email off list if you would be > interested. Thanks Kevin, that would help a lot. If the username "badger" or "toshio" is available, I'll take it :-). -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 toshio at tiki-lounge.com Thu Feb 2 17:35:29 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 02 Feb 2006 09:35:29 -0800 Subject: non building packages list In-Reply-To: <1138849173.31136.21.camel@mccallum.corsepiu.local> References: <20060201.132156.628631317.kevin@scrye.com> <1138825962.3359.5.camel@localhost> <20060201.151415.668598140.kevin@scrye.com> <1138832869.8430.1.camel@orodruin.boston.redhat.com> <1138835976.3359.16.camel@localhost> <1138836913.5164.7.camel@bree.local.net> <20060201.194730.944183415.kevin@scrye.com> <1138849173.31136.21.camel@mccallum.corsepiu.local> Message-ID: <1138901729.3411.10.camel@localhost> On Thu, 2006-02-02 at 03:59 +0100, Ralf Corsepius wrote: > On Wed, 2006-02-01 at 19:47 -0700, Kevin Fenzi wrote: > > http://www.scrye.com/~kevin/config.log > > Probably a broken configure script: > > The X11 check this configure script uses, checks for libXt (cf. > X11/Intrinsic.h) instead of libX. > > BR: libXt-devel > inside of the spec should be applicalbe to work around this issue. > > The actual fix would be to fix the configure script to not look for Xt > header (X11/Intrinsic.h) but for an X-header. > Thanks Ralf, Kevin, and Jeremy! I'm looking into whether the configure script needs to be using AC_PATH_XTRA or if AC_PATH_X is fine. -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 Thu Feb 2 17:44:32 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 02 Feb 2006 12:44:32 -0500 Subject: numpy-0.9.4 + scipy-0.4.4 In-Reply-To: <200602021716.00872.jamatos@fc.up.pt> References: <200602021716.00872.jamatos@fc.up.pt> Message-ID: <1138902272.23767.22.camel@ignacio.lan> On Thu, 2006-02-02 at 17:16 +0000, Jose' Matos wrote: > On Thursday 02 February 2006 14:21, Neal Becker wrote: > > I have built/installed numpy-0.9.4 and scipy-0.4.4 on develop/x86_64. It > > did need a bit of work on the spec file. I know it's not ready for > > release, but I'd like to post my work so far. Maybe someone would like to > > pick it up? > > I am interested. As soon as this is declared stable matplotlib can be linked > with it as the last version 0.86.2 already supports it. :-) I've actually been working on them. I have numpy in review (#178668) and am building a new SRPM as we speak, but haven't had a chance to finish up the scipy 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 bugzilla at redhat.com Thu Feb 2 17:40:55 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 12:40:55 -0500 Subject: [Bug 177275] Review Request: perl-AnyData: Easy access to data in many formats In-Reply-To: Message-ID: <200602021740.k12Het2M030486@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-AnyData: Easy access to data in many formats https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177275 paul at city-fan.org changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |177276 nThis| | ------- Additional Comments From paul at city-fan.org 2006-02-02 12:40 EST ------- (In reply to comment #1) > Review for release 1: > * RPM name is OK > * Source AnyData-0.10.tar.gz is the same as upstream > * Builds fine in mock > * rpmlint of perl-AnyData looks OK > * File list of perl-AnyData looks OK > > Needs work: > * BuildRequires: perl should not be included > (wiki: PackagingGuidelines#Exceptions) > * Missing SMP flags. If it doesn't build with it, please add a comment > (wiki: PackagingGuidelines#parallelmake) Agreed. > * The package should contain the text of the license > (wiki: PackageReviewGuidelines) This only applies of the upstream tarball includes the license text, which this one doesn't. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From dragoran at feuerpokemon.de Thu Feb 2 17:48:36 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 02 Feb 2006 18:48:36 +0100 Subject: extras package that require changes in selinux-policy (initng) In-Reply-To: <1138902557.18268.212.camel@moss-spartans.epoch.ncsc.mil> References: <43DE4707.9010900@feuerpokemon.de> <43DE6A09.2040602@redhat.com> <43DF869C.1090700@feuerpokemon.de> <43E23C4C.4070203@feuerpokemon.de> <1138902557.18268.212.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <43E245F4.30309@feuerpokemon.de> Stephen Smalley wrote: >On Thu, 2006-02-02 at 18:07 +0100, dragoran wrote: > > >>checked this and found out that initng does not execute any scripts. >>the "scripts" are just files that contain infos about which daemon >>should be started and which deps it has. >>this results in hald beeing started directly from initng using execv(). >>This results in hald (and other services) run as init_t. If I put >>/sbin/service hald start into the exec line hald runs as hald_t. >>Why is a script required to get into the correct domain? Is there any >>way to fix this without adding setexeccon() for every daemon? >> >> > >The current policy only defines domain transitions from init (init_t) to >rc (initrc_t) -> daemons. It doesn't define direct domain transitions >from init_t to the daemon domains, except for a few cases where that has >been necessary (getty, gdm). The policy could certainly also include >additional transitions directly from init_t to the daemon domains, and >that would work, but it will bloat the policy a bit to include both sets >of transitions. The script isn't required; it just happens to be the >current init approach, so that is what policy was written for. Adding >setexeccon() to every daemon wouldn't be desirable or helpful. > > > so what is the solution? use setexecon() to run the daemons as initrc_t to let the domain transitions take effect? this should also be init_t -> initrc_t -> daemon .. or did I miss / missunderstood something? From bugzilla at redhat.com Thu Feb 2 17:54:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 12:54:56 -0500 Subject: [Bug 179758] New: Review Request: Eiciel (ACL editor) Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179758 Summary: Review Request: Eiciel (ACL editor) Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: fedora at adslpipe.co.uk QAContact: fedora-extras-list at redhat.com Spec Url: http://adslpipe.co.uk/fedora/extras/eiciel/eiciel.spec SRPM Url: http://adslpipe.co.uk/fedora/extras/eiciel/eiciel-0.9-4.src.rpm Description: Eiciel is a graphical editor for access control lists either as an extension within nautilus, or as a standalone utility. Notes: This is my first package, so I thoroughly expect you to easily be able to pull holes in it ;-) Comments gratefully received, hints even more gratefully received. One step which I don't know how to handle at the moment, after installing the RPM you need to "killall nautilus" so that it picks up the new extensions, obviously it wouldn't be particularly friendly to do that in a post script! I've only built and run it on rawhide x86_64 so far, can't install an i386 machine until rawhide is in a better mood. I've done an rpmlint on it, two errors, one warning E: eiciel standard-dir-owned-by-package /usr/share/man E: eiciel standard-dir-owned-by-package /usr/share/man/man1 I tried to fix the errors by changing the %files under %{_mandir} but it doesn't seem to have helped. W: eiciel devel-file-in-non-devel-package /usr/lib64/nautilus/extensions-1.0/libeiciel-nautilus.a I'm not sure if the warning is significant, I can't see having an eiciel-devel package being very likely, should the .a file stay or go, or the warning be ignored? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From gajownik at fedora.pl Thu Feb 2 18:07:49 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Thu, 02 Feb 2006 19:07:49 +0100 Subject: rpms/ginac/devel ginac.spec,1.4,1.5 In-Reply-To: <200602021658.k12GwfxE030879@cvs-int.fedora.redhat.com> References: <200602021658.k12GwfxE030879@cvs-int.fedora.redhat.com> Message-ID: <43E24A75.8020505@fedora.pl> Dnia 02/02/2006 05:59 PM, U?ytkownik Quentin Spencer (qspencer) napisa?: > Author: qspencer > Log Message: > Remove static libs. > +%exclude %{_libdir}/*.a IMHO it would be better to configure ginac with these options: %configure \ --disable-dependency-tracking \ --disable-static I also notices that you don't build ginac with `make %{?_smp_mflags}'. I've tested it with make -j3 and it seems to work fine. If parallel make breaks, you should mention it in the spec file. http://fedoraproject.org/wiki/Packaging/Guidelines#parallelmake Regards, Dawid -- ^_* From wart at kobold.org Thu Feb 2 18:23:05 2006 From: wart at kobold.org (Michael Thomas) Date: Thu, 02 Feb 2006 10:23:05 -0800 Subject: Taking ownership of 2 orphaned packages In-Reply-To: <43E24247.3090501@hhs.nl> References: <43E24247.3090501@hhs.nl> Message-ID: <43E24E09.2000205@kobold.org> Hans de Goede wrote: > HI, > > I would like to take ownership of bochs and scorched3d, any objections? I'd love to see you pick up scorched3d. I can help with some of the testing of it on FC4 x86_64. Last time I tried to run it my SDL parachutes kept getting deployed. :) --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From dragoran at feuerpokemon.de Thu Feb 2 18:26:13 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 02 Feb 2006 19:26:13 +0100 Subject: extras package that require changes in selinux-policy (initng) In-Reply-To: <1138903982.18268.216.camel@moss-spartans.epoch.ncsc.mil> References: <43DE4707.9010900@feuerpokemon.de> <43DE6A09.2040602@redhat.com> <43DF869C.1090700@feuerpokemon.de> <43E23C4C.4070203@feuerpokemon.de> <1138902557.18268.212.camel@moss-spartans.epoch.ncsc.mil> <43E245F4.30309@feuerpokemon.de> <1138903982.18268.216.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <43E24EC5.3000004@feuerpokemon.de> Stephen Smalley wrote: >On Thu, 2006-02-02 at 18:48 +0100, dragoran wrote: > > >>so what is the solution? use setexecon() to run the daemons as initrc_t >>to let the domain transitions take effect? >> >> > >No, that wouldn't work, nor it is useful. > > > >>this should also be init_t -> initrc_t -> daemon .. or did I miss / >>missunderstood something? >> >> > >As I said, the policy could be extended to include direct transitions >from init_t -> daemon domains so that initng would work as is. But that >needs to be taken up on selinux list and directed to refpolicy >maintainers. > > > filled bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179761 From bugzilla at redhat.com Thu Feb 2 18:23:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 13:23:18 -0500 Subject: [Bug 173459] Review Request: initng In-Reply-To: Message-ID: <200602021823.k12INIrG007634@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: initng https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459 ------- Additional Comments From dragoran at feuerpokemon.de 2006-02-02 13:23 EST ------- the selinux patch is now in svn .. but some changes to the policy are needed. I filled a bug here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179761 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From toshio at tiki-lounge.com Thu Feb 2 18:32:33 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 02 Feb 2006 10:32:33 -0800 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: References: Message-ID: <1138905153.3411.34.camel@localhost> On Thu, 2006-02-02 at 08:36 -0600, Rex Dieter wrote: > Per > http://fedoraproject.org/wiki/ScriptletSnippets > in the desktop-database and mimeinfo sections says to add > Requires(post): desktop-file-utils > Requires(postun): desktop-file-utils > and > Requires(post): shared-mime-info > Requires(postun): shared-mime-info > respectively, but the "GTK+ icon cache" section says (rightfully) "Note > that no dependencies should be added for this". Couldn't the same > argument for this latter statement be applied to both desktop-database > and mimeinfo as well? > > Shouldn't desktop-file-utils and shared-mime-info be Req'd (only) by the > desktop environments that use/require them (AFAIK, only gnome at the > moment). I don't know much about any of the technologies so here's some questions: Is gtk icon cache only a cache (ie: things will run without, just slower?) Do shared-mime-info and desktop-file-utils fall into the same category or does some functionality of programs fail to work if desktop-file-utils and shared-mime-info aren't run? Your post makes me think that some Core GNOME applications (nautilus? gnome-panel? gnome-vfs?) make use of the data generated by desktop-file-utils and shared-mime-info but nothing else. Is that true or just a guess? shared-mime-info seems to run itself on installation and update but desktop-file-utils does not. If desktop-file-utils is made optional for the scriptlets, the desktop-file-utils Core package should run itself on install. (Hmm.. gtk2 doesn't run gtk-update-icon-cache on install... is this a packaging bug? Or perhaps this bug would resolve it: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170335 ) -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 orion at cora.nwra.com Thu Feb 2 18:43:21 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 02 Feb 2006 11:43:21 -0700 Subject: Time for a FE update? Message-ID: <43E252C9.9060603@cora.nwra.com> 2 day old packages that need signing. Can we get a release? 3514 kdocker kdocker-1_3-4_fc5_1 needsign 2d ago fedora-development-extras rdieter math unl edu Thanks! -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From bugzilla at redhat.com Thu Feb 2 18:45:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 13:45:53 -0500 Subject: [Bug 177658] Review Request: mediawiki - The PHP-based wiki software behind Wikipedia In-Reply-To: Message-ID: <200602021845.k12IjrH0012731@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mediawiki - The PHP-based wiki software behind Wikipedia https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177658 ------- Additional Comments From imlinux at gmail.com 2006-02-02 13:45 EST ------- I believe you can use Requires(pre) instead of PreReq to achieve the same affect. I was looking at some that are already in Extras and some of them do them different ways. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From tibbs at math.uh.edu Thu Feb 2 19:03:57 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 02 Feb 2006 13:03:57 -0600 Subject: Time for a FE update? In-Reply-To: <43E252C9.9060603@cora.nwra.com> (Orion Poplawski's message of "Thu, 02 Feb 2006 11:43:21 -0700") References: <43E252C9.9060603@cora.nwra.com> Message-ID: >>>>> "OP" == Orion Poplawski writes: OP> kdocker-1_3-4_fc5_1 needsign 2d ago That package showed up on my mirror two days ago. If you're looking at the "Successful Builds" page, then you should be aware that items there don't disappear once they've been signed and added to the repo. - J< From meme at DaughtersOfTiresias.org Thu Feb 2 19:18:19 2006 From: meme at DaughtersOfTiresias.org (Karen Pease) Date: Thu, 2 Feb 2006 13:18:19 -0600 Subject: Retrying: magic file / invalid type 20 in mconvert()? Message-ID: <200602021318.19001.meme@DaughtersOfTiresias.org> Thanks, Frank. I don't think I ever would have figured that out, and it did the trick just great. Naturally, I credited you in the changelog. - Karen On Wednesday 01 February 2006 05:55 pm, Frank Arnold wrote: > Am Mittwoch, den 01.02.2006, 09:51 -0600 schrieb Karen Pease: > > error: magic_file(ms, > > "/var/tmp/nethack-vultures-1.11.2-3-root-meme/usr/games/vulturesclaw/Guid > >eboo k.txt") failed: invalid type 20 in mconvert() > > rpmbuild: rpmfc.c:1229: rpmfcClassify: Assertion `ftype != ((void *)0)' > > failed. > > make: *** [i386] Aborted > > rpmbuild tries to determine the file type of Guidebook.txt, which seems > to fail. You should be able to reproduce this with > $ file -m /usr/lib/rpm/magic /path/to/Guidebook.txt > > If not, I have no clue what's going on. > > > I tried to build nethack-vultures-1.11.1-3 through mock with FC4 setup. > This failed with another error. The following command failed inside > BUILD/vultures-1.11.1/slashem/doc: > > tbl tmac.n Guidebook.mn | nroff -c -Tascii | col -bx > Guidebook.txt > > The problem here is that col returns 1, although the output looks usable > to me. This might be related to a patch in util-linux > (util-linux-2.12p-col-EILSEQ.patch, Bug 176441) which is only applied to > FC4 and FC5. > > Workaround is quite easy. With the following change inside your > nethack-vultures-1.10.1-clawguide.patch I was able to build the package: > > Current: > +GUIDECMD = tbl tmac.n Guidebook.mn | nroff -c -Tascii | $(COLCMD) > New: > +GUIDECMD = tbl tmac.n Guidebook.mn | nroff -c -Tascii | $(COLCMD) | cat > > Now 'cat' is the last command and it returns 0. > > HTH, > Frank ------------------------------------------------------- From bugzilla at redhat.com Thu Feb 2 19:19:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 14:19:47 -0500 Subject: [Bug 178668] Review Request: numpy: A fast multidimensional array facility for Python In-Reply-To: Message-ID: <200602021919.k12JJlGR019429@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: numpy: A fast multidimensional array facility for Python https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178668 ------- Additional Comments From ivazquez at ivazquez.net 2006-02-02 14:19 EST ------- Updated. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From qspencer at ieee.org Thu Feb 2 19:42:53 2006 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 02 Feb 2006 13:42:53 -0600 Subject: error loading shared lib Message-ID: <43E260BD.30401@ieee.org> I've never seen this before. I installed the latest octave and atlas on a devel machine and when I try to either start octave or even run ldd /usr/bin/octave, I get this: octave: error while loading shared libraries: libblas.so.3: cannot enable executable stack as shared object requires: Permission denied This works fine in FC-4, and used to work in devel. ATLAS was rebuilt after the upgrade to gcc 4.1, so I don't think that would cause it. Is it possible that further changes to gcc in the last month could have caused it? Any other ideas? -Quentin From bugzilla at redhat.com Thu Feb 2 20:15:17 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 15:15:17 -0500 Subject: [Bug 179775] New: Review Request: distcc Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179775 Summary: Review Request: distcc Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: ch.nolte at fh-wolfenbuettel.de QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://public.fh-wolfenbuettel.de/~noltec/open-source/distcc/distcc.spec SRPM Name or Url: http://public.fh-wolfenbuettel.de/~noltec/open-source/distcc/distcc-2.18.3-1.src.rpm Description: distcc is a program to distribute builds of C, C++, Objective C or Objective C++ code across several machines on a network. Hi! I have made a package and would like you to review it. Best regards Christian -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From j.w.r.degoede at hhs.nl Thu Feb 2 20:33:04 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 02 Feb 2006 21:33:04 +0100 Subject: error loading shared lib In-Reply-To: <43E260BD.30401@ieee.org> References: <43E260BD.30401@ieee.org> Message-ID: <43E26C80.2090104@hhs.nl> Quentin Spencer wrote: > I've never seen this before. I installed the latest octave and atlas on > a devel machine and when I try to either start octave or even run ldd > /usr/bin/octave, I get this: > > octave: error while loading shared libraries: libblas.so.3: cannot > enable executable stack as shared object requires: Permission denied > > This works fine in FC-4, and used to work in devel. ATLAS was rebuilt > after the upgrade to gcc 4.1, so I don't think that would cause it. Is > it possible that further changes to gcc in the last month could have > caused it? Any other ideas? > > -Quentin > selinux, try "setenforce 0" as root and then running octave, be it as user or as root. Regards, Hans From jamatos at fc.up.pt Thu Feb 2 20:34:33 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Thu, 2 Feb 2006 20:34:33 +0000 Subject: numpy-0.9.4 + scipy-0.4.4 In-Reply-To: <1138902272.23767.22.camel@ignacio.lan> References: <200602021716.00872.jamatos@fc.up.pt> <1138902272.23767.22.camel@ignacio.lan> Message-ID: <200602022034.33804.jamatos@fc.up.pt> On Thursday 02 February 2006 17:44, Ignacio Vazquez-Abrams wrote: > > I've actually been working on them. I have numpy in review (#178668) and > am building a new SRPM as we speak, but haven't had a chance to finish > up the scipy package. I will try to review it then. :-) -- Jos? Ab?lio From bugzilla at redhat.com Thu Feb 2 20:31:37 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 15:31:37 -0500 Subject: [Bug 179758] Review Request: Eiciel (ACL editor) In-Reply-To: Message-ID: <200602022031.k12KVbGN002078@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Eiciel (ACL editor) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179758 ------- Additional Comments From fedora at adslpipe.co.uk 2006-02-02 15:31 EST ------- To see the extra ACL properties tab within nautilus you need at least one of your filesystems to be mounted with "-o acl" A basic familiarity with getfacl/setfacl would be useful too http://acl.bestbits.at/ -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From gajownik at fedora.pl Thu Feb 2 20:53:23 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Thu, 02 Feb 2006 21:53:23 +0100 Subject: error loading shared lib In-Reply-To: <43E26C80.2090104@hhs.nl> References: <43E260BD.30401@ieee.org> <43E26C80.2090104@hhs.nl> Message-ID: <43E27143.9050603@fedora.pl> Dnia 02/02/2006 09:30 PM, U?ytkownik Hans de Goede napisa?: >> octave: error while loading shared libraries: libblas.so.3: cannot >> enable executable stack as shared object requires: Permission denied libblas.so.3 should be fixed somehow ;) http://www.gentoo.org/proj/en/hardened/gnu-stack.xml http://people.redhat.com/drepper/selinux-mem.html > selinux, try "setenforce 0" As a temporary workaround for this problem you may want to enable execstack: setsebool allow_execstack=true (add `-P' option if you want this to be persistent). It will have less security impact than running SELinux in permissive mode :) -- ^_* From rdieter at math.unl.edu Thu Feb 2 21:14:40 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 02 Feb 2006 15:14:40 -0600 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: <1138905153.3411.34.camel@localhost> References: <1138905153.3411.34.camel@localhost> Message-ID: Toshio Kuratomi wrote: > Is gtk icon cache only a cache (ie: things will run without, just > slower?) Yes. > Do shared-mime-info and desktop-file-utils fall into the same category > or does some functionality of programs fail to work if > desktop-file-utils and shared-mime-info aren't run? The latter. > Your post makes me think that some Core GNOME applications (nautilus? > gnome-panel? gnome-vfs?) make use of the data generated by > desktop-file-utils and shared-mime-info but nothing else. Is that true > or just a guess? Gnome in general, yes. That's why I'm arguing it should be the GNOME libs/core bits that should depend on these, not (all) individual apps. > shared-mime-info seems to run itself on installation and update but > desktop-file-utils does not. If desktop-file-utils is made optional for > the scriptlets, the desktop-file-utils Core package should run itself on > install. I'm not arguing that running them should be optional, only that the additional dependancies for them not be added/Required. > (Hmm.. gtk2 doesn't run gtk-update-icon-cache on install... is > this a packaging bug? IMO, yes. >Or perhaps this bug would resolve it: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170335 Yes too. (that's my bug). -- Rex From Christian.Iseli at licr.org Thu Feb 2 23:16:45 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 03 Feb 2006 00:16:45 +0100 Subject: typo in owners file ? Message-ID: <200602022317.k12NH4nd027799@mx1.redhat.com> Hi folks, After perusing my script output, I hit this strangeness in the owners file: Fedora Extras|xaliclock|A clock for the X Window System|kaboom oobleck.net|extras-qa at fedoraproject.org| Fedora Extras|xdaliclock|A clock for the X Window System|kaboom oobleck.net|extras-qa at fedoraproject.org| I'd say the first line looks like a typo, especially considering the fact that there is no such package (xaliclock, without the d) in the repo... I'm tempted to just remove the line, but then won't that break something wrt the bugzilla components ? So I thought I'd ask before breaking something... Cheers, Christian From bugzilla at redhat.com Fri Feb 3 01:03:04 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 20:03:04 -0500 Subject: [Bug 179802] New: Review Request: seamonkey Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179802 Summary: Review Request: seamonkey Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: kengert at redhat.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://kuix.de/mozilla/seamonkey/1.0/src/parts/seamonkey.spec SRPM Name or Url: http://kuix.de/mozilla/seamonkey/1.0/src/seamonkey-1.0-1.src.rpm Description: This is my first package and I need a sponsor. I propose that Chris Aillon could be my sponsor, who let me know he is willing to help me. See http://www.mozilla.org/projects/seamonkey/ for the project homepage. SeaMonkey is not a contribution by me, it is produced by the SeaMonkey Project. My intention is limited to be a provider of a SeaMonkey package for Fedora Extras, adding some patches that make sense in the context in the context of the Fedora project. SeaMonkey might eventually obsolete the Mozilla package, but we are not yet sure when that should happen. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From sopwith at redhat.com Fri Feb 3 01:18:33 2006 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 2 Feb 2006 20:18:33 -0500 (EST) Subject: typo in owners file ? In-Reply-To: <200602022317.k12NH4nd027799@mx1.redhat.com> References: <200602022317.k12NH4nd027799@mx1.redhat.com> Message-ID: Looks like an honest mistake - feel free to remove that first line... bugzilla should be fine. Best, -- Elliot On Fri, 3 Feb 2006 Christian.Iseli at licr.org wrote: > Fedora Extras|xaliclock|A clock for the X Window System|kaboom oobleck.net|extras-qa at fedoraproject.org| > Fedora Extras|xdaliclock|A clock for the X Window System|kaboom oobleck.net|extras-qa at fedoraproject.org| > > I'd say the first line looks like a typo, especially considering the fact that > there is no such package (xaliclock, without the d) in the repo... > > I'm tempted to just remove the line, but then won't that break something wrt > the bugzilla components ? So I thought I'd ask before breaking something... > > Cheers, > Christian > > > From jwboyer at jdub.homelinux.org Fri Feb 3 01:38:02 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 02 Feb 2006 20:38:02 -0500 Subject: [Bug 179802] New: Review Request: seamonkey In-Reply-To: References: Message-ID: <1138930683.2546.4.camel@yoda.jdub.homelinux.org> On Thu, 2006-02-02 at 20:03 -0500, bugzilla at redhat.com wrote: > Please do not reply directly to this email. All additional > comments should be made in the comments box of this bug report. > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179802 I get an access denied when trying to view this bug. Anybody else having issues? josh From bugzilla at redhat.com Fri Feb 3 02:35:43 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 21:35:43 -0500 Subject: [Bug 178263] Review Request: ncarg - A Fortran and C based software package for scientific visualization In-Reply-To: Message-ID: <200602030235.k132ZhAd029348@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ncarg - A Fortran and C based software package for scientific visualization https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178263 ed at eh3.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From ed at eh3.com 2006-02-02 21:35 EST ------- Hi Orion, you've addressed all the comments and I just got a clean build in mock (fc5, i386) with the 4.4.1-2 SRPM. Good! And thanks to Wart (#7 above) for checking that the binaries don't segfault. APPROVED. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From ivazquez at ivazquez.net Fri Feb 3 02:41:14 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 02 Feb 2006 21:41:14 -0500 Subject: [Bug 179802] New: Review Request: seamonkey In-Reply-To: <1138930683.2546.4.camel@yoda.jdub.homelinux.org> References: <1138930683.2546.4.camel@yoda.jdub.homelinux.org> Message-ID: <1138934474.23767.28.camel@ignacio.lan> On Thu, 2006-02-02 at 20:38 -0500, Josh Boyer wrote: > On Thu, 2006-02-02 at 20:03 -0500, bugzilla at redhat.com wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179802 > > I get an access denied when trying to view this bug. Anybody else > having issues? Ditto. -- 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 Fri Feb 3 02:43:39 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 02 Feb 2006 21:43:39 -0500 Subject: [Bug 179802] New: Review Request: seamonkey In-Reply-To: <1138930683.2546.4.camel@yoda.jdub.homelinux.org> References: <1138930683.2546.4.camel@yoda.jdub.homelinux.org> Message-ID: <1138934620.3451.21.camel@bree.local.net> On Thu, 2006-02-02 at 20:38 -0500, Josh Boyer wrote: > On Thu, 2006-02-02 at 20:03 -0500, bugzilla at redhat.com wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179802 > > I get an access denied when trying to view this bug. Anybody else > having issues? Fixed Jeremy From bugzilla at redhat.com Fri Feb 3 02:41:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 21:41:48 -0500 Subject: [Bug 175281] Review Request: perl-Tie-EncryptedHash In-Reply-To: Message-ID: <200602030241.k132fm6r030097@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Tie-EncryptedHash https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175281 Bug 175281 depends on bug 168580, which changed state. Bug 168580 Summary: Review Request: perl-Crypt-DES https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168580 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NEXTRELEASE Status|ASSIGNED |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 3 02:42:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 21:42:02 -0500 Subject: [Bug 168583] Review Request: perl-Crypt-DES_EDE3 In-Reply-To: Message-ID: <200602030242.k132g2TL030163@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Crypt-DES_EDE3 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168583 Bug 168583 depends on bug 168580, which changed state. Bug 168580 Summary: Review Request: perl-Crypt-DES https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168580 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NEXTRELEASE Status|ASSIGNED |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 3 02:48:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 21:48:36 -0500 Subject: [Bug 168607] Review Request: perl-Convert-PEM In-Reply-To: Message-ID: <200602030248.k132macb030973@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Convert-PEM https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168607 Bug 168607 depends on bug 168583, which changed state. Bug 168583 Summary: Review Request: perl-Crypt-DES_EDE3 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168583 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NEXTRELEASE Status|ASSIGNED |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 3 03:12:40 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 22:12:40 -0500 Subject: [Bug 174368] Review Request: perl-Crypt-DSA In-Reply-To: Message-ID: <200602030312.k133CemT002849@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Crypt-DSA https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174368 Bug 174368 depends on bug 168607, which changed state. Bug 168607 Summary: Review Request: perl-Convert-PEM https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168607 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NEXTRELEASE Status|ASSIGNED |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 3 03:30:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 2 Feb 2006 22:30:27 -0500 Subject: [Bug 167354] Review Request: amavisd-new In-Reply-To: Message-ID: <200602030330.k133URdY006911@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: amavisd-new https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167354 steve at silug.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From steve at silug.org 2006-02-02 22:30 EST ------- Please open a new bug if you can reproduce the problem with 2.3.3-5 when it comes out of the build system. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 3 05:50:32 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 00:50:32 -0500 Subject: [Bug 179818] New: Review Request: xpilot-ng - A mutiplayer space arcade game Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179818 Summary: Review Request: xpilot-ng - A mutiplayer space arcade game Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: wart at kobold.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.kobold.org/~wart/fedora/xpilot-ng.spec SRPM Name or Url: http://www.kobold.org/~wart/fedora/xpilot-ng-4.7.2-1.src.rpm Description: A highly addictive, infinitely configurable multiplayer space arcade game. You pilot a spaceship around space, dodging obstacles, shooting players and bots, collecting power-ups, and causing general mayhem. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 3 06:05:04 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 01:05:04 -0500 Subject: [Bug 179818] Review Request: xpilot-ng - A mutiplayer space arcade game In-Reply-To: Message-ID: <200602030605.k13654gZ005755@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xpilot-ng - A mutiplayer space arcade game https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179818 ------- Additional Comments From wart at kobold.org 2006-02-03 01:04 EST ------- There are two issues that I already know about with this package: 1) rpmlint on FC5 complains about non-utf-8 files: W: xpilot-ng file-not-utf8 /usr/share/man/man6/xpilot-ng-x11.6.gz W: xpilot-ng-server file-not-utf8 /usr/share/man/man6/xpilot-ng-server.6.gz I'm not sure how to properly fix these. 2) Neither the base package nor the -server package own %{_datadir}/%{name} Both packages can be installed independently, or both can be installed at the same time. In such a case, which package should own the directory? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From Christian.Iseli at licr.org Fri Feb 3 07:00:33 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 03 Feb 2006 08:00:33 +0100 Subject: typo in owners file ? In-Reply-To: Your message of "Thu, 02 Feb 2006 20:18:33 EST." Message-ID: <200602030700.k1370ZXp009492@mx1.redhat.com> sopwith at redhat.com said: > Looks like an honest mistake - feel free to remove that first line... > bugzilla should be fine. Done. Cheers, Christian From bugzilla at redhat.com Fri Feb 3 07:27:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 02:27:50 -0500 Subject: [Bug 179775] Review Request: distcc In-Reply-To: Message-ID: <200602030727.k137Roju026257@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: distcc https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179775 paul at city-fan.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |DUPLICATE OtherBugsDependingO|163776 | nThis| | ------- Additional Comments From paul at city-fan.org 2006-02-03 02:27 EST ------- You may wish to work with the owner of Bug 174883, who submitted a distcc package some time ago. *** This bug has been marked as a duplicate of 174883 *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 3 07:28:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 02:28:08 -0500 Subject: [Bug 174883] Review Request: distcc -- A free distributed C/C++ compiler system In-Reply-To: Message-ID: <200602030728.k137S85Y026332@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: distcc -- A free distributed C/C++ compiler system https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174883 paul at city-fan.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ch.nolte at fh-wolfenbuettel.de ------- Additional Comments From paul at city-fan.org 2006-02-03 02:27 EST ------- *** Bug 179775 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From Eric.Tanguy at univ-nantes.fr Fri Feb 3 07:53:54 2006 From: Eric.Tanguy at univ-nantes.fr (Eric TANGUY) Date: Fri, 3 Feb 2006 08:53:54 +0100 (CET) Subject: new gcc-4.1 issues Message-ID: <56320.172.20.10.60.1138953234.squirrel@webmail.univ-nantes.fr> I have a package which no more build in devel with gcc-4.1. It seems that i need to pass a new paramater -ffriend-injection (http://gcc.gnu.org/gcc-4.1/changes.html) but i don't know how to do that. During configure process or during make process ? Someone could help me ? Thanks Eric From rc040203 at freenet.de Fri Feb 3 08:10:40 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 03 Feb 2006 09:10:40 +0100 Subject: new gcc-4.1 issues In-Reply-To: <56320.172.20.10.60.1138953234.squirrel@webmail.univ-nantes.fr> References: <56320.172.20.10.60.1138953234.squirrel@webmail.univ-nantes.fr> Message-ID: <1138954240.31136.247.camel@mccallum.corsepiu.local> On Fri, 2006-02-03 at 08:53 +0100, Eric TANGUY wrote: > I have a package which no more build in devel with gcc-4.1. It seems that > i need to pass a new paramater -ffriend-injection > (http://gcc.gnu.org/gcc-4.1/changes.html) but i don't know how to do that. > During configure process or during make process ? 1. Have the code fixed. 2. During configuration. %configure CXXFLAGS="${RPM_OPT_FLAGS} -ffriend-injection" However, if the offending code you are facing this issue with, is part of a public header, only alternative 1. is a feasible alternative. Ralf From ivazquez at ivazquez.net Fri Feb 3 08:13:47 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 03 Feb 2006 03:13:47 -0500 Subject: new gcc-4.1 issues In-Reply-To: <56320.172.20.10.60.1138953234.squirrel@webmail.univ-nantes.fr> References: <56320.172.20.10.60.1138953234.squirrel@webmail.univ-nantes.fr> Message-ID: <1138954427.23767.34.camel@ignacio.lan> On Fri, 2006-02-03 at 08:53 +0100, Eric TANGUY wrote: > I have a package which no more build in devel with gcc-4.1. It seems that > i need to pass a new paramater -ffriend-injection > (http://gcc.gnu.org/gcc-4.1/changes.html) but i don't know how to do that. > During configure process or during make process ? > Someone could help me ? Don't bother. Just write a patch for the code. *** class f; struct S { friend void f(); }; void g() { f(); } *** -- 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 bugzilla at redhat.com Fri Feb 3 09:07:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 04:07:48 -0500 Subject: [Bug 174883] Review Request: distcc -- A free distributed C/C++ compiler system In-Reply-To: Message-ID: <200602030907.k1397m6K014733@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: distcc -- A free distributed C/C++ compiler system https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174883 ------- Additional Comments From ch.nolte at fh-wolfenbuettel.de 2006-02-03 04:07 EST ------- Hi! As I have submitted a duplicate, I am now in a position to tear your package apart ;-) I have found the following problems and possible sollutions: A " mock -r fedora-development-i386-core" failed because subpackage gnome needs "BuildRequires: desktop-file-utils" for desktop-file-install. Rpmlint shows the following problems: W: distcc incoherent-version-in-changelog 2.18.3-0.6 2.18.3-1 The version your changelog refers to should be 2.18.3-1 W: distcc conffile-without-noreplace-flag /etc/profile.d/distcc.sh As this is no config-file this warning seems to be ignorable E: distcc executable-marked-as-config-file /etc/profile.d/distcc.sh You should add distcc.sh separately not flagging it as a config. This will make the warning above go away, too. E: distcc script-without-shellbang /etc/profile.d/distcc.sh "!#" is missing in your shellscript W: distcc dangerous-command-in-%preun rm W: distcc dangerous-command-in-%trigger ln W: distcc dangerous-command-in-%trigger rm I don't know how dangerous this really is. Please check that. W: distcc-gnome non-standard-group Development/Applications This should just be one of /usr/share/doc/rpm-4.?.?/GROUPS W: distcc-gnome no-documentation As there is no documentation only for distccmon-gnome, this can be ignored W: distcc-server-lsb conffile-without-noreplace-flag /etc/rc.d/init.d/distccd This is no config-file, don't flag it as such. W: distcc-server-lsb no-documentation The manpage for the server is missing: %{_mandir}/man1/distccd.1.gz E: distcc-server-lsb executable-marked-as-config-file /etc/rc.d/init.d/distccd This is related to the warning above. E: distcc-server-lsb non-standard-gid /var/run/distccd distcc E: distcc-server-lsb non-standard-dir-perm /var/run/distccd 0775 I guess this must be ignored because the server won't work as user "distcc" otherwise E: distcc-server-lsb postin-without-chkconfig /etc/rc.d/init.d/distccd E: distcc-server-lsb preun-without-chkconfig /etc/rc.d/init.d/distccd "chkconfig -add distccd" and "chkconfig -del distccd" is needed for correctly un-/installing the server package W: distcc-server-lsb incoherent-init-script-name distccd I don't know what is wrong here... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 3 10:16:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 05:16:34 -0500 Subject: [Bug 178310] Review Request: w3c-libwww - An HTTP library of common code In-Reply-To: Message-ID: <200602031016.k13AGY7Y028351@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: w3c-libwww - An HTTP library of common code https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178310 pertusus at free.fr changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|gdk at redhat.com |pertusus at free.fr ------- Additional Comments From pertusus at free.fr 2006-02-03 05:16 EST ------- I was going to approve, but I have found (by chance) an issue. It seems to me that w3c-libwww uses a very outdated version of expat, with code included. I filed a bug #179836 against the FC-4 version. I think it is better not to ship it before we get a return on that issue (but if somebody feels like doing a patch and testing, it'll be nice ;-). I also have an advice, it is to add a comment for each patch explaining what it does. It is optionnal, though, and can be done much later. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 3 11:16:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 06:16:13 -0500 Subject: [Bug 178310] Review Request: w3c-libwww - An HTTP library of common code In-Reply-To: Message-ID: <200602031116.k13BGDvc003670@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: w3c-libwww - An HTTP library of common code https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178310 ------- Additional Comments From andreas.bierfert at lowlatency.de 2006-02-03 06:16 EST ------- Hm, maybe I don't get this but both expat libs that get created are _not_ part of expat or expat-devel or did I miss something? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 3 12:47:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 07:47:01 -0500 Subject: [Bug 179758] Review Request: Eiciel (ACL editor) In-Reply-To: Message-ID: <200602031247.k13Cl1iu017215@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Eiciel (ACL editor) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179758 ------- Additional Comments From fedora at adslpipe.co.uk 2006-02-03 07:46 EST ------- Just to note that I've now built and installed this on rawhide i386 too. In addition I've uploaded the x86_64 and i386 RPMS to http://adslpipe.co.uk/fedora/extras/eiciel The gcc4.1 patch has been accepted upstream, so will disappear for 0.9.1 Talking with the developer the .a library which causes the rpmlint warning is probably best removed from the RPM, is there a way to ignore it in the %files section, or just "rm" it after "make" and before "make install" I'm still getting the rpmlint errors about ownership of the man files, also when I tried an rpmbuild --rebuild of the SRPM file on i386 I got a warning about the man file being present twice. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 3 12:52:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 07:52:10 -0500 Subject: [Bug 178310] Review Request: w3c-libwww - An HTTP library of common code In-Reply-To: Message-ID: <200602031252.k13CqAjG018014@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: w3c-libwww - An HTTP library of common code https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178310 ------- Additional Comments From pertusus at free.fr 2006-02-03 07:52 EST ------- No you didn't miss anything, it seems that libxmlparse and libxmltok were merged in the expat library. The included expat seems to correspond with expat version below 1.2, that was at this page: http://www.jclark.com/xml/expat.html I haven't investigated precisely, but at least some symbols that are in xmlparse.h and xmltok.h are in expat.h. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 3 12:55:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 07:55:10 -0500 Subject: [Bug 179758] Review Request: Eiciel (ACL editor) In-Reply-To: Message-ID: <200602031255.k13CtAkW018436@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Eiciel (ACL editor) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179758 ------- Additional Comments From paul at city-fan.org 2006-02-03 07:55 EST ------- (In reply to comment #3) > Talking with the developer the .a library which causes the rpmlint warning is > probably best removed from the RPM, is there a way to ignore it in the %files > section, or just "rm" it after "make" and before "make install" You can either remove it in %install, or use %exclude for the file in the %files list. > I tried an rpmbuild --rebuild of the SRPM file on i386 I got a warning about the > man file being present twice. %{_mandir}/man1/eiciel* is also included as part of %{_datadir}/* Be more specific in what you're including in the files list. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 3 14:12:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 09:12:02 -0500 Subject: [Bug 179818] Review Request: xpilot-ng - A mutiplayer space arcade game In-Reply-To: Message-ID: <200602031412.k13EC2u0031537@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xpilot-ng - A mutiplayer space arcade game https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179818 ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-03 09:12 EST ------- (In reply to comment #1) > There are two issues that I already know about with this package: > > 1) rpmlint on FC5 complains about non-utf-8 files: > W: xpilot-ng file-not-utf8 /usr/share/man/man6/xpilot-ng-x11.6.gz > W: xpilot-ng-server file-not-utf8 /usr/share/man/man6/xpilot-ng-server.6.gz > I'm not sure how to properly fix these. In %prep: pushd doc/man iconv --from=ISO-8859-1 --to=UTF-8 xpilot-ng-server.man > xpilot-ng-server.man.new mv xpilot-ng-server.man.new xpilot-ng-server.man iconv --from=ISO-8859-1 --to=UTF-8 xpilot-ng-x11.man > xpilot-ng-x11.man.new mv xpilot-ng-x11.man.new xpilot-ng-x11.man popd > 2) Neither the base package nor the -server package own %{_datadir}/%{name} > Both packages can be installed independently, or both can be installed at the > same time. In such a case, which package should own the directory? I would create a third package "xpilot-ng-common" that would own any files or directories that were required by both the client and server packages. Then add a "Requires: xpilot-ng-common = %{version}-%{release}" to both the xpilot-ng and xpilot-ng-server packages. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 3 14:22:26 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 09:22:26 -0500 Subject: [Bug 179758] Review Request: Eiciel (ACL editor) In-Reply-To: Message-ID: <200602031422.k13EMQUe000954@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Eiciel (ACL editor) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179758 ------- Additional Comments From fedora at adslpipe.co.uk 2006-02-03 09:22 EST ------- Thanks for that ... I've excluded the .a file, and been more specific about the %files now it builds and rebuilds clean on i386 and x86_64 plus rpmlint is silent. I presume that because %doc matches all the files under /usr/share/doc it's best to remove my (currently commented) %{_datadir}/doc/eiciel*/* Similarly I believe that RPM is clever enough to work out the Requires: for itself, so my commented Requires: should be removed too? Or if it's not so clever as I've assumed I should check more closely the actual Requires: I only get a -debuginfo package produced on x86_64, does that indicate a problem? All files refreshed to http://adslpipe.co.uk/fedora/extras/eiciel I think I should go through a typical review checklist in a "muttering to myself" fashion ... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 3 14:55:41 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 09:55:41 -0500 Subject: [Bug 179758] Review Request: Eiciel (ACL editor) In-Reply-To: Message-ID: <200602031455.k13EtftX008006@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Eiciel (ACL editor) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179758 ------- Additional Comments From paul at city-fan.org 2006-02-03 09:55 EST ------- (In reply to comment #5) > I presume that because %doc matches all the files under /usr/share/doc it's best > to remove my (currently commented) %{_datadir}/doc/eiciel*/* Yes. > Similarly I believe that RPM is clever enough to work out the Requires: for > itself, so my commented Requires: should be removed too? Or if it's not so > clever as I've assumed I should check more closely the actual Requires: Look at the dependencies of your built package: $ rpm -qp --requires /path/to/eiciel*.x86_64.rpm There should be dependencies for the required shared libraries, normally satisfied by the libacl, libattr, and gnome-vfs2 packages, so there should be no need to explictly require these packages. > I only get a -debuginfo package produced on x86_64, does that indicate a problem? Maybe you don't have redhat-rpm-config installed on your i386 system? > All files refreshed to http://adslpipe.co.uk/fedora/extras/eiciel > > I think I should go through a typical review checklist in a "muttering to > myself" fashion ... That's always a good idea. http://fedoraproject.org/wiki/Packaging/ReviewGuidelines -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 3 15:16:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 10:16:10 -0500 Subject: [Bug 172755] Review Request: xcompmgr - X11 composite manager In-Reply-To: Message-ID: <200602031516.k13FGAXX011546@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xcompmgr - X11 composite manager https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172755 ------- Additional Comments From bos at serpentine.com 2006-02-03 10:15 EST ------- I'd love to see this in extras, too, but the URL is down again. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From jonathan.underwood at gmail.com Fri Feb 3 15:27:45 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 3 Feb 2006 15:27:45 +0000 Subject: Povray, fedora extras and licensing Message-ID: <645d17210602030727o36bdb493i@mail.gmail.com> Hi I was considering adding POV-Ray to fedora extras, butI notice that the license that POV-Ray is distributed is not in any of the 3 lists referenced in the packaging guidelines. However, their redistribution license found here: http://www.povray.org/distribution-license.html specifically names fedora and implies that it is fine to redistribute POV-Ray for this distribution. So, shall I go ahead and submit? Jonathan. From bugzilla at redhat.com Fri Feb 3 15:32:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 10:32:36 -0500 Subject: [Bug 179818] Review Request: xpilot-ng - A mutiplayer space arcade game In-Reply-To: Message-ID: <200602031532.k13FWa5e014727@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xpilot-ng - A mutiplayer space arcade game https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179818 j.w.r.degoede at hhs.nl changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |j.w.r.degoede at hhs.nl ------- Additional Comments From j.w.r.degoede at hhs.nl 2006-02-03 10:32 EST ------- I would only create the common package if there are indeed common files, otherwise just own the dir in both packages, there is plenty of precedence for this. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rc040203 at freenet.de Fri Feb 3 15:56:00 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 03 Feb 2006 16:56:00 +0100 Subject: Povray, fedora extras and licensing In-Reply-To: <645d17210602030727o36bdb493i@mail.gmail.com> References: <645d17210602030727o36bdb493i@mail.gmail.com> Message-ID: <1138982160.31136.306.camel@mccallum.corsepiu.local> On Fri, 2006-02-03 at 15:27 +0000, Jonathan Underwood wrote: > Hi > > I was considering adding POV-Ray to fedora extras, butI notice that > the license that POV-Ray is distributed is not in any of the 3 lists > referenced in the packaging guidelines. However, their redistribution > license found here: > > http://www.povray.org/distribution-license.html > > specifically names fedora and implies that it is fine to redistribute > POV-Ray for this distribution. So, shall I go ahead and submit? The povray license had repeatedly been subject to fierce arguments. Several people (eg. me) consider it not to be an OpenSource License, but read it (IANAL) as a "Free Beer License" (You can get the sources, but you are not allowed to reuse the source code). May-be you should contact the "legal channels" of Fedora, the FF, the OSI, or may-be POV-Ray Ltd. to give a legally qualified statement on this. Ralf From gdk at redhat.com Fri Feb 3 16:06:25 2006 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Fri, 3 Feb 2006 11:06:25 -0500 (EST) Subject: Povray, fedora extras and licensing In-Reply-To: <1138982160.31136.306.camel@mccallum.corsepiu.local> References: <645d17210602030727o36bdb493i@mail.gmail.com> <1138982160.31136.306.camel@mccallum.corsepiu.local> Message-ID: It reminds me of some of Mozilla's Firefox/Iceweasel stuff. Lemme get this in front of the board. --g --------------------------------------------------------------- Greg DeKoenigsberg || Fedora Foundation || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors --------------------------------------------------------------- On Fri, 3 Feb 2006, Ralf Corsepius wrote: > On Fri, 2006-02-03 at 15:27 +0000, Jonathan Underwood wrote: > > Hi > > > > I was considering adding POV-Ray to fedora extras, butI notice that > > the license that POV-Ray is distributed is not in any of the 3 lists > > referenced in the packaging guidelines. However, their redistribution > > license found here: > > > > http://www.povray.org/distribution-license.html > > > > specifically names fedora and implies that it is fine to redistribute > > POV-Ray for this distribution. So, shall I go ahead and submit? > The povray license had repeatedly been subject to fierce arguments. > > Several people (eg. me) consider it not to be an OpenSource License, but > read it (IANAL) as a "Free Beer License" (You can get the sources, but > you are not allowed to reuse the source code). > > May-be you should contact the "legal channels" of Fedora, the FF, the > OSI, or may-be POV-Ray Ltd. to give a legally qualified statement on > this. > > Ralf > > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From bugzilla at redhat.com Fri Feb 3 16:10:26 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 11:10:26 -0500 Subject: [Bug 179758] Review Request: Eiciel (ACL editor) In-Reply-To: Message-ID: <200602031610.k13GAQjC022248@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Eiciel (ACL editor) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179758 ------- Additional Comments From fedora at adslpipe.co.uk 2006-02-03 11:10 EST ------- ******* SELF REVIEW ****** - MUST: rpmlint must be run on every package. The output should be posted in the review. # rpmlint -v eiciel-0.9-5.x86_64.rpm I: eiciel checking seems nice # rpmlint -v eiciel-0.9-5.i386.rpm I: eiciel checking W: eiciel unstripped-binary-or-object /usr/lib/nautilus/extensions-1.0/libeiciel-nautilus.so.0.0.0 W: eiciel unstripped-binary-or-object /usr/bin/eiciel so why did this happen on i386 but not x86_64, I have a pretty mininal install on i386, some -devel tool missing perhaps? # rpmlint -v eiciel-0.9-5.src.rpm I: eiciel checking W: eiciel strange-permission eiciel-gcc41.patch 0646 ok, my original file, I did chmod it when passing it between root and another user, what is normal? 644? - MUST: The package must be named according to the Package Naming Guidelines. I beieve this is straighforward "eiciel" though I do keep mistyping it :-) I see that the template .spec file does use %{?dist} take, but I don't get .fc5 in make RPMs is that ok for me, will it be ok in buildsys? - MUST: The spec file name must match the base package %{name}, in the format %{name}.spec "eiciel.spec", tick - MUST: The package must meet the Packaging Guidelines. hmm, should I really treat the packaging guidelines as a checklist within a checklist? - MUST: The package must be licensed with an open-source compatible license and meet other legal requirements as defined in the legal section of Packaging Guidelines. Copying file is GPL2, most cpp/hpp files have explicit GPL2 in them, necessary to check them all individually? - MUST: The License field in the package spec file must match the actual license. GPL, tick - MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc. COPYING in %doc - MUST: The spec file must be written in American English. tick - MUST: The spec file for the package MUST be legible. If the reviewer is unable to read the spec file, it will be impossible to perform a review. Fedora Extras is not the place for entries into the Obfuscated Code Contest ([WWW] http://www.ioccc.org/). I hope it's clean, I'll remove my commented section(s) following advice - MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. hmm, kind of like marking my own essay, but a083609380ec8272b3693cbaee184f13 eiciel-0.9.tar.bz2 - MUST: The package must successfully compile and build into binary rpms on at least one supported architecture. i386 and x86_64 - MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch needs to have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number should then be placed in a comment, next to the corresponding ExcludeArch line. New packages will not have bugzilla entries during the review process, so they should put this description in the comment until the package is approved, then file the bugzilla entry, and replace the long explanation with the bug number. The bug should be marked as blocking one (or more) of the following bugs to simplify tracking such issues: [WWW] FE-ExcludeArch-x86, [WWW] FE-ExcludeArch-x64, [WWW] FE-ExcludeArch-ppc status unknown on other arches so far - MUST: A package must not contain any BuildRequires that are listed in the exceptions section of Packaging Guidelines. tick - MUST: All other Build dependencies must be listed in BuildRequires. hmm, fedora-rmdevelrpms wanted to remove packages that would cause broken dependencies, I guess I need to setup mock to test this? - MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden. got me bang to rights there, I'll look at how it's done - MUST: If the package contains shared library files located in the dynamic linker's default paths, that package must call ldconfig in %post and %postun. my .so files stay well clear of /bin and /usr/bin is that enough? - MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. tick - MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. The exception to this are directories listed explicitly in the Filesystem Hierarchy Standard ([WWW] http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to assume that those directories exist. is this talking about directories it creates at runtime, or install time, what about my dirs e.g /usr/share/eiceil ? - MUST: A package must not contain any duplicate files in the %files listing. tick, thanks paul - MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. hmmm, I din't make any change from the defattr the template gave me, presume I've got some work to do here? - MUST: Each package must have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). tick - MUST: Each package must consistently use macros, as described in the macros section of Packaging Guidelines. I hope the mix of $XXX and %{xxx} that the template started with is allowed? - MUST: The package must contain code, or permissable content. This is described in detail in the code vs. content section of Packaging Guidelines. no pr0n, tick - MUST: Large documentation files should go in a -docs subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity) not needed - MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. tick - MUST: Header files or static libraries must be in a -devel package. removed - MUST: Files used by pkgconfig (.pc files) must be in a -devel package. n/a - MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. but softlinks without suffix, pointing to the files with suffix are ok, right? - MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency. n/a - MUST: Packages must NOT contain any .la libtool archives, these should be removed in the spec. guilty, I'll exclude it then - MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. This is described in detail in the desktop files section of Packaging Guidelines. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. Ok, need to add this, it can be run standalone as well as from properties in nautilus - MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora Extras should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. think i'm clear here - SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. n/a - SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available. none provided - SHOULD: The reviewer should test that the package builds in mock. not done so yet - SHOULD: The package should compile and build into binary rpms on all supported architectures. i386 and x86_64 so far - SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example. works for me, provided you have a filesystem mounted "-o acl" but doesn't crash even if you don't - SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity. none - SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency. n/a OK, so I've found a few things to change :-) better to eat my time first! -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rc040203 at freenet.de Fri Feb 3 16:26:35 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 03 Feb 2006 17:26:35 +0100 Subject: Povray, fedora extras and licensing In-Reply-To: References: <645d17210602030727o36bdb493i@mail.gmail.com> <1138982160.31136.306.camel@mccallum.corsepiu.local> Message-ID: <1138983995.31136.319.camel@mccallum.corsepiu.local> On Fri, 2006-02-03 at 11:06 -0500, Greg DeKoenigsberg wrote: > It reminds me of some of Mozilla's Firefox/Iceweasel stuff. > > Lemme get this in front of the board. The crucial points of this license are [..] 3.4. Except as explicitly set out in this agreement, nothing in this agreement permits Distributor to make any modification to any part of the Software. [..] and 4. as a whole, with an emphasize on 4.1. Nothing in this agreement gives the Distributor: [..] (b) any rights or permissions in respect of, including rights or permissions to distribute or permit the use of, any Derived Code; There exist packages which once were based on povray code and ended up in trench wars on interpreting the povray license and abandoning supporting povray. As I read all this, the license grants rights to "distribute binaries and the sources of poyray", but does not allow using their sources. I don't see how this way of shipping is substantially different from "Closed Source". Similar to to the nvidia stuff it's conditionally distributable, but its sources actually are non-free. I'd be glad to be proved wrong ;) BTW: Debian has povray-3.5 in "stable", but classifies it as "non-free". Ralf From gdk at redhat.com Fri Feb 3 16:31:28 2006 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Fri, 3 Feb 2006 11:31:28 -0500 (EST) Subject: Povray, fedora extras and licensing In-Reply-To: <1138983995.31136.319.camel@mccallum.corsepiu.local> References: <645d17210602030727o36bdb493i@mail.gmail.com> <1138982160.31136.306.camel@mccallum.corsepiu.local> <1138983995.31136.319.camel@mccallum.corsepiu.local> Message-ID: On Fri, 3 Feb 2006, Ralf Corsepius wrote: > BTW: Debian has povray-3.5 in "stable", but classifies it as "non-free". Yep. >From the reactions I've heard so far, sounds like a big "no" to me -- and it brings up a good question: is it reasonable to consider a similar "non-free" repo for things like this that are (a) explicitly redistributable, but (b) not free? Not sure how I stand on that. --g --------------------------------------------------------------- Greg DeKoenigsberg || Fedora Foundation || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors --------------------------------------------------------------- From bugzilla at redhat.com Fri Feb 3 16:33:04 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 11:33:04 -0500 Subject: [Bug 179818] Review Request: xpilot-ng - A mutiplayer space arcade game In-Reply-To: Message-ID: <200602031633.k13GX4LG027530@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xpilot-ng - A mutiplayer space arcade game https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179818 ------- Additional Comments From wart at kobold.org 2006-02-03 11:32 EST ------- There are no common files between the two packages, but they both write to the same directory. However, both packages should probably have COPYING and README. But it would seem silly to make a "xpilog-ng-common" package that only included the license file and README. I created an updated package that uses iconv to utf8-ify the man pages and allow both packages to own %{_datadir}/%{name}: http://www.kobold.org/~wart/fedora/xpilot-ng-4.7.2-2.src.rpm http://www.kobold.org/~wart/fedora/xpilot-ng.spec -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From notting at redhat.com Fri Feb 3 16:43:17 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 3 Feb 2006 11:43:17 -0500 Subject: Povray, fedora extras and licensing In-Reply-To: References: <645d17210602030727o36bdb493i@mail.gmail.com> <1138982160.31136.306.camel@mccallum.corsepiu.local> <1138983995.31136.319.camel@mccallum.corsepiu.local> Message-ID: <20060203164316.GA8387@devserv.devel.redhat.com> Greg DeKoenigsberg (gdk at redhat.com) said: > > BTW: Debian has povray-3.5 in "stable", but classifies it as "non-free". > > Yep. > > >From the reactions I've heard so far, sounds like a big "no" to me -- and > it brings up a good question: is it reasonable to consider a similar > "non-free" repo for things like this that are (a) explicitly > redistributable, but (b) not free? > > Not sure how I stand on that. Hm, well, I could see something like that being useful, for, say, firmware. Bill From bugzilla at redhat.com Fri Feb 3 17:44:40 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 12:44:40 -0500 Subject: [Bug 179802] Review Request: seamonkey In-Reply-To: Message-ID: <200602031744.k13Hie3n011350@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: seamonkey https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179802 ------- Additional Comments From kengert at redhat.com 2006-02-03 12:44 EST ------- I've been asked to use SeaMonkey (capitalized M) in descriptions, will change that in next version of spec file. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 3 18:05:57 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 03 Feb 2006 19:05:57 +0100 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: (Rex Dieter's message of "Thu, 02 Feb 2006 08:36:10 -0600") References: Message-ID: <87k6ccs4fu.fsf@kosh.bigo.ensc.de> rdieter at math.unl.edu (Rex Dieter) writes: > respectively, but the "GTK+ icon cache" section says (rightfully) > "Note that no dependencies should be added for this". This section is wrong. Instead of, it should state that: * 'Requires(post): gtk2' shall be added for packages shipping icons and requiring gtk2 (e.g. typical Gnome2 applications) * a '%trigger -- gtk2' with gtk-update-icon-cache shall be added for packages shipping icons and NOT requiring gtk2 (e.g. KDE applications) * no additional deps should be added (as stated currently) Else, when you have a installation sequence of 1. package-A 2. gtk2 with package-A shipping icons, you will get a 5-10 startup penalty for every gtk2 application because the icon cache is outdated and 'gtk-update-icon-cache' was not executed. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From bugzilla at redhat.com Fri Feb 3 18:20:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 13:20:16 -0500 Subject: [Bug 179758] Review Request: Eiciel (ACL editor) In-Reply-To: Message-ID: <200602031820.k13IKG7J017762@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Eiciel (ACL editor) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179758 ------- Additional Comments From fedora at adslpipe.co.uk 2006-02-03 13:20 EST ------- Just made some changes and uploaded to the usual place installing redhat-rpm-config fixed a thing or two on the i386 box Last time around I didn't rpmlint the -debuginfo RPM, I did this time and I get # rpmlint -v eiciel-debuginfo-0.9-6.x86_64.rpm I: eiciel-debuginfo checking W: eiciel-debuginfo objdump-failed is that another worry? http://www.google.com/search?&q=rpmlint%20objdump-failed returns a googlewhack :-( -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From pertusus at free.fr Fri Feb 3 19:17:51 2006 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 3 Feb 2006 20:17:51 +0100 Subject: Povray, fedora extras and licensing In-Reply-To: References: <645d17210602030727o36bdb493i@mail.gmail.com> <1138982160.31136.306.camel@mccallum.corsepiu.local> <1138983995.31136.319.camel@mccallum.corsepiu.local> Message-ID: <20060203191751.GE3153@free.fr> > it brings up a good question: is it reasonable to consider a similar > "non-free" repo for things like this that are (a) explicitly > redistributable, but (b) not free? There are things like that on livna. -- Pat From notting at redhat.com Fri Feb 3 19:21:30 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 3 Feb 2006 14:21:30 -0500 Subject: Povray, fedora extras and licensing In-Reply-To: <20060203191751.GE3153@free.fr> References: <645d17210602030727o36bdb493i@mail.gmail.com> <1138982160.31136.306.camel@mccallum.corsepiu.local> <1138983995.31136.319.camel@mccallum.corsepiu.local> <20060203191751.GE3153@free.fr> Message-ID: <20060203192130.GA10552@devserv.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > > it brings up a good question: is it reasonable to consider a similar > > "non-free" repo for things like this that are (a) explicitly > > redistributable, but (b) not free? > > There are things like that on livna. Well, yes, but it might be useful to separate the things that are redistributable-everywhere-but-don't-meet-the-explicit-criteria vs. other things. Bill From eric.tanguy at univ-nantes.fr Fri Feb 3 19:29:01 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Fri, 03 Feb 2006 20:29:01 +0100 Subject: How to make a selective spec file Message-ID: <1138994941.2953.5.camel@bureau.maison> I would like to make only one spec taking into account the system build is devel/fc5 or fc3/fc4. How to make this ? In devel/fc5 i need to have : %configure CXXFLAGS="${RPM_OPT_FLAGS} -ffriend-injection" and in fc3/fc4 i need to have : %configure Thanks Eric From ivazquez at ivazquez.net Fri Feb 3 19:37:51 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 03 Feb 2006 14:37:51 -0500 Subject: How to make a selective spec file In-Reply-To: <1138994941.2953.5.camel@bureau.maison> References: <1138994941.2953.5.camel@bureau.maison> Message-ID: <1138995471.5160.7.camel@ignacio.lan> On Fri, 2006-02-03 at 20:29 +0100, Eric Tanguy wrote: > I would like to make only one spec taking into account the system build > is devel/fc5 or fc3/fc4. > How to make this ? > In devel/fc5 i need to have : > %configure CXXFLAGS="${RPM_OPT_FLAGS} -ffriend-injection" > and in fc3/fc4 i need to have : > %configure No, the variable only comes after the command with make. Everything else needs it before. Anyways... http://fedoraproject.org/wiki/DistTag -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rdieter at math.unl.edu Fri Feb 3 19:42:52 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 03 Feb 2006 13:42:52 -0600 Subject: How to make a selective spec file In-Reply-To: <1138994941.2953.5.camel@bureau.maison> References: <1138994941.2953.5.camel@bureau.maison> Message-ID: Eric Tanguy wrote: > I would like to make only one spec taking into account the system build > is devel/fc5 or fc3/fc4. > How to make this ? > In devel/fc5 i need to have : > %configure CXXFLAGS="${RPM_OPT_FLAGS} -ffriend-injection" > and in fc3/fc4 i need to have : > %configure Something like this ought to do the trick: %if "%{?fedora}" > "4" CXXFLAGS="${RPM_OPT_FLAGS} -ffriend-injection" %endif %configure -- Rex From rdieter at math.unl.edu Fri Feb 3 19:49:17 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 03 Feb 2006 13:49:17 -0600 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: <87k6ccs4fu.fsf@kosh.bigo.ensc.de> References: <87k6ccs4fu.fsf@kosh.bigo.ensc.de> Message-ID: Enrico Scholz wrote: > rdieter at math.unl.edu (Rex Dieter) writes: >>respectively, but the "GTK+ icon cache" section says (rightfully) >>"Note that no dependencies should be added for this". >Instead of, it should state that: > * 'Requires(post): gtk2' shall be added for packages shipping icons and > requiring gtk2 (e.g. typical Gnome2 applications) I disagree. This would be (mostly?) pointless. The pkgs in question already implicitly require gtk2 already, why add the bloat? > * a '%trigger -- gtk2' with gtk-update-icon-cache shall be added for > packages shipping icons and NOT requiring gtk2 (e.g. KDE applications) Ack, no. No need to add needless triggers, that could potentially get run 10's or theoretically 100's of times. There's a better way (see below) > Else, when you have a installation sequence of > 1. package-A > 2. gtk2 > with package-A shipping icons, you will get a 5-10 startup penalty > for every gtk2 application because the icon cache is outdated and > 'gtk-update-icon-cache' was not executed. That's why gtk2 should include it's own %post scriptlet: http://bugzilla.redhat.com/170335 -- REx From bugzilla at redhat.com Fri Feb 3 19:49:57 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 14:49:57 -0500 Subject: [Bug 179904] New: Review Request: icecast Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179904 Summary: Review Request: icecast Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: andreas at bawue.net QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://helena.bawue.de/~ixs/icecast/icecast.spec SRPM Name or Url: http://helena.bawue.de/~ixs/icecast/icecast-2.3.1-1.src.rpm Description: Icecast is a streaming media server which currently supports Ogg Vorbis and MP3 audio streams. It can be used to create an Internet radio station or a privately running jukebox and many things in between. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 3 20:01:55 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 15:01:55 -0500 Subject: [Bug 179904] Review Request: icecast In-Reply-To: Message-ID: <200602032001.k13K1t04013689@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: icecast https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179904 Matt_Domsch at dell.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Matt_Domsch at dell.com ------- Additional Comments From Matt_Domsch at dell.com 2006-02-03 15:01 EST ------- Do you plan to package ices also? I went down this path in November, using the copy of icecast in the mf repository, and building new ices, which needed new libshout (older libshout was in FC4 Extras already). There was concensus that upgrading libshout for FC4 wasn't a viable option, so it was either wait for FC5, or do a libshout21 package for FC4 that didn't conflict with libshout. And that's where I stopped... http://domsch.com/linux/fedora/extras/ had my packages for ices and libshout, if you're interested. Thanks, Matt -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 3 20:06:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 15:06:30 -0500 Subject: [Bug 179910] New: Review Request: commoncpp C++ framework Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179910 Summary: Review Request: commoncpp C++ framework Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: andreas at bawue.net QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://helena.bawue.de/~ixs/commoncpp/commoncpp.spec SRPM Name or Url: http://helena.bawue.de/~ixs/commoncpp/commoncpp-1.3.22-1.src.rpm Description: GNU Common C++ is a portable and highly optimized class framework for writing C++ applications that need to use threads, sockets, XML parsing, serialization, config files, etc. This framework offers a class foundation that hides platform differences from your C++ application so that you need not write platform specific code. GNU Common C++ has been ported to compile nativily on most platforms which support posix threads. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 3 20:17:32 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 15:17:32 -0500 Subject: [Bug 178604] Review Request: ruby-mysql In-Reply-To: Message-ID: <200602032017.k13KHWHS017430@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ruby-mysql https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178604 ------- Additional Comments From imlinux at gmail.com 2006-02-03 15:17 EST ------- One small thing. I'd release this under the GPL license. In the copying file it says the following: Ruby is copyrighted free software by Yukihiro Matsumoto . You can redistribute it and/or modify it under either the terms of the GPL (see the file GPL), or the conditions below. I'd just change the License to GPL since more people are familiar with it. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rdieter at math.unl.edu Fri Feb 3 20:22:59 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 03 Feb 2006 14:22:59 -0600 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: <87k6ccs4fu.fsf@kosh.bigo.ensc.de> References: <87k6ccs4fu.fsf@kosh.bigo.ensc.de> Message-ID: Enrico Scholz wrote: > rdieter at math.unl.edu (Rex Dieter) writes: >>respectively, but the "GTK+ icon cache" section says (rightfully) >>"Note that no dependencies should be added for this". > This section is wrong. Instead of, it should state that: Consider this too: * Packages that own/create the parent icon theme directories should include in %files (something like): %ghost %{_datadir}/icons//icon-theme.cache Else, this (and the folder) gets left behind on icon_theme removal. Of course, gtk-update-icon-cache could have been created to put the cache somewhere else/better, like under /var/cache, and we wouldn't have had to worry about it. -- Rex From bugzilla at redhat.com Fri Feb 3 20:31:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 15:31:30 -0500 Subject: [Bug 179818] Review Request: xpilot-ng - A mutiplayer space arcade game In-Reply-To: Message-ID: <200602032031.k13KVUdI020470@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xpilot-ng - A mutiplayer space arcade game https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179818 ------- Additional Comments From wart at kobold.org 2006-02-03 15:31 EST ------- Yet another minor update: I added the readme and license files to the server subpackage. I also added the missing %defattr() line for the server subpackage. http://www.kobold.org/~wart/fedora/xpilot-ng-4.7.2-3.src.rpm http://www.kobold.org/~wart/fedora/xpilot-ng.spec -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 3 20:39:50 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 03 Feb 2006 21:39:50 +0100 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: (Rex Dieter's message of "Fri, 03 Feb 2006 13:49:17 -0600") References: <87k6ccs4fu.fsf@kosh.bigo.ensc.de> Message-ID: <87fyn0rxbd.fsf@kosh.bigo.ensc.de> rdieter at math.unl.edu (Rex Dieter) writes: >> * 'Requires(post): gtk2' shall be added for packages shipping icons and >> requiring gtk2 (e.g. typical Gnome2 applications) > > I disagree. This would be (mostly?) pointless. The pkgs in question > already implicitly require gtk2 already, why add the bloat? There is a difference between Requires(post): and a plain Requires:. The first statement guarantees that the cache will be created, the latter might miss to create it. >> Else, when you have a installation sequence of >> 1. package-A >> 2. gtk2 >> with package-A shipping icons, you will get a 5-10 startup penalty >> for every gtk2 application because the icon cache is outdated and >> 'gtk-update-icon-cache' was not executed. > > That's why gtk2 should include it's own %post scriptlet: > http://bugzilla.redhat.com/170335 Just for completeness (it is stated from the bugreport): A cronjob which updates content under /usr regularly, sounds like a really bad idea to me. When the caching would be changed to look for the icon-cache under /var, it would be fine with me. A quick&dirty (or well-designed&clean) solutions might be symlinks like /usr/share/icons/.../.icon-cache -> /var/cache/icon-cache/usr_share_icons_..._icon-cache and 'gtk-update-icon-cache' writes either directly into this file or reads the symlink and recreates it. Else, are you sure that all possible icon-directories can be enumerated in this way? (thtat's not a critic, I just do not know it ;)) Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From toshio at tiki-lounge.com Fri Feb 3 20:49:15 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 03 Feb 2006 12:49:15 -0800 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: References: <1138905153.3411.34.camel@localhost> Message-ID: <1138999755.3377.22.camel@localhost> On Thu, 2006-02-02 at 15:14 -0600, Rex Dieter wrote: > Toshio Kuratomi wrote: > > Do shared-mime-info and desktop-file-utils fall into the same category > > or does some functionality of programs fail to work if > > desktop-file-utils and shared-mime-info aren't run? > > The latter. > > > Your post makes me think that some Core GNOME applications (nautilus? > > gnome-panel? gnome-vfs?) make use of the data generated by > > desktop-file-utils and shared-mime-info but nothing else. Is that true > > or just a guess? > > Gnome in general, yes. That's why I'm arguing it should be the GNOME > libs/core bits that should depend on these, not (all) individual apps. > If I'm reading your responses correctly, shared-mime-info and desktop-file-utils must be run in order for Core Gnome to function correctly. However, the application itself can run under KDE or another environment with no errors or loss of functionality. I don't see a problem with changing the shared-mime-info section if that's the case. (shared-mime-info's dependencies percolate through to libgnome which should be required by anything depending on it and it does have a scriptlet to update on install.) dekstop-file-utils doesn't seem to have either a dependency into the Core of Gnome or a scriptlet to care for the case where it is installed later so even though this seems like a valid concept, those issues should be resolved first. > > shared-mime-info seems to run itself on installation and update but > > desktop-file-utils does not. If desktop-file-utils is made optional for > > the scriptlets, the desktop-file-utils Core package should run itself on > > install. > > I'm not arguing that running them should be optional, only that the > additional dependancies for them not be added/Required. > This is what I mean: No Requires line. Scriptlet contains a call to the mime/desktop-file utility that does not fail if they are not available on install/uninstall. I assume we're on the same page but stumbling over my imprecise wording? > > (Hmm.. gtk2 doesn't run gtk-update-icon-cache on install... is > > this a packaging bug? > > IMO, yes. > > >Or perhaps this bug would resolve it: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170335 > > Yes too. (that's my bug). I saw :-) Thanks for adding the update to add a scriptlet as well. -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 bugzilla at redhat.com Fri Feb 3 20:45:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 15:45:52 -0500 Subject: [Bug 179916] New: Review Request: docbook2X - Convert docbook into man and Texinfo Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179916 Summary: Review Request: docbook2X - Convert docbook into man and Texinfo Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: pertusus at free.fr QAContact: fedora-extras-list at redhat.com SRPM Name or Url:http://www.environnement.ens.fr/perso/dumas/fc-srpms/docbook2X-0.8.5-1.src.rpm Description: docbook2X converts DocBook documents into man pages and Texinfo documents. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From orion at cora.nwra.com Fri Feb 3 20:55:25 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 03 Feb 2006 13:55:25 -0700 Subject: Please help comment on hdf/netcdf compatability Message-ID: <43E3C33D.3030403@cora.nwra.com> I maintain hdf 4.2r1 in FE. I'm running into an issue with compatibility with netcdf. By default, hdf provides the netcdf api as well, unless compiled with -DHAVE_NETCDF. I also maintain gdl, which can be linked against both hdf and netcdf, but I get complaints. I don't know if gdl can use the netcdf API in the hdf library or not - looking into it (if you know, tell me!). Those of you who use both, what would you like to see? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From toshio at tiki-lounge.com Fri Feb 3 20:58:31 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 03 Feb 2006 12:58:31 -0800 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: <87fyn0rxbd.fsf@kosh.bigo.ensc.de> References: <87k6ccs4fu.fsf@kosh.bigo.ensc.de> <87fyn0rxbd.fsf@kosh.bigo.ensc.de> Message-ID: <1139000311.3377.32.camel@localhost> On Fri, 2006-02-03 at 21:39 +0100, Enrico Scholz wrote: > rdieter at math.unl.edu (Rex Dieter) writes: > > >> * 'Requires(post): gtk2' shall be added for packages shipping icons and > >> requiring gtk2 (e.g. typical Gnome2 applications) > > > > I disagree. This would be (mostly?) pointless. The pkgs in question > > already implicitly require gtk2 already, why add the bloat? > > There is a difference between Requires(post): and a plain Requires:. The > first statement guarantees that the cache will be created, the latter > might miss to create it. > What if gtk's %post has a script to invoke the icon cache? Then installation order could be either: package-with-icons => icon cache creation fails. gtk => icon cache creation succeeds. or: gtk => icon cache created package-with-icons => icon cache update succeeds Or am I misunderstanding how gtk-update-icon-cache works? I realize it doesn't work this way currently... Rex's bugzilla includes a request to add that to gtk's %post. For releases before gtk is changed, what do you think is the best fix? The three step process you outline (which involves triggers which are always nice to avoid) or change something else? -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 bugzilla at redhat.com Fri Feb 3 20:54:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 15:54:16 -0500 Subject: [Bug 178604] Review Request: ruby-mysql In-Reply-To: Message-ID: <200602032054.k13KsGPn025604@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ruby-mysql https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178604 ------- Additional Comments From oliver.andrich at gmail.com 2006-02-03 15:54 EST ------- Spec Name or Url: http://roughbook.de/fedora/ruby-mysql.spec SRPM Name or Url: http://roughbook.de/fedora/ruby-mysql-2.7-5.src.rpm As just discussed in #fedora-extras I switched to GPL as the licence, cause this is what the Packaging Guidelines tell in case of dual licensed software. I also included the license files. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From ed at eh3.com Fri Feb 3 21:11:15 2006 From: ed at eh3.com (Ed Hill) Date: Fri, 03 Feb 2006 16:11:15 -0500 Subject: Please help comment on hdf/netcdf compatability In-Reply-To: <43E3C33D.3030403@cora.nwra.com> References: <43E3C33D.3030403@cora.nwra.com> Message-ID: <1139001075.15027.344.camel@ernie> On Fri, 2006-02-03 at 13:55 -0700, Orion Poplawski wrote: > I maintain hdf 4.2r1 in FE. I'm running into an issue with > compatibility with netcdf. By default, hdf provides the netcdf api as > well, unless compiled with -DHAVE_NETCDF. > > I also maintain gdl, which can be linked against both hdf and netcdf, > but I get complaints. I don't know if gdl can use the netcdf API in the > hdf library or not - looking into it (if you know, tell me!). > > Those of you who use both, what would you like to see? Hi Orion, I don't have an opinion here since I rarely use hdf4 and have yet to try gdl (although it sounds cool and useful--just haven't had enough spare time to examine it!). In any case, if there is anything that I can do to help (eg. with the netcdf package) please let me know. 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 bugzilla at redhat.com Fri Feb 3 21:12:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 16:12:56 -0500 Subject: [Bug 178604] Review Request: ruby-mysql In-Reply-To: Message-ID: <200602032112.k13LCuGJ029250@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ruby-mysql https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178604 ------- Additional Comments From imlinux at gmail.com 2006-02-03 16:12 EST ------- Found something else, this package creates /usr/lib/site_ruby/1.8/i386-linux/mysql.so Because it doesn't own those directories it leaves /usr/lib/site_ruby/1.8/i386-linux/ when you remove the package. Also aren't most ruby libraries located in /usr/lib/ruby/? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 3 21:17:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 16:17:18 -0500 Subject: [Bug 168838] Review Request: cpanspec In-Reply-To: Message-ID: <200602032117.k13LHI9K029975@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cpanspec https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168838 orion at cora.nwra.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From orion at cora.nwra.com 2006-02-03 16:17 EST ------- Good: - rpmlint checks return: - package meets naming guidelines - package meets packaging guidelines - license (GPL/Artistic) OK, text in %doc, matches source - spec file legible, in am. english - source matches upstream - package compiles on devel (x86) - no missing BR - no unnecessary BR - no locales - not relocatable - owns all directories that it creates - no duplicate files - permissions ok - %clean ok - macro use consistent - code, not content - no need for -docs - nothing in %doc affects runtime - no need for .desktop file Approved -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 3 21:17:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 16:17:48 -0500 Subject: [Bug 178951] Review Request: modules - Provides dynamic modification of a user's environment In-Reply-To: Message-ID: <200602032117.k13LHmpm030066@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: modules - Provides dynamic modification of a user's environment https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178951 ------- Additional Comments From orion at cora.nwra.com 2006-02-03 16:17 EST ------- Okay, so it looks like "modules" is obsoleted by module-init-tools, so I've changed the name to environment-modules. Looks like upstream is missing a copy of the GPL with the tarball, so I'm sending a message about fixing that. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 3 21:34:29 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 16:34:29 -0500 Subject: [Bug 178604] Review Request: ruby-mysql In-Reply-To: Message-ID: <200602032134.k13LYT7j001529@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ruby-mysql https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178604 ------- Additional Comments From oliver.andrich at gmail.com 2006-02-03 16:34 EST ------- Yes, this intended behaviour, cause /usr/lib/site_ruby/1.8/i386-linux/ is owned by the ruby-libs package. This package is required anyway, cause my package requires libruby.so.1.8 which is provided by the package ruby-libs. So I think, I don'T need to explicitly require ruby-libs. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From jspaleta at gmail.com Fri Feb 3 21:39:32 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 3 Feb 2006 16:39:32 -0500 Subject: FE package status Thu Feb 2 2006 In-Reply-To: <200602021655.k12GtJYb003950@ludwig-alpha.unil.ch> References: <200602021655.k12GtJYb003950@ludwig-alpha.unil.ch> Message-ID: <604aa7910602031339h482216a8ocd2dff851d438792@mail.gmail.com> On 2/2/06, Christian.Iseli at licr.org wrote: > We have 80 packages not available in extras devel: Can you explain how are you producing this list? I think perhaps you need to seperate items which are not available in both devel and latest release from those which are not available just in devel... it might help in the determination of the underlying package state and whether this is just a janitorial issue or if there is a build problem that needs to be investigated by interested contributors. Several things sort of jump out as odd... initng is in the list why? This hasn't even passed review and I dont see it in the owners list There are several things that aren't even built for fc4 in your list. Either they are orphaned or they are no longer needed and have been replaced by other functionality freenx and nx are in the list why? These have cvs entries but aren't even built in the fc4 package tree afaict. Are we even sure this passed review? Was this ever built in FE? wxPython is in the list why? wxPythonGTK2 now exists which provides wxPython Its not in fc4 either. repoquery -q --provides wxPythonGTK2 ... wxPython = 2.4.2.4-7 wxPythonGTK2 = 2.4.2.4-7 ... gnome-applet-netmon.. not currently build for fc4 either.. was this ever built inside FE? -jef From bugzilla at redhat.com Fri Feb 3 21:59:41 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 16:59:41 -0500 Subject: [Bug 178604] Review Request: ruby-mysql In-Reply-To: Message-ID: <200602032159.k13LxfKd007351@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ruby-mysql https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178604 imlinux at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From imlinux at gmail.com 2006-02-03 16:59 EST ------- Got'cha. No problem there then: -rpmlint: No output -Meets Naming Guidelines -%{name}.spec matches -License is GPL and a COPYING file is included stating that fact -SPEC is written in english -SPEC file is easy to follow -Source matches Upstream -Compiles successfully in Mock -Only required build requres listed -No duplicate build requires -locales unused (not needed) -included libraries are not located in dynamic linker's default paths -No duplicate files -Owns all directories it creates: doesn't actually create any dirs -does not have any devel packages (does not need them) ACCEPTED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 3 22:00:57 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 17:00:57 -0500 Subject: [Bug 179904] Review Request: icecast In-Reply-To: Message-ID: <200602032200.k13M0vlZ007661@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: icecast https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179904 ------- Additional Comments From andreas at bawue.net 2006-02-03 17:00 EST ------- I do have a local ices package. That could be cleaned up and included in extras. However, if libshout is too old, we should probably skip that, and just wait for FC5, which should be round to corner. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From Christian.Iseli at licr.org Fri Feb 3 22:19:02 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 03 Feb 2006 23:19:02 +0100 Subject: FE package status Thu Feb 2 2006 In-Reply-To: Your message of "Fri, 03 Feb 2006 16:39:32 EST." <604aa7910602031339h482216a8ocd2dff851d438792@mail.gmail.com> Message-ID: <200602032219.k13MJ5ho007245@mx1.redhat.com> jspaleta at gmail.com said: > Can you explain how are you producing this list? Using the parseBZbugList.pl script available on the UsefulScripts wiki page :-) (sorry, couldn't resist...) Basically: 1. extract all package names from owners.list 2. extract all available packages from the devel repo 3. subtract 1 - 2 and print it (if it's not orphaned in this case)... > I think perhaps you need to seperate items which are not available in both > devel and latest release from those which are not available just in devel... Could do. My idea was to make sure devel is in good shape, as FC5 is around the corner... > it might help in the determination of the underlying package state and > whether this is just a janitorial issue or if there is a build problem that > needs to be investigated by interested contributors. Yes, I could make two lists: - not in latest, not in devel - present in latest, but not in devel > Several things sort of jump out as odd... initng is in the list why? Because it's in the owners.list file: $ grep initng owners.list Fedora Extras|initng|A full replacement of SysVinit|daner964 at student.liu.se|extras-qa at fedoraproject.org| > This hasn't even passed review and I dont see it in the owners list Well it is in mine: $ cvs stat For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs =================================================================== File: owners.list Status: Up-to-date Working revision: 1.603 Repository revision: 1.603 /cvs/extras/owners/owners.list,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) > There are several things that aren't even built for fc4 in your list. Either > they are orphaned or they are no longer needed and have been replaced by > other functionality I started a discarded packages list, also available on the wiki page. > freenx and nx are in the list why? No idea, but they are in owners.list > These have cvs entries but aren't even > built in the fc4 package tree afaict. Are we even sure this passed review? > Was this ever built in FE? No idea. > wxPython is in the list why? 'cause it's in owners.list. > wxPythonGTK2 now exists which provides wxPython > Its not in fc4 either. repoquery -q --provides wxPythonGTK2 ... wxPython = > 2.4.2.4-7 wxPythonGTK2 = 2.4.2.4-7 ... Yes, I guess it's a good candidate for my discarded package list... > gnome-applet-netmon.. not currently build for fc4 either.. was this ever > built inside FE? dunno. Thanks for your comments. Cheers, Christian From bugzilla at redhat.com Fri Feb 3 22:23:04 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 17:23:04 -0500 Subject: [Bug 179758] Review Request: Eiciel (ACL editor) In-Reply-To: Message-ID: <200602032223.k13MN4Ik011163@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Eiciel (ACL editor) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179758 ------- Additional Comments From fedora at adslpipe.co.uk 2006-02-03 17:23 EST ------- Ok, final update for tonight, all files updated on website 64bit machine ============= # rpmlint -v RPMS/x86_64/eiciel-0.9-7.x86_64.rpm I: eiciel checking # rpmlint -v RPMS/x86_64/eiciel-debuginfo-0.9-7.x86_64.rpm I: eiciel-debuginfo checking W: eiciel-debuginfo objdump-failed # rpmlint -v SRPMS/eiciel-0.9-7.src.rpm I: eiciel checking I notice a error to do with extraxting debug information /usr/lib/rpm/find-debuginfo.sh /usr/src/redhat/BUILD/eiciel-0.9 extracting debug info from /var/tmp/eiciel-0.9-7-root-root/usr/bin/eiciel extracting debug info from /var/tmp/eiciel-0.9-7-root-root/usr/lib64/nautilus/extensions-1.0/libeiciel-nautilus.so.0.0.0 cpio: eiciel-0.9/src/: No such file or directory 227 blocks I though this was due to not havinf 755 permissions on the .so* file but I can't seem to get rid of it. 32bit machine ============= # rpmlint -v RPMS/i386/eiciel-0.9-7.i386.rpm I: eiciel checking W: eiciel unstripped-binary-or-object /usr/lib/debug/usr/lib/nautilus/extensions-1.0/libeiciel-nautilus.so.0.0.0.debug W: eiciel objdump-failed W: eiciel unstripped-binary-or-object /usr/lib/debug/usr/bin/eiciel.debug E: eiciel statically-linked-binary /usr/lib/debug/usr/bin/eiciel.debug # rpmlint -v RPMS/i386/eiciel-debuginfo-0.9-7.i386.rpm I: eiciel-debuginfo checking W: eiciel-debuginfo objdump-failed # rpmlint -v SRPMS/eiciel-0.9-7.src.rpm I: eiciel checking Desktop Icon ============ Is the way I use "install" to copy the .png icon clean enough? The eiciel icon appears under "Other" on the Applications menu, presumble I need to change the way I use "desktop-file-install"? Mock ==== Still not tried building in mock Other ===== Any answers/hints/comments on my questions in my "self review" welcome -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From jspaleta at gmail.com Fri Feb 3 22:29:56 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 3 Feb 2006 17:29:56 -0500 Subject: FE package status Thu Feb 2 2006 In-Reply-To: <200602032219.k13MJ5ho007245@mx1.redhat.com> References: <604aa7910602031339h482216a8ocd2dff851d438792@mail.gmail.com> <200602032219.k13MJ5ho007245@mx1.redhat.com> Message-ID: <604aa7910602031429i6d0a6eaaq60db810b5e89eb86@mail.gmail.com> On 2/3/06, Christian.Iseli at licr.org wrote: > Because it's in the owners.list file: > $ grep initng owners.list > Fedora Extras|initng|A full replacement of SysVinit|daner964 at student.liu.se|extras-qa at fedoraproject.org| > > > This hasn't even passed review and I dont see it in the owners list > > Well it is in mine: > $ cvs stat yeah i had a stale one sorry. -jef From bugzilla at redhat.com Fri Feb 3 22:32:58 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 17:32:58 -0500 Subject: [Bug 179910] Review Request: commoncpp C++ framework In-Reply-To: Message-ID: <200602032232.k13MWwIw013044@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: commoncpp C++ framework https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179910 ------- Additional Comments From andreas at bawue.net 2006-02-03 17:32 EST ------- Note: The package name was changed after this bug was filed to commoncpp2. It seems the gnu people refer to the software as commoncpp, even though the tarball is named commoncpp2. As the library is named commoncpp2-*.so as well, this is probably a more sensible name. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From eric.tanguy at univ-nantes.fr Fri Feb 3 22:41:01 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Fri, 03 Feb 2006 23:41:01 +0100 Subject: How to make a selective spec file In-Reply-To: References: <1138994941.2953.5.camel@bureau.maison> Message-ID: <1139006461.3158.2.camel@bureau.maison> Le vendredi 03 f?vrier 2006 ? 13:42 -0600, Rex Dieter a ?crit : > Eric Tanguy wrote: > > I would like to make only one spec taking into account the system build > > is devel/fc5 or fc3/fc4. > > How to make this ? > > In devel/fc5 i need to have : > > %configure CXXFLAGS="${RPM_OPT_FLAGS} -ffriend-injection" > > and in fc3/fc4 i need to have : > > %configure > > Something like this ought to do the trick: > > %if "%{?fedora}" > "4" > CXXFLAGS="${RPM_OPT_FLAGS} -ffriend-injection" > %endif > %configure It seems it's not taken into account for devel. How to know what %{?fedora} returns for devel ? Eric From rdieter at math.unl.edu Fri Feb 3 22:51:52 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 03 Feb 2006 16:51:52 -0600 Subject: How to make a selective spec file In-Reply-To: <1139006461.3158.2.camel@bureau.maison> References: <1138994941.2953.5.camel@bureau.maison> <1139006461.3158.2.camel@bureau.maison> Message-ID: Eric Tanguy wrote: >>Something like this ought to do the trick: >> >>%if "%{?fedora}" > "4" >>CXXFLAGS="${RPM_OPT_FLAGS} -ffriend-injection" >>%endif >>%configure > > It seems it's not taken into account for devel. How to know what > %{?fedora} returns for devel ? AFAIK, on devel, %fedora expands to 5 in buildsys-macros -- Rex From eric.tanguy at univ-nantes.fr Fri Feb 3 22:49:39 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Fri, 03 Feb 2006 23:49:39 +0100 Subject: How to make a selective spec file In-Reply-To: References: <1138994941.2953.5.camel@bureau.maison> <1139006461.3158.2.camel@bureau.maison> Message-ID: <1139006979.3158.10.camel@bureau.maison> Le vendredi 03 f?vrier 2006 ? 16:51 -0600, Rex Dieter a ?crit : > Eric Tanguy wrote: > > >>Something like this ought to do the trick: > >> > >>%if "%{?fedora}" > "4" > >>CXXFLAGS="${RPM_OPT_FLAGS} -ffriend-injection" > >>%endif > >>%configure > > > > It seems it's not taken into account for devel. How to know what > > %{?fedora} returns for devel ? > > AFAIK, on devel, %fedora expands to 5 in buildsys-macros > > -- Rex > Maybe in buildsys but i'm trying to build it on a fc4 box using mock : mock -r fedora-5-i386-core foobar.spec and it seems to not be taken into account : configure: running /bin/sh './configure' --prefix=/usr '--build=i686-redhat-linux-gnu' '--host=i686-redhat-linux-gnu' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables' 'CXXFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables' 'build_alias=i686-redhat-linux-gnu' 'host_alias=i686-redhat-linux-gnu' 'target_alias=i386-redhat-linux-gnu' --cache-file=/dev/null --srcdir=. Eric From bugzilla at redhat.com Fri Feb 3 23:13:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 18:13:44 -0500 Subject: [Bug 179940] New: Review Request: ruby-http-access2 Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179940 Summary: Review Request: ruby-http-access2 Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: oliver.andrich at gmail.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://roughbook.de/fedora/ruby-http-access2.spec SRPM Name or Url: http://roughbook.de/fedora/ruby-http-access2-2.0.6-1.src.rpm Description: http-access2 gives something like the functionality of libwww-perl (LWP) in Ruby. Features: * methods like GET/HEAD/POST via HTTP/1.1. * asynchronous HTTP request * HTTPS(SSL) * by contrast with net/http in standard distribution; o you don't have to care HTTP/1.1 persistent connection (http-access2 cares instead of you). o MT-safe o streaming POST o Cookies Required for using basic authentication with SOAP4R. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 3 23:30:05 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 18:30:05 -0500 Subject: [Bug 178901] Review Request: gtksourceview-sharp In-Reply-To: Message-ID: <200602032330.k13NU5Vb023323@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gtksourceview-sharp https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178901 ------- Additional Comments From rowan at stasis.org 2006-02-03 18:29 EST ------- /usr/bin/mcs /unsafe /target:library /pkg:gnome-sharp-2.0 \ generated/*.cs ./GtkSourceView.cs AssemblyInfo.cs -out:gtksourceview-sharp.dll error CS2001: Source file `generated/*.cs' could not be found Compilation failed: 1 error(s), 0 warnings make[1]: *** [gtksourceview-sharp.dll] Error 1 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 3 23:30:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 18:30:34 -0500 Subject: [Bug 178900] Review Request: monodoc In-Reply-To: Message-ID: <200602032330.k13NUYAH023421@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: monodoc https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178900 ------- Additional Comments From rowan at stasis.org 2006-02-03 18:30 EST ------- Builds and installs without errors. (on rawhide) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 3 23:32:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 18:32:08 -0500 Subject: [Bug 178903] Review Request: ikvm In-Reply-To: Message-ID: <200602032332.k13NW87m023791@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ikvm https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178903 ------- Additional Comments From rowan at stasis.org 2006-02-03 18:31 EST ------- Builds and installs OK. (On fc5t2 upgraded to today's rawhide). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 3 23:33:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 18:33:34 -0500 Subject: [Bug 178904] Review Request: Monodevelop In-Reply-To: Message-ID: <200602032333.k13NXYPk024104@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Monodevelop https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178904 ------- Additional Comments From rowan at stasis.org 2006-02-03 18:33 EST ------- Can't build until gtksourceview-sharp (#178900) is installed. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From gajownik at fedora.pl Fri Feb 3 23:53:09 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Sat, 04 Feb 2006 00:53:09 +0100 Subject: How to downgrade version of a program? Message-ID: <43E3ECE5.8010705@fedora.pl> Hi! I've done a really stupid thing - I've been testing python-sqlite2 mainly on Rawhide and did not notice that newer version does not work on FC-4 (sqlite is too old). Now I need to downgrade it to 2.0.7. I tried to do something like in this thread ? https://www.redhat.com/archives/fedora-packaging/2005-June/msg00002.html but yum or rpm did not replace python-sqlite2-2.1.0-1.fc4 with python-sqlite2-2.0.7-1. Is Epoch bump the only solution? Regards, Dawid -- ^_* From bugzilla at redhat.com Sat Feb 4 00:08:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 19:08:28 -0500 Subject: [Bug 178904] Review Request: Monodevelop In-Reply-To: Message-ID: <200602040008.k1408SB9029666@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Monodevelop https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178904 fedora at adslpipe.co.uk changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fedora at adslpipe.co.uk ------- Additional Comments From fedora at adslpipe.co.uk 2006-02-03 19:08 EST ------- Re comment #1 - it built ok for me with mono-develop as the only dependency I needed to satisfy. A bit heavy going for a specfile & mono newbie, but here goes for what it's worth ... - MUST: rpmlint must be run on every package. The output should be posted in the review. # rpmlint -v RPMS/i386/monodoc-1.1.9-2.i386.rpm I: monodoc checking E: monodoc no-binary E: monodoc only-non-binary-in-usr-lib I pulled the rpm apart with rpm2cpio | cpio -id and had a look inside I presume the no-binary is because it produces PE rather than ELF executables? What do beagle/fspot do in this case? W: monodoc no-documentation Ironic! W: monodoc devel-file-in-non-devel-package /usr/lib/pkgconfig/monodoc.pc Don't know what this is, so no clue why rpmlint moans about it # rpmlint -v RPMS/i386/monodoc-debuginfo-1.1.9-2.i386.rpm I: monodoc-debuginfo checking OK # rpmlint -v SRPMS/monodoc-1.1.9-2.src.rpm I: monodoc checking E: monodoc hardcoded-library-path in %{buildroot}/usr/lib/mono/gac E: monodoc hardcoded-library-path in %{buildroot}/usr/lib within %install any reason you've used some with /usr/lib instead of %{_libdir} ? e.g. %{__mkdir} -p %{buildroot}%{_libdir}/pkgconfig %{__mkdir} -p %{buildroot}/usr/lib/mono/gac E: monodoc hardcoded-library-path in /usr/lib/mono/gac/monodoc E: monodoc hardcoded-library-path in /usr/lib/mono/monodoc/monodoc.dll similar from %files shodle these be %{_libdir} too? /usr/lib/mono/gac/monodoc /usr/lib/mono/monodoc/monodoc.dll - MUST: The package must be named according to the Package Naming Guidelines. OK - MUST: The spec file name must match the base package %{name}, in the format %{name}.spec OK - MUST: The package must meet the Packaging Guidelines. NOT CHECKED - MUST: The package must be licensed with an open-source compatible license and meet other legal requirements as defined in the legal section of Packaging Guidelines. "COPYING" file shows GPL If REDHAT can't comment about legal matters on mono/.net I'm sure I'm not qualified to :-( In general found individual sorce fiels didn't have licence info contained - MUST: The License field in the package spec file must match the actual license. GPL in .spec and "COPYING" - MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc. No %doc in %files, shoul dit be added and COPYING placed there? - MUST: The spec file must be written in American English. Didn't spot any Britishisms ;-) - MUST: The spec file for the package MUST be legible. Clean - MUST: The sources used to build the package must match the upstream source # md5sum /usr/src/redhat/SOURCES/monodoc-1.1.9.tar.gz 2b8548b7160c1f3124c9f7b8f2044a88 /usr/src/redhat/SOURCES/monodoc-1.1.9.tar.gz # wget -O upstream.tgz http://go-mono.com/sources/monodoc/monodoc-1.1.9.tar.gz --23:35:38-- http://go-mono.com/sources/monodoc/monodoc-1.1.9.tar.gz => `upstream.tgz' Resolving go-mono.com... 64.14.94.188 Connecting to go-mono.com|64.14.94.188|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 17,328,634 (17M) [application/x-gzip] 100%[==================================================================================================>] 17,328,634 111.94K/s ETA 00:00 23:38:09 (111.73 KB/s) - `upstream.tgz' saved [17328634/17328634] # md5sum /root/upstream.tgz 2b8548b7160c1f3124c9f7b8f2044a88 /root/upstream.tgz OK - MUST: The package must successfully compile and build into binary rpms on at least one supported architecture. OK for me on i386 FAILED to compile for me on x86_64 (likely flaky mono on my machine beagle is acting up to) - MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch needs to have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number should then be placed in a comment, next to the corresponding ExcludeArch line. New packages will not have bugzilla entries during the review process, so they should put this description in the comment until the package is approved, then file the bugzilla entry, and replace the long explanation with the bug number. The bug should be marked as blocking one (or more) of the following bugs to simplify tracking such issues: [WWW] FE-ExcludeArch-x86, [WWW] FE-ExcludeArch-x64, [WWW] FE-ExcludeArch-ppc NOT CHECKED - MUST: A package must not contain any BuildRequires that are listed in the exceptions section of Packaging Guidelines. OK - MUST: All other Build dependencies must be listed in BuildRequires. SEEMED OK, I had to install mono-devel - MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden. NO /locale/* files at all, not sure if monodoc has any i18n at all - MUST: If the package contains shared library files located in the dynamic linker's default paths, No .so files, whether it needs to do anything similar with it's .dll files I don't know - MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. Dont think so - MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. The exception to this are directories listed explicitly in the Filesystem Hierarchy Standard ([WWW] http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to assume that those directories exist. Not checked - MUST: A package must not contain any duplicate files in the %files listing. No wildcards used at all, disn't spot any dupes - MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. No %defattr, can't see a reason why it would hurt to have one - MUST: Each package must have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). yes - MUST: Each package must consistently use macros, as described in the macros section of Packaging Guidelines. yes - MUST: The package must contain code, or permissable content. This is described in detail in the code vs. content section of Packaging Guidelines. seems OK, rpmlint doesn't acknowledge PE as code, but it plainly is also the actual monodoc content seems to be in xml bundles - MUST: Large documentation files should go in a -docs subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity) This *is* a docs package - MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. No %doc at all at present, should be fixed - MUST: Header files or static libraries must be in a -devel package. Didn't check - MUST: Files used by pkgconfig (.pc files) must be in a -devel package. There is a monodoc.pc file being packaged, I don't kneo if ".pc" files are significant in some other way (apart from pgkconfig) to mono? - MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. No .so files - MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency. No separate -devel - MUST: Packages must NOT contain any .la libtool archives, these should be removed in the spec. No .la files - MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. This is described in detail in the desktop files section of Packaging Guidelines. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. No .desktop file, unclear to me now if monodocs actually displays docs, in GUI, or just prepares thenm for later display, or browser based display. - MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora Extras should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. Didn't check - SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. It does include separate licence file - SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available. No extra translations provided - SHOULD: The reviewer should test that the package builds in mock. not done - SHOULD: The package should compile and build into binary rpms on all supported architectures. Only done on i386, tried and failed on x86_64 (probably not this packages fault) - SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example. Installed ok in i386 machine that was used to build no info how to start, or what it should do I tried "mono mod.exe" at least it gave a polite error rather than crashing - SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity. None used - SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency. None -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 00:13:31 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 19:13:31 -0500 Subject: [Bug 178901] Review Request: gtksourceview-sharp In-Reply-To: Message-ID: <200602040013.k140DVH7030469@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gtksourceview-sharp https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178901 ------- Additional Comments From paul at all-the-johnsons.co.uk 2006-02-03 19:13 EST ------- Which version of gtksourceview and gtksourceview-devel have you got installed? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 00:14:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 19:14:30 -0500 Subject: [Bug 178901] Review Request: gtksourceview-sharp In-Reply-To: Message-ID: <200602040014.k140EUmL030713@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gtksourceview-sharp https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178901 ------- Additional Comments From paul at all-the-johnsons.co.uk 2006-02-03 19:14 EST ------- And more over, which versions of gtksharp2 and mono-core -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 00:14:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 19:14:59 -0500 Subject: [Bug 178900] Review Request: monodoc In-Reply-To: Message-ID: <200602040014.k140Ex3G030822@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: monodoc https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178900 fedora at adslpipe.co.uk changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fedora at adslpipe.co.uk ------- Additional Comments From fedora at adslpipe.co.uk 2006-02-03 19:14 EST ------- Rowan, did you just mid klight collide over the top of my >10K review ? :-( -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 00:16:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 19:16:27 -0500 Subject: [Bug 178900] Review Request: monodoc In-Reply-To: Message-ID: <200602040016.k140GRw0031007@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: monodoc https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178900 ------- Additional Comments From fedora at adslpipe.co.uk 2006-02-03 19:16 EST ------- I would have been *MIGHTY PEEVED OFF* if I han't kept a copy of it pasted somewhere else :-) - MUST: rpmlint must be run on every package. The output should be posted in the review. # rpmlint -v RPMS/i386/monodoc-1.1.9-2.i386.rpm I: monodoc checking E: monodoc no-binary E: monodoc only-non-binary-in-usr-lib I pulled the rpm apart with rpm2cpio | cpio -id and had a look inside I presume the no-binary is because it produces PE rather than ELF executables? What do beagle/fspot do in this case? W: monodoc no-documentation Ironic! W: monodoc devel-file-in-non-devel-package /usr/lib/pkgconfig/monodoc.pc Don't know what this is, so no clue why rpmlint moans about it # rpmlint -v RPMS/i386/monodoc-debuginfo-1.1.9-2.i386.rpm I: monodoc-debuginfo checking OK # rpmlint -v SRPMS/monodoc-1.1.9-2.src.rpm I: monodoc checking E: monodoc hardcoded-library-path in %{buildroot}/usr/lib/mono/gac E: monodoc hardcoded-library-path in %{buildroot}/usr/lib within %install any reason you've used some with /usr/lib instead of %{_libdir} ? e.g. %{__mkdir} -p %{buildroot}%{_libdir}/pkgconfig %{__mkdir} -p %{buildroot}/usr/lib/mono/gac E: monodoc hardcoded-library-path in /usr/lib/mono/gac/monodoc E: monodoc hardcoded-library-path in /usr/lib/mono/monodoc/monodoc.dll similar from %files shodle these be %{_libdir} too? /usr/lib/mono/gac/monodoc /usr/lib/mono/monodoc/monodoc.dll - MUST: The package must be named according to the Package Naming Guidelines. OK - MUST: The spec file name must match the base package %{name}, in the format %{name}.spec OK - MUST: The package must meet the Packaging Guidelines. NOT CHECKED - MUST: The package must be licensed with an open-source compatible license and meet other legal requirements as defined in the legal section of Packaging Guidelines. "COPYING" file shows GPL If REDHAT can't comment about legal matters on mono/.net I'm sure I'm not qualified to :-( In general found individual sorce fiels didn't have licence info contained - MUST: The License field in the package spec file must match the actual license. GPL in .spec and "COPYING" - MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc. No %doc in %files, shoul dit be added and COPYING placed there? - MUST: The spec file must be written in American English. Didn't spot any Britishisms ;-) - MUST: The spec file for the package MUST be legible. Clean - MUST: The sources used to build the package must match the upstream source # md5sum /usr/src/redhat/SOURCES/monodoc-1.1.9.tar.gz 2b8548b7160c1f3124c9f7b8f2044a88 /usr/src/redhat/SOURCES/monodoc-1.1.9.tar.gz # wget -O upstream.tgz http://go-mono.com/sources/monodoc/monodoc-1.1.9.tar.gz --23:35:38-- http://go-mono.com/sources/monodoc/monodoc-1.1.9.tar.gz => `upstream.tgz' Resolving go-mono.com... 64.14.94.188 Connecting to go-mono.com|64.14.94.188|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 17,328,634 (17M) [application/x-gzip] 100%[==================================================================================================>] 17,328,634 111.94K/s ETA 00:00 23:38:09 (111.73 KB/s) - `upstream.tgz' saved [17328634/17328634] # md5sum /root/upstream.tgz 2b8548b7160c1f3124c9f7b8f2044a88 /root/upstream.tgz OK - MUST: The package must successfully compile and build into binary rpms on at least one supported architecture. OK for me on i386 FAILED to compile for me on x86_64 (likely flaky mono on my machine beagle is acting up to) - MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch needs to have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number should then be placed in a comment, next to the corresponding ExcludeArch line. New packages will not have bugzilla entries during the review process, so they should put this description in the comment until the package is approved, then file the bugzilla entry, and replace the long explanation with the bug number. The bug should be marked as blocking one (or more) of the following bugs to simplify tracking such issues: [WWW] FE-ExcludeArch-x86, [WWW] FE-ExcludeArch-x64, [WWW] FE-ExcludeArch-ppc NOT CHECKED - MUST: A package must not contain any BuildRequires that are listed in the exceptions section of Packaging Guidelines. OK - MUST: All other Build dependencies must be listed in BuildRequires. SEEMED OK, I had to install mono-devel - MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden. NO /locale/* files at all, not sure if monodoc has any i18n at all - MUST: If the package contains shared library files located in the dynamic linker's default paths, No .so files, whether it needs to do anything similar with it's .dll files I don't know - MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. Dont think so - MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. The exception to this are directories listed explicitly in the Filesystem Hierarchy Standard ([WWW] http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to assume that those directories exist. Not checked - MUST: A package must not contain any duplicate files in the %files listing. No wildcards used at all, disn't spot any dupes - MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. No %defattr, can't see a reason why it would hurt to have one - MUST: Each package must have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). yes - MUST: Each package must consistently use macros, as described in the macros section of Packaging Guidelines. yes - MUST: The package must contain code, or permissable content. This is described in detail in the code vs. content section of Packaging Guidelines. seems OK, rpmlint doesn't acknowledge PE as code, but it plainly is also the actual monodoc content seems to be in xml bundles - MUST: Large documentation files should go in a -docs subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity) This *is* a docs package - MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. No %doc at all at present, should be fixed - MUST: Header files or static libraries must be in a -devel package. Didn't check - MUST: Files used by pkgconfig (.pc files) must be in a -devel package. There is a monodoc.pc file being packaged, I don't kneo if ".pc" files are significant in some other way (apart from pgkconfig) to mono? - MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. No .so files - MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency. No separate -devel - MUST: Packages must NOT contain any .la libtool archives, these should be removed in the spec. No .la files - MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. This is described in detail in the desktop files section of Packaging Guidelines. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. No .desktop file, unclear to me now if monodocs actually displays docs, in GUI, or just prepares thenm for later display, or browser based display. - MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora Extras should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. Didn't check - SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. It does include separate licence file - SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available. No extra translations provided - SHOULD: The reviewer should test that the package builds in mock. not done - SHOULD: The package should compile and build into binary rpms on all supported architectures. Only done on i386, tried and failed on x86_64 (probably not this packages fault) - SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example. Installed ok in i386 machine that was used to build no info how to start, or what it should do I tried "mono mod.exe" at least it gave a polite error rather than crashing - SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity. None used - SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency. None -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 00:20:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 19:20:27 -0500 Subject: [Bug 178904] Review Request: Monodevelop In-Reply-To: Message-ID: <200602040020.k140KR3V031618@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Monodevelop https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178904 ------- Additional Comments From fedora at adslpipe.co.uk 2006-02-03 19:20 EST ------- Err, apoligies all round first sorry rowan, you din't mid-flight collide over me second this review belongs on BZ#178900 i've already send a copy of it there -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 00:21:06 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 19:21:06 -0500 Subject: [Bug 179910] Review Request: commoncpp C++ framework In-Reply-To: Message-ID: <200602040021.k140L6en031748@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: commoncpp C++ framework https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179910 ed at eh3.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|bugzilla-sink at leemhuis.info |ed at eh3.com OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From ed at eh3.com 2006-02-03 19:20 EST ------- Hi Andreas, this isn't a full review (yet!), just a handful of observations: - please shorten "A portable and highly optimized class framework for writing C++ applications" to something shorter such as "A portable and optimized framework for C++ applications" - "nativily" --> "natively" - please delete all *.la files (per the packaging guidelines) - the "/usr/include/cc++2" dir is unowned -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From icon at fedoraproject.org Sat Feb 4 00:25:37 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Fri, 03 Feb 2006 19:25:37 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139006387.2652.29.camel@bree.local.net> References: <1139006387.2652.29.camel@bree.local.net> Message-ID: <43E3F481.9080800@fedoraproject.org> ? 03/02/06 05:39 PM, Jeremy Katz a ?crit: > Although I hate to do it, it looks like we're going to have to slip > Fedora Core 5 test3 by a week. There is an ABI change in the gcc/glibc > stack that requires a rebuild of the entire distribution. Given that, > there is no way that we'll be able to make a freeze date of Monday. So, > test3 will now freeze on Monday, 13 February with a release date of > Monday, 20 February. > > We'll adjust the final schedule sometime next week based on the progress > of the rebuilding efforts. Hey, Jeremy: How will this affect the readiness of Extras for FC5? About 4 weeks ago we were asked to rebuild our packages if we hadn't done that in a while -- in order to be ready for FC5. Will this have to be re-done? (Not complaining, just asking. :)) Regards, -- Konstantin Ryabitsev McGill University WSG Montr?al, Qu?bec From bugzilla at redhat.com Sat Feb 4 00:27:32 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 19:27:32 -0500 Subject: [Bug 178904] Review Request: Monodevelop In-Reply-To: Message-ID: <200602040027.k140RWKS032612@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Monodevelop https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178904 ------- Additional Comments From paul at all-the-johnsons.co.uk 2006-02-03 19:27 EST ------- Hi, > # rpmlint -v RPMS/i386/monodoc-1.1.9-2.i386.rpm > I: monodoc checking > E: monodoc no-binary > E: monodoc only-non-binary-in-usr-lib Um, this is a bugzilla report for monodoc and not monodevelop... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 00:44:23 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 19:44:23 -0500 Subject: [Bug 178900] Review Request: monodoc In-Reply-To: Message-ID: <200602040044.k140iN8O002470@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: monodoc https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178900 ------- Additional Comments From paul at all-the-johnsons.co.uk 2006-02-03 19:44 EST ------- Hi, > # rpmlint -v RPMS/i386/monodoc-1.1.9-2.i386.rpm > I: monodoc checking > E: monodoc no-binary > E: monodoc only-non-binary-in-usr-lib > There are binaries, but it's probably because they're .NET ones instead of standard ELF one which are causing the false positive. > W: monodoc no-documentation > > Ironic! There is some external documentation, but it requires mod-mono and xsp to be installed and as the package works fine without those extras, I felt it was better to exclude them. I will include them if needs be. > # rpmlint -v SRPMS/monodoc-1.1.9-2.src.rpm > I: monodoc checking > E: monodoc hardcoded-library-path in %{buildroot}/usr/lib/mono/gac > E: monodoc hardcoded-library-path in %{buildroot}/usr/lib > > within %install any reason you've used some with /usr/lib instead of %{_libdir} ? > e.g. > %{__mkdir} -p %{buildroot}%{_libdir}/pkgconfig > %{__mkdir} -p %{buildroot}/usr/lib/mono/gac You have to. By default, all that is mono installs to /usr/lib. Now, if I'm on an x86_64 or any other non-32 bit architecture, %{_libdir} is /usr/lib64. This breaks a lot of stuff under Mono (from what I've seen). Please see my bit on the fedorawiki on packaging for mono. > - MUST: The package must meet the Packaging Guidelines. > NOT CHECKED It should ;-) > - MUST: The package must be licensed with an open-source compatible > license and meet other legal requirements as defined in the legal section of > Packaging Guidelines. > > "COPYING" file shows GPL > If REDHAT can't comment about legal matters on mono/.net I'm sure I'm not > qualified to :-( > In general found individual sorce fiels didn't have licence info contained Mono itself is a right mix of licences. monodoc is GPL. I can't comment on the legal cloud around RH allowing mono in, but if a licence says GPL (or LGPL, BSD or the likes), then I'm good with it. > No %doc in %files, shoul dit be added and COPYING placed there? Yes. As should AUTHORS and a couple of others. > - MUST: The package must successfully compile and build into binary rpms > on at least one supported architecture. > > > OK for me on i386 > FAILED to compile for me on x86_64 (likely flaky mono on my machine beagle is > acting up to) Which version of mono have you got on the 64 bit box? I'm on 1.1.3 and it compiled without a hitch. > - MUST: All other Build dependencies must be listed in BuildRequires. > > SEEMED OK, I had to install mono-devel Good :-) > - MUST: The spec file MUST handle locales properly. This is done by using > the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden. > > > NO /locale/* files at all, not sure if monodoc has any i18n at all I can't see any. > - MUST: If the package contains shared library files located in the > dynamic linker's default paths, > > No .so files, whether it needs to do anything similar with it's .dll files I > don't know .NET doesn't use .so (as such). Again, see my piece on the fedora wiki for packaging for mono > - MUST: In the vast majority of cases, devel packages must require the > base package using a fully versioned dependency. > > > No separate -devel As such, there aren't really devel packages for mono (other than mono-devel that is!) > - MUST: Packages containing GUI applications must include a > %{name}.desktop file, and that file must be properly installed with > desktop-file-install in the %install section. This is described in detail in the > desktop files section of Packaging Guidelines. If you feel that your packaged > GUI application does not need a .desktop file, you must put a comment in the > spec file with your explanation. > > > No .desktop file, unclear to me now if monodocs actually displays docs, in GUI, > or just prepares thenm for later display, or browser based display. monodoc is used inside of monodevelop and won't run outside of it. > - SHOULD: The reviewer should test that the package builds in mock. > > not done I can't get mock to work, so I just compile it on the laptop and x86_64 box! > Installed ok in i386 machine that was used to build > no info how to start, or what it should do > I tried "mono mod.exe" at least it gave a polite error rather than crashing monodoc is not designed to work standalone. Thanks for the feedback -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 01:08:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 20:08:16 -0500 Subject: [Bug 177818] Review Request: adplug In-Reply-To: Message-ID: <200602040108.k1418G2l005198@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: adplug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177818 bugs.michael at gmx.net changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From bugs.michael at gmx.net 2006-02-03 20:08 EST ------- * spec looks good * dependencies 177865 and 178360 build with this * basic run-time testing: works for me * sources match upstream However: I'm unsure with regard to the stuff it does when running "adplugdb" with option "-s". Currently, it cannot create /usr/share/adplug/adplug.db because the directory is missing. And it ought not try writing to a file there anyway, as according to the FHS /usr/share is supposed to be for read-only and platform-independent data. Which leads to a question: Is adplug.db a platform-independent format? The default configuration of adplugdb (and the manual page) would need a correction to use directory /var/lib/adplug instead (or var/lib/misc/adplug.db if only that single file is accessed in there). Which leads to another question: If %dir /var/lib/adplug gets included, what to do with /var/lib/adplug/adplug.db during package removal? If %ghost'ed, user would lose the database file. If not %ghost'ed, the directory could not be removed. I prefer the latter, since I don't like removing user-created data files. In either case, /usr/share/adplug{/adplug.db} as a default is questionable. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 01:41:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 20:41:10 -0500 Subject: [Bug 178901] Review Request: gtksourceview-sharp In-Reply-To: Message-ID: <200602040141.k141fAUN009688@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gtksourceview-sharp https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178901 ------- Additional Comments From paul at all-the-johnsons.co.uk 2006-02-03 20:41 EST ------- This problem may be related to #179958 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rdieter at math.unl.edu Sat Feb 4 02:45:08 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 03 Feb 2006 20:45:08 -0600 Subject: How to make a selective spec file In-Reply-To: <1139006979.3158.10.camel@bureau.maison> References: <1138994941.2953.5.camel@bureau.maison> <1139006461.3158.2.camel@bureau.maison> <1139006979.3158.10.camel@bureau.maison> Message-ID: Eric Tanguy wrote: > Le vendredi 03 f?vrier 2006 ? 16:51 -0600, Rex Dieter a ?crit : >>Eric Tanguy wrote: >>>>Something like this ought to do the trick: >>>>%if "%{?fedora}" > "4" >>>>CXXFLAGS="${RPM_OPT_FLAGS} -ffriend-injection" >>>>%endif >>>>%configure >>>It seems it's not taken into account for devel. How to know what >>>%{?fedora} returns for devel ? >> >>AFAIK, on devel, %fedora expands to 5 in buildsys-macros > Maybe in buildsys but i'm trying to build it on a fc4 box using mock : > mock -r fedora-5-i386-core foobar.spec Of course it's not. That macro only gets defined if using the FE buildsystem (and/or) building from FE's Makefiles, ie, 'make mockbuild'. I had assumed this was what you were referring to in your original post. -- Rex From rdieter at math.unl.edu Sat Feb 4 03:03:00 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 03 Feb 2006 21:03:00 -0600 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: <87fyn0rxbd.fsf@kosh.bigo.ensc.de> References: <87k6ccs4fu.fsf@kosh.bigo.ensc.de> <87fyn0rxbd.fsf@kosh.bigo.ensc.de> Message-ID: Enrico Scholz wrote: > There is a difference between Requires(post): and a plain Requires:. The > first statement guarantees that the cache will be created, the latter > might miss to create it. Not if gtk2 run gtk-update-icon-cache in its own %post. (-: > Just for completeness (it is stated from the bugreport): > A cronjob which updates content under /usr regularly, sounds like a > really bad idea to me. It wouldn't update content regularly, but only when new rpms (that include icons) are installed. The content update is only, at most, being delayed from when the pkg is installed, to when the cron.daily (or whatever) task is run. I completely agree with you that the icon-cache should be in /var or /var/cache somewhere, but I suspect that's not something that we'll see soon (if ever). > Else, are you sure that all possible icon-directories can be enumerated > in this way? Not 100%, but it's at least a start, and can easily be incrementally expanded or improved upon. -- Rex From bugzilla at redhat.com Sat Feb 4 04:39:12 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Feb 2006 23:39:12 -0500 Subject: [Bug 178668] Review Request: numpy: A fast multidimensional array facility for Python In-Reply-To: Message-ID: <200602040439.k144dCPi006438@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: numpy: A fast multidimensional array facility for Python https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178668 ed at eh3.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From ed at eh3.com 2006-02-03 23:39 EST ------- Hi Ignacio, heres a more thorough review: good: + good parts from comment #1 still good + rpmlint produces a bunch of warnings and errors but taking a look at them it appears that they're all just brain-dead rpmlint annoyances + package builds in mock for fc4-i386 + BR list looks good + shared libs looks good (no *.la) + dir ownership OK + no %files dupes + permissions OK + has correct clean bits + code not content + some headers and libs are included but its acceptable + ran some simple examples and no segfaults -- good and I don't see any blockers so its APPROVED. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 06:38:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 01:38:18 -0500 Subject: [Bug 174494] Review Request: libopensync-plugin-irmc In-Reply-To: Message-ID: <200602040638.k146cIHf020130@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libopensync-plugin-irmc https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174494 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-04 01:38 EST ------- - rpmlint checks return: rpmlint of libopensync-plugin-irmc-0.18-2.i386.rpm:E: libopensync-plugin-irmc zero-length /usr/share/doc/libopensync-plugin-irmc-0.18/ChangeLog E: libopensync-plugin-irmc zero-length /usr/share/doc/libopensync-plugin-irmc-0.18/AUTHORS E: libopensync-plugin-irmc zero-length /usr/share/doc/libopensync-plugin-irmc-0.18/README E: libopensync-plugin-irmc zero-length /usr/share/doc/libopensync-plugin-irmc-0.18/NEWS Empty doc files go. Good: - package meets naming guidelines - package meets packaging guidelines - license (GPL) OK, text in %doc, matches source - spec file legible, in am. english - source matches upstream - package compiles on FC4 i386 - no missing BR - no unnecessary BR - no locales - not relocatable - owns all directories that it creates - no duplicate files - permissions ok - %clean ok - macro use consistent - code, not content - no need for -docs - nothing in %doc affects runtime - no need for .desktop file Ax the empty files and this is APPROVED. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 06:52:37 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 01:52:37 -0500 Subject: [Bug 172343] Review Request: libtomoe-gtk In-Reply-To: Message-ID: <200602040652.k146qbTH021525@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libtomoe-gtk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172343 ------- Additional Comments From jpmahowald at gmail.com 2006-02-04 01:52 EST ------- Links are not working. bcvrf.yahoo.com could not be found. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 07:09:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 02:09:49 -0500 Subject: [Bug 174265] Review Request: itcl - Object oriented extension to Tcl In-Reply-To: Message-ID: <200602040709.k1479nNi023309@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: itcl - Object oriented extension to Tcl https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174265 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-04 02:09 EST ------- Good: - rpmlint checks: W: itcl-devel no-documentation can ignore - package meets naming guidelines - package meets packaging guidelines - license (BSD) OK, text in %doc, matches source - spec file legible, in am. english - source matches upstream - package compiles on FC4 i386 - no missing BR - no unnecessary BR - no locales - not relocatable - owns all directories that it creates - no duplicate files - permissions ok - %clean ok - macro use consistent - code, not content - no need for -docs - nothing in %doc affects runtime - no need for .desktop file APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From eric.tanguy at univ-nantes.fr Sat Feb 4 08:33:01 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Sat, 04 Feb 2006 09:33:01 +0100 Subject: Qucs no more build in devel Message-ID: <1139041981.3121.9.camel@bureau.maison> As it said before (https://www.redhat.com/archives/fedora-extras-list/2006-February/msg00044.html) qucs no more build in devel due to gcc-4.1. I found a solution to have it building against gcc-4.1 but i need also to update it to the new and very interesting version which now support also digital simulation. The problem to do this is that now it requires freehdl to perform digital simulation using gcc. But i can't try either qucs or freehdl using gcc-4.1 because my own system is fc4. I know there is a lot of packages in review process but i would like qucs and freehdl to be tested against rawhide and for this freehdl need to be reviewed before ( https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178709 ). So if someone could have a few time to review this package it will be very usefull for qucs update. Thanks Eric From ivazquez at ivazquez.net Sat Feb 4 08:39:28 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 04 Feb 2006 03:39:28 -0500 Subject: Qucs no more build in devel In-Reply-To: <1139041981.3121.9.camel@bureau.maison> References: <1139041981.3121.9.camel@bureau.maison> Message-ID: <1139042368.14676.0.camel@ignacio.lan> On Sat, 2006-02-04 at 09:33 +0100, Eric Tanguy wrote: > But i can't try either qucs or freehdl using gcc-4.1 because my own > system is fc4. Okay, you *really* need to set up mock on your machine... -- 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 eric.tanguy at univ-nantes.fr Sat Feb 4 08:45:04 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Sat, 04 Feb 2006 09:45:04 +0100 Subject: Qucs no more build in devel In-Reply-To: <1139042368.14676.0.camel@ignacio.lan> References: <1139041981.3121.9.camel@bureau.maison> <1139042368.14676.0.camel@ignacio.lan> Message-ID: <1139042704.3121.11.camel@bureau.maison> Le samedi 04 f?vrier 2006 ? 03:39 -0500, Ignacio Vazquez-Abrams a ?crit : > On Sat, 2006-02-04 at 09:33 +0100, Eric Tanguy wrote: > > But i can't try either qucs or freehdl using gcc-4.1 because my own > > system is fc4. > > Okay, you *really* need to set up mock on your machine... > Mock is set up on my machine so i know it biulds fine now but i have no mean to test the program running with gcc-4.1. Eric From bugzilla at redhat.com Sat Feb 4 08:42:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 03:42:36 -0500 Subject: [Bug 177818] Review Request: adplug In-Reply-To: Message-ID: <200602040842.k148gawE003872@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: adplug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177818 ------- Additional Comments From triad at df.lth.se 2006-02-04 03:42 EST ------- Sent question to upstream: http://sourceforge.net/tracker/index.php?func=detail&aid=1423945&group_id=28079&atid=392364 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From ivazquez at ivazquez.net Sat Feb 4 08:51:42 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 04 Feb 2006 03:51:42 -0500 Subject: Qucs no more build in devel In-Reply-To: <1139042704.3121.11.camel@bureau.maison> References: <1139041981.3121.9.camel@bureau.maison> <1139042368.14676.0.camel@ignacio.lan> <1139042704.3121.11.camel@bureau.maison> Message-ID: <1139043102.14676.2.camel@ignacio.lan> On Sat, 2006-02-04 at 09:45 +0100, Eric Tanguy wrote: > Le samedi 04 f?vrier 2006 ? 03:39 -0500, Ignacio Vazquez-Abrams a > ?crit : > > On Sat, 2006-02-04 at 09:33 +0100, Eric Tanguy wrote: > > > But i can't try either qucs or freehdl using gcc-4.1 because my own > > > system is fc4. > > > > Okay, you *really* need to set up mock on your machine... > > > Mock is set up on my machine so i know it biulds fine now but i have no > mean to test the program running with gcc-4.1. You could always chroot to /var/lib/mock/foo/root and test there. -- 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 bugzilla at redhat.com Sat Feb 4 09:03:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 04:03:21 -0500 Subject: [Bug 178904] Review Request: Monodevelop In-Reply-To: Message-ID: <200602040903.k1493LMX008661@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Monodevelop https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178904 ------- Additional Comments From fedora at adslpipe.co.uk 2006-02-04 04:03 EST ------- (In reply to comment #4) > Um, this is a bugzilla report for monodoc and not monodevelop... Err yes, I though I'd coughed up to my mistake in comment #3 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 09:24:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 04:24:56 -0500 Subject: [Bug 178900] Review Request: monodoc In-Reply-To: Message-ID: <200602040924.k149Ouhr013144@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: monodoc https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178900 ------- Additional Comments From fedora at adslpipe.co.uk 2006-02-04 04:24 EST ------- (In reply to comment #4) > There are binaries, but it's probably because they're .NET ones instead of > standard ELF one which are causing the false positive. yes, I did realise this with my "because it produces PE rather than ELF executables?" comment, Still interested to know if/how beagle/fspot go out of their way to persuade rpmlint it's ok? > > Ironic! > > There is some external documentation, [snip] I will include them if needs be. I meant rpmlint had missed the point about monodoc *being* doc, rather than having doc, though if the docs did explain that this package is not runnable as such, just providing doc contents it might be worthwhile. > any other non-32 bit architecture, %{_libdir} is /usr/lib64. This > breaks a lot of stuff under Mono at least there's a reason, I'm not qualified to say if its a qood enough one > Which version of mono have you got on the 64 bit box? I'm on 1.1.3 and it > compiled without a hitch. 1.1.3.2 beagle/fspot have worked in the past, they broke some time after fc5t2, mabe when the kernel went to 2.6-16-pre series? what's a very simple mono prog to run check if all of mono is deas on my machine, or just bits of it? I believe you compile your own mono rather than installing fedora's? > monodoc is used inside of monodevelop and won't run outside of it. ok, so no .desktop required > Thanks for the feedback If you get a chance to review my Eiciel package I'd be greatful https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179758 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 09:28:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 04:28:49 -0500 Subject: [Bug 174494] Review Request: libopensync-plugin-irmc In-Reply-To: Message-ID: <200602040928.k149Snxa013849@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libopensync-plugin-irmc https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174494 ------- Additional Comments From andreas.bierfert at lowlatency.de 2006-02-04 04:28 EST ------- Thanks fixed in this one :) http://fedora.lowlatency.de/review/libopensync-plugin-irmc-0.18-3.src.rpm http://fedora.lowlatency.de/review/libopensync-plugin-irmc.spec -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 10:04:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 05:04:02 -0500 Subject: [Bug 179988] New: Review Request: freealut - Implementation of OpenAL's ALUT standard Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179988 Summary: Review Request: freealut - Implementation of OpenAL's ALUT standard Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: andreas.bierfert at lowlatency.de QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://fedora.lowlatency.de/review/freealut.spec SRPM Name or Url: http://fedora.lowlatency.de/review/freealut-1.0.0-1.src.rpm Description: freealut is a free implementation of OpenAL's ALUT standard. See the file AUTHORS for the people involved. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 4 10:14:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 05:14:36 -0500 Subject: [Bug 175748] Review Request: cacti In-Reply-To: Message-ID: <200602041014.k14AEafi019975@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cacti https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175748 ------- Additional Comments From gauret at free.fr 2006-02-04 05:14 EST ------- Sorry for not getting back earlier. In you last spec file, seem to have moved files back to /usr/share and /var/lib. In order to avoid the SELinux problem, I think we should keep everything in /var/www, as you said in comment 12. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From paul at city-fan.org Sat Feb 4 10:24:10 2006 From: paul at city-fan.org (Paul Howarth) Date: Sat, 04 Feb 2006 10:24:10 +0000 Subject: How to make a selective spec file In-Reply-To: References: <1138994941.2953.5.camel@bureau.maison> <1139006461.3158.2.camel@bureau.maison> <1139006979.3158.10.camel@bureau.maison> Message-ID: <1139048651.12134.7.camel@laurel.intra.city-fan.org> On Fri, 2006-02-03 at 20:45 -0600, Rex Dieter wrote: > Eric Tanguy wrote: > > Le vendredi 03 f?vrier 2006 ? 16:51 -0600, Rex Dieter a ?crit : > > >>Eric Tanguy wrote: > > >>>>Something like this ought to do the trick: > >>>>%if "%{?fedora}" > "4" > >>>>CXXFLAGS="${RPM_OPT_FLAGS} -ffriend-injection" > >>>>%endif > >>>>%configure > > >>>It seems it's not taken into account for devel. How to know what > >>>%{?fedora} returns for devel ? > >> > >>AFAIK, on devel, %fedora expands to 5 in buildsys-macros > > > Maybe in buildsys but i'm trying to build it on a fc4 box using mock : > > mock -r fedora-5-i386-core foobar.spec > > Of course it's not. That macro only gets defined if using the FE > buildsystem (and/or) building from FE's Makefiles, ie, 'make mockbuild'. > I had assumed this was what you were referring to in your original post. He said he was using mock, and mock pulls in the required macro definitions by default courtesy of the [groups] repo, which points to http://fedoraproject.org/buildgroups/development/i386/ So a mock build should be the same as an FE buildsystem build in this respect. The root.log from the mock build should show buildsys-macros being installed. Paul. From eric.tanguy at univ-nantes.fr Sat Feb 4 11:45:39 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Sat, 04 Feb 2006 12:45:39 +0100 Subject: How to make a selective spec file In-Reply-To: <1139048651.12134.7.camel@laurel.intra.city-fan.org> References: <1138994941.2953.5.camel@bureau.maison> <1139006461.3158.2.camel@bureau.maison> <1139006979.3158.10.camel@bureau.maison> <1139048651.12134.7.camel@laurel.intra.city-fan.org> Message-ID: <1139053539.3115.4.camel@bureau.maison> Le samedi 04 f?vrier 2006 ? 10:24 +0000, Paul Howarth a ?crit : > On Fri, 2006-02-03 at 20:45 -0600, Rex Dieter wrote: > > Eric Tanguy wrote: > > > Le vendredi 03 f?vrier 2006 ? 16:51 -0600, Rex Dieter a ?crit : > > > > >>Eric Tanguy wrote: > > > > >>>>Something like this ought to do the trick: > > >>>>%if "%{?fedora}" > "4" > > >>>>CXXFLAGS="${RPM_OPT_FLAGS} -ffriend-injection" > > >>>>%endif > > >>>>%configure > > > > >>>It seems it's not taken into account for devel. How to know what > > >>>%{?fedora} returns for devel ? > > >> > > >>AFAIK, on devel, %fedora expands to 5 in buildsys-macros > > > > > Maybe in buildsys but i'm trying to build it on a fc4 box using mock : > > > mock -r fedora-5-i386-core foobar.spec > > > > Of course it's not. That macro only gets defined if using the FE > > buildsystem (and/or) building from FE's Makefiles, ie, 'make mockbuild'. > > I had assumed this was what you were referring to in your original post. > > He said he was using mock, and mock pulls in the required macro > definitions by default courtesy of the [groups] repo, which points to > http://fedoraproject.org/buildgroups/development/i386/ > > So a mock build should be the same as an FE buildsystem build in this > respect. The root.log from the mock build should show buildsys-macros > being installed. > > Paul. The problem is : cd /var/lib/mock/fedora-development-i386-core/root/etc/rpm ls nothing and i would be able to find macros.disttag containing : %fedora 5 %dist .fc5 So it seems mock build is not the same as an FE buildsystem build or i do something wrong ? Or it's because in FE buildsystem i do a make tag before requesting a build ? Eric From bugzilla at redhat.com Sat Feb 4 11:44:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 06:44:18 -0500 Subject: [Bug 177658] Review Request: mediawiki - The PHP-based wiki software behind Wikipedia In-Reply-To: Message-ID: <200602041144.k14BiINl029532@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mediawiki - The PHP-based wiki software behind Wikipedia https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177658 ------- Additional Comments From roozbeh at farsiweb.info 2006-02-04 06:44 EST ------- (In reply to comment #16) > I believe you can use Requires(pre) instead of PreReq to achieve the same > affect. Yes, that would work, and the package will be forward-compatible that way. New version: Spec Url: http://guava.farsiweb.info/~roozbeh/mediawiki.spec SRPM Url: http://guava.farsiweb.info/~roozbeh/mediawiki-1.5.6-4.src.rpm %changelog - Use Requires(pre) instead of PreReq (Mike McGrath) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From nicolas.mailhot at laposte.net Sat Feb 4 12:04:39 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 04 Feb 2006 13:04:39 +0100 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: <1139000311.3377.32.camel@localhost> References: <87k6ccs4fu.fsf@kosh.bigo.ensc.de> <87fyn0rxbd.fsf@kosh.bigo.ensc.de> <1139000311.3377.32.camel@localhost> Message-ID: <1139054679.24024.19.camel@rousalka.dyndns.org> Hi, You have exactly the same problem with fonts and fc-cache. The current idiom (which works very well) is : - fc-cache call in fontconfig postinstall scriptlet - conditional fc-cache in font packages postinstall scriptlet (using /bin/sh): if [ -x /usr/bin/fc-cache ]; then /usr/bin/fc-cache /usr/share/fonts fi postuninstall scriptlet (using /bin/sh): if [ "$1" = "0" ]; then if [ -x /usr/bin/fc-cache ]; then /usr/bin/fc-cache /usr/share/fonts fi fi This works well, catches 100% of the cases, does not force fontconfig dep in font packages (apps that need the fonts but use another font rendering tech are happy), does not sprinkle triggers everywhere where they're difficult to get rid of. This model should be followed by every package needing optional indexing provided by another packager IMHO Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From roozbeh at farsiweb.info Sat Feb 4 12:58:58 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Sat, 04 Feb 2006 16:28:58 +0330 Subject: extras metadata not updated since february 1 Message-ID: <1139057939.3007.18.camel@tameshk.farsiweb.info> it seems that the extras metadata has not got updated since February 1, although new RPMs have been pushed. As an example, there are three RPMs for fontforge at the URL: http://download.fedora.redhat.com/pub/fedora/linux/extras/4/i386/ While there are only two older ones listed in primary.xml. The repomd.xml file also mentions a last change on February 1 (timestamp 1138758388). Would someone with access see what's going on? roozbeh From enrico.scholz at informatik.tu-chemnitz.de Sat Feb 4 13:16:07 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 04 Feb 2006 14:16:07 +0100 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: <1139054679.24024.19.camel@rousalka.dyndns.org> (Nicolas Mailhot's message of "Sat, 04 Feb 2006 13:04:39 +0100") References: <87k6ccs4fu.fsf@kosh.bigo.ensc.de> <87fyn0rxbd.fsf@kosh.bigo.ensc.de> <1139000311.3377.32.camel@localhost> <1139054679.24024.19.camel@rousalka.dyndns.org> Message-ID: <878xsrs1rc.fsf@kosh.bigo.ensc.de> nicolas.mailhot at laposte.net (Nicolas Mailhot) writes: > You have exactly the same problem with fonts and fc-cache. The fc-cache case is easier because the locations of all possible cache files are known to the 'fc-cache' program. For gtk-update-icon-cache, you have to enumerate them manually. > postinstall scriptlet (using /bin/sh): > if [ -x /usr/bin/fc-cache ]; then > /usr/bin/fc-cache /usr/share/fonts Here, a '|| :' should be added. Else, scriptlets will fail when /usr/share is shared between multiple hosts and mounted read-only therefore. > fi This scriptlet can be written shorter as | %post | /usr/bin/fc-cache /usr/share/fonts >/dev/null 2>&1 || : Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From bugzilla at redhat.com Sat Feb 4 13:26:26 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 08:26:26 -0500 Subject: [Bug 172343] Review Request: libtomoe-gtk In-Reply-To: Message-ID: <200602041326.k14DQQBb008747@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libtomoe-gtk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172343 ------- Additional Comments From ryo-dairiki at users.sourceforge.net 2006-02-04 08:26 EST ------- I'm sorry, it seems like yahoo briefcase sometimes changes it's download link URLs. You can see them in libtomoe-gtk folder at http://briefcase.yahoo.co.jp/ryo_dairiki But I'll upload them as soon as I get a better file sharering repository. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 14:39:31 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 09:39:31 -0500 Subject: [Bug 174494] Review Request: libopensync-plugin-irmc In-Reply-To: Message-ID: <200602041439.k14EdV6D017988@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libopensync-plugin-irmc https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174494 ------- Additional Comments From jpmahowald at gmail.com 2006-02-04 09:39 EST ------- Better. Release 3 APPROVED. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 15:16:31 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 10:16:31 -0500 Subject: [Bug 175748] Review Request: cacti In-Reply-To: Message-ID: <200602041516.k14FGV33021837@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cacti https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175748 ------- Additional Comments From imlinux at gmail.com 2006-02-04 10:16 EST ------- I can move it back but do you see any reason Paul's suggestion won't work? (From Comment 13) https://www.redhat.com/archives/fedora-extras-list/2006-January/msg01169.html -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 15:30:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 10:30:09 -0500 Subject: [Bug 176523] Review Request: python-json: A JSON reader and writer for Python In-Reply-To: Message-ID: <200602041530.k14FU9eb023484@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: python-json: A JSON reader and writer for Python https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176523 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |jpmahowald at gmail.com OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-04 10:29 EST ------- Minor: Doesn't %ghost *.pyo like the python template does. Good: - rpmlint clean - package meets naming guidelines - package meets packaging guidelines - license (LGPL) OK, text in %doc, matches source - spec file legible, in am. english - source matches upstream - package compiles on FC4 i386 - no missing BR - no unnecessary BR - no locales - not relocatable - owns all directories that it creates - no duplicate files - permissions ok - %clean ok - macro use consistent - code, not content - no need for -docs - nothing in %doc affects runtime - no need for .desktop file - unit tests pass APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 16:31:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 11:31:33 -0500 Subject: [Bug 179910] Review Request: commoncpp C++ framework In-Reply-To: Message-ID: <200602041631.k14GVXdP031028@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: commoncpp C++ framework https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179910 ------- Additional Comments From ville.skytta at iki.fi 2006-02-04 11:31 EST ------- More observations: - 1.3.23 is out - Most likely missing build dependencies: libxml2-devel, zlib-devel, doxygen - Missing dependency on pkgconfig in -devel - Missing install-info dependencies in -devel, "|| :" safeguards missing from install-info invocations (breaks --excludedocs installs) - Installation may try to modify /etc/ld.so.conf Feel free to borrow fixes for the above and whatever you find worth taking from my local package at http://cachalot.mine.nu/5/SRPMS/commoncpp2-1.3.23-v1.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 4 16:35:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 11:35:35 -0500 Subject: [Bug 175433] Review Request: tor - Anonymizing overlay network for TCP (The onion router) In-Reply-To: Message-ID: <200602041635.k14GZZqd031932@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: tor - Anonymizing overlay network for TCP (The onion router) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175433 ------- Additional Comments From enrico.scholz at informatik.tu-chemnitz.de 2006-02-04 11:35 EST ------- * Mon Jan 30 2006 Enrico Scholz - 0.1.0.16-0.1 - renamed the current main-package into a '-core' subpackage and created a new main-package which requires both the 'tor-core' subpackage and this with the current default init-method. This allows 'yum install tor' to work better; because yum is not very smart, the old packaging might install unwanted packages else. http://ensc.de/fedora/tor.spec http://ensc.de/fedora/tor-0.1.0.16-0.1.src.rpm ============ An rpm package which is linked on the Tor homepage and which would run on every (LSB compliant) system is possible. But it would require heavily discouraged things like static linking of non-LSB deps (e.g. libevent). So, this review is for a package in the Fedora Extras environment. This environment provides all the packages required for my packaging. The tor homepage does not link to Debian, Gentoo or *BSD binaries either but tells the installation command. For this package, the corresponding command is 'yum install tor'. The current packaging will also install the current default init-method but allows still minimal environments with more effective init methods. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 16:36:45 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 11:36:45 -0500 Subject: [Bug 178951] Review Request: modules - Provides dynamic modification of a user's environment In-Reply-To: Message-ID: <200602041636.k14Gajlv032096@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: modules - Provides dynamic modification of a user's environment https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178951 ------- Additional Comments From ed at eh3.com 2006-02-04 11:36 EST ------- OK, thats cool. And I'd like to withdraw my request for the inclusion of the paper (last part of comment #3) because its not released under any clear license/copyright plus its content not code. So the only thing thats going to be changed is the package name, right? If so, just point me towards a new SRPM and I'll take a quick (hopefully last!) look. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 16:47:45 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 11:47:45 -0500 Subject: [Bug 179910] Review Request: commoncpp C++ framework In-Reply-To: Message-ID: <200602041647.k14Gljnl000759@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: commoncpp C++ framework https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179910 ------- Additional Comments From ed at eh3.com 2006-02-04 11:47 EST ------- Hi Ville, I think you have a much better idea whats happening here so, if you want, please go ahead and replace me as the reviewer. Otherwise, I'll do what I can to help the submitter get the good bits from your package incorporated into this one. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 4 16:48:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 11:48:15 -0500 Subject: [Bug 177658] Review Request: mediawiki - The PHP-based wiki software behind Wikipedia In-Reply-To: Message-ID: <200602041648.k14GmFC1000825@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mediawiki - The PHP-based wiki software behind Wikipedia https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177658 imlinux at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From imlinux at gmail.com 2006-02-04 11:48 EST ------- -rpmlint (mediawiki): E: mediawiki no-binary E: mediawiki non-standard-gid /var/www/mediawiki/config apache E: mediawiki non-standard-dir-perm /var/www/mediawiki/config 0770 These are safe to ignore -rpmlint (mediawiki-math): No output -Matches naming requirements -is %{name}.spec -Meets packaging guidelines -License is GPL -Spec file is written in English and is easy to follow -Source matches upstream -Successfully builds on i386 -All build requires listed, no duplicates -Locale not used -Package ownes all directories it creates -Contains no duplicate file listings -Both files sections contain proper %defattr -Cleans $RPM_BUILD_ROOT -%macro's used consistantly -Builds in mock Everything looks good, I look forward to using this package. One thing before you upload it, take my name out of the comments :-D APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From buildsys at fedoraproject.org Sat Feb 4 16:58:57 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 4 Feb 2006 11:58:57 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060204165857.8244A7FDC@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 13 amavisd-new-2.3.3-5.fc3 libetpan-0.42-1.fc3 liboil-0.3.6-2.fc3 perl-CPAN-DistnameInfo-0.06-1.fc3 perl-Convert-ASCII-Armour-1.4-3.fc3 perl-Module-CoreList-2.04-1.fc3 perl-Parse-CPAN-Packages-2.25-2.fc3 perl-Text-Levenshtein-0.05-2.fc3 quilt-0.43-1.fc3 wine-0.9.7-1.fc3 wine-docs-0.9.7-1.fc3 workrave-1.8.2-1.fc3 xfce4-netload-plugin-0.3.3-4.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Sat Feb 4 16:54:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 11:54:28 -0500 Subject: [Bug 176526] Review Request: TestGears: Unit testing for Python In-Reply-To: Message-ID: <200602041654.k14GsSc7001577@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: TestGears: Unit testing for Python https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176526 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |jpmahowald at gmail.com OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-04 11:54 EST ------- Good: - rpmlint clean - package meets naming guidelines - package meets packaging guidelines - license (MIT) OK, text in %doc, matches source - spec file legible, in am. english - source matches upstream - package compiles on FC4 - no missing BR - no unnecessary BR - no locales - not relocatable - owns all directories that it creates - no duplicate files - permissions ok - %clean ok - macro use consistent - code, not content - no need for -docs - nothing in %doc affects runtime - no need for .desktop file APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From buildsys at fedoraproject.org Sat Feb 4 16:59:47 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 4 Feb 2006 11:59:47 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060204165947.39DDC7FDC@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 26 amavisd-new-2.3.3-5.fc4 eet-0.9.10.023-1.fc4 fftw-3.1-1.fc4 firestarter-1.0.3-9.fc4 libetpan-0.42-1.fc4 liferea-1.0.3-1.fc4 nethack-vultures-1.11.2-4.fc4 notecase-1.1.4-1.fc4 octave-2.1.72-3.fc4 octave-forge-2006.01.28-2.fc4 perl-CPAN-DistnameInfo-0.06-1.fc4 perl-Class-Loader-2.03-1.fc4 perl-Convert-ASCII-Armour-1.4-3.fc4 perl-Module-CoreList-2.04-1.fc4 perl-Parse-CPAN-Packages-2.25-2.fc4 perl-Text-Levenshtein-0.05-2.fc4 python-enchant-1.1.3-3.fc4 quilt-0.43-1.fc4 smb4k-0.6.5-5.fc4 sylpheed-claws-2.0.0-1.fc4 sylpheed-claws-plugins-2.0.0-1.fc4 translate-toolkit-0.8-0.5.rc5.fc4 translate-toolkit-0.8-0.6.rc6.fc4 wine-0.9.7-1.fc4 workrave-1.8.2-1.fc4 xfce4-netload-plugin-0.3.3-4.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat Feb 4 17:01:23 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 4 Feb 2006 12:01:23 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060204170123.126927FDC@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 45 amavisd-new-2.3.3-5.fc5 bittorrent-4.4.0-1.fc5 deskbar-applet-2.13.90-1.fc5 eet-0.9.10.023-1.fc5 fedora-rpmdevtools-1.4-2.fc5 fftw-3.1-1.fc5 firestarter-1.0.3-9.fc5 fonttools-2.0-0.4.20050624cvs.fc5 ginac-1.3.3-3.fc5 gnome-translate-0.99-5.fc5 gnotime-2.2.2-3.fc5 hdf-4.2r1-7.fc5 koffice-1.4.90-1.fc5 kphone-4.2-5.fc5 leafpad-0.8.7-1.fc5 libapreq2-2.07-0.2.rc4.fc5 libetpan-0.42-1.fc5 nautilus-open-terminal-0.6-2.fc5 nethack-vultures-1.11.2-4.fc5 new-1.3.7-1 notecase-1.1.4-1.fc5 numpy-0.9.4-1.fc5 octave-2.9.4-6.fc5 openal-0.0.9-0.1.20060204.fc5 pam_usb-0.3.3-3.fc5 perl-CPAN-DistnameInfo-0.06-1.fc5 perl-Convert-ASCII-Armour-1.4-3.fc5 perl-Convert-PEM-0.07-3.fc5 perl-Crypt-DES-2.05-1.fc5 perl-Crypt-DES_EDE3-0.01-2.fc5 perl-Crypt-DES_EDE3-0.01-3.fc5 perl-Module-CoreList-2.04-1.fc5 perl-Module-Signature-0.53-1.fc5 perl-Parse-CPAN-Packages-2.25-2.fc5 perl-Test-Pod-1.24-1.fc5 perl-Text-Levenshtein-0.05-2.fc5 python-sqlite2-2.1.3-2.fc5 quilt-0.43-1.fc5 sylpheed-claws-2.0.0-1.fc5 sylpheed-claws-plugins-2.0.0-1.fc5 translate-toolkit-0.8-0.7.rc6.fc5 wine-0.9.7-1.fc5 wine-docs-0.9.7-1.fc5 workrave-1.8.2-1.fc5 xfce4-netload-plugin-0.3.3-4.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From ville.skytta at iki.fi Sat Feb 4 17:05:30 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 04 Feb 2006 19:05:30 +0200 Subject: extras metadata not updated since february 1 In-Reply-To: <1139057939.3007.18.camel@tameshk.farsiweb.info> References: <1139057939.3007.18.camel@tameshk.farsiweb.info> Message-ID: <1139072730.6075.0.camel@bobcat.mine.nu> On Sat, 2006-02-04 at 16:28 +0330, Roozbeh Pournader wrote: > Would someone with access see what's going on? Damn, I just kicked a push before seeing this message, so I guess it's too late to debug it now... let's see how it goes. From bugzilla at redhat.com Sat Feb 4 17:07:39 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 12:07:39 -0500 Subject: [Bug 174265] Review Request: itcl - Object oriented extension to Tcl In-Reply-To: Message-ID: <200602041707.k14H7dxQ003462@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: itcl - Object oriented extension to Tcl https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174265 wart at kobold.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From wart at kobold.org 2006-02-04 12:07 EST ------- Package imported and pushed through the devel build system with no problems. Thanks for the review! -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 17:08:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 12:08:02 -0500 Subject: [Bug 177359] Review Request: itk - object oriented extensions for Tk In-Reply-To: Message-ID: <200602041708.k14H82JZ003524@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: itk - object oriented extensions for Tk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177359 Bug 177359 depends on bug 174265, which changed state. Bug 174265 Summary: Review Request: itcl - Object oriented extension to Tcl https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174265 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NEXTRELEASE Status|ASSIGNED |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From paul at city-fan.org Sat Feb 4 17:14:35 2006 From: paul at city-fan.org (Paul Howarth) Date: Sat, 04 Feb 2006 17:14:35 +0000 Subject: How to make a selective spec file In-Reply-To: <1139053539.3115.4.camel@bureau.maison> References: <1138994941.2953.5.camel@bureau.maison> <1139006461.3158.2.camel@bureau.maison> <1139006979.3158.10.camel@bureau.maison> <1139048651.12134.7.camel@laurel.intra.city-fan.org> <1139053539.3115.4.camel@bureau.maison> Message-ID: <1139073275.12134.14.camel@laurel.intra.city-fan.org> On Sat, 2006-02-04 at 12:45 +0100, Eric Tanguy wrote: > Le samedi 04 f?vrier 2006 ? 10:24 +0000, Paul Howarth a ?crit : > > On Fri, 2006-02-03 at 20:45 -0600, Rex Dieter wrote: > > > Eric Tanguy wrote: > > > > Le vendredi 03 f?vrier 2006 ? 16:51 -0600, Rex Dieter a ?crit : > > > > > > >>Eric Tanguy wrote: > > > > > > >>>>Something like this ought to do the trick: > > > >>>>%if "%{?fedora}" > "4" > > > >>>>CXXFLAGS="${RPM_OPT_FLAGS} -ffriend-injection" > > > >>>>%endif > > > >>>>%configure > > > > > > >>>It seems it's not taken into account for devel. How to know what > > > >>>%{?fedora} returns for devel ? > > > >> > > > >>AFAIK, on devel, %fedora expands to 5 in buildsys-macros > > > > > > > Maybe in buildsys but i'm trying to build it on a fc4 box using mock : > > > > mock -r fedora-5-i386-core foobar.spec > > > > > > Of course it's not. That macro only gets defined if using the FE > > > buildsystem (and/or) building from FE's Makefiles, ie, 'make mockbuild'. > > > I had assumed this was what you were referring to in your original post. > > > > He said he was using mock, and mock pulls in the required macro > > definitions by default courtesy of the [groups] repo, which points to > > http://fedoraproject.org/buildgroups/development/i386/ > > > > So a mock build should be the same as an FE buildsystem build in this > > respect. The root.log from the mock build should show buildsys-macros > > being installed. > > > > Paul. > > The problem is : > cd /var/lib/mock/fedora-development-i386-core/root/etc/rpm > ls > nothing > and i would be able to find macros.disttag containing : > %fedora 5 > %dist .fc5 > > So it seems mock build is not the same as an FE buildsystem build or i > do something wrong ? Is there no reference to buildsys-macros in /var/lib/mock/fedora-development-i386-core/result/root.log? > Or it's because in FE buildsystem i do a make tag before requesting a > build ? No, that's a cvs tag, nothing to do with dist tag. Paul. From bugzilla at redhat.com Sat Feb 4 17:12:55 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 12:12:55 -0500 Subject: [Bug 177658] Review Request: mediawiki - The PHP-based wiki software behind Wikipedia In-Reply-To: Message-ID: <200602041712.k14HCtEp004185@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mediawiki - The PHP-based wiki software behind Wikipedia https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177658 ------- Additional Comments From roozbeh at farsiweb.info 2006-02-04 12:12 EST ------- (In reply to comment #18) > Everything looks good, I look forward to using this package. Thanks a lot for the review. I really appreciated it, and I believe your comments have resulted in an easier time in maintaining it for the long term. > One thing before you upload it, take my name out of the comments :-D Well, usually someone who provides a patch (some of your comments were really a patch) is credited. I will take your name out if you don't wish to be credited, but these were really your patches, you were really helpful, and I'd really like to credit you for them. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From eric.tanguy at univ-nantes.fr Sat Feb 4 17:44:03 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Sat, 04 Feb 2006 18:44:03 +0100 Subject: How to make a selective spec file In-Reply-To: <1139073275.12134.14.camel@laurel.intra.city-fan.org> References: <1138994941.2953.5.camel@bureau.maison> <1139006461.3158.2.camel@bureau.maison> <1139006979.3158.10.camel@bureau.maison> <1139048651.12134.7.camel@laurel.intra.city-fan.org> <1139053539.3115.4.camel@bureau.maison> <1139073275.12134.14.camel@laurel.intra.city-fan.org> Message-ID: <1139075043.3115.6.camel@bureau.maison> Le samedi 04 f?vrier 2006 ? 17:14 +0000, Paul Howarth a ?crit : > On Sat, 2006-02-04 at 12:45 +0100, Eric Tanguy wrote: > > Le samedi 04 f?vrier 2006 ? 10:24 +0000, Paul Howarth a ?crit : > > > On Fri, 2006-02-03 at 20:45 -0600, Rex Dieter wrote: > > > > Eric Tanguy wrote: > > > > > Le vendredi 03 f?vrier 2006 ? 16:51 -0600, Rex Dieter a ?crit : > > > > > > > > >>Eric Tanguy wrote: > > > > > > > > >>>>Something like this ought to do the trick: > > > > >>>>%if "%{?fedora}" > "4" > > > > >>>>CXXFLAGS="${RPM_OPT_FLAGS} -ffriend-injection" > > > > >>>>%endif > > > > >>>>%configure > > > > > > > > >>>It seems it's not taken into account for devel. How to know what > > > > >>>%{?fedora} returns for devel ? > > > > >> > > > > >>AFAIK, on devel, %fedora expands to 5 in buildsys-macros > > > > > > > > > Maybe in buildsys but i'm trying to build it on a fc4 box using mock : > > > > > mock -r fedora-5-i386-core foobar.spec > > > > > > > > Of course it's not. That macro only gets defined if using the FE > > > > buildsystem (and/or) building from FE's Makefiles, ie, 'make mockbuild'. > > > > I had assumed this was what you were referring to in your original post. > > > > > > He said he was using mock, and mock pulls in the required macro > > > definitions by default courtesy of the [groups] repo, which points to > > > http://fedoraproject.org/buildgroups/development/i386/ > > > > > > So a mock build should be the same as an FE buildsystem build in this > > > respect. The root.log from the mock build should show buildsys-macros > > > being installed. > > > > > > Paul. > > > > The problem is : > > cd /var/lib/mock/fedora-development-i386-core/root/etc/rpm > > ls > > nothing > > and i would be able to find macros.disttag containing : > > %fedora 5 > > %dist .fc5 > > > > So it seems mock build is not the same as an FE buildsystem build or i > > do something wrong ? > > Is there no reference to buildsys-macros > in /var/lib/mock/fedora-development-i386-core/result/root.log? No see the root.log above. > > > Or it's because in FE buildsystem i do a make tag before requesting a > > build ? > > No, that's a cvs tag, nothing to do with dist tag. > > Paul. > > ------------ ensuring dir /var/lib/mock/fedora-development-i386-core/state Cleaning Root ensuring dir /var/lib/mock/fedora-development-i386-core ensuring dir /var/lib/mock/fedora-development-i386-core/root ensuring dir /var/lib/mock/fedora-development-i386-core/state ensuring dir /home/tanguy/mock ensuring dir /var/lib/mock/fedora-development-i386-core ensuring dir /var/lib/mock/fedora-development-i386-core/root ensuring dir /var/lib/mock/fedora-development-i386-core/state ensuring dir /home/tanguy/mock ensuring dir /var/lib/mock/fedora-development-i386-core/root/var/lib/rpm ensuring dir /var/lib/mock/fedora-development-i386-core/root/var/log ensuring dir /var/lib/mock/fedora-development-i386-core/root/dev ensuring dir /var/lib/mock/fedora-development-i386-core/root/etc/rpm ensuring dir /var/lib/mock/fedora-development-i386-core/root/tmp ensuring dir /var/lib/mock/fedora-development-i386-core/root/var/tmp ensuring dir /var/lib/mock/fedora-development-i386-core/root/etc/yum.repos.d ensuring dir /var/lib/mock/fedora-development-i386-core/root/proc ensuring dir /var/lib/mock/fedora-development-i386-core/root/dev/pts ensuring dir /var/lib/mock/fedora-development-i386-core/root/proc ensuring dir /var/lib/mock/fedora-development-i386-core/root/dev/pts /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core/root groupinstall build ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: autoconf noarch 2.59-5.1 core 639 k automake noarch 1.9.6-2 core 487 k automake14 noarch 1.4p6-12.1 core 205 k automake15 noarch 1.5-14 core 239 k automake16 noarch 1.6.3-5.1 core 248 k automake17 noarch 1.7.9-6.1 core 286 k binutils i386 2.16.91.0.5-1 core 3.2 M bison i386 2.1-1.1 core 494 k byacc i386 1.9-29.1 core 36 k bzip2 i386 1.0.3-2.1 core 47 k cpio i386 2.6-11.1 core 116 k ctags i386 5.5.4-4.1 core 120 k diffstat i386 1.41-1.1 core 17 k diffutils i386 2.8.1-15.1 core 208 k doxygen i386 1:1.4.6-1 core 2.3 M elfutils i386 0.119-1 core 152 k flex i386 2.5.4a-37 core 124 k gcc i386 4.1.0-0.20 core 4.2 M gcc-c++ i386 4.1.0-0.20 core 3.0 M gdb i386 6.3.0.0-1.98 core 2.7 M gettext i386 0.14.5-2.2 core 1.4 M gzip i386 1.3.5-6.1 core 97 k indent i386 2.2.9-11 core 92 k intltool i386 0.34.1-1.1 core 112 k libtool i386 1.5.22-1 core 677 k make i386 1:3.80-10 core 342 k patch i386 2.5.4-29.1 core 62 k patchutils i386 0.2.31-2.1 core 107 k perl-XML-Dumper noarch 0.79-1.1 core 21 k perl-XML-Parser i386 2.34-6.1 core 210 k perl-XML-SAX noarch 0.13-1 core 75 k pkgconfig i386 1:0.20-2.1 core 54 k redhat-rpm-config noarch 8.0.39-1.1 core 44 k rpm-build i386 4.4.2-15 core 532 k strace i386 4.5.14-1 core 97 k tar i386 1.15.1-11.1 core 735 k udev i386 078-8 core 1.0 M unzip i386 5.52-1 core 150 k Installing for dependencies: MAKEDEV i386 3.21-1 core 135 k SysVinit i386 2.86-2 core 110 k audit-libs i386 1.1.3-1 core 26 k basesystem noarch 8.0-5.1 core 2.7 k bash i386 3.1-5 core 1.8 M beecrypt i386 4.1.2-9.1 core 107 k bzip2-libs i386 1.0.3-2.1 core 34 k chkconfig i386 1.3.26-1 core 141 k coreutils i386 5.93-7 core 3.3 M cpp i386 4.1.0-0.20 core 2.3 M cracklib i386 2.8.6-1.1 core 56 k cracklib-dicts i386 2.8.6-1.1 core 3.3 M db4 i386 4.3.29-1.1 core 854 k device-mapper i386 1.02.02-3 core 544 k dmraid i386 1.0.0.rc9-FC5_5 core 460 k e2fsprogs i386 1.38-6 core 917 k e2fsprogs-libs i386 1.38-6 core 103 k elfutils-libelf i386 0.119-1 core 46 k elfutils-libs i386 0.119-1 core 95 k ethtool i386 3-1.1 core 54 k expat i386 1.95.8-8 core 73 k fedora-release noarch 4-99.rawhide core 400 k file i386 4.16-5 core 303 k filesystem i386 2.3.7-1.1 core 16 k findutils i386 1:4.2.27-3 core 291 k gawk i386 3.1.5-5 core 1.7 M gdbm i386 1.8.0-26 core 26 k glibc i686 2.3.90-34 core 4.9 M glibc-common i386 2.3.90-34 core 16 M glibc-devel i386 2.3.90-34 core 1.9 M glibc-headers i386 2.3.90-34 core 598 k glibc-kernheaders i386 3.0-4 core 723 k grep i386 2.5.1-51.1 core 172 k info i386 4.8-9 core 161 k initscripts i386 8.25-1 core 1.1 M iproute i386 2.6.15-1 core 790 k iputils i386 20020927-33 core 107 k krb5-libs i386 1.4.3-3 core 534 k less i386 394-2 core 97 k libacl i386 2.2.32-2.1.1 core 17 k libattr i386 2.4.24-2.1 core 9.8 k libgcc i386 4.1.0-0.20 core 43 k libgomp i386 4.1.0-0.20 core 31 k libselinux i386 1.29.6-1 core 81 k libsepol i386 1.11.12-1 core 124 k libsetrans i386 0.1.18-1 core 12 k libstdc++ i386 4.1.0-0.20 core 299 k libstdc++-devel i386 4.1.0-0.20 core 9.5 M libtermcap i386 2.0.8-44 core 13 k lvm2 i386 2.02.01-1.1 core 948 k m4 i386 1.4.4-1.1 core 112 k mingetty i386 1.07-5.1 core 18 k mkinitrd i386 5.0.18-1 core 580 k mktemp i386 3:1.5-23.1 core 13 k module-init-tools i386 3.2-0.pre9.2 core 382 k ncurses i386 5.5-18 core 1.1 M neon i386 0.25.5-1 core 91 k net-tools i386 1.60-60 core 352 k openssl i686 0.9.8a-5 core 1.3 M pam i386 0.99.2.1-3 core 920 k pcre i386 6.3-1.1 core 126 k perl i386 4:5.8.8-1 core 12 M perl-Compress-Zlib i386 1.41-1.1 core 52 k perl-HTML-Parser i386 3.48-1 core 90 k perl-HTML-Tagset noarch 3.10-2 core warning: binutils-2.16.91.0.5-1: Header V3 DSA signature: NOKEY, key ID 30c9ecf8 14 k perl-URI noarch 1.35-2.1 core 117 k perl-XML-NamespaceSupport noarch 1.09-1.1 core 15 k perl-libwww-perl noarch 5.805-1 core 376 k popt i386 1.10.2-15 core 65 k procps i386 3.2.6-3 core 199 k psmisc i386 21.8-1.1 core 49 k python i386 2.4.2-3 core 5.8 M readline i386 5.0-3.1 core 206 k rpm i386 4.4.2-15 core 642 k rpm-libs i386 4.4.2-15 core 924 k sed i386 4.1.4-1.1 core 202 k setup noarch 2.5.48-1 core 32 k shadow-utils i386 2:4.0.14-1 core 929 k sqlite i386 3.3.3-1 core 198 k sysklogd i386 1.4.1-34 core 71 k termcap noarch 1:5.4-7.1 core 263 k tzdata noarch 2006a-1 core 488 k util-linux i386 2.13-0.14 core 1.7 M zlib i386 1.2.3-1.1 core 48 k Transaction Summary ============================================================================= Install 122 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 108 M Installed: autoconf.noarch 0:2.59-5.1 automake.noarch 0:1.9.6-2 automake14.noarch 0:1.4p6-12.1 automake15.noarch 0:1.5-14 automake16.noarch 0:1.6.3-5.1 automake17.noarch 0:1.7.9-6.1 binutils.i386 0:2.16.91.0.5-1 bison.i386 0:2.1-1.1 byacc.i386 0:1.9-29.1 bzip2.i386 0:1.0.3-2.1 cpio.i386 0:2.6-11.1 ctags.i386 0:5.5.4-4.1 diffstat.i386 0:1.41-1.1 diffutils.i386 0:2.8.1-15.1 doxygen.i386 1:1.4.6-1 elfutils.i386 0:0.119-1 flex.i386 0:2.5.4a-37 gcc.i386 0:4.1.0-0.20 gcc-c++.i386 0:4.1.0-0.20 gdb.i386 0:6.3.0.0-1.98 gettext.i386 0:0.14.5-2.2 gzip.i386 0:1.3.5-6.1 indent.i386 0:2.2.9-11 intltool.i386 0:0.34.1-1.1 libtool.i386 0:1.5.22-1 make.i386 1:3.80-10 patch.i386 0:2.5.4-29.1 patchutils.i386 0:0.2.31-2.1 perl-XML-Dumper.noarch 0:0.79-1.1 perl-XML-Parser.i386 0:2.34-6.1 perl-XML-SAX.noarch 0:0.13-1 pkgconfig.i386 1:0.20-2.1 redhat-rpm-config.noarch 0:8.0.39-1.1 rpm-build.i386 0:4.4.2-15 strace.i386 0:4.5.14-1 tar.i386 0:1.15.1-11.1 udev.i386 0:078-8 unzip.i386 0:5.52-1 Dependency Installed: MAKEDEV.i386 0:3.21-1 SysVinit.i386 0:2.86-2 audit-libs.i386 0:1.1.3-1 basesystem.noarch 0:8.0-5.1 bash.i386 0:3.1-5 beecrypt.i386 0:4.1.2-9.1 bzip2-libs.i386 0:1.0.3-2.1 chkconfig.i386 0:1.3.26-1 coreutils.i386 0:5.93-7 cpp.i386 0:4.1.0-0.20 cracklib.i386 0:2.8.6-1.1 cracklib-dicts.i386 0:2.8.6-1.1 db4.i386 0:4.3.29-1.1 device-mapper.i386 0:1.02.02-3 dmraid.i386 0:1.0.0.rc9-FC5_5 e2fsprogs.i386 0:1.38-6 e2fsprogs-libs.i386 0:1.38-6 elfutils-libelf.i386 0:0.119-1 elfutils-libs.i386 0:0.119-1 ethtool.i386 0:3-1.1 expat.i386 0:1.95.8-8 fedora-release.noarch 0:4-99.rawhide file.i386 0:4.16-5 filesystem.i386 0:2.3.7-1.1 findutils.i386 1:4.2.27-3 gawk.i386 0:3.1.5-5 gdbm.i386 0:1.8.0-26 glibc.i686 0:2.3.90-34 glibc-common.i386 0:2.3.90-34 glibc-devel.i386 0:2.3.90-34 glibc-headers.i386 0:2.3.90-34 glibc-kernheaders.i386 0:3.0-4 grep.i386 0:2.5.1-51.1 info.i386 0:4.8-9 initscripts.i386 0:8.25-1 iproute.i386 0:2.6.15-1 iputils.i386 0:20020927-33 krb5-libs.i386 0:1.4.3-3 less.i386 0:394-2 libacl.i386 0:2.2.32-2.1.1 libattr.i386 0:2.4.24-2.1 libgcc.i386 0:4.1.0-0.20 libgomp.i386 0:4.1.0-0.20 libselinux.i386 0:1.29.6-1 libsepol.i386 0:1.11.12-1 libsetrans.i386 0:0.1.18-1 libstdc++.i386 0:4.1.0-0.20 libstdc++-devel.i386 0:4.1.0-0.20 libtermcap.i386 0:2.0.8-44 lvm2.i386 0:2.02.01-1.1 m4.i386 0:1.4.4-1.1 mingetty.i386 0:1.07-5.1 mkinitrd.i386 0:5.0.18-1 mktemp.i386 3:1.5-23.1 module-init-tools.i386 0:3.2-0.pre9.2 ncurses.i386 0:5.5-18 neon.i386 0:0.25.5-1 net-tools.i386 0:1.60-60 openssl.i686 0:0.9.8a-5 pam.i386 0:0.99.2.1-3 pcre.i386 0:6.3-1.1 perl.i386 4:5.8.8-1 perl-Compress-Zlib.i386 0:1.41-1.1 perl-HTML-Parser.i386 0:3.48-1 perl-HTML-Tagset.noarch 0:3.10-2 perl-URI.noarch 0:1.35-2.1 perl-XML-NamespaceSupport.noarch 0:1.09-1.1 perl-libwww-perl.noarch 0:5.805-1 popt.i386 0:1.10.2-15 procps.i386 0:3.2.6-3 psmisc.i386 0:21.8-1.1 python.i386 0:2.4.2-3 readline.i386 0:5.0-3.1 rpm.i386 0:4.4.2-15 rpm-libs.i386 0:4.4.2-15 sed.i386 0:4.1.4-1.1 setup.noarch 0:2.5.48-1 shadow-utils.i386 2:4.0.14-1 sqlite.i386 0:3.3.3-1 sysklogd.i386 0:1.4.1-34 termcap.noarch 1:5.4-7.1 tzdata.noarch 0:2006a-1 util-linux.i386 0:2.13-0.14 zlib.i386 0:1.2.3-1.1 ensuring dir /var/lib/mock/fedora-development-i386-core/root/proc ensuring dir /var/lib/mock/fedora-development-i386-core/root/dev/pts ensuring dir /var/lib/mock/fedora-development-i386-core/root/proc ensuring dir /var/lib/mock/fedora-development-i386-core/root/dev/pts /sbin/runuser -c 'rpm -Uvh --nodeps /builddir/build/originals/qucs-0.0.8-1.src.rpm' mockbuild qucs warning: user tanguy does not exist - using root warning: group tanguy does not exist - using root ################################################## warning: user tanguy does not exist - using root warning: group tanguy does not exist - using root warning: user tanguy does not exist - using root warning: group tanguy does not exist - using root warning: Could not canonicalize hostname: bureau.maison Building target platforms: i386 Building for target i386 Wrote: /builddir/build/SRPMS/qucs-0.0.8-1.src.rpm ensuring dir /var/lib/mock/fedora-development-i386-core/root/proc ensuring dir /var/lib/mock/fedora-development-i386-core/root/dev/pts /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core/root resolvedep 'desktop-file-utils' 'qt-devel' 0:desktop-file-utils-0.10-4.i386 1:qt-devel-3.3.5-12.i386 0:desktop-file-utils-0.10-4.i386 1:qt-devel-3.3.5-12.i386 ensuring dir /var/lib/mock/fedora-development-i386-core/root/proc ensuring dir /var/lib/mock/fedora-development-i386-core/root/dev/pts /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core/root install 'desktop-file-utils' 'qt-devel' warning: libmng-devel-1.0.9-3.1: Header V3 DSA signature: NOKEY, key ID 30c9ecf8 ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: desktop-file-utils i386 0.10-4 core 57 k qt-devel i386 1:3.3.5-12 core 14 M Installing for dependencies: fontconfig i386 2.3.93.cvs20060131-2 core 179 k fontconfig-devel i386 2.3.93.cvs20060131-2 core 168 k freetype i386 2.1.10-5.1 core 515 k freetype-devel i386 2.1.10-5.1 core 560 k glib2 i386 2.9.5-1 core 623 k libICE i386 1.0.0-2 core 51 k libICE-devel i386 1.0.0-2 core 13 k libSM i386 1.0.0-2 core 25 k libSM-devel i386 1.0.0-2 core 8.9 k libX11 i386 1.0.0-2 core 748 k libX11-devel i386 1.0.0-2 core 677 k libXau i386 1.0.0-2 core 17 k libXau-devel i386 1.0.0-2 core 10 k libXcursor i386 1.1.5.2-2 core 30 k libXcursor-devel i386 1.1.5.2-2 core 14 k libXdmcp i386 1.0.0-2 core 18 k libXdmcp-devel i386 1.0.0-2 core 6.8 k libXext i386 1.0.0-3 core 34 k libXext-devel i386 1.0.0-3 core 57 k libXfixes i386 3.0.1.2-2 core 13 k libXft i386 2.1.8.2-2 core 43 k libXft-devel i386 2.1.8.2-2 core 16 k libXinerama i386 1.0.1-1 core 9.3 k libXinerama-devel i386 1.0.1-1 core 4.6 k libXrandr i386 1.1.0.2-2 core 14 k libXrandr-devel i386 1.1.0.2-2 core 15 k libXrender i386 0.9.0.2-3 core 26 k libXrender-devel i386 0.9.0.2-3 core 8.2 k libXt i386 1.0.0-2 core 164 k libXt-devel i386 1.0.0-2 core 336 k libjpeg i386 6b-36.1 core 133 k libjpeg-devel i386 6b-36.1 core 105 k libmng i386 1.0.9-3.1 core 147 k libmng-devel i386 1.0.9-3.1 core 53 k libpng i386 2:1.2.8-2.1 core 161 k libpng-devel i386 2:1.2.8-2.1 core 176 k qt i386 1:3.3.5-12 core 3.4 M xorg-x11-filesystem noarch 0.99.2-3 core 5.4 k xorg-x11-proto-devel i386 7.0-1 core 262 k zlib-devel i386 1.2.3-1.1 core 99 k Transaction Summary ============================================================================= Install 42 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 23 M Installed: desktop-file-utils.i386 0:0.10-4 qt-devel.i386 1:3.3.5-12 Dependency Installed: fontconfig.i386 0:2.3.93.cvs20060131-2 fontconfig-devel.i386 0:2.3.93.cvs20060131-2 freetype.i386 0:2.1.10-5.1 freetype-devel.i386 0:2.1.10-5.1 glib2.i386 0:2.9.5-1 libICE.i386 0:1.0.0-2 libICE-devel.i386 0:1.0.0-2 libSM.i386 0:1.0.0-2 libSM-devel.i386 0:1.0.0-2 libX11.i386 0:1.0.0-2 libX11-devel.i386 0:1.0.0-2 libXau.i386 0:1.0.0-2 libXau-devel.i386 0:1.0.0-2 libXcursor.i386 0:1.1.5.2-2 libXcursor-devel.i386 0:1.1.5.2-2 libXdmcp.i386 0:1.0.0-2 libXdmcp-devel.i386 0:1.0.0-2 libXext.i386 0:1.0.0-3 libXext-devel.i386 0:1.0.0-3 libXfixes.i386 0:3.0.1.2-2 libXft.i386 0:2.1.8.2-2 libXft-devel.i386 0:2.1.8.2-2 libXinerama.i386 0:1.0.1-1 libXinerama-devel.i386 0:1.0.1-1 libXrandr.i386 0:1.1.0.2-2 libXrandr-devel.i386 0:1.1.0.2-2 libXrender.i386 0:0.9.0.2-3 libXrender-devel.i386 0:0.9.0.2-3 libXt.i386 0:1.0.0-2 libXt-devel.i386 0:1.0.0-2 libjpeg.i386 0:6b-36.1 libjpeg-devel.i386 0:6b-36.1 libmng.i386 0:1.0.9-3.1 libmng-devel.i386 0:1.0.9-3.1 libpng.i386 2:1.2.8-2.1 libpng-devel.i386 2:1.2.8-2.1 qt.i386 1:3.3.5-12 xorg-x11-filesystem.noarch 0:0.99.2-3 xorg-x11-proto-devel.i386 0:7.0-1 zlib-devel.i386 0:1.2.3-1.1 cd /;/sbin/runuser -c 'rpmbuild --rebuild --target i386 --nodeps /builddir/build/SRPMS/qucs-0.0.8-1.src.rpm' mockbuild Cleaning up... Done. ------------------ From nicolas.mailhot at laposte.net Sat Feb 4 18:21:21 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 04 Feb 2006 19:21:21 +0100 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: <878xsrs1rc.fsf@kosh.bigo.ensc.de> References: <87k6ccs4fu.fsf@kosh.bigo.ensc.de> <87fyn0rxbd.fsf@kosh.bigo.ensc.de> <1139000311.3377.32.camel@localhost> <1139054679.24024.19.camel@rousalka.dyndns.org> <878xsrs1rc.fsf@kosh.bigo.ensc.de> Message-ID: <1139077281.3705.4.camel@rousalka.dyndns.org> Le samedi 04 f?vrier 2006 ? 14:16 +0100, Enrico Scholz a ?crit : > nicolas.mailhot at laposte.net (Nicolas Mailhot) writes: > > > You have exactly the same problem with fonts and fc-cache. > > The fc-cache case is easier because the locations of all possible cache > files are known to the 'fc-cache' program. For gtk-update-icon-cache, > you have to enumerate them manually. I'm surprised, if gtk-update-icon-cache needs to be told exactly where files changed, it's either a boog in gtk-update-icon-cache or file location is underspecified. The use case seems to be pretty similar to fc-cache. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From bugzilla at redhat.com Sat Feb 4 18:22:54 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 13:22:54 -0500 Subject: [Bug 180015] New: Review Request: OTRS - Open Ticket Request System Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180015 Summary: Review Request: OTRS - Open Ticket Request System Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: imlinux at gmail.com QAContact: fedora-extras-list at redhat.com Spec: http://mmcgrath.net/~mmcgrath/otrs/otrs.spec SRPM: http://mmcgrath.net/~mmcgrath/otrs/otrs-2.0.4-1.src.rpm Description: OTRS is an Open source Ticket Request System (also well known as trouble ticket system) with many features to manage customer telephone calls and e-mails. The system is built to allow your support, sales, pre-sales, billing, internal IT, helpdesk, etc. department to react quickly to inbound inquiries. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 4 19:19:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 14:19:33 -0500 Subject: [Bug 177083] Review Request: xmldiff In-Reply-To: Message-ID: <200602041919.k14JJXP9019251@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xmldiff https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177083 ------- Additional Comments From ville.skytta at iki.fi 2006-02-04 14:19 EST ------- The patch in the message pointed out in comment 19 fixes the test suite on x86_64. FWIW, it still has these compilation warnings: extensions/maplookup.c: In function 'fmes_node_equal': extensions/maplookup.c:160: warning: cast from pointer to integer of different size extensions/maplookup.c:164: warning: cast from pointer to integer of different size -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 19:21:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 14:21:07 -0500 Subject: [Bug 177083] Review Request: xmldiff In-Reply-To: Message-ID: <200602041921.k14JL7Pq019491@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xmldiff https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177083 ------- Additional Comments From ville.skytta at iki.fi 2006-02-04 14:21 EST ------- (In reply to comment #20) > fixes the test suite on x86_64 s/test suite/test suite failure/ -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 19:43:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 14:43:47 -0500 Subject: [Bug 177083] Review Request: xmldiff In-Reply-To: Message-ID: <200602041943.k14JhlPl022916@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xmldiff https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177083 stickster at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |CLOSED Resolution| |NOTABUG ------- Additional Comments From stickster at gmail.com 2006-02-04 14:43 EST ------- Great news. I will patch, remove the ExcludeArch, and push a new release. Thanks for finding an x86_64 to test this, Ville. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 19:50:03 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 14:50:03 -0500 Subject: [Bug 179988] Review Request: freealut - Implementation of OpenAL's ALUT standard In-Reply-To: Message-ID: <200602041950.k14Jo36u023788@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: freealut - Implementation of OpenAL's ALUT standard https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179988 ivazquez at ivazquez.net changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From ivazquez at ivazquez.net 2006-02-04 14:49 EST ------- - Consider including examples/*.c in -devel %doc APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 4 20:16:55 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 15:16:55 -0500 Subject: [Bug 178310] Review Request: w3c-libwww - An HTTP library of common code In-Reply-To: Message-ID: <200602042016.k14KGtAN027376@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: w3c-libwww - An HTTP library of common code https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178310 kevin at tummy.com changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Package Review |p7zip ------- Additional Comments From kevin at tummy.com 2006-02-04 15:16 EST ------- Oddly, it looks like there was talk of making a 5.4.1 release last year: http://lists.w3.org/Archives/Public/www-lib/2005OctDec/0014.html That seems to be updated in CVS, but no release was pushed out. I see several security fixes in the Changelog in CVS, so perhaps you should base off a CVS snapshot? and/or check with the mailing list to get them moving again on a release? It would be good to link against the system expat, not sure how easy that will be to do however. As a temp measure, perhaps a patch to update them to the latest expat versions? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 4 21:34:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 16:34:21 -0500 Subject: [Bug 179910] Review Request: commoncpp C++ framework In-Reply-To: Message-ID: <200602042134.k14LYLda004774@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: commoncpp C++ framework https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179910 ------- Additional Comments From andreas at bawue.net 2006-02-04 16:34 EST ------- 1.3.23 is out? hmmm. gonna update that then. The webpage referred to 1.3.22. About the build-dependencies, mock does build the package as is. I checked. The sagefuard is a good idea. The modification of ld.so.conf is taken care of, the Makefile.in is being patched accordingly. Thanks so far for the suggestions. I'm gonna update the package. Only thing I'm unsure about are the .la files. It seems they were being used by ccrtp. If so, removing them is probably not a good idea. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 4 22:21:45 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 17:21:45 -0500 Subject: [Bug 180034] New: Review Request: perl-Font-TTF (part of the dejavu-fonts toolchain) Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180034 Summary: Review Request: perl-Font-TTF (part of the dejavu-fonts toolchain) Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: Nicolas.Mailhot at laPoste.net QAContact: fedora-extras-list at redhat.com The spec file is really simple so I'm attaching it to the bug The perl sources can be downloaded at http://search.cpan.org/CPAN/authors/id/M/MH/MHOSKEN/Font-TTF-0.37.tar.gz Description: This is a perl module to manipulate TTF files and do all sorts of strange things with them. It's used by the free font project dejavu (http://dejavu.sourceforge.net/wiki/index.php/FontForge) Since I'm FE's dejavu maintainer, I'd like to get the full dejavu toolchain into FE to package dejavu from sources instead of pushing prebuild TTFs. dejavu is not GPL'd so it's not a requirement. However : - the spirit of Fedora is to push free software, so IMHO we should follow GPL requirements even if upstream does not force them on us - Fedora is sorely missing quality fonts and having the full font creation toolset packaged is my little attempt to get more people contributing glyphs to dejavu or starting their own project (when you force font creators to buy expensive closed software tools because the free ones are hard to get you pretty much ensure they'll never contribute to FOSS projects) - the other big dejavu requirement has been packaged and updated to allow this, and I'd hate this effort to be wasted (bug #170177) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 4 23:32:40 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 18:32:40 -0500 Subject: [Bug 176374] Review Request: nagios-plugins In-Reply-To: Message-ID: <200602042332.k14NWeU9019243@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: nagios-plugins https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176374 ------- Additional Comments From imlinux at gmail.com 2006-02-04 18:32 EST ------- Hey Jesse, can you attach a build log for when MySQL fails? I build it in mock --arch=x86_64 and it seemed to build correctly. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 5 01:07:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 20:07:11 -0500 Subject: [Bug 174494] Review Request: libopensync-plugin-irmc In-Reply-To: Message-ID: <200602050107.k1517Bpo029439@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libopensync-plugin-irmc https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174494 andreas.bierfert at lowlatency.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From andreas.bierfert at lowlatency.de 2006-02-04 20:07 EST ------- Thanks. Imported and pushed. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 5 01:19:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 20:19:01 -0500 Subject: [Bug 170973] Review Request: gnomebaker: Gnome CD/DVD burner In-Reply-To: Message-ID: <200602050119.k151J1gU030542@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnomebaker: Gnome CD/DVD burner https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170973 ------- Additional Comments From bdpepple at ameritech.net 2006-02-04 20:18 EST ------- Updated package to new version, which fixes the problem with glade. Spec: http://piedmont.homelinux.org/fedora/gnomebaker/gnomebaker.spec SRPM: http://piedmont.homelinux.org/fedora/gnomebaker/gnomebaker-0.5.1-1.src.rpm Note: This spec is currently set-up for FC5 only (gstreamer08-devel). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 5 01:19:45 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 20:19:45 -0500 Subject: [Bug 170973] Review Request: gnomebaker: Gnome CD/DVD burner In-Reply-To: Message-ID: <200602050119.k151JjKH030734@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnomebaker: Gnome CD/DVD burner https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170973 bdpepple at ameritech.net changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #120164|0 |1 is obsolete| | ------- Additional Comments From bdpepple at ameritech.net 2006-02-04 20:19 EST ------- (From update of attachment 120164) No longer relevent -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 5 01:27:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 20:27:53 -0500 Subject: [Bug 180034] Review Request: perl-Font-TTF (part of the dejavu-fonts toolchain) In-Reply-To: Message-ID: <200602050127.k151RrTu031597@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Font-TTF (part of the dejavu-fonts toolchain) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180034 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From tibbs at math.uh.edu 2006-02-04 20:27 EST ------- Generally you should supply a src.rpm; it makes the review process a bit easier and some of the review items require having it. My rpmlint complains: W: perl-Font-TTF wrong-file-end-of-line-encoding /usr/share/doc/perl-Font-TTF-0.37/README.TXT and indeed README.TXT has CRLF endings. However, there are several packages which include documentation files with DOS-style line endings so I don't believe this is a blocker. Fix it up if you like. Other issues: I can't review spec file naming. I can't review the source used to build the SRPM as none was provided. BuildRequires: perl is not permitted. The license does not seem to be GPL. I see only: The Perl TTF module is licensed under the Perl Artistic License. I don't understand this comment in the %files section: # For arch-specific packages: vendorarch I can't install the resulting RPM: error: Failed dependencies: perl(Win32) is needed by perl-Font-TTF-0.37-1.noarch perl(Win32::Registry) is needed by perl-Font-TTF-0.37-1.noarch I believe this is the result of lib/Font/TTF/Win32.pm. I'm not sure what would be best to do here. You can fix it with a quick rm %{buildroot}/%{perl_vendorlib}/Font/TTF/Win32.pm in the %install section but I'm not completely sure if that's acceptable. Another solution would be to postprocess the output of the dependency generator, but that's rather unpalatable as well (and more complicated than just deleting the file). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From pertusus at free.fr Fri Feb 3 21:12:38 2006 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 3 Feb 2006 22:12:38 +0100 Subject: Please help comment on hdf/netcdf compatability In-Reply-To: <43E3C33D.3030403@cora.nwra.com> References: <43E3C33D.3030403@cora.nwra.com> Message-ID: <20060203211238.GB2716@free.fr> On Fri, Feb 03, 2006 at 01:55:25PM -0700, Orion Poplawski wrote: > I maintain hdf 4.2r1 in FE. I'm running into an issue with > compatibility with netcdf. By default, hdf provides the netcdf api as > well, unless compiled with -DHAVE_NETCDF. > I also maintain gdl, which can be linked against both hdf and netcdf, > but I get complaints. I don't know if gdl can use the netcdf API in the > hdf library or not - looking into it (if you know, tell me!). What I know is that hdf4 implements the netcdf 2 API. The netcdf 3 is backward compatible, so it also contains the netcdf 2 API. > Those of you who use both, what would you like to see? I believe it is right to have the netcdf includes that come with hdf in the hdf include dir, not directly in /usr/include. This is like that allready. In case it could be of use to you, I attach to my mail the autoconf files I use when I want to detect hdf4 or netcdf, in case it is of use for you. -- Pat -------------- next part -------------- dnl example of use dnl AC_CHECK_NETCDF( dnl [ dnl LIBS="$LIBS $NC_LIBS" dnl LDFLAGS="$LDFLAGS $NC_LDFLAGS" dnl CPPFLAGS="$CPPFLAGS $NC_CPPFLAGS" dnl ], dnl [ dnl echo "*** Use --with-netcdf for the root netcdf directory." dnl echo "*** Otherwise use --with-netcdf-include switch for includes directory" dnl echo "*** and --with-netcdf-libdir switch for libraries directory." dnl AC_MSG_ERROR([netcdf library and netcdf headers are required.]) dnl ] dnl ) # Check for the netcdf library. # AC_CHECK_NETCDF([ACTION-IF-FOUND],[ACTION-IF-NOT-FOUND],[INTERFACE-NR]) # if interface number is given, check for a specific interface # sets NC_LDFLAGS, NC_LIBS, and, by calling other macros # NC_CPPFLAGS and maybe NC_NETCDF_3_CPPFLAG AC_DEFUN([AC_CHECK_NETCDF], [ AC_ARG_WITH([netcdf], [AS_HELP_STRING([--with-netcdf=ARG],[netcdf directory])], [NC_PATH=$withval], [NC_PATH=""]) AC_ARG_WITH([netcdf_include], [AS_HELP_STRING([--with-netcdf-include=ARG],[netcdf include directory])], [NC_PATH_INC=$withval], [NC_PATH_INC=""]) AC_ARG_WITH([netcdf_libdir], [AS_HELP_STRING([--with-netcdf-libdir=ARG],[netcdf library directory])], [NC_PATH_LIBDIR=$withval], [NC_PATH_LIBDIR=""]) AS_IF([test "z$NC_PATH" != "z"], [ AS_IF([test "z$NC_PATH_LIBDIR" = "z"],[NC_PATH_LIBDIR="$NC_PATH/lib"]) AS_IF([test "z$NC_PATH_INC" = "z"],[NC_PATH_INC="$NC_PATH/include"]) ]) ac_netcdf_ok='no' NC_LIBS= NC_LDFLAGS= ac_nc_save_LDFLAGS=$LDFLAGS ac_nc_save_LIBS=$LIBS ac_check_nc_func_checked='ncopen' ac_check_nc_interface= dnl the interface number isn't quoted with "" otherwise a newline dnl following the number isn't stripped. m4_if([$3],[],[ac_check_nc_interface=2],[ac_check_nc_interface=$3]) AS_IF([test "z$ac_check_nc_interface" = 'z3'], [ac_check_nc_func_checked='nc_open']) AS_IF([test "z$NC_PATH_LIBDIR" != "z"], [ NC_LDFLAGS="-L$NC_PATH_LIBDIR" LDFLAGS="$LDFLAGS $NC_LDFLAGS" dnl the autoconf internal cache isn't avoided because we really check for dnl libnetcdf, other libraries that implement the same api have other names dnl AC_LINK_IFELSE([AC_LANG_CALL([],[$ac_check_func_checked])], AC_CHECK_LIB([netcdf],[$ac_check_nc_func_checked], [ NC_LIBS='-lnetcdf' ac_netcdf_ok='yes' ]) ], [ for ac_netcdf_libdir in "" \ /usr/local/netcdf-${ac_check_nc_interface}/lib \ /opt/netcdf-${ac_check_nc_interface}/lib \ /usr/netcdf-${ac_check_nc_interface}/lib \ /usr/local/lib/netcdf-${ac_check_nc_interface} \ /opt/lib/netcdf-${ac_check_nc_interface} \ /usr/lib/netcdf-${ac_check_nc_interface} \ /usr/local/netcdf/lib /opt/netcdf/lib \ /usr/netcdf/lib /usr/local/lib/netcdf /opt/lib/netcdf \ /usr/lib/netcdf ; do AS_IF([test "z$ac_netcdf_libdir" = 'z'], [NC_LDFLAGS=], [ AC_MSG_CHECKING([for netcdf libraries in $ac_netcdf_libdir]) NC_LDFLAGS="-L$ac_netcdf_libdir" ]) LDFLAGS="$LDFLAGS $NC_LDFLAGS" LIBS="$LIBS -lnetcdf" dnl we have to avoid the autoconf internal cache in that case AC_LINK_IFELSE([AC_LANG_CALL([],[$ac_check_nc_func_checked])], [ NC_LIBS='-lnetcdf' ac_netcdf_ok='yes' AS_IF([test "z$ac_netcdf_libdir" != 'z'],[AC_MSG_RESULT([yes])]) ], [ AS_IF([test "z$ac_netcdf_libdir" != 'z'],[AC_MSG_RESULT([no])]) ]) AS_IF([test $ac_netcdf_ok = 'yes'],[break]) LDFLAGS=$ac_nc_save_LDFLAGS LIBS=$ac_nc_save_LIBS done ]) LDFLAGS=$ac_nc_save_LDFLAGS LIBS=$ac_nc_save_LIBS AC_SUBST([NC_LDFLAGS]) AC_SUBST([NC_LIBS]) ac_netcdf_header='no' AS_IF([test "z$NC_PATH_INC" != "z"], [ AC_CHECK_NETCDF_HEADER([$NC_PATH_INC], [ac_netcdf_header='yes'], [ac_netcdf_header='no'], [$ac_check_nc_interface]) ], [ for ac_netcdf_incdir in "" \ /usr/local/netcdf-${ac_check_nc_interface}/include \ /opt/netcdf-${ac_check_nc_interface}/include \ /usr/netcdf-${ac_check_nc_interface}/include \ /usr/local/include/netcdf-${ac_check_nc_interface} \ /opt/include/netcdf-${ac_check_nc_interface} \ /usr/include/netcdf-${ac_check_nc_interface} \ /usr/local/netcdf/include \ /opt/netcdf/include /usr/netcdf/include /usr/local/include/netcdf \ /opt/include/netcdf /usr/include/netcdf ; do AC_MSG_NOTICE([searching netcdf includes in $ac_netcdf_incdir]) AC_CHECK_NETCDF_HEADER([$ac_netcdf_incdir],[ac_netcdf_header='yes'], [ac_netcdf_header='no'],[$ac_check_nc_interface]) AS_IF([test $ac_netcdf_header = 'yes'],[break]) done ]) AS_IF([test "$ac_netcdf_ok" = 'no' -o "$ac_netcdf_header" = 'no'], [m4_if([$2], [], [:], [$2])], [m4_if([$1], [], [:], [$1])]) ]) -------------- next part -------------- # Check for the netcdf header. # AC_CHECK_NETCDF_HEADER([INCLUDE-DIR],[ACTION-IF-FOUND], # [ACTION-IF-NOT-FOUND],[INTERFACE-NR]) # if interface number is given, check for a specific interface # sets NC_CPPFLAGS and maybe NC_NETCDF_3_CPPFLAG AC_DEFUN([AC_CHECK_NETCDF_HEADER], [ NC_CPPFLAGS= ac_netcdf_h='no' ac_netcdf_h_compile='no' ac_netcdf_h_preproc='no' ac_nc_include_dir= ac_nc_header_interface= ac_nc_save_CPPFLAGS=$CPPFLAGS m4_if([$1],[],[:],[ ac_nc_include_dir="$1" AS_IF([test "z$ac_nc_include_dir" != "z"], [CPPFLAGS="$CPPFLAGS -I$ac_nc_include_dir"]) ]) m4_if([$4],[],[:],[ac_nc_header_interface=$4]) dnl dont use AC_CHECK_HEADERS to avoid autoconf internal caching AC_MSG_CHECKING([for netcdf.h with compiler]) AC_COMPILE_IFELSE([AC_LANG_SOURCE([[#include ]])], [ AC_MSG_RESULT([yes]) ac_netcdf_h_compile='yes' ], [ AC_MSG_RESULT([no]) ac_netcdf_h_compile='no' ]) AC_MSG_CHECKING([for netcdf.h with preprocessor]) AC_PREPROC_IFELSE([AC_LANG_SOURCE([[#include ]])], [ AC_MSG_RESULT([yes]) ac_netcdf_h_preproc='yes' ], [ AC_MSG_RESULT([no]) ac_netcdf_h_preproc='no' ]) CPPFLAGS="$ac_nc_save_CPPFLAGS" AS_IF([test $ac_netcdf_h_compile = 'yes'], [ac_netcdf_h='yes' AS_IF([test "z$ac_nc_header_interface" = 'z3'], [AC_CHECK_NETCDF_3_HEADER([$1], [ac_netcdf_h='yes'],[ac_netcdf_h='no'])]) ]) AS_IF([test "$ac_netcdf_h" = 'yes'], [ AS_IF([test "z$ac_nc_include_dir" != "z"], [NC_CPPFLAGS="-I$ac_nc_include_dir"]) m4_if([$2], [], [:], [$2]) ], [m4_if([$3], [], [:], [$3])]) AC_SUBST([NC_CPPFLAGS]) ]) AC_DEFUN([AC_CHECK_NETCDF_3_HEADER], [ NC_NETCDF_3_CPPFLAG= ac_check_netcdf_3_include= ac_check_netcdf_3_header='no' ac_nc_save_CPPFLAGS=$CPPFLAGS AC_MSG_CHECKING([for netcdf 3 interface]) m4_if([$1],[],[:],[ ac_check_netcdf_3_include="$1" ]) AS_IF([test "z$ac_check_netcdf_3_include" != "z"], [CPPFLAGS="$CPPFLAGS -I$ac_check_netcdf_3_include"]) AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include ]], [[int status; int ncid; status = nc_open("foo.nc", 0, &ncid); char vernum; vernum = *nc_inq_libvers();]])], [ AS_IF([test "z$ac_check_netcdf_3_include" != "z"], [NC_NETCDF_3_CPPFLAG="-I$ac_check_netcdf_3_include"]) ac_check_netcdf_3_header='yes' ],[ac_check_netcdf_3_header='no']) CPPFLAGS=$ac_nc_save_CPPFLAGS AS_IF([test "$ac_check_netcdf_3_header" = 'yes'], [ AC_MSG_RESULT([yes]) m4_if([$2], [], [:], [$2]) ], [ AC_MSG_RESULT([no]) m4_if([$3], [], [:], [$3]) ]) AC_SUBST([NC_NETCDF_3_CPPFLAG]) ]) -------------- next part -------------- dnl AC_CHECK_HDF : Check for hdf4 dnl args : action-if-yes, action-if-no AC_DEFUN([AC_CHECK_HDF4], [ AC_ARG_WITH([hdf4], [AS_HELP_STRING([--with-hdf4=ARG],[hdf4 directory])], [HDF4_PATH=$withval], [HDF4_PATH=""]) AC_ARG_WITH([hdf4_include], [AS_HELP_STRING([--with-hdf4-include=ARG],[hdf 4 include directory])], [HDF4_PATH_INC=$withval], [HDF4_PATH_INC=""]) AC_ARG_WITH([hdf4_libdir], [AS_HELP_STRING([--with-hdf4-libdir=ARG],[hdf 4 library directory])], [HDF4_PATH_LIBDIR=$withval], [HDF4_PATH_LIBDIR=""]) dnl This is a very common location for the hdf4 code. jhrg 10/11/05 AS_IF([test -d /usr/local/hdf], [HDF4_PATH="/usr/local/hdf"]) AS_IF([test "z$HDF4_PATH" != "z"], [ AS_IF([test "z$HDF4_PATH_LIBDIR" = "z"], [HDF4_PATH_LIBDIR="$HDF4_PATH/lib"]) AS_IF([test "z$HDF4_PATH_INC" = "z"], [HDF4_PATH_INC="$HDF4_PATH/include"]) ]) ac_hdf4_lib_ok='no' ac_hdf4_save_LDFLAGS=$LDFLAGS HDF4_LIBS= AS_IF([test "z$HDF4_PATH_LIBDIR" != "z"], [ HDF4_LDFLAGS="-L$HDF4_PATH_LIBDIR" LDFLAGS="$LDFLAGS $HDF4_LDFLAGS" AC_CHECK_HDF4_LIB([ac_hdf4_lib_ok='yes']) ], [ for ac_hdf4_libdir in "" /usr/local/hdf4.2r1/lib /opt/hdf4.2r1/lib \ /usr/hdf4.2r1/lib /usr/local/lib/hdf4.2r1 /opt/lib/hdf4.2r1 \ /usr/lib/hdf4.2r1 /usr/local/hdf/lib/ /opt/hdf/lib /usr/hdf/lib \ /usr/local/lib/hdf /opt/lib/hdf /usr/lib/hdf ; do AS_IF([test "z$ac_hdf4_libdir" = 'z'], [HDF4_LDFLAGS=], [ AC_MSG_NOTICE([searching hdf libraries in $ac_hdf4_libdir]) HDF4_LDFLAGS="-L$ac_hdf4_libdir" ]) LDFLAGS="$LDFLAGS $HDF4_LDFLAGS" AC_CHECK_HDF4_LIB([ac_hdf4_lib_ok='yes']) AS_IF([test $ac_hdf4_lib_ok = 'yes'],[break]) LDFLAGS=$ac_hdf4_save_LDFLAGS done ]) LDFLAGS=$ac_hdf4_save_LDFLAGS ac_hdf4_h='no' HDF4_CPPFLAGS= ac_hdf4_save_CPPFLAGS=$CPPFLAGS AS_IF([test "z$HDF4_PATH_INC" != "z"], [ HDF4_CPPFLAGS="-I$HDF4_PATH_INC" CPPFLAGS="$CPPFLAGS $HDF4_CPPFLAGS" AC_CHECK_HEADER_NOCACHE_HDF4([mfhdf.h],[ac_hdf4_h='yes']) ], [ for ac_hdf4_incdir in "" /usr/local/hdf4.2r1/include /opt/hdf4.2r1/include \ /usr/hdf4.2r1/include /usr/local/include/hdf4.2r1 \ /opt/include/hdf4.2r1 /usr/include/hdf4.2r1 /usr/local/hdf/include \ /opt/hdf/include /usr/hdf/include /usr/local/include/hdf \ /opt/include/hdf /usr/include/hdf ; do AS_IF([test "z$ac_hdf4_incdir" = 'z'], [HDF4_CPPFLAGS=], [ AC_MSG_NOTICE([searching hdf includes in $ac_hdf4_incdir]) HDF4_CPPFLAGS="-I$ac_hdf4_incdir" ]) CPPFLAGS="$CPPFLAGS $HDF4_CPPFLAGS" AC_CHECK_HEADER_NOCACHE_HDF4([mfhdf.h],[ac_hdf4_h='yes']) AS_IF([test $ac_hdf4_h = 'yes'],[break]) CPPFLAGS=$ac_hdf4_save_CPPFLAGS done ]) CPPFLAGS=$ac_hdf4_save_CPPFLAGS AS_IF([test "$ac_hdf4_h" = 'yes' -a "$ac_hdf4_lib_ok" = 'yes'], [m4_if([$1], [], [:], [$1])], [m4_if([$2], [], [:], [$2])]) AC_SUBST([HDF4_LIBS]) AC_SUBST([HDF4_CPPFLAGS]) AC_SUBST([HDF4_LDFLAGS]) ]) dnl check for the netcdf 2 interface provided by hdf AC_DEFUN([AC_CHECK_HDF4_NETCDF], [ ac_hdf4_netcdf_lib='no' ac_hdf4_netcdf_h='no' AC_CHECK_HDF4([ ac_hdf4_netcdf_save_LDFLAGS=$LDFLAGS ac_hdf4_netcdf_save_LIBS=$LIBS LIBS="$LIBS $HDF4_LIBS" LDFLAGS="$LDFLAGS $HDF4_LDFLAGS" AC_MSG_CHECKING([for ncopen with hdf link flags]) AC_LINK_IFELSE([AC_LANG_CALL([],[ncopen])], [ AC_MSG_RESULT([yes]) ac_hdf4_netcdf_lib='yes' ], [ AC_MSG_RESULT([no]) ac_hdf4_netcdf_lib='no' ]) LDFLAGS=$ac_hdf4_netcdf_save_LDFLAGS LIBS=$ac_hdf4_netcdf_save_LIBS ac_hdf4_netcdf_save_CPPFLAGS=$CPPFLAGS CPPFLAGS="$CPPFLAGS $HDF4_CPPFLAGS" AC_CHECK_NETCDF_HEADER([],[ac_hdf4_netcdf_h='yes']) CPPFLAGS=$ac_hdf4_netcdf_save_CPPFLAGS ]) AS_IF([test $ac_hdf4_netcdf_lib = 'yes' -a $ac_hdf4_netcdf_h = 'yes'], [m4_if([$1], [], [:], [$1])], [m4_if([$2], [], [:], [$2])]) ]) AC_DEFUN([AC_CHECK_HDF4_LIB], [ HDF4_LIBS= ac_hdf4_save_LIBS=$LIBS AC_CHECK_LIB_NOCACHE_HDF4([sz], [SZ_BufftoBuffCompress], [ LIBS="$LIBS -lsz" HDF4_LIBS='-lsz' ]) dnl -lsz is not required because due to licencing it may not be present dnl nor required everywhere ac_hdf4_lib='no' AC_CHECK_LIB_NOCACHE_HDF4([z],[deflate], [ AC_CHECK_LIB_NOCACHE_HDF4([jpeg],[jpeg_start_compress], [ AC_CHECK_LIB_NOCACHE_HDF4([df],[Hopen], [ AC_CHECK_LIB_NOCACHE_HDF4([mfhdf],[SDstart], [ ac_hdf4_lib="yes" HDF4_LIBS="-lmfhdf -ldf -ljpeg -lz $HDF4_LIBS" ],[],[-ldf -ljpeg -lz]) ],[],[-ljpeg -lz]) ]) ]) LIBS=$ac_hdf4_save_LIBS AS_IF([test "$ac_hdf4_lib" = 'yes'], [m4_if([$1], [], [:], [$1])], [m4_if([$2], [], [:], [$2])]) ]) AC_DEFUN([AC_CHECK_LIB_NOCACHE_HDF4], [ AS_TR_SH([ac_check_lib_nocache_ok_$1_$2])='no' AS_TR_SH([ac_check_lib_nocache_$1_$2_LIBS])=$LIBS LIBS="-l$1 $5 $LIBS" AC_MSG_CHECKING([for $2 in -l$1]) AC_LINK_IFELSE([AC_LANG_CALL([], [$2])], [ AS_TR_SH([ac_check_lib_nocache_ok_$1_$2])='yes' AC_MSG_RESULT([yes]) ],[ AC_MSG_RESULT([no]) ]) LIBS=$AS_TR_SH([ac_check_lib_nocache_$1_$2_LIBS]) AS_IF([test $AS_TR_SH([ac_check_lib_nocache_ok_$1_$2]) = 'yes'], [m4_if([$3], [], [:], [$3])], [m4_if([$4], [], [:], [$4])]) ]) AC_DEFUN([AC_CHECK_HEADER_NOCACHE_HDF4], [ AS_TR_SH([ac_check_header_nocache_compile_$1])='no' AS_TR_SH([ac_check_header_nocache_preproc_$1])='no' AC_MSG_CHECKING([for $1 with compiler]) AC_COMPILE_IFELSE([AC_LANG_SOURCE([[#include <$1>]])], [ AC_MSG_RESULT([yes]) AS_TR_SH([ac_check_header_nocache_compile_$1])='yes' ], [ AC_MSG_RESULT([no]) ]) AC_MSG_CHECKING([for $1 with preprocessor]) AC_PREPROC_IFELSE([AC_LANG_SOURCE([[#include <$1>]])], [ AC_MSG_RESULT([yes]) AS_TR_SH([ac_check_header_nocache_preproc_$1])='yes' ], [ AC_MSG_RESULT([no]) AS_IF([test "$AS_TR_SH([ac_check_header_nocache_compile_$1])" = 'yes'], [AC_MSG_WARN([trusting compiler result, ignoring preprocessor error])]) ]) AS_IF([test "$AS_TR_SH([ac_check_header_nocache_compile_$1])" = 'yes'], [m4_if([$2], [], [:], [$2])], [m4_if([$3], [], [:], [$3])]) ]) From bugzilla at redhat.com Sun Feb 5 02:21:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 21:21:02 -0500 Subject: [Bug 179988] Review Request: freealut - Implementation of OpenAL's ALUT standard In-Reply-To: Message-ID: <200602050221.k152L2EK004622@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: freealut - Implementation of OpenAL's ALUT standard https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179988 andreas.bierfert at lowlatency.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From andreas.bierfert at lowlatency.de 2006-02-04 21:20 EST ------- Thanks... imported and pushed... docs included :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 5 02:46:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 4 Feb 2006 21:46:48 -0500 Subject: [Bug 179758] Review Request: Eiciel (ACL editor) In-Reply-To: Message-ID: <200602050246.k152kmVt007651@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Eiciel (ACL editor) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179758 michel.salim at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michel.salim at gmail.com ------- Additional Comments From michel.salim at gmail.com 2006-02-04 21:46 EST ------- You might want to add the GNOME and System categories. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 5 05:17:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 00:17:09 -0500 Subject: [Bug 180052] New: Review Request: evas: A hardware-accelerated canvas API Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180052 Summary: Review Request: evas: A hardware-accelerated canvas API Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: ivazquez at ivazquez.net QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://fedora.ivazquez.net/files/extras/evas.spec SRPM Name or Url: http://fedora.ivazquez.net/files/extras/evas-0.9.9.023-1.src.rpm Description: Evas is a hardware-accelerated canvas API for X-Windows that can draw anti-aliased text, smooth super and sub-sampled images, alpha-blend, as well as drop down to using normal X11 primitives such as pixmaps, lines and rectangles for speed if your CPU or graphics hardware are too slow. Evas abstracts any need to know much about what the characteristics of your XServer's display are, what depth or what magic visuals etc, it has. The most you need to tell Evas is how many colors (at a maximum) to use if the display is not a truecolor display. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 5 08:02:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 03:02:27 -0500 Subject: [Bug 174588] Review Request: libopensync-plugin-gpe In-Reply-To: Message-ID: <200602050802.k1582RaW009327@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libopensync-plugin-gpe https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174588 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |jpmahowald at gmail.com OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-05 03:02 EST ------- Minor: - warnings while building: gpesync_client.c: In function 'write_command': gpesync_client.c:70: warning: ignoring return value of 'write', declared with attribute warn_unused_result gpesync_client.c: In function 'gpesync_client_open': gpesync_client.c:248: warning: ignoring return value of 'pipe', declared with attribute warn_unused_result gpesync_client.c:249: warning: ignoring return value of 'pipe', declared with attribute warn_unused_result It'd be nice if these went away and we could use -Werror again. File a bug upstream. - %description too long rpmlint of libopensync-plugin-gpe-devel-0.18-1.i386.rpm:E: libopensync-plugin-gpe-devel description-line-too-long The libopensync-plugin-gpe-devel package contains the files needed for development rpmlint of libopensync-plugin-gpe-devel-0.18-1.i386.rpm:E: libopensync-plugin-gpe-devel description-line-too-long The libopensync-plugin-gpe-devel package contains the files needed for development Good: - package meets naming guidelines - package meets packaging guidelines - license (GPL) OK, text in %doc, matches source - spec file legible, in am. english - source matches upstream - package compiles on FC4 i386 - no missing BR - no unnecessary BR - no locales - not relocatable - owns all directories that it creates - no duplicate files - permissions ok - %clean ok - macro use consistent - code, not content - no need for -docs - nothing in %doc affects runtime - no need for .desktop file - devel package ok - no .la files - post/postun ldconfig ok - devel requires base package n-v-r Fixup the %description and this is APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 5 08:21:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 03:21:36 -0500 Subject: [Bug 180058] New: Review Request: ecore: An event and X abstraction layer Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180058 Summary: Review Request: ecore: An event and X abstraction layer Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: ivazquez at ivazquez.net QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://fedora.ivazquez.net/files/extras/ecore.spec SRPM Name or Url: http://fedora.ivazquez.net/files/extras/ecore-0.9.9.023-1.src.rpm Description: Ecore is the core event abstraction layer and X abstraction layer that makes doing selections, Xdnd, general X stuff, and event loops, timeouts and idle handlers fast, optimized, and convenient. It's a separate library so anyone can make use of the work put into Ecore to make this job easy for applications. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 5 08:42:38 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 03:42:38 -0500 Subject: [Bug 180034] Review Request: perl-Font-TTF (part of the dejavu-fonts toolchain) In-Reply-To: Message-ID: <200602050842.k158gcHW015681@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Font-TTF (part of the dejavu-fonts toolchain) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180034 ------- Additional Comments From roozbeh at farsiweb.info 2006-02-05 03:42 EST ------- Nicolas, would you please provide an SRPM? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From j.w.r.degoede at hhs.nl Sun Feb 5 09:06:14 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 05 Feb 2006 10:06:14 +0100 Subject: Taking ownership of bochs and scorched3d Message-ID: <43E5C006.102@hhs.nl> Hi, As announced sometime ago I'm taking ownership of bochs and scorched3d. I'll edit the orphaned wikipage. Regards, Hans From bugzilla at redhat.com Sun Feb 5 09:04:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 04:04:27 -0500 Subject: [Bug 179910] Review Request: commoncpp C++ framework In-Reply-To: Message-ID: <200602050904.k1594RpR019150@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: commoncpp C++ framework https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179910 ville.skytta at iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|ed at eh3.com |ville.skytta at iki.fi ------- Additional Comments From ville.skytta at iki.fi 2006-02-05 04:04 EST ------- (Reassigning to myself per comment 4) Sure, mock probably builds it without the build dependencies, but obviously leaves out zlib and libxml2 support. But if they're installed, the corresponding features are built in. So please either add the build dependencies or explicitly disable these features so that the build is reproducible. doxygen is a slightly different thing; with it installed the API docs are built into doc/html/ and I think it would be good to include them in the devel package (%doc doc/html). If you're planning to include the *.la, please show a real case where they are required (not "seems", "probably"...) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 5 09:21:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 04:21:33 -0500 Subject: [Bug 179818] Review Request: xpilot-ng - A mutiplayer space arcade game In-Reply-To: Message-ID: <200602050921.k159LXWv021609@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xpilot-ng - A mutiplayer space arcade game https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179818 ------- Additional Comments From j.w.r.degoede at hhs.nl 2006-02-05 04:21 EST ------- some first impression comments: -use %{version} in Source0 -why the cp-ing of the doc files, you can have 2 identical %doc lines for (sub)packages. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 5 09:56:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 04:56:52 -0500 Subject: [Bug 174588] Review Request: libopensync-plugin-gpe In-Reply-To: Message-ID: <200602050956.k159uqpj003076@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libopensync-plugin-gpe https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174588 ------- Additional Comments From andreas.bierfert at lowlatency.de 2006-02-05 04:56 EST ------- Here is a fixed version :) http://fedora.lowlatency.de/review/libopensync-plugin-gpe-0.18-2.src.rpm http://fedora.lowlatency.de/review/libopensync-plugin-gpe.spec -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 5 10:22:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 05:22:01 -0500 Subject: [Bug 179818] Review Request: xpilot-ng - A mutiplayer space arcade game In-Reply-To: Message-ID: <200602051022.k15AM1wd006043@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xpilot-ng - A mutiplayer space arcade game https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179818 j.w.r.degoede at hhs.nl changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|bugzilla-sink at leemhuis.info |j.w.r.degoede at hhs.nl OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From j.w.r.degoede at hhs.nl 2006-02-05 05:21 EST ------- MUST items: * rpmlint output is clean * package and spec name matches upstream * GPL license valid, matches upstream, license file included * Meets packaging guidelines * Spec file is legible and in Am. English. * Source matches upstream (md5sum ok) * Builds cleanly on FC5 x86_64 * Valid BR; none are redundant * No lang files; no shlibs. * Package not relocatable * 0wns all directories that it creates * File permissions ok * %clean looks good * code and content, both under GPL * minimal doc files, do not affect runtime * no -devel package necessary * desktop file installed correctly SHOULD items: * Runs although I have yet to figure out the keys to use. MUST FIX: *use %{version} in Source0 *don't cp the doc-files to .server versions use just them 2 times in the %doc parts of the %files sections *icons should be installed in /usr/share/icons/hicolor/48x48/apps/ (freedekstop.org standard) *and then should run gtk-update-icon-cache in %post(un), use the scriptlets found on: http://www.fedoraproject.org/wiki/ScriptletSnippets for this. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From ville.skytta at iki.fi Sun Feb 5 10:37:00 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 05 Feb 2006 12:37:00 +0200 Subject: How to downgrade version of a program? In-Reply-To: <43E3ECE5.8010705@fedora.pl> References: <43E3ECE5.8010705@fedora.pl> Message-ID: <1139135820.8440.14.camel@bobcat.mine.nu> On Sat, 2006-02-04 at 00:53 +0100, Dawid Gajownik wrote: > I tried to do something like in this thread ? > https://www.redhat.com/archives/fedora-packaging/2005-June/msg00002.html > but yum or rpm did not replace python-sqlite2-2.1.0-1.fc4 with > python-sqlite2-2.0.7-1. Yep, that's too bad, and looks like rpm won't be fixed: https://bugzilla.redhat.com/168563 > Is Epoch bump the only solution? I'm afraid it is. From bugzilla at redhat.com Sun Feb 5 10:33:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 05:33:09 -0500 Subject: [Bug 180034] Review Request: perl-Font-TTF (part of the dejavu-fonts toolchain) In-Reply-To: Message-ID: <200602051033.k15AX9t7007462@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Font-TTF (part of the dejavu-fonts toolchain) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180034 ------- Additional Comments From Nicolas.Mailhot at laPoste.net 2006-02-05 05:33 EST ------- (In reply to comment #2) > Generally you should supply a src.rpm; it makes the review process a bit easier > and some of the review items require having it. I know, it's just that my isp changed it's upload rules and I couldn't locate the new ones yesterday > My rpmlint complains: > W: perl-Font-TTF wrong-file-end-of-line-encoding > /usr/share/doc/perl-Font-TTF-0.37/README.TXT > > and indeed README.TXT has CRLF endings. However, there are several packages > which include documentation files with DOS-style line endings so I don't believe > this is a blocker. Fix it up if you like. It's as you want, the rpmlint in rawhide does not care > Other issues: > I can't review spec file naming. > I can't review the source used to build the SRPM as none was provided. > BuildRequires: perl is not permitted. This line is straight from the fedora-rpmdevtools-1.4-2.fc5 perl template. Is the template wrong ? > The license does not seem to be GPL. I see only: > The Perl TTF module is licensed under the Perl Artistic License. Ok, my mistake, copied the licensing in dries rpm without checking > I don't understand this comment in the %files section: > # For arch-specific packages: vendorarch This is a bit of fedora-rpmdevtools-1.4-2.fc5 perl template I should have snipped > I can't install the resulting RPM: > > error: Failed dependencies: > perl(Win32) is needed by perl-Font-TTF-0.37-1.noarch > perl(Win32::Registry) is needed by perl-Font-TTF-0.37-1.noarch > > I believe this is the result of lib/Font/TTF/Win32.pm. I'm not sure what would > be best to do here. You can fix it with a quick > > rm %{buildroot}/%{perl_vendorlib}/Font/TTF/Win32.pm > > in the %install section but I'm not completely sure if that's acceptable. I agree on this, will do > Another solution would be to postprocess the output of the dependency generator, > but that's rather unpalatable as well (and more complicated than just deleting > the file). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From andreas.bierfert at lowlatency.de Sun Feb 5 10:40:35 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sun, 05 Feb 2006 11:40:35 +0100 Subject: [Fwd: [Fedora Project Wiki] Update of "Extras/CVSSyncNeeded" by RoozbehPournader] Message-ID: <43E5D623.1010106@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The comment on the change is: FC-3 is EOLed - ------------------------------------------------------------------------------ List package name and distribution here: * FC-4 python-json * FC-4 python-TestGears - - * FC-3 FC-4 libopensync-plugin-irmc + * FC-4 libopensync-plugin-irmc - - * FC-3 FC-4 freealut + * FC-4 freealut }}} Hey ;), I wonder if we really should not ship them. libopensync-plugin-* have been provided and it is not clear to anyone using FC-3 that one plugin is there and the other one is not (but for >= FC-4). freealut was part of openal but has been split up from it so I really feel very strong about having it in FC-3 for people who used to use the old openal version. - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFD5dYjQEQyPsWM8csRAuvlAJ4z06MAVRhQqZGdOpZuqPvhGY4BvQCgoKH8 sNGvjIy5TCfMkjUQCo3Nbtk= =RKfS -----END PGP SIGNATURE----- From bugzilla at redhat.com Sun Feb 5 10:42:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 05:42:36 -0500 Subject: [Bug 180034] Review Request: perl-Font-TTF (part of the dejavu-fonts toolchain) In-Reply-To: Message-ID: <200602051042.k15AgaKl008516@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Font-TTF (part of the dejavu-fonts toolchain) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180034 ------- Additional Comments From Nicolas.Mailhot at laPoste.net 2006-02-05 05:42 EST ------- (In reply to comment #3) > Nicolas, would you please provide an SRPM? Since the SRPM is only 148 kiB I'll attach it too -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From gajownik at fedora.pl Sun Feb 5 10:52:23 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Sun, 05 Feb 2006 11:52:23 +0100 Subject: How to downgrade version of a program? In-Reply-To: <1139135820.8440.14.camel@bobcat.mine.nu> References: <43E3ECE5.8010705@fedora.pl> <1139135820.8440.14.camel@bobcat.mine.nu> Message-ID: <43E5D8E7.9080107@fedora.pl> Dnia 02/05/2006 11:38 AM, U?ytkownik Ville Skytt? napisa?: > Yep, that's too bad, and looks like rpm won't be fixed: > https://bugzilla.redhat.com/168563 What a pity :( >> Is Epoch bump the only solution? > > I'm afraid it is. Thanks for the answer! -- ^_* From bugzilla at redhat.com Sun Feb 5 10:55:46 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 05:55:46 -0500 Subject: [Bug 180067] New: Review Request: mod_cband - Bandwidth limiting for Apache vhosts Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180067 Summary: Review Request: mod_cband - Bandwidth limiting for Apache vhosts Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: mfleming+rpm at enlartenment.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.enlartenment.com/extras/mod_cband.spec SRPM Name or Url: http://www.enlartenment.com/extras/mod_cband-0.9.7.2-1.src.rpm Description: mod_cband is an Apache 2 module provided to solve the problem of limiting virtualhosts bandwidth usage. When the configured virtualhost's transfer limit is exceeded, mod_cband will redirect all further requests to a location specified in the configuration file. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 5 11:01:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 06:01:02 -0500 Subject: [Bug 180068] New: Review Request: geoip - Library for mapping IP/hostname to a country/city/organization Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180068 Summary: Review Request: geoip - Library for mapping IP/hostname to a country/city/organization Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: mfleming+rpm at enlartenment.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.enlartenment.com/extras/geoip.spec SRPM Name or Url: http://www.enlartenment.com/extras/geoip-1.3.14-1.src.rpm Description: GeoIP is a C library that enables the user to find the country that any IP address or hostname originates from. It uses a file based database that is accurate as of March 2003. This database simply contains IP blocks as keys, and countries as values. This database should be more complete and accurate than using reverse DNS lookups. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From ville.skytta at iki.fi Sun Feb 5 11:13:20 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 05 Feb 2006 13:13:20 +0200 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: References: <87k6ccs4fu.fsf@kosh.bigo.ensc.de> <87fyn0rxbd.fsf@kosh.bigo.ensc.de> Message-ID: <1139138000.8440.42.camel@bobcat.mine.nu> On Fri, 2006-02-03 at 21:03 -0600, Rex Dieter wrote: > Enrico Scholz wrote: > > > There is a difference between Requires(post): and a plain Requires:. The > > first statement guarantees that the cache will be created, the latter > > might miss to create it. > > Not if gtk2 run gtk-update-icon-cache in its own %post. (-: In the case of 1) an app that already requires gtk2 eg. through a shared lib dependency, and 2) assuming no dependency loops involving both gtk2 and the package are present (which is pretty much granted in Extras) and 3) that the cache updater executable is assumed to be in the gtk2 package, I fail to see how the app could be installed before gtk2 -> the Requires(post) and gtk2 running gtk-update-icon-cache in its %post are no-ops in the scope of this particular problem (and actually, I think the problem does not exist). If 1) above doesn't hold true, the %trigger approach would be "correct" but it has its drawbacks. If you have evidence suggesting otherwise, please post it somewhere for examination. On the other hand, I seem to remember that some recent versions of rpm have added a %posttrans scriptlet which (if it indeed exists and does what I think, never tried it) could be used solve this problem cleanly in packages, without %triggers or any Requires, using the "|| :" or test-if-executable-exists-before-invoking-it safeguards. Does something benefit from updating the GTK icon cache (or require it) for a non-GTK app? If so, in addition to using %posttrans, the gtk2 package would need to run the cache updater in its %post. Is it just me or do others think that GNOME/GTK has some catching up to do in this area when compared to KDE's "it just works" implementation? Unfortunately the trend seems to be that GNOME/GTK is drifting further away from "just works", with the amount of additional required whatever-updated executables to run increasing... From pertusus at free.fr Sun Feb 5 11:15:27 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 5 Feb 2006 12:15:27 +0100 Subject: Buildrequires perl in spec template against guidelines Message-ID: <20060205111527.GB2640@free.fr> Hello, There is an inconsistency between the spec template in fedora-rpmdevtools, which has a BuildRequires: perl and the Package Review Guidelines http://fedoraproject.org/wiki/Packaging/ReviewGuidelines where there is - MUST: A package must not contain any BuildRequires that are listed in the exceptions section of Packaging Guidelines. with perl in the exception section of Packaging Guidelines http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions Ville thinks that the guidelines are wrong, that is perl should be allowed to be a BuildRequires for perl packages. For more informations, there is a bug I filled, with Ville response: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179426 -- Pat From bugzilla at redhat.com Sun Feb 5 11:14:25 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 06:14:25 -0500 Subject: [Bug 180034] Review Request: perl-Font-TTF (part of the dejavu-fonts toolchain) In-Reply-To: Message-ID: <200602051114.k15BEPSq011813@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Font-TTF (part of the dejavu-fonts toolchain) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180034 ------- Additional Comments From ville.skytta at iki.fi 2006-02-05 06:14 EST ------- (In reply to comment #4) > (In reply to comment #2) > > BuildRequires: perl is not permitted. > This line is straight from the fedora-rpmdevtools-1.4-2.fc5 perl template. Is > the template wrong ? Mileages vary. IMO not and rather the MUST in the guidelines is a bit over the top in this case. See bug 179426. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From roozbeh at farsiweb.info Sun Feb 5 11:21:14 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Sun, 05 Feb 2006 14:51:14 +0330 Subject: [Fwd: [Fedora Project Wiki] Update of "Extras/CVSSyncNeeded" by RoozbehPournader] In-Reply-To: <43E5D623.1010106@lowlatency.de> References: <43E5D623.1010106@lowlatency.de> Message-ID: <1139138474.3147.10.camel@tameshk.farsiweb.info> On ??????, 2006-02-05 at 11:40 +0100, Andreas Bierfert wrote: > I wonder if we really should not ship them. libopensync-plugin-* have been > provided and it is not clear to anyone using FC-3 that one plugin is there and > the other one is not (but for >= FC-4). Because we shouldn't provide new extras packages for FC3. See the following for the proposal: http://fedoraproject.org/wiki/Extras/Schedule/EolPolicy This was not finalized in the last FESCO meeting, but everybody agreed that we shouldn't make new releases for FC3. roozbeh From bugzilla at redhat.com Sun Feb 5 11:28:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 06:28:10 -0500 Subject: [Bug 180066] Request: Inclusion of a ruby template file In-Reply-To: Message-ID: <200602051128.k15BSAZv013346@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Request: Inclusion of a ruby template file https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180066 ville.skytta at iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |fedora-extras- | |list at redhat.com ------- Additional Comments From ville.skytta at iki.fi 2006-02-05 06:28 EST ------- I think this is a good idea, but the implementation is not quite ready. In particular: - Too many comments for a spec template at the top of the specfile near the %defines as well as the License tag. - Requires: ruby = %(...) needs verification whether it does the right thing. Maybe something like python(abi) and perl(:MODULE_COMPAT_*) should be implemented in the ruby(-libs?) package. Additionally, do all ruby extension packages require ruby, or would ruby-libs be more appropriate? - BuildRequires: ruby is needed, because ruby-devel does not pull in ruby (only ruby-libs) and ruby is invoked in the above Requires: ... line - Should use %{ruby_sitelib} and %{ruby_sitearch} for consistency with perl and python - The current %{ruby_sitedir} definition actually defines %{ruby_sitearch} - Is there a generic thingy that ruby extensions use akin to perl's "perl Makefile.PL ; ..." and python's "python setup.py ..."? Help from people who are familiar with ruby packaging would be appreciated. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From andreas.bierfert at lowlatency.de Sun Feb 5 11:33:34 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sun, 05 Feb 2006 12:33:34 +0100 Subject: [Fwd: [Fedora Project Wiki] Update of "Extras/CVSSyncNeeded" by RoozbehPournader] In-Reply-To: <1139138474.3147.10.camel@tameshk.farsiweb.info> References: <43E5D623.1010106@lowlatency.de> <1139138474.3147.10.camel@tameshk.farsiweb.info> Message-ID: <43E5E28E.5050205@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roozbeh Pournader wrote: > Because we shouldn't provide new extras packages for FC3. See the > following for the proposal: > > http://fedoraproject.org/wiki/Extras/Schedule/EolPolicy > > This was not finalized in the last FESCO meeting, but everybody agreed > that we shouldn't make new releases for FC3. I know about this thanks... but there are special cases and both imho apply for one. - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFD5eKOQEQyPsWM8csRApAeAJ9Vp3EWIUzOK7A14jXT6fiM5neoEQCgrMD8 q9BpuObgdJHCTA9XLZZjw3A= =0V4E -----END PGP SIGNATURE----- From bugzilla at redhat.com Sun Feb 5 11:30:22 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 06:30:22 -0500 Subject: [Bug 180066] Request: Inclusion of a ruby template file In-Reply-To: Message-ID: <200602051130.k15BUMUH013681@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Request: Inclusion of a ruby template file https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180066 ------- Additional Comments From ville.skytta at iki.fi 2006-02-05 06:30 EST ------- One more thing: if ruby extensions generally include a test suite (and maybe even if not), %check section should be added. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From roozbeh at farsiweb.info Sun Feb 5 11:55:40 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Sun, 05 Feb 2006 15:25:40 +0330 Subject: [Fwd: [Fedora Project Wiki] Update of "Extras/CVSSyncNeeded" by RoozbehPournader] In-Reply-To: <43E5E28E.5050205@lowlatency.de> References: <43E5D623.1010106@lowlatency.de> <1139138474.3147.10.camel@tameshk.farsiweb.info> <43E5E28E.5050205@lowlatency.de> Message-ID: <1139140540.25578.1.camel@tameshk.farsiweb.info> ??? ??????? 2006-02-05 ???? 12:33 +0100? Andreas Bierfert ????: > I know about this thanks... but there are special cases and both imho apply for one. I don't think these are special cases, but would you re-explain why these are special? Why must an FC3 user be able to install these new package on his system? roozbeh From bugzilla at redhat.com Sun Feb 5 12:02:39 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 07:02:39 -0500 Subject: [Bug 179263] Review Request: perl-Text-Unidecode - US-ASCII transliterations of Unicode text In-Reply-To: Message-ID: <200602051202.k15C2d4Q017368@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Text-Unidecode - US-ASCII transliterations of Unicode text https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179263 pertusus at free.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From pertusus at free.fr 2006-02-05 07:02 EST ------- I have filled a bug about the BuildRequires: perl, and then send a mail on the fedora mailing list. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From fedora at leemhuis.info Sun Feb 5 12:20:51 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 05 Feb 2006 13:20:51 +0100 Subject: Summary from the last FESCo meeting Message-ID: <1139142051.2948.5.camel@localhost.localdomain> Find below a summary from the last FESCo meeting. Full log and this summary in a prettier format is available from: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060202 The Agenda, often with links to some more detailed background on the topics is found at http://www.fedoraproject.org/wiki/Extras/Schedule * Cleanup the Schedule from non-extras tasks Discussed some items and removed them. FC5 naming is still there: {{{ Sopwith> | And the naming thing just needs someone to adopt it. thl> | Sopwith, who is someone? f13> | thl: could be someone interested, however somebody at red hat will still have to get it pushed through legal. Sopwith> | thl: I'm writing an e-mail to jkeating right now - he's the one that'll have to make it happen... f13> | Sopwith: thanks. f13> | Sopwith: I'll make it happen }}} * Mass Rebuild of FE5 We still can't start yet, need to wait for another rebuild in core * EOL Policy for FE The current plan found at http://www.fedoraproject.org/wiki/Extras/Schedule/EolPolicy is this: {{{ This is a rough draft of what to do about Extras when a Fedora release goes EOL. When a Fedora Core release reaches End of Life (such as Fedora Core 3 will once Fedora Core 5 Test 2 is released), the corresponding release of Fedora Extras well enter a Maintenance state. In this state maintainers will be allowed to issue updates to existing packages, but no new packages can be introduced. Maintainers are strongly urged to only issue severe bugfix or security fixes. New software versions should be avoided except when necessary for resolving issues with the the current version. At this point there is no plan to close a release of Fedora Extras, preventing any further package releases. While the Fedora Core release will be transferred to the Fedora Legacy project, Fedora Legacy will not be responsible for maintaining Fedora Extras. We feel it is better for the current package maintainer to continue handling package releases for the Fedora Extras release that is in maintenance state. }}} Speak up now or this will be policy soon. * Encourage Extras reviews Current state: 134 Bugs in the new state, 54 under review -- some for a very long time already! Action: Create SIGs (Special Interest Groups). Which ones? Good question. Ignacio already started a bit of work at http://www.fedoraproject.org/wiki/Extras/SIGs Current groups: GNOME, KDE, Multimedia, Perl, Python, Ruby, Scientific and Technical, Server Tools, ppc, x86-64. Do we need more? Input needed! Action: Review days (general or specific to the SIGs) may help getting stuff reviewed -- somebody needs to work out the details. Help-Needed -- interested to work in one of the SIGs? Add yourself to the wiki-pages! Undecided: Maybe separate mailing-lists for the SIGs Undecided: How to track the bugs for the SIGs? Tracker-BUGs? Wiki? * Broken deps report mschwendt has a handy script that does most things automatic. Should run in the future with every extras push. mschwendt will send the current proposal to fedora-extras-list for futher discussion and put the script in a public place. * JesseKeating wants to remove himself from FESCo "I was on FESCO mostly because of Legacy, which is its own project now. I rarely have anything to do w/ FESCO and it doesn't make sense for me to be trying ot make decisions for hte project." We didn't let him go for now :-) Okay, now seriously: We need to work out the details who is in FESCo, why, how to get in, how to get out, when people are thrown out to make space for more active people, how many people should be in FESCo in general, how the chair gets elected and similar stuff. Opinions? * We should discuss more topics on mailing-lists Some discussion in FESCo were done on the private FESCo-Mailinglist. We should avoid this in the future as much as possible and discuss everything on fedora-extras-list directly. We also should discuss less in the FESCo meetings on IRC and more on the lists where everyone can participate. BTW, sorry for the delay, I didn't find time earlier to write this summary. -- Thorsten Leemhuis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugzilla at redhat.com Sun Feb 5 12:38:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 07:38:15 -0500 Subject: [Bug 180066] Request: Inclusion of a ruby template file In-Reply-To: Message-ID: <200602051238.k15CcFxT021859@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Request: Inclusion of a ruby template file https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180066 ------- Additional Comments From oliver.andrich at gmail.com 2006-02-05 07:38 EST ------- (In reply to comment #2) > I think this is a good idea, but the implementation is not quite ready. In > particular: > > - Too many comments for a spec template at the top of the specfile near the > %defines as well as the License tag. Well, I agree with you, but concerning the License tag I like to put some kind of comment into the file to clarify the license issue. Or do you suggest to correct this in case someone commits a new package? > - Requires: ruby = %(...) needs verification whether it does the right thing. > Maybe something like python(abi) and perl(:MODULE_COMPAT_*) should be > implemented in the ruby(-libs?) package. Additionally, do all ruby extension > packages require ruby, or would ruby-libs be more appropriate? Basically you could provide a ruby extension, that only requires the ruby package, but you mentioned the right thing. ruby-libs is what I shall require in the template, especially cause the directories from the macros are provided by ruby-libs. I am not sure what the reasoning behind this python-abi = %(...) is, but what I need to check is, that ruby is >= 1.8 cause there are syntactic differences between ruby 1.6 and ruby 1.8. But this is the only thing I have to check. How would you implement this? > - BuildRequires: ruby is needed, because ruby-devel does not pull in ruby > (only ruby-libs) and ruby is invoked in the above Requires: ... line Fixed. And most of the time you also need ruby to execute some kind of install script. > - Should use %{ruby_sitelib} and %{ruby_sitearch} for consistency with perl > and python Fixed. > - The current %{ruby_sitedir} definition actually defines %{ruby_sitearch} Fixed. > - Is there a generic thingy that ruby extensions use akin to perl's "perl > Makefile.PL ; ..." and python's "python setup.py ..."? Sadly not yet. I have two packages submitted so far, and both use different approaches. But these things are clarifying in the future. A lot developers are moving to Gems, which is ruby's CPAN equivalent. > Help from people who are familiar with ruby packaging would be appreciated. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 5 12:39:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 07:39:11 -0500 Subject: [Bug 180066] Request: Inclusion of a ruby template file In-Reply-To: Message-ID: <200602051239.k15CdBVG022015@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Request: Inclusion of a ruby template file https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180066 ------- Additional Comments From oliver.andrich at gmail.com 2006-02-05 07:39 EST ------- (In reply to comment #3) > One more thing: if ruby extensions generally include a test suite (and maybe > even if not), %check section should be added. Fixed. Not all packages include a test suite, so I put an empty %check section inside the template. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 5 12:49:12 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 07:49:12 -0500 Subject: [Bug 179910] Review Request: commoncpp C++ framework In-Reply-To: Message-ID: <200602051249.k15CnCiL023143@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: commoncpp C++ framework https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179910 ------- Additional Comments From andreas at bawue.net 2006-02-05 07:49 EST ------- Okay, Changes are incorporated. Take a look please at http://home.bawue.de/~ixs/commoncpp/commoncpp2.spec and http://home.bawue.de/~ixs/commoncpp/commoncpp2-1.3.23-2.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 5 14:01:58 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 09:01:58 -0500 Subject: [Bug 180066] Request: Inclusion of a ruby template file In-Reply-To: Message-ID: <200602051401.k15E1wl1030649@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Request: Inclusion of a ruby template file https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180066 ------- Additional Comments From ville.skytta at iki.fi 2006-02-05 09:01 EST ------- (In reply to comment #4) > Well, I agree with you, but concerning the License tag I like to put some kind > of comment into the file to clarify the license issue. Or do you suggest to > correct this in case someone commits a new package? I don't think there's any need for clarification/correction. > I am not sure what the reasoning behind this python-abi = %(...) is, but what > I need to check is, that ruby is >= 1.8 Actually, if it's like in perl/python, one needs to require a version of ruby-libs that the package works with, including ruby-libs loading extensions from the versioned install dirs. >= 1.8 is probably incorrect, because I guess ruby 2.0 won't load extensions from the 1.8 dirs. The ruby-libs package could provide for example ruby(abi) = 1.8, and in that case the scriptlet from your original specfile would be ok I think (obviously changed to require ruby(abi) = ...). Currently, I think the best that can be done is to use dir based dependencies, %{ruby_sitelib} for noarch, %{ruby_sitearch} for non-noarch. I've committed the template from comment 7 to CVS with the dir based deps and other minor modifications, please submit further changes as diffs against the fedora-rpmdevtools in the fedora (note: not extras) repository, http://cvs.fedora.redhat.com/viewcvs/fedora-rpmdevtools/?root=fedora I wonder if a 'export CFLAGS="$RPM_OPT_FLAGS"' should be put to the spec template's %build section (to honor $RPM_OPT_FLAGS like in perl/python). Also, is it possible to include something better than the comments in %files, for example stuff like in the perl spec template? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rdieter at math.unl.edu Sun Feb 5 14:33:29 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 05 Feb 2006 08:33:29 -0600 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: <1139138000.8440.42.camel@bobcat.mine.nu> References: <87k6ccs4fu.fsf@kosh.bigo.ensc.de> <87fyn0rxbd.fsf@kosh.bigo.ensc.de> <1139138000.8440.42.camel@bobcat.mine.nu> Message-ID: Ville Skytt? wrote: > Does something benefit from updating the GTK icon cache (or require it) > for a non-GTK app? If so, in addition to using %posttrans, the gtk2 > package would need to run the cache updater in its %post. gnome does. One example, it helps gnome find the app-icon (faster) for display in its menu(s). > Is it just me or do others think that GNOME/GTK has some catching up to > do in this area when compared to KDE's "it just works" implementation? Gnome/GTK could be made to "just work" too, that's what I'm trying to accomplish here... (-: To be fair/complete, it just works without the cache, it's just a bit slower. -- Rex From bugzilla at redhat.com Sun Feb 5 15:26:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 10:26:21 -0500 Subject: [Bug 180034] Review Request: perl-Font-TTF (part of the dejavu-fonts toolchain) In-Reply-To: Message-ID: <200602051526.k15FQLE3007475@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Font-TTF (part of the dejavu-fonts toolchain) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180034 ------- Additional Comments From tibbs at math.uh.edu 2006-02-05 10:26 EST ------- I agree about the BuildRequires: perl thing, and indeed in another review I said it was not a blocker (which was my mistake) but then I noticed the MUST. I'm not sure what to do here; I think the MUST is unnecessary and conflicts with language in the the packaging guidelines: "There is no need to include the following packages or their dependencies as BuildRequires because they would occur too often." which doesn't sound very MUST like. We can't just ignore the guidelines, so I suggest removing the BuildRequires: while this gets worked out on the mailing list. Also, could you comment the %exclude you added, so it's obvious why this is required. I'll finish off the review in a few minutes. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From tibbs at math.uh.edu Sun Feb 5 15:52:45 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sun, 05 Feb 2006 09:52:45 -0600 Subject: Buildrequires perl in spec template against guidelines In-Reply-To: <20060205111527.GB2640@free.fr> (Patrice Dumas's message of "Sun, 5 Feb 2006 12:15:27 +0100") References: <20060205111527.GB2640@free.fr> Message-ID: I think the conflict is not just between the spec template and the review guidelines, but between the MUST in the review guidelines and language in the packaging guidelines. I read the following at http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRequires: There is no need to include the following packages or their dependencies as BuildRequires because they would occur too often. and think, OK, so it has a single unnecessary BuildRequires: but it's not a blocker. And then I see: - MUST: A package must not contain any BuildRequires that are listed in the exceptions section of Packaging Guidelines. which is pretty unequivocal. Ville's position is that perl could someday disappear from the minimum build environment. I guess anything's possible, and mock builds do take a while so leaving out perl might save some time. In any case, something needs to change. - J< From buildsys at fedoraproject.org Sun Feb 5 16:11:52 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 5 Feb 2006 11:11:52 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060205161152.96B96800B@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 8 fonttools-2.0-0.4.20050624cvs.fc4 itcl-3.3-0.3.RC1.fc4 nagios-2.0-0.2.rc2.fc4 numpy-0.9.4-1.fc4 python-cheetah-1.0-1.fc4 python-sqlite2-2.0.7-1.fc4 ruby-mysql-2.7-6.fc4 xmldiff-0.6.7-9.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun Feb 5 16:12:01 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 5 Feb 2006 11:12:01 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060205161201.CBCF1800B@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 16 denyhosts-2.0-1.fc5 freealut-1.0.0-2.fc5 itcl-3.3-0.3.RC1.fc5 libopensync-plugin-irmc-0.18-4.fc5 mediawiki-1.5.6-4.fc5 nagios-2.0-0.2.rc2.fc5 numpy-0.9.4-1.fc5 openal-0.0.9-0.2.20060204cvs.fc5 python-TestGears-0.2-1.fc5 python-cheetah-1.0-1.fc5 python-formencode-0.4-2.fc5 python-json-3.4-1.fc5 python-sqlite2-2.1.3-3.fc5 ruby-mysql-2.7-6.fc5 xmldiff-0.6.7-9.fc5 yumex-0.99.4-1.0.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Sun Feb 5 16:25:42 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 11:25:42 -0500 Subject: [Bug 180052] Review Request: evas: A hardware-accelerated canvas API In-Reply-To: Message-ID: <200602051625.k15GPgOs014224@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: evas: A hardware-accelerated canvas API https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180052 ------- Additional Comments From eric.tanguy at univ-nantes.fr 2006-02-05 11:25 EST ------- Review for release 1: * RPM name is OK * Source evas-0.9.9.023.tar.gz is the same as upstream * This is the latest version * Builds fine in mock * File list of evas-devel looks OK * File list of evas looks OK * Run fine Needs work: * rpmlint of evas-devel : W: evas-devel no-documentation * rpmlint of evas : E: evas library-without-ldconfig-postin /usr/lib/libevas.so.1.0.0 E: evas library-without-ldconfig-postun /usr/lib/libevas.so.1.0.0 E: evas zero-length /usr/share/doc/evas-0.9.9.023/ChangeLog E: evas zero-length /usr/share/doc/evas-0.9.9.023/NEWS I can't try it with mock devel which seems broken but BuildRequires: xorg-x11-devel seems not good for modular X in fc5 and maybe you can also BuildRequires: cairo-devel for fc5. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 5 16:44:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 11:44:50 -0500 Subject: [Bug 180058] Review Request: ecore: An event and X abstraction layer In-Reply-To: Message-ID: <200602051644.k15GioEQ016576@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ecore: An event and X abstraction layer https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180058 ------- Additional Comments From eric.tanguy at univ-nantes.fr 2006-02-05 11:44 EST ------- Review for release 1: * RPM name is OK * Source ecore-0.9.9.023.tar.gz is the same as upstream * Builds fine in mock * File list of ecore-devel looks OK * File list of ecore looks OK * Run fine Needs work: rpmlint of ecore-devel-0.9.9.023-1.i386.rpm:E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/list_destroy_example.o E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/x_window_example.o E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/timer_example.o E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/event_handler_example.o E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/con_server_example.o E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/list_example.o E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/config_basic_example.o E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/config_listener_example.o E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/con_client_example W: ecore-devel unstripped-binary-or-object /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/con_client_example E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/exe_example W: ecore-devel unstripped-binary-or-object /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/exe_example E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/args_example W: ecore-devel unstripped-binary-or-object /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/args_example E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/x_window_example W: ecore-devel unstripped-binary-or-object /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/x_window_example E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/event_handler_example W: ecore-devel unstripped-binary-or-object /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/event_handler_example E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/con_server_example W: ecore-devel unstripped-binary-or-object /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/con_server_example E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/config_listener_example W: ecore-devel unstripped-binary-or-object /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/config_listener_example E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/config_basic_example W: ecore-devel unstripped-binary-or-object /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/config_basic_example E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/list_destroy_example W: ecore-devel unstripped-binary-or-object /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/list_destroy_example E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/list_example W: ecore-devel unstripped-binary-or-object /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/list_example E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/timer_example W: ecore-devel unstripped-binary-or-object /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs/timer_example E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/exe_example.o E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/args_example.o E: ecore-devel arch-dependent-file-in-usr-share /usr/share/doc/ecore-devel-0.9.9.023/examples/con_client_example.o W: ecore-devel hidden-file-or-dir /usr/share/doc/ecore-devel-0.9.9.023/examples/.deps W: ecore-devel hidden-file-or-dir /usr/share/doc/ecore-devel-0.9.9.023/examples/.deps W: ecore-devel hidden-file-or-dir /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs W: ecore-devel hidden-file-or-dir /usr/share/doc/ecore-devel-0.9.9.023/examples/.libs rpmlint of ecore-0.9.9.023-1.i386.rpm:E: ecore library-without-ldconfig-postin /usr/lib/libecore.so.1.0.0 E: ecore library-without-ldconfig-postun /usr/lib/libecore.so.1.0.0 E: ecore library-without-ldconfig-postin /usr/lib/libecore_file.so.1.0.0 E: ecore library-without-ldconfig-postun /usr/lib/libecore_file.so.1.0.0 E: ecore library-without-ldconfig-postin /usr/lib/libecore_dbus.so.1.0.0 E: ecore library-without-ldconfig-postun /usr/lib/libecore_dbus.so.1.0.0 E: ecore library-without-ldconfig-postin /usr/lib/libecore_x.so.1.0.0 E: ecore library-without-ldconfig-postun /usr/lib/libecore_x.so.1.0.0 E: ecore library-without-ldconfig-postin /usr/lib/libecore_txt.so.1.0.0 E: ecore library-without-ldconfig-postun /usr/lib/libecore_txt.so.1.0.0 E: ecore library-without-ldconfig-postin /usr/lib/libecore_fb.so.1.0.0 E: ecore library-without-ldconfig-postun /usr/lib/libecore_fb.so.1.0.0 E: ecore library-without-ldconfig-postin /usr/lib/libecore_evas.so.1.0.0 E: ecore library-without-ldconfig-postun /usr/lib/libecore_evas.so.1.0.0 E: ecore library-without-ldconfig-postin /usr/lib/libecore_con.so.1.0.0 E: ecore library-without-ldconfig-postun /usr/lib/libecore_con.so.1.0.0 E: ecore library-without-ldconfig-postin /usr/lib/libecore_job.so.1.0.0 E: ecore library-without-ldconfig-postun /usr/lib/libecore_job.so.1.0.0 E: ecore zero-length /usr/share/doc/ecore-0.9.9.023/NEWS E: ecore library-without-ldconfig-postin /usr/lib/libecore_config.so.1.0.0 E: ecore library-without-ldconfig-postun /usr/lib/libecore_config.so.1.0.0 E: ecore library-without-ldconfig-postin /usr/lib/libecore_directfb.so.1.0.0 E: ecore library-without-ldconfig-postun /usr/lib/libecore_directfb.so.1.0.0 E: ecore library-without-ldconfig-postin /usr/lib/libecore_ipc.so.1.0.0 E: ecore library-without-ldconfig-postun /usr/lib/libecore_ipc.so.1.0.0 Minor: * Duplicate BuildRequires: zlib-devel (by directfb-devel), openssl-devel (by curl-devel) I can't try it with mock devel which seems broken but BuildRequires: xorg-x11-devel seems not good for modular X in fc5. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From nicolas.mailhot at laposte.net Sun Feb 5 17:33:32 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 05 Feb 2006 18:33:32 +0100 Subject: Buildrequires perl in spec template against guidelines In-Reply-To: References: <20060205111527.GB2640@free.fr> Message-ID: <1139160813.3178.0.camel@rousalka.dyndns.org> Le dimanche 05 f?vrier 2006 ? 09:52 -0600, Jason L Tibbitts III a ?crit : > Ville's position is that perl could someday disappear from the minimum > build environment. I guess anything's possible, and mock builds do > take a while so leaving out perl might save some time. > > In any case, something needs to change. Meanwhile, can packages that follow the template be approved ? -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From bugzilla at redhat.com Sun Feb 5 17:33:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 12:33:08 -0500 Subject: [Bug 180034] Review Request: perl-Font-TTF (part of the dejavu-fonts toolchain) In-Reply-To: Message-ID: <200602051733.k15HX86J022305@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Font-TTF (part of the dejavu-fonts toolchain) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180034 ------- Additional Comments From Nicolas.Mailhot at laPoste.net 2006-02-05 12:33 EST ------- (In reply to comment #9) > We can't just ignore the guidelines, so I suggest removing the BuildRequires: > while this gets worked out on the mailing list. I strongly suspect most FE packages follow the official templates, so leaving it might be the more conservative option IMHO. But I'll follow the reviewer position ;) > Also, could you comment the %exclude you added, so it's obvious why this is > required. > > I'll finish off the review in a few minutes. Ok, new spec/srpm in 30s -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 5 18:09:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 13:09:21 -0500 Subject: [Bug 180034] Review Request: perl-Font-TTF (part of the dejavu-fonts toolchain) In-Reply-To: Message-ID: <200602051809.k15I9Lu7026544@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Font-TTF (part of the dejavu-fonts toolchain) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180034 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From tibbs at math.uh.edu 2006-02-05 13:09 EST ------- Cool. OK, everything's looking good: No rpmlint blockers, just the end-of-line warning. Package meets naming and packaging guidelines. License is acceptable and matches License: tag. Specfile is properly named, legible, well-written, well-commented and uses macros consistently. Source file matches upstream. Package builds and installs on FC3 and FC4. BuildRequires: is proper. Approved. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 5 18:13:51 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 13:13:51 -0500 Subject: [Bug 180092] New: Review Request: NRPE - Monitoring agent for Nagios Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180092 Summary: Review Request: NRPE - Monitoring agent for Nagios Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: imlinux at gmail.com QAContact: fedora-extras-list at redhat.com Spec: http://mmcgrath.net/~mmcgrath/nrpe/nrpe.spec SRPM Name or Url: http://mmcgrath.net/~mmcgrath/nrpe/nrpe-2.3-1.src.rpm Description: Nrpe is a system daemon that will execute various Nagios plugins locally on behalf of a remote (monitoring) host that uses the check_nrpe plugin. Various plugins that can be executed by the daemon are available at: http://sourceforge.net/projects/nagiosplug This package provides the core agent. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 5 18:21:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 13:21:01 -0500 Subject: [Bug 180066] Request: Inclusion of a ruby template file In-Reply-To: Message-ID: <200602051821.k15IL1im027803@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Request: Inclusion of a ruby template file https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180066 ------- Additional Comments From ville.skytta at iki.fi 2006-02-05 13:20 EST ------- Applied, thanks. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 5 18:33:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 13:33:56 -0500 Subject: [Bug 179802] Review Request: seamonkey In-Reply-To: Message-ID: <200602051833.k15IXuOr029462@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: seamonkey https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179802 ------- Additional Comments From caillon at redhat.com 2006-02-05 13:33 EST ------- Review comments: - Is this really distributed under NPL/MPL? I think it should be MPL/GPL/LGPL - Lose the Prefix: tag - Don't BuildRequire autoconf213; if you make changes to configure, include that part in the patch - Remove the ExclusiveArch. You are including all of our current platforms, and it probably builds on others that we don't. - You probably ought to have the FindExternalProvides stuff that the Firefox and Thunderbird package does. Since the libraries provided aren't versioned, this can cause problems when two packages provide the same libraries (mozilla also provides these for now, and when xulrunner eventually takes over, it will do so). - I think you can safely remove the conditional for desktop_file, unless you really want to push this to really old releases (I think FC1 needed it, newer don't). - Without a GRE, the -devel package should arguably not be built since that is a key part of the -devel platform. - regxpcom is no longer required. This (and the entire block surrounding it) should go away. - Your comment about cp -L doesn't seem needed. - Since this is for Fedora Extras, you probably shouldn't name the default pref/bookmarks files with redhat :-) - seamonkey-rebuild-databases should not be needed - I don't think selinux/chcon stuff should be in this specfile. Is there a bug you are trying to work around? - The following are installed with +x and shouldn't be. Using a %defattr in %files with the appropriate modes will fix this. ++ seamonkey ++ /usr/lib/seamonkey-1.0/components/nsXmlRpcClient.js /usr/lib/seamonkey-1.0/components/nsComposerCmdLineHandler.js /usr/lib/seamonkey-1.0/components/nsSidebar.js /usr/lib/seamonkey-1.0/components/nsProgressDialog.js /usr/lib/seamonkey-1.0/components/nsCloseAllWindows.js /usr/lib/seamonkey-1.0/components/nsHelperAppDlg.js /usr/lib/seamonkey-1.0/components/nsFilePicker.js /usr/lib/seamonkey-1.0/components/nsDictionary.js /usr/lib/seamonkey-1.0/components/nsUpdateNotifier.js /usr/lib/seamonkey-1.0/components/nsDownloadProgressListener.js /usr/lib/seamonkey-1.0/components/jsconsole-clhandler.js /usr/lib/seamonkey-1.0/components/nsProxyAutoConfig.js /usr/lib/seamonkey-1.0/components/nsResetPref.js /usr/lib/seamonkey-1.0/components/nsInterfaceInfoToIDL.js ++ seamonkey-chat ++ /usr/lib/seamonkey-1.0/components/chatzilla-service.js ++ seamonkey-dom-inspector ++ /usr/lib/seamonkey-1.0/components/inspector-cmdline.js ++ seamonkey-js-debugger ++ /usr/lib/seamonkey-1.0/components/venkman-service.js ++ seamonkey-mail ++ /usr/lib/seamonkey-1.0/components/offlineStartup.js /usr/lib/seamonkey-1.0/components/nsLDAPPrefsService.js /usr/lib/seamonkey-1.0/components/nsAbLDAPAttributeMap.js /usr/lib/seamonkey-1.0/components/smime-service.js /usr/lib/seamonkey-1.0/components/mdn-service.js ++++ Optional: - Use a .mozconfig file (see what I do in the firefox package). This will make it easier to do development with the same flags with a different tree (just copy the mozconfig over) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From tibbs at math.uh.edu Sun Feb 5 19:05:12 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sun, 05 Feb 2006 13:05:12 -0600 Subject: Buildrequires perl in spec template against guidelines In-Reply-To: <1139160813.3178.0.camel@rousalka.dyndns.org> (Nicolas Mailhot's message of "Sun, 05 Feb 2006 18:33:32 +0100") References: <20060205111527.GB2640@free.fr> <1139160813.3178.0.camel@rousalka.dyndns.org> Message-ID: >>>>> "NM" == Nicolas Mailhot writes: NM> Meanwhile, can packages that follow the template be approved ? I'm not even sure who would be responsible for making such a decision. Do we need to wait for the next steering committee meeting? - J< From bugzilla at redhat.com Sun Feb 5 19:10:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 14:10:18 -0500 Subject: [Bug 175433] Review Request: tor - Anonymizing overlay network for TCP (The onion router) In-Reply-To: Message-ID: <200602051910.k15JAIKL001512@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: tor - Anonymizing overlay network for TCP (The onion router) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175433 ------- Additional Comments From kevin at tummy.com 2006-02-05 14:10 EST ------- >* Mon Jan 30 2006 Enrico Scholz - 0.1.0.16-0.1 >- renamed the current main-package into a '-core' subpackage and > created a new main-package which requires both the 'tor-core' > subpackage and this with the current default init-method. This > allows 'yum install tor' to work better; because yum is not very > smart, the old packaging might install unwanted packages else. Humm.. Can you elobrate on what situation would result in unwanted packages? I think this is a regression from the package in comment #10. I would prefer just one tor package (with the lsb stuff), but I don't see how adding additional packages helps anything. >An rpm package which is linked on the Tor homepage and which would run on >every (LSB compliant) system is possible. But it would require heavily >discouraged things like static linking of non-LSB deps (e.g. libevent). Quite possibly. >So, this review is for a package in the Fedora Extras environment. This >environment provides all the packages required for my packaging. Agreed. This is specifically a Fedora Extras package. In my mind this would be an argument against having a tor-lsb subpackage as well, since fedora-extras doesn't have (yet) any other init setups. This tor-lsb subpackage seems only needed for your setup, not for Fedora Extras. >The tor homepage does not link to Debian, Gentoo or *BSD binaries >either but tells the installation command. For this package, the >corresponding command is 'yum install tor'. The current packaging >will also install the current default init-method but allows still >minimal environments with more effective init methods. True, but there is currently nothing but the default init-method in Fedora, so it would seem to me that adding packaging for these non Fedora cases adds confusion and isn't needed. In any case I would be willing to approve the package as it was in comment #10, since it meets all the guidelines. I would prefer that version over this one with the additional tor-core subpackage, unless there is some good reason for the package inflation. If you prefer to get approval for the 0.1.0.16-0.1 version instead, perhaps I should move this back to FE-NEW and you can pick up a diffrent reviewer. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rdieter at math.unl.edu Sun Feb 5 19:32:16 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 05 Feb 2006 13:32:16 -0600 Subject: Buildrequires perl in spec template against guidelines In-Reply-To: <20060205111527.GB2640@free.fr> References: <20060205111527.GB2640@free.fr> Message-ID: Patrice Dumas wrote: > Ville thinks that the guidelines are wrong, that is perl should be allowed to > be a BuildRequires for perl packages. +1, Ville is correct. perl modules are certainly a reasonable exception to the rule. -- Rex From bugzilla at redhat.com Sun Feb 5 19:22:38 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 14:22:38 -0500 Subject: [Bug 177106] Review Request: libgdgeda - graphical library for gEDA In-Reply-To: Message-ID: <200602051922.k15JMchx003590@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libgdgeda - graphical library for gEDA https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177106 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |jpmahowald at gmail.com OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-05 14:22 EST ------- Can't sponsor, but I am interested in circuit software. ** Configuration summary for libgdgeda 2.0.15: Support for PNG library: yes Support for JPEG library: no Support for Freetype 2.x library: no Support for Xpm library: no Why not add these? It's usually a good idea to enable as many features as possible. All it would take is adding libjpeg-devel and freetype-devel to BuildRequires. # install will be a bit complicated because we are not assured # that the builder has root privileges What do you mean by this? All packages are built by a non root user, and I did sucessfully. You have defined a BuildRoot you don't need root to write to. The source in the tarball isn't matching what I downloaded for some reason. d4978ce4e8eb9fa2e7c0d7dba40b3c5b libgdgeda-2.0.15.tar.gz (downloaded) 1580beb2bd224f38ce8637c67a5512f8 /tmp/libgdgeda-2.0.15.tar.gz (src rpm) rpmlint checks are clean, which is good. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 5 19:33:12 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 14:33:12 -0500 Subject: [Bug 180052] Review Request: evas: A hardware-accelerated canvas API In-Reply-To: Message-ID: <200602051933.k15JXCZT005404@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: evas: A hardware-accelerated canvas API https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180052 ------- Additional Comments From ivazquez at ivazquez.net 2006-02-05 14:33 EST ------- Updated. I'll update it for modular X once it's in CVS. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 5 19:33:32 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 14:33:32 -0500 Subject: [Bug 180058] Review Request: ecore: An event and X abstraction layer In-Reply-To: Message-ID: <200602051933.k15JXW4I005510@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ecore: An event and X abstraction layer https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180058 ------- Additional Comments From ivazquez at ivazquez.net 2006-02-05 14:33 EST ------- Updated. I'll update it for modular X once it's in CVS. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 5 19:46:23 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 14:46:23 -0500 Subject: [Bug 180052] Review Request: evas: A hardware-accelerated canvas API In-Reply-To: Message-ID: <200602051946.k15JkNMs007312@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: evas: A hardware-accelerated canvas API https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180052 ------- Additional Comments From eric.tanguy at univ-nantes.fr 2006-02-05 14:46 EST ------- Ok for modular X but i could be interesting to enable cairo support, no ? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From eric.tanguy at univ-nantes.fr Sun Feb 5 19:54:34 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Sun, 05 Feb 2006 20:54:34 +0100 Subject: Qucs no more build in devel In-Reply-To: <1139043102.14676.2.camel@ignacio.lan> References: <1139041981.3121.9.camel@bureau.maison> <1139042368.14676.0.camel@ignacio.lan> <1139042704.3121.11.camel@bureau.maison> <1139043102.14676.2.camel@ignacio.lan> Message-ID: <1139169274.3112.4.camel@bureau.maison> Le samedi 04 f?vrier 2006 ? 03:51 -0500, Ignacio Vazquez-Abrams a ?crit : > On Sat, 2006-02-04 at 09:45 +0100, Eric Tanguy wrote: > > Le samedi 04 f?vrier 2006 ? 03:39 -0500, Ignacio Vazquez-Abrams a > > ?crit : > > > On Sat, 2006-02-04 at 09:33 +0100, Eric Tanguy wrote: > > > > But i can't try either qucs or freehdl using gcc-4.1 because my own > > > > system is fc4. > > > > > > Okay, you *really* need to set up mock on your machine... > > > > > Mock is set up on my machine so i know it biulds fine now but i have no > > mean to test the program running with gcc-4.1. > > You could always chroot to /var/lib/mock/foo/root and test there. > It's more difficult to test X apps like this... Eric From bugzilla at redhat.com Sun Feb 5 19:53:55 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 14:53:55 -0500 Subject: [Bug 168690] Review Request: pyBackPack (GTK+ Python backup tool) In-Reply-To: Message-ID: <200602051953.k15Jrt87008177@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: pyBackPack (GTK+ Python backup tool) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168690 ------- Additional Comments From kevin at tummy.com 2006-02-05 14:53 EST ------- Hey Dave. Hopefully you are still out there. ;) I also get the traceback that Luke reported in comment #4. I'd be happy to work with you to track it down and fix it. Also, I'd consider sponsoring you, but as Warren mentioned in comment #5, the best way for sponsors to see that you understand the guidelines is to see comments from you on other packages that are in review. I currently don't see any comments out there from you. You can find a list of packages in NEW or REVIEW state at: https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=FE-NEW&hide_resolved=1 https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=FE-REVIEW&hide_resolved=1 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 5 19:54:31 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 14:54:31 -0500 Subject: [Bug 180052] Review Request: evas: A hardware-accelerated canvas API In-Reply-To: Message-ID: <200602051954.k15JsVJg008309@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: evas: A hardware-accelerated canvas API https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180052 ------- Additional Comments From ivazquez at ivazquez.net 2006-02-05 14:54 EST ------- I'll cross that bridge when I get to it. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 5 19:59:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 14:59:36 -0500 Subject: [Bug 171040] Review Request: postgis In-Reply-To: Message-ID: <200602051959.k15JxasT009071@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: postgis https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171040 ------- Additional Comments From kevin at tummy.com 2006-02-05 14:59 EST ------- In reply to comment #2: See the new package guidelines at: http://fedoraproject.org/wiki/Packaging/ReviewGuidelines Once you have your fc5 package and spec, post them to this bug, and wait for reviews. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 5 20:01:40 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 15:01:40 -0500 Subject: [Bug 180102] New: Review Request: embryo: A C like scripting language Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180102 Summary: Review Request: embryo: A C like scripting language Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: ivazquez at ivazquez.net QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://fedora.ivazquez.net/files/extras/embryo.spec SRPM Name or Url: http://fedora.ivazquez.net/files/extras/evas-0.9.1.023-1.src.rpm Description: Embryo implements a C like scripting language used in various parts of the Enlightenment project, namely Edje. Embryo's scripting language is based on CompuPhase's Small language that was introduced in Dr Dobb's Journal in 1999. Embryo allows scripting capabilities in places that otherwise wouldn't support basic programming structures such as in Edje EDCs. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 5 20:15:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 15:15:13 -0500 Subject: [Bug 172803] Review Request: openssl097f - compat package to help transitioning to new openssl In-Reply-To: Message-ID: <200602052015.k15KFDdx010855@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openssl097f - compat package to help transitioning to new openssl https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172803 ------- Additional Comments From kevin at tummy.com 2006-02-05 15:15 EST ------- openssl097a-0.9.7a-4.1 seems to currently be in devel/rawhide. Are you suggesting that it be moved to extras? If thats the intention, I would be happy to review it, otherwise we should probibly just close this bug? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 5 21:00:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 16:00:53 -0500 Subject: [Bug 179802] Review Request: seamonkey In-Reply-To: Message-ID: <200602052100.k15L0r4P016406@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: seamonkey https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179802 jwboyer at jdub.homelinux.org changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |163778, 177841 nThis| | ------- Additional Comments From jwboyer at jdub.homelinux.org 2006-02-05 16:00 EST ------- Fixed up the tracker bugs -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 5 21:11:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 16:11:10 -0500 Subject: [Bug 173368] Review Request: planetplanet In-Reply-To: Message-ID: <200602052111.k15LBA7f017508@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: planetplanet https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173368 kevin at tummy.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |kevin at tummy.com OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From kevin at tummy.com 2006-02-05 16:11 EST ------- A review: MUST items: OK - No rpmlint output OK - Package name. OK - Spec file name matches. OK - Package guidelines. SEE #1 BELOW - License. (Python) (but see item #1 below) OK - License field matches in spec. OK - License included in files. OK - Spec in american english. SEE #2 BELOW - md5sum of source from upstream OK - Compiles and builds on one arch at least. OK - No forbidden buildrequires included OK - Owns all directories it creates. OK - No duplicate files in %files listing. OK - Permissions on files correct. OK - Clean section correct. OK - Macros consistant. OK - Code not content. OK - Doesn't own any files/dirs that are already owned by other packages. Items needing attention: 1. The package is licensed under the Python license, but the planet/htmltmpl.py file appears to be under the GPL. Doesn't that mean the entire package has to be released under the GPL? 2. Wanted to check the md5sum against upstream, but it's unclear how to get the specific version you are using out of their arch/bzr setup. Can you provide a bzr command to get that version? Also, you might want to upgrade to the latest. SHOULD Items: OK - Package builds in mock. OK - Binary rpms on all arches. (x86 and x86_64 at least, don't have ppc) OK - Check for functionality. Seems to work fine here. Additionally, since you are seeking a sponsor, you should consider commenting on others packages to show your good understanding of the package guidelines. You can find the list of packages awaiting review at: https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=FE-NEW&hide_resolved=1 and the ones in review and seeking more comments at: https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=FE-REVIEW&hide_resolved=1 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 5 21:11:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 16:11:15 -0500 Subject: [Bug 176733] Review Request: php-pear-DB (PEAR database abstraction layer) In-Reply-To: Message-ID: <200602052111.k15LBFDX017545@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-pear-DB (PEAR database abstraction layer) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176733 ------- Additional Comments From rpm at timj.co.uk 2006-02-05 16:11 EST ------- The DB.xml file is static for a particular version of a package, so yes you're right that maybe %_var is not the right place. libdir/php/pear sounds good to me; any comments to the contrary? The only possible problem is that I *think* this was formerly used in some installations as the actual installation directory for PEAR modules; that shouldn't actually be a problem but may make a slight mess. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 5 21:26:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 16:26:30 -0500 Subject: [Bug 179910] Review Request: commoncpp C++ framework In-Reply-To: Message-ID: <200602052126.k15LQU0K019215@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: commoncpp C++ framework https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179910 ------- Additional Comments From ville.skytta at iki.fi 2006-02-05 16:26 EST ------- Blockers: - need fully versioned %{name} = %{version}-%{release} dependency in -devel. - need Requires: libxml2-devel and zlib-devel in -devel (see ccgnu2-config --stdlibs and --extlibs, and libccext2.pc, and some installed *.h) Suggestions: - configure with --disable-dependency-tracking for possibly faster builds and cleaner build output - Don't hardcode .gz in info filenames, install-info works without it and * can be used in %files - install-info is not a "Requires", it's "Requires(post)" and "Requires(preun)" - move %doc in -devel's %files after %defattr (actually, I'm a bit surprised that it being before %defattr doesn't cause problems with files being owned by the build owner here) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 5 21:35:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 16:35:18 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602052135.k15LZIuq020611@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From dennis at ausil.us 2006-02-05 16:35 EST ------- made a quick attempt to try with kdemultimedia 3.5.1 and its wanting unsermake -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 5 21:37:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 16:37:30 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602052137.k15LbUks020836@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From rdieter at math.unl.edu 2006-02-05 16:37 EST ------- It builds fine for me (in mock), and I have no unsermake. Could you post the failed build log? (or at least the errors you receive)? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 5 21:42:24 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 16:42:24 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602052142.k15LgOdI021388@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From rdieter at math.unl.edu 2006-02-05 16:42 EST ------- %changelog * Mon Jan 23 2006 Rex Dieter 6:3.5.1-1.1 - document "cleanup .la files" (#178734) - (re)enable juk * Sat Jan 21 2006 Rex Dieter 6:3.5.1-1.0 - kde-3.5.1 Spec Name or Url: http://apt.kde-redhat.org/apt/kde-redhat/SPECS/kdemultimedia-extras.spec SRPM Name or Url: http://apt.kde-redhat.org/apt/kde-redhat/all/SRPMS.stable/kdemultimedia-extras-3.5.1-1.1.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 5 21:52:29 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 16:52:29 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602052152.k15LqTbS022338@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From dennis at ausil.us 2006-02-05 16:52 EST ------- trying in mock now. i have unsermake installed on my desktop. hence it tried to use it and failed. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 5 22:02:23 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 17:02:23 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602052202.k15M2NsR023447@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From dennis at ausil.us 2006-02-05 17:02 EST ------- development tree build fails it needs to use the correct gstreamer plugins development package one of the following gstreamer-plugins-base-devel gstreamer-plugins-good-devel gstreamer08-plugins-devel -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From wolfy at nobugconsulting.ro Mon Feb 6 00:32:10 2006 From: wolfy at nobugconsulting.ro (lonely wolf) Date: Mon, 06 Feb 2006 02:32:10 +0200 Subject: How to downgrade version of a program? In-Reply-To: <43E5D8E7.9080107@fedora.pl> References: <43E3ECE5.8010705@fedora.pl> <1139135820.8440.14.camel@bobcat.mine.nu> <43E5D8E7.9080107@fedora.pl> Message-ID: <43E6990A.8070400@nobugconsulting.ro> Dawid Gajownik wrote: > Dnia 02/05/2006 11:38 AM, U?ytkownik Ville Skytt? napisa?: > >> Yep, that's too bad, and looks like rpm won't be fixed: >> https://bugzilla.redhat.com/168563 > > > What a pity :( > >>> Is Epoch bump the only solution? >> >> >> I'm afraid it is. > > > Thanks for the answer! > How about one of the followings brute force methods: a) rpm -U --oldpackage sqlite-2.0 b) rpm -e --nodeps sqlite 2.1 && yum install sqlite 2.0 From bugzilla at redhat.com Mon Feb 6 00:31:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 19:31:16 -0500 Subject: [Bug 179818] Review Request: xpilot-ng - A mutiplayer space arcade game In-Reply-To: Message-ID: <200602060031.k160VGGr007158@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xpilot-ng - A mutiplayer space arcade game https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179818 ------- Additional Comments From wart at kobold.org 2006-02-05 19:31 EST ------- (In reply to comment #7) > MUST FIX: > *use %{version} in Source0 Added. > *don't cp the doc-files to .server versions use just them 2 times in the %doc > parts of the %files sections For some misguided reason I thought that this would result in both packages owning the files. Fixed. > *icons should be installed in /usr/share/icons/hicolor/48x48/apps/ > (freedekstop.org standard) Fixed. > *and then should run gtk-update-icon-cache in %post(un), use the > scriptlets found on: http://www.fedoraproject.org/wiki/ScriptletSnippets > for this. Fixed. http://www.kobold.org/~wart/fedora/xpilot-ng-4.7.2-4.src.rpm http://www.kobold.org/~wart/fedora/xpilot-ng.spec -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 6 00:50:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 19:50:34 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602060050.k160oYFx009446@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From rdieter at math.unl.edu 2006-02-05 19:50 EST ------- Please ignore devel for now, as this package is (primarily) targetted for fc4. Though, for devel, I'm pretty sure the correct BR is gstreamer08-plugins-devel. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 6 01:55:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 20:55:56 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602060155.k161tuCB016767@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From rdieter at math.unl.edu 2006-02-05 20:55 EST ------- (ignore comment #15, should be fixed now). %changelog * Sun Feb 05 2006 Rex Dieter 6:3.5.1-2 - fc5+: BR: gstreamer08-plugins-devel Spec Name or Url: http://apt.kde-redhat.org/apt/kde-redhat/SPECS/kdemultimedia-extras.spec SRPM Name or Url: http://apt.kde-redhat.org/apt/kde-redhat/all/SRPMS.stable/kdemultimedia-extras-3.5.1-2.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 6 02:02:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 5 Feb 2006 21:02:02 -0500 Subject: [Bug 172140] Review Request: libmal: a convenience library for malsync In-Reply-To: Message-ID: <200602060202.k16222r5017477@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libmal: a convenience library for malsync https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172140 ------- Additional Comments From rdieter at math.unl.edu 2006-02-05 21:01 EST ------- Yes, still need a reviewer. No, I want/need libmal-0.31, since that's what kdepim currently can use. When/if there's ever a need/demand for 0.40, we can make a compat pkg. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From chabotc at xs4all.nl Mon Feb 6 07:24:07 2006 From: chabotc at xs4all.nl (Chris Chabot) Date: Mon, 06 Feb 2006 08:24:07 +0100 Subject: How to downgrade version of a program? In-Reply-To: <43E6990A.8070400@nobugconsulting.ro> References: <43E3ECE5.8010705@fedora.pl> <1139135820.8440.14.camel@bobcat.mine.nu> <43E5D8E7.9080107@fedora.pl> <43E6990A.8070400@nobugconsulting.ro> Message-ID: <1139210647.1819.0.camel@localhost.localdomain> > b) rpm -e --nodeps sqlite 2.1 && yum install sqlite 2.0 > Doesn't yum actually require sqlite to operate? Doing b) might be a bad choice in that case :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugzilla at redhat.com Mon Feb 6 07:48:06 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 02:48:06 -0500 Subject: [Bug 172803] Review Request: openssl097f - compat package to help transitioning to new openssl In-Reply-To: Message-ID: <200602060748.k167m6S8025897@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openssl097f - compat package to help transitioning to new openssl https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172803 tmraz at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NOTABUG OtherBugsDependingO|163776 | nThis| | ------- Additional Comments From tmraz at redhat.com 2006-02-06 02:48 EST ------- No, openssl097a will stay in core for now. I'm backing out of the review request. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From tla-ml at rasmil.dk Mon Feb 6 15:35:27 2006 From: tla-ml at rasmil.dk (Tim Lauridsen) Date: Mon, 06 Feb 2006 10:35:27 -0500 Subject: How to downgrade version of a program? In-Reply-To: <43E6990A.8070400@nobugconsulting.ro> References: <43E3ECE5.8010705@fedora.pl> <1139135820.8440.14.camel@bobcat.mine.nu> <43E5D8E7.9080107@fedora.pl> <43E6990A.8070400@nobugconsulting.ro> Message-ID: <43E76CBF.8070000@rasmil.dk> lonely wolf wrote: > Dawid Gajownik wrote: > >> Dnia 02/05/2006 11:38 AM, U?ytkownik Ville Skytt? napisa?: >> >>> Yep, that's too bad, and looks like rpm won't be fixed: >>> https://bugzilla.redhat.com/168563 >> >> >> What a pity :( >> >>>> Is Epoch bump the only solution? >>> >>> >>> I'm afraid it is. >> >> >> Thanks for the answer! >> > How about one of the followings brute force methods: > a) rpm -U --oldpackage sqlite-2.0 > b) rpm -e --nodeps sqlite 2.1 && yum install sqlite 2.0 > > b) is a very bad thing, i tried it, in a moment of insanity. :-( It break rpm and yum, then it is very hard to update something. Tim From bugzilla at redhat.com Mon Feb 6 09:37:19 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 04:37:19 -0500 Subject: [Bug 179818] Review Request: xpilot-ng - A mutiplayer space arcade game In-Reply-To: Message-ID: <200602060937.k169bJU6013207@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xpilot-ng - A mutiplayer space arcade game https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179818 j.w.r.degoede at hhs.nl changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From j.w.r.degoede at hhs.nl 2006-02-06 04:37 EST ------- Checking ... Approved Notes: -I'm now behind my i386 machine and that freezes when running this probably xorg bug, it does run for you? (worked fine on my x86_64). -It wouldn't build without disabling selinux because of the new execstack selinux stuff, I hope it will build on the buildsys, but I'm not sure. This is a rawhide problem, not a problem in / with the src.rpm -please pass -p (preserve timestamps) to install that way 2 builds (on say 2 different archs) of the same build end up with the same timestamps for identical files. Having different timestamps for things like icons can cause problems for multilib systems. (Not really an issue in this case though). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 6 10:34:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 05:34:52 -0500 Subject: [Bug 180149] New: Review Request: edje: A complex graphical design and layout library Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180149 Summary: Review Request: edje: A complex graphical design and layout library Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: ivazquez at ivazquez.net QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://fedora.ivazquez.net/files/extras/edje.spec SRPM Name or Url: http://fedora.ivazquez.net/files/extras/edje-0.5.0.023-1.src.rpm Description: Edje is a complex graphical design & layout library. Its purpose is to be a sequel to "Ebits" which to date has serviced the needs of Enlightenment development for version 0.17. The original design parameters under which Ebits came about were a lot more restricted than the resulting use of them, thus Edje was born. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 6 11:22:40 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 06:22:40 -0500 Subject: [Bug 179910] Review Request: commoncpp C++ framework In-Reply-To: Message-ID: <200602061122.k16BMeeO031156@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: commoncpp C++ framework https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179910 ------- Additional Comments From andreas at bawue.net 2006-02-06 06:22 EST ------- Changes incorporated. http://helena.bawue.de/~ixs/commoncpp/ I'm a bit surprised though, to notice that the external dependencies were not taken up by rpm automagically. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 6 12:39:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 07:39:33 -0500 Subject: [Bug 170303] Review Request: google-perftools: Very fast malloc & performance analysis tools In-Reply-To: Message-ID: <200602061239.k16CdXvD010519@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: google-perftools: Very fast malloc & performance analysis tools https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170303 ------- Additional Comments From dmitry at butskoy.name 2006-02-06 07:39 EST ------- 0.6 upstream. All the same... :( -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From eric.tanguy at univ-nantes.fr Mon Feb 6 12:44:30 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Mon, 06 Feb 2006 13:44:30 +0100 Subject: Mock question Message-ID: <1139229870.3120.9.camel@bureau.maison> Is mock using buildsys-macros because it seems that %fedora and %dist are not filled at least using mock with fedora-5-i386-core. Eric From bugzilla at redhat.com Mon Feb 6 12:45:39 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 07:45:39 -0500 Subject: [Bug 170973] Review Request: gnomebaker: Gnome CD/DVD burner In-Reply-To: Message-ID: <200602061245.k16CjdZd011339@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnomebaker: Gnome CD/DVD burner https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170973 adrian at lisas.de changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From adrian at lisas.de 2006-02-06 07:45 EST ------- * source matches upstream * rpmlint is happy * spec looks good * clean installation and removal * works as expected * builds in mock APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 6 12:53:43 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 07:53:43 -0500 Subject: [Bug 171040] Review Request: postgis In-Reply-To: Message-ID: <200602061253.k16Crhub012427@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: postgis https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171040 ------- Additional Comments From bugs.michael at gmx.net 2006-02-06 07:53 EST ------- Just a comment while purging messages from one of my mail folders: > make %{?_smp_mflags} PGXS=1 PGSQL_SRC=/usr/lib/pgsql/pgxs LPATH=\$\(pkglibdir\) > make install DESTDIR=$RPM_BUILD_ROOT PGXS=1 PGSQL_SRC=/usr/lib/pgsql/pgxs > %files > %defattr(-,root,root,-) > %{_libdir}/pgsql/* The hardcoded /usr/lib here most certainly breaks on 64-bit multilib platforms where %_libdir is /usr/lib64. Which package owns the "pgxs" directory? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 6 12:57:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 07:57:53 -0500 Subject: [Bug 174377] Review Request:gnu-smalltalk - GNU Smalltalk In-Reply-To: Message-ID: <200602061257.k16Cvr7L012874@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request:gnu-smalltalk - GNU Smalltalk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174377 ------- Additional Comments From michel.salim at gmail.com 2006-02-06 07:57 EST ------- Only the .i686 RPM is uploaded on that address. I rebuilt from the new .spec file, and on i386 gets the same errors you get. The shlib-with-non-pic-code is probably not that bad; I just recompiled libid3tag to compare and it produced the same error with rpmlint. So you're down to one error (rpath) plus compilation failure on x86_64 if the patch is applied. The 'make check' log is attached; look for this line in it: ./run-test: line 9: 6984 Segmentation fault $top_builddir/gst -rI $top_builddir/gst.im ${base}.st >$build_base.log 2>&1 At this point it's probably advisable to contact upstream developers and ask about the rpath problem (also, why renaming the package and regenerating the build scripts cause some libraries to fail on some platforms). Once we know more about the rpath problem, a quick fix would be for you to exclude x86_64 from the supported architecture, pending a fix for that, and the package can then be approved. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From wolfy at nobugconsulting.ro Mon Feb 6 13:08:08 2006 From: wolfy at nobugconsulting.ro (lonely wolf) Date: Mon, 06 Feb 2006 15:08:08 +0200 Subject: How to downgrade version of a program? In-Reply-To: <43E76CBF.8070000@rasmil.dk> References: <43E3ECE5.8010705@fedora.pl> <1139135820.8440.14.camel@bobcat.mine.nu> <43E5D8E7.9080107@fedora.pl> <43E6990A.8070400@nobugconsulting.ro> <43E76CBF.8070000@rasmil.dk> Message-ID: <43E74A38.6040008@nobugconsulting.ro> Tim Lauridsen wrote: >> How about one of the followings brute force methods: >> a) rpm -U --oldpackage sqlite-2.0 >> b) rpm -e --nodeps sqlite 2.1 && yum install sqlite 2.0 >> >> > b) is a very bad thing, i tried it, in a moment of insanity. :-( > It break rpm and yum, then it is very hard to update something. been there, done that. just copy the required libs from a different (functional) system. or use an older yum, which does not rely on sqlite. but yes, of course, using rpm -e --nodeps requires a bit of insanity :) (which is why I always try yum remove first, at least I know what might be broken after the forced removal) From rc040203 at freenet.de Mon Feb 6 13:07:51 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 06 Feb 2006 14:07:51 +0100 Subject: rpms/bidiv/FC-3 .cvsignore, 1.2, 1.3 bidiv.spec, 1.1, 1.2 sources, 1.2, 1.3 In-Reply-To: <200602061046.k16AkWo3004888@cvs-int.fedora.redhat.com> References: <200602061046.k16AkWo3004888@cvs-int.fedora.redhat.com> Message-ID: <1139231271.1084.29.camel@mccallum.corsepiu.local> On Mon, 2006-02-06 at 05:45 -0500, Dan Kenigsberg wrote: > Author: danken > diff -u -r1.2 -r1.3 > --- .cvsignore 29 Jan 2006 07:12:58 -0000 1.2 > +++ .cvsignore 6 Feb 2006 10:45:59 -0000 1.3 > @@ -1 +1,2 @@ > bidiv-1.5.tgz > +nostrip.patch.gz Would you please chose a unique name for your patch, preferably prefixed with your packages name? Thanks, Ralf From bugzilla at redhat.com Mon Feb 6 13:09:29 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 08:09:29 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602061309.k16D9T4J014409@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From dennis at ausil.us 2006-02-06 08:09 EST ------- akode is missing from fc4 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 6 13:14:40 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 08:14:40 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602061314.k16DEeB1015040@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From rdieter at math.unl.edu 2006-02-06 08:14 EST ------- fc4 building now, should appear shortly. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 6 13:27:55 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 08:27:55 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602061327.k16DRtTE017010@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From rdieter at math.unl.edu 2006-02-06 08:27 EST ------- 3760 (akode): Build on target fedora-4-extras succeeded. Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-4-extras/3760-akode-2.0-1.fc4/ -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From gajownik at fedora.pl Mon Feb 6 14:08:07 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Mon, 06 Feb 2006 15:08:07 +0100 Subject: How to downgrade version of a program? In-Reply-To: <43E6990A.8070400@nobugconsulting.ro> References: <43E3ECE5.8010705@fedora.pl> <1139135820.8440.14.camel@bobcat.mine.nu> <43E5D8E7.9080107@fedora.pl> <43E6990A.8070400@nobugconsulting.ro> Message-ID: <43E75847.1010209@fedora.pl> Dnia 02/06/2006 01:33 AM, U?ytkownik lonely wolf napisa?: > How about one of the followings brute force methods: These methods cannot be used because most of the users do not read fedora-*-list and they would not know that python-sqlite2-2.1.0-1.fc4 was broken. Whole downgrading process must be done automatically via yum or rpm. Without epoch bump `yum update' would also replace python-sqlite2-2.0.7-1.fc4 with python-sqlite2-2.1.0-1.fc4. Regards, Dawid -- ^_* From bugzilla at redhat.com Mon Feb 6 14:11:04 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 09:11:04 -0500 Subject: [Bug 178901] Review Request: gtksourceview-sharp In-Reply-To: Message-ID: <200602061411.k16EB4Tb023908@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gtksourceview-sharp https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178901 ------- Additional Comments From rowan at stasis.org 2006-02-06 09:10 EST ------- gtksourceview-1.5.7-1 gtksourceview-devel-1.5.7-1 mono-core-1.1.13.2-1 gtksharp2 not installed Haven't updated to latest Rawhide yet (still on the Feb 03 version) but probably will today. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 6 14:42:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 09:42:11 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602061442.k16EgBe2029588@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From dennis at ausil.us 2006-02-06 09:41 EST ------- juk still has some issues on devel. im about to build a fc4 package and test it. rpmlint shows E: kdemultimedia-extras invalid-soname /usr/lib64/libarts_akode.so libarts_akode.so which is ok. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 6 14:47:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 09:47:44 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602061447.k16Eli6a030673@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From rdieter at math.unl.edu 2006-02-06 09:47 EST ------- Ah, could be a x86_64-specific problem. Regardless, I consider juk to be a minor part here (the extra audio/video metafile/ecoding/decoding bits are, IMO). I'd rather this review not get bogged down in debugging one included app. As I said before, if juk becomes too burdensome with problems, we could just as easily omit it (and possibly package it separately). Those backtraces would be better served being submitted upstream to bugs.kde.org -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 6 15:14:40 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 10:14:40 -0500 Subject: [Bug 180164] New: Review Request: muine Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180164 Summary: Review Request: muine Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: foolish at guezz.net QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://folk.ntnu.no/sindrb/packages/muine.spec SRPM Name or Url: http://folk.ntnu.no/sindrb/packages/muine-0.8.4-1.src.rpm Description: Muine is a new music player for GNOME using some new UI ideas. The idea is that it will be much easier and comfortable to use than the iTunes model, which is used by most GNOME music players. It is written in C and C#, using GStreamer for music playback. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 6 15:19:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 10:19:09 -0500 Subject: [Bug 175748] Review Request: cacti In-Reply-To: Message-ID: <200602061519.k16FJ9Fh004956@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cacti https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175748 ------- Additional Comments From gauret at free.fr 2006-02-06 10:19 EST ------- OK, it looks good. Minor improvements: - add " || : " at the end of the scriptlets to make sure they always return 0 - the logrotate file contains a "//" in the logfile path - please add a README.Fedora with something like that : If you have SELinux enabled, you have to run the following commands : chcon -R -t httpd_sys_content_t /var/log/cacti/ chcon -R -t httpd_sys_content_t /var/lib/cacti/rra/ This README could be removed when cacti is added into the policy. If you agree with the above, make the changes and I'll approve it -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From katzj at redhat.com Mon Feb 6 15:50:47 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Feb 2006 10:50:47 -0500 Subject: How to downgrade version of a program? In-Reply-To: <1139210647.1819.0.camel@localhost.localdomain> References: <43E3ECE5.8010705@fedora.pl> <1139135820.8440.14.camel@bobcat.mine.nu> <43E5D8E7.9080107@fedora.pl> <43E6990A.8070400@nobugconsulting.ro> <1139210647.1819.0.camel@localhost.localdomain> Message-ID: <1139241048.12453.4.camel@bree.local.net> On Mon, 2006-02-06 at 08:24 +0100, Chris Chabot wrote: > > b) rpm -e --nodeps sqlite 2.1 && yum install sqlite 2.0 > > Doesn't yum actually require sqlite to operate? Doing b) might be a bad > choice in that case :-) No, yum will use sqlite if available to make things faster, but it does continue to work even without it[1] Jeremy [1] Well, unless that's broken recently. :) From bugzilla at redhat.com Mon Feb 6 15:47:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 10:47:28 -0500 Subject: [Bug 175748] Review Request: cacti In-Reply-To: Message-ID: <200602061547.k16FlSNM012014@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cacti https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175748 ------- Additional Comments From imlinux at gmail.com 2006-02-06 10:47 EST ------- Sounds good to me, all things added: %changelog * Mon Feb 6 2006 Mike McGrath - 0.8.6h-4 - Fixed some scriptlets to always return 0 - Fixed extra '/' in logrotate - Added README.Fedora SPEC: http://mmcgrath.net/~mmcgrath/cacti/cacti.spec SRPM: http://mmcgrath.net/~mmcgrath/cacti/cacti-0.8.6h-4.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From notting at redhat.com Mon Feb 6 16:08:38 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 6 Feb 2006 11:08:38 -0500 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: <878xsrs1rc.fsf@kosh.bigo.ensc.de> References: <87k6ccs4fu.fsf@kosh.bigo.ensc.de> <87fyn0rxbd.fsf@kosh.bigo.ensc.de> <1139000311.3377.32.camel@localhost> <1139054679.24024.19.camel@rousalka.dyndns.org> <878xsrs1rc.fsf@kosh.bigo.ensc.de> Message-ID: <20060206160838.GF18634@devserv.devel.redhat.com> Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: > Here, a '|| :' should be added. Else, scriptlets will fail when /usr/share > is shared between multiple hosts and mounted read-only therefore. fc-cache these days (as of a few weeks ago) only writes caches in /var... Bill From bugzilla at redhat.com Mon Feb 6 16:23:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 11:23:01 -0500 Subject: [Bug 179818] Review Request: xpilot-ng - A mutiplayer space arcade game In-Reply-To: Message-ID: <200602061623.k16GN1qF019766@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xpilot-ng - A mutiplayer space arcade game https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179818 ------- Additional Comments From wart at kobold.org 2006-02-06 11:22 EST ------- (In reply to comment #9) > Notes: > -I'm now behind my i386 machine and that freezes when running this probably xorg > bug, it does run for you? (worked fine on my x86_64). I've run the client in classic "x11" mode and the server on devel-i386 with no problem. Though now I notice that the newer SDL client fails to run on devel because of the execstack stuff. > -It wouldn't build without disabling selinux because of the new execstack > selinux stuff, I hope it will build on the buildsys, but I'm not sure. This > is a rawhide problem, not a problem in / with the src.rpm I haven't seen any problems building on my devel box, just running the newer SDL client because of the execstack stuff. > -please pass -p (preserve timestamps) to install that way 2 builds (on say 2 > different archs) of the same build end up with the same timestamps for > identical files. Having different timestamps for things like icons can cause > problems for multilib systems. (Not really an issue in this case though). Done. I'll add the -p to release -4 before importing to CVS. Thanks for the review! -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rdieter at math.unl.edu Mon Feb 6 16:32:11 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 06 Feb 2006 10:32:11 -0600 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: <20060206160838.GF18634@devserv.devel.redhat.com> References: <87k6ccs4fu.fsf@kosh.bigo.ensc.de> <87fyn0rxbd.fsf@kosh.bigo.ensc.de> <1139000311.3377.32.camel@localhost> <1139054679.24024.19.camel@rousalka.dyndns.org> <878xsrs1rc.fsf@kosh.bigo.ensc.de> <20060206160838.GF18634@devserv.devel.redhat.com> Message-ID: Bill Nottingham wrote: > Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: > >>Here, a '|| :' should be added. Else, scriptlets will fail when /usr/share >>is shared between multiple hosts and mounted read-only therefore. > > > fc-cache these days (as of a few weeks ago) only writes caches in /var... That's all well and good for fc5+ ... (-: Now go try to convince the gtk2 maintainer that the icon-cache belongs in /var too... -- Rex From bugzilla at redhat.com Mon Feb 6 16:40:25 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 11:40:25 -0500 Subject: [Bug 174377] Review Request:gnu-smalltalk - GNU Smalltalk In-Reply-To: Message-ID: <200602061640.k16GePpA024813@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request:gnu-smalltalk - GNU Smalltalk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174377 ------- Additional Comments From michel.salim at gmail.com 2006-02-06 11:40 EST ------- Similar rpath problem discussed on a Debian mailing list: http://lists.debian.org/debian-mentors/2005/10/msg00080.html I did a cursory scan and a lot of the Makefiles have -rpath in them. Perhaps you can automatically remove the references and try and see if it rebuilds fine and passes the test suite.. there is the possibility that the rpath's are all required, but in that case, the --disable-rpath switch should not be there in configure. For the PIC problem, just add --with-pic=yes to %configure. For some reason by default it uses both PIC and non-PIC object -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 6 16:53:43 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 11:53:43 -0500 Subject: [Bug 177658] Review Request: mediawiki - The PHP-based wiki software behind Wikipedia In-Reply-To: Message-ID: <200602061653.k16GrhUh028543@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mediawiki - The PHP-based wiki software behind Wikipedia https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177658 alexl at users.sourceforge.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexl at users.sourceforge.net ------- Additional Comments From alexl at users.sourceforge.net 2006-02-06 11:53 EST ------- Since this has now successfully been built in devel, it should be closed. Note also, however, bug #180177, which I just opened against mediawiki. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From kevin-fedora-extras at scrye.com Mon Feb 6 17:33:12 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Mon, 06 Feb 2006 10:33:12 -0700 (MST) Subject: Mock question References: <1139229870.3120.9.camel@bureau.maison> Message-ID: <20060206.103312.68377837.kevin@scrye.com> >>>>> "Eric" == Eric Tanguy writes: Eric> Is mock using buildsys-macros because it seems that %fedora and Eric> %dist are not filled at least using mock with Eric> fedora-5-i386-core. Eric Aren't those variables filled in when you make the src.rpm that you pass mock to build? I think you need to set them when you make a src.rpm for it to build. ie, if you look at what 'make mockbuild' target does: generate the src.rpm from the spec file, and set dist, etc: rpmbuild --define "_sourcedir /home/kevin/yourpackage" --define "_builddir /home/kevin/yourpackage" --define "_srcrpmdir /home/kevin/yourpackage" --define "_rpmdir /home/kevin/yourpackage" --define "dist .fc5" --define "fedora 5" --nodeps -bs yourpackage.spec Now, build it with mock: mock -r fedora-5-i386-core.cfg --resultdir=/home/kevin/yourpackage/mockbuild /home/kevin/yourpackage/yourpackage-0.1-1.fc5.src.rpm kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugzilla at redhat.com Mon Feb 6 17:30:23 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 12:30:23 -0500 Subject: [Bug 175433] Review Request: tor - Anonymizing overlay network for TCP (The onion router) In-Reply-To: Message-ID: <200602061730.k16HUNPO003792@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: tor - Anonymizing overlay network for TCP (The onion router) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175433 ------- Additional Comments From paul at xtdnet.nl 2006-02-06 12:30 EST ------- in btoh cases there are (i think unwanted) sub-packages. but in the later one, at least one can "yum install tor" to prevent some confusion, where as the one in #comment 10 you had to "yum install tor-lsb". So the latter one is better then the previous one, though I'm still in favour of one package until a new supported init system makes it into Fedora Core/Extras -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rdieter at math.unl.edu Mon Feb 6 17:49:35 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 06 Feb 2006 11:49:35 -0600 Subject: Mock question In-Reply-To: <20060206.103312.68377837.kevin@scrye.com> References: <1139229870.3120.9.camel@bureau.maison> <20060206.103312.68377837.kevin@scrye.com> Message-ID: Kevin Fenzi wrote: > Aren't those variables filled in when you make the src.rpm that you > pass mock to build? I think you need to set them when you make a > src.rpm for it to build. > > ie, if you look at what 'make mockbuild' target does: > > generate the src.rpm from the spec file, and set dist, etc: > > rpmbuild --define "_sourcedir /home/kevin/yourpackage" --define "_builddir /home/kevin/yourpackage" --define "_srcrpmdir /home/kevin/yourpackage" --define "_rpmdir /home/kevin/yourpackage" --define "dist .fc5" --define "fedora 5" --nodeps -bs yourpackage.spec > > Now, build it with mock: > > mock -r fedora-5-i386-core.cfg --resultdir=/home/kevin/yourpackage/mockbuild /home/kevin/yourpackage/yourpackage-0.1-1.fc5.src.rpm No, in the specfile, they're still referenced as %fedora and %dist, not replaced with hard-coded values. -- Rex From bugzilla at redhat.com Mon Feb 6 18:04:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 13:04:09 -0500 Subject: [Bug 179818] Review Request: xpilot-ng - A mutiplayer space arcade game In-Reply-To: Message-ID: <200602061804.k16I49NP010053@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xpilot-ng - A mutiplayer space arcade game https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179818 wart at kobold.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From wart at kobold.org 2006-02-06 13:04 EST ------- devel build (job #3772) succeeded. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From eric.tanguy at univ-nantes.fr Mon Feb 6 18:09:31 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Mon, 06 Feb 2006 19:09:31 +0100 Subject: Mock question In-Reply-To: References: <1139229870.3120.9.camel@bureau.maison> <20060206.103312.68377837.kevin@scrye.com> Message-ID: <1139249371.3121.7.camel@bureau.maison> Le lundi 06 f?vrier 2006 ? 11:49 -0600, Rex Dieter a ?crit : > Kevin Fenzi wrote: > > > Aren't those variables filled in when you make the src.rpm that you > > pass mock to build? I think you need to set them when you make a > > src.rpm for it to build. > > > > ie, if you look at what 'make mockbuild' target does: > > > > generate the src.rpm from the spec file, and set dist, etc: > > > > rpmbuild --define "_sourcedir /home/kevin/yourpackage" --define "_builddir /home/kevin/yourpackage" --define "_srcrpmdir /home/kevin/yourpackage" --define "_rpmdir /home/kevin/yourpackage" --define "dist .fc5" --define "fedora 5" --nodeps -bs yourpackage.spec > > > > Now, build it with mock: > > > > mock -r fedora-5-i386-core.cfg --resultdir=/home/kevin/yourpackage/mockbuild /home/kevin/yourpackage/yourpackage-0.1-1.fc5.src.rpm > > No, in the specfile, they're still referenced as %fedora and %dist, not > replaced with hard-coded values. > > -- Rex > So it seems that mock does not use buildsys-macros and i can't understand why ? Eric From rdieter at math.unl.edu Mon Feb 6 18:32:07 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 06 Feb 2006 12:32:07 -0600 Subject: Mock question In-Reply-To: <1139249371.3121.7.camel@bureau.maison> References: <1139229870.3120.9.camel@bureau.maison> <20060206.103312.68377837.kevin@scrye.com> <1139249371.3121.7.camel@bureau.maison> Message-ID: Eric Tanguy wrote: > So it seems that mock does not use buildsys-macros and i can't > understand why ? More specifically, *your* installation of mock doesn't use buildsys-macros. (-: Mine works just fine, thank you. -- Rex From bugzilla at redhat.com Mon Feb 6 18:45:42 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 13:45:42 -0500 Subject: [Bug 178263] Review Request: ncarg - A Fortran and C based software package for scientific visualization In-Reply-To: Message-ID: <200602061845.k16IjgxR019510@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ncarg - A Fortran and C based software package for scientific visualization https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178263 orion at cora.nwra.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From orion at cora.nwra.com 2006-02-06 13:45 EST ------- Checked in and built on devel. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From eric.tanguy at univ-nantes.fr Mon Feb 6 18:56:25 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Mon, 06 Feb 2006 19:56:25 +0100 Subject: Mock question In-Reply-To: References: <1139229870.3120.9.camel@bureau.maison> <20060206.103312.68377837.kevin@scrye.com> <1139249371.3121.7.camel@bureau.maison> Message-ID: <1139252185.3121.19.camel@bureau.maison> Le lundi 06 f?vrier 2006 ? 12:32 -0600, Rex Dieter a ?crit : > Eric Tanguy wrote: > > > So it seems that mock does not use buildsys-macros and i can't > > understand why ? > > More specifically, *your* installation of mock doesn't use > buildsys-macros. (-: > > Mine works just fine, thank you. > > -- Rex > So maybe you could explain me what you did to mock to use buildsys-macros ? and why this is not enable by default. Thanks Eric From bugzilla at redhat.com Mon Feb 6 18:55:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 13:55:11 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602061855.k16ItBk5021417@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From dennis at ausil.us 2006-02-06 13:55 EST ------- -md5sum kdemultimedia-3.5.1.tar.bz2 595f637c637987a92f6dac9d9cd6667d kdemultimedia-3.5.1.tar.bz2 matches values posted at http://kde.org/download/ -rpmlint is ok -package meets naming guidelines -spec file is named correctly -license is acceptable and correct -spec file is in english -package built in mock on devel for x86_64 and i386 extra build requires BuildRequires: libtheora-devel BuildRequires: libvorbis-devel >= 1:1.1.0 only need versioned one. i would also suggest that the commented out patches and defines be removed to clean things up a little. I would personally remove the gtk-update-icon-cache from post as I believe thats not where it belongs, but thats a personal preference and not a blocker. -no duplicate files -file permissions look good -package contains code - bad -package contains .la files -juk does not install .desktop file correctly -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rdieter at math.unl.edu Mon Feb 6 19:03:09 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 06 Feb 2006 13:03:09 -0600 Subject: Mock question In-Reply-To: <1139252185.3121.19.camel@bureau.maison> References: <1139229870.3120.9.camel@bureau.maison> <20060206.103312.68377837.kevin@scrye.com> <1139249371.3121.7.camel@bureau.maison> <1139252185.3121.19.camel@bureau.maison> Message-ID: Eric Tanguy wrote: > Le lundi 06 f?vrier 2006 ? 12:32 -0600, Rex Dieter a ?crit : >>Eric Tanguy wrote: >>More specifically, *your* installation of mock doesn't use >>buildsys-macros. (-: >> >>Mine works just fine, thank you. > So maybe you could explain me what you did to mock to use > buildsys-macros ? and why this is not enable by default. The default *is* to use it, my (and the default) fedora-5-*-core.cfg contains: [groups] name=groups baseurl=http://fedoraproject.org/buildgroups/development/$basearch/ Which holds the buildsys-macros and the proper buildroots.xml No idea why it's not working for you. -- Rex From bugzilla at redhat.com Mon Feb 6 18:59:32 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 13:59:32 -0500 Subject: [Bug 180199] New: Review Request: Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180199 Summary: Review Request: Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: splinux25 at gmail.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: SRPM Name or Url: Description: -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 6 19:04:58 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 14:04:58 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602061904.k16J4wfx023286@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From rdieter at math.unl.edu 2006-02-06 14:04 EST ------- > extra build requires > BuildRequires: libtheora-devel > BuildRequires: libvorbis-devel >= 1:1.1.0 > only need versioned one. I don't follow. Why? > -package contains .la files These are loadable modules, not devel libraries, so don't worry. (-: Regardless, kde really does need them unfortunately, so there's really no option to remove these. > I would personally remove the gtk-update-icon-cache from post as I believe > thats not where it belongs, Especially after the recent discussions on the mailing list(s), I agree 100%. > -juk does not install .desktop file correctly I assume you mean that we're missing: desktop-file-install --add-category "X-Fedora" ? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 6 19:32:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 14:32:09 -0500 Subject: [Bug 180205] New: Review Request: gnome-menu-editor Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180205 Summary: Review Request: gnome-menu-editor Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: splinux25 at gmail.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://glive.tuxfamily.org/fedora/gnome-menu-editor/gnome-menu-editor.spec SRPM Name or Url: http://glive.tuxfamily.org/fedora/gnome-menu-editor/gnome-menu-editor-0.5-1.src.rpm Description: Gnome-menu-editor is a simple menu editor for GNOME in its early stages. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From andreas.bierfert at lowlatency.de Mon Feb 6 19:41:26 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Mon, 06 Feb 2006 20:41:26 +0100 Subject: [Fwd: [Fedora Project Wiki] Update of "Extras/CVSSyncNeeded" by RoozbehPournader] In-Reply-To: <1139140540.25578.1.camel@tameshk.farsiweb.info> References: <43E5D623.1010106@lowlatency.de> <1139138474.3147.10.camel@tameshk.farsiweb.info> <43E5E28E.5050205@lowlatency.de> <1139140540.25578.1.camel@tameshk.farsiweb.info> Message-ID: <43E7A666.5010805@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roozbeh Pournader wrote: > I don't think these are special cases, but would you re-explain why > these are special? Why must an FC3 user be able to install these new > package on his system? Ok, as I would like to see libopensync-plugin-irmc in FC-3 as well. The libopensync stuff currently is not usable anyway because multisync is not reviewed yet so maybe we can argue about that at a later point. For openal/freealut this ihmo is a must: openal used to provide the stuff that now is in freealut and hence gone from openal itself. So when I pushed an openal upgrade to FC-3 the freealut stuff went away and users of that part now contained within freealut are sort of hanging. Now if you ask if an upgrade was necessary: yes. So the only solution is pushing freealut to FC-3 as well and that is why I requested it in the first place. - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFD56ZlQEQyPsWM8csRAuWVAJwNfQA6q7EdC8duOviQB4jRara/sgCeNP/e iOsNL42HZ/Icf63xR/v+Yuw= =B2+4 -----END PGP SIGNATURE----- From bugzilla at redhat.com Mon Feb 6 19:37:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 14:37:10 -0500 Subject: [Bug 180205] Review Request: gnome-menu-editor In-Reply-To: Message-ID: <200602061937.k16JbA6G000613@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-menu-editor https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180205 ------- Additional Comments From wart at kobold.org 2006-02-06 14:37 EST ------- A couple of comments (this is not a formal review): * Don't use the name/version/release defines at the top of the file. Set the values explicitly in the Name:, Version:, and Release: fields. These implicitly define %{name}, %{version}, and %{release} macros. * Be consistent with your use of $RPM_BUILD_ROOT and %{buildroot}. They both evaluate to the same value. Use one or the other in your specfile, but not both. * Don't use the Package and Vedor tags, per the FE packaging guidelines. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 6 19:51:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 14:51:44 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602061951.k16Jpifj004880@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From dennis at ausil.us 2006-02-06 14:51 EST ------- (In reply to comment #25) > > extra build requires > > BuildRequires: libtheora-devel > > BuildRequires: libvorbis-devel >= 1:1.1.0 > > only need versioned one. > > I don't follow. Why? Cause i misread :( sorry > > -package contains .la files > > These are loadable modules, not devel libraries, so don't worry. (-: > Regardless, kde really does need them unfortunately, so there's really no option > to remove these. yeah i thought they were getting removed > > I would personally remove the gtk-update-icon-cache from post as I believe > > thats not where it belongs, > > Especially after the recent discussions on the mailing list(s), I agree 100%. > > -juk does not install .desktop file correctly > > I assume you mean that we're missing: > desktop-file-install --add-category "X-Fedora" > ? yeah thats what i mean -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From jamatos at fc.up.pt Mon Feb 6 20:00:27 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Mon, 6 Feb 2006 20:00:27 +0000 Subject: Shortlog from todays fesco meeting In-Reply-To: <1138308919.2638.35.camel@localhost.localdomain> References: <1138308919.2638.35.camel@localhost.localdomain> Message-ID: <200602062000.27959.jamatos@fc.up.pt> On Thursday 26 January 2006 20:55, Thorsten Leemhuis wrote: > * Encourage more Extras reviews > > ?Create special interest groups? > > ?Input needed! I saw this page: http://www.fedoraproject.org/wiki/Extras/SIGs but I did not saw any discussion about it here. Am I missing any email messages? :-) I would like to see also defined the precise roles of SIG's. I would like to belong to python and to Scientific and Technical, FWIW. :-) Even although not everything is defined I like the idea. :-) -- Jos? Ab?lio From bugzilla at redhat.com Mon Feb 6 19:59:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 14:59:36 -0500 Subject: [Bug 180205] Review Request: gnome-menu-editor In-Reply-To: Message-ID: <200602061959.k16Jxaut007225@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-menu-editor https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180205 ------- Additional Comments From splinux25 at gmail.com 2006-02-06 14:59 EST ------- Ok, it's rebuild and changed. Spec Name or Url: http://glive.tuxfamily.org/fedora/gnome-menu-editor/gnome-menu-editor.spec SRPM Name or Url: http://glive.tuxfamily.org/fedora/gnome-menu-editor/gnome-menu-editor-0.5-1.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 6 20:08:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 15:08:01 -0500 Subject: [Bug 180255] New: Review Request: nazghul - Old school RPG engine Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180255 Summary: Review Request: nazghul - Old school RPG engine Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: tibbs at math.uh.edu QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.math.uh.edu/~tibbs/rpms/nazghul/nazghul.spec SRPM Name or Url: http://www.math.uh.edu/~tibbs/rpms/nazghul/nazghul-0.5.3-1.src.rpm Description: Nazghul is an old-school RPG engine modeled after those made in the heyday of top-down, 2d tile-based graphics. It is specifically modeled after Ultima V. Note that this SRPM builds two packages: nazghul, the game engine and nazghul-haxima, the supplied game, which is just plain text scheme code along with some images. rpmlint output: W: nazghul-haxima no-documentation -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 6 20:10:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 15:10:20 -0500 Subject: [Bug 180205] Review Request: gnome-menu-editor In-Reply-To: Message-ID: <200602062010.k16KAK50010900@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-menu-editor https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180205 ------- Additional Comments From wart at kobold.org 2006-02-06 15:10 EST ------- It looks like you lost your %clean section in this latest package. You should also increment the release number for every package that you build, even during this initial package review process. It makes it easier for reviewers to track changes between packages. I get build errors on FC-5: checking for GNOME_MENU_EDITOR_LIBS... configure: error: Package requirements (glib-2.0 >= 2.4.0 gtk+-2.0 >= 2.4.0 gnome-vfs-2.0 libgnome-menu >= 2.11.1 libxml-2.0 >= 2.6.0) were not met. Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively you may set the GNOME_MENU_EDITOR_CFLAGS and GNOME_MENU_EDITOR_LIBS environment variables to avoid the need to call pkg-config. See the pkg-config man page for more details. error: Bad exit status from /var/tmp/rpm-tmp.11642 (%build) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 6 20:14:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 15:14:35 -0500 Subject: [Bug 180205] Review Request: gnome-menu-editor In-Reply-To: Message-ID: <200602062014.k16KEZA5012417@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-menu-editor https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180205 ------- Additional Comments From wart at kobold.org 2006-02-06 15:14 EST ------- Based on the contents of owners.list, this looks like your first package. If this is the case the you should add the FE-NEEDSPONSOR blocker bug. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 6 20:15:05 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 15:15:05 -0500 Subject: [Bug 179916] Review Request: docbook2X - Convert docbook into man and Texinfo In-Reply-To: Message-ID: <200602062015.k16KF5GI012569@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: docbook2X - Convert docbook into man and Texinfo https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179916 jamatos at fc.up.pt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|bugzilla-sink at leemhuis.info |jamatos at fc.up.pt OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From jamatos at fc.up.pt 2006-02-06 15:14 EST ------- Expect a review soon. :-) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 6 20:19:29 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 15:19:29 -0500 Subject: [Bug 180149] Review Request: edje: A complex graphical design and layout library In-Reply-To: Message-ID: <200602062019.k16KJTPd013954@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: edje: A complex graphical design and layout library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180149 ------- Additional Comments From tibbs at math.uh.edu 2006-02-06 15:19 EST ------- Why does bug 180056 (system-config-httpd references obsolete module names) block this? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 6 20:39:41 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 15:39:41 -0500 Subject: [Bug 179910] Review Request: commoncpp C++ framework In-Reply-To: Message-ID: <200602062039.k16Kdfh6019521@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: commoncpp C++ framework https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179910 ville.skytta at iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From ville.skytta at iki.fi 2006-02-06 15:39 EST ------- Looks good. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 6 20:45:23 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 15:45:23 -0500 Subject: [Bug 179910] Review Request: commoncpp C++ framework In-Reply-To: Message-ID: <200602062045.k16KjN4Y020903@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: commoncpp C++ framework https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179910 ------- Additional Comments From andreas at bawue.net 2006-02-06 15:45 EST ------- thx for the review. as soon as this one is build, I'll put up the ccrtp for review. I'd be glad, if you could take alook as well. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 6 20:55:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 15:55:52 -0500 Subject: [Bug 180205] Review Request: gnome-menu-editor In-Reply-To: Message-ID: <200602062055.k16Ktqol023810@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-menu-editor https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180205 ------- Additional Comments From splinux25 at gmail.com 2006-02-06 15:55 EST ------- The specs file has been reorganised and packaged. Spec Name or Url:http://glive.tuxfamily.org/fedora/gnome-menu-editor/gnome-menu-editor.spec SRPM Name or Url: http://glive.tuxfamily.org/fedora/gnome-menu-editor/gnome-menu-editor-0.5-3.src.rpm For compil this package, you must install gtk2-devel, gnome-vfs2, vte-devel -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 6 21:11:03 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 16:11:03 -0500 Subject: [Bug 180205] Review Request: gnome-menu-editor In-Reply-To: Message-ID: <200602062111.k16LB3Ox027903@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-menu-editor https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180205 ------- Additional Comments From bdpepple at ameritech.net 2006-02-06 16:10 EST ------- Couple of things: 1. You got ownership problems with your datadir files. 2. Most of your requires are unnecessary since the devel sonames should pull them in. 3. Your missing the %clean section I would suggest reading the Fedora Extras wiki fully, because a lot of these issues are addressed there. In addition, before anyone will sponser you, you've got to demonstrate a good understanding of Fedora Extras packaging process & requirements. http://fedoraproject.org/wiki/Extras -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From paul at cypherpunks.ca Mon Feb 6 21:41:17 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Mon, 6 Feb 2006 22:41:17 +0100 (CET) Subject: What is the proper way to fix 'make tag' and 'make plague' conflict Message-ID: [ oops sent it to fedora-devel instead of fedora-extras ] Hey, Sometimes I am stupid and I forget to make tag after commiting my files and trying out make plague. You then end up in a situation where your release version exists in limbo: # make tag cvs tag -c fetchlog-1_0-3_fc5 For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs ? clog cvs tag: .cvsignore is locally modified ERROR: Tag fetchlog-1_0-3_fc5 has been already created. cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first! make: *** [tag] Error 1 [root at bofh devel]# make plague fetchlog.spec not tagged with tag fetchlog-1_0-3_fc5 make: *** [plague] Error 1 My fix so far has been to just bump the release, but that's rather ugly. Is there a "proper" fix for this situation (excluding brain surgery) Paul From buildsys at fedoraproject.org Mon Feb 6 21:38:56 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 6 Feb 2006 16:38:56 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060206213856.3BBD5800B@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 6 abiword-2.4.2-2.fc3 bidiv-1.5-2.fc3 bluefish-1.0.5-1.fc3 enchant-1.2.2-1.fc3 kphone-4.2-6.fc3 python-nltk-1.4.2-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From andreas.bierfert at lowlatency.de Mon Feb 6 21:39:04 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Mon, 06 Feb 2006 22:39:04 +0100 Subject: What is the proper way to fix 'make tag' and 'make plague' conflict In-Reply-To: References: Message-ID: <43E7C1F8.9010207@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Wouters wrote: > My fix so far has been to just bump the release, but that's rather ugly. > Is there a "proper" fix for this situation (excluding brain surgery) Actually it should not happen and there have been talks to add a check for this to the makefiles. You can do a 'cvs tag -F oldtag'. Where oldtag is the tag that was generated before. Be carefull with this so... - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFD58H4QEQyPsWM8csRAkxVAJ9fa+EKcYz/yQ+jTsDYYGEnFNyfUACgnnLz uusZjZbY3yi5lE7662++A9w= =9Ugm -----END PGP SIGNATURE----- From buildsys at fedoraproject.org Mon Feb 6 21:39:12 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 6 Feb 2006 16:39:12 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060206213912.15EA9800B@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 14 abiword-2.4.2-2.fc4 akode-2.0-1.fc4 bidiv-1.5-2.fc4 bluefish-1.0.5-1.fc4 chmlib-0.37.4-4.fc4 enchant-1.2.2-1.fc4 freealut-1.0.0-2.fc4 fwbuilder-2.0.10-1.fc4 kphone-4.2-6.fc4 libfwbuilder-2.0.10-1.fc4 libopensync-plugin-irmc-0.18-4.fc4 openal-0.0.9-0.2.20060204cvs.fc4 perl-GDGraph-1.4306-1.fc4 revelation-0.4.7-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon Feb 6 21:40:29 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 6 Feb 2006 16:40:29 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060206214029.378A1800B@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 25 abiword-2.4.2-4.fc5 abiword-2.4.2-5.fc5 barcode-0.98-8.fc5 bidiv-1.5-2.fc5 bluefish-1.0.5-1.fc5 cvs2cl-2.59-3.fc5 enchant-1.2.2-1.fc5 epiphany-extensions-1.9.6-1 fwbuilder-2.0.10-1.fc5 gnomebaker-0.5.1-2.fc5 gtkglext-1.2.0-1.fc5 gtkmathview-0.7.6-2.fc5 koffice-1.4.90-2.fc5 kphone-4.2-6.fc5 libfwbuilder-2.0.10-1.fc5 libsexy-0.1.6-1.fc5 mediawiki-1.5.6-5.fc5 meld-1.1.3-2.fc5 moin-1.5.2-1.fc5 ncarg-4.4.1-2.fc5 perl-Font-TTF-0.37-3.fc5 perl-GDGraph-1.4306-1.fc5 revelation-0.4.7-1.fc5 wxGTK-2.6.2-4.fc5 xpilot-ng-4.7.2-4.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From ville.skytta at iki.fi Mon Feb 6 21:53:04 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 06 Feb 2006 23:53:04 +0200 Subject: What is the proper way to fix 'make tag' and 'make plague' conflict In-Reply-To: References: Message-ID: <1139262784.29100.4.camel@bobcat.mine.nu> On Mon, 2006-02-06 at 22:41 +0100, Paul Wouters wrote: > My fix so far has been to just bump the release, but that's rather ugly. > Is there a "proper" fix for this situation (excluding brain surgery) IMNSHO bumping the release is the best available fix and force-tagging is much uglier. From andreas.bierfert at lowlatency.de Mon Feb 6 21:57:53 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Mon, 06 Feb 2006 22:57:53 +0100 Subject: What is the proper way to fix 'make tag' and 'make plague' conflict In-Reply-To: <1139262784.29100.4.camel@bobcat.mine.nu> References: <1139262784.29100.4.camel@bobcat.mine.nu> Message-ID: <43E7C661.5000509@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ville Skytt? wrote: > IMNSHO bumping the release is the best available fix and force-tagging > is much uglier. Hm, not that you need to but I really would like to know why you think that... :) just curious... - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFD58ZhQEQyPsWM8csRAmO8AJ9FcQO1yGpVxDYIk3BF06U3NzzJWwCeKE2G ZlLAg8OCXCro7ZuIFFpUbYM= =cswx -----END PGP SIGNATURE----- From eric.tanguy at univ-nantes.fr Mon Feb 6 22:07:07 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Mon, 06 Feb 2006 23:07:07 +0100 Subject: Mock question In-Reply-To: References: <1139229870.3120.9.camel@bureau.maison> <20060206.103312.68377837.kevin@scrye.com> <1139249371.3121.7.camel@bureau.maison> <1139252185.3121.19.camel@bureau.maison> Message-ID: <1139263627.3121.27.camel@bureau.maison> Le lundi 06 f?vrier 2006 ? 13:03 -0600, Rex Dieter a ?crit : > Eric Tanguy wrote: > > Le lundi 06 f?vrier 2006 ? 12:32 -0600, Rex Dieter a ?crit : > >>Eric Tanguy wrote: > > >>More specifically, *your* installation of mock doesn't use > >>buildsys-macros. (-: > >> > >>Mine works just fine, thank you. > > > So maybe you could explain me what you did to mock to use > > buildsys-macros ? and why this is not enable by default. > > The default *is* to use it, my (and the default) fedora-5-*-core.cfg > contains: > > [groups] > name=groups > baseurl=http://fedoraproject.org/buildgroups/development/$basearch/ > > Which holds the buildsys-macros and the proper buildroots.xml > > No idea why it's not working for you. This is because i had yum 2.5 from devel installed and with it all is fine except that groups install seems to not work. I downgraded yum to 2.4 and all is fine. I can't understand why yum 2.5 don't want to install groups under fc4. Eric From bugzilla at redhat.com Mon Feb 6 22:38:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 17:38:33 -0500 Subject: [Bug 175748] Review Request: cacti In-Reply-To: Message-ID: <200602062238.k16McXEu014336@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cacti https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175748 gauret at free.fr changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From gauret at free.fr 2006-02-06 17:38 EST ------- Review for release 4: * RPM name is OK * Source cacti-0.8.6h.tar.gz is the same as upstream * This is the latest version * Builds fine in mock * rpmlint looks OK * File list looks OK * Works fine APPROVED Again, sorry for keeping you waiting. Please post here the bug number for SELinux integration when you file it. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 6 23:29:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 18:29:21 -0500 Subject: [Bug 180298] New: Review Request: gnonlin Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180298 Summary: Review Request: gnonlin Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: redhat at flyn.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.flyn.org/SRPMS/gnonlin.spec SRPM Name or Url: http://www.flyn.org/SRPMS/gnonlin-0.10.0.5-1.src.rpm Description: Gnonlin is a library built on top of GStreamer (http://gstreamer.net) which provides support for writing non-linear audio and video editing applications. It introduces the concept of a timeline. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From paul at cypherpunks.ca Mon Feb 6 23:40:20 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Tue, 7 Feb 2006 00:40:20 +0100 (CET) Subject: What is the proper way to fix 'make tag' and 'make plague' conflict In-Reply-To: <43E7C1F8.9010207@lowlatency.de> References: <43E7C1F8.9010207@lowlatency.de> Message-ID: On Mon, 6 Feb 2006, Andreas Bierfert wrote: > Actually it should not happen and there have been talks to add a check for this > to the makefiles. > > You can do a 'cvs tag -F oldtag'. Where oldtag is the tag that was generated > before. Be carefull with this so... That did not work? $ cvs tag -F fetchlog-1_0-2_fc5 For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs ? clog cvs tag: Tagging . T fetchlog.spec T sources $ make tag cvs tag -c fetchlog-1_0-3_fc5 For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs ? clog ERROR: Tag fetchlog-1_0-3_fc5 has been already created. Unless I'm doing something wrong now? Paul From bugzilla at redhat.com Mon Feb 6 23:31:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 18:31:52 -0500 Subject: [Bug 180299] New: Review Request: pitivi Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180299 Summary: Review Request: pitivi Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: redhat at flyn.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.flyn.org/SRPMS/pitivi.spec SRPM Name or Url: http://www.flyn.org/SRPMS/pitivi-0.9.9.2-1.src.rpm Description: Pitivi is an application using the GStreamer multimedia framework to manipulate a large set of multimedia sources. At this level of development it can be compared to a classic video editing program. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 6 23:36:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 18:36:20 -0500 Subject: [Bug 180300] New: Review Request: ccrtp Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180300 Summary: Review Request: ccrtp Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: andreas at bawue.net QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://helena.bawue.de/~ixs/ccrtp/ccrtp.spec SRPM Name or Url: http://helena.bawue.de/~ixs/ccrtp/ccrtp-1.3.6-1.src.rpm Description: ccRTP is a generic, extensible and efficient C++ framework for developing applications based on the Real-Time Transport Protocol (RTP) from the IETF. It is based on Common C++ and provides a full RTP/RTCP stack for sending and receiving of realtime data by the use of send and receive packet queues. ccRTP supports unicast, multi-unicast and multicast, manages multiple sources, handles RTCP automatically, supports different threading models and is generic as for underlying network and transport protocols. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 6 23:58:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 18:58:20 -0500 Subject: [Bug 170973] Review Request: gnomebaker: Gnome CD/DVD burner In-Reply-To: Message-ID: <200602062358.k16NwKQE026627@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnomebaker: Gnome CD/DVD burner https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170973 bdpepple at ameritech.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From bdpepple at ameritech.net 2006-02-06 18:58 EST ------- Packages built, and should be available soon. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 7 01:10:23 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 20:10:23 -0500 Subject: [Bug 180149] Review Request: edje: A complex graphical design and layout library In-Reply-To: Message-ID: <200602070110.k171ANPn003536@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: edje: A complex graphical design and layout library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180149 ivazquez at ivazquez.net changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn|180056 |180058 ------- Additional Comments From ivazquez at ivazquez.net 2006-02-06 20:10 EST ------- Because I'm blind. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 01:48:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 20:48:21 -0500 Subject: [Bug 170303] Review Request: google-perftools: Very fast malloc & performance analysis tools In-Reply-To: Message-ID: <200602070148.k171mLux008115@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: google-perftools: Very fast malloc & performance analysis tools https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170303 ------- Additional Comments From redhat at efalk.org 2006-02-06 20:48 EST ------- Hi all; a few answers to questions: The package we built on sourceforge was named "google-perftools". You should stick to that naming convention to avoid confusion and dependency problems. You should definately avoid "perftools" because there are other software packages by that name. The web page on sourceforge is named "goog-perftools", but that's not significant. All of our sourceforge projects start with "goog-". Version 0.6 of perftools is now on sourceforge, and it removes the "docdir" cruft. I'll be taking a look at your revised packages and possibly incorporating them into our version. Packaging questions can be directed to me at efalk at users.sourceforge.net. Bug reports should be filed at http://sourceforge.net/projects/goog-perftools/ General questions can be directed to opensource at google.com; we all read that one. -ed falk, efalk at users.sourceforge.net -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 7 01:52:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2006 20:52:47 -0500 Subject: [Bug 170303] Review Request: google-perftools: Very fast malloc & performance analysis tools In-Reply-To: Message-ID: <200602070152.k171qlAS008809@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: google-perftools: Very fast malloc & performance analysis tools https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170303 ------- Additional Comments From redhat at efalk.org 2006-02-06 20:52 EST ------- Oh, and if 0.6 is still giving you some sort of build or check problems, please file a bug at the sourceforge web page, include the errors you're getting. -ef -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 7 05:08:24 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 00:08:24 -0500 Subject: [Bug 180298] Review Request: gnonlin In-Reply-To: Message-ID: <200602070508.k1758OZc029092@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnonlin https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180298 jeff at ollie.clive.ia.us changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bugzilla-sink at leemhuis.info |jeff at ollie.clive.ia.us ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-07 00:08 EST ------- 1. Don't use "%define name". The "Name:" tag implicitly defines the %name macro. 2. Need to BR gettext-devel 3. You don't need gst-register-0.10 in %post and %postun - not necessary anymore in gstreamer 0.10. 5. Delete the %{_libdir}/gstreamer-0.10/libgnl.la in %install 6. The -devel package needs to own %{_includedir}/gnl 7. Use "-p" on the manually installed header files. 8. User "make DESTDIR=$RPM_BUILD_ROOT install" not %makeinstall. 9. Running "aclocal" and "autoconf" in %prep doesn't really seem to be necessary. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 05:13:19 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 00:13:19 -0500 Subject: [Bug 180299] Review Request: pitivi In-Reply-To: Message-ID: <200602070513.k175DJOp029944@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: pitivi https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180299 jeff at ollie.clive.ia.us changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bugzilla-sink at leemhuis.info |jeff at ollie.clive.ia.us ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-07 00:13 EST ------- 1. Eliminate the various %defines at the beginning of the spec 2. Use "make DESTDIR=$RPM_BUILD_ROOT install" instead of %makeinstall 3. Use -p when manually calling install 4. Need to BuildRequire: gnonlin-devel 5. Need to Require: gnonlin 6. Use desktop-file-install to install .desktop file. See: 7. BuildArch: noarch 8. %files section probably would work better as follows. That way the .pyo files aren't packaged, but will be removed when the packags is uninstalled. %{_bindir}/pitivi %dir %{_libdir}/pitivi %dir %{_libdir}/pitivi/python %dir %{_libdir}/pitivi/python/pitivi %{_libdir}/pitivi/python/pitivi/*.py %{_libdir}/pitivi/python/pitivi/*.pyc %ghost %{_libdir}/pitivi/python/pitivi/*.pyo %dir %{_libdir}/pitivi/python/pitivi/ui %{_libdir}/pitivi/python/pitivi/ui/*.py %{_libdir}/pitivi/python/pitivi/ui/*.pyc %ghost %{_libdir}/pitivi/python/pitivi/ui/*.pyo %{_datadir}/pitivi %{_datadir}/applications/pitivi.desktop 9. I could get pitivi to run, but couldn't seem to get it to do much. 10. Eliminate period at end of summary. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 05:34:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 00:34:27 -0500 Subject: [Bug 178922] Review Request: asterisk - The Open Source PBX In-Reply-To: Message-ID: <200602070534.k175YRqs000499@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: asterisk - The Open Source PBX https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178922 ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-07 00:34 EST ------- Updated Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/asterisk-1.2.4-2.spec SRPM Name or Url: http://www.ocjtech.us/asterisk-1.2.4-2.src.rpm * Mon Feb 6 2006 Jeffrey C. Ollie - 1.2.4-2 - BR sqlite2-devel -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From Christian.Iseli at licr.org Tue Feb 7 07:40:03 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Tue, 07 Feb 2006 08:40:03 +0100 Subject: What is the proper way to fix 'make tag' and 'make plague' conflict In-Reply-To: Your message of "Tue, 07 Feb 2006 00:40:20 +0100." Message-ID: <200602070740.k177e41R015435@mx1.redhat.com> paul at cypherpunks.ca said: > Unless I'm doing something wrong now? Yup, you can't do another "make tag" until you've increased the version-release pair. "cvs tag -F" is only a way to force file tagging after you issued a "make tag" but forgot to "cvs commit" some of the files... it will not allow you to re-issue a failed "make tag". But now all your files should have the proper tag (you can check using "cvs stat -v") and a "make build" should work properly. Cheers, Christian From bugzilla at redhat.com Tue Feb 7 08:28:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 03:28:01 -0500 Subject: [Bug 179443] Review Request: perl-Math-GMP In-Reply-To: Message-ID: <200602070828.k178S1IF022199@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Math-GMP https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179443 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From tibbs at math.uh.edu 2006-02-07 03:27 EST ------- rpmlint is completely silent. Package meets naming and packaging guidelines. Specfile is properly named, legible, and uses macros consistently. BuildRequires: is proper. License is acceptable, matches License: tag and is included as %doc. Source file md5sum matches upstream. Package builds and installs on FC4 x86. Approved. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 7 08:58:58 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 03:58:58 -0500 Subject: [Bug 180319] New: Review Request: svnmailer - Tool to post subversion repository commit information Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180319 Summary: Review Request: svnmailer - Tool to post subversion repository commit information Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: mfleming+rpm at enlartenment.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.enlartenment.com/extras/svnmailer.spec SRPM Name or Url: http://www.enlartenment.com/extras/svnmailer-1.0.6-1.src.rpm Description: Svnmailer is a tool to post subversion repository commit information by mail, news or XML (to a CIA tracker). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 11:08:22 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 06:08:22 -0500 Subject: [Bug 180255] Review Request: nazghul - Old school RPG engine In-Reply-To: Message-ID: <200602071108.k17B8Mhk011350@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: nazghul - Old school RPG engine https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180255 ------- Additional Comments From mfleming+rpm at enlartenment.com 2006-02-07 06:08 EST ------- Builds fine in mock (FC4) and plays well for this old Ultima geek (10yrs+ udic.org member :-)). - rpmlint is mostly happy aside the lack of doco in the haxima subpackage - nazgul-haxima should be noarch - rm $RPM_BUILD_ROOT%{_bindir}/haxima.sh - > rm -f $RPM_BUILD_ROOT.... - Rather than use chmod during %install use %attr in %files (my preference) - install -Dp instead of mkdir/install -p for the haxima icon? - %exclude %{_datadir}/nazghul/haxima in base package - why? - list fedora-haxima.desktop & haxima.png in %files rather than using a wildcard as you probably don't want to own all desktop and pixmap files I'll take this bug for a fuller review a little later (once my bz group membership is sorted) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 11:26:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 06:26:34 -0500 Subject: [Bug 179916] Review Request: docbook2X - Convert docbook into man and Texinfo In-Reply-To: Message-ID: <200602071126.k17BQYDa013501@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: docbook2X - Convert docbook into man and Texinfo https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179916 ------- Additional Comments From jamatos at fc.up.pt 2006-02-07 06:26 EST ------- I like the package but it fails to build in mock: Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/docbook2X-0.8.5-1.fc4-root-mockbuild error: Installed (but unpackaged) file(s) found: /usr/share/info/dir RPM build errors: Installed (but unpackaged) file(s) found: /usr/share/info/dir -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 11:37:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 06:37:08 -0500 Subject: [Bug 180319] Review Request: svnmailer - Tool to post subversion repository commit information In-Reply-To: Message-ID: <200602071137.k17Bb8YZ015008@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: svnmailer - Tool to post subversion repository commit information https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180319 roozbeh at farsiweb.info changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bugzilla-sink at leemhuis.info |roozbeh at farsiweb.info OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From roozbeh at farsiweb.info 2006-02-07 06:36 EST ------- Random first comments: * Delete the python_sitearch definition, as it's not used. * Since this is an original submission, please use a template created by fedora-newrpmspec and follow that template's style * Use "BuildArch: noarch" (since this has no arch-dependent file) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 11:52:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 06:52:33 -0500 Subject: [Bug 180319] Review Request: svnmailer - Tool to post subversion repository commit information In-Reply-To: Message-ID: <200602071152.k17BqXJG017085@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: svnmailer - Tool to post subversion repository commit information https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180319 ------- Additional Comments From mfleming+rpm at enlartenment.com 2006-02-07 06:52 EST ------- New source RPM up at http://www.enlartenment.com/extras/svnmailer-1.0.6-2.src.rpm (Old spec replaced with newer shinier model, same place as before) - BuildArch: noarch added - Superflous sitearch definition removed - The inital spec /was/ based off an older FE python template :-P - I've tried to undo whatever damage my local revisions have done (I've packaged it locally before..) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 12:39:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 07:39:09 -0500 Subject: [Bug 180319] Review Request: svnmailer - Tool to post subversion repository commit information In-Reply-To: Message-ID: <200602071239.k17Cd9cg025381@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: svnmailer - Tool to post subversion repository commit information https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180319 ------- Additional Comments From roozbeh at farsiweb.info 2006-02-07 07:39 EST ------- * I would still prefer a more strict following of the spec template. Use the new template and fill it with the older information: it would really make it more readable. * Change the license to "Apache Software License" so rpmlint likes it. * Does it really need subversion as a Buildreq? Suggestions (non-binding!): * You may consider separating the documentation into a subpackage. It's large and it probably won't be useful to most of the users. * You may also consider running the test suite provided upstream automatically. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 12:45:24 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 07:45:24 -0500 Subject: [Bug 179443] Review Request: perl-Math-GMP In-Reply-To: Message-ID: <200602071245.k17CjOpH026457@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Math-GMP https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179443 paul at city-fan.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From paul at city-fan.org 2006-02-07 07:45 EST ------- Thanks for the review. It turns out I needed to patch the testsuite to get it to work on 64-bit arches (see http://rt.cpan.org/Public/Bug/Display.html?id=12751). Build on target fedora-development-extras has now succeeded. I've updated owners.list and requested an FC-4 branch. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From paul at city-fan.org Tue Feb 7 12:55:18 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 07 Feb 2006 12:55:18 +0000 Subject: What is the proper way to fix 'make tag' and 'make plague' conflict In-Reply-To: References: <43E7C1F8.9010207@lowlatency.de> Message-ID: <43E898B6.3090808@city-fan.org> Paul Wouters wrote: > On Mon, 6 Feb 2006, Andreas Bierfert wrote: > > >>Actually it should not happen and there have been talks to add a check for this >>to the makefiles. >> >>You can do a 'cvs tag -F oldtag'. Where oldtag is the tag that was generated >>before. Be carefull with this so... > > > That did not work? > > $ cvs tag -F fetchlog-1_0-2_fc5 > For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs > ? clog > cvs tag: Tagging . > T fetchlog.spec > T sources > $ make tag > cvs tag -c fetchlog-1_0-3_fc5 > For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs > ? clog > ERROR: Tag fetchlog-1_0-3_fc5 has been already created. The "cvs tag -F" is equivalent to "make tag TAG_OPTS=-F"; there's no need to re-run "make tag" again afterwards. Paul. From andreas at bawue.net Tue Feb 7 13:19:41 2006 From: andreas at bawue.net (Andreas Thienemann) Date: Tue, 7 Feb 2006 14:19:41 +0100 (CET) Subject: Problem with GLIBC_PRIVATE Message-ID: Hi, I've tried packaging twinkle, a sip softphone, for FE but there is a problem with the dependencies. twinkle is linking against libresolv, but is using some GLIBC_PRIVATE symbols, as objdump shows: required from libresolv.so.2: 0x0d696912 0x00 16 GLIBC_2.2 0x0d696910 0x00 11 GLIBC_2.0 0x0963cf85 0x00 10 GLIBC_PRIVATE Calling nm on the binary shows that the following to symbols are used: U __ns_get16@@GLIBC_PRIVATE U __ns_name_ntop@@GLIBC_PRIVATE Question is, how to proceed? Is this merely a linker problem, that the wrong libraries are linked or is it a problem in the application which shouldn't use these calls at all? thx, andreas From paul at city-fan.org Tue Feb 7 13:42:07 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 07 Feb 2006 13:42:07 +0000 Subject: Problem with GLIBC_PRIVATE In-Reply-To: References: Message-ID: <43E8A3AF.7010406@city-fan.org> Andreas Thienemann wrote: > I've tried packaging twinkle, a sip softphone, for FE but there is a > problem with the dependencies. > > twinkle is linking against libresolv, but is using some GLIBC_PRIVATE > symbols, as objdump shows: > > required from libresolv.so.2: > 0x0d696912 0x00 16 GLIBC_2.2 > 0x0d696910 0x00 11 GLIBC_2.0 > 0x0963cf85 0x00 10 GLIBC_PRIVATE > > Calling nm on the binary shows that the following to symbols are used: > U __ns_get16@@GLIBC_PRIVATE > U __ns_name_ntop@@GLIBC_PRIVATE > > > Question is, how to proceed? > Is this merely a linker problem, that the wrong libraries are linked or is > it a problem in the application which shouldn't use these calls at all? I saw a similar thing with __ns_get16 in a different package a while back. There was a configure test that looked for this symbol in the C library and picked that one if it was present, otherwise it used one provided by the package itself. A similar thing may be happening in your case. The way I fixed it for __ns_get16 was to tell configure that __ns_get16 was not found in the C library: ac_cv_func___ns_get16=no export ac_cv_func___ns_get16 %configure ... Paul. From bugzilla at redhat.com Tue Feb 7 14:21:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 09:21:18 -0500 Subject: [Bug 180344] New: Review Request: ser - Sip Express Router Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180344 Summary: Review Request: ser - Sip Express Router Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: andreas at bawue.net QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://helena.bawue.de/~ixs/ser/ser.spec SRPM Name or Url: http://helena.bawue.de/~ixs/ser/ser-0.9.6-1.src.rpmser-0.9.6-1.src.rpm Everything else: http://helena.bawue.de/~ixs/ser/ Description: A high-performance, configurable SIP server. It can act as registrar, proxy or redirect server. It features an application-server interface, presence support, SMS gateway, SIMPLE2Jabber gateway, RADIUS/syslog accounting and authorization, server status monitoring, FCP security, etc. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 14:21:29 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 09:21:29 -0500 Subject: [Bug 180345] New: Review Request: ser - Sip Express Router Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 Summary: Review Request: ser - Sip Express Router Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: andreas at bawue.net QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://helena.bawue.de/~ixs/ser/ser.spec SRPM Name or Url: http://helena.bawue.de/~ixs/ser/ser-0.9.6-1.src.rpm Everything else: http://helena.bawue.de/~ixs/ser/ Description: A high-performance, configurable SIP server. It can act as registrar, proxy or redirect server. It features an application-server interface, presence support, SMS gateway, SIMPLE2Jabber gateway, RADIUS/syslog accounting and authorization, server status monitoring, FCP security, etc. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 14:24:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 09:24:02 -0500 Subject: [Bug 180344] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602071424.k17EO2Qu011013@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180344 andreas at bawue.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |DUPLICATE ------- Additional Comments From andreas at bawue.net 2006-02-07 09:23 EST ------- *** This bug has been marked as a duplicate of 180345 *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 14:24:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 09:24:09 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602071424.k17EO94I011055@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From andreas at bawue.net 2006-02-07 09:24 EST ------- *** Bug 180344 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From andreas at bawue.net Tue Feb 7 14:51:04 2006 From: andreas at bawue.net (Andreas Thienemann) Date: Tue, 7 Feb 2006 15:51:04 +0100 (CET) Subject: Problem with GLIBC_PRIVATE In-Reply-To: <43E8A3AF.7010406@city-fan.org> References: <43E8A3AF.7010406@city-fan.org> Message-ID: On Tue, 7 Feb 2006, Paul Howarth wrote: > I saw a similar thing with __ns_get16 in a different package a while > back. There was a configure test that looked for this symbol in the C > library and picked that one if it was present, otherwise it used one > provided by the package itself. A similar thing may be happening in your > case. I do not think so. There was no reference in the sourcecode to anything providing ns_get16. > The way I fixed it for __ns_get16 was to tell configure that __ns_get16 > was not found in the C library: > > ac_cv_func___ns_get16=no > export ac_cv_func___ns_get16 > %configure > ... I tried that already, after seeing a spec file disabling ns_get16 that way, but no luck. bye, andreas From bugzilla at redhat.com Tue Feb 7 15:14:17 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 10:14:17 -0500 Subject: [Bug 180255] Review Request: nazghul - Old school RPG engine In-Reply-To: Message-ID: <200602071514.k17FEHww020762@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: nazghul - Old school RPG engine https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180255 ------- Additional Comments From tibbs at math.uh.edu 2006-02-07 10:14 EST ------- Point-by-point comnments: Note that is is not possible to build both noarch and arch-dependent packages from the same specfile, so nazghul-haxima cannot be noarch. If they packaged it separately then I could just build it as a separate package. I was wanting the rm to fail if haxima.sh isn't installed so the package won't build, but it's immaterial. It's actually an upstream bug that the provided script isn't correct, so I think I'll just patch the upstream bug and let this go away. This steps around the chmod/%attr issue as well. Never used install -D; I'll switch. The main package owns %{_datadir}/nazghul, but the subpackage owns the subdirectory. (This is in perhaps optimistic preparation for more games using the engine; packages should not own the same directory if possible.) I'll use %dir and skip the exclude. True; if there are ever other games in the base package I will have to list them separately so I might as well do it now. Updated spec and src.rpm are in http://www.math.uh.edu/~tibbs/rpms/nazghul/ -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 15:15:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 10:15:35 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602071515.k17FFZ94021007@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 jeff at ollie.clive.ia.us changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bugzilla-sink at leemhuis.info |jeff at ollie.clive.ia.us ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-07 10:15 EST ------- First look... builds in mock on development, results of rpmlint: [jcollie at lt16585 result]$ rpmlint ser-*0.9.6-1.i386.rpm W: ser doc-file-dependency /usr/share/doc/ser-0.9.6/Jabber/regjab.pl perl(DBD::mysql) W: ser doc-file-dependency /usr/share/doc/ser-0.9.6/Jabber/regjab.pl /usr/bin/perl W: ser doc-file-dependency /usr/share/doc/ser-0.9.6/Jabber/regjab.pl perl(Socket) Perhaps renaming this to .txt will prevent rpm from picking up the dependencies? W: ser service-default-enabled /etc/rc.d/init.d/ser Please patch so that SER doesn't get enabled by default. W: ser-mysql spelling-error-in-description persistant persistent W: ser-postgresql spelling-error-in-description persistant persistent Minor, but might as well fix since we're at it. W: ser-postgresql doc-file-dependency /usr/share/doc/ser-postgresql-0.9.6/copy_to_psql /usr/bin/perl Perhaps renaming to .txt again will prevent RPM from picking up the dependency. W: ser-serweb summary-ended-with-dot Web interface for ser user self-provisioning and administration. Please fix. E: ser-serweb version-control-internal-file /usr/share/serweb/templates/cache/.cvsignore E: ser-serweb zero-length /usr/share/serweb/templates/cache/.cvsignore Delete. W: ser-serweb non-conffile-in-etc /etc/httpd/conf.d/serweb.conf Mark as %config(noreplace) E: ser-serweb version-control-internal-file /usr/share/serweb/templates/configs/.cvsignore E: ser-serweb zero-length /usr/share/serweb/templates/configs/.cvsignore Delete. E: ser-serweb version-control-internal-file /usr/share/serweb/templates/templates_c/.cvsignore Delete. E: ser-serweb version-control-internal-file /usr/share/serweb/html/.cvsignore E: ser-serweb zero-length /usr/share/serweb/html/.cvsignore Delete. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 15:29:29 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 10:29:29 -0500 Subject: [Bug 177106] Review Request: libgdgeda - graphical library for gEDA In-Reply-To: Message-ID: <200602071529.k17FTT4x023802@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libgdgeda - graphical library for gEDA https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177106 ------- Additional Comments From wk at ire.pw.edu.pl 2006-02-07 10:29 EST ------- This test about JPEG and Freetype support is something left from original libgd library or something unfinished yet. Some part of configure.ac is commented out, so support for JPEG and Freetype will be disabled even if proper -devel files are present. Adding the option --with-jpeg to configure does not help too. More, JPEG is not optimal for line graphs produced by gschem and currently the only bitmap format supported by gschem is png. The two comment lines are very old, maybe building rpms as user was not usual for someone before me. I'll check md5sums of the sources, my version of libgeda source is from 2003 and is one byte shorter. It could be repackaged without bumping the version. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 7 16:19:51 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 11:19:51 -0500 Subject: [Bug 170303] Review Request: google-perftools: Very fast malloc & performance analysis tools In-Reply-To: Message-ID: <200602071619.k17GJpWV000578@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: google-perftools: Very fast malloc & performance analysis tools https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170303 ------- Additional Comments From tcallawa at redhat.com 2006-02-07 11:19 EST ------- Upstream bug filed: http://sourceforge.net/tracker/index.php?func=detail&aid=1426205&group_id=133355&atid=726859 (it got filed twice because sourceforge is a laggy piece of crap, but I closed the dupe) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From Christian.Iseli at licr.org Tue Feb 7 17:18:07 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Tue, 07 Feb 2006 18:18:07 +0100 Subject: FE package status Tue Feb 7 2006 Message-ID: <200602071718.k17HI7fL011115@ludwig-alpha.unil.ch> Hi folks, Here is the weekly report of FE package status. I tried to take into account all the comments I received. Please don't hesitate to send further ones... :-) There are 5 parts in the listing, starting with the wiki-style ===: - About owners file - About FE-ACCEPT packages - About FE-REVIEW packages - About FE-NEW packages - About FE-NEEDSPONSOR packages I added a few entries in the discarded list. Script and all will be updated on the Extras/UsefulScripts page shortly. Cheers, Christian --- === About owners file === We have 1419 extras packages in owners file. There are 60 orphans. Top 10 package owners: tcallawa at redhat dot com : 88 ville dot skytta at iki dot fi : 82 jpo at di dot uminho dot pt : 80 matthias at rpmforge dot net : 70 andreas dot bierfert at lowlatency dot de : 56 rc040203 at freenet dot de : 50 ivazquez at ivazquez dot net : 44 rdieter at math dot unl dot edu : 41 gauret at free dot fr : 40 steve at silug dot org : 37 We have 58 packages not available in extras devel or release: GiNaC qspencer R-hdf5 tcallawa alsa-firmware fedora apmud dwmw2 cacti imlinux cdiff ville.skytta commoncpp2 andreas compat-wxPythonGTK2 tcallawa comps notting configure-thinkpad jcarpenter cpanspec steve cryptplug dennis dd_rescue andreas drscheme gemi fillets-ng-data-cs matthias freenx zipsonic gcdmaster denis gnome-applet-netmon ghenry gnome-cpufreq-applet adrian gnome-theme-clearlooks ivazquez gpredict ivazquez initng daner964 inti gemi juk nomis80 k3b-ape mihai libgcrypt1 bugs.michael libgsf113 j.w.r.degoede libmatchbox toniw libsafe sgrubb lirc-kmod ville.skytta lirc-kmod-common ville.skytta nabi djoo newpg ville.skytta nx zipsonic openbox kaboom opendap tcallawa openoffice-extras wtogami pam_pkcs11 tcallawa perl-GD-SVG thm perl-Graph thm perl-Heap thm perl-Math-GMP paul perl-SOAP-Lite thm perl-SVG thm perl-Text-Shellwords thm perl-XML-Writer thm perl-bioperl thm php-pear-DB rpm php-pecl-sqlite matthias qemu dwmw2 rsnapshot ghenry sblim-cmpi-base hamzy squidGuard oliver stripesnoop tcallawa swish-e bkyoung thinkpad-kmod jcarpenter thinkpad-kmod-common jcarpenter tpctl jcarpenter We have 16 packages not available in extras devel but present in release: R-RScaLAPACK tcallawa aqhbci-qt-tools notting cdo ed ebtables tcallawa gcl gemi iiimf-le-simplehangul wtogami kiosktool rdieter kxdocker rdieter kxdocker-resources rdieter lout tcallawa osiv ed scrub tcallawa superkaramba rdieter wmweather+ andreas.bierfert wp_tray ivazquez yakuake dreadyman We have 53 orphaned packages available in extras devel: abe anjuta apg apt arc at-poke camstream cgoban cksfv conglomerate duplicity freedroidrpg gdeskcal gkrellm-themes gnofract4d gnome-password-generator gnome-telnet gnome-themes-extras gnugo gonvert gpa gtkglarea2 gurlchecker hping2 libzvt lincvs lua manedit mknbi netdiag nget ots p0f parchive perl-Net-SCP perl-Net-SSH perl-Parse-Yapp prozilla putty rpmproc screem sirius synaptic tdl tetex-arabtex tetex-armtex tetex-font-tipa tetex-lgrind tla wbxml2 wesnoth xmms-cdread xtide We have 28 packages that moved to core: anthy firefox gmime kasumi libchewing libevent m17n-db m17n-lib nautilus-sendto perl-Archive-Zip perl-IO-String perl-IO-Zlib perl-Net-IP perl-String-CRC32 perl-XML-Simple python-elementtree python-sqlite scim scim-anthy scim-chewing scim-hangul scim-m17n scim-pinyin scim-qtimm scim-tables sqlite thunderbird tog-pegasus === About FE-ACCEPT packages === We have 9 accepted, closed packages where I'm unable to find the package in the development repo: https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165488,168185,171601,172136,172144,172150,172151,173216,174266 wmweather+ andreas.bierfert z88dk paul yakuake dreadyman kiosktool rdieter superkaramba rdieter kxdocker rdieter kxdocker-resources rdieter OSIV ed libgsf113 j.w.r.degoede We have 7 accepted, closed packages where I'm unable to find the package in the owners file: https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165992,167863,168185,168920,171801,179263,179910 Glide3-libGL j.w.r.degoede gpp Matt_Domsch z88dk paul html-xml-utils ghenry libspectrum paul perl-Text-Unidecode pertusus commoncpp andreas We have 488 accepted, closed package reviews Top 10 BZ review requests submitters: tcallawa at redhat dot com : 43 rc040203 at freenet dot de : 41 andreas dot bierfert at lowlatency dot de : 31 fedora dot wickert at arcor dot de : 28 jpo at di dot uminho dot pt : 24 steve at silug dot org : 18 rdieter at math dot unl dot edu : 18 pertusus at free dot fr : 15 orion at cora dot nwra dot com : 14 paul at city-fan dot org : 13 Top 10 BZ review requests reviewers: paul at city-fan dot org : 68 gauret at free dot fr : 64 gdk at redhat dot com : 34 jpmahowald at gmail dot com : 30 tcallawa at redhat dot com : 27 rc040203 at freenet dot de : 22 ed at eh3 dot com : 20 jpo at di dot uminho dot pt : 20 adrian at lisas dot de : 19 ville dot skytta at iki dot fi : 14 We have 11 accepted, open package reviews where the package appears to already be in the repo... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=166207,166251,166252,166253,166254,168905,176523,176618,177038,177166,178668 rekall tcallawa perl-Apache-LogRegex ghenry perl-Gnome2-Canvas ghenry perl-Gtk2-GladeXML ghenry perl-Imager ghenry python-nltk michel.salim python-json ivazquez ushare eric.tanguy perl-version tcallawa perl-Compress-Bzip2 jpo numpy ivazquez We have 14 accepted, open package reviews older than 4 weeks https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165688,165899,165932,166207,166251,166252,166253,166254,166255,168905,170309,172871,174898,177166 YAML-Parser-Syck oliver pam_pkcs11 tcallawa msmtp taylor rekall tcallawa perl-Apache-LogRegex ghenry perl-Gnome2-Canvas ghenry perl-Gtk2-GladeXML ghenry perl-Imager ghenry Sprog ghenry python-nltk michel.salim opencv nomis80 driftnet bnocera perl-HTML-FillInForm bkyoung perl-Compress-Bzip2 jpo === About FE-REVIEW packages === We have 54 open tickets in FE-REVIEW We have 2 closed tickets still blocking FE-REVIEW https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=172267,177567 srtp jeff smb4k mgarski We have 9 FE-REVIEW tickets with no activity in eight weeks https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165689,166205,166470,166919,167525,167974,169210,174063,174783 SquidGuard oliver alleyoop tcallawa taskjuggler petersen findlib descender cpptasks green hugs98 gemi xnee jpmahowald cssed fedora gruler mclasen We have 11 FE-REVIEW tickets with no activity in four weeks https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165230,165878,165985,166547,169704,169731,173028,173388,174495,175168,175278 Eclipse aluchko kadu gogers Aeryn paul multisync andreas.bierfert mosml gemi ecl gemi ser lemenkov Denial icon libopensync-plugin-kdepim andreas.bierfert gideon denisleroy gift-gnutella rdieter === About FE-NEW packages === We have 131 open tickets in FE-NEW We have 7 closed tickets still blocking FE-NEW https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=167621,168906,176434,177859,178141,178902,180344 PyCairo jacob.kroon python-nltk-data michel.salim spicctrl roozbeh libXvMCW dominik Jakarta green ikvm paul ser andreas We have 12 FE-NEW tickets with no activity in eight weeks https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=166427,169703,169717,172872,173790,174021,174368,174440,174952,175281,175473,175623 inform chris pari gemi Internode jpmahowald sloccount bnocera gstreamer-plugins-fcextras mpeters aplus-fsf Jochen perl-Crypt-DSA paul bakery denisleroy lightning Jochen perl-Tie-EncryptedHash paul smart-channel enrico.scholz yaz icon We have 18 FE-NEW tickets with no activity in four weeks https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165666,171314,174268,174325,174866,175495,176021,176137,176579,176581,176582,176697,176712,176855,177247,177249,177270,177277 Graph oliver compat-gtkhtml36 mpeters itcl-iwidgets wart mod_spin bojan polypaudio tcallawa cgi-util redhat bwidget wart perl-Log-Log4perl jpo ipsvd enrico.scholz fnord enrico.scholz freedt enrico.scholz i386-rtems4.7-binutils rc040203 i386-rtems4.7-gcc-newlib rc040203 python-cpio ivazquez jthread jeff jrtplib jeff libresample jeff perl-SQL-Abstract-Limit tcallawa === About FE-NEEDSPONSOR packages === We have 35 open tickets in FE-NEEDSPONSOR From bdpepple at ameritech.net Tue Feb 7 17:33:10 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Tue, 07 Feb 2006 12:33:10 -0500 Subject: FE package status Tue Feb 7 2006 In-Reply-To: <200602071718.k17HI7fL011115@ludwig-alpha.unil.ch> References: <200602071718.k17HI7fL011115@ludwig-alpha.unil.ch> Message-ID: <1139333590.3053.2.camel@shuttle.273piedmont.org> On Tue, 2006-02-07 at 18:18 +0100, Christian.Iseli at licr.org wrote: > We have 58 packages not available in extras devel or release: > swish-e bkyoung Well seeing as swish-e hasn't been approved yet for FE, I question why this would be available for an earlier release. /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 fedora at leemhuis.info Tue Feb 7 17:35:36 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 07 Feb 2006 18:35:36 +0100 Subject: Shortlog from todays fesco meeting In-Reply-To: <200602062000.27959.jamatos@fc.up.pt> References: <1138308919.2638.35.camel@localhost.localdomain> <200602062000.27959.jamatos@fc.up.pt> Message-ID: <1139333736.2967.26.camel@localhost.localdomain> Am Montag, den 06.02.2006, 20:00 +0000 schrieb Jose' Matos: > On Thursday 26 January 2006 20:55, Thorsten Leemhuis wrote: > > * Encourage more Extras reviews > > > > Create special interest groups? > > > > Input needed! > > I saw this page: http://www.fedoraproject.org/wiki/Extras/SIGs but I did not > saw any discussion about it here. Am I missing any email messages? :-) Well, currently it's in the state "FESCo and some other people liked the idea and agreed in the meeting to start the SIG's, but nobody was selected for the task and until now nobody stepped up to work out the details." In fact Ignacio started the work in the wiki, but I don't know if he or anybody else is working on the details. BTW, the Summary from the meeting and the explicit "Input needed!" are meant to start a discussion between people that are interested. > I would like to see also defined the precise roles of SIG's. [...] Well, this is your (and everybody else) chance to influence how SIG's should work and to get further involved in Fedora Extras ;-) Post to this list how you think that it should work. A fl^H^H^H discussion will probably evolve and some things may need to be adjusted to make most people happy. In case you want to discuss some parts with FESCo or want a "official" blessing add the proposal and a list of things where you think a official word/discussion from FESCo is needed to http://www.fedoraproject.org/wiki/Extras/Schedule/SIGs Send the text to this list afterwards and CC me. I'll take care of it in the next FESCo-Meeting then. But I don't think we need involvement from FESCo for everything and each and every detail-- a discussion on the list and going ahead in a way that makes most people that participated in the discussions happy should be enough normally. BTW, somebody suggested in #fedora-extras that we should start a QA-SIG. Guys, what do you think about this idea? -- Thorsten Leemhuis From rdieter at math.unl.edu Tue Feb 7 17:49:26 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 07 Feb 2006 11:49:26 -0600 Subject: FE package status Tue Feb 7 2006 In-Reply-To: <200602071718.k17HI7fL011115@ludwig-alpha.unil.ch> References: <200602071718.k17HI7fL011115@ludwig-alpha.unil.ch> Message-ID: Christian.Iseli at licr.org wrote: > superkaramba rdieter FYI, superkaramba has a Pending removal request: http://fedoraproject.org/wiki/Extras/CVSSyncNeeded (since it's now included in kdeutils-3.5.x). -- Rex From fedora at leemhuis.info Tue Feb 7 18:01:02 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 07 Feb 2006 19:01:02 +0100 Subject: FE package status Tue Feb 7 2006 In-Reply-To: <200602071718.k17HI7fL011115@ludwig-alpha.unil.ch> References: <200602071718.k17HI7fL011115@ludwig-alpha.unil.ch> Message-ID: <1139335262.2967.51.camel@localhost.localdomain> Christian, many thanks for these reports. I like then a lot. Some suggestions for improvements: Am Dienstag, den 07.02.2006, 18:18 +0100 schrieb Christian.Iseli at licr.org: > We have 58 packages not available in extras devel or release: > > GiNaC qspencer > R-hdf5 tcallawa > alsa-firmware fedora [...] Could you sort this and maybe some of the other lists by the owner and not by package name? This way each and every packager has to go through the whole list a look out for his packages. When it is sorted by owner you just have to search for your own email address -- that's a lot easier. You probably should add the domains somehow -- there are at least two people (I'm one of them) that use fedora at my.domain.foo. I would suggest fedora[AT]leemhuis[DOT]info, fedora at leemhuis, fedora-leemhuis_info or something like that. And another thing: How to I get a package out of the list in case it is stuck due to legal problems or other well known things? [...] > We have 28 packages that moved to core: > anthy firefox gmime kasumi libchewing libevent m17n-db m17n-lib > nautilus-sendto perl-Archive-Zip perl-IO-String perl-IO-Zlib perl-Net-IP > perl-String-CRC32 perl-XML-Simple python-elementtree python-sqlite scim > scim-anthy scim-chewing scim-hangul scim-m17n scim-pinyin scim-qtimm > scim-tables sqlite thunderbird tog-pegasus Well, at least firefox and thunderbird (probably many more) were moved to core long time ago -- do we really need them in this list? Then it will grow endlessly over time. > We have 12 FE-NEW tickets with no activity in eight weeks This one is a great idea! Maybe is should be placed somewhere more prominent... -- Thorsten Leemhuis From tibbs at math.uh.edu Tue Feb 7 18:08:55 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 07 Feb 2006 12:08:55 -0600 Subject: SIGs (Was: Shortlog from todays fesco meeting) In-Reply-To: <1139333736.2967.26.camel@localhost.localdomain> (Thorsten Leemhuis's message of "Tue, 07 Feb 2006 18:35:36 +0100") References: <1138308919.2638.35.camel@localhost.localdomain> <200602062000.27959.jamatos@fc.up.pt> <1139333736.2967.26.camel@localhost.localdomain> Message-ID: >>>>> "TL" == Thorsten Leemhuis writes: TL> Well, this is your (and everybody else) chance to influence how TL> SIG's should work and to get further involved in Fedora Extras ;-) I've noted my interest on a couple of the SIG pages. I see SIGs as being simply being groups of interested people who propose the addition of various packages and work to make sure they're submitted and reviewed. I don't think it would be necessary to enforce any kind of structure, although if a SIG goes dead there should probably be a procedure for deleting it. Also, I think we could use a Games SIG, so went ahead and added it to the wiki. - J< From nassar at etymon.com Tue Feb 7 18:09:13 2006 From: nassar at etymon.com (Nassib Nassar) Date: Tue, 7 Feb 2006 13:09:13 -0500 Subject: Package with dependency on xerces-c Message-ID: <20060207180913.GA20746@etymon.com> This is my first try contributing to a fedora repository, and I'd like to submit a package for amberfish (http://etymon.com/tr.html), which is text indexing/searching software. One of its features is XPath-like query constraints on text searching within XML, but this depends on the xerces-c library which I can't find in the fedora base repositories. It looks like I have three options: (1) contribute a xerces-c package to extras, unless there is a reason it should not be included, (2) build amberfish without XML support, or (3) modify amberfish to use a different XML library, which may be difficult or not possible. Can anyone offer suggestions or guidance? Nassib From bugzilla at redhat.com Tue Feb 7 18:14:45 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 13:14:45 -0500 Subject: [Bug 171640] Review Request: perl-Log-Dispatch-FileRotate - Log to files that archive/rotate themselves In-Reply-To: Message-ID: <200602071814.k17IEj4c024260@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Log-Dispatch-FileRotate - Log to files that archive/rotate themselves https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171640 ------- Additional Comments From tibbs at math.uh.edu 2006-02-07 13:14 EST ------- Perhaps a contributor in Australia could be persuaded to give them a call? Their phone number can be found via their CPAN page. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From nicolas.mailhot at laposte.net Tue Feb 7 18:19:25 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 07 Feb 2006 19:19:25 +0100 Subject: FE package status Tue Feb 7 2006 In-Reply-To: <1139335262.2967.51.camel@localhost.localdomain> References: <200602071718.k17HI7fL011115@ludwig-alpha.unil.ch> <1139335262.2967.51.camel@localhost.localdomain> Message-ID: <1139336365.6700.1.camel@rousalka.dyndns.org> Le mardi 07 f?vrier 2006 ? 19:01 +0100, Thorsten Leemhuis a ?crit : > Christian, many thanks for these reports. I like then a lot. They're great, but there's so much information in there they're begging to be put on a web site somewhere with weekly archives, bugzilla links and "what changed since last week" metrics Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From fedora at leemhuis.info Tue Feb 7 18:32:33 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 07 Feb 2006 19:32:33 +0100 Subject: SIGs (Was: Shortlog from todays fesco meeting) In-Reply-To: References: <1138308919.2638.35.camel@localhost.localdomain> <200602062000.27959.jamatos@fc.up.pt> <1139333736.2967.26.camel@localhost.localdomain> Message-ID: <1139337154.2967.74.camel@localhost.localdomain> Am Dienstag, den 07.02.2006, 12:08 -0600 schrieb Jason L Tibbitts III: > >>>>> "TL" == Thorsten Leemhuis writes: > > I don't think it would be necessary to enforce any kind > of structure, although if a SIG goes dead there should probably be a > procedure for deleting it. Well, I agree mostly. But some questions maybe should be discussed once (and the answers should be written down somewhere in the wiki): - How to get in contact with a SIG - What do SIGs do? And what not? - Do we need mailinglists? IRC-Channels? - Should SIG's have a leader ? - How can FESCo contact a SIG(-leader)? - Who coordinates the SIG creation? I think we shouldn't have more then 10 or 15 groups. And we probably all don't want a "GNOME Games written in python SIG" - That's a good example: If I have a gnome game written in python: Which SIG do I contact in case of problems: The Gnome, Python or Games SIG? (Okay, common sense should normally be enough to answer this question, but I bet that we'll see such a question on this list sooner or later) -- Thorsten Leemhuis From fedora at leemhuis.info Tue Feb 7 18:41:12 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 07 Feb 2006 19:41:12 +0100 Subject: FE package status Tue Feb 7 2006 In-Reply-To: <1139336365.6700.1.camel@rousalka.dyndns.org> References: <200602071718.k17HI7fL011115@ludwig-alpha.unil.ch> <1139335262.2967.51.camel@localhost.localdomain> <1139336365.6700.1.camel@rousalka.dyndns.org> Message-ID: <1139337672.2967.77.camel@localhost.localdomain> Am Dienstag, den 07.02.2006, 19:19 +0100 schrieb Nicolas Mailhot: > Le mardi 07 f?vrier 2006 ? 19:01 +0100, Thorsten Leemhuis a ?crit : > > Christian, many thanks for these reports. I like then a lot. > > They're great, but there's so much information in there they're begging > to be put on a web site somewhere Wiki? > with weekly archives, Wiki history? > bugzilla links Christian? > and "what changed since last week" metrics The wiki can send out a diff if a page changes. Anyway, the important parts still should be send to the list. -- Thorsten Leemhuis From bugzilla at redhat.com Tue Feb 7 18:41:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 13:41:59 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602071841.k17IfxwN029417@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From andreas at bawue.net 2006-02-07 13:41 EST ------- .spec is updated. I opted to remove the execute permissions on the perl scripts in the %docdir. That is the preferred solution, even though rpmlint complains now with an Error and not a Warning. *shrug* -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From nicolas.mailhot at laposte.net Tue Feb 7 19:08:33 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 07 Feb 2006 20:08:33 +0100 Subject: FE package status Tue Feb 7 2006 In-Reply-To: <1139337672.2967.77.camel@localhost.localdomain> References: <200602071718.k17HI7fL011115@ludwig-alpha.unil.ch> <1139335262.2967.51.camel@localhost.localdomain> <1139336365.6700.1.camel@rousalka.dyndns.org> <1139337672.2967.77.camel@localhost.localdomain> Message-ID: <1139339314.6700.5.camel@rousalka.dyndns.org> Le mardi 07 f?vrier 2006 ? 19:41 +0100, Thorsten Leemhuis a ?crit : > Am Dienstag, den 07.02.2006, 19:19 +0100 schrieb Nicolas Mailhot: > > Le mardi 07 f?vrier 2006 ? 19:01 +0100, Thorsten Leemhuis a ?crit : > > > Christian, many thanks for these reports. I like then a lot. > > > > They're great, but there's so much information in there they're begging > > to be put on a web site somewhere > > Wiki Actually I was thinking more of some automated form of http://www.abisource.com/information/news/ This kind of timeline is great to attract new contributors. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From bugzilla at redhat.com Tue Feb 7 19:04:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 14:04:52 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602071904.k17J4qME001194@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-07 14:04 EST ------- Please bump the revision number, even when the package is in the review process. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 19:10:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 14:10:28 -0500 Subject: [Bug 180205] Review Request: gnome-menu-editor In-Reply-To: Message-ID: <200602071910.k17JAS60002679@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-menu-editor https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180205 ------- Additional Comments From splinux25 at gmail.com 2006-02-07 14:10 EST ------- I have rewrited the spec file and build the package. Spec Name or Url: http://glive.tuxfamily.org/fedora/gnome-menu-editor/gnome-menu-editor.spec SRPM Name or Url: http://glive.tuxfamily.org/fedora/gnome-menu-editor/gnome-menu-editor-0.5-1.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 19:26:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 14:26:11 -0500 Subject: [Bug 180205] Review Request: gnome-menu-editor In-Reply-To: Message-ID: <200602071926.k17JQBTA006727@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-menu-editor https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180205 ------- Additional Comments From bdpepple at ameritech.net 2006-02-07 14:26 EST ------- I think you need to review the documentation some more, because there's quite a few items that still need to be addressed. 1. The package doesn't build. http://fedoraproject.org/wiki/Projects/Mock 2. You need to handle the translations. 3. Ownership issues with %{_datadir} files. 4. Requires on gtk isn't needed. 5. Desktop file isn't handled. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From Christian.Iseli at licr.org Tue Feb 7 19:44:03 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Tue, 07 Feb 2006 20:44:03 +0100 Subject: FE package status Tue Feb 7 2006 In-Reply-To: Your message of "Tue, 07 Feb 2006 12:33:10 EST." <1139333590.3053.2.camel@shuttle.273piedmont.org> Message-ID: <200602071944.k17JiB9d014143@mx1.redhat.com> bdpepple at ameritech.net said: > Well seeing as swish-e hasn't been approved yet for FE, I question why this > would be available for an earlier release. It seems some people put their package in owners.list before they get approved... :-| So far, I noticed swish-e and initng Dunno if they should be summarily removed... :-) Christian From bdpepple at ameritech.net Tue Feb 7 19:48:15 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Tue, 07 Feb 2006 14:48:15 -0500 Subject: FE package status Tue Feb 7 2006 In-Reply-To: <200602071944.k17JiB9d014143@mx1.redhat.com> References: <200602071944.k17JiB9d014143@mx1.redhat.com> Message-ID: <1139341695.16896.4.camel@shuttle.273piedmont.org> On Tue, 2006-02-07 at 20:44 +0100, Christian.Iseli at licr.org wrote: > bdpepple at ameritech.net said: > > Well seeing as swish-e hasn't been approved yet for FE, I question why this > > would be available for an earlier release. > > It seems some people put their package in owners.list before they get > approved... :-| > > So far, I noticed swish-e and initng > > Dunno if they should be summarily removed... :-) Yeah, they probably should be since it's fairly misleading about there status in FE. /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 Christian.Iseli at licr.org Tue Feb 7 19:50:40 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Tue, 07 Feb 2006 20:50:40 +0100 Subject: FE package status Tue Feb 7 2006 In-Reply-To: Your message of "Tue, 07 Feb 2006 19:01:02 +0100." <1139335262.2967.51.camel@localhost.localdomain> Message-ID: <200602071950.k17JogKY015815@mx1.redhat.com> fedora at leemhuis.info said: > Could you sort this and maybe some of the other lists by the owner and not by > package name? This way each and every packager has to go through the whole > list a look out for his packages. When it is sorted by owner you just have to > search for your own email address -- that's a lot easier. Ok, will do. > You probably should add the domains somehow -- there are at least two people > (I'm one of them) that use fedora at my.domain.foo. I would suggest > fedora[AT]leemhuis[DOT]info, fedora at leemhuis, fedora-leemhuis_info or > something like that. Ok. > And another thing: How to I get a package out of the list in case it is stuck > due to legal problems or other well known things? I think probably the easiest is I create a wiki page with package names that I should not check. The hardest part is choosing a page name, I guess... > Well, at least firefox and thunderbird (probably many more) were moved to > core long time ago -- do we really need them in this list? Then it will grow > endlessly over time. Yea, I agree the "moved to core" part is not so useful. I'll remove it. > This one is a great idea! Maybe is should be placed somewhere more > prominent... Thanks. It's not bullet proof, though. Some packages actually do get comment but their change date is not updated. But it's rather uncommon... Christian From Christian.Iseli at licr.org Tue Feb 7 20:00:22 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Tue, 07 Feb 2006 21:00:22 +0100 Subject: FE package status Tue Feb 7 2006 In-Reply-To: Your message of "Tue, 07 Feb 2006 19:19:25 +0100." <1139336365.6700.1.camel@rousalka.dyndns.org> Message-ID: <200602072000.k17K0WHI019404@mx1.redhat.com> nicolas.mailhot at laposte.net said: > They're great, but there's so much information in there they're begging to be > put on a web site somewhere with weekly archives, bugzilla links and "what > changed since last week" metrics fedora at leemhuis.info said: > Wiki? nicolas.mailhot at laposte.net said: > Actually I was thinking more of some automated form of http:// > www.abisource.com/information/news/ > This kind of timeline is great to attract new contributors. Well, the thing is: it seems a lot easier to add a wiki page than a web page (but I might be mistaken...). The wiki can be made to look pretty much like the abisource page though, see FESCO minutes. I'll give a shot to create a wiki page. Can links be made within a wiki page (e.g., a table of content entry with a link that jumps to the proper spot down the page) ? I'll let you know when I get something out... > > with weekly archives, > Wiki history? or a la FESCO minutes ? > > bugzilla links > Christian? Sure, can do in the wiki page. > > and "what changed since last week" metrics > The wiki can send out a diff if a page changes. That's right. But the diff might be rather ugly ? > Anyway, the important parts still should be send to the list. +1 But we'll probably need to fine tune what "important parts" really mean... :-) Cheers, Christian From bugzilla at redhat.com Tue Feb 7 20:05:00 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 15:05:00 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602072005.k17K50XU014501@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 lemenkov at newmail.ru changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lemenkov at newmail.ru ------- Additional Comments From lemenkov at newmail.ru 2006-02-07 15:04 EST ------- Look also at the https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173028 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 20:14:06 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 15:14:06 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602072014.k17KE6Kd016053@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From andreas at bawue.net 2006-02-07 15:13 EST ------- (In reply to comment #5) > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173028 I noticed that. But as nothing happened there in the last 2 months, I thought that package was probably dead. Are you planning on maintaining the ser package in the future? Should we get together and do it? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 20:16:55 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 15:16:55 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602072016.k17KGtEC016550@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 jeff at ollie.clive.ia.us changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |DUPLICATE ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-07 15:16 EST ------- I'm going to close this review request and mark it as a duplicate of #173028. Andreas, perhaps you and Peter can work together to get SER into FE. *** This bug has been marked as a duplicate of 173028 *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 20:17:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 15:17:13 -0500 Subject: [Bug 173028] Review Request: ser - SIP Express Router In-Reply-To: Message-ID: <200602072017.k17KHDo1016617@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - SIP Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173028 jeff at ollie.clive.ia.us changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andreas at bawue.net ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-07 15:17 EST ------- *** Bug 180345 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 7 20:20:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 15:20:11 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602072020.k17KKBbV017005@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From andreas at bawue.net 2006-02-07 15:20 EST ------- (In reply to comment #4) > Please bump the revision number, even when the package is in the review process. Uhm. As far as I know, this is not a requirement. And personally, I do not believe in needlessly bumping a release number. When the package is introduced into the repository, every change should be reflected by the release number, but as long as it's in the review process, this is IMHO unnecessary. But if you insist, I can bump up the releasenumber. Everything to please the reviewer. ;-D -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 20:21:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 15:21:08 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602072021.k17KL8DF017674@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From andreas at bawue.net 2006-02-07 15:21 EST ------- (In reply to comment #7) > I'm going to close this review request and mark it as a duplicate of #173028. > Andreas, perhaps you and Peter can work together to get SER into FE. > > *** This bug has been marked as a duplicate of 173028 *** The spec in 173028 is the template spec delivered with the ser-tarball. Basically it's crap. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 20:29:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 15:29:28 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602072029.k17KTSag019466@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-07 15:29 EST ------- (In reply to comment #9) > (In reply to comment #7) > > I'm going to close this review request and mark it as a duplicate of #173028. > > Andreas, perhaps you and Peter can work together to get SER into FE. > > > > *** This bug has been marked as a duplicate of 173028 *** > > The spec in 173028 is the template spec delivered with the ser-tarball. > Basically it's crap. The quality of the spec file that Peter submitted isn't the issue - Peter had his review request first and should have been contacted first to see what the status of his package was. Since Peter still seems to be around let's let him decide if he wants to defer packaging SER to Andreas. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From nicolas.mailhot at laposte.net Tue Feb 7 20:59:43 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 07 Feb 2006 21:59:43 +0100 Subject: FE package status Tue Feb 7 2006 In-Reply-To: <200602071950.k17JogKY015815@mx1.redhat.com> References: <200602071950.k17JogKY015815@mx1.redhat.com> Message-ID: <1139345984.6700.12.camel@rousalka.dyndns.org> Le mardi 07 f?vrier 2006 ? 20:50 +0100, Christian.Iseli at licr.org a ?crit : > fedora at leemhuis.info said: > > Well, at least firefox and thunderbird (probably many more) were moved to > > core long time ago -- do we really need them in this list? Then it will grow > > endlessly over time. > > Yea, I agree the "moved to core" part is not so useful. I'll remove it. Please don't You're right on the operational front it's useless However from a marketing POW it's invaluable: it shows people stuff does move from FE to FC, so even if they don't care about FE FE is the primary path to core inclusion If you don't point to these packages people will be endlessly trying to get directly to core/rhel, short-circuiting the FE process and wasting everyone's time. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From bugzilla at redhat.com Tue Feb 7 21:00:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 16:00:13 -0500 Subject: [Bug 179916] Review Request: docbook2X - Convert docbook into man and Texinfo In-Reply-To: Message-ID: <200602072100.k17L0DGY031771@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: docbook2X - Convert docbook into man and Texinfo https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179916 ------- Additional Comments From pertusus at free.fr 2006-02-07 16:00 EST ------- An updated version that builds in mock, and with minor fixes is there: http://www.environnement.ens.fr/perso/dumas/fc-srpms/docbook2X-0.8.5-2.src.rpm rpmlint isn't happy with libxslt as Require, but docbook2X requires xsltproc which is in libxslt. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From jspaleta at gmail.com Tue Feb 7 21:11:53 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 7 Feb 2006 16:11:53 -0500 Subject: FE package status Tue Feb 7 2006 In-Reply-To: <200602072000.k17K0WHI019404@mx1.redhat.com> References: <1139336365.6700.1.camel@rousalka.dyndns.org> <200602072000.k17K0WHI019404@mx1.redhat.com> Message-ID: <604aa7910602071311t35ccfca3pfb5ba6302719fe5a@mail.gmail.com> On 2/7/06, Christian.Iseli at licr.org wrote: > Sure, can do in the wiki page. You are going to automate the creation of the content for the wiki page? -jef From bugzilla at redhat.com Tue Feb 7 21:41:29 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 16:41:29 -0500 Subject: [Bug 175281] Review Request: perl-Tie-EncryptedHash In-Reply-To: Message-ID: <200602072141.k17LfTn8010921@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Tie-EncryptedHash https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175281 ------- Additional Comments From tibbs at math.uh.edu 2006-02-07 16:41 EST ------- perl-Crypt-DES isn't built on the FC-4 branch yet so I build it from CVS. There's not really much to this package. The shebang line at the top of the module is odd; thanks for removing it. Good stuff: pmlint is completely silent. Package meets naming and packaging guidelines. Specfile is properly named, legible, and uses macros consistently. BuildRequires: is proper. License is acceptable and matches License: tag. Source file md5sum matches upstream. Package builds and installs on FC4 x86 and FC3 x86_64. Odd stuff: The tests spew a few (nine) warnings. They don't seem to affect the outcome. t/operations test takes fifteen seconds on FC3 x86_64 but seems to be instantaneous on i386. Everything does build and pass on x86_64 so I'm not sure what the issue is. I see no reason why either of these should be blockers. Approved. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From buildsys at fedoraproject.org Tue Feb 7 22:03:08 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 7 Feb 2006 17:03:08 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060207220308.8DFF0800B@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 2 commoncpp2-1.3.23-1.fc3 nagios-2.0-0.4.rc2.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue Feb 7 22:03:20 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 7 Feb 2006 17:03:20 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060207220320.7D3F5800B@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 14 balsa-2.3.10-1.fc4 blender-2.41-2.fc4 commoncpp2-1.3.23-1.fc4 cpanspec-1.59-2.fc4 gnome-applet-sensors-1.4-2.fc4 gnomebaker-0.5.1-1.fc4 mediawiki-1.5.6-5.fc4 nagios-2.0-0.3.rc2.fc4 perl-Crypt-DES-2.05-1.fc4 perl-Crypt-DES_EDE3-0.01-3.fc4 python-TestGears-0.2-1.fc4 python-enchant-1.1.5-2.fc4 python-json-3.4-1.fc4 translate-toolkit-0.8-0.8.rc6.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue Feb 7 22:03:36 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 7 Feb 2006 17:03:36 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060207220336.555B9800B@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 14 allegro-4.2.0-6 blender-2.41-2.fc5 cacti-0.8.6h-4 commoncpp2-1.3.23-1.fc5 cpanspec-1.59-2.fc5 kiosktool-1.0-5.fc5 kxdocker-0.39-3.fc5 kxdocker-resources-0.14-3.fc5 mod_suphp-0.6.1-1.fc5 nagios-2.0-0.3.rc2.fc5 perl-Math-GMP-2.04-2.fc5 python-enchant-1.1.5-2.fc5 translate-toolkit-0.8-0.8.rc6.fc5 xchat-gnome-0.9-4.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From ville.skytta at iki.fi Tue Feb 7 22:33:05 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 08 Feb 2006 00:33:05 +0200 Subject: Package with dependency on xerces-c In-Reply-To: <20060207180913.GA20746@etymon.com> References: <20060207180913.GA20746@etymon.com> Message-ID: <1139351585.9605.5.camel@bobcat.mine.nu> On Tue, 2006-02-07 at 13:09 -0500, Nassib Nassar wrote: > but this > depends on the xerces-c library which I can't find in the fedora base > repositories. xerces-c is not the easiest thing in the world to package properly, but I've spent some time in the past trying to do so. I'm no longer actively using it for anything so I don't plan to submit/maintain it, but in case someone's interested, go grab it at http://cachalot.mine.nu/5/SRPMS/ Having xerces-c in Extras would allow things such as xalan-c, xml-security-c, possibly opensaml etc there too. From bugzilla at redhat.com Tue Feb 7 23:52:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 18:52:48 -0500 Subject: [Bug 180299] Review Request: pitivi In-Reply-To: Message-ID: <200602072352.k17Nqmm5030802@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: pitivi https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180299 ------- Additional Comments From redhat at flyn.org 2006-02-07 18:52 EST ------- Implemented Jeffrey's suggestions: Spec Name or Url: http://www.flyn.org/SRPMS/pitivi.spec SRPM Name or Url: http://www.flyn.org/SRPMS/pitivi-0.9.9.2-2.src.rpm Description: Pitivi is an application using the GStreamer multimedia framework to manipulate a large set of multimedia sources. At this level of development it can be compared to a classic video editing program. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 7 23:56:03 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 18:56:03 -0500 Subject: [Bug 180298] Review Request: gnonlin In-Reply-To: Message-ID: <200602072356.k17Nu3Vx031178@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnonlin https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180298 ------- Additional Comments From redhat at flyn.org 2006-02-07 18:55 EST ------- Implemented Jeffrey's suggestions: Spec Name or Url: http://www.flyn.org/SRPMS/gnonlin.spec SRPM Name or Url: http://www.flyn.org/SRPMS/gnonlin-0.10.0.5-2.src.rpm Description: Gnonlin is a library built on top of GStreamer (http://gstreamer.net) which provides support for writing non-linear audio and video editing applications. It introduces the concept of a timeline -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From Christian.Iseli at licr.org Wed Feb 8 00:50:21 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 08 Feb 2006 01:50:21 +0100 Subject: FE package status Tue Feb 7 2006 In-Reply-To: Your message of "Tue, 07 Feb 2006 16:11:53 EST." <604aa7910602071311t35ccfca3pfb5ba6302719fe5a@mail.gmail.com> Message-ID: <200602080051.k180pRfQ013375@mx1.redhat.com> jspaleta at gmail.com said: > You are going to automate the creation of the content for the wiki page? Yup. Done. The result can be seen here: http://fedoraproject.org/wiki/Extras/PackageStatus I need to get some sleep now... I'll update the scripts page tomorrow. Please have a look and let me know what you think. I'd also like to know what parts y'all feel should be sent to the mailing list... Cheers, Christian From bugzilla at redhat.com Wed Feb 8 01:22:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 20:22:59 -0500 Subject: [Bug 180422] New: Review Request: gnome-mud Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180422 Summary: Review Request: gnome-mud Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: sysadmin at tacticalbusinesspartners.com QAContact: fedora-extras-list at redhat.com Spec URL: http://m2g04.tunegenie.com/~hlb/Personal/gnome-mud.spec SRPM URL: http://m2g04.tunegenie.com/~hlb/Personal/gnome-mud-0.10.7-1.src.rpm Description: A GTK based MUD client scriptable in python! -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From ndbecker2 at gmail.com Wed Feb 8 01:49:01 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 07 Feb 2006 20:49:01 -0500 Subject: [extra-devel] octave-forge broken deps Message-ID: --> Finished Dependency Resolution Error: Missing Dependency: libcln.so.3()(64bit) is needed by package octave-forge Error: Missing Dependency: octave = 6:2.9.3 is needed by package octave-forge Error: Missing Dependency: libgfortran.so.0()(64bit) is needed by package octave-forge From michael at knox.net.nz Wed Feb 8 02:02:40 2006 From: michael at knox.net.nz (Michael J Knox) Date: Wed, 08 Feb 2006 15:02:40 +1300 Subject: libnotify in gnomebaker In-Reply-To: <1139362651.3727.10.camel@cosima.et.endace.com> References: <1139362651.3727.10.camel@cosima.et.endace.com> Message-ID: <1139364160.3727.12.camel@cosima.et.endace.com> Is there any reason why libnotify support is missing in gnomebaker? Michael From bugzilla at redhat.com Wed Feb 8 02:48:58 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 21:48:58 -0500 Subject: [Bug 176523] Review Request: python-json: A JSON reader and writer for Python In-Reply-To: Message-ID: <200602080248.k182mw0d019925@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: python-json: A JSON reader and writer for Python https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176523 ivazquez at ivazquez.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From ivazquez at ivazquez.net 2006-02-07 21:48 EST ------- Built for FC4 and devel. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 02:49:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 21:49:11 -0500 Subject: [Bug 176526] Review Request: TestGears: Unit testing for Python In-Reply-To: Message-ID: <200602080249.k182nBQd019972@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: TestGears: Unit testing for Python https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176526 ivazquez at ivazquez.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From ivazquez at ivazquez.net 2006-02-07 21:49 EST ------- Built for FC4 and devel. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 02:49:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 21:49:13 -0500 Subject: [Bug 176532] Review Request: TurboGears: Back-to-front web development in Python In-Reply-To: Message-ID: <200602080249.k182nDAQ019990@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: TurboGears: Back-to-front web development in Python https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176532 Bug 176532 depends on bug 176523, which changed state. Bug 176523 Summary: Review Request: python-json: A JSON reader and writer for Python https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176523 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NEXTRELEASE Status|ASSIGNED |CLOSED Bug 176532 depends on bug 176526, which changed state. Bug 176526 Summary: Review Request: TestGears: Unit testing for Python https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176526 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NEXTRELEASE Status|ASSIGNED |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From qspencer at ieee.org Wed Feb 8 02:57:57 2006 From: qspencer at ieee.org (Quentin Spencer) Date: Tue, 07 Feb 2006 20:57:57 -0600 Subject: [extra-devel] octave-forge broken deps In-Reply-To: References: Message-ID: <43E95E35.9020002@ieee.org> Neal Becker wrote: >--> Finished Dependency Resolution >Error: Missing Dependency: libcln.so.3()(64bit) is needed by package octave-forge >Error: Missing Dependency: octave = 6:2.9.3 is needed by package octave-forge >Error: Missing Dependency: libgfortran.so.0()(64bit) is needed by package octave-forge > > This is a known problem. The newest octave-forge release is very old and depends on outdated libraries because octave-forge doesn't currently build with g++ 4.1. I'm in contact with the developer and hope to get this resolved in the near future. -Quentin From bugzilla at redhat.com Wed Feb 8 03:01:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 22:01:44 -0500 Subject: [Bug 180422] Review Request: gnome-mud In-Reply-To: Message-ID: <200602080301.k1831iGi021841@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-mud https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180422 ------- Additional Comments From sysadmin at tacticalbusinesspartners.com 2006-02-07 22:01 EST ------- Upgraded, Spec URL the same, SRPM url is http://m2g04.tunegenie.com/~hlb/Personal/gnome-mud-0.10.7-2.src.rpm Builds successfully in mock. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 8 03:11:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 22:11:48 -0500 Subject: [Bug 180430] New: Review Request: Tong - a game of skill Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180430 Summary: Review Request: Tong - a game of skill Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: wart at kobold.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.kobold.org/~wart/fedora/tong.spec SRPM Name or Url: http://www.kobold.org/~wart/fedora/tong-1.0-2.src.rpm Description: Tong is a clever mixture of two other popular computer games. The data files and core game are split into two packages; the small game package requires the much larger data files package. Both come from the same source archive and spec file, however, so there won't be any space saving benefit from splitting this up into the two packages since an rebuild and release of the game will trigger a rebuild and release of the data package as well. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 8 03:31:38 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 22:31:38 -0500 Subject: [Bug 176780] Review Request: wp_tray: A wallpaper utility that sits in the Notification Area In-Reply-To: Message-ID: <200602080331.k183Vcbg027694@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: wp_tray: A wallpaper utility that sits in the Notification Area https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176780 ------- Additional Comments From ivazquez at ivazquez.net 2006-02-07 22:31 EST ------- Built under FC4 and devel. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 03:58:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 22:58:49 -0500 Subject: [Bug 173028] Review Request: ser - SIP Express Router In-Reply-To: Message-ID: <200602080358.k183wnId000912@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - SIP Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173028 ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-07 22:58 EST ------- Peter, do you want to keep SER or can it be turned over to Andreas? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 04:02:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 23:02:56 -0500 Subject: [Bug 174368] Review Request: perl-Crypt-DSA In-Reply-To: Message-ID: <200602080402.k1842uSv001714@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Crypt-DSA https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174368 ------- Additional Comments From tibbs at math.uh.edu 2006-02-07 23:02 EST ------- I had to build perl-Convert-PEM and one of its prerequisites from CVS in order to begin a review. The %check portion of the build took several minutes, some of it without any noticeable CPU consumption. I found that odd, but the package built in the end. rpmlint is silent. Source matches upstream. The license is acceptable ("same as Perl" in the source, so "GPL or Artistic" is appropriate). Package meets naming and packaging guidelines. Specfile is properly named, legible, and uses macros consistently. Package builds and installs on FC4 x86 and FC3 x86_64. BuildRequires: is proper. Could you verify that the odd test behavior is OK? If it is, I'll approve this package. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 04:40:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 7 Feb 2006 23:40:59 -0500 Subject: [Bug 180298] Review Request: gnonlin In-Reply-To: Message-ID: <200602080440.k184exht008668@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnonlin https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180298 ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-07 23:40 EST ------- Here's the full review: - MUST: rpmlint must be run on every package. The output should be posted in the review. Not OK: [jcollie at lt16585 result]$ rpmlint gnonlin-0.10.0.5-2.i386.rpm gnonlin-devel-0.10.0.5-2.i386.rpm W: gnonlin non-standard-group System/Libraries Should be "System Environment/Libraries". W: gnonlin-devel non-standard-group Development/C Should be "Development/Libraries". W: gnonlin-devel no-documentation Safe to ignore, but wouldn't hurt to include the COPYING.LIB file in the -devel subpackages %doc. - MUST: The package must be named according to the Package Naming Guidelines. OK - MUST: The spec file name must match the base package %{name}, in the format %{name}.spec OK - MUST: The package must meet the Packaging Guidelines. OK - MUST: The package must be licensed with an open-source compatible license and meet other legal requirements as defined in the legal section of Packaging Guidelines. OK (LGPL) - MUST: The License field in the package spec file must match the actual license. Not OK - the .spec (and the web page) indicates LGPL but the COPYING file included in the package is the GPL. COPYING.LIB is the LGPL text. - MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc. OK (But see above) - MUST: The spec file must be written in American English. OK - MUST: The spec file for the package MUST be legible. If the reviewer is unable to read the spec file, it will be impossible to perform a review. Fedora Extras is not the place for entries into the Obfuscated Code Contest ([WWW] http://www.ioccc.org/). OK - MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. OK - MUST: The package must successfully compile and build into binary rpms on at least one supported architecture. OK (Tested devel/i386) - MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch needs to have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number should then be placed in a comment, next to the corresponding ExcludeArch line. New packages will not have bugzilla entries during the review process, so they should put this description in the comment until the package is approved, then file the bugzilla entry, and replace the long explanation with the bug number. The bug should be marked as blocking one (or more) of the following bugs to simplify tracking such issues: [WWW] FE-ExcludeArch-x86, [WWW] FE-ExcludeArch-x64, [WWW] FE-ExcludeArch-ppc OK - MUST: A package must not contain any BuildRequires that are listed in the exceptions section of Packaging Guidelines. OK - MUST: All other Build dependencies must be listed in BuildRequires. OK - MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden. OK (no localized text included in package). - MUST: If the package contains shared library files located in the dynamic linker's default paths, that package must call ldconfig in %post and %postun. If the package has multiple subpackages with libraries, each subpackage should also have a %post/%postun section that calls /sbin/ldconfig. An example of the correct syntax for this is: %post -p /sbin/ldconfig %postun -p /sbin/ldconfig OK (shared libraries are included but running ldconfig is not needed on gstreamer plugins) - MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. OK (Not designed to be locatable) - MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. The exception to this are directories listed explicitly in the Filesystem Hierarchy Standard ([WWW] http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to assume that those directories exist. OK - MUST: A package must not contain any duplicate files in the %files listing. NOT OK (The %{_includedir}/gnl/* in the -devel subpackage's %file is not necessary. %{_includedir}/gnl will pick up the directory and all of the files below it.) - MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. OK - MUST: Each package must have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). OK - MUST: Each package must consistently use macros, as described in the macros section of Packaging Guidelines. OK - MUST: The package must contain code, or permissable content. This is described in detail in the code vs. content section of Packaging Guidelines. OK - MUST: Large documentation files should go in a -docs subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity) OK - MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. OK - MUST: Header files or static libraries must be in a -devel package. OK - MUST: Files used by pkgconfig (.pc files) must be in a -devel package. OK - MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. OK - MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency. OK - MUST: Packages must NOT contain any .la libtool archives, these should be removed in the spec. OK - MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. This is described in detail in the desktop files section of Packaging Guidelines. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. OK (no GUI applications) - MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora Extras should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. OK - SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. OK (package includes license text) - SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available. OK - SHOULD: The reviewer should test that the package builds in mock. OK (builds in mock for devel/i386) - SHOULD: The package should compile and build into binary rpms on all supported architectures. OK - SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example. OK (I think. I tried to use as part of pitivi. pitivi runs (or at least opens it's main window) but I'm unable to do anything. I don't think that that's the fault of gnonlin though.) - SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity. OK (no scriptlets used) - SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency. OK (all subpackages have fully versioned dependency) Some other things that I noticed: 1. Actually, without the aclocal and autoconf in %prep gettext-devel isn't needed as a build requirement. 2. Don't need the Requires(pre) and Requires(post) since there are no %pre and %post scripts. 3. I would expand the URL of the gnonlin home page to . -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From a.kurtz at hardsun.net Wed Feb 8 05:06:58 2006 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Tue, 07 Feb 2006 21:06:58 -0800 Subject: FE package status Tue Feb 7 2006 In-Reply-To: <200602071718.k17HI7fL011115@ludwig-alpha.unil.ch> References: <200602071718.k17HI7fL011115@ludwig-alpha.unil.ch> Message-ID: <1139375219.4182.5.camel@nene.hardsun.net> On Tue, 2006-02-07 at 18:18 +0100, Christian.Iseli at licr.org wrote: > gnome-cpufreq-applet adrian Isn't this included in gnome-applets since at least FC4? I think this is a fedora.us holdover. -- Aaron Kurtz From bugzilla at redhat.com Wed Feb 8 05:59:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 00:59:44 -0500 Subject: [Bug 180299] Review Request: pitivi In-Reply-To: Message-ID: <200602080559.k185xi5l017730@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: pitivi https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180299 ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-08 00:59 EST ------- Here's the full review: - MUST: rpmlint must be run on every package. The output should be posted in the review. Not OK (Does not build yet in mock.) - MUST: The package must be named according to the Package Naming Guidelines. OK - MUST: The spec file name must match the base package %{name}, in the format %{name}.spec OK - MUST: The package must meet the Packaging Guidelines. OK - MUST: The package must be licensed with an open-source compatible license and meet other legal requirements as defined in the legal section of Packaging Guidelines. OK (GPL) - MUST: The License field in the package spec file must match the actual license. OK - MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc. OK - MUST: The spec file must be written in American English. OK - MUST: The spec file for the package MUST be legible. If the reviewer is unable to read the spec file, it will be impossible to perform a review. Fedora Extras is not the place for entries into the Obfuscated Code Contest ([WWW] http://www.ioccc.org/). OK - MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. OK - MUST: The package must successfully compile and build into binary rpms on at least one supported architecture. Not OK (See notes about BuildRequires and unpackaged files). - MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch needs to have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number should then be placed in a comment, next to the corresponding ExcludeArch line. New packages will not have bugzilla entries during the review process, so they should put this description in the comment until the package is approved, then file the bugzilla entry, and replace the long explanation with the bug number. The bug should be marked as blocking one (or more) of the following bugs to simplify tracking such issues: [WWW] FE-ExcludeArch-x86, [WWW] FE-ExcludeArch-x64, [WWW] FE-ExcludeArch-ppc Not OK (Does not build yet.) - MUST: A package must not contain any BuildRequires that are listed in the exceptions section of Packaging Guidelines. OK - MUST: All other Build dependencies must be listed in BuildRequires. Not OK (Need to BuildRequire pygtk2-devel gnome-python2 and gstreamer-python) - MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden. OK (No localized text.) - MUST: If the package contains shared library files located in the dynamic linker's default paths, that package must call ldconfig in %post and %postun. If the package has multiple subpackages with libraries, each subpackage should also have a %post/%postun section that calls /sbin/ldconfig. An example of the correct syntax for this is: %post -p /sbin/ldconfig %postun -p /sbin/ldconfig OK (No shared libraries.) - MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. OK (Not designed to be relocatable.) - MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. The exception to this are directories listed explicitly in the Filesystem Hierarchy Standard ([WWW] http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to assume that those directories exist. Not OK (missing %{_libdir}/pitivi/python/pitivi/ui/*.glade) - MUST: A package must not contain any duplicate files in the %files listing. OK - MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. OK - MUST: Each package must have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). OK - MUST: Each package must consistently use macros, as described in the macros section of Packaging Guidelines. OK - MUST: The package must contain code, or permissable content. This is described in detail in the code vs. content section of Packaging Guidelines. OK - MUST: Large documentation files should go in a -docs subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity) OK (No large docs.) - MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. OK - MUST: Header files or static libraries must be in a -devel package. OK (no header files or static libraries) - MUST: Files used by pkgconfig (.pc files) must be in a -devel package. OK (no pkgconfig files) - MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. OK (no shared libs) - MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency. OK (no -devel subpackage) - MUST: Packages must NOT contain any .la libtool archives, these should be removed in the spec. OK - MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. This is described in detail in the desktop files section of Packaging Guidelines. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. OK - MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora Extras should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. OK - SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. OK - SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available. OK - SHOULD: The reviewer should test that the package builds in mock. Not OK (Missing build requires - see above). - SHOULD: The package should compile and build into binary rpms on all supported architectures. Not OK (Does not build yet.) - SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example. Not OK (Does not build yet.) - SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity. OK (no scriptlets) - SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency. OK (no subpackages) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From sdl.web at gmail.com Tue Feb 7 20:02:47 2006 From: sdl.web at gmail.com (leon) Date: Tue, 07 Feb 2006 20:02:47 +0000 Subject: where to request package to be added to FE? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, I'm curious about why FE doesn't include xCHM or gnochm. Both are released under GPL. Cheers - -- .--~~,__ :-....,-------`~~'._.' Dog's year! `-,,, ,_ ;'~U' _,-' ,'`-__; '--. (_/'~~ ''''(; -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFD6PzpkaVrPa103cYRAkxKAJ9eGBat299Ju8DJi9rPgoAcr+kjvwCbBZoe jGZybpsPvdtX+NqnvWbEtb4= =Ig9A -----END PGP SIGNATURE----- From bugzilla at redhat.com Wed Feb 8 06:30:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 01:30:34 -0500 Subject: [Bug 173028] Review Request: ser - SIP Express Router In-Reply-To: Message-ID: <200602080630.k186UYv5021571@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - SIP Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173028 ------- Additional Comments From lemenkov at newmail.ru 2006-02-08 01:30 EST ------- (In reply to comment #3) > Peter, do you want to keep SER or can it be turned over to Andreas? I willingly let Andreas to take ownership over SER. My only reques is to make separate packages for ser-jabber, ser-cpl-c and ser-pa modules as well as for ser-postgres and ser-mysql modules. This patch would be useful for doing this: http://paula.comtv.ru/ser-0.9.4-Makefile.patch -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 06:34:40 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 01:34:40 -0500 Subject: [Bug 176528] Review Request: MochiKit: A lightweight JavaScript library In-Reply-To: Message-ID: <200602080634.k186Yenc022335@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: MochiKit: A lightweight JavaScript library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176528 ------- Additional Comments From ivazquez at ivazquez.net 2006-02-08 01:34 EST ------- Updated. http://fedora.ivazquez.net/files/extras/MochiKit-1.2-1.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From ankit644 at yahoo.com Wed Feb 8 07:16:44 2006 From: ankit644 at yahoo.com (Ankit Patel) Date: Tue, 7 Feb 2006 23:16:44 -0800 (PST) Subject: where to request package to be added to FE? In-Reply-To: Message-ID: <20060208071644.97622.qmail@web34605.mail.mud.yahoo.com> --- leon wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi guys, > > I'm curious about why FE doesn't include xCHM or > gnochm. Both are > released under GPL. > > Cheers > - -- > .--~~,__ > :-....,-------`~~'._.' Dog's year! > `-,,, ,_ ;'~U' > _,-' ,'`-__; '--. > (_/'~~ ''''(; > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.0 (GNU/Linux) > > iD8DBQFD6PzpkaVrPa103cYRAkxKAJ9eGBat299Ju8DJi9rPgoAcr+kjvwCbBZoe > jGZybpsPvdtX+NqnvWbEtb4= > =Ig9A > -----END PGP SIGNATURE----- > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > Leon, Please refer to the following URL: http://fedoraproject.org/wiki/Extras/Contributors Regards, Ankit Patel __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From bugzilla at redhat.com Wed Feb 8 07:56:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 02:56:01 -0500 Subject: [Bug 175281] Review Request: perl-Tie-EncryptedHash In-Reply-To: Message-ID: <200602080756.k187u1f9000351@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Tie-EncryptedHash https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175281 paul at city-fan.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From paul at city-fan.org 2006-02-08 02:55 EST ------- Thanks for the review. Build on target fedora-development-extras succeeded. I'm not sure about the test issues either, but there don't seems to be any bugs on rt.cpan.org and this module release is getting on for 4 years old now, so I reckon it's OK. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From adrian at lisas.de Wed Feb 8 08:02:12 2006 From: adrian at lisas.de (Adrian Reber) Date: Wed, 8 Feb 2006 09:02:12 +0100 Subject: FE package status Tue Feb 7 2006 In-Reply-To: <1139375219.4182.5.camel@nene.hardsun.net> References: <200602071718.k17HI7fL011115@ludwig-alpha.unil.ch> <1139375219.4182.5.camel@nene.hardsun.net> Message-ID: <20060208080212.GA939@lisas.de> On Tue, Feb 07, 2006 at 09:06:58PM -0800, Aaron Kurtz wrote: > > gnome-cpufreq-applet adrian > > Isn't this included in gnome-applets since at least FC4? I think this is > a fedora.us holdover. It is not a fedora.us holdover but it is included in gnome-applets since FC4. Adrian From sdl.web at gmail.com Wed Feb 8 08:02:27 2006 From: sdl.web at gmail.com (leon) Date: Wed, 08 Feb 2006 08:02:27 +0000 Subject: where to request package to be added to FE? References: <20060208071644.97622.qmail@web34605.mail.mud.yahoo.com> Message-ID: Ankit Patel writes: | | Leon, | | Please refer to the following URL: | http://fedoraproject.org/wiki/Extras/Contributors | | Regards, | Ankit Patel | Thank you, Ankit. -- .--~~,__ :-....,-------`~~'._.' Dog's year! `-,,, ,_ ;'~U' _,-' ,'`-__; '--. (_/'~~ ''''(; -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From bugzilla at redhat.com Wed Feb 8 08:03:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 03:03:13 -0500 Subject: [Bug 168607] Review Request: perl-Convert-PEM In-Reply-To: Message-ID: <200602080803.k1883DKM001134@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Convert-PEM https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168607 ------- Additional Comments From paul at city-fan.org 2006-02-08 03:03 EST ------- Steve, can you do a build of this module for FC-4 please? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 08:08:39 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 03:08:39 -0500 Subject: [Bug 179916] Review Request: docbook2X - Convert docbook into man and Texinfo In-Reply-To: Message-ID: <200602080808.k1888duX001783@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: docbook2X - Convert docbook into man and Texinfo https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179916 ------- Additional Comments From paul at city-fan.org 2006-02-08 03:08 EST ------- (In reply to comment #3) > rpmlint isn't happy with libxslt as Require, but docbook2X requires xsltproc > which is in libxslt. Perhaps you could change the dependency from libxslt to /usr/bin/xsltproc then? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 8 09:15:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 04:15:11 -0500 Subject: [Bug 180319] Review Request: svnmailer - Tool to post subversion repository commit information In-Reply-To: Message-ID: <200602080915.k189FBIT017527@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: svnmailer - Tool to post subversion repository commit information https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180319 ------- Additional Comments From mfleming+rpm at enlartenment.com 2006-02-08 04:15 EST ------- (In reply to comment #3) New SRPM: http://www.enlartenment.com/extras/svnmailer-1.0.6-2.src.rpm New SPEC: http://www.enlartenment.com/extras/svnmailer.spec > * I would still prefer a more strict following of the spec template. Use the new > template and fill it with the older information: it would really make it more > readable. Done, hope it's more sensible and legible. > * Change the license to "Apache Software License" so rpmlint likes it. Done. How on earth did I miss that before :-P > * Does it really need subversion as a Buildreq? Interestingly, yes - as it likes the subversion python bindings there during builds (and FC4 has them in the base package...). I've built it before without it and the results are quite erm, *interesting* :-). > Suggestions (non-binding!): > * You may consider separating the documentation into a subpackage. It's large > and it probably won't be useful to most of the users. Done (svnmailer-doc - suggestions on a better subpackage convention welcomed) > * You may also consider running the test suite provided upstream automatically. > Not a bad idea for folks who want to extend or otherwise hack on it, but I'd like to nail the basic package first. TODO. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 8 09:36:42 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 04:36:42 -0500 Subject: [Bug 173028] Review Request: ser - SIP Express Router In-Reply-To: Message-ID: <200602080936.k189agkU021880@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - SIP Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173028 ------- Additional Comments From andreas at bawue.net 2006-02-08 04:36 EST ------- Thx Peter. About the different packages: mysql and postgresql are already packaged as subpackages. This makes sense, as both pull in quite a lot of dependencies, which is unnecessary if one is only using one database and not the other. But about the jabber, cpl-c and pa modules, I'm not so sure. All they depend on are libxml2, expat and pthread. These libraries are already installed on most systems by default, so it makes no sense IMHO to split the package up any further. Comments? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 09:57:55 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 04:57:55 -0500 Subject: [Bug 177507] Review Request: pida In-Reply-To: Message-ID: <200602080957.k189vtUu025415@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: pida https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177507 ------- Additional Comments From che666 at gmail.com 2006-02-08 04:57 EST ------- (In reply to comment #6) > - This > >Requires: python-abi = %(%{__python} -c "import sys ; print sys.version[:3]") > is not needed anymore -- works automatically in FC4 and later alright thats cleaned up now. > - Don't repeat the name of the package in the beginning of the summary cosmetical fix done ;) > - The license doesn't look like GPL its MIT... fixed > - Description needs a linebreak after 80 chars linebreaks done > - Description might be a bit to long gotta recheck that. shouldnt be a big problem to make it shorter > - Change > Requires: desktop-file-utils > to > BuildRequires: desktop-file-utils thats correct and fixed now > - In the future please add versions in the changelog also done > - why "Release: 0.2" and not "Release: 2"? this has multible reasons. first i dont want to give the impression that the package is yet really production ready and second of all i wanted to start of with a clean -1 release once its approved. in my eyes pida is very promising software but very young yet so it can definitely use some love and care already. 0.3.1 is a useable release if the embedded vim editor is used. > - saw those warnings when starting pida: > which: no pydoc in > (/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/rpmbuild/usr/bin:/home/rpmbuild/server/usr/bin) > which: no xemacs in > (/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/rpmbuild/usr/bin:/home/rpmbuild/server/usr/bin) > Are they relevant? optional components. pida is a framework. > - In the future please upload the srpms somewhere to the web and post only post > links to it -- don't attach the packages in bugzilla alright but unfortunately thats the reason why i dont have the src rpm up yet. > > (In reply to comment #5) > > list of known issues: > > - usually bicyclerepair would be required to load the python plugins but i left > > the dependencys out since the plugins (browser/profiler/debugger) dont load > > anyways. (will be fixed with 0.3.0) > > I would add it nevertheless seems to be not even required anymore. but i will talk back to upstream. going to clear up the issue until the next src rpm upload. TODO: 1) do something with the stuff in docs/ folder... maybe it would be nice to pdf those html manuals. suggestions? 2) get the vim problem fixed (actually i had problems to get the external vim editor going) 3) build install and split off the in extras/ included gazpacho plugin 4) report all found issues to upstream -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 10:14:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 05:14:28 -0500 Subject: [Bug 174368] Review Request: perl-Crypt-DSA In-Reply-To: Message-ID: <200602081014.k18AESb1027913@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Crypt-DSA https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174368 ------- Additional Comments From paul at city-fan.org 2006-02-08 05:14 EST ------- (In reply to comment #1) > I had to build perl-Convert-PEM and one of its prerequisites from CVS in order > to begin a review. I've asked Steve to do an FC4 build of perl-Convert-PEM now, so hopefully this will be available soon. > The %check portion of the build took several minutes, some of it without any > noticeable CPU consumption. I found that odd, but the package built in the end. ... > Could you verify that the odd test behavior is OK? If it is, I'll approve this > package. I've just done a test rebuild of the package here, which took just under 5 minutes (seems reasonable), and it used 100% CPU throughout the test suite. One possibility is that your build was waiting for some entropy at some point during the test suite? Perhaps pressing some keys when it's in that state might help? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 10:36:05 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 05:36:05 -0500 Subject: [Bug 179916] Review Request: docbook2X - Convert docbook into man and Texinfo In-Reply-To: Message-ID: <200602081036.k18Aa59X030727@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: docbook2X - Convert docbook into man and Texinfo https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179916 ------- Additional Comments From jamatos at fc.up.pt 2006-02-08 05:36 EST ------- (In reply to comment #4) > > Perhaps you could change the dependency from libxslt to /usr/bin/xsltproc then? I think that in this case this it is just a style issue. I don't have any problem with the dependency as it is. :-) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugs.michael at gmx.net Wed Feb 8 11:35:35 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 8 Feb 2006 06:35:35 -0500 Subject: Summary - Broken dependencies in Fedora Extras 4 Message-ID: <200602081135.k18BZZm6025283@mx3.redhat.com> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- gnome-applet-sensors 1.4-2.fc4.i386 ---------------------------------------------------------------------- Report for: a.kurtz AT hardsun.net package: gnome-applet-sensors - 1.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: lm-sensors From bugs.michael at gmx.net Wed Feb 8 11:36:53 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 8 Feb 2006 06:36:53 -0500 Subject: Summary - Broken dependencies in Fedora Extras development Message-ID: <200602081136.k18BarwJ025669@mx3.redhat.com> From bugs.michael at gmx.net Wed Feb 8 11:47:12 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 8 Feb 2006 12:47:12 +0100 Subject: RFC: automated broken deps reports Message-ID: <20060208124712.59cfeaf4.bugs.michael@gmx.net> As discussed briefly in the last meeting of FESCO, there are a few open questions with regard to running a script that does automated checking of broken dependencies in Fedora Extras: * How often to run it? Daily? After every push of new builds for Fedora Extras? If Rawhide breaks something how do we become aware of that in time? That is, do we know exactly when new packages are pushed in Rawhide so the script would not run before that? Does it matter? The next run a day later would catch broken deps. Do we, at Fedora Extras, have big interest in knowing quickly when changes in Rawhide break anything in Extras? Reports of broken packages are not worthwhile if rebuilds or fixes won't happen until packagers track and "support" Rawhide or unless a special team at Fedora Extras takes over doing the rebuilds for devel. * Whether to mail a summary of all broken dependencies to fedora-extras-list? So far, during the few public test-runs, a packager received a summary of all broken dependencies for all his broken packages in a single mail. What format should a complete summary, which is posted to fedora-extras-list, have, so it would be useful and readable? Maybe package name version repository e-mail or srcrpm name repository e-mail or package name version sorted by name or sorted by e-mail and grouped by arch? With the full summary at the bottom? Ideas? The complete list of broken packages in Fedora Extras Development is not short. Additionally, if reports for FE3, FE4 and FE Development were squeezed into the same mail, that would decrease readability even more. Create individuals mails for FE3/FE4/FE5? (that almost sounds like it could be merged with the "new packages" report) * How often to mail the packager? Would it be considered an annoyance to mail the packager daily because the script is run every day? Would it be enough to mail once then not repeat the reports for 7-14 days or unless the src.rpm file name changes? [...] The current scripts and their working directory can be found here for anybody who likes to take a look: http://home.arcor.de/ms2002sep/tmp/repoclosure-modified-20060208.tgz From bugs.michael at gmx.net Wed Feb 8 11:50:26 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 8 Feb 2006 06:50:26 -0500 Subject: Summary - Broken dependencies in Fedora Extras development Message-ID: <200602081150.k18BoQql029835@mx3.redhat.com> And another try... Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- apt 0.5.15cnc7-7.fc5.i386 apt-groupinstall 0.5.15cnc7-7.fc5.i386 at-poke 0.2.2-2.i386 cyrus-imapd 2.2.12-6.fc4.i386 cyrus-imapd-murder 2.2.12-6.fc4.i386 cyrus-imapd-nntp 2.2.12-6.fc4.i386 cyrus-imapd-utils 2.2.12-6.fc4.i386 hping2 2.0.0-0.5.rc3.i386 istanbul 0.1.1-5.i386 libgda-sqlite 1:1.2.0-8.i386 libgdamm 1.3.7-2.fc5.i386 ngrep 1.44-4.fc5.i386 octave-forge 2005.06.13-4.fc5.i386 openal-test 0.0-0.4.20040726.i386 p0f 2.0.5-3.i386 pam_mount 0.9.25-4.i386 perl-Cyrus 2.2.12-6.fc4.i386 pgadmin3 1.0.2-5.i386 php-eaccelerator 5.0.5_0.9.3-4.fc5.i386 php-mmcache 5.0.5_2.4.6-7.fc5.i386 proftpd 1.2.10-6.fc5.i386 python-amara 0.9.4-7.fc4.noarch sabayon-admin 2.12.1-2.i386 scalapack 1.7-7.fc4.i386 screem 0.14.1-1.fc5.i386 seahorse 0.7.9-1.fc5.i386 soundconverter 0.8.1-2.fc5.noarch syck-php 0.55-6.fc5.i386 tripwire 2.3.1-22.i386 up-imapproxy 1.2.4-4.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- apt 0.5.15cnc7-7.fc5.ppc apt-groupinstall 0.5.15cnc7-7.fc5.ppc at-poke 0.2.2-2.ppc cyrus-imapd 2.2.12-6.fc4.ppc cyrus-imapd-murder 2.2.12-6.fc4.ppc cyrus-imapd-nntp 2.2.12-6.fc4.ppc cyrus-imapd-utils 2.2.12-6.fc4.ppc hping2 2.0.0-0.5.rc3.ppc istanbul 0.1.1-5.ppc libgda-sqlite 1:1.2.0-8.ppc libgdamm 1.3.7-2.fc5.ppc ngrep 1.44-3.fc5.ppc octave-forge 2005.06.13-4.fc5.ppc openal-test 0.0-0.4.20040726.ppc p0f 2.0.5-3.ppc pam_mount 0.9.25-4.ppc perl-Cyrus 2.2.12-6.fc4.ppc pgadmin3 1.0.2-5.ppc php-eaccelerator 5.0.5_0.9.3-4.fc5.ppc php-mmcache 5.0.5_2.4.6-7.fc5.ppc proftpd 1.2.10-6.fc5.ppc python-amara 0.9.4-7.fc4.noarch sabayon-admin 2.12.1-2.ppc scalapack 1.7-7.fc4.ppc screem 0.14.1-1.fc5.ppc seahorse 0.7.9-1.fc5.ppc soundconverter 0.8.1-2.fc5.noarch syck-php 0.55-6.fc5.ppc up-imapproxy 1.2.4-4.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- at-poke 0.2.2-2.x86_64 cernlib 2005-7.fc5.x86_64 cernlib-packlib 2005-7.fc5.x86_64 cyrus-imapd 2.2.12-6.fc4.x86_64 cyrus-imapd-murder 2.2.12-6.fc4.x86_64 cyrus-imapd-nntp 2.2.12-6.fc4.x86_64 cyrus-imapd-utils 2.2.12-6.fc4.x86_64 hping2 2.0.0-0.5.rc3.x86_64 istanbul 0.1.1-5.x86_64 libgda-sqlite 1:1.2.0-8.x86_64 libgdamm 1.3.7-2.fc5.x86_64 ngrep 1.44-4.fc5.x86_64 octave-forge 2005.06.13-4.fc5.x86_64 openal-test 0.0-0.4.20040726.x86_64 p0f 2.0.5-3.x86_64 pam_mount 0.9.25-4.x86_64 paw 2005-7.fc5.x86_64 perl-Cyrus 2.2.12-6.fc4.x86_64 pgadmin3 1.0.2-5.x86_64 php-eaccelerator 5.0.5_0.9.3-4.fc5.x86_64 php-mmcache 5.0.5_2.4.6-7.fc5.x86_64 proftpd 1.2.10-6.fc5.x86_64 python-amara 0.9.4-7.fc4.noarch sabayon-admin 2.12.1-2.x86_64 scalapack 1.7-7.fc4.x86_64 screem 0.14.1-1.fc5.x86_64 seahorse 0.7.9-1.fc5.x86_64 soundconverter 0.8.1-2.fc5.noarch syck-php 0.55-6.fc5.x86_64 up-imapproxy 1.2.4-4.fc5.x86_64 ---------------------------------------------------------------------- Report for: ghenry AT suretecsystems.com package: pgadmin3 - 1.0.2-5.i386 from fedora-extras-development-i386 unresolved deps: libssl.so.5 libcrypto.so.5 package: pgadmin3 - 1.0.2-5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcrypto.so.5()(64bit) libssl.so.5()(64bit) package: pgadmin3 - 1.0.2-5.ppc from fedora-extras-development-ppc unresolved deps: libssl.so.5 libcrypto.so.5 ---------------------------------------------------------------------- Report for: extras-orphan AT fedoraproject.org package: apt-groupinstall - 0.5.15cnc7-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: comps package: p0f - 2.0.5-3.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.8.3 package: at-poke - 0.2.2-2.i386 from fedora-extras-development-i386 unresolved deps: libpixman.so.1 libcairo.so.1 package: screem - 0.14.1-1.fc5.i386 from fedora-extras-development-i386 unresolved deps: libpixman.so.1 libdbus-1.so.1 libcairo.so.1 libgnome-menu.so.0 libdbus-glib-1.so.1 package: hping2 - 2.0.0-0.5.rc3.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.3 package: apt - 0.5.15cnc7-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libneon.so.24 package: p0f - 2.0.5-3.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.8.3()(64bit) package: screem - 0.14.1-1.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libdbus-glib-1.so.1()(64bit) libpixman.so.1()(64bit) libcairo.so.1()(64bit) libgnome-menu.so.0()(64bit) libdbus-1.so.1()(64bit) package: hping2 - 2.0.0-0.5.rc3.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.3()(64bit) package: at-poke - 0.2.2-2.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpixman.so.1()(64bit) libcairo.so.1()(64bit) package: screem - 0.14.1-1.fc5.ppc from fedora-extras-development-ppc unresolved deps: libpixman.so.1 libdbus-1.so.1 libcairo.so.1 libgnome-menu.so.0 libdbus-glib-1.so.1 package: at-poke - 0.2.2-2.ppc from fedora-extras-development-ppc unresolved deps: libpixman.so.1 libcairo.so.1 package: apt - 0.5.15cnc7-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libneon.so.24 package: p0f - 2.0.5-3.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.8.3 package: apt-groupinstall - 0.5.15cnc7-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: comps package: hping2 - 2.0.0-0.5.rc3.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.3 ---------------------------------------------------------------------- Report for: andreas.bierfert AT lowlatency.de package: openal-test - 0.0-0.4.20040726.i386 from fedora-extras-development-i386 unresolved deps: openal = 0:0.0-0.4.20040726 package: openal-test - 0.0-0.4.20040726.x86_64 from fedora-extras-development-x86_64 unresolved deps: openal = 0:0.0-0.4.20040726 package: openal-test - 0.0-0.4.20040726.ppc from fedora-extras-development-ppc unresolved deps: openal = 0:0.0-0.4.20040726 ---------------------------------------------------------------------- Report for: tripwire-devel AT genesis-x.nildram.co.uk package: tripwire - 2.3.1-22.i386 from fedora-extras-development-i386 unresolved deps: libcrypto.so.5 ---------------------------------------------------------------------- Report for: oliver AT linux-kernel.at package: ngrep - 1.44-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.3 package: syck-php - 0.55-6.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.0.5 package: ngrep - 1.44-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.3()(64bit) package: syck-php - 0.55-6.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.0.5 package: ngrep - 1.44-3.fc5.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.3 package: syck-php - 0.55-6.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.0.5 ---------------------------------------------------------------------- Report for: qspencer AT ieee.org package: octave-forge - 2005.06.13-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgfortran.so.0 libcln.so.3 octave = 6:2.9.3 package: octave-forge - 2005.06.13-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgfortran.so.0()(64bit) libcln.so.3()(64bit) octave = 6:2.9.3 package: octave-forge - 2005.06.13-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgfortran.so.0 libcln.so.3 octave = 6:2.9.3 ---------------------------------------------------------------------- Report for: jspaleta AT gmail.com package: istanbul - 0.1.1-5.i386 from fedora-extras-development-i386 unresolved deps: gstreamer-plugins >= 0:0.8.9 package: istanbul - 0.1.1-5.x86_64 from fedora-extras-development-x86_64 unresolved deps: gstreamer-plugins >= 0:0.8.9 package: istanbul - 0.1.1-5.ppc from fedora-extras-development-ppc unresolved deps: gstreamer-plugins >= 0:0.8.9 ---------------------------------------------------------------------- Report for: redhat AT flyn.org package: pam_mount - 0.9.25-4.i386 from fedora-extras-development-i386 unresolved deps: libcrypto.so.5 libssl.so.5 package: pam_mount - 0.9.25-4.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcrypto.so.5()(64bit) libssl.so.5()(64bit) package: pam_mount - 0.9.25-4.ppc from fedora-extras-development-ppc unresolved deps: libcrypto.so.5 libssl.so.5 ---------------------------------------------------------------------- Report for: pertusus AT free.fr package: paw - 2005-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libXm.so.3()(64bit) package: cernlib - 2005-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libXm.so.3()(64bit) package: cernlib-packlib - 2005-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libXm.so.3()(64bit) ---------------------------------------------------------------------- Report for: tcallawa AT redhat.com package: libgdamm - 1.3.7-2.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgda-2.so.3 package: scalapack - 1.7-7.fc4.i386 from fedora-extras-development-i386 unresolved deps: libgfortran.so.0 package: scalapack - 1.7-7.fc4.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgfortran.so.0()(64bit) package: libgdamm - 1.3.7-2.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgda-2.so.3()(64bit) package: libgdamm - 1.3.7-2.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgda-2.so.3 package: scalapack - 1.7-7.fc4.ppc from fedora-extras-development-ppc unresolved deps: libgfortran.so.0 ---------------------------------------------------------------------- Report for: jdennis AT redhat.com package: cyrus-imapd - 2.2.12-6.fc4.i386 from fedora-extras-development-i386 unresolved deps: libssl.so.5 libcrypto.so.5 package: cyrus-imapd-murder - 2.2.12-6.fc4.i386 from fedora-extras-development-i386 unresolved deps: libssl.so.5 libcrypto.so.5 package: perl-Cyrus - 2.2.12-6.fc4.i386 from fedora-extras-development-i386 unresolved deps: libssl.so.5 libcrypto.so.5 package: cyrus-imapd-nntp - 2.2.12-6.fc4.i386 from fedora-extras-development-i386 unresolved deps: libcrypto.so.5 libssl.so.5 package: cyrus-imapd-utils - 2.2.12-6.fc4.i386 from fedora-extras-development-i386 unresolved deps: libcrypto.so.5 libssl.so.5 package: cyrus-imapd-nntp - 2.2.12-6.fc4.x86_64 from fedora-extras-development-x86_64 unresolved deps: libssl.so.5()(64bit) libcrypto.so.5()(64bit) package: cyrus-imapd-murder - 2.2.12-6.fc4.x86_64 from fedora-extras-development-x86_64 unresolved deps: libssl.so.5()(64bit) libcrypto.so.5()(64bit) package: perl-Cyrus - 2.2.12-6.fc4.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcrypto.so.5()(64bit) libssl.so.5()(64bit) package: cyrus-imapd - 2.2.12-6.fc4.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcrypto.so.5()(64bit) libssl.so.5()(64bit) package: cyrus-imapd-utils - 2.2.12-6.fc4.x86_64 from fedora-extras-development-x86_64 unresolved deps: libssl.so.5()(64bit) libcrypto.so.5()(64bit) package: cyrus-imapd - 2.2.12-6.fc4.ppc from fedora-extras-development-ppc unresolved deps: libssl.so.5 libcrypto.so.5 package: cyrus-imapd-murder - 2.2.12-6.fc4.ppc from fedora-extras-development-ppc unresolved deps: libssl.so.5 libcrypto.so.5 package: cyrus-imapd-utils - 2.2.12-6.fc4.ppc from fedora-extras-development-ppc unresolved deps: libcrypto.so.5 libssl.so.5 package: cyrus-imapd-nntp - 2.2.12-6.fc4.ppc from fedora-extras-development-ppc unresolved deps: libcrypto.so.5 libssl.so.5 package: perl-Cyrus - 2.2.12-6.fc4.ppc from fedora-extras-development-ppc unresolved deps: libssl.so.5 libcrypto.so.5 ---------------------------------------------------------------------- Report for: markmc AT redhat.com package: sabayon-admin - 2.12.1-2.i386 from fedora-extras-development-i386 unresolved deps: xorg-x11-Xnest package: sabayon-admin - 2.12.1-2.x86_64 from fedora-extras-development-x86_64 unresolved deps: xorg-x11-Xnest package: sabayon-admin - 2.12.1-2.ppc from fedora-extras-development-ppc unresolved deps: xorg-x11-Xnest ---------------------------------------------------------------------- Report for: jeff AT ultimateevil.org package: up-imapproxy - 1.2.4-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libssl.so.5 libcrypto.so.5 package: up-imapproxy - 1.2.4-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libssl.so.5()(64bit) libcrypto.so.5()(64bit) package: up-imapproxy - 1.2.4-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libssl.so.5 libcrypto.so.5 ---------------------------------------------------------------------- Report for: ivazquez AT ivazquez.net package: python-amara - 0.9.4-7.fc4.noarch from fedora-extras-development-i386 unresolved deps: 4Suite >= 0:1.0 package: soundconverter - 0.8.1-2.fc5.noarch from fedora-extras-development-i386 unresolved deps: gstreamer-plugins package: soundconverter - 0.8.1-2.fc5.noarch from fedora-extras-development-x86_64 unresolved deps: gstreamer-plugins package: python-amara - 0.9.4-7.fc4.noarch from fedora-extras-development-x86_64 unresolved deps: 4Suite >= 0:1.0 package: python-amara - 0.9.4-7.fc4.noarch from fedora-extras-development-ppc unresolved deps: 4Suite >= 0:1.0 package: soundconverter - 0.8.1-2.fc5.noarch from fedora-extras-development-ppc unresolved deps: gstreamer-plugins ---------------------------------------------------------------------- Report for: matthias AT rpmforge.net package: proftpd - 1.2.10-6.fc5.i386 from fedora-extras-development-i386 unresolved deps: libssl.so.5 libcrypto.so.5 package: php-mmcache - 5.0.5_2.4.6-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.0.5 package: php-eaccelerator - 5.0.5_0.9.3-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.0.5 package: php-mmcache - 5.0.5_2.4.6-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.0.5 package: php-eaccelerator - 5.0.5_0.9.3-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.0.5 package: proftpd - 1.2.10-6.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcrypto.so.5()(64bit) libssl.so.5()(64bit) package: php-eaccelerator - 5.0.5_0.9.3-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.0.5 package: proftpd - 1.2.10-6.fc5.ppc from fedora-extras-development-ppc unresolved deps: libssl.so.5 libcrypto.so.5 package: php-mmcache - 5.0.5_2.4.6-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.0.5 ---------------------------------------------------------------------- Report for: skvidal AT phy.duke.edu package: seahorse - 0.7.9-1.fc5.i386 from fedora-extras-development-i386 unresolved deps: libpixman.so.1 libcairo.so.1 package: seahorse - 0.7.9-1.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpixman.so.1()(64bit) libcairo.so.1()(64bit) package: seahorse - 0.7.9-1.fc5.ppc from fedora-extras-development-ppc unresolved deps: libpixman.so.1 libcairo.so.1 ---------------------------------------------------------------------- Report for: j.w.r.degoede AT hhs.nl package: libgda-sqlite - 1:1.2.0-8.i386 from fedora-extras-development-i386 unresolved deps: libgda-2.so.3 package: libgda-sqlite - 1:1.2.0-8.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgda-2.so.3()(64bit) package: libgda-sqlite - 1:1.2.0-8.ppc from fedora-extras-development-ppc unresolved deps: libgda-2.so.3 From pertusus at free.fr Wed Feb 8 11:29:51 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 8 Feb 2006 12:29:51 +0100 Subject: where to request package to be added to FE? In-Reply-To: References: Message-ID: <20060208112950.GD2750@free.fr> > I'm curious about why FE doesn't include xCHM or gnochm. Both are I'm interested in packaging xCHM, however I would like to use the latest version which means wxGTK 2.6, and it is only in development, but I don't have a rawhide box. If nobody do it before, I'll certainly package it once FC-5 is released. -- Pat From bugs.michael at gmx.net Wed Feb 8 12:06:21 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 8 Feb 2006 07:06:21 -0500 Subject: Summary - Broken dependencies in Fedora Extras development Message-ID: <200602081206.k18C6LMj002875@mx3.redhat.com> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- apt 0.5.15cnc7-7.fc5.i386 apt-groupinstall 0.5.15cnc7-7.fc5.i386 at-poke 0.2.2-2.i386 cyrus-imapd 2.2.12-6.fc4.i386 cyrus-imapd-murder 2.2.12-6.fc4.i386 cyrus-imapd-nntp 2.2.12-6.fc4.i386 cyrus-imapd-utils 2.2.12-6.fc4.i386 hping2 2.0.0-0.5.rc3.i386 istanbul 0.1.1-5.i386 libgda-sqlite 1:1.2.0-8.i386 libgdamm 1.3.7-2.fc5.i386 ngrep 1.44-4.fc5.i386 octave-forge 2005.06.13-4.fc5.i386 openal-test 0.0-0.4.20040726.i386 p0f 2.0.5-3.i386 pam_mount 0.9.25-4.i386 perl-Cyrus 2.2.12-6.fc4.i386 pgadmin3 1.0.2-5.i386 php-eaccelerator 5.0.5_0.9.3-4.fc5.i386 php-mmcache 5.0.5_2.4.6-7.fc5.i386 proftpd 1.2.10-6.fc5.i386 python-amara 0.9.4-7.fc4.noarch sabayon-admin 2.12.1-2.i386 scalapack 1.7-7.fc4.i386 screem 0.14.1-1.fc5.i386 seahorse 0.7.9-1.fc5.i386 soundconverter 0.8.1-2.fc5.noarch syck-php 0.55-6.fc5.i386 tripwire 2.3.1-22.i386 up-imapproxy 1.2.4-4.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- apt 0.5.15cnc7-7.fc5.ppc apt-groupinstall 0.5.15cnc7-7.fc5.ppc at-poke 0.2.2-2.ppc cyrus-imapd 2.2.12-6.fc4.ppc cyrus-imapd-murder 2.2.12-6.fc4.ppc cyrus-imapd-nntp 2.2.12-6.fc4.ppc cyrus-imapd-utils 2.2.12-6.fc4.ppc hping2 2.0.0-0.5.rc3.ppc istanbul 0.1.1-5.ppc libgda-sqlite 1:1.2.0-8.ppc libgdamm 1.3.7-2.fc5.ppc ngrep 1.44-3.fc5.ppc octave-forge 2005.06.13-4.fc5.ppc openal-test 0.0-0.4.20040726.ppc p0f 2.0.5-3.ppc pam_mount 0.9.25-4.ppc perl-Cyrus 2.2.12-6.fc4.ppc pgadmin3 1.0.2-5.ppc php-eaccelerator 5.0.5_0.9.3-4.fc5.ppc php-mmcache 5.0.5_2.4.6-7.fc5.ppc proftpd 1.2.10-6.fc5.ppc python-amara 0.9.4-7.fc4.noarch sabayon-admin 2.12.1-2.ppc scalapack 1.7-7.fc4.ppc screem 0.14.1-1.fc5.ppc seahorse 0.7.9-1.fc5.ppc soundconverter 0.8.1-2.fc5.noarch syck-php 0.55-6.fc5.ppc up-imapproxy 1.2.4-4.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- at-poke 0.2.2-2.x86_64 cernlib 2005-7.fc5.x86_64 cernlib-packlib 2005-7.fc5.x86_64 cyrus-imapd 2.2.12-6.fc4.x86_64 cyrus-imapd-murder 2.2.12-6.fc4.x86_64 cyrus-imapd-nntp 2.2.12-6.fc4.x86_64 cyrus-imapd-utils 2.2.12-6.fc4.x86_64 hping2 2.0.0-0.5.rc3.x86_64 istanbul 0.1.1-5.x86_64 libgda-sqlite 1:1.2.0-8.x86_64 libgdamm 1.3.7-2.fc5.x86_64 ngrep 1.44-4.fc5.x86_64 octave-forge 2005.06.13-4.fc5.x86_64 openal-test 0.0-0.4.20040726.x86_64 p0f 2.0.5-3.x86_64 pam_mount 0.9.25-4.x86_64 paw 2005-7.fc5.x86_64 perl-Cyrus 2.2.12-6.fc4.x86_64 pgadmin3 1.0.2-5.x86_64 php-eaccelerator 5.0.5_0.9.3-4.fc5.x86_64 php-mmcache 5.0.5_2.4.6-7.fc5.x86_64 proftpd 1.2.10-6.fc5.x86_64 python-amara 0.9.4-7.fc4.noarch sabayon-admin 2.12.1-2.x86_64 scalapack 1.7-7.fc4.x86_64 screem 0.14.1-1.fc5.x86_64 seahorse 0.7.9-1.fc5.x86_64 soundconverter 0.8.1-2.fc5.noarch syck-php 0.55-6.fc5.x86_64 up-imapproxy 1.2.4-4.fc5.x86_64 ---------------------------------------------------------------------- Report for: ghenry AT suretecsystems.com package: pgadmin3 - 1.0.2-5.i386 from fedora-extras-development-i386 unresolved deps: libssl.so.5 libcrypto.so.5 package: pgadmin3 - 1.0.2-5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcrypto.so.5()(64bit) libssl.so.5()(64bit) package: pgadmin3 - 1.0.2-5.ppc from fedora-extras-development-ppc unresolved deps: libssl.so.5 libcrypto.so.5 ---------------------------------------------------------------------- Report for: extras-orphan AT fedoraproject.org package: apt-groupinstall - 0.5.15cnc7-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: comps package: p0f - 2.0.5-3.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.8.3 package: at-poke - 0.2.2-2.i386 from fedora-extras-development-i386 unresolved deps: libpixman.so.1 libcairo.so.1 package: screem - 0.14.1-1.fc5.i386 from fedora-extras-development-i386 unresolved deps: libpixman.so.1 libdbus-1.so.1 libcairo.so.1 libgnome-menu.so.0 libdbus-glib-1.so.1 package: hping2 - 2.0.0-0.5.rc3.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.3 package: apt - 0.5.15cnc7-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libneon.so.24 package: p0f - 2.0.5-3.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.8.3()(64bit) package: screem - 0.14.1-1.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libdbus-glib-1.so.1()(64bit) libpixman.so.1()(64bit) libcairo.so.1()(64bit) libgnome-menu.so.0()(64bit) libdbus-1.so.1()(64bit) package: hping2 - 2.0.0-0.5.rc3.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.3()(64bit) package: at-poke - 0.2.2-2.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpixman.so.1()(64bit) libcairo.so.1()(64bit) package: screem - 0.14.1-1.fc5.ppc from fedora-extras-development-ppc unresolved deps: libpixman.so.1 libdbus-1.so.1 libcairo.so.1 libgnome-menu.so.0 libdbus-glib-1.so.1 package: at-poke - 0.2.2-2.ppc from fedora-extras-development-ppc unresolved deps: libpixman.so.1 libcairo.so.1 package: apt - 0.5.15cnc7-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libneon.so.24 package: p0f - 2.0.5-3.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.8.3 package: apt-groupinstall - 0.5.15cnc7-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: comps package: hping2 - 2.0.0-0.5.rc3.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.3 ---------------------------------------------------------------------- Report for: andreas.bierfert AT lowlatency.de package: openal-test - 0.0-0.4.20040726.i386 from fedora-extras-development-i386 unresolved deps: openal = 0:0.0-0.4.20040726 package: openal-test - 0.0-0.4.20040726.x86_64 from fedora-extras-development-x86_64 unresolved deps: openal = 0:0.0-0.4.20040726 package: openal-test - 0.0-0.4.20040726.ppc from fedora-extras-development-ppc unresolved deps: openal = 0:0.0-0.4.20040726 ---------------------------------------------------------------------- Report for: tripwire-devel AT genesis-x.nildram.co.uk package: tripwire - 2.3.1-22.i386 from fedora-extras-development-i386 unresolved deps: libcrypto.so.5 ---------------------------------------------------------------------- Report for: oliver AT linux-kernel.at package: ngrep - 1.44-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.3 package: syck-php - 0.55-6.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.0.5 package: ngrep - 1.44-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.3()(64bit) package: syck-php - 0.55-6.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.0.5 package: ngrep - 1.44-3.fc5.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.3 package: syck-php - 0.55-6.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.0.5 ---------------------------------------------------------------------- Report for: qspencer AT ieee.org package: octave-forge - 2005.06.13-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgfortran.so.0 libcln.so.3 octave = 6:2.9.3 package: octave-forge - 2005.06.13-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgfortran.so.0()(64bit) libcln.so.3()(64bit) octave = 6:2.9.3 package: octave-forge - 2005.06.13-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgfortran.so.0 libcln.so.3 octave = 6:2.9.3 ---------------------------------------------------------------------- Report for: jspaleta AT gmail.com package: istanbul - 0.1.1-5.i386 from fedora-extras-development-i386 unresolved deps: gstreamer-plugins >= 0:0.8.9 package: istanbul - 0.1.1-5.x86_64 from fedora-extras-development-x86_64 unresolved deps: gstreamer-plugins >= 0:0.8.9 package: istanbul - 0.1.1-5.ppc from fedora-extras-development-ppc unresolved deps: gstreamer-plugins >= 0:0.8.9 ---------------------------------------------------------------------- Report for: redhat AT flyn.org package: pam_mount - 0.9.25-4.i386 from fedora-extras-development-i386 unresolved deps: libcrypto.so.5 libssl.so.5 package: pam_mount - 0.9.25-4.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcrypto.so.5()(64bit) libssl.so.5()(64bit) package: pam_mount - 0.9.25-4.ppc from fedora-extras-development-ppc unresolved deps: libcrypto.so.5 libssl.so.5 ---------------------------------------------------------------------- Report for: pertusus AT free.fr package: paw - 2005-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libXm.so.3()(64bit) package: cernlib - 2005-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libXm.so.3()(64bit) package: cernlib-packlib - 2005-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libXm.so.3()(64bit) ---------------------------------------------------------------------- Report for: tcallawa AT redhat.com package: libgdamm - 1.3.7-2.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgda-2.so.3 package: scalapack - 1.7-7.fc4.i386 from fedora-extras-development-i386 unresolved deps: libgfortran.so.0 package: scalapack - 1.7-7.fc4.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgfortran.so.0()(64bit) package: libgdamm - 1.3.7-2.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgda-2.so.3()(64bit) package: libgdamm - 1.3.7-2.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgda-2.so.3 package: scalapack - 1.7-7.fc4.ppc from fedora-extras-development-ppc unresolved deps: libgfortran.so.0 ---------------------------------------------------------------------- Report for: jdennis AT redhat.com package: cyrus-imapd - 2.2.12-6.fc4.i386 from fedora-extras-development-i386 unresolved deps: libssl.so.5 libcrypto.so.5 package: cyrus-imapd-murder - 2.2.12-6.fc4.i386 from fedora-extras-development-i386 unresolved deps: libssl.so.5 libcrypto.so.5 package: perl-Cyrus - 2.2.12-6.fc4.i386 from fedora-extras-development-i386 unresolved deps: libssl.so.5 libcrypto.so.5 package: cyrus-imapd-nntp - 2.2.12-6.fc4.i386 from fedora-extras-development-i386 unresolved deps: libcrypto.so.5 libssl.so.5 package: cyrus-imapd-utils - 2.2.12-6.fc4.i386 from fedora-extras-development-i386 unresolved deps: libcrypto.so.5 libssl.so.5 package: cyrus-imapd-nntp - 2.2.12-6.fc4.x86_64 from fedora-extras-development-x86_64 unresolved deps: libssl.so.5()(64bit) libcrypto.so.5()(64bit) package: cyrus-imapd-murder - 2.2.12-6.fc4.x86_64 from fedora-extras-development-x86_64 unresolved deps: libssl.so.5()(64bit) libcrypto.so.5()(64bit) package: perl-Cyrus - 2.2.12-6.fc4.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcrypto.so.5()(64bit) libssl.so.5()(64bit) package: cyrus-imapd - 2.2.12-6.fc4.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcrypto.so.5()(64bit) libssl.so.5()(64bit) package: cyrus-imapd-utils - 2.2.12-6.fc4.x86_64 from fedora-extras-development-x86_64 unresolved deps: libssl.so.5()(64bit) libcrypto.so.5()(64bit) package: cyrus-imapd - 2.2.12-6.fc4.ppc from fedora-extras-development-ppc unresolved deps: libssl.so.5 libcrypto.so.5 package: cyrus-imapd-murder - 2.2.12-6.fc4.ppc from fedora-extras-development-ppc unresolved deps: libssl.so.5 libcrypto.so.5 package: cyrus-imapd-utils - 2.2.12-6.fc4.ppc from fedora-extras-development-ppc unresolved deps: libcrypto.so.5 libssl.so.5 package: cyrus-imapd-nntp - 2.2.12-6.fc4.ppc from fedora-extras-development-ppc unresolved deps: libcrypto.so.5 libssl.so.5 package: perl-Cyrus - 2.2.12-6.fc4.ppc from fedora-extras-development-ppc unresolved deps: libssl.so.5 libcrypto.so.5 ---------------------------------------------------------------------- Report for: markmc AT redhat.com package: sabayon-admin - 2.12.1-2.i386 from fedora-extras-development-i386 unresolved deps: xorg-x11-Xnest package: sabayon-admin - 2.12.1-2.x86_64 from fedora-extras-development-x86_64 unresolved deps: xorg-x11-Xnest package: sabayon-admin - 2.12.1-2.ppc from fedora-extras-development-ppc unresolved deps: xorg-x11-Xnest ---------------------------------------------------------------------- Report for: jeff AT ultimateevil.org package: up-imapproxy - 1.2.4-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libssl.so.5 libcrypto.so.5 package: up-imapproxy - 1.2.4-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libssl.so.5()(64bit) libcrypto.so.5()(64bit) package: up-imapproxy - 1.2.4-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libssl.so.5 libcrypto.so.5 ---------------------------------------------------------------------- Report for: ivazquez AT ivazquez.net package: python-amara - 0.9.4-7.fc4.noarch from fedora-extras-development-i386 unresolved deps: 4Suite >= 0:1.0 package: soundconverter - 0.8.1-2.fc5.noarch from fedora-extras-development-i386 unresolved deps: gstreamer-plugins package: soundconverter - 0.8.1-2.fc5.noarch from fedora-extras-development-x86_64 unresolved deps: gstreamer-plugins package: python-amara - 0.9.4-7.fc4.noarch from fedora-extras-development-x86_64 unresolved deps: 4Suite >= 0:1.0 package: python-amara - 0.9.4-7.fc4.noarch from fedora-extras-development-ppc unresolved deps: 4Suite >= 0:1.0 package: soundconverter - 0.8.1-2.fc5.noarch from fedora-extras-development-ppc unresolved deps: gstreamer-plugins ---------------------------------------------------------------------- Report for: matthias AT rpmforge.net package: proftpd - 1.2.10-6.fc5.i386 from fedora-extras-development-i386 unresolved deps: libssl.so.5 libcrypto.so.5 package: php-mmcache - 5.0.5_2.4.6-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.0.5 package: php-eaccelerator - 5.0.5_0.9.3-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.0.5 package: php-mmcache - 5.0.5_2.4.6-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.0.5 package: php-eaccelerator - 5.0.5_0.9.3-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.0.5 package: proftpd - 1.2.10-6.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcrypto.so.5()(64bit) libssl.so.5()(64bit) package: php-eaccelerator - 5.0.5_0.9.3-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.0.5 package: proftpd - 1.2.10-6.fc5.ppc from fedora-extras-development-ppc unresolved deps: libssl.so.5 libcrypto.so.5 package: php-mmcache - 5.0.5_2.4.6-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.0.5 ---------------------------------------------------------------------- Report for: skvidal AT phy.duke.edu package: seahorse - 0.7.9-1.fc5.i386 from fedora-extras-development-i386 unresolved deps: libpixman.so.1 libcairo.so.1 package: seahorse - 0.7.9-1.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpixman.so.1()(64bit) libcairo.so.1()(64bit) package: seahorse - 0.7.9-1.fc5.ppc from fedora-extras-development-ppc unresolved deps: libpixman.so.1 libcairo.so.1 ---------------------------------------------------------------------- Report for: j.w.r.degoede AT hhs.nl package: libgda-sqlite - 1:1.2.0-8.i386 from fedora-extras-development-i386 unresolved deps: libgda-2.so.3 package: libgda-sqlite - 1:1.2.0-8.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgda-2.so.3()(64bit) package: libgda-sqlite - 1:1.2.0-8.ppc from fedora-extras-development-ppc unresolved deps: libgda-2.so.3 From ndbecker2 at gmail.com Wed Feb 8 14:00:51 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 08 Feb 2006 09:00:51 -0500 Subject: strange scribus depends Message-ID: rpm -q --requires scribus claims scribus needs tkinter? From Christian.Iseli at licr.org Wed Feb 8 14:03:06 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 08 Feb 2006 15:03:06 +0100 Subject: Two questions about owners.list file Message-ID: <200602081403.k18E36FC018047@ludwig-alpha.unil.ch> Hi folks, Question 1: there are package entries in the owners.list file which have not yet be approved for FE (e.g., initng, swish-e). My impression is that they should be removed until accepted. Does anybody object that I remove them ? Question 2: there are package entries in the owners.list file where the package is listed twice with different upper/lower case mix (e.g., ginac vs GiNaC). Should the one not corresponding to the actual package name be removed ? Cheers, Christian From jamatos at fc.up.pt Wed Feb 8 14:07:26 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Wed, 8 Feb 2006 14:07:26 +0000 Subject: Two questions about owners.list file In-Reply-To: <200602081403.k18E36FC018047@ludwig-alpha.unil.ch> References: <200602081403.k18E36FC018047@ludwig-alpha.unil.ch> Message-ID: <200602081407.26668.jamatos@fc.up.pt> On Wednesday 08 February 2006 14:03, Christian.Iseli at licr.org wrote: > Hi folks, > > Question 1: there are package entries in the owners.list file which have > not yet be approved for FE (e.g., initng, swish-e). My impression is that > they should be removed until accepted. Does anybody object that I remove > them ? Too eager proponents... :-) That was due to a misinterpretation of the review from the authors, those cases were cleared immediately but meanwhile those entries remained. > Question 2: there are package entries in the owners.list file where the > package is listed twice with different upper/lower case mix (e.g., ginac vs > GiNaC). Should the one not corresponding to the actual package name be > removed ? Package renamed, the lower case version is the current name. > Cheers, > Christian -- Jos? Ab?lio From bugzilla at redhat.com Wed Feb 8 14:07:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 09:07:47 -0500 Subject: [Bug 174368] Review Request: perl-Crypt-DSA In-Reply-To: Message-ID: <200602081407.k18E7l3t025963@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Crypt-DSA https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174368 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From tibbs at math.uh.edu 2006-02-08 09:07 EST ------- > I've just done a test rebuild of the package here, which took just under 5 > minutes (seems reasonable), and it used 100% CPU throughout the test suite. One > possibility is that your build was waiting for some entropy at some point during > the test suite? That is reasonable; the machine is headless and so probably doesn't have much of an entropy source. Approved, but of course you're stuck in the development branch until all of your prerequisites are built. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugs.michael at gmx.net Wed Feb 8 14:29:57 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 8 Feb 2006 15:29:57 +0100 Subject: strange scribus depends In-Reply-To: References: Message-ID: <20060208152957.723a9fc4.bugs.michael@gmx.net> On Wed, 08 Feb 2006 09:00:51 -0500, Neal Becker wrote: > rpm -q --requires scribus claims scribus needs tkinter? If you were a bit more verbose about what you find "strange" about that, that would be helpful. The package changelog mentions that tkinter was added during fedora.us package review. A brief look at Scribus reveals that the FontSampler Python scripting backend uses tkinter. There's even a _missing_ dependency nowadays (this output from FC4): : You need to install Python Imaging Library (PIL). : If using gentoo then you need to emerge /dev-python/imaging : If using an RPM based linux distribution then you add python-imaging or similar. : Script will continue without the font preview panel. : Module ImageTk not found, font preview disabled It's missing "Requires: python-imaging" indeed. From bugs.michael at gmx.net Wed Feb 8 14:38:58 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 8 Feb 2006 15:38:58 +0100 Subject: What is the proper way to fix 'make tag' and 'make plague' conflict In-Reply-To: <43E7C661.5000509@lowlatency.de> References: <1139262784.29100.4.camel@bobcat.mine.nu> <43E7C661.5000509@lowlatency.de> Message-ID: <20060208153858.3309657d.bugs.michael@gmx.net> On Mon, 06 Feb 2006 22:57:53 +0100, Andreas Bierfert wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ville Skytt? wrote: > > IMNSHO bumping the release is the best available fix and force-tagging > > is much uglier. > > Hm, not that you need to but I really would like to know why you think that... > :) just curious... Because force-tagging bears the risk of breaking something in even less expected ways. Some of the solutions suggested in this thread are dangerous. Paul Howarth wrote: > The "cvs tag -F" is equivalent to "make tag TAG_OPTS=-F"; No, it isn't. The latter determines the tag automatically (!). For the former you need to specify the tag yourself. That is dangerous, because you can move an arbitrary existing tag you don't want to move. You can even break other people's packages in CVS that way. So, everyone, please don't play with this. From bugzilla at redhat.com Wed Feb 8 14:41:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 09:41:16 -0500 Subject: [Bug 174368] Review Request: perl-Crypt-DSA In-Reply-To: Message-ID: <200602081441.k18EfGYl031886@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Crypt-DSA https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174368 ------- Additional Comments From paul at city-fan.org 2006-02-08 09:41 EST ------- Build on target fedora-development-extras succeeded. Will wait for perl-Convert-PEM to appear in the FC4 repo now. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugs.michael at gmx.net Wed Feb 8 14:52:37 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 8 Feb 2006 15:52:37 +0100 Subject: FE package status Tue Feb 7 2006 In-Reply-To: <200602071718.k17HI7fL011115@ludwig-alpha.unil.ch> References: <200602071718.k17HI7fL011115@ludwig-alpha.unil.ch> Message-ID: <20060208155237.53dd13ea.bugs.michael@gmx.net> On Tue, 07 Feb 2006 18:18:07 +0100, Christian.Iseli at licr.org wrote: > We have 58 packages not available in extras devel or release: > k3b-ape mihai Not available due to licensing issues. > libgcrypt1 bugs.michael > newpg ville.skytta Only used/needed in older releases. From bugzilla at redhat.com Wed Feb 8 14:49:24 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 09:49:24 -0500 Subject: [Bug 177107] Review Request: libgeda - library for gEDA circuit design software In-Reply-To: Message-ID: <200602081449.k18EnOgZ000688@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libgeda - library for gEDA circuit design software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177107 ------- Additional Comments From wk at ire.pw.edu.pl 2006-02-08 09:49 EST ------- There is new release of libgeda available. Specfile: http://www.sp5pbe.waw.pl/~sp5smk/fedora-extras/specs2/libgeda.spec Source RPM: http://www.sp5pbe.waw.pl/~sp5smk/libgeda-20060123-1.fc4.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 14:51:38 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 09:51:38 -0500 Subject: [Bug 177108] Review Request: geda-gschem - schematic editor for gEDA circuit design software In-Reply-To: Message-ID: <200602081451.k18Epcgp001002@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: geda-gschem - schematic editor for gEDA circuit design software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177108 ------- Additional Comments From wk at ire.pw.edu.pl 2006-02-08 09:51 EST ------- There is new release of geda-gschem available. Specfile: http://www.sp5pbe.waw.pl/~sp5smk/fedora-extras/specs2/geda-gschem.spec Source RPM: http://www.sp5pbe.waw.pl/~sp5smk/geda-gschem-20060123-1.fc4.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 14:53:22 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 09:53:22 -0500 Subject: [Bug 177109] Review Request: geda-symbols - symbol repository for gEDA circuit design software In-Reply-To: Message-ID: <200602081453.k18ErMsJ001163@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: geda-symbols - symbol repository for gEDA circuit design software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177109 wk at ire.pw.edu.pl changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: geda-sybols |Review Request: geda-symbols |- symbol repository for gEDA|- symbol repository for gEDA |circuit design software |circuit design software ------- Additional Comments From wk at ire.pw.edu.pl 2006-02-08 09:53 EST ------- There is new release of geda-symbols available. Specfile: http://www.sp5pbe.waw.pl/~sp5smk/fedora-extras/specs2/geda-symbols.spec Source RPM: http://www.sp5pbe.waw.pl/~sp5smk/geda-symbols-20060123-1.fc4.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 14:54:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 09:54:21 -0500 Subject: [Bug 177110] Review Request: geda-gsymcheck - symbol checker for gEDA circuit design software In-Reply-To: Message-ID: <200602081454.k18EsLst001341@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: geda-gsymcheck - symbol checker for gEDA circuit design software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177110 ------- Additional Comments From wk at ire.pw.edu.pl 2006-02-08 09:54 EST ------- There is new release of geda-gschem available. Specfile: http://www.sp5pbe.waw.pl/~sp5smk/fedora-extras/specs2/geda-gsymcheck.spec Source RPM: http://www.sp5pbe.waw.pl/~sp5smk/geda-gsymcheck-20060123-1.fc4.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 14:55:31 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 09:55:31 -0500 Subject: [Bug 177113] Review Request: geda-gnetlist - netlist generator for gEDA circuit design software In-Reply-To: Message-ID: <200602081455.k18EtVGV001555@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: geda-gnetlist - netlist generator for gEDA circuit design software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177113 ------- Additional Comments From wk at ire.pw.edu.pl 2006-02-08 09:55 EST ------- There is new release of geda-gnetlist available. Specfile: http://www.sp5pbe.waw.pl/~sp5smk/fedora-extras/specs2/geda-gnetlist.spec Source RPM: http://www.sp5pbe.waw.pl/~sp5smk/geda-gnetlist-20060123-1.fc4.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From Christian.Iseli at licr.org Wed Feb 8 15:01:19 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 08 Feb 2006 16:01:19 +0100 Subject: FE package status Tue Feb 7 2006 In-Reply-To: Your message of "Wed, 08 Feb 2006 15:52:37 +0100." <20060208155237.53dd13ea.bugs.michael@gmx.net> Message-ID: <200602081501.k18F1Jqr018898@ludwig-alpha.unil.ch> Folks, I have started a new wiki page to list those retired/migrated packages that my script cannot reliably track: http://fedoraproject.org/wiki/Extras/PackagesNoLongerInDevel I'll use those lists when I analyze the owners.list file. Please feel free to edit/improve the page, or just drop me an email... Cheers, Christian From bugzilla at redhat.com Wed Feb 8 14:57:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 09:57:56 -0500 Subject: [Bug 177413] geda-gattrib - attribute editor for gEDA project In-Reply-To: Message-ID: <200602081457.k18EvuKV001861@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: geda-gattrib - attribute editor for gEDA project https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177413 ------- Additional Comments From wk at ire.pw.edu.pl 2006-02-08 09:57 EST ------- There is new release of geda-gattrib available. Specfile: http://www.sp5pbe.waw.pl/~sp5smk/fedora-extras/specs2/geda-gattrib.spec Source RPM: http://www.sp5pbe.waw.pl/~sp5smk/geda-gattrib-20060123-1.fc4.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 15:00:14 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 10:00:14 -0500 Subject: [Bug 177414] Review Request: geda - project manager for gEDA project In-Reply-To: Message-ID: <200602081500.k18F0EiW002378@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: geda - project manager for gEDA project https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177414 wk at ire.pw.edu.pl changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|geda - project manager for |Review Request: geda - |gEDA project |project manager for gEDA | |project ------- Additional Comments From wk at ire.pw.edu.pl 2006-02-08 10:00 EST ------- There is new release of geda available. Specfile: http://www.sp5pbe.waw.pl/~sp5smk/fedora-extras/specs2/geda.spec Source RPM: http://www.sp5pbe.waw.pl/~sp5smk/geda-20060123-1.fc4.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 15:01:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 10:01:20 -0500 Subject: [Bug 177415] Review Request: geda-docs - documentation for gEDA project In-Reply-To: Message-ID: <200602081501.k18F1KfB002685@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: geda-docs - documentation for gEDA project https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177415 wk at ire.pw.edu.pl changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|geda-docs - documentation |Review Request: geda-docs - |for gEDA project |documentation for gEDA | |project ------- Additional Comments From wk at ire.pw.edu.pl 2006-02-08 10:01 EST ------- There is new release of geda-docs available. Specfile: http://www.sp5pbe.waw.pl/~sp5smk/fedora-extras/specs2/geda-docs.spec Source RPM: http://www.sp5pbe.waw.pl/~sp5smk/geda-docs-20060123-1.fc4.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 15:02:37 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 10:02:37 -0500 Subject: [Bug 177416] Review Request: geda-examples - some examples for gEDA project In-Reply-To: Message-ID: <200602081502.k18F2b99002989@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: geda-examples - some examples for gEDA project https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177416 wk at ire.pw.edu.pl changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|geda-examples - some |Review Request: geda- |examples for gEDA project |examples - some examples for | |gEDA project ------- Additional Comments From wk at ire.pw.edu.pl 2006-02-08 10:02 EST ------- There is new release of geda-examples available. Specfile: http://www.sp5pbe.waw.pl/~sp5smk/fedora-extras/specs2/geda-examples.spec Source RPM: http://www.sp5pbe.waw.pl/~sp5smk/geda-examples-20060123-1.fc4.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 15:19:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 10:19:35 -0500 Subject: [Bug 177106] Review Request: libgdgeda - graphical library for gEDA In-Reply-To: Message-ID: <200602081519.k18FJZ9V006281@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libgdgeda - graphical library for gEDA https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177106 ------- Additional Comments From rc040203 at freenet.de 2006-02-08 10:19 EST ------- Some proposals on your spec files: 1. The *-devel package provides *.pc files. Therefore I'd propose to let it Requires: pkgconfig 2. Why not simply use %{_includedir}/gdgeda, instead of: %files devel %dir %{_includedir}/gdgeda [..] %{_includedir}/gdgeda/* 3. I'd strongly recommend not to ship the static libs. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 15:24:51 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 10:24:51 -0500 Subject: [Bug 177107] Review Request: libgeda - library for gEDA circuit design software In-Reply-To: Message-ID: <200602081524.k18FOpGr007296@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libgeda - library for gEDA circuit design software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177107 ------- Additional Comments From rc040203 at freenet.de 2006-02-08 10:24 EST ------- Some remarks on your spec file (without having built it): 1. Missing requirements: Requires(post): /sbin/ldconfig Requires(post): /sbin/install-info Requires(preun): /sbin/install-info 2. IIRC, due to an issue in rpm, the %post, %preun etc. sections must be separated by blank lines, otherwise rpm will concatenate then into one section. 3. The same remarks as on you libgdeda specs also apply here (pkgconfig, includedir, static libs). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 15:30:29 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 10:30:29 -0500 Subject: [Bug 175748] Review Request: cacti In-Reply-To: Message-ID: <200602081530.k18FUThq008403@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cacti https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175748 imlinux at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From imlinux at gmail.com 2006-02-08 10:30 EST ------- I've created an SELinux bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180482 Also cacti is now available in devel. (Soon FC3 and FC4) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bdpepple at ameritech.net Wed Feb 8 15:50:35 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Wed, 08 Feb 2006 10:50:35 -0500 Subject: libnotify in gnomebaker In-Reply-To: <1139364160.3727.12.camel@cosima.et.endace.com> References: <1139362651.3727.10.camel@cosima.et.endace.com> <1139364160.3727.12.camel@cosima.et.endace.com> Message-ID: <1139413835.2811.2.camel@shuttle.273piedmont.org> On Wed, 2006-02-08 at 15:02 +1300, Michael J Knox wrote: > Is there any reason why libnotify support is missing in gnomebaker? > > Michael Because maybe that support wasn't released in 0.5.1? Look at the tarball. Not to mention that it's fairly worthless from what I've seen so far. /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 andreas.bierfert at lowlatency.de Wed Feb 8 15:59:57 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Wed, 08 Feb 2006 16:59:57 +0100 Subject: What is the proper way to fix 'make tag' and 'make plague' conflict In-Reply-To: <20060208153858.3309657d.bugs.michael@gmx.net> References: <1139262784.29100.4.camel@bobcat.mine.nu> <43E7C661.5000509@lowlatency.de> <20060208153858.3309657d.bugs.michael@gmx.net> Message-ID: <43EA157D.5090206@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > So, everyone, please don't play with this. I agree with you but that just pops up the issue again why 'make tag' does not check if the cvs repo is up to date. If I remember correctly someone was going to implement that? - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFD6hV9QEQyPsWM8csRAgPMAJ9p3WJshSmpSuwpMSqg+dBlEDpNWgCgjYd1 4aLscK7hUdun92/7B47+gHw= =mCgv -----END PGP SIGNATURE----- From andreas.bierfert at lowlatency.de Wed Feb 8 16:52:19 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Wed, 08 Feb 2006 17:52:19 +0100 Subject: strange scribus depends In-Reply-To: <20060208152957.723a9fc4.bugs.michael@gmx.net> References: <20060208152957.723a9fc4.bugs.michael@gmx.net> Message-ID: <43EA21C3.5060405@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > It's missing "Requires: python-imaging" indeed. Thanks... Fixed in cvs and building... - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFD6iHDQEQyPsWM8csRAtjkAJ9crcyCF89uG7sz6CSxBQSsyp9QEACfZABs zgvK/99ZYAr7ZdDaj7gERiw= =b7Vc -----END PGP SIGNATURE----- From bugzilla at redhat.com Wed Feb 8 17:02:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 12:02:36 -0500 Subject: [Bug 168607] Review Request: perl-Convert-PEM In-Reply-To: Message-ID: <200602081702.k18H2aP9024804@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Convert-PEM https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168607 ------- Additional Comments From steve at silug.org 2006-02-08 12:02 EST ------- I've been trying... http://buildsys.fedoraproject.org/build-status/job.psp?uid=3816 I wonder if hammer2 is having issues. I had another build fail on it yesterday that worked fine on my x86_64 system under mock. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From petro at mail.ru Wed Feb 8 16:08:18 2006 From: petro at mail.ru (Peter Lemenkov) Date: Wed, 8 Feb 2006 19:08:18 +0300 Subject: where to request package to be added to FE? In-Reply-To: <20060208112950.GD2750@free.fr> References: <20060208112950.GD2750@free.fr> Message-ID: On Wed, 8 Feb 2006, Patrice Dumas wrote: >> I'm curious about why FE doesn't include xCHM or gnochm. Both are > I'm interested in packaging xCHM, however I would like to use the latest > version which means wxGTK 2.6, and it is only in development, but I don't > have a rawhide box. If nobody do it before, I'll certainly package it > once FC-5 is released. I packaged it already for myself, for Rawhide-box, so you may find it useful to look at the: Summary: A GUI front-end to CHMlib Name: xchm Version: 1.2 Release: 1 License: GPL Group: Applications/Publishing Source: http://dl.sf.net/%{name}/%{name}-%{version}.tar.gz URL: http://xchm.sourceforge.net/ BuildRequires: chmlib-devel BuildRequires: wxGTK-devel BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) %description xCHM is a wxWidgets-based .chm viewer. xCHM can show the contents tree if one is available, print the displayed page, change fonts faces and size, work with bookmarks, do the usual history stunts (forward, back, home), provide a searchable index and seach for text in the whole book. The search is a fast B-tree search, based on the internal $FIftiMain file found inside indexed .chm archives, and it can be customized to search in content or just the topics' titles. %prep %setup -q %build %configure --enable-optimize %{__make} %{?_smp_mflags} %install %{__rm} -rf %{buildroot} %makeinstall %clean %{__rm} -rf %{buildroot} %files %defattr(-, root, root) %doc AUTHORS COPYING ChangeLog README %{_bindir}/xchm %{_datadir}/pixmaps/*.xpm %{_datadir}/locale/*/LC_MESSAGES/xchm.mo %changelog * Mon Dec 05 2005 Peter Lemenkov 1.2-1 - Version 1.2-1 * Mon Mar 21 2005 Nick Soracco - Initial RPM release. Complementing the faderbox.org package. -- With best regards, Peter Lemenkov. From bugzilla at redhat.com Wed Feb 8 17:06:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 12:06:16 -0500 Subject: [Bug 168607] Review Request: perl-Convert-PEM In-Reply-To: Message-ID: <200602081706.k18H6GLi025687@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Convert-PEM https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168607 ------- Additional Comments From steve at silug.org 2006-02-08 12:06 EST ------- Scratch that. My other mystery failed build yesterday died on hammer3. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 17:28:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 12:28:20 -0500 Subject: [Bug 178310] Review Request: w3c-libwww - An HTTP library of common code In-Reply-To: Message-ID: <200602081728.k18HSKEi031613@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: w3c-libwww - An HTTP library of common code https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178310 ------- Additional Comments From andreas.bierfert at lowlatency.de 2006-02-08 12:28 EST ------- Ok I have a new release here: 1) it is based of current cvs 2) it builds without the included expat lib and links against the system expat I have not tried however to compile any programs against this so we will see if all works out or not... =) http://fedora.lowlatency.de/review/w3c-libwww-5.4.1-0.1.20060206cvs.src.rpm http://fedora.lowlatency.de/review/w3c-libwww.spec -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From gajownik at fedora.pl Wed Feb 8 17:41:00 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Wed, 08 Feb 2006 18:41:00 +0100 Subject: where to request package to be added to FE? In-Reply-To: References: <20060208112950.GD2750@free.fr> Message-ID: <43EA2D2C.8080700@fedora.pl> Dnia 02/08/2006 06:11 PM, U?ytkownik Peter Lemenkov napisa?: > %{_datadir}/locale/*/LC_MESSAGES/xchm.mo You should use %find_lang macro. I would also add xchm.desktop file :) -- ^_* From buildsys at fedoraproject.org Wed Feb 8 17:54:23 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 8 Feb 2006 12:54:23 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060208175423.2B3B6800B@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 2 cacti-0.8.6h-4.fc3 scribus-1.2.4.1-2.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed Feb 8 17:54:40 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 8 Feb 2006 12:54:40 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060208175440.343D6800B@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 12 cacti-0.8.6h-4.fc4 digikam-0.8.1-2.fc4 fwbuilder-2.0.10-2.fc4 gnome-applet-sensors-1.4-3.fc4 perl-Font-TTF-0.37-3.fc4 perl-Math-GMP-2.04-2.fc4 perl-Tie-EncryptedHash-1.21-1.fc4 scribus-1.2.4.1-3.fc4 smb4k-0.6.7-1.fc4 xpilot-ng-4.7.2-4.fc4 yumex-0.44-3.0.fc4 yumex-0.44-4.0.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed Feb 8 17:55:08 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 8 Feb 2006 12:55:08 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060208175508.D85E9800B@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 30 Gtk-Perl-0.7008-39.fc5 advancecomp-1.15-3.fc5 bash-completion-20050721-4.fc5 bbkeys-0.9.0-3.fc5 blackbox-0.70.1-3.fc5 boa-0.94.14-0.3.rc21.fc5 camE-1.9-5.fc5 csmash-0.6.6-11.fc5 digikam-0.8.1-2.fc5 diradmin-1.7.1-3.fc5 easytag-1.1-2.fc5 fillets-ng-0.7.3-2.fc5 fwbuilder-2.0.10-2.fc5 galculator-1.2.5-3.fc5 gcombust-0.1.55-7 gentoo-0.11.55-2.fc5 giblib-1.2.4-5.fc5 gkrellm-aclock-0.3.3-3.fc5 gkrellm-freq-1.0-1.fc5 hping2-2.0.0-0.6.rc3 lighttpd-1.4.10-1.fc5 linphone-1.2.0-3.fc5 nuttcp-5.1.11-5 perl-Crypt-DSA-0.13-1.fc5 perl-Tie-EncryptedHash-1.21-1.fc5 rssowl-1.2-10.fc5 sblim-cmpi-base-1.5.4-3.fc5 scribus-1.2.4.1-3.fc5 smb4k-0.6.7-1.fc5 wp_tray-0.5.1-1.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Wed Feb 8 18:10:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 13:10:10 -0500 Subject: [Bug 180422] Review Request: gnome-mud In-Reply-To: Message-ID: <200602081810.k18IAAKN006523@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-mud https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180422 ------- Additional Comments From wart at kobold.org 2006-02-08 13:10 EST ------- Package doesn't build for me as a non-root user in a non-mock environment. It looks like there is an invocation of scrollkeeper in one of the Makefiles that doesn't obey $(DESTDIR): mkdir -p -- /var/tmp/gnome-mud-0.10.7-2-root-rpmbuild/usr/share/omf/gnome-mud for file in ./*.omf; do \ /usr/bin/install -c -m 644 ./$file /var/tmp/gnome-mud-0.10.7-2-root-rpmbuild/usr/share/omf/gnome-mud; \ done scrollkeeper-update -p /var/scrollkeeper Could not create directory /var/scrollkeeper : Permission denied -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 8 18:25:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 13:25:20 -0500 Subject: [Bug 180422] Review Request: gnome-mud In-Reply-To: Message-ID: <200602081825.k18IPKYn009398@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-mud https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180422 frank at scirocco-5v-turbo.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |frank at scirocco-5v-turbo.de ------- Additional Comments From frank at scirocco-5v-turbo.de 2006-02-08 13:25 EST ------- (In reply to comment #2) > Package doesn't build for me as a non-root user in a non-mock environment. It > looks like there is an invocation of scrollkeeper in one of the Makefiles that > doesn't obey $(DESTDIR): gnome-mud uses gnome-doc-utils for building the help files. Adding the configure flag --disable-scrollkeeper should fix it. I wonder if gnome-doc-utils should be added as BR... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 8 18:35:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 13:35:16 -0500 Subject: [Bug 180422] Review Request: gnome-mud In-Reply-To: Message-ID: <200602081835.k18IZGYP011194@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-mud https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180422 ------- Additional Comments From frank at scirocco-5v-turbo.de 2006-02-08 13:35 EST ------- Sorry, forgot to mention it: scrollkeeper-update is needed in %post and %postun Basically like documented in the Wiki, but without 'BuildRequires: scrollkeeper': http://fedoraproject.org/wiki/ScriptletSnippets#head-3c9f517f0cd4aaabb369a8805226d85dc2f02793 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 8 19:21:40 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 14:21:40 -0500 Subject: [Bug 176205] Review Request: GZLauncher In-Reply-To: Message-ID: <200602081921.k18JLeL9019478@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: GZLauncher https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176205 ------- Additional Comments From mwoodj at knology.net 2006-02-08 14:21 EST ------- Thank you for submitting a bug report for my gzlauncher project. I also appreciate the testing that is taking place in your attempt to approve the software. I need to note a few things about the current state of gzlauncher. 1) Due to DoS attacks on the gzlauncher master server the gzlauncher developers decided that with the latest release of zdaemon they would close the launcher protocol. The developers would allow me access to the launcher protocol if it weren't for the open nature of my launcher. As I will not close-source my software this means that gzlauncher is currently unable to contact the zdaemon master servers. In the event that someone decides to do a branch off the most recent open-source version of Zdaemon and use an open launcher protocol I will support that project with gzlauncher. In the event that Zdaemon decides to open the launcher protocol at some point I will support that project again as well. 2) GZLauncher was developed rather quickly due to a sudden demand for a decent Linux launcher. I exclusively use Linux and when I decided I wanted a launcher other users expressed their desire for one. So, I decided to build GZLauncher and I cranked it out as quickly as possible. Their are very likely some bugs including the one that has been reported to me. There is probably memory allocated but never freed, etc, etc. When the opportunity arises to continue GZLauncher developent (when the protocol is again open) I plan on doing a full re-write of the application. This will include changing to the use of libglade as opposed to using glade produced code for the interface. I will also develop it more cleanly which will hopefully mean less bugs. I also have many ideas for features including adding buddly list and an irc client to connect to the zdaemon player chat as the windows launcher does. Basically, in my opinion, this software is not in a state to be included in any packages particularly since it is useless as long as the Zdaemon launcher protocol remains closed. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From triad at df.lth.se Wed Feb 8 19:35:57 2006 From: triad at df.lth.se (Linus Walleij) Date: Wed, 8 Feb 2006 20:35:57 +0100 (CET) Subject: inotify in FC5? Message-ID: A quick, interesting question to those running the test versions: is inotify (/dev/inotify) default enabled in the FC5 stock kernel? Linus From dlutter at redhat.com Wed Feb 8 19:49:20 2006 From: dlutter at redhat.com (David Lutterkort) Date: Wed, 08 Feb 2006 11:49:20 -0800 Subject: inotify in FC5? In-Reply-To: References: Message-ID: <1139428160.3865.15.camel@currant.watzmann.net> On Wed, 2006-02-08 at 20:35 +0100, Linus Walleij wrote: > A quick, interesting question to those running the test versions: is > inotify (/dev/inotify) default enabled in the FC5 stock kernel? The kernel headers for inotify have been missing for a while, but should be there in the latest rawhide (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179366) See also this discussion on fedora-devel: https://www.redhat.com/archives/fedora-devel-list/2006-January/msg01362.html David From davej at redhat.com Wed Feb 8 20:01:13 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 8 Feb 2006 15:01:13 -0500 Subject: inotify in FC5? In-Reply-To: References: Message-ID: <20060208200113.GA11105@redhat.com> On Wed, Feb 08, 2006 at 08:35:57PM +0100, Linus Walleij wrote: > A quick, interesting question to those running the test versions: is > inotify (/dev/inotify) default enabled in the FC5 stock kernel? The /dev/inotify interface never made it upstream. It uses syscalls now. Dave From bugzilla at redhat.com Wed Feb 8 20:17:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 15:17:34 -0500 Subject: [Bug 176137] Review Request: perl-Log-Log4perl - Log4j implementation for Perl In-Reply-To: Message-ID: <200602082017.k18KHYJB029970@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Log-Log4perl - Log4j implementation for Perl https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176137 jpo at di.uminho.pt changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn|171640 | ------- Additional Comments From jpo at di.uminho.pt 2006-02-08 15:17 EST ------- http://gsd.di.uminho.pt/jpo/software/fedora/perl-Log-Log4perl-1.03-1.src.rpm Changelog * Update to version 1.03 * Using the sourceforge URIs (version 1.03 still hasn't been uploaded into CPAN; it has been released at least three days ago in sourceforge) * Disabled the Log::Dispatch::FileRotate requirement and build requirement (disabled the #171640 dependency) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 20:40:37 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 15:40:37 -0500 Subject: [Bug 180532] New: Review Request: perl-UNIVERSAL-can Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180532 Summary: Review Request: perl-UNIVERSAL-can Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: jpo at di.uminho.pt QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://gsd.di.uminho.pt/jpo/software/fedora/perl-UNIVERSAL-can.spec SRPM Name or Url: http://gsd.di.uminho.pt/jpo/software/fedora/perl-UNIVERSAL-can-1.03-1.src.rpm Description: The UNIVERSAL class provides a few default methods so that all objects can use them. Object orientation allows programmers to override these methods in subclasses to provide more specific and appropriate behavior. Some authors call methods in the UNIVERSAL class on potential invocants as functions, bypassing any possible overriding. This is wrong and you should not do it. Unfortunately, not everyone heeds this warning and their bad code can break your good code. Note: This a new requirement of perl-Test-MockObject (which is tagged for an update) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 8 20:55:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 15:55:01 -0500 Subject: [Bug 175237] Review Request: bzr - bazaar-ng distributed revision control system In-Reply-To: Message-ID: <200602082055.k18Kt1eS006012@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: bzr - bazaar-ng distributed revision control system https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175237 ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-08 15:54 EST ------- Shahms, I noticed that version 0.7 is out, are you going to update/get this into FE? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 21:14:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 16:14:49 -0500 Subject: [Bug 180532] Review Request: perl-UNIVERSAL-can In-Reply-To: Message-ID: <200602082114.k18LEniI009314@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-UNIVERSAL-can https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180532 ------- Additional Comments From tibbs at math.uh.edu 2006-02-08 16:14 EST ------- This package has BuildRequires: perl(Test::Simple) >= 0.60, which I can't satisfy on FC4. I suppose this is a perl 5.8.8 thing, which means that this package will never build on FC4. After commenting out the above BuildRequires: line, I find an unsatisfied dependency on Perl(Test::Exception), which I can fulfill from extras. I'll set up a mock build so I can test this with the current development release. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 8 21:55:25 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 16:55:25 -0500 Subject: [Bug 175237] Review Request: bzr - bazaar-ng distributed revision control system In-Reply-To: Message-ID: <200602082155.k18LtPaF017384@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: bzr - bazaar-ng distributed revision control system https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175237 ------- Additional Comments From shahms at shahms.com 2006-02-08 16:55 EST ------- Yeah, getting bzr into FE is high on my TODO list, but I've been swamped with work and school, leaving little time for much else. Barring unforeseen events, I should have it updated and into FE by this weekend. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 8 22:38:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 17:38:36 -0500 Subject: [Bug 170303] Review Request: google-perftools: Very fast malloc & performance analysis tools In-Reply-To: Message-ID: <200602082238.k18McamM025779@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: google-perftools: Very fast malloc & performance analysis tools https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170303 ------- Additional Comments From csilvers2000 at yahoo.com 2006-02-08 17:38 EST ------- Another note from an 'upstream' person: thanks for filing the heap-checker_unittest failure on sourceforge. I'll be following up with it there. As to the other bugs reported on this page, I tried compiling google-perftools-0.6 on a standard FC3 machine and could not reproduce the problems reported. The code compiled straight out of the box, and pprof did not give any syntax errors or warnings. If you do not see the same, please file bug reports on sourceforge with details of how to reproduce the error, and we'll look into fixing them. craig -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From orion at cora.nwra.com Wed Feb 8 22:55:32 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 08 Feb 2006 15:55:32 -0700 Subject: Please help comment on hdf/netcdf compatability In-Reply-To: <1139001075.15027.344.camel@ernie> References: <43E3C33D.3030403@cora.nwra.com> <1139001075.15027.344.camel@ernie> Message-ID: <43EA76E4.6030706@cora.nwra.com> Ed Hill wrote: > On Fri, 2006-02-03 at 13:55 -0700, Orion Poplawski wrote: >> I maintain hdf 4.2r1 in FE. I'm running into an issue with >> compatibility with netcdf. By default, hdf provides the netcdf api as >> well, unless compiled with -DHAVE_NETCDF. >> >> I also maintain gdl, which can be linked against both hdf and netcdf, >> but I get complaints. I don't know if gdl can use the netcdf API in the >> hdf library or not - looking into it (if you know, tell me!). >> >> Those of you who use both, what would you like to see? > > Hi Orion, > > I don't have an opinion here since I rarely use hdf4 and have yet to try > gdl (although it sounds cool and useful--just haven't had enough spare > time to examine it!). In any case, if there is anything that I can do > to help (eg. with the netcdf package) please let me know. > > Ed > After looking at the GDL docs some more, it looks like I'm going to need to compile HDF with -DHAVE_NETCDF in order for GDL to link to both netcdf and hdf. Hopefully this won't cause other problems. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From bugzilla at redhat.com Wed Feb 8 23:43:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 18:43:56 -0500 Subject: [Bug 180422] Review Request: gnome-mud In-Reply-To: Message-ID: <200602082343.k18NhuMq004460@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-mud https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180422 ------- Additional Comments From sysadmin at tacticalbusinesspartners.com 2006-02-08 18:43 EST ------- Fixed all above. Added gnome-doc-utils as BR, just in case. Spec file is the same, SRPM is: http://m2g04.tunegenie.com/~hlb/Personal/gnome-mud-0.10.7-3.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From sdl.web at gmail.com Thu Feb 9 00:00:43 2006 From: sdl.web at gmail.com (leon) Date: Thu, 09 Feb 2006 00:00:43 +0000 Subject: where to request package to be added to FE? References: <20060208112950.GD2750@free.fr> Message-ID: Patrice Dumas writes: | > I'm curious about why FE doesn't include xCHM or gnochm. Both are | | I'm interested in packaging xCHM, however I would like to use the latest | version which means wxGTK 2.6, and it is only in development, but I don't | have a rawhide box. If nobody do it before, I'll certainly package it | once FC-5 is released. | No wonder nobody package xCHM yet. wxGTK is stable enough and would be great if we can have it for FC5. I definitely would be looking forward to your xCHM package. -- Leon From bugzilla at redhat.com Thu Feb 9 00:04:25 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 19:04:25 -0500 Subject: [Bug 180422] Review Request: gnome-mud In-Reply-To: Message-ID: <200602090004.k1904PxT007360@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-mud https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180422 ------- Additional Comments From bdpepple at ameritech.net 2006-02-08 19:04 EST ------- Some thing that you need to fix: 1. There's a couple of unnecessary BR, such as vte, libglade2. 2. Drop the requires on gtk2. Your BR should pull this in automatically. 3. You need to use macros in your file section (and also when you modify the desktop file). Refer to the wiki for the specific macros. 4. Run rpmlint on your rpm. I'm guessing that it will give a few error that need to fix (just by looking at your spec I'd say that some of the lines in the description are to long). 5. In the files section, /usr/share/* (which should be %{_datadir}, BTW) should be changed, using a wildcard to pull child directories could cause ownership problems. 6. The desktop file looks to be wrong in the files section, since your adding a vendor. The file should be fedora-gnome-mud.desktop. I'm guessing your packing the wrong desktop file, since your not deleting the original. You should give the wiki another read-over, since most of the issues are addressed there. Before someone will sponser you, you've got to demonstate a good understanding of Fedora Extras package process and requirements. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From kevin-fedora-extras at scrye.com Thu Feb 9 00:14:32 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Wed, 08 Feb 2006 17:14:32 -0700 (MST) Subject: RFC: automated broken deps reports References: <20060208124712.59cfeaf4.bugs.michael@gmx.net> Message-ID: <20060208.171432.144930893.kevin@scrye.com> >>>>> "Michael" == Michael Schwendt writes: Michael> As discussed briefly in the last meeting of FESCO, there are Michael> a few open questions with regard to running a script that Michael> does automated checking of broken dependencies in Fedora Michael> Extras: Michael> * How often to run it? Michael> Daily? After every push of new builds for Fedora Extras? If I think it would be most usefull after each push of new builds. Michael> Rawhide breaks something how do we become aware of that in Michael> time? That is, do we know exactly when new packages are Michael> pushed in Rawhide so the script would not run before that? Michael> Does it matter? The next run a day later would catch broken Michael> deps. Do we, at Fedora Extras, have big interest in knowing Michael> quickly when changes in Rawhide break anything in Extras? Michael> Reports of broken packages are not worthwhile if rebuilds or Michael> fixes won't happen until packagers track and "support" Michael> Rawhide or unless a special team at Fedora Extras takes over Michael> doing the rebuilds for devel. Michael> * Whether to mail a summary of all broken dependencies to Michael> fedora-extras-list? I think we should. This would allow people to comment and see how the list of packages as a whole are doing. Michael> So far, during the few public test-runs, a packager received Michael> a summary of all broken dependencies for all his broken Michael> packages in a single mail. What format should a complete Michael> summary, which is posted to fedora-extras-list, have, so it Michael> would be useful and readable? Maybe Michael> package name version repository e-mail or srcrpm name Michael> repository e-mail or package name version Michael> sorted by name or sorted by e-mail and grouped by arch? With Michael> the full summary at the bottom? Ideas? The complete list of How about listed twice: First set is: package name version repository e-mail and then sorted again: email package name version repository So that maintainers could easily spot all their packages? Michael> broken packages in Fedora Extras Development is not Michael> short. Additionally, if reports for FE3, FE4 and FE Michael> Development were squeezed into the same mail, that would Michael> decrease readability even more. Create individuals mails for Michael> FE3/FE4/FE5? (that almost sounds like it could be merged Michael> with the "new packages" report) I would say split them up per branch. Michael> * How often to mail the packager? Michael> Would it be considered an annoyance to mail the packager Michael> daily because the script is run every day? Would it be enough Michael> to mail once then not repeat the reports for 7-14 days or Michael> unless the src.rpm file name changes? I would think an email each time it's run isn't too bad... Would perhaps get people fixing broken packages. On the other hand it might annoy people. :( Perhaps start out that way and see if people don't like that often? Michael> [...] Michael> The current scripts and their working directory can be found Michael> here for anybody who likes to take a look: Michael> http://home.arcor.de/ms2002sep/tmp/repoclosure-modified-20060208.tgz Oh, as a somewhat related note... would removing all the orphaned packages from the repo reduce the size of this report? I see a number of the packages with broken deps are also on the orphan list. That seems like they would be unlikely to get fixed ever until they have a maintainer. I would think we would want to remove a package if it has no maintainer... surely before fc5 release? kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin-fedora-extras at scrye.com Thu Feb 9 00:22:44 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Wed, 08 Feb 2006 17:22:44 -0700 (MST) Subject: apg and p0f maintainership Message-ID: <20060208.172244.480637624.kevin@scrye.com> I see that apg and p0f are orphaned currently. If no one else would like to maintain them I would be happy to do so. Neither package has any open bugs in bugzilla. The upsteam apg web page appears to be down, but hopefully thats transitory. Will wait a few days and see if anyone else is interested before taking them on. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From toshio at tiki-lounge.com Thu Feb 9 00:53:25 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 08 Feb 2006 16:53:25 -0800 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: <1138999755.3377.22.camel@localhost> References: <1138905153.3411.34.camel@localhost> <1138999755.3377.22.camel@localhost> Message-ID: <1139446405.3380.54.camel@localhost> On Fri, 2006-02-03 at 12:49 -0800, Toshio Kuratomi wrote: > On Thu, 2006-02-02 at 15:14 -0600, Rex Dieter wrote: > > Toshio Kuratomi wrote: > > > Do shared-mime-info and desktop-file-utils fall into the same category > > > or does some functionality of programs fail to work if > > > desktop-file-utils and shared-mime-info aren't run? > > > > The latter. > > > > > Your post makes me think that some Core GNOME applications (nautilus? > > > gnome-panel? gnome-vfs?) make use of the data generated by > > > desktop-file-utils and shared-mime-info but nothing else. Is that true > > > or just a guess? > > > > Gnome in general, yes. That's why I'm arguing it should be the GNOME > > libs/core bits that should depend on these, not (all) individual apps. > > > If I'm reading your responses correctly, shared-mime-info and > desktop-file-utils must be run in order for Core Gnome to function > correctly. However, the application itself can run under KDE or another > environment with no errors or loss of functionality. > > I don't see a problem with changing the shared-mime-info section if > that's the case. (shared-mime-info's dependencies percolate through to > libgnome which should be required by anything depending on it and it > does have a scriptlet to update on install.) > I've made this change to the shared-mime-info section. Look it over and correct any wrong assumptions there. > dekstop-file-utils doesn't seem to have either a dependency into the > Core of Gnome or a scriptlet to care for the case where it is installed > later so even though this seems like a valid concept, those issues > should be resolved first. > I didn't change this one. Rex, have you opened an RFE in bugzilla to change desktop-file-utils and get something to depend on it? -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 toshio at tiki-lounge.com Thu Feb 9 00:53:25 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 08 Feb 2006 16:53:25 -0800 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: <1138999755.3377.22.camel@localhost> References: <1138905153.3411.34.camel@localhost> <1138999755.3377.22.camel@localhost> Message-ID: <1139446405.3380.55.camel@localhost> On Fri, 2006-02-03 at 12:49 -0800, Toshio Kuratomi wrote: > On Thu, 2006-02-02 at 15:14 -0600, Rex Dieter wrote: > > Toshio Kuratomi wrote: > > > Do shared-mime-info and desktop-file-utils fall into the same category > > > or does some functionality of programs fail to work if > > > desktop-file-utils and shared-mime-info aren't run? > > > > The latter. > > > > > Your post makes me think that some Core GNOME applications (nautilus? > > > gnome-panel? gnome-vfs?) make use of the data generated by > > > desktop-file-utils and shared-mime-info but nothing else. Is that true > > > or just a guess? > > > > Gnome in general, yes. That's why I'm arguing it should be the GNOME > > libs/core bits that should depend on these, not (all) individual apps. > > > If I'm reading your responses correctly, shared-mime-info and > desktop-file-utils must be run in order for Core Gnome to function > correctly. However, the application itself can run under KDE or another > environment with no errors or loss of functionality. > > I don't see a problem with changing the shared-mime-info section if > that's the case. (shared-mime-info's dependencies percolate through to > libgnome which should be required by anything depending on it and it > does have a scriptlet to update on install.) > I've made this change to the shared-mime-info section. Look it over and correct any wrong assumptions there. > dekstop-file-utils doesn't seem to have either a dependency into the > Core of Gnome or a scriptlet to care for the case where it is installed > later so even though this seems like a valid concept, those issues > should be resolved first. > I didn't change this one. Rex, have you opened an RFE in bugzilla to change desktop-file-utils and get something to depend on it? -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 bugzilla at redhat.com Thu Feb 9 02:11:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 21:11:56 -0500 Subject: [Bug 180571] New: Review Request: puppet Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180571 Summary: Review Request: puppet Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: dlutter at redhat.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://people.redhat.com/dlutter/yum/spec/puppet.spec http://people.redhat.com/dlutter/yum/spec/facter.spec SRPM Name or Url: http://people.redhat.com/dlutter/yum/SRPMS/puppet-0.13.0-3.src.rpm http://people.redhat.com/dlutter/yum/SRPMS/facter-1.1.1-3.src.rpm Description [puppet]: Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. Description [facter]: Facter is a module for collecting simple facts about a host Operating system. Notes: - I included facter, one of puppet's requirements in this request since it is miniscule - This is my first Fedora Extras submission, and needs to be sponsored -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 9 02:31:06 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 21:31:06 -0500 Subject: [Bug 176205] Review Request: GZLauncher In-Reply-To: Message-ID: <200602090231.k192V6k4026481@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: GZLauncher https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176205 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |WONTFIX OtherBugsDependingO|163778 | nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-08 21:31 EST ------- Closed as per request of Michael in comment 11. (What a silly condition, only allowing protocol access to closed software. What are they trying to achieve, security through obscurity?) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 9 02:32:23 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 21:32:23 -0500 Subject: [Bug 180299] Review Request: pitivi In-Reply-To: Message-ID: <200602090232.k192WN5b026773@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: pitivi https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180299 ------- Additional Comments From redhat at flyn.org 2006-02-08 21:32 EST ------- Implemented Jeffrey's suggestions: Spec Name or Url: http://www.flyn.org/SRPMS/pitivi.spec SRPM Name or Url: http://www.flyn.org/SRPMS/pitivi-0.9.9.2-3.src.rpm Description: Pitivi is an application using the GStreamer multimedia framework to manipulate a large set of multimedia sources. At this level of development it can be compared to a classic video editing program. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 9 02:33:17 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 21:33:17 -0500 Subject: [Bug 180298] Review Request: gnonlin In-Reply-To: Message-ID: <200602090233.k192XHmX026926@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnonlin https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180298 ------- Additional Comments From redhat at flyn.org 2006-02-08 21:33 EST ------- Implemented Jeffrey's suggestions: Spec Name or Url: http://www.flyn.org/SRPMS/gnonlin.spec SRPM Name or Url: http://www.flyn.org/SRPMS/gnonlin-0.10.0.5-3.src.rpm Description: Gnonlin is a library built on top of GStreamer (http://gstreamer.net) which provides support for writing non-linear audio and video editing applications. It introduces the concept of a timeline -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rdieter at math.unl.edu Thu Feb 9 03:35:01 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 08 Feb 2006 21:35:01 -0600 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: <1139446405.3380.54.camel@localhost> References: <1138905153.3411.34.camel@localhost> <1138999755.3377.22.camel@localhost> <1139446405.3380.54.camel@localhost> Message-ID: Toshio Kuratomi wrote: >>dekstop-file-utils doesn't seem to have either a dependency into the >>Core of Gnome or a scriptlet to care for the case where it is installed >>later so even though this seems like a valid concept, those issues >>should be resolved first. >> > > I didn't change this one. Rex, have you opened an RFE in bugzilla to > change desktop-file-utils and get something to depend on it? No... not yet anyway. -- Rex From orion at cora.nwra.com Thu Feb 9 03:33:29 2006 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Wed, 8 Feb 2006 20:33:29 -0700 (MST) Subject: RFC: automated broken deps reports In-Reply-To: <20060208124712.59cfeaf4.bugs.michael@gmx.net> References: <20060208124712.59cfeaf4.bugs.michael@gmx.net> Message-ID: <20307.70.56.38.46.1139456009.squirrel@www.cora.nwra.com> > As discussed briefly in the last meeting of FESCO, there are a few open > questions with regard to running a script that does automated checking of > broken dependencies in Fedora Extras: > > * How often to run it? > > Daily? After every push of new builds for Fedora Extras? If Rawhide breaks > something how do we become aware of that in time? Barring excessive cpu usage, I would run as often as possible. Why not catch a broken dependencies as soon as possible (assuming the script has access to the just built plague repository). Some caveats follow. > > * Whether to mail a summary of all broken dependencies to > fedora-extras-list? I vote for just the list of packages per repository. No email addresses. Not broken down by email address. Just the package names. The summary should only be posted about once a day though - probably after FE pushes. > > * How often to mail the packager? Just once per N-V-R. From bugzilla at redhat.com Thu Feb 9 03:42:46 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 22:42:46 -0500 Subject: [Bug 180532] Review Request: perl-UNIVERSAL-can In-Reply-To: Message-ID: <200602090342.k193gkBD005885@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-UNIVERSAL-can https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180532 ------- Additional Comments From tibbs at math.uh.edu 2006-02-08 22:42 EST ------- Yep, a mock build with the current development tree dies due to the failed Test::Exception dependency. I'll attach the build log. I hacked a bit to build an SRPM that with that additional dependency but it still failed many of the tests. I wonder if I'm doing something wrong. How did you get this to build? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From michael at knox.net.nz Thu Feb 9 03:52:48 2006 From: michael at knox.net.nz (Michael J Knox) Date: Thu, 09 Feb 2006 16:52:48 +1300 Subject: libnotify in gnomebaker In-Reply-To: <1139413835.2811.2.camel@shuttle.273piedmont.org> References: <1139362651.3727.10.camel@cosima.et.endace.com> <1139364160.3727.12.camel@cosima.et.endace.com> <1139413835.2811.2.camel@shuttle.273piedmont.org> Message-ID: <1139457169.31428.0.camel@pingu.homenetwork.lan> On Wed, 2006-02-08 at 10:50 -0500, Brian Pepple wrote: > On Wed, 2006-02-08 at 15:02 +1300, Michael J Knox wrote: > > Is there any reason why libnotify support is missing in gnomebaker? > > > > Michael > > Because maybe that support wasn't released in 0.5.1? Look at the > tarball. Not to mention that it's fairly worthless from what I've seen > so far. > > /B Oops. Your quiet right, not in 0.5.1. However, I disagree about its usefulness. Michael From bugzilla at redhat.com Thu Feb 9 04:18:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 23:18:52 -0500 Subject: [Bug 176200] Review Request: Mud Magic Client In-Reply-To: Message-ID: <200602090418.k194IqwV012701@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Mud Magic Client https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176200 imlinux at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|imlinux at gmail.com |bugzilla-sink at leemhuis.info ------- Additional Comments From imlinux at gmail.com 2006-02-08 23:18 EST ------- Sorry Calvin, I didn't realize this was FE-NEEDSPONSOR. I'm only just recently sponsored myself so I can't sponsor you, I'll assign this to bugzilla-sink at leemhuis.info Which by the sounds of the name is not unlike /dev/null :-D but someone will pick it up soon I'm sure. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 9 04:24:23 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 23:24:23 -0500 Subject: [Bug 176200] Review Request: Mud Magic Client In-Reply-To: Message-ID: <200602090424.k194ONss013874@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Mud Magic Client https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176200 ------- Additional Comments From kyndig at mudmagic.com 2006-02-08 23:24 EST ------- *lol* Thank you. The 1.8 version is published. 1.9 will be mostly internal updates and completion of MXP and will not be a major release. I'll work again on getting it in Fedora for version 2.0 in about a year. http://www.mudmagic.com/mud-client/downloads/mudmagic-1.8-fdr.src.rpm Calvin -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 9 04:32:51 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 8 Feb 2006 23:32:51 -0500 Subject: [Bug 177841] Tracker: New Extras packages that need a sponsor In-Reply-To: Message-ID: <200602090432.k194WpUB015006@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Tracker: New Extras packages that need a sponsor Alias: FE-NEEDSPONSOR https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177841 Bug 177841 depends on bug 176200, which changed state. Bug 176200 Summary: Review Request: Mud Magic Client https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176200 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |DEFERRED Status|NEW |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 9 12:43:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 07:43:49 -0500 Subject: [Bug 176137] Review Request: perl-Log-Log4perl - Log4j implementation for Perl In-Reply-To: Message-ID: <200602091243.k19Chn4R022214@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Log-Log4perl - Log4j implementation for Perl https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176137 paul at city-fan.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |paul at city-fan.org OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From paul at city-fan.org 2006-02-09 07:43 EST ------- Review: - rpmlint clean - package and spec naming OK - package meets guidelines - license is same as perl, matches spec, text included - spec file written in English and is legible - sources match upstream - package builds OK on FC4 (i386) and in mock for rawhide (i386) - BR's OK - no locales, libraries, pkgconfigs, or subpackages to worry about - not relocatable - no directory ownership or permissions issues - no duplicate files - %clean section present and correct - macro usage is consistent - code, not content - no large docs - docs don't affect runtime - no desktop file needed - no scriptlets - patches look sane Suggestions: - perhaps a comment in the spec file about the issue with Log::Dispatch::FileRotate, and a reference to this bugzilla ticket? - perhaps the rrdtool buildreq could be replaced by perl(RRDs)? Approved. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 9 13:55:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 08:55:53 -0500 Subject: [Bug 170303] Review Request: google-perftools: Very fast malloc & performance analysis tools In-Reply-To: Message-ID: <200602091355.k19Dtriu002021@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: google-perftools: Very fast malloc & performance analysis tools https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170303 ------- Additional Comments From dmitry at butskoy.name 2006-02-09 08:55 EST ------- > I tried compiling google-perftools-0.6 on a standard FC3 machine and could not > reproduce the problems reported. Well, I use FC3 too (with all the updates needed). To reproduce: 1. Take the source rpm here: http://dmitry.butskoy.name/google-perftools-0.6-1.src.rpm It is Tom's srpm with just the tarball upgraded. 2. rpm -i *.src.rpm 3. Go to your SPEC directory and run "rpmbuild -bc" (i.e., compile only) 4. Go to the appropriate BUILD subdirectory and run "make check" You should see the failure (and a lot of another falusers when playing with various optimisation levels and LD_ASSUME_KERNEL's ...) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From petro at mail.ru Thu Feb 9 15:51:00 2006 From: petro at mail.ru (Peter Lemenkov) Date: Thu, 9 Feb 2006 18:51:00 +0300 Subject: where to request package to be added to FE? In-Reply-To: References: <20060208112950.GD2750@free.fr> Message-ID: On Thu, 9 Feb 2006, leon wrote: > No wonder nobody package xCHM yet. wxGTK is stable enough and would be > great if we can have it for FC5. FYI I can't compile xCHM using rawhides's GCC. Older one (pre-4.1) compiles xCHM w/o troubles. -- With best regards, Peter Lemenkov. From sdl.web at gmail.com Thu Feb 9 16:48:44 2006 From: sdl.web at gmail.com (leon) Date: Thu, 09 Feb 2006 16:48:44 +0000 Subject: where to request package to be added to FE? References: <20060208112950.GD2750@free.fr> Message-ID: Peter Lemenkov writes: | On Thu, 9 Feb 2006, leon wrote: | | > No wonder nobody package xCHM yet. wxGTK is stable enough and would be | > great if we can have it for FC5. | | FYI I can't compile xCHM using rawhides's GCC. Older one (pre-4.1) | compiles xCHM w/o troubles. Is it a bug of gcc or xchm? Have you tried xCHM 1.3? Thank you for your effort. -- Leon From bugzilla at redhat.com Thu Feb 9 16:52:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 11:52:10 -0500 Subject: [Bug 176137] Review Request: perl-Log-Log4perl - Log4j implementation for Perl In-Reply-To: Message-ID: <200602091652.k19GqANU004056@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Log-Log4perl - Log4j implementation for Perl https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176137 jpo at di.uminho.pt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From jpo at di.uminho.pt 2006-02-09 11:52 EST ------- (In reply to comment #2) > Suggestions: > > - perhaps a comment in the spec file about the issue with > Log::Dispatch::FileRotate, and a reference to this bugzilla ticket? Done. > - perhaps the rrdtool buildreq could be replaced by perl(RRDs)? Done. Also added a comment about perl(RRDs) being provided by the rrdtool package (a package outside the perl- namespace). > Approved. Thanks. PS - Also added a comment with the CPAN URL (Log-Log4perl 1.03 appeared today in CPAN). PS2 - Package already built for devel. CVS FC-4 branch pending. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From ndbecker2 at gmail.com Thu Feb 9 17:02:02 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 09 Feb 2006 12:02:02 -0500 Subject: wxPython needs update? Message-ID: I just tried to install faces-pm (project management). It wants wxPython. I did yum install wxPythonGTK2. This grabbed: Installed: wxPythonGTK2.x86_64 0:2.4.2.4-7 Dependency Installed: compat-wxGTK-common.x86_64 0:2.4.2-16.fc5 compat-wxGTK2.x86_64 0:2.4.2-16.fc5 compat-wxGTK2-gl.x86_64 0:2.4.2-16.fc5 Now fire up faces: raceback (most recent call last): File "/usr/bin/faces", line 2, in ? from faces.gui.plangui import main File "/usr/lib/python2.4/site-packages/faces/gui/plangui.py", line 36, in ? import wx.html File "/usr/lib64/python2.4/site-packages/wx/__init__.py", line 45, in ? from wxPython import wx File "/usr/lib64/python2.4/site-packages/wxPython/__init__.py", line 20, in ? import wxc ImportError: /usr/lib64/libwx_gtk2-2.4.so.0: undefined symbol: pango_x_get_context Not sure what's going on, but I notice that faces says it should use wxGTK-2.6. Seems wxPythonGTK2 is using wxGTK-2.4. Many packages I see are now requiring 2.6. Anyone working on updating our package? From bugzilla at redhat.com Thu Feb 9 17:03:19 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 12:03:19 -0500 Subject: [Bug 180422] Review Request: gnome-mud In-Reply-To: Message-ID: <200602091703.k19H3Jg3006276@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-mud https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180422 ------- Additional Comments From wart at kobold.org 2006-02-09 12:03 EST ------- The scrollkeeper problem from comment #2 still exists in the -3 package. It looks like '--disable-scrollkeeper' didn't fix the problem. In addition, there is an rpath set that should be removed: ERROR 0001: file '/usr/games/gnome-mud' contains a standard rpath '/usr/lib64' in [/usr/lib64] -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From toshio at tiki-lounge.com Thu Feb 9 17:46:19 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 09 Feb 2006 09:46:19 -0800 Subject: wxPython needs update? In-Reply-To: References: Message-ID: <1139507179.3366.4.camel@localhost> On Thu, 2006-02-09 at 12:02 -0500, Neal Becker wrote: > I just tried to install faces-pm (project management). It wants wxPython. > > I did yum install wxPythonGTK2. This grabbed: > Installed: wxPythonGTK2.x86_64 0:2.4.2.4-7 > Dependency Installed: compat-wxGTK-common.x86_64 0:2.4.2-16.fc5 > compat-wxGTK2.x86_64 0:2.4.2-16.fc5 compat-wxGTK2-gl.x86_64 0:2.4.2-16.fc5 > > Now fire up faces: > raceback (most recent call last): > File "/usr/bin/faces", line 2, in ? > from faces.gui.plangui import main > File "/usr/lib/python2.4/site-packages/faces/gui/plangui.py", line 36, > in ? > import wx.html > File "/usr/lib64/python2.4/site-packages/wx/__init__.py", line 45, in ? > from wxPython import wx > File "/usr/lib64/python2.4/site-packages/wxPython/__init__.py", line 20, > in ? > import wxc > ImportError: /usr/lib64/libwx_gtk2-2.4.so.0: undefined symbol: > pango_x_get_context > > > Not sure what's going on, but I notice that faces says it should use > wxGTK-2.6. Seems wxPythonGTK2 is using wxGTK-2.4. Many packages I see are > now requiring 2.6. Anyone working on updating our package? > 2.6 is in devel thanks to Matthew Miller. I don't know that there's any plan to update wxGTK for FC4 though. -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 ndbecker2 at gmail.com Thu Feb 9 18:02:29 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 09 Feb 2006 13:02:29 -0500 Subject: wxPython needs update? References: <1139507179.3366.4.camel@localhost> Message-ID: Toshio Kuratomi wrote: > On Thu, 2006-02-09 at 12:02 -0500, Neal Becker wrote: >> I just tried to install faces-pm (project management). It wants >> wxPython. >> >> I did yum install wxPythonGTK2. This grabbed: >> Installed: wxPythonGTK2.x86_64 0:2.4.2.4-7 >> Dependency Installed: compat-wxGTK-common.x86_64 0:2.4.2-16.fc5 >> compat-wxGTK2.x86_64 0:2.4.2-16.fc5 compat-wxGTK2-gl.x86_64 >> 0:2.4.2-16.fc5 >> >> Now fire up faces: >> raceback (most recent call last): >> File "/usr/bin/faces", line 2, in ? >> from faces.gui.plangui import main >> File "/usr/lib/python2.4/site-packages/faces/gui/plangui.py", line 36, >> in ? >> import wx.html >> File "/usr/lib64/python2.4/site-packages/wx/__init__.py", line 45, in ? >> from wxPython import wx >> File "/usr/lib64/python2.4/site-packages/wxPython/__init__.py", line >> 20, >> in ? >> import wxc >> ImportError: /usr/lib64/libwx_gtk2-2.4.so.0: undefined symbol: >> pango_x_get_context >> >> >> Not sure what's going on, but I notice that faces says it should use >> wxGTK-2.6. Seems wxPythonGTK2 is using wxGTK-2.4. Many packages I see >> are >> now requiring 2.6. Anyone working on updating our package? >> > 2.6 is in devel thanks to Matthew Miller. I don't know that there's any > plan to update wxGTK for FC4 though. > wxGTK2 is 2.6, but wxPythonGTK2 seems to be 2.4. I'm talking about devel. From Christian.Iseli at licr.org Thu Feb 9 18:11:15 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 09 Feb 2006 19:11:15 +0100 Subject: FE Package Status of Feb 9, 2006 Message-ID: <200602091811.k19IBF7P008862@mx1.redhat.com> Hi folks, Ok, I'm through revising the script. Below is its short output, and the rest of the report is on the wiki page. Cheers, Christian --- FE Package Status of Feb 9, 2006 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 1418 packages - 59 orphans - 50 not available in extras devel or release - 11 packages not available in extras devel but present in release - 3 packages which have not yet been FE_APPROVE'd... - 15 packages present in the development repo which have no owners entry - 53 orphaned packages, yet available in extras devel - 33 packages that moved to core FE-ACCEPT packages stats: - 496 accepted, closed package reviews - 8 accepted, closed packages not in repo - 7 accepted, closed packages not in owners - 14 accepted, open package reviews older than 4 weeks; - 10 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 54 open tickets - 10 tickets with no activity in eight weeks - 10 tickets with no activity in four weeks - 2 closed tickets FE-NEW packages stats: - 129 open tickets - 11 tickets with no activity in eight weeks - 19 tickets with no activity in four weeks - 9 closed tickets FE-NEEDSPONSOR packages stats: - 35 open tickets From bugs.michael at gmx.net Thu Feb 9 18:12:34 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 9 Feb 2006 19:12:34 +0100 Subject: RFC: automated broken deps reports In-Reply-To: <20060208.171432.144930893.kevin@scrye.com> References: <20060208124712.59cfeaf4.bugs.michael@gmx.net> <20060208.171432.144930893.kevin@scrye.com> Message-ID: <20060209191234.32eeb9cf.bugs.michael@gmx.net> On Wed, 08 Feb 2006 17:14:32 -0700 (MST), Kevin Fenzi wrote: > Oh, as a somewhat related note... would removing all the orphaned > packages from the repo reduce the size of this report? > > I see a number of the packages with broken deps are also on the orphan > list. That seems like they would be unlikely to get fixed ever until > they have a maintainer. I would think we would want to remove a > package if it has no maintainer... surely before fc5 release? Yes. Not offering broken orphaned packages at all is certainly better than offering broken packages. ;) From bugzilla at redhat.com Thu Feb 9 18:26:51 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 13:26:51 -0500 Subject: [Bug 178951] Review Request: modules - Provides dynamic modification of a user's environment In-Reply-To: Message-ID: <200602091826.k19IQp7H022985@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: modules - Provides dynamic modification of a user's environment https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178951 ------- Additional Comments From orion at cora.nwra.com 2006-02-09 13:26 EST ------- Updated version: http://www.cora.nwra.com/~orion/fedora/modules-3.2.0p1-1.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 9 18:40:22 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 13:40:22 -0500 Subject: [Bug 178951] Review Request: modules - Provides dynamic modification of a user's environment In-Reply-To: Message-ID: <200602091840.k19IeMXU026063@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: modules - Provides dynamic modification of a user's environment https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178951 ------- Additional Comments From ed at eh3.com 2006-02-09 13:40 EST ------- I'm getting a 404 from the URL in comment #6 above. Also, I thought that (per comment #4) the package name was going to change from "modules" to "environment-modules" ? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From wart at kobold.org Thu Feb 9 18:51:35 2006 From: wart at kobold.org (Michael Thomas) Date: Thu, 09 Feb 2006 10:51:35 -0800 Subject: SIGs (Was: Shortlog from todays fesco meeting) In-Reply-To: <1139337154.2967.74.camel@localhost.localdomain> References: <1138308919.2638.35.camel@localhost.localdomain> <200602062000.27959.jamatos@fc.up.pt> <1139333736.2967.26.camel@localhost.localdomain> <1139337154.2967.74.camel@localhost.localdomain> Message-ID: <43EB8F37.7080500@kobold.org> Thorsten Leemhuis wrote: > Am Dienstag, den 07.02.2006, 12:08 -0600 schrieb Jason L Tibbitts III: > >>>>>>>"TL" == Thorsten Leemhuis writes: >> >>I don't think it would be necessary to enforce any kind >>of structure, although if a SIG goes dead there should probably be a >>procedure for deleting it. > > > Well, I agree mostly. But some questions maybe should be discussed once > (and the answers should be written down somewhere in the wiki): > > - How to get in contact with a SIG fedora-extras-list seems like a good place. I don't see enough traffic to warrant an extra list, and much of the discussion in a SIG would probably be of wider interest to the rest of the FE community. IRC is another option, but that would require that SIG members camp out in the IRC channel. I'm not sure about other's irc habits, but I don't tend to monitor irc as much as email. > - What do SIGs do? And what not? Encourage reviews of SIG-related packages. Discuss packaging details specific to the SIG (such as language-specific nuances). Suggest additional packages for submission. imho, the goal of a SIG would be to publish high-quality packages of interest to the SIG community. > - Do we need mailinglists? IRC-Channels? See above. I think fedora-extras-list is fine. > - Should SIG's have a leader ? Not necessarily. I don't see SIGs needing any sort of higher level management. If some sort of leader is needed because a SIG gets big, then that leader will likely naturally emerge from the SIG. > - How can FESCo contact a SIG(-leader)? > - Who coordinates the SIG creation? I think we shouldn't have more then > 10 or 15 groups. And we probably all don't want a "GNOME Games written > in python SIG" How about proposing new SIGs on the mailing list? > - That's a good example: If I have a gnome game written in python: Which > SIG do I contact in case of problems: The Gnome, Python or Games SIG? > (Okay, common sense should normally be enough to answer this question, > but I bet that we'll see such a question on this list sooner or later) I guess I really see SIGs as a wiki page listing packages under review, packaging details, etc. I don't see the need to create additional communications channels from the very beginning. So in your example, you'd contact the fedora-extras mailing list, and members of the relevant SIGs should respond. I'm assuming in all of this that SIGs are organized around the packaging of software, rather than an end-user discussion/support group. --Wart -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From bugzilla at redhat.com Thu Feb 9 18:51:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 13:51:13 -0500 Subject: [Bug 178951] Review Request: environment-modules - Provides dynamic modification of a user's environment In-Reply-To: Message-ID: <200602091851.k19IpDad029449@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: environment-modules - Provides dynamic modification of a user's environment https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178951 orion at cora.nwra.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: modules - |Review Request: environment- |Provides dynamic |modules - Provides dynamic |modification of a user's |modification of a user's |environment |environment ------- Additional Comments From orion at cora.nwra.com 2006-02-09 13:51 EST ------- Whoops: http://www.cora.nwra.com/~orion/fedora/environment-modules-3.2.0p1-1.src.rppm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From toshio at tiki-lounge.com Thu Feb 9 18:59:50 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 09 Feb 2006 10:59:50 -0800 Subject: wxPython needs update? In-Reply-To: References: <1139507179.3366.4.camel@localhost> Message-ID: <1139511590.3366.9.camel@localhost> On Thu, 2006-02-09 at 13:02 -0500, Neal Becker wrote: > Toshio Kuratomi wrote: > > > On Thu, 2006-02-09 at 12:02 -0500, Neal Becker wrote: > >> Not sure what's going on, but I notice that faces says it should use > >> wxGTK-2.6. Seems wxPythonGTK2 is using wxGTK-2.4. Many packages I see > >> are > >> now requiring 2.6. Anyone working on updating our package? > >> > > 2.6 is in devel thanks to Matthew Miller. I don't know that there's any > > plan to update wxGTK for FC4 though. > > > > wxGTK2 is 2.6, but wxPythonGTK2 seems to be 2.4. I'm talking about devel. > Oops. My mistake. You're mostly interested in this bug, then: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163440 which says Matthew is probably going to wait a couple weeks for some build fixes in 2.6.3. -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 bugzilla at redhat.com Thu Feb 9 19:07:12 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 14:07:12 -0500 Subject: [Bug 169717] Review Request: Internode DSL usage applet In-Reply-To: Message-ID: <200602091907.k19J7COh000565@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Internode DSL usage applet https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169717 ------- Additional Comments From wart at kobold.org 2006-02-09 14:06 EST ------- Just a couple of initial comments: * I believe the Requires: python-abi is no longer needed for FC4+5. * Use %{SOURCE1} in %prep instead of %{_sourcedir}. It's a little easier to read. * There is a debug 'echo' line in %install I've never been clear on the recommendations for .pyc files. Should these be shipped or %ghosted? I will try to do a more formal review later today... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 9 19:11:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 14:11:48 -0500 Subject: [Bug 180422] Review Request: gnome-mud In-Reply-To: Message-ID: <200602091911.k19JBmwp002073@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-mud https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180422 ------- Additional Comments From sysadmin at tacticalbusinesspartners.com 2006-02-09 14:11 EST ------- Fixed problems mentioned in #6, with one exception. No matter how many times I looked, I couldn't find fedora-gnome-mud.desktop. Also, I'm adding the vendor per wiki specifications. Am at a loss about what to do with the scrollkeeper issue. Also, couldn't find any mention of the rpath error as said in comment #7. SRPM is: http://m2g04.tunegenie.com/~hlb/Personal/gnome-mud-0.10.7-4.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 9 19:13:24 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 14:13:24 -0500 Subject: [Bug 169717] Review Request: Internode DSL usage applet In-Reply-To: Message-ID: <200602091913.k19JDOPI002431@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Internode DSL usage applet https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169717 ------- Additional Comments From wart at kobold.org 2006-02-09 14:13 EST ------- Build error on FC-4 x86_64. It looks like the package installs some files into /usr/lib instead of %{_libdir} File not found: /var/tmp/gnome-applet-internode-1.3-1-root-rpmbuild/usr/lib64/bonobo/servers/InternodeUsageMeterApplet.server -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 9 19:14:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 14:14:30 -0500 Subject: [Bug 178951] Review Request: environment-modules - Provides dynamic modification of a user's environment In-Reply-To: Message-ID: <200602091914.k19JEURc002650@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: environment-modules - Provides dynamic modification of a user's environment https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178951 ------- Additional Comments From ed at eh3.com 2006-02-09 14:14 EST ------- Not to be excessively picky, but the above URL should be "s/rppm/rpm/" and it took me a few minutes to see why I was still getting 404s. :-) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 9 19:37:03 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 14:37:03 -0500 Subject: [Bug 180422] Review Request: gnome-mud In-Reply-To: Message-ID: <200602091937.k19Jb3gL008508@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-mud https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180422 ------- Additional Comments From bdpepple at ameritech.net 2006-02-09 14:36 EST ------- The package still fails to build in Mock. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 9 19:42:57 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 14:42:57 -0500 Subject: [Bug 180422] Review Request: gnome-mud In-Reply-To: Message-ID: <200602091942.k19JgvVY009836@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-mud https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180422 ------- Additional Comments From wart at kobold.org 2006-02-09 14:42 EST ------- I'm not sure what to do about scrollkeeper either. Even if I set "scrollkeeper_localstate_dir" on the "make install" line, scrollkeeper still tries (and fails) to write to /var/log/scrollkeeper. Best just to turn off the scrollkeeper-update during 'make install', but from what I can see you'll have to patch the Makefile to do that. The rpath error that I get comes from the check-rpaths test at the end of rpmbuild: + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot It's possible that you don't have this rpath-checking turned on in your build environment. 'fedora-buildrpmtree' should have put the following line in your .rpmmacros to enable this feature: %__arch_install_post /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 9 19:57:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 14:57:28 -0500 Subject: [Bug 179916] Review Request: docbook2X - Convert docbook into man and Texinfo In-Reply-To: Message-ID: <200602091957.k19JvS0R012529@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: docbook2X - Convert docbook into man and Texinfo https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179916 jamatos at fc.up.pt changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From jamatos at fc.up.pt 2006-02-09 14:57 EST ------- Preliminary review: Review for release 2: * RPM name is OK * Source docbook2X-0.8.5.tar.gz is the same as upstream * Spec file is readable * License is correct * This is the latest version * Builds fine in mock * rpmlint of docbook2X looks OK it complains about the lib nature of one of its dependencies but in this case it is bogus. * Package follows packaging rules OK * File list of docbook2X looks OK One minor question, since the package searches tidy is there any reason not to BR it? Package is APPROVED. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 9 20:14:22 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 15:14:22 -0500 Subject: [Bug 180422] Review Request: gnome-mud In-Reply-To: Message-ID: <200602092014.k19KEMlO015982@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-mud https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180422 ------- Additional Comments From bdpepple at ameritech.net 2006-02-09 15:14 EST ------- (In reply to comment #8) > Fixed problems mentioned in #6, with one exception. No matter how many times I > looked, I couldn't find fedora-gnome-mud.desktop. Also, I'm adding the vendor > per wiki specifications. The problem is that your not deleting the original desktop file. Use this: desktop-file-install --vendor fedora --delete-original \ --dir $RPM_BUILD_ROOT%{_datadir}/applications \ --add-category X-Fedora \ $RPM_BUILD_ROOT%{_datadir}/applications/%{name}.desktop Also, the spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 9 20:46:03 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 15:46:03 -0500 Subject: [Bug 178951] Review Request: environment-modules - Provides dynamic modification of a user's environment In-Reply-To: Message-ID: <200602092046.k19Kk3Li024984@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: environment-modules - Provides dynamic modification of a user's environment https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178951 ed at eh3.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From ed at eh3.com 2006-02-09 15:45 EST ------- Hi Orion, it appears that you've addressed all the comments, the latest SRPM just built cleanly for me in mock (FC4 i386), and I don't see any remaining blockers. APPROVED. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 9 20:51:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 15:51:28 -0500 Subject: [Bug 179916] Review Request: docbook2X - Convert docbook into man and Texinfo In-Reply-To: Message-ID: <200602092051.k19KpS8n025607@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: docbook2X - Convert docbook into man and Texinfo https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179916 ------- Additional Comments From pertusus at free.fr 2006-02-09 15:51 EST ------- It searches tidy and xmllint to rebuild the doc, but the doc needs not to be rebuilt, as they are packaged. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 9 23:20:04 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 18:20:04 -0500 Subject: [Bug 166960] Review Request: Fuse-emulator In-Reply-To: Message-ID: <200602092320.k19NK4Vs017774@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Fuse-emulator https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166960 ------- Additional Comments From paul at all-the-johnsons.co.uk 2006-02-09 18:19 EST ------- New URLS http://www.smmp.salford.ac.uk/packages/fuse-emulator.spec http://www.smmp.salford.ac.uk/packages/fuse-emulator-0.7.0-6.src.rpm Now correctly packaged and with the fresh smell of mint -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 9 23:25:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 18:25:27 -0500 Subject: [Bug 167364] Review Request: Fuse emulator utilities In-Reply-To: Message-ID: <200602092325.k19NPR3g018550@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Fuse emulator utilities https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167364 ------- Additional Comments From paul at all-the-johnsons.co.uk 2006-02-09 18:25 EST ------- Spec Name or Url: http://www.smmp.salford.ac.uk/packages/fuse-emulator-utils-0.7.0.spec I've not rebuilt it as there is a blocker against 64 bit architectures - I'll need to investigate that on the source -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 10 00:18:05 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 19:18:05 -0500 Subject: [Bug 180743] New: Review Request: pdsh Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180743 Summary: Review Request: pdsh Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: woodard at redhat.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://osdn.dl.sourceforge.net/sourceforge/pdsh/pdsh.spec SRPM Name or Url: http://osdn.dl.sourceforge.net/sourceforge/pdsh/pdsh-2.8.1-2.src.rpm Description: Pdsh is a multithreaded remote shell client which executes commands on multiple remote hosts in parallel. Pdsh can use several different remote shell services, including standard "rsh", Kerberos IV, and ssh. This is my first submission and I need a sponsor. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 01:30:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 9 Feb 2006 20:30:44 -0500 Subject: [Bug 180747] New: Review Request: powerman Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180747 Summary: Review Request: powerman Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: woodard at redhat.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://osdn.dl.sourceforge.net/sourceforge/powerman/powerman.spec SRPM Name or Url: http://osdn.dl.sourceforge.net/sourceforge/powerman/powerman-1.0.22-2.src.rpm Description: PowerMan is a tool for manipulating remote power control (RPC) devices from a central location. Several RPC varieties are supported natively by PowerMan and Expect-like configurability simplifies the addition of new devices. I will need a sponsor for this package. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 08:53:57 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 03:53:57 -0500 Subject: [Bug 180068] Review Request: geoip - Library for mapping IP/hostname to a country/city/organization In-Reply-To: Message-ID: <200602100853.k1A8rvKu031286@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: geoip - Library for mapping IP/hostname to a country/city/organization https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180068 rc040203 at freenet.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bugzilla-sink at leemhuis.info |rc040203 at freenet.de OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From rc040203 at freenet.de 2006-02-10 03:53 EST ------- NEEDSWORK Blockers: - Packaging of shared libs is messed up. What you call "superfluous symlinks" is essential. Non-Blockers: - The tarball is named GeoIP, therefore the rpm also should use this name. - Shipping static libs. You should ship shared libraries, instead (--disable-static) - You should append --disable-dependency-tracking to %configure to speed up building. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 10:23:05 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 05:23:05 -0500 Subject: [Bug 180532] Review Request: perl-UNIVERSAL-can In-Reply-To: Message-ID: <200602101023.k1AAN5ss014410@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-UNIVERSAL-can https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180532 ------- Additional Comments From jpo at di.uminho.pt 2006-02-10 05:22 EST ------- Jason, I messed up and tested the previous specfile in the wrong system. The previous specfile didn't build correctely in devel (perl 5.8.8/Sup::Uplevel/Test::Warn problems). Right now there are two new versions of UNIVERSAL::can in CPAN and at least the latest one passes all tests in devel (according to the Changelog it now includes workarounds to the weird problems in Test::Warn). I believe the problems are due to Sub::Uplevel in perl 5.8.8 (the test suite generates a lot of noise) but I only have time to look into it next week. Diff from UNIVERSAL-can-1.03 to UNIVERSAL-can-1.11 http://search.cpan.org/diff?from=UNIVERSAL-can-1.03&to=UNIVERSAL-can-1.11 New SRPM: http://gsd.di.uminho.pt/jpo/software/fedora/perl-UNIVERSAL-can-1.11-1.src.rpm The specfile link is the same. jpo -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 10:54:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 05:54:56 -0500 Subject: [Bug 180422] Review Request: gnome-mud In-Reply-To: Message-ID: <200602101054.k1AAsuVu019208@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-mud https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180422 frank at scirocco-5v-turbo.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC|frank at scirocco-5v-turbo.de | ------- Additional Comments From frank at scirocco-5v-turbo.de 2006-02-10 05:54 EST ------- (In reply to comment #7) > The scrollkeeper problem from comment #2 still exists in the -3 package. It > looks like '--disable-scrollkeeper' didn't fix the problem. Ooops, this was my fault. I should look at the package sources or at least select the correct tag in GNOME CVS. The packaged version is old style scrollkeeper. The gnome-doc-utils approach is only in CVS HEAD right now, so future versions will use it. More careful comments: 1. Undo the crap suggested by me. Remove BR gnome-doc-utils and add BR scrollkeeper 2. Add 'export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1' before 'make install' 3. Unpackaged files: %{_datadir}/gnome/help/gnome-mud/C/monitor.py[co]. Not sure if they should be ghosted. 4. GConf scheme handling is missing - see ScriptletSnippets in the wiki 5. Description needs to be wrapped after 80 chars 6. Changelog not up to date (rpmlint) 7. At least the license text (COPYING) is missing in %doc. I would add AUTHORS, NEWS, and ROADMAP too. 8. I would add this line after '%setup -q' to solve the scrollkeeper issue: sed -i -e '/-scrollkeeper-update -p/d' doc/omf-install/Makefile.in -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 11:25:29 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 06:25:29 -0500 Subject: [Bug 180068] Review Request: geoip - Library for mapping IP/hostname to a country/city/organization In-Reply-To: Message-ID: <200602101125.k1ABPTHP024595@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: geoip - Library for mapping IP/hostname to a country/city/organization https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180068 ------- Additional Comments From mfleming+rpm at enlartenment.com 2006-02-10 06:25 EST ------- New spec and URL implementing the above suggestions: http://www.enlartenment.com/extras/GeoIP.spec http://www.enlartenment.com/extras/GeoIP-1.3.14-2.src.rpm Built OK for me in mock (Core 4), rpmlint seems mostly happy (some warnings re: the .so symlinks, but that's about all.) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 11:31:55 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 06:31:55 -0500 Subject: [Bug 177106] Review Request: libgdgeda - graphical library for gEDA In-Reply-To: Message-ID: <200602101131.k1ABVtLf025467@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libgdgeda - graphical library for gEDA https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177106 ------- Additional Comments From wk at ire.pw.edu.pl 2006-02-10 06:31 EST ------- 1. OK, libgdgeda-devel put files into pkgconfig directory so the dependency is necessary. 2. I was not sure that if package owns a directory then it owns everything inside. There is some risk of strange files getting into a package, if the files are named in %files you have more control what is packaged. 3 OK, I will make a test with --disable-static. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 10 12:03:26 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 07:03:26 -0500 Subject: [Bug 177107] Review Request: libgeda - library for gEDA circuit design software In-Reply-To: Message-ID: <200602101203.k1AC3Qgg029762@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libgeda - library for gEDA circuit design software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177107 ------- Additional Comments From wk at ire.pw.edu.pl 2006-02-10 07:03 EST ------- 1. Finished library has autogenerated dependence on ldconfig. Does it need extra dependency for install/uninstal? Dependency on install-info is not autogenerated so it may be good to include it explicitely. I will look into other packages having info files. 2. Some half of existing packages have those sections without empty line between them. I have not seen any problem so far. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 10 12:44:31 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 07:44:31 -0500 Subject: [Bug 180897] New: Review Request: heartbeat Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 Summary: Review Request: heartbeat Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: fedora at soeterbroek.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.soeterbroek.com/linux/fedora/extras/heartbeat/heartbeat.spec SRPM Name or Url: http://www.soeterbroek.com/linux/fedora/extras/heartbeat/heartbeat-2.0.2-1.src.rpm Description: Heartbeat subsystem for High-Availability Linux -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 12:45:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 07:45:52 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602101245.k1ACjqnh004967@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From fedora at soeterbroek.com 2006-02-10 07:45 EST ------- Still generates a number of rpmlint errors and warnings. Need help on determining which are valid and which can be safely ignored. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rdieter at math.unl.edu Fri Feb 10 12:58:08 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 10 Feb 2006 06:58:08 -0600 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: <1139446405.3380.54.camel@localhost> References: <1138905153.3411.34.camel@localhost> <1138999755.3377.22.camel@localhost> <1139446405.3380.54.camel@localhost> Message-ID: Toshio Kuratomi wrote: >>dekstop-file-utils doesn't seem to have either a dependency into the >>Core of Gnome or a scriptlet to care for the case where it is installed >>later so even though this seems like a valid concept, those issues >>should be resolved first. >> > > I didn't change this one. Rex, have you opened an RFE in bugzilla to > change desktop-file-utils and get something to depend on it? Here ya go, looks like we were pretty close already: desktop-file-utils: %post: update-desktop-database http://bugzilla.redhat.com/bugzilla/180898 shared-mime-info: missing Requires(post): desktop-file-utils http://bugzilla.redhat.com/bugzilla/180899 -- Rex From bugzilla at redhat.com Fri Feb 10 13:34:05 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 08:34:05 -0500 Subject: [Bug 177107] Review Request: libgeda - library for gEDA circuit design software In-Reply-To: Message-ID: <200602101334.k1ADY58G012326@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libgeda - library for gEDA circuit design software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177107 ------- Additional Comments From rc040203 at freenet.de 2006-02-10 08:33 EST ------- (In reply to comment #3) > 1. Finished library has autogenerated dependence on ldconfig. Does it need > extra dependency for install/uninstal? Yes. You are using scriptlets consisting of multiple lines. For these, explicit Requires(...) on all tools being used inside are necessary. > 2. Some half of existing packages have those sections without empty line > between them. I have not seen any problem so far. Check the output of "rpm -q --scripts" on your package. There have been cases where rpm "lumped together" such scripts into one script. This had caused sporatic installation/deinstallation errors. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rdieter at math.unl.edu Fri Feb 10 14:20:58 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 10 Feb 2006 08:20:58 -0600 Subject: dxpc needs a new home Message-ID: As I no longer actively use dxpc, I've added it to the the "potentially orphaned packages" section of http://fedoraproject.org/wiki/Extras/OrphanedPackages -- Rex From mattdm at mattdm.org Fri Feb 10 14:43:52 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 10 Feb 2006 09:43:52 -0500 Subject: wxPython needs update? In-Reply-To: <1139511590.3366.9.camel@localhost> References: <1139507179.3366.4.camel@localhost> <1139511590.3366.9.camel@localhost> Message-ID: <20060210144352.GA24676@jadzia.bu.edu> On Thu, Feb 09, 2006 at 10:59:50AM -0800, Toshio Kuratomi wrote: > > wxGTK2 is 2.6, but wxPythonGTK2 seems to be 2.4. I'm talking about devel. > Oops. My mistake. You're mostly interested in this bug, then: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163440 > which says Matthew is probably going to wait a couple weeks for some > build fixes in 2.6.3. Yep -- thanks Toshio. I'm probably also going to rename "wxPythonGTK2" back to wxPython (to keep with the standard naming conventions). I also do plan to backport this to FC4 based on popular demand, but not before the wxPython thing is straightened out. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dennis at ausil.us Fri Feb 10 15:01:34 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 10 Feb 2006 09:01:34 -0600 Subject: extras maintainence Message-ID: <200602100901.34790.dennis@ausil.us> Hi all, Some people are waiting to make fc3 extras end of life. I personally have a huge interest in fc3 extras not become stale and unmaintained. I have rebuilt all of extras for Aurora SPARC Linux* (except a few packages that have not built successfully) Aurora's latest build is based on fc3 which is why i have based the extras packages on the same. It is currently in beta status so i will be maintaining extras packages for awhile. I can understand that some maintainers do not want to support fc3 anymore. however I personally believe we should maintain support at least until Fedora Legacy no longer supports fc3 alot of users that use legacy will have extras packages installed also. for example i have 3 servers running fc3 at work and i have a file/ asterisk server at home running fc3. I use clamav and amavisd-new on the ones at work. What does this mean? extras and core need to be considered as one not two entities, both needing maintainence for the same period of time how do we do this? We have two options, one) existing package maintainers need to maintain there packages until legacy no longer supports a release. but a stipulation could be made that once a release moves to legacy the only updates in extras are bugfixes and security related. two) we create an extras legacy team, who would then take over maintainership of all extras packages once a release moves to legacy. though if a package maintainer wanted to continue support of his/her packages that would be beneficial. So which way are we going to move forward -- Regards Dennis Gilmore, RHCE Proud Australian * http://www.auroralinux.org * http://fedoramirror.net From jspaleta at gmail.com Fri Feb 10 15:29:30 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 10 Feb 2006 10:29:30 -0500 Subject: extras maintainence In-Reply-To: <200602100901.34790.dennis@ausil.us> References: <200602100901.34790.dennis@ausil.us> Message-ID: <604aa7910602100729l135560ak1ec710b15bf1710b@mail.gmail.com> On 2/10/06, Dennis Gilmore wrote: > how do we do this? We have two options, > one) existing package maintainers need to maintain there packages until legacy > no longer supports a release. but a stipulation could be made that once a > release moves to legacy the only updates in extras are bugfixes and security > related. I do not think this is wise nor do I think this is a workable option. I think making this a requirement for all package maintainers to have to track legacy releases will mean less maintainers over time. > two) we create an extras legacy team, who would then take over > maintainership of all extras packages once a release moves to legacy. > though if a package maintainer wanted to continue support of his/her packages > that would be beneficial. I think this is the only way forward and the most flexible option. People interested in maintaining things into legacy status should be the ones responsible for those legacy branches. I'd have no problem ceding "ownership" of legacy branches to people interested in maintaining legacy packages. And along these lines, I'm in favor of package maintainers registering their intent to support or not support legacy branches upfront when they submit the packages for review. That we know as early as possible whether or not a package is going to need to change hands on legacy status, instead of scrambling to determine if the original maintainer is still interested in legacy branches or not. Knowing if a package is going to need a legacy maintainer on package submission, gives the legacy team some time to recruit or allocate volunteers for those packages if there is a need or it gives the legacy team enough time to plan a list of orphan/expire subsets of packages if it becomes clear some packages are unmaintainable with available resources. -jef From bugzilla at redhat.com Fri Feb 10 15:35:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 10:35:53 -0500 Subject: [Bug 180205] Review Request: gnome-menu-editor In-Reply-To: Message-ID: <200602101535.k1AFZrnO000344@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-menu-editor https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180205 bugs.michael at gmx.net changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |177841 nThis| | ------- Additional Comments From bugs.michael at gmx.net 2006-02-10 10:35 EST ------- Missing at least BuildRequires: libxml2-devel gnome-vfs2-devel gnome-menus-devel libgnome-menu >= 2.11.1 makes this for FC >= 5. > BuildRequires: gnome-vfs2 should be: gnome-vfs2-devel -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 15:39:03 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 10:39:03 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602101539.k1AFd3dg001050@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From tibbs at math.uh.edu 2006-02-10 10:39 EST ------- Build fails for me on FC-4 i386 in send_arp.c; I'll attach a log. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 16:07:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 11:07:15 -0500 Subject: [Bug 176733] Review Request: php-pear-DB (PEAR database abstraction layer) In-Reply-To: Message-ID: <200602101607.k1AG7F07007693@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-pear-DB (PEAR database abstraction layer) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176733 ------- Additional Comments From rpm at timj.co.uk 2006-02-10 11:07 EST ------- In the absence of any feedback I've changed the path for the package XML file to libdir/php/pear in CVS and there is a build job running now. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From nicolas.mailhot at laposte.net Fri Feb 10 16:19:02 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 10 Feb 2006 17:19:02 +0100 (CET) Subject: extras maintainence In-Reply-To: <200602100901.34790.dennis@ausil.us> References: <200602100901.34790.dennis@ausil.us> Message-ID: <57294.192.54.193.25.1139588342.squirrel@rousalka.dyndns.org> Le Ven 10 f?vrier 2006 16:01, Dennis Gilmore a ?crit : > one) existing package maintainers need to maintain there packages until > legacy > no longer supports a release. but a stipulation could be made that once > a > release moves to legacy the only updates in extras are bugfixes and > security > related. > two) we create an extras legacy team, who would then take over > maintainership of all extras packages once a release moves to legacy. > though if a package maintainer wanted to continue support of his/her > packages > that would be beneficial. > > So which way are we going to move forward IMHO legacy maintenance should be left to legacy teams, maintaining extras for three releases (FCx, FCx-1 and rawhide) is already a lot to ask of FE contributors. That is, if you do not want FE to shrink radically. -- Nicolas Mailhot From pmatilai at laiskiainen.org Fri Feb 10 16:36:00 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 10 Feb 2006 18:36:00 +0200 Subject: Summary - Broken dependencies in Fedora Extras development In-Reply-To: <200602081150.k18BoQql029835@mx3.redhat.com> References: <200602081150.k18BoQql029835@mx3.redhat.com> Message-ID: <1139589361.2721.7.camel@weasel.turre.laiskiainen.org> On Wed, 2006-02-08 at 06:50 -0500, Michael Schwendt wrote: > And another try... > > Summary of broken packages in fedora-extras-development-i386: > ---------------------------------------------------------------------- > apt 0.5.15cnc7-7.fc5.i386 > apt-groupinstall 0.5.15cnc7-7.fc5.i386 Apt itself only would need a rebuild, apt-groupinstall needs to die because comps package doesn't exist anymore and while it's possible to make groupinstall fetch comps.xml from a remote location rhpl.Comps doesn't at least fully grok the new comps format in fc5 so .. time to just kill it I guess. Groupinstall removed, and apt itself updated to my bleeding-edge multilib capable fork of apt-rpm: http://laiskiainen.org/apt/testing/apt-0.5.15lorg2-2.src.rpm sha1sum: 2fc2d80c57e48d2c5b76a37f7dd5440a6b9a966b If somebody could update the devel-tree apt to this version I'd appreciate. Oh and Synaptic will need a rebuild as well against the new version. - Panu - From toshio at tiki-lounge.com Fri Feb 10 16:39:41 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 10 Feb 2006 08:39:41 -0800 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: References: <1138905153.3411.34.camel@localhost> <1138999755.3377.22.camel@localhost> <1139446405.3380.54.camel@localhost> Message-ID: <1139589581.3394.3.camel@localhost> On Fri, 2006-02-10 at 06:58 -0600, Rex Dieter wrote: > Toshio Kuratomi wrote: > > Rex, have you opened an RFE in bugzilla to > > change desktop-file-utils and get something to depend on it? > > Here ya go, looks like we were pretty close already: > desktop-file-utils: %post: update-desktop-database > http://bugzilla.redhat.com/bugzilla/180898 Okay -- I added a note on ScriptletSnippets for now that it will be changed to not use Require: in the future but for now we're awaiting the outcome of some bugs. > shared-mime-info: missing Requires(post): desktop-file-utils > http://bugzilla.redhat.com/bugzilla/180899 Are you sure about this one? update-mime-database comes from shared-mime-info, not desktop-file-utils. -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 rc040203 at freenet.de Fri Feb 10 17:14:15 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 10 Feb 2006 18:14:15 +0100 Subject: extras maintainence In-Reply-To: <604aa7910602100729l135560ak1ec710b15bf1710b@mail.gmail.com> References: <200602100901.34790.dennis@ausil.us> <604aa7910602100729l135560ak1ec710b15bf1710b@mail.gmail.com> Message-ID: <1139591656.1084.222.camel@mccallum.corsepiu.local> On Fri, 2006-02-10 at 10:29 -0500, Jeff Spaleta wrote: > On 2/10/06, Dennis Gilmore wrote: > > how do we do this? We have two options, > > one) existing package maintainers need to maintain there packages until legacy > > no longer supports a release. but a stipulation could be made that once a > > release moves to legacy the only updates in extras are bugfixes and security > > related. > I do not think this is wise nor do I think this is a workable option. > I think making this a requirement for all package maintainers to have > to track legacy releases will mean less maintainers over time. IMO, you are missing one important point: FE is a volunteer effort, so there are no requirements to make. FE-maintainers update/upgrade packages at their personal will and disposition. Therefore (besides of mere technical constrains) maintainers are abandoning "older releases" for personal reasons, completely independent of the point in time an FC release is discontinued _by RH_. > > two) we create an extras legacy team, who would then take over > > maintainership of all extras packages once a release moves to legacy. > > though if a package maintainer wanted to continue support of his/her packages > > that would be beneficial. > > I think this is the only way forward and the most flexible option. I don't think so. The most flexible solution would be * continuation and seamless integration of "Legacy and Extras", i.e. not to formally split "Legacy and Extras" and the people behind them. * cooperation/teaming up between those folks who are more interested in older releases ("Legacy team") and upstream ("Extras maintainers"), i.e. not to formally "pass ownership", but to collaborate and share package maintenance. In short: We are volunteers, and if volunteers want to do something, you shouldn't prevent them from doing it - You should make it as easy as possible, otherwise they will feel peed. Example: I don't have a problem in continuing maintenance of some packages for FE3 for some time, until _I_ am loosing interest, but I am not interested putting the burdon a legacy project would additionally impose on me. Ralf From jspaleta at gmail.com Fri Feb 10 17:42:19 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 10 Feb 2006 12:42:19 -0500 Subject: extras maintainence In-Reply-To: <1139591656.1084.222.camel@mccallum.corsepiu.local> References: <200602100901.34790.dennis@ausil.us> <604aa7910602100729l135560ak1ec710b15bf1710b@mail.gmail.com> <1139591656.1084.222.camel@mccallum.corsepiu.local> Message-ID: <604aa7910602100942l71b5d33dt3620b1714cb752f2@mail.gmail.com> On 2/10/06, Ralf Corsepius wrote: > In short: We are volunteers, and if volunteers want to do something, you > shouldn't prevent them from doing it - You should make it as easy as > possible, otherwise they will feel peed. Volunteer fire fighers don't get to do whatever they want.. Volunteers for the special olympics don't get to do whatever they want. Many examples of volunteers in the brick and mortar world have a code of conduct and lay out a set of responsibilities and obligations associated with the volunteer work which volunteers agree to comply with, partly to discourage lackluster and irresponsible volunteers from participating and detracting from the overall effort. Its not unreasonable to discuss the responsibilities and expectations on volunteer packagers in the context of the overall goals. > Example: I don't have a problem in continuing maintenance of some > packages for FE3 for some time, until _I_ am loosing interest, but I am > not interested putting the burdon a legacy project would additionally > impose on me. I think its quite fair to ask all maintainers to pledge to maintainership for a package on the timescales of specific releases to be honest about what their commitment is to the project... upfront. If a maintainer is only interested in maintaining a package in Extras for the latest Core release..we should know that.. upfront... so other people in the project can prepare to take over maintainership at the appropriate time. And I don't think its in this project's best interest to encourage packagers show up, build a package, and then lose interest in that package within a month and orphan it. I think there should be accountability for atleast a release for ALL packages from ALL maintainers, and if a maintainer has personal issues which makes it impossible to meet the expectation for maintainence for atleast one standard Core release.. then perhaps that packager shouldn't be volunteering for this project. And I don't think its in the project's best interest to encourage maintainers to lose interest part way through fc3's "legacy" process. I think we should be asking maintainers to be explicit about the timescales over which they are willing to make the effort over defined chunks of time and holding them to those estimates. Its going to save us lots of effort down the road scrambling to replace maintainers as they orphan packages willy-nilly. I think there should be clearly established points at which dropping maintainership for a package is encouraged so other people can plan their time to pick up maintainership of packages they are interested in and to discourage dropping maintainership between those time points. 6 month periods or something. Every six months or so, we do a general shout out to all maintainers and ask them to re-affirm if they are going to be maintaining their packages for the next 6 months. If they can't honestly commit to that, then other people can plan on taking over the co-maintainership of those packages to prevent a gap for any package. Its called planning. Many volunteer organizations have accountability mechanisms which rely on explicitly defined expectations as to how much work individual volunteers are pledging to do when they join the organization. There is no reason that a discussion about the expectation for volunteers in this project cannot happen. -jef From bugzilla at redhat.com Fri Feb 10 18:25:37 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 13:25:37 -0500 Subject: [Bug 180052] Review Request: evas: A hardware-accelerated canvas API In-Reply-To: Message-ID: <200602101825.k1AIPb17003279@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: evas: A hardware-accelerated canvas API https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180052 eric.tanguy at univ-nantes.fr changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bugzilla-sink at leemhuis.info |eric.tanguy at univ-nantes.fr OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From eric.tanguy at univ-nantes.fr 2006-02-10 13:25 EST ------- Review for release 1: * RPM name is OK * Source evas-0.9.9.023.tar.gz is the same as upstream * This is the latest version * Builds fine in mock * rpmlint of evas-devel looks OK * rpmlint of evas looks OK * File list of evas-devel looks OK * File list of evas looks OK * Work fine APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From fedora at leemhuis.info Fri Feb 10 18:45:32 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 10 Feb 2006 19:45:32 +0100 Subject: Summary from yesterdays FESCo-Meeting Message-ID: <1139597132.2967.20.camel@localhost.localdomain> Full log: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060209 === Summary === Present from Fesco: thl, jpo, skvidal, Sopwith, jeremy, mschwendt, scop, thomasvs, f13 Tasks: * Fedora Extras RPMs should have Vendor and Packager Sopwith and skvidal will make sure that the following will be be added to the buildsystems: {{{ Vendor: Fedora Extras Packager: Fedora Extras }}} * Mass rebuild of Extras for FC5 A separate mail will follow. This is the rough version: Can probably start on Sunday (February 12). Method: All packagers will take care of their to rebuild their own packages. Means: Increase release, put a comment like "Rebuild for FC5" in the changelog and request build. We're ignoring dep-order this way, but that works fine in core, too. It's to late for a better solution, but if anybody has problem with that please prepare a proposal how to do mass builds in the future. Orphaned packages will be removed before the rebuild starts. Rebuilds only for FE5 of course -- rebuilding packages in FE4 also just to keep the spec files in all branches in sync is stupid because it would mean unneeded updates/downloads for Extras users. Please only rebuild the packages you own! Branching for FE6 will probably happen at the same time as in rawhide. Still unsure (Comments please!): * what do we do with packages where no maintainer steps up to request builds? Jeremy suggest "and when we get to FC5 - 2 weeks or so, we can step in for things that haven't been touch if needed". Or do we remove them and consider them orphaned if we don't hear *anything* from the maintainers after a bug was opened and nothing happened for one or two weeks? * Packages not rebuild before the 12th of February will be removed before FC5 is shipped to start with a clean tree with old cruft removed. * Encourage Extras reviews Some SIG's were created and already started to work -- see http://www.fedoraproject.org/wiki/Extras/SIGs The whole thing is a bit unorganized ATM. We don't need to many rules to organize a SIG, but we probably need *some*. Some parts of the discussions: {{{ 19:27 < jpo> | perl draft page: http://www.fedoraproject.org/wiki/Extras/SIGs/Perl 19:28 < mschwendt> | jwb: SIGs need "goals" at least. 19:31 < mschwendt> | http://www.fedoraproject.org/wiki/Extras/SIGs/Games 19:31 < mschwendt> | There's some content. 19:31 < mschwendt> | But they don't say "how" they work. 19:32 < thl> | mschwendt, I agree that we should work more on that stuff 19:32 < thl> | mschwendt, see also https://www.redhat.com/archives/fedora-extras-list/2006-February/msg00482.html 19:32 < nirik> | I was imaging SIG's would be a group that would help in package questions and reviews for the groups type of packages. 19:32 < mschwendt> | thl: see the two "Up for review" entries on the SIGs/Games page 19:33 < mschwendt> | thl: good posting - sums up a few good points 19:33 < nirik> | yeah, linking to bugs in review/new for packages in that SIG would be usefull. Then people in that group or interested in it could notice and do reviews. ;) 19:33 < thl> | mschwendt, but nobody answered :-| 19:34 < mschwendt> | thl: sounds like we need a template Wiki page 19:35 < thl> | mschwendt, we need sombody that organizes the SIG idea in general 19:35 < thl> | anyone interested in that job? 19:35 < mschwendt> | not necessarily 19:35 < mschwendt> | a few people have started working in the Wiki already 19:35 < mschwendt> | it just needs more time 19:35 < mschwendt> | and a bit of guidance perhaps 19:35 < thl> | mschwendt, agreed 19:36 < thl> | but some guidance would really be helpful imho }}} nirik suggested 'package review days'. We'll try this out and see how it works: {{{ 19:30 < nirik> | shall I move forward with trying to setup a package review day (modeled on the bug review days that have been done in the past)? 19:30 < nirik> | perhaps sometime next week? 19:32 < nirik> | thl: ok. Will try and send something to the list to start it rolling. }}} * EOL Policy for FE Still under discussion. See the full log for all details. Highlights: {{{ 19:40 < mschwendt> | we cannot offer an old FE which is out-of-date or possible insecure at least partially 19:43 < jwb> | mschwendt, by EOL you mean what exactly? 19:43 < mschwendt> | sometime after release of FE5? 19:43 < mschwendt> | jwb: to inform the user community about the "state of support/maintenance" of a version of FE 19:44 < jwb> | yeah, the "state of support/maintenance" is what i'm asking about. do you mean none of that by EOL, or do you mean security/bug fixes? 19:44 < mschwendt> | jwb: the latter -- if package maintainers move forward to FC4/FC5 and don't care about FE3 anymore, it becomes out-of-date/insecure and so on 19:44 < mschwendt> | it would be a disservice to the community to pretend that it's as maintained as FE4/FE5 19:47 < thl> | we really should move the discussion to the fedora-extras-list 19:52 < dgilmore> | i have a great intrest in maintaing fc3 extras 19:52 < jwb> | the entire thing? 19:53 < dgilmore> | jwb: yes i have rebuilt Fc3 extras for Aurora Linux 19:53 < mschwendt> | dgilmore: the thing is, in order to be a bit more on the quality-side (the safe side) it may be necessary to volunteers to build a Fedora Extras Legacy Team. 19:53 < thl> | dgilmore, could you take care that the EOL discussion goes to the list? 19:54 < dgilmore> | thl: yes i will do }}} * Broken deps report Waiting for further discussion on the list. * Weekly sponsorship nomination Andreas Bierfert (awjb) was nominated and accepted. BTW, It seems some people hesitate to nominate people in a public IRC channel. Therefore I'll modify the process slightly: FESCo-Members will discuss nominations directly on the FESCo-mailinglist in the future. If other sponsors or Extras packagers want to nominate someone just drop me a mail and I'll forward it. Okay for everybody? * Kernel module standardization What remains to be done? buildsys :( thl will try to get this moving again. CU thl P.S.: Is this slightly new format okay for everybody? I think some people won't like the long lines, but without them the parts from the IRC-Log are totally unreadable. And most lines are not that long. -- Thorsten Leemhuis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugzilla at redhat.com Fri Feb 10 18:59:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 13:59:56 -0500 Subject: [Bug 180422] Review Request: gnome-mud In-Reply-To: Message-ID: <200602101859.k1AIxu0N009677@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-mud https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180422 ------- Additional Comments From toshio at tiki-lounge.com 2006-02-10 13:59 EST ------- > 3. Unpackaged files: %{_datadir}/gnome/help/gnome-mud/C/monitor.py[co]. Not sure > if they should be ghosted. Possibly ghosted, possibly left out altogether (by rm'ing them in %install). It looks like monitor.py is documentation, not as something that should be run. The monitor.py file itself should probably not be exceutable as it is documentation. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From jamatos at fc.up.pt Fri Feb 10 19:10:19 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Fri, 10 Feb 2006 19:10:19 +0000 Subject: Package adoption Message-ID: <200602101910.19401.jamatos@fc.up.pt> Hi, I would like to adopt: - conglomerate - sodipodi - wesnoth Does anyone objects? -- Jos? Ab?lio From bugzilla at redhat.com Fri Feb 10 19:18:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 14:18:28 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602101918.k1AJISSf013712@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |180952 ------- Additional Comments From tibbs at math.uh.edu 2006-02-10 14:18 EST ------- BTW, I can't build in mock either, because libnet10 and libnet-devel conflict. I've opened bug 180952, which I'll add as a blocker for this one. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From mmcgrath at fedoraproject.org Fri Feb 10 19:32:56 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 10 Feb 2006 13:32:56 -0600 Subject: Summary from yesterdays FESCo-Meeting In-Reply-To: <1139597132.2967.20.camel@localhost.localdomain> References: <1139597132.2967.20.camel@localhost.localdomain> Message-ID: <43ECEA68.8050202@fedoraproject.org> > Still unsure (Comments please!): > * what do we do with packages where no maintainer steps up to request >builds? Jeremy suggest "and when we get to FC5 - 2 weeks or so, we can >step in for things that haven't been touch if needed". Or do we remove >them and consider them orphaned if we don't hear *anything* from the >maintainers after a bug was opened and nothing happened for one or two >weeks? > > I'll get this ball rolling. I think what might be worth doing here is figuring out a Fedora policy about our software lifecycle. Core has a fairly clear policy. Once FC5 got to test 2, FC3 went to legacy. At present that's a FC policy. Should we adapt that to all things Fedora? I think what we really need is just as clear of a policy that applies to all of our Fedora software including Extras, Core and any projects that might get added later. We should keep it simple for our users so they can easily follow it. But we should have a very serious conversation about it. I know a lot of people out there don't really like FC's release cycle. I also think it would make it harder for the Fedora Legacy project to take on FC and FE once a cycle changes. But since FC's release cycle is so quick we need to come up with something that will work for *MOST* people involved. This includes the users, contributers, maintainers, developers, etc. We won't be able to please everyone here. I, for one, like Ubuntu's release cycle. If I remember correctly it has a new release every 6 months with each release being supported for 2 years. I'm sure not everyone will like/agree with this release cycle but I thought I'd throw it out there :-D -Mike From bugzilla at redhat.com Fri Feb 10 20:02:58 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 15:02:58 -0500 Subject: [Bug 179802] Review Request: seamonkey In-Reply-To: Message-ID: <200602102002.k1AK2wqe023149@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: seamonkey https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179802 ------- Additional Comments From kengert at redhat.com 2006-02-10 15:02 EST ------- > - Is this really distributed under NPL/MPL? Yes it is, I explicitly asked on irc.mozilla.org #seamonkey. In addition, SeaMonkey's about page says "Mozilla Public License and Netscape Public License" > - Lose the Prefix: tag removed Not sure which of all the changes were the culprit, but I got build failures, I had to replace some %{prefix} statements to make it work again. > - Don't BuildRequire autoconf213; if you make changes to configure, include that > part in the patch I think that request makes package maintenance a bit inconvenient, but you probably have a good reason to suggest that. removed > - Remove the ExclusiveArch. You are including all of our current platforms, and > it probably builds on others that we don't. removed > - You probably ought to have the FindExternalProvides stuff that the Firefox and > Thunderbird package does. Since the libraries provided aren't versioned, this > can cause problems when two packages provide the same libraries (mozilla also > provides these for now, and when xulrunner eventually takes over, it will do so). I'm confused, because you mention FindExternal and Provides in one word, but I can't find such a thing in the TB and FF spec files. Are you suggesting to add the following 3 lines? AutoProv: 0 %define _use_internal_dependency_generator 0 %define __find_requires %{SOURCE100} That's what I did. But I ended up with a depency problem, although package "seamonkey" contained libxpcom_core.so, package "seamonkey-mail" complained that lib can't be found. Therefore I set AutoProv to on, that made it work, but we again have lots of provides. Is that ok, or do you suggest a different way to fix it? > - I think you can safely remove the conditional for desktop_file, unless you > really want to push this to really old releases (I think FC1 needed it, newer > don't). removed %define desktop_file 1 and all conditionals and all "else" portions. > - Without a GRE, the -devel package should arguably not be built since that is a > key part of the -devel platform. Ok, removed for now, as the primary intention is indeed to provide the application. We can re-add it in a future package version, if required. > - regxpcom is no longer required. This (and the entire block surrounding it) > should go away. > - seamonkey-rebuild-databases should not be needed removed, also removed ldconfig commands > - Your comment about cp -L doesn't seem needed. It wasn't my comment, it's a leftover from mozilla.spec. removed > - Since this is for Fedora Extras, you probably shouldn't name the default > pref/bookmarks files with redhat :-) Renamed the files from "mozilla-redhat-" to "seamonkey-fedora-". Also changed the bookmarks file to match your firefox bookmarks file. > - I don't think selinux/chcon stuff should be in this specfile. Is there a bug > you are trying to work around? My rawhide system runs with selinux enabled. It failed during build, and using chcon was the only fix I found. But now that regxpcom is no longer necessary, chcon isn't either. I have now removed both regxpcom and chcon, and have been able to build on the rawhide system. > - Use a .mozconfig file (see what I do in the firefox package). This will make > it easier to do development with the same flags with a different tree (just copy > the mozconfig over) Ok, done. Motivated by your proposal, I tried to use the same build code as used in the firefox spec file. But that failed, I got errors in install stage, the pathes were incorrect. So I decided to continue to use the current build commands, and only moved the compilation configure options to mozconfig. I guess that's sufficient to satisfy your request. > - The following are installed with +x and shouldn't be. Using a %defattr in > %files with the appropriate modes will fix this. The mozilla 1.7.x package does the same thing! The statement currently in use is %defattr(-,root,root). I think we must not chance the modes for most of the files, so your request means, we'd have to filter the *.js files from the "list of files" and use explicit %defattr(644) statements for them. Do you want me to hack "sed/grep" code to change the file lists? Or should we use some "find" statements to change the modes before they are copied? Or do you have a better idea? Other changes: - capitalize M in SeaMonkey - use official 1.0 release source tarball New SPEC file: http://kuix.de/mozilla/seamonkey/1.0-4/src/seamonkey.spec New SRPM file: http://kuix.de/mozilla/seamonkey/1.0-4/src/seamonkey-1.0-4.src.rpm Note, if you want to download at the SOURCES without downloading the .src.rpm, look here: http://kuix.de/mozilla/seamonkey/1.0-4/src/ -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 20:21:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 15:21:07 -0500 Subject: [Bug 179802] Review Request: seamonkey In-Reply-To: Message-ID: <200602102021.k1AKL7Xg027066@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: seamonkey https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179802 ------- Additional Comments From caillon at redhat.com 2006-02-10 15:21 EST ------- (In reply to comment #4) > > - Don't BuildRequire autoconf213; if you make changes to configure, include that > > part in the patch > > I think that request makes package maintenance a bit inconvenient, > but you probably have a good reason to suggest that. > removed Mozilla's build inadequacies is their problem. The only reason we have this package at all is because mozilla still needs it to generate configure. There's no need to force this requirement on people who simply want to build an SRPM. > > - You probably ought to have the FindExternalProvides stuff that the Firefox and > > Thunderbird package does. Since the libraries provided aren't versioned, this > > can cause problems when two packages provide the same libraries (mozilla also > > provides these for now, and when xulrunner eventually takes over, it will do so). > > I'm confused, because you mention FindExternal and Provides in one word, > but I can't find such a thing in the TB and FF spec files. > Are you suggesting to add the following 3 lines? > AutoProv: 0 > %define _use_internal_dependency_generator 0 > %define __find_requires %{SOURCE100} > That's what I did. > > But I ended up with a depency problem, although package "seamonkey" contained > libxpcom_core.so, package "seamonkey-mail" complained that lib can't be found. > Therefore I set AutoProv to on, that made it work, but we again have > lots of provides. Is that ok, or do you suggest a different way to fix it? Does it work if you Require: seamonkey (it should be Require anyway, and please one Require per line.) > > - Use a .mozconfig file (see what I do in the firefox package). This will make > > it easier to do development with the same flags with a different tree (just copy > > the mozconfig over) > > Ok, done. Motivated by your proposal, I tried to > use the same build code as used in the firefox spec file. > But that failed, I got errors in install stage, What specific errors? > The mozilla 1.7.x package does the same thing! Yeah, its a bug that we need to fix there, too. Don't copy over bugs :-) > The statement currently in use is %defattr(-,root,root). > I think we must not chance the modes for most of the files, > so your request means, we'd have to filter the *.js files > from the "list of files" and use explicit %defattr(644) statements for them. > Do you want me to hack "sed/grep" code to change the file lists? > Or should we use some "find" statements to change the modes before they > are copied? Or do you have a better idea? I think either solution is probably sufficient. Will look at the rest over the weekend. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 20:30:46 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 15:30:46 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602102030.k1AKUkSV029583@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From fedora at soeterbroek.com 2006-02-10 15:30 EST ------- Rebuild - removed BuildRequires libnet-devel Spec Name or Url: http://www.soeterbroek.com/linux/fedora/extras/heartbeat/heartbeat.spec SRPM Name or Url: http://www.soeterbroek.com/linux/fedora/extras/heartbeat/heartbeat-2.0.2-2.src.rpm Description: Heartbeat subsystem for High-Availability Linux Jason, Can you uninstall libnet-devel and try again? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 20:36:23 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 15:36:23 -0500 Subject: [Bug 179802] Review Request: seamonkey In-Reply-To: Message-ID: <200602102036.k1AKaNdG031145@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: seamonkey https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179802 ------- Additional Comments From kengert at redhat.com 2006-02-10 15:36 EST ------- > > Ok, done. Motivated by your proposal, I tried to > > use the same build code as used in the firefox spec file. > > But that failed, I got errors in install stage, > > What specific errors? During install, the RPM build system tries to access a path that does not match what is produced in /var/tmp As it requires so much time to build, I was not motivated to make further attempts, but decided to go with the code that works. > Does it work if you Require: seamonkey (it should be Require anyway, and > please one Require per line.) You mean RequireS: instead of Prereq: ? Trying. > > Or should we use some "find" statements to change the modes before they > > are copied? Or do you have a better idea? > > I think either solution is probably sufficient. I found the existing spec has # fix permissions of the chrome directories /usr/bin/find . -type d -perm 0700 -exec chmod 755 {} \; || : I will add # We don't want JS files to be executable /usr/bin/find . -type f -name \*.js -exec chmod 644 {} \; || : and see if that works -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 20:50:14 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 15:50:14 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602102050.k1AKoEA3001702@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From tibbs at math.uh.edu 2006-02-10 15:50 EST ------- A mock build proceeds further than before, but the various confgure runs die because glib2-devel is not installed. Did you mean to BuildRequire: glib2-devel instead of glib-devel? A build attempt on an FC4 box with glib2-devel already installed fails as before in send_arp.c. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 20:54:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 15:54:50 -0500 Subject: [Bug 179802] Review Request: seamonkey In-Reply-To: Message-ID: <200602102054.k1AKsofl002842@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: seamonkey https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179802 ------- Additional Comments From kengert at redhat.com 2006-02-10 15:54 EST ------- > > Does it work if you Require: seamonkey (it should be Require anyway, and > > please one Require per line.) > You mean RequireS: instead of Prereq: ? > Trying. No, it still does not work. [root at kaiefast x86_64]# rpm -ivh seamonkey-1.0-5.x86_64.rpm seamonkey-mail-1.0-5.x86_64.rpm error: Failed dependencies: libxpcom_core.so()(64bit) is needed by seamonkey-mail-1.0-5.x86_64 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 20:58:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 15:58:07 -0500 Subject: [Bug 179802] Review Request: seamonkey In-Reply-To: Message-ID: <200602102058.k1AKw7UY003486@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: seamonkey https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179802 ------- Additional Comments From kengert at redhat.com 2006-02-10 15:58 EST ------- > > - The following are installed with +x and shouldn't be. > > I will add > # We don't want JS files to be executable > /usr/bin/find . -type f -name \*.js -exec chmod 644 {} \; || : > and see if that works Yes, that worked fine. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 20:59:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 15:59:49 -0500 Subject: [Bug 180205] Review Request: gnome-menu-editor In-Reply-To: Message-ID: <200602102059.k1AKxn67003872@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-menu-editor https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180205 ------- Additional Comments From splinux25 at gmail.com 2006-02-10 15:59 EST ------- I have make the changes, no problem for build with mock. Spec Name or Url: http://glive.tuxfamily.org/fedora/gnome-menu-editor/gnome-menu-editor.spec SRPM Name or Url: http://glive.tuxfamily.org/fedora/gnome-menu-editor/gnome-menu-editor-0.5-2.fc5.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 21:12:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 16:12:44 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602102112.k1ALCiYx006295@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From fedora at soeterbroek.com 2006-02-10 16:12 EST ------- (In reply to comment #6) > A build attempt on an FC4 box with glib2-devel already installed fails as before > in send_arp.c. Jason, Can you send me (or attach) the output of 'rpm -qa | sort' command on the FC4 box? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 21:24:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 16:24:11 -0500 Subject: [Bug 173035] Review Request: chmlib - Library for dealing with ITSS/CHM format files In-Reply-To: Message-ID: <200602102124.k1ALOBYn008940@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: chmlib - Library for dealing with ITSS/CHM format files https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173035 ------- Additional Comments From jpo at di.uminho.pt 2006-02-10 16:23 EST ------- Peter, As I didn't get any answer to my previous post I took the liberty of building chmlib for FC-4. Best regards, jpo -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 10 21:27:51 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 16:27:51 -0500 Subject: [Bug 173035] Review Request: chmlib - Library for dealing with ITSS/CHM format files In-Reply-To: Message-ID: <200602102127.k1ALRpg1009653@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: chmlib - Library for dealing with ITSS/CHM format files https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173035 ------- Additional Comments From jpo at di.uminho.pt 2006-02-10 16:27 EST ------- Hi, Is someone planning to submit and maintain one of these CHM viewers? * kchmviewer http://www.kchmviewer.net/ * xchm http://xchm.sourceforge.net/ * kchm http://kchm.sourceforge.net/ Regards, jpo -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 10 21:28:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 16:28:10 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602102128.k1ALSAC5009735@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From andreas at bawue.net 2006-02-10 16:28 EST ------- According to Peter in #173028 it would be okay for me to introduce ser into extras, given that some plugins are packaged as subpackages. Jeff? That's okay with you? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 21:41:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 16:41:44 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602102141.k1ALfi42012464@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 jeff at ollie.clive.ia.us changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|DUPLICATE | ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-10 16:41 EST ------- (In reply to comment #11) > According to Peter in #173028 it would be okay for me to introduce ser into > extras, given that some plugins are packaged as subpackages. > > Jeff? That's okay with you? Fine by me. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From Christian.Iseli at licr.org Fri Feb 10 21:47:09 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 10 Feb 2006 22:47:09 +0100 Subject: Summary from yesterdays FESCo-Meeting In-Reply-To: Your message of "Fri, 10 Feb 2006 19:45:32 +0100." <1139597132.2967.20.camel@localhost.localdomain> Message-ID: <200602102147.k1ALl9fL000651@mx1.redhat.com> fedora at leemhuis.info said: > Is this slightly new format okay for everybody? I like it. Thanks, Christian From bugzilla at redhat.com Fri Feb 10 21:43:46 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 16:43:46 -0500 Subject: [Bug 173028] Review Request: ser - SIP Express Router In-Reply-To: Message-ID: <200602102143.k1ALhkji012767@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - SIP Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173028 jeff at ollie.clive.ia.us changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |DUPLICATE ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-10 16:43 EST ------- *** This bug has been marked as a duplicate of 180345 *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 10 21:43:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 16:43:52 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602102143.k1ALhqEC012789@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-10 16:43 EST ------- *** Bug 173028 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 21:47:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 16:47:53 -0500 Subject: [Bug 180205] Review Request: gnome-menu-editor In-Reply-To: Message-ID: <200602102147.k1ALlrXs013805@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-menu-editor https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180205 ------- Additional Comments From bdpepple at ameritech.net 2006-02-10 16:47 EST ------- You still haven't corrected problems 2,3, and 5 from comment #8. Refer to wiki on how to correctly handle the desktop file. The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 22:55:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 17:55:59 -0500 Subject: [Bug 180205] Review Request: gnome-menu-editor In-Reply-To: Message-ID: <200602102255.k1AMtxeY025794@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-menu-editor https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180205 ------- Additional Comments From splinux25 at gmail.com 2006-02-10 17:55 EST ------- i have a problem with the desktop file. make[1]: Entering directory `/home/damien/rpmbuild/BUILD/gnome-menu-editor-0.5' make[2]: Entering directory `/home/damien/rpmbuild/BUILD/gnome-menu-editor-0.5' make[2]: Nothing to be done for `install-exec-am'. make[2]: Nothing to be done for `install-data-am'. make[2]: Leaving directory `/home/damien/rpmbuild/BUILD/gnome-menu-editor-0.5' make[1]: Leaving directory `/home/damien/rpmbuild/BUILD/gnome-menu-editor-0.5' + /usr/lib/rpm/redhat/find-lang.sh /var/tmp/gnome-menu-editor-0.5-2.fc5-root-damien gnome-menu-editor + desktop-file-install --vendor fedora --dir /var/tmp/gnome-menu-editor-0.5-2.fc5-root-damien/usr/share/applications --add-category X-Fedora --delete-original /var/tmp/gnome-menu-editor-0.5-2.fc5-root-damien/usr/share/applications/gnome-menu-editor.desktop /var/tmp/gnome-menu-editor-0.5-2.fc5-root-damien/usr/share/applications/fedora-gnome-menu-editor.desktop: error: value of key "OnlyShowIn" is a list of strings and must end with a semicolon desktop-file-install created an invalid desktop file! erreur: Mauvais status de sortie pour /var/tmp/rpm-tmp.75066 (%install) I don't understand, gnome-menu-editor have a .desktop, why remove this one and creat a new ? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 23:14:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 18:14:53 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602102314.k1ANErOW028382@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From andreas at bawue.net 2006-02-10 18:14 EST ------- Great. In that case, I suggest we'll wait a few more days for peter to respond to my request for clarification about packaging the pa, cpl-c and jabber plugins as a seperate package, and then do a final review of the spec. okay? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 23:22:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 18:22:47 -0500 Subject: [Bug 180205] Review Request: gnome-menu-editor In-Reply-To: Message-ID: <200602102322.k1ANMlHe029610@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-menu-editor https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180205 ------- Additional Comments From bdpepple at ameritech.net 2006-02-10 18:22 EST ------- (In reply to comment #12) > I don't understand, gnome-menu-editor have a .desktop, why remove this one and > creat a new ? We add the vendor & X-Fedora category to the file. Refer to the wiki. http://fedoraproject.org/wiki/Packaging/Guidelines#desktop -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From steve at silug.org Fri Feb 10 23:34:24 2006 From: steve at silug.org (Steven Pritchard) Date: Fri, 10 Feb 2006 17:34:24 -0600 Subject: Summary - Broken dependencies in Fedora Extras development In-Reply-To: <1139589361.2721.7.camel@weasel.turre.laiskiainen.org> References: <200602081150.k18BoQql029835@mx3.redhat.com> <1139589361.2721.7.camel@weasel.turre.laiskiainen.org> Message-ID: <20060210233424.GB22668@osiris.silug.org> On Fri, Feb 10, 2006 at 06:36:00PM +0200, Panu Matilainen wrote: > If somebody could update the devel-tree apt to this version I'd > appreciate. I have an interest in apt, so I'd be willing to do the update. In fact, I know I'm going to regret this, but I'd be willing to take over as "owner" (read "Panu proxy"), if there are no objections. 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 bugzilla at redhat.com Fri Feb 10 23:30:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 18:30:35 -0500 Subject: [Bug 180205] Review Request: gnome-menu-editor In-Reply-To: Message-ID: <200602102330.k1ANUZPw030693@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-menu-editor https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180205 ------- Additional Comments From bdpepple at ameritech.net 2006-02-10 18:30 EST ------- BTW, that error is due to an error in the desktop file included with the tarball. You need to create a patch to correct this, and should send it upstream so that it can be fixed in future versions. The reason this didn't show up in your prior specs, is because you didn't use desktop-file-install, which checks the desktop file for errors. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 10 23:33:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 10 Feb 2006 18:33:11 -0500 Subject: [Bug 176528] Review Request: MochiKit: A lightweight JavaScript library In-Reply-To: Message-ID: <200602102333.k1ANXBXM031267@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: MochiKit: A lightweight JavaScript library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176528 ------- Additional Comments From tibbs at math.uh.edu 2006-02-10 18:32 EST ------- Sorry for taking so long.... After seeing the Cacti package go in, I'll drop any objection I had to storing the files in /usr/share. And rpmlint only complains about the license, which is not an issue since the license is valid. So: No rpmlint blockers, just the end-of-line warning. Package meets naming and packaging guidelines. License is acceptable and matches License: tag. Specfile is properly named, legible, well-written, well-commented and uses macros consistently. Source file matches upstream. Package builds and installs on FC3 and FC4. I'd just like clarification on one thing. It's not common practise to install package tests under %doc (or even to install them at all). I understand that it's not really possible to execute those tests in any meaningful way at build time, but I wonder what your reasoning is behind including them in the final package. Examples are already included, so the tests don't really add much in the way of documentation. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rc040203 at freenet.de Sat Feb 11 05:57:49 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 11 Feb 2006 06:57:49 +0100 Subject: buildsys hangs? Message-ID: <1139637469.12023.106.camel@mccallum.corsepiu.local> Hi, May-be I am in error, but as it seems to me, the buildsystem currently hangs. Ralf From rc040203 at freenet.de Sat Feb 11 06:03:54 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 11 Feb 2006 07:03:54 +0100 Subject: extras maintainence In-Reply-To: <604aa7910602100942l71b5d33dt3620b1714cb752f2@mail.gmail.com> References: <200602100901.34790.dennis@ausil.us> <604aa7910602100729l135560ak1ec710b15bf1710b@mail.gmail.com> <1139591656.1084.222.camel@mccallum.corsepiu.local> <604aa7910602100942l71b5d33dt3620b1714cb752f2@mail.gmail.com> Message-ID: <1139637835.12023.113.camel@mccallum.corsepiu.local> On Fri, 2006-02-10 at 12:42 -0500, Jeff Spaleta wrote: > On 2/10/06, Ralf Corsepius wrote: > > In short: We are volunteers, and if volunteers want to do something, you > > shouldn't prevent them from doing it - You should make it as easy as > > possible, otherwise they will feel peed. > > Volunteer fire fighers don't get to do whatever they want.. [apples and oranges] > Its not > unreasonable to discuss the responsibilities and expectations on > volunteer packagers in the context of the overall goals. Face it: You can set up as many expectations and responsibilities as you want, but nobody around here is in a position to force any body to do anything. - If you do, it's the project who's going to loose. It's characteristic for OSS projects (and any volunteered project in general) that people come and go. > > Example: I don't have a problem in continuing maintenance of some > > packages for FE3 for some time, until _I_ am loosing interest, but I am > > not interested putting the burdon a legacy project would additionally > > impose on me. > > I think its quite fair to ask all maintainers to pledge to > maintainership for a package on the timescales of specific releases to > be honest about what their commitment is to the project... upfront. > If a maintainer is only interested in maintaining a package in Extras > for the latest Core release..we should know that It's happening all over the place. The reasons are simple: Maintainers' resources are limited, so maintainers restrict themselves to actively working the release they are actively using and try to avoid to touch anything that is not "reported to be broken" (The old: "don't try to fix what ain't broken") In the end you see a policy of "If it builds it goes to FC(n+1)", "If it seems to work it goes to FC(n)", "If a change is harmless it goes to FC(n-1), if it seems scary, it doesn't". Frankly speaking, I don't see what's wrong with this. > .. upfront... so other > people in the project can prepare to take over maintainership at the > appropriate time. > And I don't think its in this project's best interest to encourage > packagers show up, build a package, and then lose interest in that > package within a month and orphan it. That's why I, as long as Fedora exists, have been demanding to abandon the concept of "personal ownership" and to team up. An individual may have the "lead" and "last word" on maintaining a package, but he should not block others from improving/fixing a packages. Unfortunately this is what current FE's policy encourages and what currently is happening. > And I don't think its in the project's best interest to encourage > maintainers to lose interest part way through fc3's "legacy" process. Let me put it this way: You'd loose maintainers if you'd try to force people into maintaining a package for a release, they don't have any use for. Applying this thought on myself: I don't have a problem in "having an eye on a package for FC3 as part of FE", nor do I have any problem in people reporting problems with an FC3 package "I own", but you'd probably loose me if you force me to "actively maintain/test" or if you want to force me into "Fedora Legacy Project". > I think we should be asking maintainers to be explicit about the > timescales over which they are willing to make the effort over defined > chunks of time and holding them to those estimates. Its going to save > us lots of effort down the road scrambling to replace maintainers as > they orphan packages willy-nilly. I think there should be clearly > established points at which dropping maintainership for a package is > encouraged so other people can plan their time to pick up > maintainership of packages they are interested in and to discourage > dropping maintainership between those time points. 6 month periods or > something. Every six months or so, we do a general shout out to all > maintainers and ask them to re-affirm if they are going to be > maintaining their packages for the next 6 months. If they can't > honestly commit to that, then other people can plan on taking over the > co-maintainership of those packages to prevent a gap for any package. > Its called planning. As I said before, you can't force anybody around here. As in any other project run by volunteers, people show up and drop off for various reasons. I you'd try to commit them to anything, you'll loose people (c.f. how the CLA is perceived - It took me 1/2 a year of careful consideration to accept it, and I guess it caused many other willing people to refrain from participating). IMO, the only workaround is setting up teams, people can apply and (temporarily) subscribe/unsubscribe to. The SIGs currently being discussed and introduced, are a step into this direction. > Many volunteer organizations have accountability mechanisms which rely > on explicitly defined expectations as to how much work individual > volunteers are pledging to do when they join the organization. There > is no reason that a discussion about the expectation for volunteers in > this project cannot happen. c.f. above. You can't control us. If you try, the project looses. Ralf From bugzilla at redhat.com Sat Feb 11 07:31:51 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 11 Feb 2006 02:31:51 -0500 Subject: [Bug 180058] Review Request: ecore: An event and X abstraction layer In-Reply-To: Message-ID: <200602110731.k1B7VpBt031297@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ecore: An event and X abstraction layer https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180058 eric.tanguy at univ-nantes.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|bugzilla-sink at leemhuis.info |eric.tanguy at univ-nantes.fr OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From eric.tanguy at univ-nantes.fr 2006-02-11 02:31 EST ------- Review for release 1: * RPM name is OK * Source ecore-0.9.9.023.tar.gz is the same as upstream * Builds fine in mock * rpmlint of ecore-devel looks OK * rpmlint of ecore looks OK * File list of ecore-devel looks OK * File list of ecore looks OK * Run fine APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 11 07:58:43 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 11 Feb 2006 02:58:43 -0500 Subject: [Bug 172343] Review Request: libtomoe-gtk In-Reply-To: Message-ID: <200602110758.k1B7whSR001440@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libtomoe-gtk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172343 ------- Additional Comments From ryo-dairiki at users.sourceforge.net 2006-02-11 02:58 EST ------- Now it's okay. I've uploaded them on the stable place. SRPM: http://homepage2.nifty.com/shibatama/garage/libtomoe-gtk-0.1.0-4.src.rpm SPEC: http://homepage2.nifty.com/shibatama/garage/libtomoe-gtk.spec # I'm sorry to have trouble you, with the old repository. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 11 09:08:14 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 11 Feb 2006 04:08:14 -0500 Subject: [Bug 178709] Review Request: freehdl : GPLed free VHDL In-Reply-To: Message-ID: <200602110908.k1B98E8s013648@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: freehdl : GPLed free VHDL https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178709 ivazquez at ivazquez.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |ivazquez at ivazquez.net OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From ivazquez at ivazquez.net 2006-02-11 04:08 EST ------- - Missing Requires(post): /sbin/ldconfig The rest looks good to me. Fix that up then consider it APPROVED. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From green at redhat.com Sat Feb 11 09:13:31 2006 From: green at redhat.com (Anthony Green) Date: Sat, 11 Feb 2006 01:13:31 -0800 Subject: Circular dependencies Message-ID: <1139649212.3367.451.camel@localhost.localdomain> I've been forking a number of JPackage RPMS so they will build and run on our Free Software java stack. Unfortunately, these packages have circular dependencies. Is there any way to inject binary RPMs into the FE build system in order to bootstrap the loopy packages? Thanks, AG From lists at timj.co.uk Sat Feb 11 09:21:23 2006 From: lists at timj.co.uk (Tim Jackson) Date: Sat, 11 Feb 2006 09:21:23 +0000 Subject: Summary from yesterdays FESCo-Meeting In-Reply-To: <43ECEA68.8050202@fedoraproject.org> References: <1139597132.2967.20.camel@localhost.localdomain> <43ECEA68.8050202@fedoraproject.org> Message-ID: <43EDAC93.7050502@timj.co.uk> Mike McGrath wrote: > I'll get this ball rolling. I think what might be worth doing here is > figuring out a Fedora policy about our software lifecycle. Core has a > fairly clear policy. Once FC5 got to test 2, FC3 went to legacy. At > present that's a FC policy. Should we adapt that to all things Fedora? I'm going off at a tangent here, but as an FC/FE user and FE packager, I've always wondered where the reasoning behind this policy came from. Can anyone give me a pointer? Where would be the appropriate place to discuss it? Tim From rdieter at math.unl.edu Fri Feb 10 17:23:55 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 10 Feb 2006 11:23:55 -0600 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: <1139589581.3394.3.camel@localhost> References: <1138905153.3411.34.camel@localhost> <1138999755.3377.22.camel@localhost> <1139446405.3380.54.camel@localhost> <1139589581.3394.3.camel@localhost> Message-ID: Toshio Kuratomi wrote: > On Fri, 2006-02-10 at 06:58 -0600, Rex Dieter wrote: >>shared-mime-info: missing Requires(post): desktop-file-utils >>http://bugzilla.redhat.com/bugzilla/180899 > > > Are you sure about this one? update-mime-database comes from > shared-mime-info, not desktop-file-utils. Duh, my bad. you're right, of course. -- Rex From lists at timj.co.uk Sat Feb 11 09:29:41 2006 From: lists at timj.co.uk (Tim Jackson) Date: Sat, 11 Feb 2006 09:29:41 +0000 Subject: extras maintainence In-Reply-To: <1139637835.12023.113.camel@mccallum.corsepiu.local> References: <200602100901.34790.dennis@ausil.us> <604aa7910602100729l135560ak1ec710b15bf1710b@mail.gmail.com> <1139591656.1084.222.camel@mccallum.corsepiu.local> <604aa7910602100942l71b5d33dt3620b1714cb752f2@mail.gmail.com> <1139637835.12023.113.camel@mccallum.corsepiu.local> Message-ID: <43EDAE85.6040705@timj.co.uk> Ralf Corsepius wrote: > The reasons are simple: Maintainers' resources are limited, so > maintainers restrict themselves to actively working the release they are > actively using and try to avoid to touch anything that is not "reported > to be broken" (The old: "don't try to fix what ain't broken") > > In the end you see a policy of "If it builds it goes to FC(n+1)", "If it > seems to work it goes to FC(n)", "If a change is harmless it goes to > FC(n-1), if it seems scary, it doesn't". > > Frankly speaking, I don't see what's wrong with this. Thanks for that succinct description Ralph: I think you've probably captured there the realistic (not theoretical) way many volunteers will work, consciously or not. To add to that I would also say that most maintainers are also probably able to make a call that "these changes are security related, but I don't have resources to test on FC(n-x), therefore I will drop that branch or offer it to someone who wants to maintain it as a legacy branch" Tim From rdieter at math.unl.edu Fri Feb 10 17:25:14 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 10 Feb 2006 11:25:14 -0600 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: <1139589581.3394.3.camel@localhost> References: <1138905153.3411.34.camel@localhost> <1138999755.3377.22.camel@localhost> <1139446405.3380.54.camel@localhost> <1139589581.3394.3.camel@localhost> Message-ID: Toshio Kuratomi wrote: > On Fri, 2006-02-10 at 06:58 -0600, Rex Dieter wrote: >>shared-mime-info: missing Requires(post): desktop-file-utils >>http://bugzilla.redhat.com/bugzilla/180899 > > > Are you sure about this one? update-mime-database comes from > shared-mime-info, not desktop-file-utils. gnome-vfs2 already requires shared-mime-info, so that should take care of this, as-is. -- Rex From buildsys at fedoraproject.org Sat Feb 11 10:09:53 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 11 Feb 2006 05:09:53 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060211100953.6EC7A800B@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 9 denyhosts-2.0-1.fc3 fetchlog-1.0-2.fc3 linux_logo-4.13-1.fc3 nagios-2.0-0.5.rc2.fc3 nautilus-actions-1.0-1.fc3 pbzip2-0.9.6-1.fc3 perl-Mail-Mbox-MessageParser-1.4002-1.fc3 rxvt-unicode-7.6-1.fc3 wine-0.9.7-3.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat Feb 11 10:10:23 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 11 Feb 2006 05:10:23 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060211101023.2B356800B@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 11 denyhosts-2.0-1.fc4 fetchlog-1.0-2.fc4 linux_logo-4.13-1.fc4 nagios-2.0-0.4.rc2.fc4 nautilus-actions-1.0-1.fc4 pbzip2-0.9.6-1.fc4 perl-HTTP-Server-Simple-0.18-1.fc4 perl-Mail-Mbox-MessageParser-1.4002-1.fc4 rxvt-unicode-7.6-1.fc4 shorewall-3.0.4-1.fc4 wine-0.9.7-3.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat Feb 11 10:12:02 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 11 Feb 2006 05:12:02 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060211101202.1AC02800B@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 84 SDL_gfx-2.0.13-3.fc5 apollon-1.0.1-4.fc5.1 azureus-2.3.0.7-2.20060207cvs.fc5 buoh-0.8.1-6 docbook2X-0.8.5-1.fc5 dxpc-3.8.2-3.fc5.1 gc-6.6-5.fc5 gdl-0.8.11-3.fc5 geomview-1.8.2-0.2.cvs20040221.fc5.2 gift-0.11.8.1-4.fc5.1 gift-openft-0.2.1.6-2.fc5.1 gnupg2-1.9.20-1.fc5.1 gpgme-1.1.0-3.fc5.1 gsview-4.7-5.fc5.1 gtk-qt-engine-0.60-7.fc5.1 gtktalog-1.0.4-6.fc5 gtweakui-0.4.0-1.fc5 hackedbox-0.8.4-5.fc5 hdf-4.2r1-8.fc5 i8kutils-1.25-5.fc5 jasper-1.701.0-9.fc5.1 jogl-1.1.1-13.fc5 js-1.5-3.fc5 kannel-1.4.0-7.fc5 kasablanca-0.4.0.2-7.fc5.2 kdocker-1.3-4.fc5.3 kickpim-0.5.3-9.fc5.2 kile-1.8.1-7.fc5.1 kimdaba-2.1-6.fc5.1 kiosktool-1.0-5.fc5.1 kmymoney2-0.8.2-1.fc5.1 kxdocker-0.39-3.fc5.1 libassuan-0.6.10-2.fc5.1 libcaca-0.9-9.fc5 libksba-0.9.13-2.fc5.1 libsigsegv-2.2-1.fc5.1 libtorrent-0.8.2-3.fc5 libtunepimp-0.4.0-5.fc5.1 linux_logo-4.13-1.fc5 lmarbles-1.0.7-4 metakit-2.4.9.5-1.fc5 mlmmj-1.2.11-2.fc5 mod_security-1.9.2-2.fc5 nagios-2.0-0.4.rc2.fc5 naim-0.11.8.2-1.fc5 nautilus-actions-1.0-1.fc5 ncftp-3.1.9-2.fc5 oidentd-2.0.7-8.fc5 openslp-1.2.1-4.fc5.1 p7zip-4.30-2.fc5 pbzip2-0.9.5-1.fc5 perl-HTTP-Server-Simple-0.18-1.fc5 perl-Log-Log4perl-1.03-2.fc5 perl-Mail-Mbox-MessageParser-1.4002-1.fc5 perl-libintl-1.16-1.fc5 php-eaccelerator-4.4.1_0.9.3-0.1.fc5 php-pear-DB-1.7.6-4 php-pecl-mailparse-2.1.1-2.fc5 php-pecl-pdo-1.0.2-1.fc5 pinentry-0.7.2-1.fc5.1 plib-1.8.4-2.fc5 plib16-1.6.0-4.fc5 portaudio-18.1-6.fc5 powermanga-0.79-7.fc5 proftpd-1.3.0-0.1.rc3.fc5 rtorrent-0.4.2-4.fc5 rxvt-unicode-7.6-1.fc5 sblim-cmpi-devel-1.0.4-1.fc5 sblim-testsuite-1.2.4-1.fc5 sblim-wbemcli-1.5.1-1.fc5 starfighter-1.1-6.fc5 thttpd-2.25b-9.fc5 tidy-0.99.0-9.20051025.fc5.1 ucarp-1.1-4.fc5 udftools-1.0.0b3-4.fc5 ufsparse-0.93-1.fc5 uw-imap-2004g-4.fc5.1 viruskiller-0.9-6.fc5 wine-0.9.7-3.fc5 xforms-1.0.90-6.fc5.1 xvattr-1.3-8.fc5 yasm-0.4.0-5.fc5 yumex-0.99.5-1.0.fc5 zziplib-0.13.45-1.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From dan at danny.cz Sat Feb 11 10:21:41 2006 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Sat, 11 Feb 2006 11:21:41 +0100 Subject: Summary from yesterdays FESCo-Meeting In-Reply-To: <1139597132.2967.20.camel@localhost.localdomain> References: <1139597132.2967.20.camel@localhost.localdomain> Message-ID: <1139653301.3400.9.camel@eagle.danny.cz> > Still unsure (Comments please!): > * what do we do with packages where no maintainer steps up to request > builds? Jeremy suggest "and when we get to FC5 - 2 weeks or so, we can > step in for things that haven't been touch if needed". Or do we remove > them and consider them orphaned if we don't hear *anything* from the > maintainers after a bug was opened and nothing happened for one or two > weeks? > * Packages not rebuild before the 12th of February will be removed > before FC5 is shipped to start with a clean tree with old cruft > removed. Should not this be "Packages not rebuild after 12th of February will be removed"? Because you plan to start the rebuild on the 12th. Dan From ville.skytta at iki.fi Sat Feb 11 10:27:13 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 11 Feb 2006 12:27:13 +0200 Subject: Circular dependencies In-Reply-To: <1139649212.3367.451.camel@localhost.localdomain> References: <1139649212.3367.451.camel@localhost.localdomain> Message-ID: <1139653633.12811.1.camel@bobcat.mine.nu> On Sat, 2006-02-11 at 01:13 -0800, Anthony Green wrote: > I've been forking a number of JPackage RPMS so they will build and run > on our Free Software java stack. Unfortunately, these packages have > circular dependencies. > > Is there any way to inject binary RPMs into the FE build system in order > to bootstrap the loopy packages? I don't think so. However, I think at least some of the upstream dep loops are just packaging bugs and could be fixed. From wtogami at redhat.com Sat Feb 11 10:29:06 2006 From: wtogami at redhat.com (Warren Togami) Date: Sat, 11 Feb 2006 00:29:06 -1000 Subject: Circular dependencies In-Reply-To: <1139649212.3367.451.camel@localhost.localdomain> References: <1139649212.3367.451.camel@localhost.localdomain> Message-ID: <43EDBC72.3070403@redhat.com> Anthony Green wrote: > I've been forking a number of JPackage RPMS so they will build and run > on our Free Software java stack. Unfortunately, these packages have > circular dependencies. > > Is there any way to inject binary RPMs into the FE build system in order > to bootstrap the loopy packages? > > Thanks, > > AG > > In the past FE has used a bootstrap repository with a special binary-only ghc in order to build ghc in Extras from sources. I suppose we could do something like this again, however we should formalize some official bootstrap process for cases like this within FESCO. Warren Togami wtogami at redhat.com From ville.skytta at iki.fi Sat Feb 11 10:39:50 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 11 Feb 2006 12:39:50 +0200 Subject: Summary from yesterdays FESCo-Meeting In-Reply-To: <1139653301.3400.9.camel@eagle.danny.cz> References: <1139597132.2967.20.camel@localhost.localdomain> <1139653301.3400.9.camel@eagle.danny.cz> Message-ID: <1139654390.12811.9.camel@bobcat.mine.nu> On Sat, 2006-02-11 at 11:21 +0100, Dan Hor?k wrote: > > Still unsure (Comments please!): > > * what do we do with packages where no maintainer steps up to request > > builds? Jeremy suggest "and when we get to FC5 - 2 weeks or so, we can > > step in for things that haven't been touch if needed". Or do we remove > > them and consider them orphaned if we don't hear *anything* from the > > maintainers after a bug was opened and nothing happened for one or two > > weeks? > > * Packages not rebuild before the 12th of February will be removed > > before FC5 is shipped to start with a clean tree with old cruft > > removed. > > Should not this be "Packages not rebuild after 12th of February will be > removed"? Because you plan to start the rebuild on the 12th. Also, there are many noarch packages which don't benefit from a rebuild at all, so I think the above removal plan should be limited to non-noarch packages. The buildsys assigns (or at least did) all noarch builds to the ppc builder which is already a bottleneck and that is made even worse if we're doing dummy zero-gain noarch rebuilds at a time like this. https://bugzilla.redhat.com/174685 From bugzilla at redhat.com Sat Feb 11 12:42:38 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 11 Feb 2006 07:42:38 -0500 Subject: [Bug 180205] Review Request: gnome-menu-editor In-Reply-To: Message-ID: <200602111242.k1BCgcQH007192@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-menu-editor https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180205 ------- Additional Comments From bugs.michael at gmx.net 2006-02-11 07:42 EST ------- desktop-file-install doesn't create the .desktop file from scratch. It modifies the file you feed into it, then creates a file with a new file name. You can run desktop-file-validate to verify a .desktop file manually. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugs.michael at gmx.net Sat Feb 11 13:05:26 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 11 Feb 2006 08:05:26 -0500 Subject: Summary - Broken dependencies in Fedora Extras development Message-ID: <200602111305.k1BD5Q1n027060@mx1.redhat.com> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- amarok 1.3.6-1.fc5.i386 at-poke 0.2.2-2.i386 cyrus-imapd 2.2.12-6.fc4.i386 cyrus-imapd-murder 2.2.12-6.fc4.i386 cyrus-imapd-nntp 2.2.12-6.fc4.i386 cyrus-imapd-utils 2.2.12-6.fc4.i386 gnomebaker 0.5.1-2.fc5.i386 gstreamer08-python 0.8.3-1.fc5.i386 istanbul 0.1.1-5.i386 libgda-sqlite 1:1.2.0-8.i386 libgdamm 1.3.7-2.fc5.i386 ngrep 1.44-4.fc5.i386 octave-forge 2005.06.13-4.fc5.i386 pam_mount 0.9.25-4.i386 perl-Cyrus 2.2.12-6.fc4.i386 pgadmin3 1.0.2-5.i386 python-amara 0.9.4-7.fc4.noarch sabayon-admin 2.12.1-2.i386 scalapack 1.7-7.fc4.i386 scim-fcitx 3.1.1-2.fc5.i386 scim-input-pad 0.1.1-1.fc5.i386 scim-skk 0.5.2-1.fc5.i386 scim-tomoe 0.1.0-2.fc5.i386 seahorse 0.7.9-1.fc5.i386 soundconverter 0.8.1-2.fc5.noarch syck-php 0.55-6.fc5.i386 synaptic 0.57.2-2.fc5.i386 tidy-devel 0.99.0-8.20051025.fc5.i386 tripwire 2.3.1-22.i386 up-imapproxy 1.2.4-4.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- amarok 1.3.6-1.fc5.ppc at-poke 0.2.2-2.ppc cyrus-imapd 2.2.12-6.fc4.ppc cyrus-imapd-murder 2.2.12-6.fc4.ppc cyrus-imapd-nntp 2.2.12-6.fc4.ppc cyrus-imapd-utils 2.2.12-6.fc4.ppc gnomebaker 0.5.1-2.fc5.ppc gstreamer08-python 0.8.3-1.fc5.ppc istanbul 0.1.1-5.ppc libgda-sqlite 1:1.2.0-8.ppc libgdamm 1.3.7-2.fc5.ppc ngrep 1.44-3.fc5.ppc octave-forge 2005.06.13-4.fc5.ppc pam_mount 0.9.25-4.ppc perl-Cyrus 2.2.12-6.fc4.ppc pgadmin3 1.0.2-5.ppc python-amara 0.9.4-7.fc4.noarch sabayon-admin 2.12.1-2.ppc scalapack 1.7-7.fc4.ppc scim-fcitx 3.1.1-2.fc5.ppc scim-input-pad 0.1.1-1.fc5.ppc scim-skk 0.5.2-1.fc5.ppc scim-tomoe 0.1.0-2.fc5.ppc seahorse 0.7.9-1.fc5.ppc soundconverter 0.8.1-2.fc5.noarch syck-php 0.55-6.fc5.ppc synaptic 0.57.2-2.fc5.ppc tidy-devel 0.99.0-8.20051025.fc5.ppc up-imapproxy 1.2.4-4.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- amarok 1.3.6-1.fc5.x86_64 at-poke 0.2.2-2.x86_64 cernlib 2005-7.fc5.x86_64 cernlib-packlib 2005-7.fc5.x86_64 cyrus-imapd 2.2.12-6.fc4.x86_64 cyrus-imapd-murder 2.2.12-6.fc4.x86_64 cyrus-imapd-nntp 2.2.12-6.fc4.x86_64 cyrus-imapd-utils 2.2.12-6.fc4.x86_64 gnomebaker 0.5.1-2.fc5.x86_64 gstreamer08-python 0.8.3-1.fc5.x86_64 istanbul 0.1.1-5.x86_64 libgda-sqlite 1:1.2.0-8.x86_64 libgdamm 1.3.7-2.fc5.x86_64 ngrep 1.44-4.fc5.x86_64 octave-forge 2005.06.13-4.fc5.x86_64 pam_mount 0.9.25-4.x86_64 paw 2005-7.fc5.x86_64 perl-Cyrus 2.2.12-6.fc4.x86_64 pgadmin3 1.0.2-5.x86_64 python-amara 0.9.4-7.fc4.noarch sabayon-admin 2.12.1-2.x86_64 scalapack 1.7-7.fc4.x86_64 scim-fcitx 3.1.1-2.fc5.x86_64 scim-input-pad 0.1.1-1.fc5.x86_64 scim-skk 0.5.2-1.fc5.x86_64 scim-tomoe 0.1.0-2.fc5.x86_64 seahorse 0.7.9-1.fc5.x86_64 soundconverter 0.8.1-2.fc5.noarch syck-php 0.55-6.fc5.x86_64 tidy-devel 0.99.0-8.20051025.fc5.x86_64 up-imapproxy 1.2.4-4.fc5.x86_64 ---------------------------------------------------------------------- Report for: extras-orphan AT fedoraproject.org package: synaptic - 0.57.2-2.fc5.i386 from fedora-extras-development-i386 unresolved deps: libapt-pkg-libc6.3-6.so.2 ---------------------------------------------------------------------- Report for: petersen AT redhat.com package: scim-fcitx - 3.1.1-2.fc5.i386 from fedora-extras-development-i386 unresolved deps: libscim-1.0.so.8(LIBSCIM_1.0) ---------------------------------------------------------------------- Report for: rdieter AT math.unl.edu package: tidy-devel - 0.99.0-8.20051025.fc5.i386 from fedora-extras-development-i386 unresolved deps: tidy = 0:0.99.0-8.20051025.fc5 ---------------------------------------------------------------------- Report for: ryo-dairiki AT users.sourceforge.net package: scim-skk - 0.5.2-1.fc5.i386 from fedora-extras-development-i386 unresolved deps: libscim-1.0.so.8(LIBSCIM_1.0) package: scim-input-pad - 0.1.1-1.fc5.i386 from fedora-extras-development-i386 unresolved deps: libscim-1.0.so.8(LIBSCIM_1.0) package: scim-tomoe - 0.1.0-2.fc5.i386 from fedora-extras-development-i386 unresolved deps: libscim-1.0.so.8(LIBSCIM_1.0) ---------------------------------------------------------------------- Report for: thomas AT apestaart.org package: gstreamer08-python - 0.8.3-1.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgstreamer-0.8.so.1 libgstcontrol-0.8.so.1 gstreamer08 >= 0:0.8.7 ---------------------------------------------------------------------- Report for: gauret AT free.fr package: amarok - 1.3.6-1.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgstreamer-0.8.so.1 ---------------------------------------------------------------------- Report for: bdpepple AT ameritech.net package: gnomebaker - 0.5.1-2.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgstreamer-0.8.so.1 From jspaleta at gmail.com Sat Feb 11 15:15:02 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 11 Feb 2006 10:15:02 -0500 Subject: extras maintainence In-Reply-To: <1139637835.12023.113.camel@mccallum.corsepiu.local> References: <200602100901.34790.dennis@ausil.us> <604aa7910602100729l135560ak1ec710b15bf1710b@mail.gmail.com> <1139591656.1084.222.camel@mccallum.corsepiu.local> <604aa7910602100942l71b5d33dt3620b1714cb752f2@mail.gmail.com> <1139637835.12023.113.camel@mccallum.corsepiu.local> Message-ID: <604aa7910602110715u6a6e40a4w5146ba8be7bc3a1e@mail.gmail.com> On 2/11/06, Ralf Corsepius wrote: > c.f. above. You can't control us. If you try, the project looses. anarchy serves noone. Its not about CONTROL its about PLANNING and COORDINATION. Or do you also think that the peer-review process for submission is control? Hell man,, lets have everyone contribute what they want.. however they want...with absolutely no oversight on any of their actions. Lets do that... lets make sure there is absolutely no coordination at all between people. -jef From fedora at leemhuis.info Sat Feb 11 15:44:36 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 11 Feb 2006 16:44:36 +0100 Subject: Summary from yesterdays FESCo-Meeting In-Reply-To: <1139654390.12811.9.camel@bobcat.mine.nu> References: <1139597132.2967.20.camel@localhost.localdomain> <1139653301.3400.9.camel@eagle.danny.cz> <1139654390.12811.9.camel@bobcat.mine.nu> Message-ID: <1139672676.2969.12.camel@localhost.localdomain> Am Samstag, den 11.02.2006, 12:39 +0200 schrieb Ville Skytt?: > On Sat, 2006-02-11 at 11:21 +0100, Dan Hor?k wrote: > > > Still unsure (Comments please!): > > > * what do we do with packages where no maintainer steps up to request > > > builds? Jeremy suggest "and when we get to FC5 - 2 weeks or so, we can > > > step in for things that haven't been touch if needed". Or do we remove > > > them and consider them orphaned if we don't hear *anything* from the > > > maintainers after a bug was opened and nothing happened for one or two > > > weeks? > > > * Packages not rebuild before the 12th of February will be removed > > > before FC5 is shipped to start with a clean tree with old cruft > > > removed. > > > > Should not this be "Packages not rebuild after 12th of February will be > > removed"? Because you plan to start the rebuild on the 12th. Yes, of course, sorry for the that and the resulting confusion. > Also, there are many noarch packages which don't benefit from a rebuild > at all, so I think the above removal plan should be limited to > non-noarch packages. They IMHO should be rebuild because - this way we notice that packagers are still alive and active (maybe some packages are orphaned and we simply don't know about it yet). - some noarch packages might not build anymore because foo or bar changed in between (modular X.org for example). Yeah, maybe that's unlikely, but we all know computers and linux well enough and know that things like that happen. Other opinions? -- Thorsten Leemhuis From bugzilla at redhat.com Sat Feb 11 15:58:46 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 11 Feb 2006 10:58:46 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602111558.k1BFwkKD027622@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From pertusus at free.fr 2006-02-11 10:58 EST ------- >From a look at the configure.in it seems that it may use both old and new libnet api. So the best is to use the newer, by having Buildrequires: libnet-devel instead of libnet10. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 11 16:05:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 11 Feb 2006 11:05:07 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602111605.k1BG57o3028335@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 Bug 180897 depends on bug 180952, which changed state. Bug 180952 Summary: Conflicts between libnet-devel and libnet10 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180952 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |WONTFIX Status|NEW |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From green at redhat.com Sat Feb 11 16:31:11 2006 From: green at redhat.com (Anthony Green) Date: Sat, 11 Feb 2006 08:31:11 -0800 Subject: Circular dependencies In-Reply-To: <43EDBC72.3070403@redhat.com> References: <1139649212.3367.451.camel@localhost.localdomain> <43EDBC72.3070403@redhat.com> Message-ID: <1139675471.3367.457.camel@localhost.localdomain> On Sat, 2006-02-11 at 00:29 -1000, Warren Togami wrote: > In the past FE has used a bootstrap repository with a special > binary-only ghc in order to build ghc in Extras from sources. I suppose > we could do something like this again, however we should formalize some > official bootstrap process for cases like this within FESCO. Here's how the JPackage people deal with this.. if FOO and BAR are two interdependent packages, they create a FOO-bootstrap package on which BAR BuildRequires. Since we're just talking about pure bytecode here, FOO-bootstrap's SRPM contains prebuilt architecture neutral jar files that would normally be found in FOO. So, would it be OK to submit binary -bootstrap SRPMS to FE for the purposes of bootstrapping these loopy packages? This has the advantage that is doesn't require any special intervention on the part of the FE build infrastructure maintainers. AG From dennis at ausil.us Sat Feb 11 16:46:34 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 11 Feb 2006 10:46:34 -0600 Subject: Circular dependencies In-Reply-To: <1139675471.3367.457.camel@localhost.localdomain> References: <1139649212.3367.451.camel@localhost.localdomain> <43EDBC72.3070403@redhat.com> <1139675471.3367.457.camel@localhost.localdomain> Message-ID: <200602111046.57877.dennis@ausil.us> Once upon a time Saturday 11 February 2006 10:31 am, Anthony Green wrote: > So, would it be OK to submit binary -bootstrap SRPMS to FE for the > purposes of bootstrapping these loopy packages? This has the advantage > that is doesn't require any special intervention on the part of the FE > build infrastructure maintainers. have a look at fpcits initial build contained a bianry copy of the compiler as fpc is written in pascal and needed a pascal compiler to build. its first update then required itself to build. you could possibly do something similar if indeed there is a circular dependancy. if that is indeed the case thats a bad design by upstream -- Dennis Gilmore, RHCE http://www.ausil.us Proud Australian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugzilla at redhat.com Sat Feb 11 16:55:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 11 Feb 2006 11:55:59 -0500 Subject: [Bug 166547] Review Request: multisync - Calendar (and other PIM data) synchronization program In-Reply-To: Message-ID: <200602111655.k1BGtxmS001470@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multisync - Calendar (and other PIM data) synchronization program https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166547 ------- Additional Comments From jpmahowald at gmail.com 2006-02-11 11:55 EST ------- Needs a bit more work: * multisync-gui lacks a .desktop file. * ** (multisync:13317): WARNING **: Couldn't find pixmap file: multisync-0.90/multisync_small.png upon start, which means it lacks an icon in the window list * Help > About doesn't work Some of this may be due to the (Experimental) label on the title bar. How unstable is this? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 11 17:33:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 11 Feb 2006 12:33:30 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602111733.k1BHXUoq005451@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From fedora at soeterbroek.com 2006-02-11 12:33 EST ------- (In reply to comment #10) > From a look at the configure.in it seems that it may use both old and new libnet > api. So the best is to use the newer, by having > > Buildrequires: libnet-devel > > instead of libnet10. Done.. Spec Name or Url: http://www.soeterbroek.com/linux/fedora/extras/heartbeat/heartbeat.spec SRPM Name or Url: http://www.soeterbroek.com/linux/fedora/extras/heartbeat/heartbeat-2.0.2-3.src.rpm - remove BuildRequire libnet10 - add BuildRequire libnet-devel Builds fine in mock (FC4-i386). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 11 18:13:54 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 11 Feb 2006 13:13:54 -0500 Subject: [Bug 181013] New: Review Request: qgit - a GUI browser for local git repositories Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181013 Summary: Review Request: qgit - a GUI browser for local git repositories Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: dan at danny.cz QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.danny.cz/qgit.spec SRPM Name or Url: http://www.danny.cz/qgit-1.1-0.1.rc3.3.srpm Description: QGit is a GUI browser for local git repositories written using the QT library. I have gone through the MUST steps for reviewers and it should be OK. The only thing about qgit's full function is a requirement for git newer then current 1.1.6. I am in contact with the developer and he is aware of it. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 11 19:36:05 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 11 Feb 2006 14:36:05 -0500 Subject: [Bug 180149] Review Request: edje: A complex graphical design and layout library In-Reply-To: Message-ID: <200602111936.k1BJa526019876@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: edje: A complex graphical design and layout library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180149 Bug 180149 depends on bug 180052, which changed state. Bug 180052 Summary: Review Request: evas: A hardware-accelerated canvas API https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180052 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NEXTRELEASE Status|ASSIGNED |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 11 19:35:58 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 11 Feb 2006 14:35:58 -0500 Subject: [Bug 180052] Review Request: evas: A hardware-accelerated canvas API In-Reply-To: Message-ID: <200602111935.k1BJZwHd019849@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: evas: A hardware-accelerated canvas API https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180052 ivazquez at ivazquez.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From ivazquez at ivazquez.net 2006-02-11 14:35 EST ------- There doesn't appear to be any cairo support in 0.9.9.023. Built in FC4 and devel. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 11 19:36:17 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 11 Feb 2006 14:36:17 -0500 Subject: [Bug 180058] Review Request: ecore: An event and X abstraction layer In-Reply-To: Message-ID: <200602111936.k1BJaHgc019962@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ecore: An event and X abstraction layer https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180058 Bug 180058 depends on bug 180052, which changed state. Bug 180052 Summary: Review Request: evas: A hardware-accelerated canvas API https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180052 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NEXTRELEASE Status|ASSIGNED |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From fedora at leemhuis.info Sat Feb 11 20:15:44 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 11 Feb 2006 21:15:44 +0100 Subject: Summary from yesterdays FESCo-Meeting In-Reply-To: <1139672676.2969.12.camel@localhost.localdomain> References: <1139597132.2967.20.camel@localhost.localdomain> <1139653301.3400.9.camel@eagle.danny.cz> <1139654390.12811.9.camel@bobcat.mine.nu> <1139672676.2969.12.camel@localhost.localdomain> Message-ID: <1139688944.7705.15.camel@localhost.localdomain> Am Samstag, den 11.02.2006, 16:44 +0100 schrieb Thorsten Leemhuis: > Am Samstag, den 11.02.2006, 12:39 +0200 schrieb Ville Skytt?: > > Also, there are many noarch packages which don't benefit from a rebuild > > at all, so I think the above removal plan should be limited to > > non-noarch packages. > > They IMHO should be rebuild because > - this way we notice that packagers are still alive and active (maybe > some packages are orphaned and we simply don't know about it yet). > > - some noarch packages might not build anymore because foo or bar > changed in between (modular X.org for example). Yeah, maybe that's > unlikely, but we all know computers and linux well enough and know that > things like that happen. I asked Kevin how many noarch packages failed in his build tests http://www.scrye.com/~kevin/mock-broken.html : nirik> | ok, 11 noarch packages on the list: perl-bioperl, perl-GD, perl-GD-SVG, perl-Graph, php-pear-DB, python-goopy, python-logilab-common, python-myghty, rsnapshot, stow, w3c-markup-validator -- Thorsten Leemhuis From bugzilla at redhat.com Sat Feb 11 20:33:23 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 11 Feb 2006 15:33:23 -0500 Subject: [Bug 180298] Review Request: gnonlin In-Reply-To: Message-ID: <200602112033.k1BKXN16026026@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnonlin https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180298 jeff at ollie.clive.ia.us changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-11 15:33 EST ------- Approved. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 11 20:39:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 11 Feb 2006 15:39:34 -0500 Subject: [Bug 180299] Review Request: pitivi In-Reply-To: Message-ID: <200602112039.k1BKdYTh026694@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: pitivi https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180299 ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-11 15:39 EST ------- The package itself looks fine now, but I still can't get pitivi to do anything for me though. I can add some OGG/Theora videos and kind of stick them into the timeline, but there's all the video is dark green and I can't save/open a project. I have the -bad and -ugly plugins from freshrpms, but if plugins from -bad or -ugly are needed then probably pitivi shouldn't be in FE since the -bad and -ugly plugins can't be in FE. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 11 20:43:24 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 11 Feb 2006 15:43:24 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602112043.k1BKhOir027090@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 alanr at unix.sh changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alanr at unix.sh ------- Additional Comments From alanr at unix.sh 2006-02-11 15:43 EST ------- (In reply to comment #11) > (In reply to comment #10) > > From a look at the configure.in it seems that it may use both old and new libnet > > api. So the best is to use the newer, by having > > > > Buildrequires: libnet-devel > > > > instead of libnet10. > > Done.. > > Spec Name or Url: > http://www.soeterbroek.com/linux/fedora/extras/heartbeat/heartbeat.spec > SRPM Name or Url: > http://www.soeterbroek.com/linux/fedora/extras/heartbeat/heartbeat-2.0.2-3.src.rpm > > - remove BuildRequire libnet10 > - add BuildRequire libnet-devel > > Builds fine in mock (FC4-i386). I think some parts use either API for historical reasons, but I believe the IPv6 code (which is newer) only uses the newer libnet API. Let me know if there's anything we should change in the project's packaging to make this easier for you. There are also lots of bug fixes and some nice new features (GUI, etc.) in 2.0.3 which just came out yesterday. Thanks! -- Alan Robertson alanr at unix.sh -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 11 23:14:40 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 11 Feb 2006 18:14:40 -0500 Subject: [Bug 181035] New: Review Request: luks-tools Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181035 Summary: Review Request: luks-tools Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: redhat at flyn.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.flyn.org/SRPMS/luks-tools.spec SRPM Name or Url: http://www.flyn.org/SRPMS/luks-tools-0.0.8-1.src.rpm Description: The luks-tools package contains various utilities for working with LUKS-protected filesystems. HAL uses these utilities to automatically mount encrypted volumes when they are attached to a system, provided the user can produce the correct passphrase. These utilities are written as separate programs to allow MAC systems like SELinux to have fine-grained control over them. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 12 00:11:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 11 Feb 2006 19:11:30 -0500 Subject: [Bug 180058] Review Request: ecore: An event and X abstraction layer In-Reply-To: Message-ID: <200602120011.k1C0BUeD018087@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ecore: An event and X abstraction layer https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180058 ivazquez at ivazquez.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From ivazquez at ivazquez.net 2006-02-11 19:11 EST ------- Built on FC4 and devel. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 12 00:11:37 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 11 Feb 2006 19:11:37 -0500 Subject: [Bug 180149] Review Request: edje: A complex graphical design and layout library In-Reply-To: Message-ID: <200602120011.k1C0BaTr018123@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: edje: A complex graphical design and layout library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180149 Bug 180149 depends on bug 180058, which changed state. Bug 180058 Summary: Review Request: ecore: An event and X abstraction layer https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180058 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NEXTRELEASE Status|ASSIGNED |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From toshio at tiki-lounge.com Sun Feb 12 05:07:16 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sat, 11 Feb 2006 21:07:16 -0800 Subject: ScriptletSnippets: desktop-database,mimeinfo In-Reply-To: References: <1138905153.3411.34.camel@localhost> <1138999755.3377.22.camel@localhost> <1139446405.3380.54.camel@localhost> <1139589581.3394.3.camel@localhost> Message-ID: <1139720836.3362.8.camel@localhost> On Fri, 2006-02-10 at 11:25 -0600, Rex Dieter wrote: > Toshio Kuratomi wrote: > > On Fri, 2006-02-10 at 06:58 -0600, Rex Dieter wrote: > > >>shared-mime-info: missing Requires(post): desktop-file-utils > >>http://bugzilla.redhat.com/bugzilla/180899 > > > > > > Are you sure about this one? update-mime-database comes from > > shared-mime-info, not desktop-file-utils. > > gnome-vfs2 already requires shared-mime-info, so that should take care > of this, as-is. Right. shared-mime-info is good to go. desktop-file-utils is the problem child. -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 bugzilla at redhat.com Sun Feb 12 06:55:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 01:55:48 -0500 Subject: [Bug 176528] Review Request: MochiKit: A lightweight JavaScript library In-Reply-To: Message-ID: <200602120655.k1C6tmHL026081@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: MochiKit: A lightweight JavaScript library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176528 ------- Additional Comments From ivazquez at ivazquez.net 2006-02-12 01:55 EST ------- You're right, it doesn't make much sense. Updated. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 12 10:34:14 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 05:34:14 -0500 Subject: [Bug 176733] Review Request: php-pear-DB (PEAR database abstraction layer) In-Reply-To: Message-ID: <200602121034.k1CAYE3u028442@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-pear-DB (PEAR database abstraction layer) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176733 rpm at timj.co.uk changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From rpm at timj.co.uk 2006-02-12 05:34 EST ------- Built in devel. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 12 10:48:05 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 05:48:05 -0500 Subject: [Bug 179237] Review Request: swaks - A command-line SMTP transaction tester In-Reply-To: Message-ID: <200602121048.k1CAm5m0030164@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: swaks - A command-line SMTP transaction tester https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179237 ------- Additional Comments From rpm at timj.co.uk 2006-02-12 05:47 EST ------- Jason, you've beaten me to it: I was going to submit swaks :) Thanks for this package submission. A few small comments: 1. I think that Source0 should be http://jetmore.org/john/code/swaks.%{version} not http://jetmore.org/john/code/swaks as presumably the latter always points to the latest version, making it invalid as new versions roll in. 2. In my own packaging of this I have the following deps in addition to the ones you have: - perl(MIME::Base64) - perl(Digest::MD5) - perl(Authen::NTLM) - perl(Authen::DigestMD5) Now, these aren't strictly required to be able to use swaks, but they are required to implement all of the advertised functionality, and without them you will get some fairly ungraceful errors when you try to do various things. Therefore, I think they should be deps. In fact, the reason why I didn't submit the swaks spec myself earlier is because one or two of the above (at least Authen::NTLM IIRC) are not currently in FC/FE so they need submitting first. This harks back to a discussion I initiated in Jan on fedora-extras-list about "optional" deps: http://marc.theaimsgroup.com/?l=fedora-extras-list&m=113683046628533 3. Does the package need a BR on /usr/bin/pod2man or is that one of the implicit prereqs? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 12 11:06:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 06:06:27 -0500 Subject: [Bug 165932] Review Request: An SMTP Client In-Reply-To: Message-ID: <200602121106.k1CB6RmW032009@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: An SMTP Client https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165932 ------- Additional Comments From gauret at free.fr 2006-02-12 06:06 EST ------- Ping ? The only diff between release 2 and release 1 is the fixed source URL, so it's still approved. If you're still interested in this package, please go ahead and import it. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 12 11:08:19 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 06:08:19 -0500 Subject: [Bug 166207] Review Request: rekall : A KDE database front-end application In-Reply-To: Message-ID: <200602121108.k1CB8Jqv032163@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: rekall : A KDE database front-end application https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166207 gauret at free.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From gauret at free.fr 2006-02-12 06:08 EST ------- Rekall is published, closing bug -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 12 11:08:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 06:08:56 -0500 Subject: [Bug 168905] Review Request: python-nltk In-Reply-To: Message-ID: <200602121108.k1CB8ufO032349@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: python-nltk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168905 gauret at free.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From gauret at free.fr 2006-02-12 06:08 EST ------- python-nltk is published, closing bug -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 12 11:38:46 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 06:38:46 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602121138.k1CBckph003129@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From fedora at soeterbroek.com 2006-02-12 06:38 EST ------- Rebuilt for 2.0.3 Spec Name or Url: http://www.soeterbroek.com/linux/fedora/extras/heartbeat/heartbeat.spec SRPM Name or Url: http://www.soeterbroek.com/linux/fedora/extras/heartbeat/heartbeat-2.0.3-1.src.rpm Builds fine in mock (FC4-i386). Needs reviewer. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From buildsys at fedoraproject.org Sun Feb 12 15:55:50 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 12 Feb 2006 10:55:50 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060212155550.B2F1A8011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 5 bash-completion-20050721-4.fc3.1 perl-Convert-PEM-0.07-3.fc3 perl-Crypt-DES-2.05-1.fc3 perl-Crypt-DES_EDE3-0.01-3.fc3 scim-input-pad-0.1.1-2.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun Feb 12 15:56:07 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 12 Feb 2006 10:56:07 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060212155607.C026E8011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 8 bash-completion-20050721-4.fc4 docbook2X-0.8.5-1.fc4.1 ecore-0.9.9.023-1.fc4 evas-0.9.9.023-1.fc4 gnome-applet-sensors-1.4-4.fc4 nagios-2.0-0.4.rc2.fc4 scim-input-pad-0.1.1-2.fc4 tog-pegasus-2.5-1.fe4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun Feb 12 15:56:52 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 12 Feb 2006 10:56:52 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060212155652.62C748011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 19 allegro-4.2.0-7 bazaar-1.4.2-5.fc5 denyhosts-2.1-1.fc5 drgeo-1.1.0-6.fc5 drgeo-doc-1.6-6.fc5 ecore-0.9.9.023-1.fc5 evas-0.9.9.023-1.fc5 gnonlin-0.10.0.5-3 gperiodic-2.0.8-3.fc5 ircd-hybrid-7.2.0-5.fc5 libupnp-1.2.1a-5.fc5 liferea-1.0.4-2.fc5 nagios-2.0-0.4.rc2.fc5 perl-Class-MethodMaker-2.08-1 perl-libintl-1.16-2.fc5 sbcl-0.9.9-1.fc5.2 scorched3d-39.1-2.fc5 scorched3d-39.1-3.fc5 ushare-0.9.5-5.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Sun Feb 12 17:34:42 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 12:34:42 -0500 Subject: [Bug 181068] New: Review Request: html401-dtds - HTML 4.01 document type definitions Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181068 Summary: Review Request: html401-dtds - HTML 4.01 document type definitions Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: ville.skytta at iki.fi QAContact: fedora-extras-list at redhat.com SRPM Name or Url: http://cachalot.mine.nu/4/SRPMS/html401-dtds-4.01-0.2.src.rpm Note for reviewers: the packaging approach here has been discussed with various folks over past few years. The general ideas in it roughly follow the Debian SGML packaging draft policy, http://debian-xml-sgml.alioth.debian.org/sgml-policy/ %description improvements gracefully accepted :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 12 17:36:29 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 12:36:29 -0500 Subject: [Bug 181068] Review Request: html401-dtds - HTML 4.01 document type definitions In-Reply-To: Message-ID: <200602121736.k1CHaTYF008414@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: html401-dtds - HTML 4.01 document type definitions https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181068 ------- Additional Comments From ville.skytta at iki.fi 2006-02-12 12:36 EST ------- Ditto opinions whether the specification subpackage should be called -spec, -doc, or -docs. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 12 17:52:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 12:52:47 -0500 Subject: [Bug 181068] Review Request: html401-dtds - HTML 4.01 document type definitions In-Reply-To: Message-ID: <200602121752.k1CHql1t010705@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: html401-dtds - HTML 4.01 document type definitions https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181068 ------- Additional Comments From Nicolas.Mailhot at laPoste.net 2006-02-12 12:52 EST ------- What are the differences with the policies followed by docbook-dtds and xhtml1-dtds ? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 12 18:35:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 13:35:52 -0500 Subject: [Bug 176373] Review Request: ytalk In-Reply-To: Message-ID: <200602121835.k1CIZq9n017621@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ytalk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176373 ------- Additional Comments From kevin at tummy.com 2006-02-12 13:35 EST ------- Greetings. I was going to do a review of this package, but the URL(s) in the submission appear to not be functional. testapp1.iesabroad.org doesn't resolve here. Can you update the ulrs and then I will be happy to do a review. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 12 19:15:45 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 14:15:45 -0500 Subject: [Bug 172755] Review Request: xcompmgr - X11 composite manager In-Reply-To: Message-ID: <200602121915.k1CJFjVc021457@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xcompmgr - X11 composite manager https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172755 kevin at tummy.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |kevin at tummy.com OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From kevin at tummy.com 2006-02-12 14:15 EST ------- Greetings, heres a review: MUST items: OK - package name good. OK - spec file matches. OK - spec in english. OK - spec legible. OK - md5sum matches: 44ccbafa8484b7e0c00e5c83cd915adc xcompmgr-1.1.3.tar.gz 44ccbafa8484b7e0c00e5c83cd915adc xcompmgr-1.1.3.tar.gz.1 OK - compiles and builds under devel. OK - files and dirs ok. OK - clean section good. OK - macros good. OK - builds ok in mock on devel. Needs looking at: 1. License. Is it really X11/MIT? I see that SuSE ships this package as GPL. The License at the top of the .c file does look BSDish. Might confirm? 2. rpmlint has some output: E: xcompmgr description-line-too-long xcompmgr is a sample compositing manager for X servers supporting the XFIXES, DAMAGE, and COMPOSITE extensions. It enables basic eye-candy effects W: xcompmgr invalid-license MIT/X11 W: xcompmgr-debuginfo invalid-license MIT/X11 You might add a line break or two in the description line. Optional: 3. You might optionally ship the Changelog file as a doc. 4. You might get upstream to ship a copy of it's license with it. Clarify and confirm the License and fix the description line, and I will APPROVE. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 12 19:18:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 14:18:18 -0500 Subject: [Bug 181068] Review Request: html401-dtds - HTML 4.01 document type definitions In-Reply-To: Message-ID: <200602121918.k1CJIIUr021801@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: html401-dtds - HTML 4.01 document type definitions https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181068 ------- Additional Comments From ville.skytta at iki.fi 2006-02-12 14:18 EST ------- docbook-dtds and xhtml1-dtds don't really seem to constitute a common policy. I think the basic ideas are mostly the same in them, this package and the Debian policy. docbook-dtds AFAICT unnecessarily embeds full version-release strings into its install dirs, making it hard for apps to point only to a specific version of the dtds. It also sets SGMLDECL in a catalog that gets included in the global catalog which is problematic because SGMLDECL (at least as implemented in opensp) is global and the first one encountered will be used for _all_ subsequent matches -> breakage. Further, it registers itself to the private catalogs of openjade -> most likely unneeded, needs changing between openjade releases, and results in a build dependency loop. xhtml1-dtds registers the dtds only to the XML catalogs (despite of installing into sgml dirs) so it's somewhat different. It also embeds a date stamp (but not version-release) in its install dirs but that's less problematic than in docbook-dtds because there's a xmlcatalog in an unversioned path in /usr/share/sgml/xhtml1. Both of the above install DTDs executable, but that's probably just a bug. So in a nutshell, compared to those, this package uses a dir structure that is very unlikely to need changing, installs a self-contained catalog to its own dir below /usr/share/sgml, uses DTDDECLs instead of SGMLDECLs in order to not interfere with (nor be confused by) other SGML dtd packages' SGML declarations, + bug fixes. Yes, I intend to file some related bug reports in the future :) And I have also HTML 2.0, 3.2, 4.0, ISO-HTML, XHTML Basic 1.0, XHTML 1.1, SMIL 2.0, and RSS *-dtds packages more or less ready to roll, some of which will probably be submitted later. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 12 19:18:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 14:18:34 -0500 Subject: [Bug 178169] Review Request: jigdo In-Reply-To: Message-ID: <200602121918.k1CJIY30021841@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: jigdo https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178169 ------- Additional Comments From kevin at tummy.com 2006-02-12 14:18 EST ------- Hey Ian. Can you build against the latest w3c-libwww from https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178310 and confirm that the package still works as expected? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 12 19:35:12 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 14:35:12 -0500 Subject: [Bug 181068] Review Request: html401-dtds - HTML 4.01 document type definitions In-Reply-To: Message-ID: <200602121935.k1CJZCTG024263@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: html401-dtds - HTML 4.01 document type definitions https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181068 ------- Additional Comments From veillard at redhat.com 2006-02-12 14:35 EST ------- you can't mix sgml and xml resources in the XML catalogs. SGML definition will generate fatal errors when loaded by an XML parser. Anything reachable from /etc/xml/catalog must be XML only. So html-4... just can share things with xhtml1. W.r.t. using /usr/share/sgml for the XML catalog this is the unfortunate result of SGML nutheads blocking XML from the LSB standard a few years ago, so Red Hat had to keep them there instead of a far more logical /usr/share/xml subtree ! W.r.t. XHTML 1.1 and SMIL 2.0, they are extensible languages, i.e. the basic language defined in the DTDs are supposed to be extended with foreign elements in different namespaces, which is actually something which doesn't work with DTDs, so the usefulness of shipping those 2 gets very limited, as DTD based validation will just fail in general (but Relax-NG or XSD schemas would work better though there isn't good ways to reference them for catalog access from the instances). Please be very careful when trying to handle XML resources if you're competent in SGML but not really aware of XML, this is a very different field with very different rules and specifications, this has bitten us in the past hard and I don't want this to happen again. Daniel (libxml2 author and member of W3C XML Core Working Group) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 12 19:50:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 14:50:16 -0500 Subject: [Bug 179510] Review Request: Nautilus-Flac-Converter In-Reply-To: Message-ID: <200602121950.k1CJoGO8025778@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Nautilus-Flac-Converter https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179510 ------- Additional Comments From bdpepple at ameritech.net 2006-02-12 14:50 EST ------- Spec Name or Url: http://piedmont.homelinux.org/fedora/nautilus/nautilus-flac-converter.spec SRPM Name or Url: http://piedmont.homelinux.org/fedora/nautilus/nautilus-flac-converter-0.0.2-2.src.rpm Changelog * Tue Feb 7 2006 Brian Pepple - 0.0.2-2 - Update URL & Source for sourceforge address. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 12 20:17:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 15:17:16 -0500 Subject: [Bug 181068] Review Request: html401-dtds - HTML 4.01 document type definitions In-Reply-To: Message-ID: <200602122017.k1CKHGYX028209@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: html401-dtds - HTML 4.01 document type definitions https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181068 ------- Additional Comments From ville.skytta at iki.fi 2006-02-12 15:17 EST ------- (In reply to comment #4) > you can't mix sgml and xml resources in the XML catalogs. SGML definition > will generate fatal errors when loaded by an XML parser. Of course. I don't know where you got the impression that someone/thing wanted to do that. It would be nice if xhtml1-dtds would register the DTDs to the SGML catalogs in addition to XML catalogs though (for example for use in SGML validation tools and things that grok SGML but not XML catalogs), but that's a bit offtopic for this submission. Of course, the html401-dtds package deals with SGML catalogs only. > Please be very careful when trying to handle XML resources if you're competent > in SGML but not really aware of XML, this is a very different field with > very different rules and specifications, this has bitten us in the past hard > and I don't want this to happen again. I don't claim to be an SGML nor XML god, but do have more than a little experience with both. > Daniel (libxml2 author and member of W3C XML Core Working Group) Ville (member of the W3C QA Tools Development Team) ;) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 12 20:32:23 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 15:32:23 -0500 Subject: [Bug 181013] Review Request: qgit - a GUI browser for local git repositories In-Reply-To: Message-ID: <200602122032.k1CKWNuI029770@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: qgit - a GUI browser for local git repositories https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181013 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-12 15:32 EST ------- Sorry, I will got a 404 when I try to download the SRPM file. Downloading the SPEC file worked fine. Best Regards: Jochen Schmitt -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 12 21:03:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 16:03:49 -0500 Subject: [Bug 181013] Review Request: qgit - a GUI browser for local git repositories In-Reply-To: Message-ID: <200602122103.k1CL3nJX000539@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: qgit - a GUI browser for local git repositories https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181013 ------- Additional Comments From dan at danny.cz 2006-02-12 16:03 EST ------- Updated SRPM Url: http://www.danny.cz/qgit-1.1-0.1.rc3.3.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 12 21:11:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 16:11:28 -0500 Subject: [Bug 180743] Review Request: pdsh In-Reply-To: Message-ID: <200602122111.k1CLBS9S001348@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: pdsh https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180743 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-12 16:11 EST ------- + Local build worked fine. + md5sum is ok. + build on mock worked fine. - Source: should contains full qualified URL. - rpm Source rpm creates warnings. $ rpmlint pdsh-2.8.1-2.src.rpm W: pdsh summary-ended-with-dot Parallel remote shell program. W: pdsh prereq-use xinetd W: pdsh prereq-use xinetd - rpmlint of Binaries RPM creates: $ rpmlint pdsh-2.8.1-2.src.rpm W: pdsh summary-ended-with-dot Parallel remote shell program. W: pdsh prereq-use xinetd W: pdsh prereq-use xinetd - Packages should not contains *.a files. Question: Why you don't use %{?smp_flags}? Best Regards: Jochen Schmitt -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 12 22:39:54 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 17:39:54 -0500 Subject: [Bug 179237] Review Request: swaks - A command-line SMTP transaction tester In-Reply-To: Message-ID: <200602122239.k1CMdsSn011446@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: swaks - A command-line SMTP transaction tester https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179237 ------- Additional Comments From tibbs at math.uh.edu 2006-02-12 17:39 EST ------- His distribution is a bit unorthodox; I wasn't aware that I could grab a particular version. Fixed. Mime::Base64 and Digest::MD5 are both part of base perl and so it would be against the packaging guidelines to BuildRequire: them. (pod2man is part of perl as well.) As neither Authen::NTLM and Authen::DigestMD5 are in Core or Extras, requiring them would be a complete blocker. I can of course rebuild the package to require them if they ever make it into the distro. The program still works fine and is useful without them, so not including them is not a blocker as far as I can tell from my reading of the packaging guidelines. Updated spec and src.rpm are in http://www.math.uh.edu/~tibbs/rpms/swaks/ -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 12 23:13:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 18:13:34 -0500 Subject: [Bug 180532] Review Request: perl-UNIVERSAL-can In-Reply-To: Message-ID: <200602122313.k1CNDYgP014316@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-UNIVERSAL-can https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180532 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From tibbs at math.uh.edu 2006-02-12 18:13 EST ------- This package builds cleanly in mock, but on the devel branch only due to the Test::Simple >= 0.60 requirement. As far as I can tell there is no requirement that packages build on the release branch so this is not a blocker. However, I just commented out the Test::Simple requirement and the package built fine and passes all tests on FC4 and FC3. rpmlint is silent. The package meets the naming and packaging guidelines. The specfile is properly named and follows the recomment Perl template. The source file matches upstream and provided signatures verify with cpansign -v. Licence: tag is proper and matches the package. BuildRequires: is proper. Approved, but you might want to investigate dropping the Test::Simple requirement altogether and building the package on the release branch. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 12 23:30:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 18:30:10 -0500 Subject: [Bug 180102] Review Request: embryo: A C like scripting language In-Reply-To: Message-ID: <200602122330.k1CNUAsM016304@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: embryo: A C like scripting language https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180102 ------- Additional Comments From tibbs at math.uh.edu 2006-02-12 18:30 EST ------- I think you gave the link to the wrong srpm there, but I found the proper one and gave a quick look. Are you sure that license is MIT? It seems to have an advertising clause that is not in the stock MIT license as found at http://www.opensource.org/licenses/mit-license.php, and indeed seems closer to the three clause BSD license (but I'm no expert). Here is the clause: The above copyright notice and this permission notice shall be included in all copies of the Software and its Copyright notices. In addition publicly documented acknowledgment must be given that this software has been used if no source code of this software is made available publicly. This includes acknowledgments in either Copyright notices, Manuals, Publicity and Marketing documents or any documentation provided with any product containing this software. This License does not apply to any software that links to the libraries provided by this software (statically or dynamically), but only to the software provided. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 13 01:11:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 12 Feb 2006 20:11:48 -0500 Subject: [Bug 176528] Review Request: MochiKit: A lightweight JavaScript library In-Reply-To: Message-ID: <200602130111.k1D1Bmjh027223@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: MochiKit: A lightweight JavaScript library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176528 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From tibbs at math.uh.edu 2006-02-12 20:11 EST ------- Cool. Approved. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rc040203 at freenet.de Mon Feb 13 05:22:40 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 13 Feb 2006 06:22:40 +0100 Subject: extras maintainence In-Reply-To: <604aa7910602110715u6a6e40a4w5146ba8be7bc3a1e@mail.gmail.com> References: <200602100901.34790.dennis@ausil.us> <604aa7910602100729l135560ak1ec710b15bf1710b@mail.gmail.com> <1139591656.1084.222.camel@mccallum.corsepiu.local> <604aa7910602100942l71b5d33dt3620b1714cb752f2@mail.gmail.com> <1139637835.12023.113.camel@mccallum.corsepiu.local> <604aa7910602110715u6a6e40a4w5146ba8be7bc3a1e@mail.gmail.com> Message-ID: <1139808160.12023.152.camel@mccallum.corsepiu.local> On Sat, 2006-02-11 at 10:15 -0500, Jeff Spaleta wrote: > On 2/11/06, Ralf Corsepius wrote: > > c.f. above. You can't control us. If you try, the project looses. > > anarchy serves noone. FUD ... there are many shades between "anarchy" and "tyranny". > Its not about CONTROL its about PLANNING and COORDINATION. Well, a matter of perspective and of word choice of words. It doesn't matter how you call it, in the end it's "control" or "rules". Also, you can set up as many "plans" as you want and set up as many "coordination stuff" as you want. Social systems based on volunteers like FE only work if your volunteers accept "the rules". If they don't accept them, your volunteer run project, be it firefighters, a football/baseball club, a charity kitchen, a welfare kindergarden will suffer from lack of people and will gradually die. > Or do you also think that the peer-review process for submission is control? Well, from a contributor's POV the package submission review process is just a "big hurdle", you're better off "playing nice to". Once you've made this hurdle, there isn't QA at all and you're given full freedom to commit any stupidity you want to. > Hell man,, lets have everyone contribute what they want.. however they > want...with absolutely no oversight on any of their actions. Lets do > that... lets make sure there is absolutely no coordination at all > between people. Come on, you are just agitating. We are talking about how the existing Fedora Extra's system and about wishes on the Fedora Extra's system. Wrt. Legacy vs. Extras and FC3 life-time, the issue boils down to "When will RH shutting down the FE3 build and distribution system prevent me from maintaining FE3 packages?" Wrt. "sharing maintainership", the issue boils down to "When will other maintainer be legitimated to fix obvious bugs in other people's packages." Wrt. "mass rebuilds", the issue boil down to "If somebody wants to initiate a mass rebuild, they have got to do it". This has nothing to do with anarchy, it's about control on FE. Ralf From petersen at redhat.com Mon Feb 13 06:48:45 2006 From: petersen at redhat.com (Jens Petersen) Date: Mon, 13 Feb 2006 15:48:45 +0900 Subject: Broken dependencies in Fedora Extras development In-Reply-To: <200602111305.k1BD5Lm8027042@mx1.redhat.com> References: <200602111305.k1BD5Lm8027042@mx1.redhat.com> Message-ID: <20060213154845.54c1cdd6.petersen@redhat.com> On Sat, 11 Feb 2006 08:05:21 -0500 Michael Schwendt wrote: > This is an automated mail. > Your following packages in the repository have broken dependencies: > > package: scim-fcitx - 3.1.1-2.fc5.i386 from fedora-extras-development-i386 > unresolved deps: > libscim-1.0.so.8(LIBSCIM_1.0) Thanks - should be fixed in 3.1.1-3.fc5. scim-input-pad, scim-skk, and scim-tomoe also updated. Jens From buildsys at fedoraproject.org Mon Feb 13 07:00:37 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 13 Feb 2006 02:00:37 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060213070037.B833D8011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 1 libapreq2-2.07-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon Feb 13 07:00:44 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 13 Feb 2006 02:00:44 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060213070044.06D8D8011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 11 dejavu-fonts-2.2-5.fc5 fontforge-20060125-5.fc5 gai-0.5.10-5.fc5 gnome-applet-sensors-1.6-2.fc5 kover-2.9.6-4 libapreq2-2.07-1.fc5 scim-fcitx-3.1.1-3.fc5 scim-input-pad-0.1.1-3.fc5 scim-skk-0.5.2-3.fc5 scim-tomoe-0.1.0-3.fc5 soundconverter-0.8.3-1.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From caillon at redhat.com Mon Feb 13 08:19:28 2006 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 13 Feb 2006 03:19:28 -0500 Subject: gstreamer08 is dead; long live gstreamer In-Reply-To: <200602130747.k1D7lXGQ018834@porkchop.devel.redhat.com> References: <200602130747.k1D7lXGQ018834@porkchop.devel.redhat.com> Message-ID: <43F04110.3050002@redhat.com> Just a note that all the dependencies of gstreamer08 are gone from Core, and we will be removing gstreamer08 soon from Core. There is a package or two in extras that depends on it still, so this is a heads up that either it needs to be imported into Extras, or packages should be updated to use gstreamer 0.10. Thanks From bugzilla at redhat.com Mon Feb 13 08:24:39 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 03:24:39 -0500 Subject: [Bug 176373] Review Request: ytalk In-Reply-To: Message-ID: <200602130824.k1D8OdRt017054@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ytalk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176373 ------- Additional Comments From imlinux at gmail.com 2006-02-13 03:24 EST ------- I forgot to update this link. The new locations are at: SRPM: http://mmcgrath.net/~mmcgrath/ytalk/ytalk-3.3.0-2.src.rpm SPEC: http://mmcgrath.net/~mmcgrath/ytalk/ytalk.spec Also I've been sponsored since posting this bug. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From jfontain at free.fr Mon Feb 13 09:02:03 2006 From: jfontain at free.fr (jfontain at free.fr) Date: Mon, 13 Feb 2006 10:02:03 +0100 Subject: FC4: %fedora_useradd undefined from rpm install Message-ID: <1139821323.43f04b0bd92a0@imp2-g19.free.fr> On a newly installed up-to-date FC4 x86_64 machine: # rpm -i moomps-5.4-2.noarch.rpm %fedora_useradd with, in the spec file: %pre echo %fedora_useradd Same result if fedora-usermgmt package is installed -- Jean-Luc From gauret at free.fr Mon Feb 13 09:24:57 2006 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 13 Feb 2006 10:24:57 +0100 Subject: gstreamer08 is dead; long live gstreamer In-Reply-To: <43F04110.3050002@redhat.com> References: <200602130747.k1D7lXGQ018834@porkchop.devel.redhat.com> <43F04110.3050002@redhat.com> Message-ID: <200602131024.58482.gauret@free.fr> Le Lundi 13 F?vrier 2006 09:19, Christopher Aillon a ?crit : > Just a note that all the dependencies of gstreamer08 are gone from Core, > and we will be removing gstreamer08 soon from Core. There is a package > or two in extras that depends on it still, so this is a heads up that > either it needs to be imported into Extras, or packages should be > updated to use gstreamer 0.10. Amarok is one of those packages still depending on gstreamer 0.8. Version 1.4beta1 was out two days ago, and in the changelog there is : * Initial port of GStreamer engine to GStreamer 0.10. So I think amarok 1.4 final will use gstreamer 0.10 (I'm double-checking that with the devs). Amarok 1.4 will be out before FC5, so this package does not need gstreamer 0.8 imported into Extras. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr L'exp?rience est quelquechose que l'on acquiert juste apr?s en avoir eu besoin. From bugs.michael at gmx.net Mon Feb 13 09:49:09 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 13 Feb 2006 10:49:09 +0100 Subject: FC4: %fedora_useradd undefined from rpm install In-Reply-To: <1139821323.43f04b0bd92a0@imp2-g19.free.fr> References: <1139821323.43f04b0bd92a0@imp2-g19.free.fr> Message-ID: <20060213104909.71bb5772.bugs.michael@gmx.net> On Mon, 13 Feb 2006 10:02:03 +0100, jfontain at free.xx wrote: > On a newly installed up-to-date FC4 x86_64 machine: > > # rpm -i moomps-5.4-2.noarch.rpm > %fedora_useradd > > with, in the spec file: > %pre > echo %fedora_useradd > > Same result if fedora-usermgmt package is installed Unless my memory plays tricks on me, there has never been an RPM macro for fedora-usermgmt tools. You're looking for: /usr/sbin/fedora-useradd From bugzilla at redhat.com Mon Feb 13 10:12:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 05:12:13 -0500 Subject: [Bug 173522] Review Request: milter-regex milter filter regular expression based In-Reply-To: Message-ID: <200602131012.k1DACDmo002009@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: milter-regex milter filter regular expression based https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173522 ------- Additional Comments From paul at city-fan.org 2006-02-13 05:12 EST ------- This ticket has been closed NOTABUG - why was that? I've been using this package for some time (with SELInux enabled) and would like to see it in Extras. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From jfontain at free.fr Mon Feb 13 10:24:39 2006 From: jfontain at free.fr (jfontain at free.fr) Date: Mon, 13 Feb 2006 11:24:39 +0100 Subject: FC4: %fedora_useradd undefined from rpm install In-Reply-To: <20060213104909.71bb5772.bugs.michael@gmx.net> References: <1139821323.43f04b0bd92a0@imp2-g19.free.fr> <20060213104909.71bb5772.bugs.michael@gmx.net> Message-ID: <1139826279.43f05e677d78f@imp2-g19.free.fr> Quoting Michael Schwendt : > On Mon, 13 Feb 2006 10:02:03 +0100, jfontain at free.xx wrote: > > > On a newly installed up-to-date FC4 x86_64 machine: > > > > # rpm -i moomps-5.4-2.noarch.rpm > > %fedora_useradd > > > > with, in the spec file: > > %pre > > echo %fedora_useradd > > > > Same result if fedora-usermgmt package is installed > > Unless my memory plays tricks on me, there has never been an RPM > macro for fedora-usermgmt tools. You're looking for: > > /usr/sbin/fedora-useradd Then the http://fedoraproject.org/wiki/Packaging/UserCreation page needs an update. -- Jean-Luc From bugs.michael at gmx.net Mon Feb 13 10:42:35 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 13 Feb 2006 05:42:35 -0500 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-02-13 Message-ID: <200602131042.k1DAgZcC027354@mx1.redhat.com> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- amarok 1.3.6-1.fc5.i386 at-poke 0.2.2-2.i386 cyrus-imapd 2.2.12-6.fc4.i386 cyrus-imapd-murder 2.2.12-6.fc4.i386 cyrus-imapd-nntp 2.2.12-6.fc4.i386 cyrus-imapd-utils 2.2.12-6.fc4.i386 gnomebaker 0.5.1-2.fc5.i386 gstreamer08-python 0.8.3-1.fc5.i386 istanbul 0.1.1-5.i386 libgda-sqlite 1:1.2.0-8.i386 libgdamm 1.3.7-2.fc5.i386 ngrep 1.44-4.fc5.i386 octave-forge 2005.06.13-4.fc5.i386 pam_mount 0.9.25-4.i386 perl-Cyrus 2.2.12-6.fc4.i386 pgadmin3 1.0.2-5.i386 python-amara 0.9.4-7.fc4.noarch sabayon-admin 2.12.1-2.i386 scalapack 1.7-7.fc4.i386 seahorse 0.7.9-1.fc5.i386 soundconverter 0.8.3-1.fc5.noarch syck-php 0.55-6.fc5.i386 tidy-devel 0.99.0-8.20051025.fc5.i386 tripwire 2.3.1-22.i386 up-imapproxy 1.2.4-4.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- amarok 1.3.6-1.fc5.ppc at-poke 0.2.2-2.ppc cyrus-imapd 2.2.12-6.fc4.ppc cyrus-imapd-murder 2.2.12-6.fc4.ppc cyrus-imapd-nntp 2.2.12-6.fc4.ppc cyrus-imapd-utils 2.2.12-6.fc4.ppc gnomebaker 0.5.1-2.fc5.ppc gstreamer08-python 0.8.3-1.fc5.ppc istanbul 0.1.1-5.ppc libgda-sqlite 1:1.2.0-8.ppc libgdamm 1.3.7-2.fc5.ppc ngrep 1.44-3.fc5.ppc octave-forge 2005.06.13-4.fc5.ppc pam_mount 0.9.25-4.ppc perl-Cyrus 2.2.12-6.fc4.ppc pgadmin3 1.0.2-5.ppc python-amara 0.9.4-7.fc4.noarch sabayon-admin 2.12.1-2.ppc scalapack 1.7-7.fc4.ppc seahorse 0.7.9-1.fc5.ppc soundconverter 0.8.3-1.fc5.noarch syck-php 0.55-6.fc5.ppc tidy-devel 0.99.0-8.20051025.fc5.ppc up-imapproxy 1.2.4-4.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- amarok 1.3.6-1.fc5.x86_64 at-poke 0.2.2-2.x86_64 cernlib 2005-7.fc5.x86_64 cernlib-packlib 2005-7.fc5.x86_64 cyrus-imapd 2.2.12-6.fc4.x86_64 cyrus-imapd-murder 2.2.12-6.fc4.x86_64 cyrus-imapd-nntp 2.2.12-6.fc4.x86_64 cyrus-imapd-utils 2.2.12-6.fc4.x86_64 gnomebaker 0.5.1-2.fc5.x86_64 gstreamer08-python 0.8.3-1.fc5.x86_64 istanbul 0.1.1-5.x86_64 libgda-sqlite 1:1.2.0-8.x86_64 libgdamm 1.3.7-2.fc5.x86_64 ngrep 1.44-4.fc5.x86_64 octave-forge 2005.06.13-4.fc5.x86_64 pam_mount 0.9.25-4.x86_64 paw 2005-7.fc5.x86_64 perl-Cyrus 2.2.12-6.fc4.x86_64 pgadmin3 1.0.2-5.x86_64 python-amara 0.9.4-7.fc4.noarch sabayon-admin 2.12.1-2.x86_64 scalapack 1.7-7.fc4.x86_64 seahorse 0.7.9-1.fc5.x86_64 soundconverter 0.8.3-1.fc5.noarch syck-php 0.55-6.fc5.x86_64 tidy-devel 0.99.0-8.20051025.fc5.x86_64 up-imapproxy 1.2.4-4.fc5.x86_64 ---------------------------------------------------------------------- New report for: ivazquez AT ivazquez.net package: soundconverter - 0.8.3-1.fc5.noarch from fedora-extras-development-i386 unresolved deps: gstreamer08-plugins From bugs.michael at gmx.net Mon Feb 13 11:18:15 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 13 Feb 2006 12:18:15 +0100 Subject: FC4: %fedora_useradd undefined from rpm install In-Reply-To: <1139826279.43f05e677d78f@imp2-g19.free.fr> References: <1139821323.43f04b0bd92a0@imp2-g19.free.fr> <20060213104909.71bb5772.bugs.michael@gmx.net> <1139826279.43f05e677d78f@imp2-g19.free.fr> Message-ID: <20060213121815.4d348f0b.bugs.michael@gmx.net> On Mon, 13 Feb 2006 11:24:39 +0100, jfontain at free.fr wrote: > Quoting Michael Schwendt : > > > On Mon, 13 Feb 2006 10:02:03 +0100, jfontain at free.xx wrote: > > > > > On a newly installed up-to-date FC4 x86_64 machine: > > > > > > # rpm -i moomps-5.4-2.noarch.rpm > > > %fedora_useradd > > > > > > with, in the spec file: > > > %pre > > > echo %fedora_useradd > > > > > > Same result if fedora-usermgmt package is installed > > > > Unless my memory plays tricks on me, there has never been an RPM > > macro for fedora-usermgmt tools. You're looking for: > > > > /usr/sbin/fedora-useradd > > Then the http://fedoraproject.org/wiki/Packaging/UserCreation page needs an > update. In my understanding the page only discusses the pros and cons of possible "useradd" techniques in rpms. Hence the "Advantages" and "Disadvantages" sections. I don't read it as a HOWTO. From bugzilla at redhat.com Mon Feb 13 12:15:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 07:15:02 -0500 Subject: [Bug 180255] Review Request: nazghul - Old school RPG engine In-Reply-To: Message-ID: <200602131215.k1DCF2Vo019096@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: nazghul - Old school RPG engine https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180255 mfleming+rpm at enlartenment.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|bugzilla-sink at leemhuis.info |mfleming+rpm at enlartenment.co | |m ------- Additional Comments From mfleming+rpm at enlartenment.com 2006-02-13 07:14 EST ------- Point noted regarding the subpackage architecture (RFE?) I've downloaded the newer SRPM and am putting it through it's paces now. I'll let you know how it goes -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From jfontain at free.fr Mon Feb 13 12:53:31 2006 From: jfontain at free.fr (jfontain at free.fr) Date: Mon, 13 Feb 2006 13:53:31 +0100 Subject: FC4: %fedora_useradd undefined from rpm install In-Reply-To: <20060213121815.4d348f0b.bugs.michael@gmx.net> References: <1139821323.43f04b0bd92a0@imp2-g19.free.fr> <20060213104909.71bb5772.bugs.michael@gmx.net> <1139826279.43f05e677d78f@imp2-g19.free.fr> <20060213121815.4d348f0b.bugs.michael@gmx.net> Message-ID: <1139835211.43f0814b99663@imp2-g19.free.fr> Quoting Michael Schwendt : > On Mon, 13 Feb 2006 11:24:39 +0100, jfontain at free.fr wrote: > > > Quoting Michael Schwendt : > > > > > On Mon, 13 Feb 2006 10:02:03 +0100, jfontain at free.xx wrote: > > > > > > > On a newly installed up-to-date FC4 x86_64 machine: > > > > > > > > # rpm -i moomps-5.4-2.noarch.rpm > > > > %fedora_useradd > > > > > > > > with, in the spec file: > > > > %pre > > > > echo %fedora_useradd > > > > > > > > Same result if fedora-usermgmt package is installed > > > > > > Unless my memory plays tricks on me, there has never been an RPM > > > macro for fedora-usermgmt tools. You're looking for: > > > > > > /usr/sbin/fedora-useradd > > > > Then the http://fedoraproject.org/wiki/Packaging/UserCreation page needs an > > update. > > In my understanding the page only discusses the pros and cons of > possible "useradd" techniques in rpms. Hence the "Advantages" and > "Disadvantages" sections. I don't read it as a HOWTO. Understood, thanks. As packager, what am I supposed to do, especially when the following fails: # /usr/sbin/fedora-useradd -u 23 -M -d /srv/moomps -c 'service companion to moodss' -s '/sbin/nologin' moomps Usage: useradd [options] LOGIN Options: -b, --base-dir BASE_DIR base directory for the new user account ... Tracing the script, the following is executed: exec /usr/sbin/useradd 300 23 -M -d /srv/moomps -c 'service companion to moodss' -s /sbin/nologin moomps Is anybody using this? -- Jean-Luc From wart at kobold.org Mon Feb 13 13:08:30 2006 From: wart at kobold.org (Michael Thomas) Date: Mon, 13 Feb 2006 07:38:30 -0530 Subject: FC4: %fedora_useradd undefined from rpm install In-Reply-To: <1139835211.43f0814b99663@imp2-g19.free.fr> References: <1139821323.43f04b0bd92a0@imp2-g19.free.fr> <20060213104909.71bb5772.bugs.michael@gmx.net> <1139826279.43f05e677d78f@imp2-g19.free.fr> <20060213121815.4d348f0b.bugs.michael@gmx.net> <1139835211.43f0814b99663@imp2-g19.free.fr> Message-ID: <43F084CE.9000305@kobold.org> jfontain at free.fr wrote: > Quoting Michael Schwendt : > > >>On Mon, 13 Feb 2006 11:24:39 +0100, jfontain at free.fr wrote: >> >> >>>Quoting Michael Schwendt : >>> >>> >>>>On Mon, 13 Feb 2006 10:02:03 +0100, jfontain at free.xx wrote: >>>> >>>> >>>>>On a newly installed up-to-date FC4 x86_64 machine: >>>>> >>>>># rpm -i moomps-5.4-2.noarch.rpm >>>>>%fedora_useradd >>>>> >>>>>with, in the spec file: >>>>>%pre >>>>>echo %fedora_useradd >>>>> >>>>>Same result if fedora-usermgmt package is installed >>>> >>>>Unless my memory plays tricks on me, there has never been an RPM >>>>macro for fedora-usermgmt tools. You're looking for: >>>> >>>> /usr/sbin/fedora-useradd >>> >>>Then the http://fedoraproject.org/wiki/Packaging/UserCreation page needs an >>>update. >> >>In my understanding the page only discusses the pros and cons of >>possible "useradd" techniques in rpms. Hence the "Advantages" and >>"Disadvantages" sections. I don't read it as a HOWTO. > > > Understood, thanks. > As packager, what am I supposed to do, especially when the following fails: File a bug. > # /usr/sbin/fedora-useradd -u 23 -M -d /srv/moomps -c 'service companion to > moodss' -s '/sbin/nologin' moomps Remove the '-u' flag, but leave the flag's argument: /usr/sbin/fedora-useradd 23 -M -d /srv/moomps -c 'service companion to moodss' -s '/sbin/nologin' moomps > Usage: useradd [options] LOGIN > Options: > -b, --base-dir BASE_DIR base directory for the new user account > ... > > Tracing the script, the following is executed: > exec /usr/sbin/useradd 300 23 -M -d /srv/moomps -c 'service companion to moodss' > -s /sbin/nologin moomps > > Is anybody using this? Yes, in tclhttpd. --Wart From jfontain at free.fr Mon Feb 13 13:12:17 2006 From: jfontain at free.fr (jfontain at free.fr) Date: Mon, 13 Feb 2006 14:12:17 +0100 Subject: FC4: %fedora_useradd undefined from rpm install In-Reply-To: <1139835211.43f0814b99663@imp2-g19.free.fr> References: <1139821323.43f04b0bd92a0@imp2-g19.free.fr> <20060213104909.71bb5772.bugs.michael@gmx.net> <1139826279.43f05e677d78f@imp2-g19.free.fr> <20060213121815.4d348f0b.bugs.michael@gmx.net> <1139835211.43f0814b99663@imp2-g19.free.fr> Message-ID: <1139836337.43f085b1eca4a@imp2-g19.free.fr> Quoting jfontain at free.fr: > As packager, what am I supposed to do, especially when the following fails: > > # /usr/sbin/fedora-useradd -u 23 -M -d /srv/moomps -c 'service companion to > moodss' -s '/sbin/nologin' moomps > Usage: useradd [options] LOGIN > Options: > -b, --base-dir BASE_DIR base directory for the new user account > ... > > Tracing the script, the following is executed: > exec /usr/sbin/useradd 300 23 -M -d /srv/moomps -c 'service companion to > moodss' > -s /sbin/nologin moomps After replacing the lines: set -- "$v" "$@" with: set -- "-u $v" "$@" in /usr/share/fedora-usermgmt/wrapper, it work by removing the -u, as in: # /usr/sbin/fedora-useradd 23 -M -d /srv/moomps -c 'service companion to moodss' -s '/sbin/nologin' moomps Let me know if I need to create a bug report, -- Jean-Luc From enrico.scholz at informatik.tu-chemnitz.de Mon Feb 13 13:13:02 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 13 Feb 2006 14:13:02 +0100 Subject: FC4: %fedora_useradd undefined from rpm install In-Reply-To: <1139835211.43f0814b99663@imp2-g19.free.fr> (jfontain@free.fr's message of "Mon, 13 Feb 2006 13:53:31 +0100") References: <1139821323.43f04b0bd92a0@imp2-g19.free.fr> <20060213104909.71bb5772.bugs.michael@gmx.net> <1139826279.43f05e677d78f@imp2-g19.free.fr> <20060213121815.4d348f0b.bugs.michael@gmx.net> <1139835211.43f0814b99663@imp2-g19.free.fr> Message-ID: <874q33mmg1.fsf@kosh.bigo.ensc.de> jfontain at free.fr writes: > As packager, what am I supposed to do, especially when the following fails: > > # /usr/sbin/fedora-useradd -u 23 -M -d /srv/moomps -c 'service companion to moodss' -s '/sbin/nologin' moomps ~~ This '-u' is too much. Just write | /usr/sbin/fedora-useradd 23 -M ... The script decides what happens with the '23'. Btw, you should add a '-r' option. Enrico From bugzilla at redhat.com Mon Feb 13 13:28:37 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 08:28:37 -0500 Subject: [Bug 181068] Review Request: html401-dtds - HTML 4.01 document type definitions In-Reply-To: Message-ID: <200602131328.k1DDSb8O031891@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: html401-dtds - HTML 4.01 document type definitions https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181068 ------- Additional Comments From veillard at redhat.com 2006-02-13 08:28 EST ------- :-) Note that there is no garantee that SGML tools will handle XML correctly, it will parse but for example they will probably misprocess xml:base or xml:id , checking dependancies to those one a case by case basis before pushing on both catalogs will be a good idea :-) Daniel -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 13 13:33:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 08:33:07 -0500 Subject: [Bug 180255] Review Request: nazghul - Old school RPG engine In-Reply-To: Message-ID: <200602131333.k1DDX7pb032762@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: nazghul - Old school RPG engine https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180255 mfleming+rpm at enlartenment.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From mfleming+rpm at enlartenment.com 2006-02-13 08:33 EST ------- Review for release 2: * RPM name is OK * Source nazghul-0.5.3.tar.gz is the same as upstream * This is the latest version * Builds fine in mock * rpmlint of nazghul looks OK * File list of nazghul looks OK * File list of nazghul-haxima looks OK * Runs perfectly well on Core 4 with current updates Needs work (but not a blocker IMHO): W: nazghul-haxima no-documentation * Something in %doc for the haxima subpackage to keep rpmlint happy? I'm old enough to remember the old Ultimas, the young 'uns might not be so fortunate - RFE upstream for some backstory? :-P But I digress... APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 13 14:32:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 09:32:28 -0500 Subject: [Bug 181013] Review Request: qgit - a GUI browser for local git repositories In-Reply-To: Message-ID: <200602131432.k1DEWSjr011822@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: qgit - a GUI browser for local git repositories https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181013 ------- Additional Comments From dan at danny.cz 2006-02-13 09:32 EST ------- Just checked that it builds in mock for devel. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From gdk at redhat.com Mon Feb 13 14:51:16 2006 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Mon, 13 Feb 2006 09:51:16 -0500 (EST) Subject: Fedora SIGs In-Reply-To: <1139142051.2948.5.camel@localhost.localdomain> References: <1139142051.2948.5.camel@localhost.localdomain> Message-ID: "Action: Create SIGs (Special Interest Groups). Which ones? Good question. Ignacio already started a bit of work at http://www.fedoraproject.org/wiki/Extras/SIGs Current groups: GNOME, KDE, Multimedia, Perl, Python, Ruby, Scientific and Technical, Server Tools, ppc, x86-64. Do we need more? Input needed!" We talked a lot about this at FUDCon Delhi last week. Specifically, a lot of talking about building relationships between SIGs like these and the Fedora Mentors project. Good stuff. Keep going. --g --------------------------------------------------------------- Greg DeKoenigsberg || Fedora Foundation || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors --------------------------------------------------------------- On Sun, 5 Feb 2006, Thorsten Leemhuis wrote: > Find below a summary from the last FESCo meeting. Full log and this > summary in a prettier format is available from: > http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060202 > > The Agenda, often with links to some more detailed background on the > topics is found at > http://www.fedoraproject.org/wiki/Extras/Schedule > > * Cleanup the Schedule from non-extras tasks > > Discussed some items and removed them. FC5 naming is still there: > {{{ > Sopwith> | And the naming thing just needs someone to adopt it. > thl> | Sopwith, who is someone? > f13> | thl: could be someone interested, however somebody at red hat will still have to get it pushed through legal. > Sopwith> | thl: I'm writing an e-mail to jkeating right now - he's the one that'll have to make it happen... > f13> | Sopwith: thanks. > f13> | Sopwith: I'll make it happen > }}} > > * Mass Rebuild of FE5 > > We still can't start yet, need to wait for another rebuild in core > > * EOL Policy for FE > > The current plan found at > http://www.fedoraproject.org/wiki/Extras/Schedule/EolPolicy is this: > {{{ > This is a rough draft of what to do about Extras when a Fedora release > goes EOL. > > When a Fedora Core release reaches End of Life (such as Fedora Core 3 > will once Fedora Core 5 Test 2 is released), the corresponding release > of Fedora Extras well enter a Maintenance state. In this state > maintainers will be allowed to issue updates to existing packages, but > no new packages can be introduced. Maintainers are strongly urged to > only issue severe bugfix or security fixes. New software versions > should be avoided except when necessary for resolving issues with the > the current version. At this point there is no plan to close a release > of Fedora Extras, preventing any further package releases. > > While the Fedora Core release will be transferred to the Fedora Legacy > project, Fedora Legacy will not be responsible for maintaining Fedora > Extras. We feel it is better for the current package maintainer to > continue handling package releases for the Fedora Extras release that is > in maintenance state. > }}} > > Speak up now or this will be policy soon. > > * Encourage Extras reviews > > Current state: 134 Bugs in the new state, 54 under review -- some for a > very long time already! > > Action: Create SIGs (Special Interest Groups). Which ones? Good > question. Ignacio already started a bit of work at > http://www.fedoraproject.org/wiki/Extras/SIGs > Current groups: GNOME, KDE, Multimedia, Perl, Python, Ruby, Scientific > and Technical, Server Tools, ppc, x86-64. Do we need more? Input > needed! > > Action: Review days (general or specific to the SIGs) may help getting > stuff reviewed -- somebody needs to work out the details. > > Help-Needed -- interested to work in one of the SIGs? Add yourself to > the wiki-pages! > > Undecided: Maybe separate mailing-lists for the SIGs > > Undecided: How to track the bugs for the SIGs? Tracker-BUGs? Wiki? > > * Broken deps report > > mschwendt has a handy script that does most things automatic. Should > run in the future with every extras push. mschwendt will send the > current proposal to fedora-extras-list for futher discussion and put the > script in a public place. > > * JesseKeating wants to remove himself from FESCo > > "I was on FESCO mostly because of Legacy, which is its own project now. > I rarely have anything to do w/ FESCO and it doesn't make sense for me > to be trying ot make decisions for hte project." > > We didn't let him go for now :-) > > Okay, now seriously: We need to work out the details who is in FESCo, > why, how to get in, how to get out, when people are thrown out to make > space for more active people, how many people should be in FESCo in > general, how the chair gets elected and similar stuff. Opinions? > > * We should discuss more topics on mailing-lists > > Some discussion in FESCo were done on the private FESCo-Mailinglist. We > should avoid this in the future as much as possible and discuss > everything on fedora-extras-list directly. > > We also should discuss less in the FESCo meetings on IRC and more on > the lists where everyone can participate. > > > BTW, sorry for the delay, I didn't find time earlier to write this > summary. > -- > Thorsten Leemhuis > From bugzilla at redhat.com Mon Feb 13 15:25:25 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 10:25:25 -0500 Subject: [Bug 178901] Review Request: gtksourceview-sharp In-Reply-To: Message-ID: <200602131525.k1DFPPmU023312@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gtksourceview-sharp https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178901 ------- Additional Comments From paul at all-the-johnsons.co.uk 2006-02-13 10:25 EST ------- It looks like mcs is still borked. I thought that it was down to a kernel problem with lookups for files, but it's not. Hopefully, today's rebuild fixes these problems. It could just be a gcc problem when mono/mcs was built. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 13 15:27:42 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 10:27:42 -0500 Subject: [Bug 178901] Review Request: gtksourceview-sharp In-Reply-To: Message-ID: <200602131527.k1DFRgHs023990@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gtksourceview-sharp https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178901 ------- Additional Comments From paul at all-the-johnsons.co.uk 2006-02-13 10:27 EST ------- #1 - the problem is that when it begins to compile, mcs looks for /usr/lib/pkgconfig/../../share/gapi-2.0/gnome-api.xml and doesn't find it. I don't understand why that should be the case as it does exist! -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From ndbecker2 at gmail.com Mon Feb 13 15:37:55 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 13 Feb 2006 10:37:55 -0500 Subject: Summary from the last FESCo meeting References: <1139142051.2948.5.camel@localhost.localdomain> Message-ID: Just curious, what is the markup language being used here? I recognize it (e.g., '{{{'), but can't quite recall which it is. From sundaram at fedoraproject.org Mon Feb 13 15:43:16 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 13 Feb 2006 21:13:16 +0530 Subject: Summary from the last FESCo meeting In-Reply-To: References: <1139142051.2948.5.camel@localhost.localdomain> Message-ID: <43F0A914.204@fedoraproject.org> Neal Becker wrote: >Just curious, what is the markup language being used here? I recognize it >(e.g., '{{{'), but can't quite recall which it is. > > > Moinmoin markup in http://fedoraproject.org wiki. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From jeff at ocjtech.us Mon Feb 13 15:47:43 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Mon, 13 Feb 2006 09:47:43 -0600 Subject: Fedora SIGs In-Reply-To: References: <1139142051.2948.5.camel@localhost.localdomain> Message-ID: <1139845663.2801.26.camel@lt16585.campus.dmacc.edu> On Mon, 2006-02-13 at 09:51 -0500, Greg DeKoenigsberg wrote: > "Action: Create SIGs (Special Interest Groups). Which ones? Good question. > Ignacio already started a bit of work at > http://www.fedoraproject.org/wiki/Extras/SIGs Current groups: GNOME, KDE, > Multimedia, Perl, Python, Ruby, Scientific and Technical, Server Tools, > ppc, x86-64. Do we need more? Input needed!" > > We talked a lot about this at FUDCon Delhi last week. Specifically, a lot > of talking about building relationships between SIGs like these and the > Fedora Mentors project. > I'd like to see a VoIP SIG. There are two major VoIP packages waiting for review, Asterisk and SER. I've committed to reviewing SER so that should get into FE once the package is ready. The Asterisk packages are likely to take a little bit because it requires 3rd party kernel modules and that's waiting on kernel module support in the build system. The Asterisk packages could use some QA love while we're waiting for the build system to be updated. Here are links to Asterisk and related packages: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171597 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177583 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177584 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177603 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178922 Here's the SER package: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 If someone can set me up with edit access on the wiki (user name JeffOllie) I can do the work of setting up the SIG pages. 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 sundaram at fedoraproject.org Mon Feb 13 15:59:53 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 13 Feb 2006 21:29:53 +0530 Subject: Fedora SIGs In-Reply-To: <1139845663.2801.26.camel@lt16585.campus.dmacc.edu> References: <1139142051.2948.5.camel@localhost.localdomain> <1139845663.2801.26.camel@lt16585.campus.dmacc.edu> Message-ID: <43F0ACF9.3060403@fedoraproject.org> Hi > >If someone can set me up with edit access on the wiki (user name >JeffOllie) I can do the work of setting up the SIG pages. > > Added. Refer to http://fedoraproject.org/wiki/WikiEditing before getting started. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From bugzilla at redhat.com Mon Feb 13 16:02:55 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 11:02:55 -0500 Subject: [Bug 180255] Review Request: nazghul - Old school RPG engine In-Reply-To: Message-ID: <200602131602.k1DG2tYJ031226@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: nazghul - Old school RPG engine https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180255 ------- Additional Comments From tibbs at math.uh.edu 2006-02-13 11:02 EST ------- It seems there are 64bit issues which prevent the package from building on x86_64. Catsting void* to int, it looks like. I didn't think people did that any longer. I'm going to hack around a bit before declaring this ExclusiveArch: i386. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 13 16:26:39 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 11:26:39 -0500 Subject: [Bug 180743] Review Request: pdsh In-Reply-To: Message-ID: <200602131626.k1DGQdfb003244@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: pdsh https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180743 Jochen at herr-schmitt.de changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-13 11:26 EST ------- Unfortunately I have some more complaints about your package: - Please use %{_initrddir} instead of /etc/init.d Best Regards: Jochen Schmitt -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 13 16:40:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 11:40:30 -0500 Subject: [Bug 180747] Review Request: powerman In-Reply-To: Message-ID: <200602131640.k1DGeUEI006972@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: powerman https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180747 Jochen at herr-schmitt.de changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: powerman |Review Request: powerman OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-13 11:40 EST ------- I have found some issue: - Source should cotain a full-qualified URL. - BuildRoot should be %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) - /usr/bin should be replace by %{_bindir} - /usr/sbin should be replace by %{_sbindir} - /usr/man should be replace by %{_mandir} - /etc/rc.d/init.d/ shoud be replace by %{_initrddir} - %doc should contain a verbatin copy of the license used by this package. - local build failed. Error messages: make[1]: Leaving directory `/home/pclinux/redhat/BUILD/powerman-1.0.22-1/src' /usr/bin/make -C test make[1]: Entering directory `/home/pclinux/redhat/BUILD/powerman-1.0.22-1/test' cc -g -Wall -I../src -DHAVE_CONFIG_H -c -o vpcd.o vpcd.c vpcd.c: In function '_vpc_thread': vpcd.c:286: warning: pointer targets in passing argument 3 of 'accept' differ in signedness vpcd.c: In function 'main': vpcd.c:393: error: 'PTHREAD_THREADS_MAX' undeclared (first use in this function) vpcd.c:393: error: (Each undeclared identifier is reported only once vpcd.c:393: error: for each function it appears in.) make[1]: *** [vpcd.o] Error 1 make[1]: Leaving directory `/home/pclinux/redhat/BUILD/powerman-1.0.22-1/test' make: *** [tests] Error 2 Best Regards: Jochen Schmitt -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From fedora at leemhuis.info Mon Feb 13 17:22:42 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 13 Feb 2006 18:22:42 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras Message-ID: <1139851362.2904.79.camel@localhost.localdomain> Replies to fedora-extras-list please, tia! Hi Fedora Maintainers! The last rawhide mass-rebuild is mostly done now so it's time for us to also rebuild **all packages** in the Fedora Extras development tree before it becomes Fedora Extras 5 (FE) when Fedora Core 5 is branched/released. Why a rebuild of all packages? There are several reasons, the most important: - use the security features the new gcc 4.1 provides - make sure everything still builds with gcc 4.1, modular xorg and all the other things that have changed since FC4 How does it work? Very simple: If you have a package in Fedora Extras checkout a fresh version from cvs, increase "Release" by one and add a changelog-entry with and explanation like "Rebuild for Fedora Extras 5". Then run the usual "make tag build". While at it make sure that the upgrade path from FE4 to FE5 works -- e.g. the epoch:version-release of a package in the devel-tree/FE5 needs to be higher than in FE4 (hint: use fedora-rpmvercmp from fedora-rpmdevtools if you want to test which epoch:version-release is higher). Are there any specific things that need attention? The most important: - Please don't flood the buildsys with to many rebuild requests. E.g. before you run make build take a look at the buildsys web interface at http://buildsys.fedoraproject.org/build-status/ If there are many jobs listed already (let's say more then round about 40 packages) then please wait with the rebuild request some hours or a day. Why that? We have no priorities in the buildsys atm, but need a chance to get urgent updates for FC-4 and/or FC-3 build in case a security problem arises in an extras package. - Don't request rebuilds for FC-4 or FC-3 just to keep the spec files in sync in all branches. This would mean a extra burden for the buildsys and for the users (they would have to download new packages where nothing changed) Do all packages need a rebuild? Yes. Most noarch packages probably would work fine without a rebuild and won't have a benefit from the new gcc security features. But we know that some noarch package are broken due to changes in rawhide -- we'd like to catch and fix those. And we want to make sure that a package still has a active maintainer while at it. If you want to be nice please submit the noach rebuild request only after February the 18th or when less then 10 packages are in the buildsys build queue. Should the build-requests happen in dep-order? They should in an ideal world -- but we chose to ignore it (core ignores the order, too, and it works fine). If you know that build-order is important to your package please take care of it manually. You don't like it? Then work on a better solution for the FE6 rebuild ;-) What about orphaned packages? They should be removed by now. If you need one of them to build your package you probably have to adopt them (we might have one or two such cases) What shall I do if a rebuild failed? Fix it. If you need help ask on fedora-extras-list and/or on #fedora-extras. It might be a good idea to use some tagging in the subject when posting to the list, e.g.: [gcc] - for problems specific to gcc [xorg] - for problems related to modular xorg [x86-64] - for problems specific to x86_64 [ppc] - for problems specific to pcc [python] - for problems related to python [perl] - for problems related to perl [gtk/gnome] - for problems related to GTK/GNOME [qt/kde] - for problems related to Qt/KDE *Note*: If you can't fix it until February the 24th please file a bug in bugzilla.redhat.com for the problem. In the field "Bug XYZ Block" please add "FE5Target" -- this way it blocks the tracker bug 162161. This bureaucracy is needed to allow other people to track the status of the packages not yet rebuild. What happens with packages where no one stepped up to rebuild them? Ehhh, we didn't talk about that to much yet. Maybe we'll file bugs after the rebuild flood goes back and ask the package-maintainer to rebuild his or her package(s). Or we simply rebuild them and ignore the maintainer -- but in that case we can't be sure that the maintainer is still active in Fedora Extras. What happens with the old packages build before February the 13th 2006? They'll probably be removed from the repo before FE5 goes live. That's all. Thanks for you attention. CU thl /me hopes that he hasn't forgotten anything important -- Thorsten Leemhuis From roozbeh at farsiweb.info Mon Feb 13 17:47:08 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Mon, 13 Feb 2006 21:17:08 +0330 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139851362.2904.79.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> Message-ID: <1139852828.3234.35.camel@tameshk.farsiweb.info> ??? ??????? 2006-02-13 ???? 18:22 +0100? Thorsten Leemhuis ????: > While at it make sure that the upgrade path from FE4 to FE5 works -- > e.g. the epoch:version-release of a package in the devel-tree/FE5 needs > to be higher than in FE4 (hint: use fedora-rpmvercmp from > fedora-rpmdevtools if you want to test which epoch:version-release is > higher). Something noteworthy: If you are not sure why rpmvercmp does a certain thing in a certain way, check the following page: http://fedoraproject.org/wiki/Tools/RPM/VersionComparison roozbeh From kevin-fedora-extras at scrye.com Mon Feb 13 17:57:01 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Mon, 13 Feb 2006 10:57:01 -0700 (MST) Subject: Fedora Extras Review day #1 2006-02-15 Message-ID: <20060213.105701.503950290.kevin@scrye.com> Greetings. One of the ideas that came up in the last FESCo meeting to help get more reviews going was suggested by me: Have a IRC Review Day. I have created a Wiki page on it, available at: http://fedoraproject.org/wiki/Extras/ReviewDay The first Review Day is scheduled for this coming Wednsday starting at 9am in your local timezone. Come join us in #fedora-extras on irc.freenode.net and review some packages. Feedback welcome. Hope to see lots of folks there and reviewing! kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Mon Feb 13 18:08:21 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 13 Feb 2006 19:08:21 +0100 Subject: unorphaning packages Message-ID: <20060213180821.GL2976@free.fr> Hello, I have taken over the orphaned perl-Parse-Yapp and libnet10, but I cannot edit the wiki page http://fedoraproject.org/wiki/Extras/OrphanedPackages Could somebody do it, please? -- Pat From sundaram at fedoraproject.org Mon Feb 13 18:12:41 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 13 Feb 2006 23:42:41 +0530 Subject: unorphaning packages In-Reply-To: <20060213180821.GL2976@free.fr> References: <20060213180821.GL2976@free.fr> Message-ID: <43F0CC19.8090307@fedoraproject.org> Patrice Dumas wrote: >Hello, > >I have taken over the orphaned perl-Parse-Yapp and libnet10, but I cannot >edit the wiki page >http://fedoraproject.org/wiki/Extras/OrphanedPackages > >Could somebody do it, please? > > > > Register in the wiki and ask anyone within the edit group to add you there for write access. http://fedoraproject.org/wiki/WikiEditing -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From fedora at leemhuis.info Mon Feb 13 18:15:32 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 13 Feb 2006 19:15:32 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139851362.2904.79.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> Message-ID: <1139854532.2904.83.camel@localhost.localdomain> Am Montag, den 13.02.2006, 18:22 +0100 schrieb Thorsten Leemhuis: > Are there any specific things that need attention? > > The most important: > - Please don't flood the buildsys with to many rebuild requests. E.g. > before you run make build take a look at the buildsys web interface at > http://buildsys.fedoraproject.org/build-status/ > If there are many jobs listed already (let's say more then round about > 40 packages) then please wait with the rebuild request some hours or a > day. Why that? We have no priorities in the buildsys atm, but need a > chance to get urgent updates for FC-4 and/or FC-3 build in case a > security problem arises in an extras package. That was a stupid idea -- the web interface does not list all packages that are in the waiting state. So use something like the following to get the number of packages that are waiting in the buildsys already: $ plague-client list status waiting | grep -e '^$' | wc -l 38 -- Thorsten Leemhuis From sundaram at fedoraproject.org Mon Feb 13 18:16:30 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 13 Feb 2006 23:46:30 +0530 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139852828.3234.35.camel@tameshk.farsiweb.info> References: <1139851362.2904.79.camel@localhost.localdomain> <1139852828.3234.35.camel@tameshk.farsiweb.info> Message-ID: <43F0CCFE.6030003@fedoraproject.org> Roozbeh Pournader wrote: >??? ??????? 2006-02-13 ???? 18:22 +0100? Thorsten Leemhuis ????: > > >>While at it make sure that the upgrade path from FE4 to FE5 works -- >>e.g. the epoch:version-release of a package in the devel-tree/FE5 needs >>to be higher than in FE4 (hint: use fedora-rpmvercmp from >>fedora-rpmdevtools if you want to test which epoch:version-release is >>higher). >> >> > >Something noteworthy: > >If you are not sure why rpmvercmp does a certain thing in a certain way, >check the following page: > >http://fedoraproject.org/wiki/Tools/RPM/VersionComparison > >roozbeh > > > When you create sub pages kindly ensure that the main pages refer to them and they are categorized properly. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From buildsys at fedoraproject.org Mon Feb 13 18:25:06 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 13 Feb 2006 13:25:06 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060213182506.5D0C08011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 2 abcm2ps-4.12.8-1.fc3 pptp-1.7.1-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon Feb 13 18:25:10 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 13 Feb 2006 13:25:10 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060213182510.CFF438011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 4 abcm2ps-4.12.8-1.fc4 bzr-0.7-3.fc4 perl-Log-Log4perl-1.03-2.fc4 pptp-1.7.1-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon Feb 13 18:25:29 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 13 Feb 2006 13:25:29 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060213182529.17DD68011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 42 Glide3-20050815-3.fc5 SDL_image-1.2.4-5.fc5 SDL_mixer-1.2.6-6.fc5 SDL_net-1.2.5-8.fc5 abcm2ps-4.12.8-1.fc5 alsa-tools-1.0.10-2.fc5 banner-1.3.1-2.fc5 brightside-1.4.0-10.fc5 bwm-ng-0.5-6.fc5 byzanz-0.1.0-5.fc5 bzr-0.7-3.fc5 contact-lookup-applet-0.13-8.fc5 dkms-2.0.9-2.fc5 fuse-2.5.2-3.fc5 fuse-sshfs-1.4-2.fc5 goffice-0.1.2-4.fc5 gpp-0.6.5-3.fc5 i810switch-0.6.5-2.fc5 lacewing-1.10-4.fc5 libeXosip2-2.2.2-3.fc5 ngrep-1.44-4.fc5 overgod-1.0-3.fc5 perl-Mail-Alias-1.12-6.fc5 perl-UNIVERSAL-can-1.11-1.fc5 perl-Unix-Statgrab-0.03-7.fc5 pptp-1.7.1-1.fc5 pybliographer-1.2.8-2.fc5 python-amara-1.1.7-1.fc5 python-bibtex-1.2.2-3.fc5 rblcheck-1.5-10.fc5 recode-3.6-21.fc5 scanssh-2.1-6.fc5 svgalib-1.9.24-2.fc5 syck-0.55-6.fc5 ttywatch-0.14-5.fc5 xmms-1.2.10-20.fc5 xmms-acme-0.4.3-5.fc5 xmms-arts-0.7.1-2 xmms-crossfade-0.3.10-1.fc5 xmms-flac-1.1.2-26.fc5 xmms-lirc-1.4-7.fc5 xmms-speex-0.9.1-6.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Mon Feb 13 18:22:12 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 13:22:12 -0500 Subject: [Bug 181068] Review Request: html401-dtds - HTML 4.01 document type definitions In-Reply-To: Message-ID: <200602131822.k1DIMC2f001887@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: html401-dtds - HTML 4.01 document type definitions https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181068 link at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |link at pobox.com ------- Additional Comments From link at pobox.com 2006-02-13 13:22 EST ------- The package in general looks good to me. I'd suggest either dropping the actual text of the specification entirely or simply include it as %doc. Having a separate sub-package for this seems essentially overkill. Alternately I'd package up the spec and have the DTDs tag along (as they're a normative part of the HTML 4.01 Recommendation). The .ent(ity) files might beneficially be shipped by sgml-common -- since they're common for HTML 2.0, 3.2, 4.0, and 4.01 -- and shared by the relevant packages (cf. the comment at the top of the spec file). For the %description I might use something along the lines of: [[[ Provides the three HTML 4.01 DTDs (strict, frameset, and transitional). The DTDs are required for processing HTML 4.01 document instances using SGML tools such as OpenSP, OpenJade, or SGMLSpm. ]]] -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 13 18:37:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 13:37:13 -0500 Subject: [Bug 181369] New: Review Request: libedit - The NetBSD Editline library Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181369 Summary: Review Request: libedit - The NetBSD Editline library Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: michael at knox.net.nz QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.knox.net.nz/fedora_extras/libedit.spec SRPM Name or Url: http://www.knox.net.nz/fedora_extras/libedit-2.9-20060103cvs.1.src.rpm Description: This is an autotool- and libtoolized port of the NetBSD Editline library (libedit). This Berkeley-style licensed command line editor library provides generic line editing, history, and tokenization functions, similar to those found in GNU Readline. I use this very often with work and since i use FC as my OS of choice, I figured why not get it into too extras. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 13 18:41:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 13:41:33 -0500 Subject: [Bug 171597] Review Request: spandsp - A DSP library for telephony In-Reply-To: Message-ID: <200602131841.k1DIfX1q006299@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: spandsp - A DSP library for telephony https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171597 ------- Additional Comments From gauret at free.fr 2006-02-13 13:41 EST ------- Sorry to get back so late. Review for release 0.2.pre4: * RPM name is OK * Source spandsp-0.0.3pre4.tgz is the same as upstream * Builds fine in mock * rpmlint looks OK * File list looks OK Everything looks OK to me packaging-wise, but I'd like to test-run it if possible. Is there a program linked to it I could try ? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From Jochen at herr-schmitt.de Mon Feb 13 18:52:24 2006 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 13 Feb 2006 19:52:24 +0100 Subject: Seting of FE-REVIEW for reviewing packages Message-ID: <0ML2ov-1F8ioP1oXi-0000fa@mrelayeu.kundenserver.de> Hello, becouse I read, that a lot of packages are retain in the FE-REVIEW status, I started to try to review some packages. During this I found out, that there are a lot of packages review requests where the review process was started, but the state was retain at FE-REVIEW. So I have changed the state on some package review requests I have found. Best Regards: Jochen Schmitt From bugs.michael at gmx.net Mon Feb 13 18:55:03 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 13 Feb 2006 19:55:03 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139851362.2904.79.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> Message-ID: <20060213195503.776b3aee.bugs.michael@gmx.net> On Mon, 13 Feb 2006 18:22:42 +0100, Thorsten Leemhuis wrote: > Do all packages need a rebuild? > > Yes. No. > Most noarch packages probably would work fine without a rebuild and > won't have a benefit from the new gcc security features. But we know > that some noarch package are broken due to changes in rawhide -- we'd > like to catch and fix those. And we want to make sure that a package > still has a active maintainer while at it. It's still short-sighted, since 1) A forced rebuild, just to check whether a package still builds, is something that can be done by the maintainer _locally_ using mock or with FC5 Test 3. 2) There are exceptions. Noarch packages which really don't need a rebuild. Either it does or it doesn't. If it doesn't, the rebuild/update is not needed. > What happens with packages where no one stepped up to rebuild them? > > Ehhh, we didn't talk about that to much yet. Maybe we'll file bugs after > the rebuild flood goes back and ask the package-maintainer to rebuild > his or her package(s). Or we simply rebuild them and ignore the > maintainer -- but in that case we can't be sure that the maintainer is > still active in Fedora Extras. We can't be sure of that anyway, because who checks whether more than a rebuild would make sense? E.g. new upstream releases not been applied prior to a rebuild done by the maintainer. We should rely a bit more on the user community who helps with reporting packages which are out-of-date or broken. > What happens with the old packages build before February the 13th 2006? > > They'll probably be removed from the repo before FE5 goes live. Veto. Removing broken orphans can cause enough poor dep breakage already during a Yum upgrade. So let's keep the number of removed packages low. Mind you, a broken installed package is not excluded from a transaction check, so anything that's installed already but missing in the repository is bad (as it won't be upgraded with something working and will cause the upgrade to fail). If you remove more than what is known to be broken, this increases the risk of breaking even further, at least for some users. We may remove what's broken and track it on the FC5Status page in the Wiki just as we did for FE4 and older. From bugzilla at redhat.com Mon Feb 13 18:53:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 13:53:30 -0500 Subject: [Bug 181068] Review Request: html401-dtds - HTML 4.01 document type definitions In-Reply-To: Message-ID: <200602131853.k1DIrU78008582@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: html401-dtds - HTML 4.01 document type definitions https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181068 ------- Additional Comments From ville.skytta at iki.fi 2006-02-13 13:53 EST ------- Well, the specification is already in the source tarball, so let's just package it somewhere. I don't have that strong opinions on actually _where_, but FWIW, the DTDs are about 30kB and the documentation is 370kB. Note that *.ent are the same "only" in 4.0, 4.01, and ISO-HTML; not 2.0 or 3.2. I'm not against including them in sgml-common (or let's say a hypothetical html-common) package, but I think the approach here is good enough at least for now, and doesn't require waiting for the FC sgml-common package to be updated, possibly also for earlier distro versions etc. And including them here makes it easier to maintain a self-contained catalog containing only the HTML 4.01 stuff in /usr/share/sgml/ which is always nice to have. The description sounds good to me, will adopt for the next package revision, due out when other things discussed here have been agreed on. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From roozbeh at farsiweb.info Mon Feb 13 19:01:50 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Mon, 13 Feb 2006 22:31:50 +0330 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <43F0CCFE.6030003@fedoraproject.org> References: <1139851362.2904.79.camel@localhost.localdomain> <1139852828.3234.35.camel@tameshk.farsiweb.info> <43F0CCFE.6030003@fedoraproject.org> Message-ID: <1139857311.8592.1.camel@tameshk.farsiweb.info> ??? ??????? 2006-02-13 ???? 23:46 +0530? Rahul Sundaram ????: > When you create sub pages kindly ensure that the main pages refer to > them and they are categorized properly. Sure. Done. roozbeh From orion at cora.nwra.com Mon Feb 13 19:05:35 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 13 Feb 2006 12:05:35 -0700 Subject: What to do with generic man3 entries Message-ID: <43F0D87F.6080006@cora.nwra.com> I just packaged up ncarg for FE devel. It delivers a lot of man3 entries, many with common names like "line". OK - this is a bad thing, but how should one fix it in general? Prefix all man3 entries with ncarg_ ? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From orion at cora.nwra.com Mon Feb 13 19:07:17 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 13 Feb 2006 12:07:17 -0700 Subject: Finding file conflicts Message-ID: <43F0D8E5.3020002@cora.nwra.com> It seems like part of the review process should be to check for file conflicts between the new package and all of FC/FE. Can this be done easily? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From bugzilla at redhat.com Mon Feb 13 19:43:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 14:43:21 -0500 Subject: [Bug 165311] Review Request: Tiger, security auditing on UNIX systems In-Reply-To: Message-ID: <200602131943.k1DJhLml018829@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Tiger, security auditing on UNIX systems https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165311 j.w.r.degoede at hhs.nl changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163776 nThis| | ------- Additional Comments From j.w.r.degoede at hhs.nl 2006-02-13 14:43 EST ------- Changing back to FE-NEW. Jochen, the review hasn't started yet, to quote Keven: "Not a review" and me "might be willing todo a review" so no review has been started yet. I saw your mail to f-e-list that you're going todo this to other bugs too, please don't unless the review has really started. Also see the asigned field. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 13 20:16:31 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 15:16:31 -0500 Subject: [Bug 171597] Review Request: spandsp - A DSP library for telephony In-Reply-To: Message-ID: <200602132016.k1DKGVMU025257@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: spandsp - A DSP library for telephony https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171597 ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-13 15:16 EST ------- No problemo... I understand fully about busy schedules... The only real program that I have right now that uses spandsp is Asterisk (#178922), which would take quite a bit to get set up just to test spandsp. There is some test code included with spandsp but I haven't figured out the magic incantation to get it the tests to compile. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 13 20:44:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 15:44:33 -0500 Subject: [Bug 181404] New: Review Request: emacs-muse Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 Summary: Review Request: emacs-muse Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: jonathan.underwood at gmail.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://physics.open.ac.uk/~ju83/emacs-muse.spec SRPM Name or Url: http://physics.open.ac.uk/~ju83/emacs-muse-3.02.6a-1.jgu.src.rpm Description: Emacs Muse is an authoring and publishing environment for Emacs. It simplifies the process of writings documents and publishing them to various output formats. Muse uses a very simple Wiki-like format as input. Muse can publish to the following formats. * Blosxom * DocBook * HTML * LaTeX * PDF * Texinfo * XHTML * XML -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 13 20:47:37 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 15:47:37 -0500 Subject: [Bug 181404] Review Request: emacs-muse In-Reply-To: Message-ID: <200602132047.k1DKlbOp032624@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 ------- Additional Comments From jonathan.underwood at gmail.com 2006-02-13 15:47 EST ------- Should have mentioned: This is my first package for FE, and I require a sponsor. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 13 21:04:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 16:04:15 -0500 Subject: [Bug 174325] Review Request: mod_spin Apache module In-Reply-To: Message-ID: <200602132104.k1DL4FAD003352@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mod_spin Apache module https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174325 imlinux at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |imlinux at gmail.com ------- Additional Comments From imlinux at gmail.com 2006-02-13 16:04 EST ------- Bojan, I see your comment #6 but if you do want this to be in Extras you're going to need to submit an actual SPEC file. SPEC files are stored in the CVS repository. I can't do a valid review without the spec file. If you don't want it in Extras and are just looking for input about your SPEC file please list that in this bug somewhere. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 13 21:15:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 16:15:11 -0500 Subject: [Bug 177401] Review Request: clamsmtp - SMTP filter for ClamAV In-Reply-To: Message-ID: <200602132115.k1DLFBst005268@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: clamsmtp - SMTP filter for ClamAV https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177401 imlinux at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |imlinux at gmail.com ------- Additional Comments From imlinux at gmail.com 2006-02-13 16:14 EST ------- you should post the SPEC and SRPM every comment when possible. Also increment the revision number every time you post. Also, postun should require /sbin/service not /sbin/chkconfig -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 13 21:26:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 16:26:48 -0500 Subject: [Bug 178932] Review Request: AutoScan - A utility for network exploration In-Reply-To: Message-ID: <200602132126.k1DLQmlV007406@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: AutoScan - A utility for network exploration https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178932 imlinux at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |imlinux at gmail.com ------- Additional Comments From imlinux at gmail.com 2006-02-13 16:26 EST ------- -Don't use %define name and %define version. Just define them under Name: and Version: -Provide a working full URL for the Source: file -Increment the revision number every time you submit a change (even to bugzilla) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From orion at cora.nwra.com Mon Feb 13 21:41:54 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 13 Feb 2006 14:41:54 -0700 Subject: buildsys borked Message-ID: <43F0FD22.1090908@cora.nwra.com> /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core-232af5a95657e78af4f25bff8b40194b70084066/root groupinstall build Failed to add groups file for repository: core http://buildsys.fedoraproject.org/plague-results/fedora-development-extras/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. Error: failure: repodata/filelists.xml.gz from local: [Errno 256] No more mirrors to try. Cleaning up... Done. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From orion at cora.nwra.com Mon Feb 13 21:45:45 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 13 Feb 2006 14:45:45 -0700 Subject: buildsys borked In-Reply-To: <43F0FD22.1090908@cora.nwra.com> References: <43F0FD22.1090908@cora.nwra.com> Message-ID: <43F0FE09.7020406@cora.nwra.com> Orion Poplawski wrote: > /usr/sbin/mock-helper yum --installroot > /var/lib/mock/fedora-development-i386-core-232af5a95657e78af4f25bff8b40194b70084066/root > groupinstall build > Failed to add groups file for repository: core > http://buildsys.fedoraproject.org/plague-results/fedora-development-extras/repodata/filelists.xml.gz: > [Errno -1] Metadata file does not match checksum > Trying other mirror. > Error: failure: repodata/filelists.xml.gz from local: [Errno 256] No > more mirrors to try. > Cleaning up... > Done. > More info: - Just got three of these from different arches. - The jobs still seem to be running on other arches even though one failed. Will they be retried on the failed ones? It used to kill the whole job.... -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From rc040203 at freenet.de Mon Feb 13 22:02:27 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 13 Feb 2006 23:02:27 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <20060213195503.776b3aee.bugs.michael@gmx.net> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> Message-ID: <1139868147.12023.233.camel@mccallum.corsepiu.local> On Mon, 2006-02-13 at 19:55 +0100, Michael Schwendt wrote: > On Mon, 13 Feb 2006 18:22:42 +0100, Thorsten Leemhuis wrote: > > > Do all packages need a rebuild? > > > > Yes. > > No. > > > Most noarch packages probably would work fine without a rebuild and > > won't have a benefit from the new gcc security features. But we know > > that some noarch package are broken due to changes in rawhide -- we'd > > like to catch and fix those. And we want to make sure that a package > > still has a active maintainer while at it. > > It's still short-sighted, since This whole undertaking is short-sighted. Anything but a dep-ordered built will result into similar disorder as we have now. Also, FESCO, why aren't you able to launch such are mass rebuild yourself in at least "manually, semi-sorted" order like RH seems to be doing it? This at least would avoid the uncoordinated confusion we will be facing now. IMO, this step of yours is irresponsible. Embarrassed, Ralf From nicolas.mailhot at laposte.net Mon Feb 13 22:16:06 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 13 Feb 2006 23:16:06 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139854532.2904.83.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1139854532.2904.83.camel@localhost.localdomain> Message-ID: <1139868966.7241.0.camel@rousalka.dyndns.org> buildsys is already dead : Package foo enqueued. (However, no Job ID was provided in the time required) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From bugzilla at redhat.com Mon Feb 13 22:14:45 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 17:14:45 -0500 Subject: [Bug 174325] Review Request: mod_spin Apache module In-Reply-To: Message-ID: <200602132214.k1DMEj3c017095@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mod_spin Apache module https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174325 ------- Additional Comments From bojan at rexursive.com 2006-02-13 17:14 EST ------- OK. I'll make a new release and then I'll submit the new spec file. Sorry about the misunderstanding :-( -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From lists at timj.co.uk Mon Feb 13 22:35:50 2006 From: lists at timj.co.uk (Tim Jackson) Date: Mon, 13 Feb 2006 22:35:50 +0000 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <20060213195503.776b3aee.bugs.michael@gmx.net> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> Message-ID: <43F109C6.5090109@timj.co.uk> Michael Schwendt wrote: > 2) There are exceptions. Noarch packages which really don't need a rebuild. > Either it does or it doesn't. If it doesn't, the rebuild/update is not > needed. A trivial and perhaps atypical example would be my package php-pear-DB, which I only built on Saturday. I don't mind at all rebuilding it if that is the agreed procedure, but it *really* doesn't need it. Tim From bugzilla at redhat.com Mon Feb 13 23:27:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 18:27:08 -0500 Subject: [Bug 171597] Review Request: spandsp - A DSP library for telephony In-Reply-To: Message-ID: <200602132327.k1DNR8r6029257@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: spandsp - A DSP library for telephony https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171597 ------- Additional Comments From gauret at free.fr 2006-02-13 18:27 EST ------- Well, I wanted to try asterisk anyway. I guess it's the perfect occasion -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From oliver at linux-kernel.at Mon Feb 13 23:43:32 2006 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 14 Feb 2006 00:43:32 +0100 Subject: [Fwd: Build Error (Job 4112): libstatgrab-0_12-1_fc5 on fedora-development-extras] Message-ID: <43F119A4.8010503@linux-kernel.at> Hi! Can someone help me with this? I have no x86_64 machine at hand at the moment and therfor cannot diag this very well... :-( Maybe not building with smp_mflags!? Thanks, -of -------- Original Message -------- Subject: Build Error (Job 4112): libstatgrab-0_12-1_fc5 on fedora-development-extras Date: Mon, 13 Feb 2006 11:43:10 -0500 (EST) From: buildsys at fedoraproject.org To: oliver at linux-kernel.at Job failed on arch x86_64 Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/4112-libstatgrab-0.12-1.fc5/ ------------------------------------------------- then mv -f ".deps/user_list.Tpo" ".deps/user_list.Po"; else rm -f ".deps/user_list.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -I../src -I../src -I../src/libstatgrab -I../src/libstatgrab -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -MT page_stats.o -MD -MP -MF ".deps/page_stats.Tpo" -c -o page_stats.o page_stats.c; \ then mv -f ".deps/page_stats.Tpo" ".deps/page_stats.Po"; else rm -f ".deps/page_stats.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -I../src -I../src -I../src/libstatgrab -I../src/libstatgrab -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -MT network_iface_stats.o -MD -MP -MF ".deps/network_iface_stats.Tpo" -c -o network_iface_stats.o network_iface_stats.c; \ then mv -f ".deps/network_iface_stats.Tpo" ".deps/network_iface_stats.Po"; else rm -f ".deps/network_iface_stats.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -I../src -I../src -I../src/libstatgrab -I../src/libstatgrab -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -MT process_snapshot.o -MD -MP -MF ".deps/process_snapshot.Tpo" -c -o process_snapshot.o process_snapshot.c; \ then mv -f ".deps/process_snapshot.Tpo" ".deps/process_snapshot.Po"; else rm -f ".deps/process_snapshot.Tpo"; exit 1; fi /bin/sh ../libtool --tag=CC --mode=link gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o network_traffic network_traffic.o ../src/libstatgrab/libstatgrab.la /bin/sh ../libtool --tag=CC --mode=link gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o disk_traffic disk_traffic.o ../src/libstatgrab/libstatgrab.la mkdir .libs gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o .libs/network_traffic network_traffic.o ../src/libstatgrab/.libs/libstatgrab.so -Wl,--rpath -Wl,/usr/lib64 creating network_traffic gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o .libs/disk_traffic disk_traffic.o ../src/libstatgrab/.libs/libstatgrab.so -Wl,--rpath -Wl,/usr/lib64 creating disk_traffic /bin/sh ../libtool --tag=CC --mode=link gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o cpu_usage cpu_usage.o ../src/libstatgrab/libstatgrab.la /bin/sh ../libtool --tag=CC --mode=link gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o load_stats load_stats.o ../src/libstatgrab/libstatgrab.la libtool: link: `../src/libstatgrab/libstatgrab.la' is not a valid libtool archive make[2]: *** [load_stats] Error 1 make[2]: *** Waiting for unfinished jobs.... gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o .libs/cpu_usage cpu_usage.o ../src/libstatgrab/.libs/libstatgrab.so -Wl,--rpath -Wl,/usr/lib64 creating cpu_usage make[2]: Leaving directory `/builddir/build/BUILD/libstatgrab-0.12/examples' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/builddir/build/BUILD/libstatgrab-0.12' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.97371 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.97371 (%build) From steve at silug.org Mon Feb 13 23:53:13 2006 From: steve at silug.org (Steven Pritchard) Date: Mon, 13 Feb 2006 17:53:13 -0600 Subject: [Fwd: Build Error (Job 4112): libstatgrab-0_12-1_fc5 on fedora-development-extras] In-Reply-To: <43F119A4.8010503@linux-kernel.at> References: <43F119A4.8010503@linux-kernel.at> Message-ID: <20060213235313.GA23216@osiris.silug.org> On Tue, Feb 14, 2006 at 12:43:32AM +0100, Oliver Falk wrote: > libtool: link: `../src/libstatgrab/libstatgrab.la' is not a valid > libtool archive I got that *exact* same error on a build last week. The thing builds fine here under mock. http://buildsys.fedoraproject.org/logs/fedora-development-extras/3811-cone-0.66.20060203-1.fc5/ Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From oliver at linux-kernel.at Tue Feb 14 00:02:19 2006 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 14 Feb 2006 01:02:19 +0100 Subject: [Fwd: Build Error (Job 4112): libstatgrab-0_12-1_fc5 on fedora-development-extras] In-Reply-To: <20060213235313.GA23216@osiris.silug.org> References: <43F119A4.8010503@linux-kernel.at> <20060213235313.GA23216@osiris.silug.org> Message-ID: <43F11E0B.4030906@linux-kernel.at> Steven Pritchard wrote: > On Tue, Feb 14, 2006 at 12:43:32AM +0100, Oliver Falk wrote: >> libtool: link: `../src/libstatgrab/libstatgrab.la' is not a valid >> libtool archive > > I got that *exact* same error on a build last week. The thing builds > fine here under mock. > > http://buildsys.fedoraproject.org/logs/fedora-development-extras/3811-cone-0.66.20060203-1.fc5/ I also received quite the same error for graphviz... Both (libstatgrab and graphviz) build fine on my local smp-i686 machine... -of From bugzilla at redhat.com Tue Feb 14 00:12:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 19:12:16 -0500 Subject: [Bug 170303] Review Request: google-perftools: Very fast malloc & performance analysis tools In-Reply-To: Message-ID: <200602140012.k1E0CG0f002392@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: google-perftools: Very fast malloc & performance analysis tools https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170303 ------- Additional Comments From csilvers2000 at yahoo.com 2006-02-13 19:12 EST ------- We've been doing some checking here, and it appears the problem has to do with kernel skew. The heap-checker code, in particular, has to do some pretty hacky stuff to deal with thread-local storage, etc -- implementations that change slightly from kernel to kernel. We're looking at fixing the code so it works with the kernels in FC3/4/5, but it may take a little while. craig -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 14 02:14:23 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 13 Feb 2006 21:14:23 -0500 Subject: [Bug 181404] Review Request: emacs-muse In-Reply-To: Message-ID: <200602140214.k1E2ENvK017558@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 ------- Additional Comments From ndbecker2 at verizon.net 2006-02-13 21:14 EST ------- How about xemacs? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From paul at cypherpunks.ca Tue Feb 14 04:18:07 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Tue, 14 Feb 2006 05:18:07 +0100 (CET) Subject: source file "already there" but "not found" ? Was: Prep Error (Job 3879)fetchlog-1_0-4_fc5 on fedora-development-extras Message-ID: I am getting the followinng build error, after adding a patchfile to this package: Error: could not make srpm for fetchlog-1_0-4_fc5 - output was: Downloading fetchlog-build.patch... --19:42:44-- http://cvs.fedora.redhat.com/repo/extras/fetchlog/fetchlog-build.patch/99228569b122b994b1ab83148a3bd261/fetchlog-build.patch => `fetchlog-build.patch' Resolving cvs.fedora.redhat.com... 209.132.176.51 Connecting to cvs.fedora.redhat.com|209.132.176.51|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 339 [text/plain] 0K 100% 24.87 MB/s 19:42:44 (24.87 MB/s) - `fetchlog-build.patch' saved [339/339] FINISHED --19:42:44-- Downloaded: 339 bytes in 1 files -rw-rw-rw- 1 root root 339 Feb 6 14:59 fetchlog-build.patch rpmbuild --define "_sourcedir /tmp/3879-fetchlog-1_0-4_fc5-1139445759/fetchlog/devel" --define "_builddir /tmp/3879-fetchlog-1_0-4_fc5-1139445759/fetchlog/devel" --define "_srcrpmdir /tmp/3879-fetchlog-1_0-4_fc5-1139445759/fetchlog/devel" --define "_rpmdir /tmp/3879-fetchlog-1_0-4_fc5-1139445759/fetchlog/devel" --define "dist .fc5" --define "fedora 5" --nodeps -bs fetchlog.spec error: File /tmp/3879-fetchlog-1_0-4_fc5-1139445759/fetchlog/devel/fetchlog-1.0.tar.gz: No such file or directory make: *** [srpm] Error 1 I am not sure why fetchlog-1.0.tar.gz vanished, since it did not change between releases. And the system things it is still there: [paul at bofh devel]$ make new-sources "FILES=/usr/src/redhat/SOURCES/fetchlog-1.0.tar.gz " Checking : fetchlog-1.0.tar.gz on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... This file (e2ef0a076d1901c489c953fe48e1b2a9 fetchlog-1.0.tar.gz) is already uploaded Source upload succeeded. Don't forget to commit the new ./sources file For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs M sources M .cvsignore And apart from that, I'm not getting jobid numbers from the buildsystem anymore, and have a package stalled on needsign. Cheers, Paul From fedora at leemhuis.info Tue Feb 14 05:47:47 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 14 Feb 2006 06:47:47 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139868147.12023.233.camel@mccallum.corsepiu.local> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139868147.12023.233.camel@mccallum.corsepiu.local> Message-ID: <1139896067.19586.7.camel@thl.ct.heise.de> Am Montag, den 13.02.2006, 23:02 +0100 schrieb Ralf Corsepius: > On Mon, 2006-02-13 at 19:55 +0100, Michael Schwendt wrote: > > On Mon, 13 Feb 2006 18:22:42 +0100, Thorsten Leemhuis wrote: > > > Most noarch packages probably would work fine without a rebuild and > > > won't have a benefit from the new gcc security features. But we know > > > that some noarch package are broken due to changes in rawhide -- we'd > > > like to catch and fix those. And we want to make sure that a package > > > still has a active maintainer while at it. > > It's still short-sighted, since > This whole undertaking is short-sighted. Anything but a dep-ordered > built will result into similar disorder as we have now. Well, I also think a build in dep-order would be better. But nobody showed up with a *concrete* plan how to do it -- there were only rough ideas but nobody worked out the details in time. And before we don't do a mass build I prefer that we do it this way. > Also, FESCO, why aren't you able to launch such are mass rebuild > yourself Most people attending to the meetings suggested a "rebuild-by-maintainer" solution. That was done then. > in at least "manually, semi-sorted" order like RH seems to be > doing it? [...] RH uses a the alphabetical order by the package name afaik -- I don't see any benefit from that ;-) CU thl From fedora at leemhuis.info Tue Feb 14 06:20:18 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 14 Feb 2006 07:20:18 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <20060213195503.776b3aee.bugs.michael@gmx.net> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> Message-ID: <1139898018.19586.40.camel@thl.ct.heise.de> Michael, thx for you comments. Am Montag, den 13.02.2006, 19:55 +0100 schrieb Michael Schwendt: > On Mon, 13 Feb 2006 18:22:42 +0100, Thorsten Leemhuis wrote: > > > Do all packages need a rebuild? > > Yes. > No. Well, we discussed the mass rebuild in at least tree meetings. The rebuild "all" or "only parts" was not explicit discussed, but from what I saw on the lists and in the meetings it seemed to me that a "rebuild everything" solution was what most people wanted. We can revisit that next Thursday if you want. > > Most noarch packages probably would work fine without a rebuild and > > won't have a benefit from the new gcc security features. But we know > > that some noarch package are broken due to changes in rawhide -- we'd > > like to catch and fix those. And we want to make sure that a package > > still has a active maintainer while at it. > > It's still short-sighted, since > > 1) A forced rebuild, just to check whether a package still builds, is > something that can be done by the maintainer _locally_ using mock or with > FC5 Test 3. You forget that we have some packagers that live in parts of the world where internet bandwidth is costly. I suspect that each rebuild for devel with mock will download 300 - 750 MByte. To much for those packagers afaics. And even if that wasn't a problem -- how do we make sure that people really tried if a package still builds? > 2) There are exceptions. Noarch packages which really don't need a rebuild. > Either it does or it doesn't. If it doesn't, the rebuild/update is not > needed. Maybe -- but where is the problem with rebuild? Yeah, packagers have to invest a bit of time to increase the Release, add a changelog entry and request build. But other that that is mostly machine time that is spend. > > What happens with packages where no one stepped up to rebuild them? > > > > Ehhh, we didn't talk about that to much yet. Maybe we'll file bugs after > > the rebuild flood goes back and ask the package-maintainer to rebuild > > his or her package(s). Or we simply rebuild them and ignore the > > maintainer -- but in that case we can't be sure that the maintainer is > > still active in Fedora Extras. > > We can't be sure of that anyway, because who checks whether more than > a rebuild would make sense? E.g. new upstream releases not been applied > prior to a rebuild done by the maintainer. We should rely a bit more on > the user community who helps with reporting packages which are out-of-date > or broken. I'd really like to see each maintainer doing some work now and then just to make sure that he is still active in FE and alive. And we have a lot of not that important packages in the tree now, some of them are rarely updated upstream (take tiobench for example). We might never notice if that package is orphaned if we always do a script-mass-rebuild... > > What happens with the old packages build before February the 13th 2006? > > > > They'll probably be removed from the repo before FE5 goes live. > > Veto. Just to make sure: this part belongs under the "Ehhh, we didn't talk about that to much yet." -- this wasn't obvious (there was only the "probably" in the sentence"), sorry for that. > Removing broken orphans can cause enough poor dep breakage already > during a Yum upgrade. So let's keep the number of removed packages low. Mind > you, a broken installed package is not excluded from a transaction check, > so anything that's installed already but missing in the repository is bad > (as it won't be upgraded with something working and will cause the upgrade > to fail). If you remove more than what is known to be broken, this increases > the risk of breaking even further, at least for some users. > > We may remove what's broken and track it on the FC5Status page in the > Wiki just as we did for FE4 and older. Well, let's see how this whole thing works out. But what I'd really like to remove before we publish FE5 are old packages from the tree when a successor is there. E.g. when both foo-1.2.FC4 and foo-1.3.FC5 are in the FE5 tree remove foo-1.2.FC4. That okay for everybody? CU thl From bugzilla at redhat.com Tue Feb 14 06:24:24 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 01:24:24 -0500 Subject: [Bug 177583] Review Request: zaptel-kmod In-Reply-To: Message-ID: <200602140624.k1E6OO2b023465@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: zaptel-kmod https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177583 ------- Additional Comments From rh_bugzilla at puzzled.xs4all.nl 2006-02-14 01:24 EST ------- Regarding comment #9 there is a patch I have used and tested courtesy of dwmw2. It works fine for me. I'll attach it -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 14 06:30:24 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 01:30:24 -0500 Subject: [Bug 181444] New: Review Request: lcov -- process gcov output into nice html pages Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181444 Summary: Review Request: lcov -- process gcov output into nice html pages Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: roland at redhat.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://people.redhat.com/roland/tmp/lcov.spec SRPM Name or Url: http://people.redhat.com/roland/tmp/lcov-1.4-1.src.rpm Description: LCOV is an extension of GCOV, a GNU tool which provides information about what parts of a program are actually executed (i.e. "covered") while running a particular test case. The extension consists of a set of PERL scripts which build on the textual GCOV output to implement HTML output and support for large projects. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 14 06:40:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 01:40:18 -0500 Subject: [Bug 178922] Review Request: asterisk - The Open Source PBX In-Reply-To: Message-ID: <200602140640.k1E6eIjC026413@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: asterisk - The Open Source PBX https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178922 ------- Additional Comments From rh_bugzilla at puzzled.xs4all.nl 2006-02-14 01:40 EST ------- A simple solution for the %config(noreplace) issue that I have used over the years is simply putting the samples in /etc/asterisk-samples-%{version}. Having run Asterisk in a production environment at a Telco I prefer rpm _not_ to touch my Asterisk config files ever. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From buildsys at fedoraproject.org Tue Feb 14 06:58:58 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 14 Feb 2006 01:58:58 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060214065858.562AF8011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 2 git-1.2.0-1.fc3 python-durus-3.2-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue Feb 14 06:59:03 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 14 Feb 2006 01:59:03 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060214065903.1BBCE8011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 3 git-1.2.0-1.fc4 python-durus-3.2-1.fc4 shorewall-3.0.5-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue Feb 14 06:59:31 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 14 Feb 2006 01:59:31 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060214065931.3831C8011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 39 SDL_ttf-2.0.7-4.fc5 atlas-3.6.0-10.fc5 autotrace-0.31.1-12.fc5 clearsilver-0.10.2-3.fc5 compface-1.4-6.fc5 foremost-1.1-1.1.20060128.fc5 freehdl-0.0.1-2.fc5 ghex-2.8.1-4.fc5 git-1.2.0-1.fc5 glunarclock-0.32.4-5.fc5 gnome-blog-0.8-12.fc5 gossip-0.9-9.fc5 gramps-2.0.9-5.fc5 gsynaptics-0.9.5-2.fc5 gweled-0.7-4.fc5 gwget-0.97-2.fc5 highlight-2.4.3-2.fc5 inadyn-1.96-2.fc5 ipython-0.7.1.fix1-2.fc5 kanatest-0.3.6-4.fc5 kyum-0.7.5-2.fc5 loudmouth-1.0.1-5.fc5 mail-notification-2.0-11.fc5 meld-1.1.3-3.fc5 nautilus-image-converter-0.0.5-3.fc5 pdftk-1.12-6.fc5 python-durus-3.2-1.fc5 python-protocols-0.9.3-7.fc5 python-psyco-1.5-4.fc5 python-quixote-2.4-2.fc5 python-simpletal-4.1-2.fc5 python-tpg-3.0.6-2.fc5 qof-0.6.1-2.fc5 qtparted-0.4.5-4.fc5 shorewall-3.0.5-1.fc5 suck-4.3.2-12.fc5 tagtool-0.12.2-3.fc5 trac-0.9.3-5.fc5 xchat-gnome-0.9-5.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Tue Feb 14 06:58:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 01:58:07 -0500 Subject: [Bug 181445] New: Review Request: php-shout Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181445 Summary: Review Request: php-shout Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: bwh34 at msstate.edu QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://prdownloads.sourceforge.net/phpshout/php-shout.spec?download SRPM Name or Url: http://prdownloads.sourceforge.net/phpshout/php-shout-0.1.3-1.src.rpm?download Description: php-shout is a PHP extension that wraps the libshout library. Libshout is used to collect and stream audio data to an Icecast Streaming Media server. php-shout allows PHP developers to use native libshout functions from within their PHP scripts. This will ultimately allow developers to write PHP-powered web jukebox applications for the storage and on-demand streaming of their personal music libraries. While writing these applications, php-shout allows developers to concentrate on a richer set of features, without the need to worry about the details of the Icecast server communication. NOTE: php-shout was designed to work with libshout 2.x (2.0 was released Jul 2003), but Fedora Extras currently contains libshout-devel-1.0.9. Development ceased on Libshout 1.x in Apr 2002, and has been deprecated in favor of libshout 2.x. I have contacted the maintainer of libshout-devel about upgrading to libshout-2.2, but have not received a response. The inclusion of php-shout WILL require an updated version of libshout-devel :-/ If the package has been orphaned, I will gladly adopt it, and update it (pending community approval). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From dcbw at redhat.com Tue Feb 14 07:33:18 2006 From: dcbw at redhat.com (Dan Williams) Date: Tue, 14 Feb 2006 02:33:18 -0500 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139868966.7241.0.camel@rousalka.dyndns.org> References: <1139851362.2904.79.camel@localhost.localdomain> <1139854532.2904.83.camel@localhost.localdomain> <1139868966.7241.0.camel@rousalka.dyndns.org> Message-ID: <1139902398.3523.12.camel@localhost.localdomain> On Mon, 2006-02-13 at 23:16 +0100, Nicolas Mailhot wrote: > buildsys is already dead : > > Package foo enqueued. (However, no Job ID was provided in the time > required) Been kicked, packages that made it into the db are restarted. Dan From rc040203 at freenet.de Tue Feb 14 07:55:07 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 14 Feb 2006 08:55:07 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139896067.19586.7.camel@thl.ct.heise.de> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139868147.12023.233.camel@mccallum.corsepiu.local> <1139896067.19586.7.camel@thl.ct.heise.de> Message-ID: <1139903708.12023.325.camel@mccallum.corsepiu.local> On Tue, 2006-02-14 at 06:47 +0100, Thorsten Leemhuis wrote: > Am Montag, den 13.02.2006, 23:02 +0100 schrieb Ralf Corsepius: > > On Mon, 2006-02-13 at 19:55 +0100, Michael Schwendt wrote: > > > On Mon, 13 Feb 2006 18:22:42 +0100, Thorsten Leemhuis wrote: > > > > Most noarch packages probably would work fine without a rebuild and > > > > won't have a benefit from the new gcc security features. But we know > > > > that some noarch package are broken due to changes in rawhide -- we'd > > > > like to catch and fix those. And we want to make sure that a package > > > > still has a active maintainer while at it. > > > It's still short-sighted, since > > This whole undertaking is short-sighted. Anything but a dep-ordered > > built will result into similar disorder as we have now. > > Well, I also think a build in dep-order would be better. But nobody > showed up with a *concrete* plan how to do it Sorry, but as YOU are keen on a mass rebuilt, you should have thought about this issue before. - Apparently you didn't do your job. Also think about "apt-get sources", rsp. "apt-get build-deps". May-be you know understand why src.rpm repositories are useful and why yum lacks a key-feature that apt had provided. > -- there were only rough > ideas but nobody worked out the details in time. > > And before we don't do a mass build I prefer that we do it this way. > > > Also, FESCO, why aren't you able to launch such are mass rebuild > > yourself > > Most people attending to the meetings suggested a > "rebuild-by-maintainer" solution. That was done then. I guess, my opinion on FESCO's competence and qualification is no secret. > > in at least "manually, semi-sorted" order like RH seems to be > > doing it? [...] > > RH uses a the alphabetical order by the package name afaik -- I don't > see any benefit from that ;-) Well, I didn't expect anything else .. Inter-package deps, inter-maintainer deps, version deps, hidden API deps etc. The main difference between RH and you is: They launched a mass rebuild, coordinated by one central instance, which in the end results into a weakly bubble-strap'ed distribution ("bubble sorted bootstrap"). Though this also is basically sense-free actionism, it at least is doable, because broken interpackage deps won't be blocked by inter-maintainer deps and can be handled by a central instance. Ralf From bugzilla at redhat.com Tue Feb 14 07:52:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 02:52:35 -0500 Subject: [Bug 179510] Review Request: Nautilus-Flac-Converter In-Reply-To: Message-ID: <200602140752.k1E7qZZQ003052@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Nautilus-Flac-Converter https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179510 adrian at lisas.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |adrian at lisas.de OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From adrian at lisas.de 2006-02-14 02:52 EST ------- * builds in mock * source matches upstream * spec looks good * clean installation and removal * works as expected * rpmlint is happy APPROVED it was necessary to restart nautilus to get this plugin working. is this how it is supposed to be? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From sundaram at fedoraproject.org Tue Feb 14 08:01:43 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 14 Feb 2006 13:31:43 +0530 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139903708.12023.325.camel@mccallum.corsepiu.local> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139868147.12023.233.camel@mccallum.corsepiu.local> <1139896067.19586.7.camel@thl.ct.heise.de> <1139903708.12023.325.camel@mccallum.corsepiu.local> Message-ID: <43F18E67.1090808@fedoraproject.org> Hi >Also think about "apt-get sources", rsp. "apt-get build-deps". May-be >you know understand why src.rpm repositories are useful and why yum >lacks a key-feature that apt had provided. > > Might want to look at yum-builddep which is part of yum-utils. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From fedora at camperquake.de Tue Feb 14 08:58:27 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 14 Feb 2006 09:58:27 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139898018.19586.40.camel@thl.ct.heise.de> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> Message-ID: <20060214095827.3823801d@dhcp05.addix.net> Hi. On Tue, 14 Feb 2006 07:20:18 +0100, Thorsten Leemhuis wrote: > You forget that we have some packagers that live in parts of the world > where internet bandwidth is costly. I suspect that each rebuild for > devel with mock will download 300 - 750 MByte. To much for those > packagers afaics. In this light it is obviously better to upgrade each and every package to make everyone download everything again, right? Personally I do not mind rebuilding or downloading, but the bandwidth argument does not really fly here. From fedora at leemhuis.info Tue Feb 14 09:13:35 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 14 Feb 2006 10:13:35 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <20060214095827.3823801d@dhcp05.addix.net> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214095827.3823801d@dhcp05.addix.net> Message-ID: <1139908415.19586.82.camel@thl.ct.heise.de> Am Dienstag, den 14.02.2006, 09:58 +0100 schrieb Ralf Ertzinger: > Hi. > > On Tue, 14 Feb 2006 07:20:18 +0100, Thorsten Leemhuis wrote: > > > You forget that we have some packagers that live in parts of the world > > where internet bandwidth is costly. I suspect that each rebuild for > > devel with mock will download 300 - 750 MByte. To much for those > > packagers afaics. > > In this light it is obviously better to upgrade each and every package > to make everyone download everything again, right? > > Personally I do not mind rebuilding or downloading, but the bandwidth > argument does not really fly here. I IMHO does -- if you use Fedora Extras development you have to use rawhide. And those that use rawhide know that they'll have to download a lot of stuff frequently anyway. The three mass-rebuild and the frequent updates there probably create a lot more traffic for the users than the one mass rebuild in extras. CU thl From bugzilla at redhat.com Tue Feb 14 09:35:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 04:35:48 -0500 Subject: [Bug 181450] New: Review Request: clamav-exim - Clam AV support files for Exim Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181450 Summary: Review Request: clamav-exim - Clam AV support files for Exim Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: rpm at timj.co.uk QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.timj.co.uk/linux/specs/clamav-exim.spec SRPM Name or Url: http://www.timj.co.uk/linux/srpms/clamav-exim-1.0-1.src.rpm Description: clamav-exim contains the support files for clamav-server that allow it to be used easily with Exim. This is a direct fork of the clamav-exim changes that were committed by dwmw2 to the main clamav package at CVS rev 1.28 but later reverted by the clamav maintainer with the note that they should be split into a separate package. See CVS log: http://cvs.fedora.redhat.com/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=clamav.spec&branch=&root=/cvs/extras&subdir=/rpms/clamav/devel&command=DIFF_FRAMESET&rev1=1.27&rev2=1.28 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From nicolas.mailhot at laposte.net Tue Feb 14 09:43:55 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 14 Feb 2006 10:43:55 +0100 (CET) Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139902398.3523.12.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1139854532.2904.83.camel@localhost.localdomain> <1139868966.7241.0.camel@rousalka.dyndns.org> <1139902398.3523.12.camel@localhost.localdomain> Message-ID: <14648.192.54.193.25.1139910235.squirrel@rousalka.dyndns.org> Le Mar 14 f?vrier 2006 08:33, Dan Williams a ?crit : > On Mon, 2006-02-13 at 23:16 +0100, Nicolas Mailhot wrote: >> buildsys is already dead : >> >> Package foo enqueued. (However, no Job ID was provided in the time >> required) > > Been kicked, packages that made it into the db are restarted. Thanks a lot (that's one reason BTW why IMHO it would better if the mass rebuild was controled by someone able to kick the system at need *and* limit the number of in-flight packages to something the buildsys can handle) Regards, -- Nicolas Mailhot From bugs.michael at gmx.net Tue Feb 14 11:43:13 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 14 Feb 2006 12:43:13 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139898018.19586.40.camel@thl.ct.heise.de> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> Message-ID: <20060214124313.765c0ca5.bugs.michael@gmx.net> On Tue, 14 Feb 2006 07:20:18 +0100, Thorsten Leemhuis wrote: > > 1) A forced rebuild, just to check whether a package still builds, is > > something that can be done by the maintainer _locally_ using mock or with > > FC5 Test 3. > > You forget that we have some packagers that live in parts of the world > where internet bandwidth is costly. I suspect that each rebuild for > devel with mock will download 300 - 750 MByte. To much for those > packagers afaics. That's just another exception. As is a package which doesn't need a rebuild. A packager who's not running Rawhide--or at least one late test release--cannot test the binaries at all prior to FC5 being published. That would be an unfortunate situation. That even bears the risk of publishing binaries which don't work but which upgrade older still-working binaries, and--in case upstream development help is needed--which will remain broken until a fix is ready. We want package maintainers, who keep their stuff working. We don't want packaging slaves who rebuild because they are told to rebuild. There are packages in the repository which are not orphaned, which have been rebuilt, but which don't work or which hardly work well. The information we are seeking is: What changes in Core/GCC/ABI/BuildRequirements/DepChains _require_ a rebuild of a package in Extras? For instance, if I'm told that the updated compiler gives significant performance improvements or adds more security features or reduces the risks of miscompilation this would be reason to rebuild my binaries although everything seems to work fine in current Rawhide. Or if I see that some of the build requirements I depend on have changed, I'm interested in how this might affect my own packages at build-time and at run-time. So, to decide when something needs a rebuild, I need to monitor dependencies. Similarly, before I perform an upgrade to one of my packages, I need to watch and test carefully whether anybody else might be affected by the upgrade in bad ways. That's the whole big show that's supposed to just work within Fedora Extras all the time. API/ABI breakage, e.g. It is mandatory that I perform local test-builds of packages which depend on my packages. Where not possible due to lack of bandwidth, more coordination is necessary among the package maintainers. I cannot simply commit my upgrade and then be confronted with the wreckage. > And even if that wasn't a problem -- how do we make sure that people > really tried if a package still builds? Do we care? I'm mainly interested in whether a binary package _works_ in the form we offer it in the repository. It doesn't interest me much, whether the src.rpm might be out-of-date and may need adjustments for broken BR dep chains (like modular X's). Either the maintainer will notice prior to next upgrade or a user will report it. If neither happens, do we care? There are packages in the repository which nobody other than the packager seems to use. As much as I'm opposed to "rebuild for every dist just to keep spec files in sync" I'm opposed to unnecessary rebuilds in general. So, again and again: Either a package hasn't been built for some time and would benefit from a rebuild with the new GCC. Or there are reasons why it doesn't need a rebuild, and in that case the time it was built doesn't matter at all. > > 2) There are exceptions. Noarch packages which really don't need a rebuild. > > Either it does or it doesn't. If it doesn't, the rebuild/update is not > > needed. > > Maybe -- but where is the problem with rebuild? Yeah, packagers have to > invest a bit of time to increase the Release, add a changelog entry and > request build. But other that that is mostly machine time that is spend. Again, why rebuild stuff that doesn't need a rebuild? > And we have a lot of not that important packages in the tree now, some > of them are rarely updated upstream (take tiobench for example). We > might never notice if that package is orphaned if we always do a > script-mass-rebuild... Yes, a scripted mass-rebuild introduces a false sense of activity. Who skims over the build logs to watch out for failed configure tests which leave out components? Who makes sure the binaries still work? My experience with the last mass-rebuild is bad, btw, since some packagers performed major version upgrades shortly after the rebuilds had been done. > > We may remove what's broken and track it on the FC5Status page in the > > Wiki just as we did for FE4 and older. > > Well, let's see how this whole thing works out. But what I'd really like > to remove before we publish FE5 are old packages from the tree when a > successor is there. E.g. when both foo-1.2.FC4 and foo-1.3.FC5 are in > the FE5 tree remove foo-1.2.FC4. That okay for everybody? A normal yum update/upgrade only sees the latest one anyway. From bugs.michael at gmx.net Tue Feb 14 11:50:05 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 14 Feb 2006 12:50:05 +0100 Subject: source file "already there" but "not found" ? Was: Prep Error (Job 3879)fetchlog-1_0-4_fc5 on fedora-development-extras In-Reply-To: References: Message-ID: <20060214125005.23461785.bugs.michael@gmx.net> On Tue, 14 Feb 2006 05:18:07 +0100 (CET), Paul Wouters wrote: > > I am getting the followinng build error, after adding a patchfile to this package: > > Error: could not make srpm for fetchlog-1_0-4_fc5 - output was: > > Downloading fetchlog-build.patch... > --19:42:44-- http://cvs.fedora.redhat.com/repo/extras/fetchlog/fetchlog-build.patch/99228569b122b994b1ab83148a3bd261/fetchlog-build.patch > => `fetchlog-build.patch' > Resolving cvs.fedora.redhat.com... 209.132.176.51 > Connecting to cvs.fedora.redhat.com|209.132.176.51|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 339 [text/plain] > 0K 100% 24.87 MB/s > 19:42:44 (24.87 MB/s) - `fetchlog-build.patch' saved [339/339] > FINISHED --19:42:44-- > Downloaded: 339 bytes in 1 files > -rw-rw-rw- 1 root root 339 Feb 6 14:59 fetchlog-build.patch > rpmbuild --define "_sourcedir /tmp/3879-fetchlog-1_0-4_fc5-1139445759/fetchlog/devel" --define "_builddir /tmp/3879-fetchlog-1_0-4_fc5-1139445759/fetchlog/devel" --define "_srcrpmdir /tmp/3879-fetchlog-1_0-4_fc5-1139445759/fetchlog/devel" --define "_rpmdir /tmp/3879-fetchlog-1_0-4_fc5-1139445759/fetchlog/devel" --define "dist .fc5" --define "fedora 5" --nodeps -bs fetchlog.spec > error: File /tmp/3879-fetchlog-1_0-4_fc5-1139445759/fetchlog/devel/fetchlog-1.0.tar.gz: No such file or directory > make: *** [srpm] Error 1 > > I am not sure why fetchlog-1.0.tar.gz vanished, since it did not change between releases. And > the system things it is still there: > > [paul at bofh devel]$ make new-sources "FILES=/usr/src/redhat/SOURCES/fetchlog-1.0.tar.gz " > > Checking : fetchlog-1.0.tar.gz on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... > This file (e2ef0a076d1901c489c953fe48e1b2a9 fetchlog-1.0.tar.gz) is already uploaded > > Source upload succeeded. Don't forget to commit the new ./sources file > For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs > M sources > M .cvsignore The lookaside cache mechanism also takes into account the file's MD5 checksum when retrieving a file. So make sure your local "sources" file is up-to-date and correct. Currently it is marked as 'M' (modified), so possibly contains a wrong checksum. Check out a fresh copy, try again. "make srpm" for fetchlog-1.0-4.fc5 works here. From fedora at camperquake.de Tue Feb 14 12:27:53 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 14 Feb 2006 13:27:53 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <20060214124313.765c0ca5.bugs.michael@gmx.net> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214124313.765c0ca5.bugs.michael@gmx.net> Message-ID: <20060214132753.3b9338b4@dhcp05.addix.net> Hi. On Tue, 14 Feb 2006 12:43:13 +0100, Michael Schwendt wrote: > Again, why rebuild stuff that doesn't need a rebuild? In general, I agree. But, seeing the rationale for rebuilding the whole of Core (twice) during the last week(s), namely "changes in the ppc ABI", at least all the non-noarch-packages ought to be rebuild. Do I have binary packages in Extras? Yes, I do. Do I know if they use some obscure double long instructions? No way. From nicolas.mailhot at laposte.net Tue Feb 14 12:29:06 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 14 Feb 2006 13:29:06 +0100 (CET) Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <20060214124313.765c0ca5.bugs.michael@gmx.net> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214124313.765c0ca5.bugs.michael@gmx.net> Message-ID: <24083.192.54.193.25.1139920146.squirrel@rousalka.dyndns.org> Le Mar 14 f?vrier 2006 12:43, Michael Schwendt a ?crit : > On Tue, 14 Feb 2006 07:20:18 +0100, Thorsten Leemhuis wrote: > >> > 1) A forced rebuild, just to check whether a package still builds, is >> > something that can be done by the maintainer _locally_ using mock or >> with >> > FC5 Test 3. >> >> You forget that we have some packagers that live in parts of the world >> where internet bandwidth is costly. I suspect that each rebuild for >> devel with mock will download 300 - 750 MByte. To much for those >> packagers afaics. > > That's just another exception. As is a package which doesn't need a > rebuild. > > A packager who's not running Rawhide--or at least one late test > release--cannot test the binaries at all prior to FC5 being > published. That would be an unfortunate situation. That even bears the > risk of publishing binaries which don't work but which upgrade older > still-working binaries, and--in case upstream development help is > needed--which will remain broken until a fix is ready. So what ? Do you think the situation is any different for packagers which run rawhide but have no access to FCn and FCn-1 ? Or i386 packagers which have no access to x86_64 or ppc systems ? At one point you have to release packages and bet that if they work on your system they'll work on the others FE is built for. The only working rule given our ressources is : - package must work on the packager system - packager must allocate time to fix the systems he didn't test after pushing a new build if someone reports a problem in the following week Even forgetting about the FE Legacy problems, full testing right now would soon mean test on devel-x86_64, devel-ppc, devel-i386, FC5-x86_64, FC5-ppc, FC5-i386, FC4-x86_64, FC4-ppc, FC4-i386 Anyone advocating full testing is welcome to ask for SRPMs of my packages a week before I push them and test them himself. Because I'll never test them on anything other than devel-x86_64. I don't have the hardware or time to do full testing. And the vast majority of packagers are in the same situation. Community process means the community does stuff. Including testing packages. You don't like it you can pay RHEL for Red Hat to do this testing for you. Regards, -- Nicolas Mailhot From rc040203 at freenet.de Tue Feb 14 13:51:17 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 14 Feb 2006 14:51:17 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <20060214124313.765c0ca5.bugs.michael@gmx.net> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214124313.765c0ca5.bugs.michael@gmx.net> Message-ID: <1139925078.12023.366.camel@mccallum.corsepiu.local> On Tue, 2006-02-14 at 12:43 +0100, Michael Schwendt wrote: > On Tue, 14 Feb 2006 07:20:18 +0100, Thorsten Leemhuis wrote: > > > > 1) A forced rebuild, just to check whether a package still builds, is > > > something that can be done by the maintainer _locally_ using mock or with > > > FC5 Test 3. > > > > You forget that we have some packagers that live in parts of the world > > where internet bandwidth is costly. I suspect that each rebuild for > > devel with mock will download 300 - 750 MByte. To much for those > > packagers afaics. > > That's just another exception. As is a package which doesn't need a > rebuild. > > A packager who's not running Rawhide--or at least one late test > release--cannot test the binaries at all prior to FC5 being > published. Let me pull you this tooth - In the vast majority of all cases, you don't need a particular OS/version of an OS to test whether a package is functional, because most packages' functionality is independent of any OS. Therefore testing update/upgrade-packages on such similar OSes (e.g FC4 vs. FC5) will be enough in many cases. Also you can't expect to a package that is known to work on one architecture to work on others, and require all maintainers to test them on all architectures - That would be irrational nonsense. > There are > packages in the repository which are not orphaned, which have been > rebuilt, but which don't work or which hardly work well. File bugs to bugzilla, that's what bugzilla is for and what rawhide/development is for: Testing SW and identifying bugs! > The information > we are seeking is: What changes in Core/GCC/ABI/BuildRequirements/DepChains > _require_ a rebuild of a package in Extras? Such cases require a rebuild. They should be detected automatically and should be triggered automatically. If this isn't possible, this has to be done manually by a centralized instance, either an individual or "rebuild task force". > For instance, if I'm told that > the updated compiler gives significant performance improvements or adds > more security features or reduces the risks of miscompilation this > would be reason to rebuild my binaries although everything seems to work > fine in current Rawhide. This would not justify a mass rebuild because this doesn't qualify a package as non-functional. A gradual rebuild would be sufficient. > Or if I see that some of the build requirements > I depend on have changed, I'm interested in how this might affect my own > packages at build-time and at run-time. This would qualify as a packaging bug, should be bugzilla'ed and be addressed by normal bugfixing > So, to decide when something needs > a rebuild, I need to monitor dependencies. Right, more aggressively: changing deps should trigger rebuilds. > Similarly, before I perform an > upgrade to one of my packages, I need to watch and test carefully whether > anybody else might be affected by the upgrade in bad ways. That's the > whole big show that's supposed to just work within Fedora Extras all the > time. API/ABI breakage, e.g. It is mandatory that I perform local > test-builds of packages which depend on my packages. Not necessarily. If a packages ABI/API don't change upon upgrades/updates, there should not be any need to rebuild a package. > Where not possible > due to lack of bandwidth, more coordination is necessary among the package > maintainers. I cannot simply commit my upgrade and then be confronted with > the wreckage. But that's what FESCO currently is doing: You are producing wreckage. > > And even if that wasn't a problem -- how do we make sure that people > > really tried if a package still builds? > > Do we care? I'm mainly interested in whether a binary package _works_ Exactly. As long as a package can be correctly installed and seems to work, there is no need for immediate action. If it can't be rebuild, ... bugzilla ... > > And we have a lot of not that important packages in the tree now, some > > of them are rarely updated upstream (take tiobench for example). We > > might never notice if that package is orphaned if we always do a > > script-mass-rebuild... > > Yes, a scripted mass-rebuild introduces a false sense of activity. Who > skims over the build logs to watch out for failed configure tests which > leave out components? Who makes sure the binaries still work? My > experience with the last mass-rebuild is bad, Nevertheless it had been much better than what is being tried now. > btw, since some packagers > performed major version upgrades shortly after the rebuilds had been done. Packagers perform major upgrades when they "happen". In some cases it's a random point in time, in some cases it's the mass rebuild co-incing with "last minute" updates. It has happened and it will happen again, you can't prevent it, and I don't see any reason why one would want to prevent it. > > > We may remove what's broken and track it on the FC5Status page in the > > > Wiki just as we did for FE4 and older. > > > > Well, let's see how this whole thing works out. But what I'd really like > > to remove before we publish FE5 are old packages from the tree when a > > successor is there. E.g. when both foo-1.2.FC4 and foo-1.3.FC5 are in > > the FE5 tree remove foo-1.2.FC4. That okay for everybody? > > A normal yum update/upgrade only sees the latest one anyway. Partial mirroring sees the older version - This renders using local mirrors of devel over a low bandwidth connection tedious. Ralf From bugzilla at redhat.com Tue Feb 14 13:51:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 08:51:15 -0500 Subject: [Bug 179510] Review Request: Nautilus-Flac-Converter In-Reply-To: Message-ID: <200602141351.k1EDpFiu030090@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Nautilus-Flac-Converter https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179510 ------- Additional Comments From bdpepple at ameritech.net 2006-02-14 08:51 EST ------- (In reply to comment #2) > APPROVED > > it was necessary to restart nautilus to get this plugin working. is this how it > is supposed to be? Yes, this is the same as other nautilus extensions (nautilus-sendto, nautilus-open-terminal, etc.) Adrian, thanks for the review. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 14 14:03:12 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 09:03:12 -0500 Subject: [Bug 181404] Review Request: emacs-muse In-Reply-To: Message-ID: <200602141403.k1EE3C52031965@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 ------- Additional Comments From jonathan.underwood at gmail.com 2006-02-14 09:03 EST ------- Fedora Core does not contain xemacs, though it is available from extras. Other packages, eg. auctex, do not support xemacs. I don't have any interest in supporting it really -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 14 14:31:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 09:31:34 -0500 Subject: [Bug 177583] Review Request: zaptel-kmod In-Reply-To: Message-ID: <200602141431.k1EEVYRp005874@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: zaptel-kmod https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177583 ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-14 09:31 EST ------- I've modified the patch a little bit so that it will work on any kernel whether it's set for 1000Hz or 250Hz. That way I don't have to add a bunch of %ifarch sections to the spec file. I've attached the patch but I haven't tested it out yet. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugs.michael at gmx.net Tue Feb 14 15:00:16 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 14 Feb 2006 16:00:16 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139925078.12023.366.camel@mccallum.corsepiu.local> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214124313.765c0ca5.bugs.michael@gmx.net> <1139925078.12023.366.camel@mccallum.corsepiu.local> Message-ID: <20060214160016.728239dd.bugs.michael@gmx.net> On Tue, 14 Feb 2006 14:51:17 +0100, Ralf Corsepius wrote: > > A packager who's not running Rawhide--or at least one late test > > release--cannot test the binaries at all prior to FC5 being > > published. > Let me pull you this tooth - In the vast majority of all cases, you > don't need a particular OS/version of an OS to test whether a package is > functional, because most packages' functionality is independent of any > OS. Therefore testing update/upgrade-packages on such similar OSes (e.g > FC4 vs. FC5) will be enough in many cases. > > Also you can't expect to a package that is known to work on one > architecture to work on others, and require all maintainers to test them > on all architectures - That would be irrational nonsense. This is all poor theory. In reality, build requirements on FC(n-1) don't suffice. And packagers cannot do any run-time testing at all, not for a single arch either. If you want to discuss quality of high-level language code, which works on one arch, but breaks on another, this is off-topic. Of course I do hope that code, which works on packager's primary arch, also builds and works on different archs. But this is just a _hope_. I'm aware that some "coders" do lots of ugly things in high-level programming languages, even things which are doomed to fail on other archs. > > > And we have a lot of not that important packages in the tree now, some > > > of them are rarely updated upstream (take tiobench for example). We > > > might never notice if that package is orphaned if we always do a > > > script-mass-rebuild... > > > > Yes, a scripted mass-rebuild introduces a false sense of activity. Who > > skims over the build logs to watch out for failed configure tests which > > leave out components? Who makes sure the binaries still work? My > > experience with the last mass-rebuild is bad, > > Nevertheless it had been much better than what is being tried now. Maybe you've got that false impression, because this time a) the responsibility to trigger rebuilds is yours, b) you have not been hit by orphans, which rebuilt successfully, but are broken nevertheless, c) packages, which would not build prior to an upstream upgrade, so package maintainer needed to work on the package anyway, and d) packages with open bug reports, where the packager just neglected packaging work till FC(n+1) was close enough. > > btw, since some packagers > > performed major version upgrades shortly after the rebuilds had been done. > Packagers perform major upgrades when they "happen". > > In some cases it's a random point in time, in some cases it's the mass > rebuild co-incing with "last minute" updates. It has happened and it > will happen again, you can't prevent it, and I don't see any reason why > one would want to prevent it. Once more, this is poor theory. This is not about prevention, but about wasted efforts and lack of coordination. Package maintainers need to learn about their dependencies within Extras/Core and coordinate required rebuilds with eachother. What I see is the following: A signal has been sent. It's time to prepare for Fedora Extras 5. It's packager's responsibility to update/upgrade where necessary. And since we still do a rolling release, packagers rebuild when they're ready and when their BR are ready. And it's them who receive build logs and build failure reports directly and may peruse them for mistakes. It's also them who decide when to ship another version upgrade, possibly with GCC fixes or things like that. Why care about any package that may be broken _today_ when the packager _will_ fix it _in time_? Why perform a rebuild attempt today when possibly a week later upstream releases a new version which would build? Why interfere with packager's way of keeping a package in shape? From rc040203 at freenet.de Tue Feb 14 16:16:44 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 14 Feb 2006 17:16:44 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <20060214160016.728239dd.bugs.michael@gmx.net> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214124313.765c0ca5.bugs.michael@gmx.net> <1139925078.12023.366.camel@mccallum.corsepiu.local> <20060214160016.728239dd.bugs.michael@gmx.net> Message-ID: <1139933804.12023.407.camel@mccallum.corsepiu.local> On Tue, 2006-02-14 at 16:00 +0100, Michael Schwendt wrote: > On Tue, 14 Feb 2006 14:51:17 +0100, Ralf Corsepius wrote: > > Nevertheless it had been much better than what is being tried now. > > Maybe you've got that false impression, False? What didn't work out in the end? Also, the effective situation is not any different from that with FC4, fedora.us etc.. The only real difference is "maintainers have access to the build system". > > > btw, since some packagers > > > performed major version upgrades shortly after the rebuilds had been done. > > Packagers perform major upgrades when they "happen". > > > > In some cases it's a random point in time, in some cases it's the mass > > rebuild co-incing with "last minute" updates. It has happened and it > > will happen again, you can't prevent it, and I don't see any reason why > > one would want to prevent it. > > Once more, this is poor theory. Do you think so? From my experience, "last minute changes/updates" are the number one cause of most severe bugs. > This is not about prevention, but about > wasted efforts and lack of coordination. The mass rebuild is wasted effort, and trying to let it be performed by maintainers IS ineffective and uncoordinated. > Package maintainers need to learn > about their dependencies within Extras/Core and coordinate required > rebuilds with eachother. I would not be opposed to this, if the infrastructure was in place - it is not. > What I see is the following: > > A signal has been sent. It's time to prepare for Fedora Extras 5. It's > packager's responsibility to update/upgrade where necessary. Note the last word of your sentence !!!! This is a completely different message than that being communicated by FIASCO. I see it as follows: Some people don't seem to have understood the difference between bootstrapping a distro from scratch and incrementally building a distro. FE has been built incrementally without having the appropriate infrastructure/QA in place. Now some people try to "clean up the mess" by shooting with the proverbial canon at the proverbial sparrows" (German proverb). In the end you will be facing a similar mess as before, some things will be have been ironed out but new ones will be introduced, because the appropriate infrastructure still is not available. Ralf From jspaleta at gmail.com Tue Feb 14 16:25:40 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 14 Feb 2006 11:25:40 -0500 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139933804.12023.407.camel@mccallum.corsepiu.local> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214124313.765c0ca5.bugs.michael@gmx.net> <1139925078.12023.366.camel@mccallum.corsepiu.local> <20060214160016.728239dd.bugs.michael@gmx.net> <1139933804.12023.407.camel@mccallum.corsepiu.local> Message-ID: <604aa7910602140825i50884cbfi201bb2df29246d69@mail.gmail.com> On 2/14/06, Ralf Corsepius wrote: > > Package maintainers need to learn > > about their dependencies within Extras/Core and coordinate required > > rebuilds with eachother. > I would not be opposed to this, if the infrastructure was in place - it > is not. the repoquery isn't enough to provide the necessary information to learn about dependancy chains to allow for maintainer coordination? What exactly do you feel is needed in terms of infrastructure with regard to dependancy discovery? -jef From toshio at tiki-lounge.com Tue Feb 14 16:40:58 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 14 Feb 2006 08:40:58 -0800 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <20060214095827.3823801d@dhcp05.addix.net> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214095827.3823801d@dhcp05.addix.net> Message-ID: <1139935258.3330.9.camel@localhost> On Tue, 2006-02-14 at 09:58 +0100, Ralf Ertzinger wrote: > Hi. > > On Tue, 14 Feb 2006 07:20:18 +0100, Thorsten Leemhuis wrote: > > > You forget that we have some packagers that live in parts of the world > > where internet bandwidth is costly. I suspect that each rebuild for > > devel with mock will download 300 - 750 MByte. To much for those > > packagers afaics. > > In this light it is obviously better to upgrade each and every package > to make everyone download everything again, right? > > Personally I do not mind rebuilding or downloading, but the bandwidth > argument does not really fly here. > The majority of the download (for a mock rebuild) will be from within Core which we don't have any control over (and, it seems, is the reason for the rebuild anyway.) Only a few (if any) inter-dependencies within Extras for any given package. So, if the Extras packages are going to be rebuilt (to use the new Core features), then I think there is a tremendous bandwidth savings to be had in this sort of rebuild vs each packager using mock. -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 rc040203 at freenet.de Tue Feb 14 17:03:55 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 14 Feb 2006 18:03:55 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <604aa7910602140825i50884cbfi201bb2df29246d69@mail.gmail.com> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214124313.765c0ca5.bugs.michael@gmx.net> <1139925078.12023.366.camel@mccallum.corsepiu.local> <20060214160016.728239dd.bugs.michael@gmx.net> <1139933804.12023.407.camel@mccallum.corsepiu.local> <604aa7910602140825i50884cbfi201bb2df29246d69@mail.gmail.com> Message-ID: <1139936636.30045.25.camel@mccallum.corsepiu.local> On Tue, 2006-02-14 at 11:25 -0500, Jeff Spaleta wrote: > On 2/14/06, Ralf Corsepius wrote: > > > Package maintainers need to learn > > > about their dependencies within Extras/Core and coordinate required > > > rebuilds with eachother. > > I would not be opposed to this, if the infrastructure was in place - it > > is not. > > the repoquery isn't enough to provide the necessary information to > learn about dependancy chains to allow for maintainer coordination? No. [Personal side-note: I hate repoquery. It's way less useable than its apt-get counterparts] > What exactly do you feel is needed in terms of infrastructure with > regard to dependancy discovery? Some issues: * How to check if packages are subject of ABI changes? I don't know. * How to check if updates/upgrades break APIs? I don't know. * Repo inconsistencies can be silent: E.g. changes to perl/python vendor dirs - They are invisible to repoquery. * Why are packages which obviously _break_ deps pushed into the repos, instead of being hold back? (IMO, a must for FE < rawhide) * Buildsystem issues: There is no means to withdraw a package from a repo, should run time issues with an update/upgraded package in devel show up. * Lack of automation: Why isn't repoquery and other repo checks run periodically at a centralized site to issue automated alerts? * There doesn't exist a package dep tracking system which would allow packagers who know they are going to break other packages, to notify other packagers (E.g. to allow maintainers to notify maintainers of packages using these packages on certain issues). I could continue this list with nitpicks, ... IMO, most of these issues would be non-issues, if an extended build system would exist which automatically recompiles all packages when on of its build time deps changes. Admitted, this would be a very radical approach, but I think it is feasible for FCN+1, if it is automated. Ralf From bugzilla at redhat.com Tue Feb 14 17:43:04 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 12:43:04 -0500 Subject: [Bug 181404] Review Request: emacs-muse In-Reply-To: Message-ID: <200602141743.k1EHh4MV019718@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 ------- Additional Comments From jonathan.underwood at gmail.com 2006-02-14 12:43 EST ------- Once this package is in FE, I will create a sister xemacs-muse package if it is felt necessary. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From jspaleta at gmail.com Tue Feb 14 18:31:20 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 14 Feb 2006 13:31:20 -0500 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139936636.30045.25.camel@mccallum.corsepiu.local> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214124313.765c0ca5.bugs.michael@gmx.net> <1139925078.12023.366.camel@mccallum.corsepiu.local> <20060214160016.728239dd.bugs.michael@gmx.net> <1139933804.12023.407.camel@mccallum.corsepiu.local> <604aa7910602140825i50884cbfi201bb2df29246d69@mail.gmail.com> <1139936636.30045.25.camel@mccallum.corsepiu.local> Message-ID: <604aa7910602141031v36483317v7b6f558d3950c32f@mail.gmail.com> On 2/14/06, Ralf Corsepius wrote: > I could continue this list with nitpicks, ... Just as long as everyone in the conversation realizes your are engaging in nitpicking instead of constructive discussion.. I'm fine with a full list. -jef From bugzilla at redhat.com Tue Feb 14 18:46:26 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 13:46:26 -0500 Subject: [Bug 175047] Review Request: NetworkManager-openvpn In-Reply-To: Message-ID: <200602141846.k1EIkQiw032201@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: NetworkManager-openvpn https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175047 ------- Additional Comments From bjohnson at symetrix.com 2006-02-14 13:46 EST ------- I built the rpm from the srpm noted in Comment #9 and installed. When I tried to start the vpn, the vpn was initiated and worked, but I got these messages in my /var/log/messages file: Feb 14 11:40:18 localhost nm-openvpn[2658]: TUN/TAP device tun0 opened Feb 14 11:40:18 localhost nm-openvpn[2658]: /sbin/ip link set dev tun0 up mtu 1500 Feb 14 11:40:18 localhost nm-openvpn[2658]: /sbin/ip addr add dev tun0 local 10.1.1.6 peer 10.1.1.5 Feb 14 11:40:18 localhost nm-openvpn[2658]: /usr/bin/nm-openvpn-service-openvpn-helper tun0 1500 1542 10.1.1.6 10.1.1.5 init Feb 14 11:40:18 localhost NetworkManager: get_dbus_guint32_helper (): Error: couldn't get IP4 VPN Local Netmask from VPN IP Config message. Feb 14 11:40:18 localhost NetworkManager: nm_vpn_service_stage4_ip_config_get (): nm_vpn_service_stage4_ip_config_get(org.freedesktop.NetworkManager.openvpn): did not receive valid IP config information. Even though you can see that the tun was assigned an address (and the remote network was reachable), NetworkManager thinks that it didn't receive valid IP4 information. Because of this, there is no status in NetworkManager that indicates I've connected to a vpn and the disconnect option is not available. I'm not sure if this is a problem with NetworkManager or NetworkManager-openvpn. dbus-0.60-7.2 NetworkManager-0.5.1-12.cvs20060213 I, for one, appreciate this package and would like to see it sponsored and moved forward. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From buildsys at fedoraproject.org Tue Feb 14 19:03:51 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 14 Feb 2006 14:03:51 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060214190351.D1FF68011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 1 git-1.2.0-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue Feb 14 19:04:32 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 14 Feb 2006 14:04:32 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060214190432.3C2CA8011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 4 git-1.2.0-1.fc4 gquilt-0.17-1.fc4 sblim-cmpi-base-1.5.4-3.fc4 stellarium-0.7.1-3.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue Feb 14 19:07:23 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 14 Feb 2006 14:07:23 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060214190723.697B68011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 116 OpenEXR-1.2.2-6.fc5 airsnort-0.2.7e-8.fc5 alltray-0.65-2.fc5 antiword-0.37-2 apcupsd-3.12.2-1.fc5 artwiz-aleczapka-fonts-1.3-4.fc5 atitvout-0.4-5 baobab-2.3.1-2.fc5 bubblemon-1.46-5.fc5 buoh-0.8.1-7 bwbar-1.2.2-4 cacti-0.8.6h-5 clearsilver-0.10.2-3.fc5 cln-1.1.11-5.fc5 dclib-0.3.7-6.fc5 dejavu-fonts-2.2-6.fc5 deskbar-applet-2.13.91-1.fc5 diction-1.08-1.2.fc5 dosbox-0.63-9.fc5 dynamite-0.1-4.fc5 ecore-0.9.9.023-2.fc5 edb-1.0.5.005-1.fc5 eet-0.9.10.023-2.fc5 enigma-0.92-3.fc5 evas-0.9.9.023-2.fc5 fbida-2.03-10.fc5 fftw-3.1-2.fc5 fltk-1.1.7-1.fc5 fluxconf-0.9.9-2.fc5 fnfx-0.3-6.fc5 fontforge-20060125-6.fc5 fonttools-2.0-0.5.20050624cvs.fc5 freeciv-2.0.7-5.fc5 freehdl-0.0.1-2.fc5 freeze-2.5.0-6.fc5 fyre-1.0.0-13.fc5 gajim-0.9.1-2.fc5 gdome2-0.8.1-3.fc5 ghasher-1.2.0-8.fc5 ghdl-0.22-0.38svn.1.fc5 gnet2-2.0.7-6.fc5 gnome-applet-rhythmbox-0.1.10-1.fc5 gparted-0.2-2.fc5 gpgme03-0.3.16-10.fc5 gquilt-0.17-1.fc5 grip-3.2.0-10.fc5 gtkglext-1.2.0-2.fc5 gtorrentviewer-0.2b-8.fc5 gtranslator-1.1.6-3.fc5 gv-3.6.1-7.fc5 hdf-4.2r1-9.fc5 htop-0.6-3.fc5 ibmonitor-1.3-3 jed-0.99.17-0.pre135.3 kdesvn-0.7.3-2.fc5 kdissert-1.0.5-1.1.fc5 koffice-1.4.90-3.fc5 konversation-0.19-2.fc5 krusader-1.70.0-1.fc5 ktrack-0.3.0-13.rc1.fc5 leafpad-0.8.7-2.fc5 libbinio-1.4-5.fc5 libid3tag-0.15.1b-2.fc5 libifp-1.0.0.2-2.fc5 libmodplug-0.7-5.fc5 libnjb-2.2.5-2.fc5 libosip-0.9.7-9.fc5 libosip2-2.2.2-2.fc5 libqalculate-0.9.2-2.fc5 libsexy-0.1.6-2.fc5 libtorrent-0.8.2-4.fc5 libxml++-2.12.0-2.1.fc5 liferea-1.0.4-3.fc5 linphone-1.2.0-4.fc5 lzop-1.02-0.2.fc5 mediawiki-1.5.6-6.fc5 mimetex-1.60-2.fc5 mod_auth_pam-1.1.1-4.fc5 mysql-administrator-1.1.6-2.fc5 nagios-2.0-0.5.rc2.fc5 nautilus-actions-1.0-2.fc5 nautilus-flac-converter-0.0.2-2.fc5 nautilus-search-tool-0.1-2.fc5 neXtaw-0.15.1-8.fc5 nomarch-1.3-5.fc5 notecase-1.1.4-2.fc5 numpy-0.9.4-2.fc5 ortp-0.8.1-2.fc5 pam_mysql-0.6.2-3.fc5 perl-Convert-UUlib-1.06-3.fc5 perl-Font-TTF-0.37-4.fc5 perl-Glib-1.105-2.fc5 perl-GnuPG-Interface-0.33-6.fc5 perl-Net-Server-0.90-2.fc5 php-json-1.1.1-1.fc5 python-amara-1.1.7-1.fc5 python-enchant-1.1.5-3.fc5 python-sqlite2-2.1.3-4.fc5 pytz-2005r-2.fc5 qalculate-gtk-0.9.2-2.fc5 qalculate-kde-0.9.2-2.fc5 qof-0.6.1-2.fc5 qps-1.9.11-2.2.fc5 qscintilla-1.6-3.2.fc5 rinetd-0.62-5.fc5 rtorrent-0.4.2-5.fc5 spicctrl-1.9-3.fc5 splint-3.1.1-12.fc5 t1lib-5.1.0-5.fc5 t1utils-1.32-6.fc5 texmaker-1.12-4.fc5 themes-backgrounds-gnome-0.4-4.fc5 ucl-1.03-5.fc5 wxGTK-2.6.2-5.fc5 yumex-0.99.8-1.0.fc5 zoo-2.10-5.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From thomas at apestaart.org Tue Feb 14 19:19:36 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Tue, 14 Feb 2006 20:19:36 +0100 Subject: gstreamer08 is dead; long live gstreamer In-Reply-To: <43F04110.3050002@redhat.com> References: <200602130747.k1D7lXGQ018834@porkchop.devel.redhat.com> <43F04110.3050002@redhat.com> Message-ID: <1139944776.4109.22.camel@otto> On Mon, 2006-02-13 at 03:19 -0500, Christopher Aillon wrote: > Just a note that all the dependencies of gstreamer08 are gone from Core, > and we will be removing gstreamer08 soon from Core. There is a package > or two in extras that depends on it still, so this is a heads up that > either it needs to be imported into Extras, or packages should be > updated to use gstreamer 0.10. Excellent news ! So, do people want a gstreamer08 in Extras ? If so, I of course wouldn't mind maintaining it. Let me know, Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> You take it in stride but still You fall as you're walking Big sky above me a river inside me and I'm Doubled up in love <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From bdpepple at ameritech.net Tue Feb 14 19:26:59 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Tue, 14 Feb 2006 14:26:59 -0500 Subject: gstreamer08 is dead; long live gstreamer In-Reply-To: <1139944776.4109.22.camel@otto> References: <200602130747.k1D7lXGQ018834@porkchop.devel.redhat.com> <43F04110.3050002@redhat.com> <1139944776.4109.22.camel@otto> Message-ID: <1139945219.17062.1.camel@shuttle.273piedmont.org> On Tue, 2006-02-14 at 20:19 +0100, Thomas Vander Stichele wrote: > So, do people want a gstreamer08 in Extras ? If so, I of course wouldn't > mind maintaining it. > Yeah, I'll need it for gnomebaker, since they haven't ported to 0.10 yet (and don't seem very motivated in doing so). /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 bugzilla at redhat.com Tue Feb 14 19:29:26 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 14:29:26 -0500 Subject: [Bug 180255] Review Request: nazghul - Old school RPG engine In-Reply-To: Message-ID: <200602141929.k1EJTQ92008679@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: nazghul - Old school RPG engine https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180255 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From tibbs at math.uh.edu 2006-02-14 14:29 EST ------- OK, after a bit of hacking I have a clean build on all three architectures. I also packaged some additional documentation including adding a users' guide to the haxima subpackage. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From jspaleta at gmail.com Tue Feb 14 19:43:27 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 14 Feb 2006 14:43:27 -0500 Subject: gstreamer08 is dead; long live gstreamer In-Reply-To: <1139944776.4109.22.camel@otto> References: <200602130747.k1D7lXGQ018834@porkchop.devel.redhat.com> <43F04110.3050002@redhat.com> <1139944776.4109.22.camel@otto> Message-ID: <604aa7910602141143o1c3ac1daw294da3d00e3c54c0@mail.gmail.com> On 2/14/06, Thomas Vander Stichele wrote: > So, do people want a gstreamer08 in Extras ? If so, I of course wouldn't > mind maintaining it. cough... you know istanbul needs it.. cough -jef From michael at knox.net.nz Tue Feb 14 19:54:38 2006 From: michael at knox.net.nz (Michael J Knox) Date: Wed, 15 Feb 2006 08:54:38 +1300 Subject: packaging suggestions. Message-ID: <1139946879.19452.15.camel@cosima.et.endace.com> I am attempting to package bro (bro-ids.org) and have a couple of questions. When bro is installed it installs its self into /usr, which is fine, but it also creates a bunch of directories like: /usr/archive /usr/logs /usr/policy /usr/reports /usr/scripts /usr/site /usr/var /usr/etc Now I am using the "%configure" macro. Are the any issues, reservations, conflicts of packaging policies that the above will create? Thanks Michael From bugzilla at redhat.com Tue Feb 14 19:54:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 14:54:08 -0500 Subject: [Bug 181445] Review Request: php-shout In-Reply-To: Message-ID: <200602141954.k1EJs8wn014841@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-shout https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181445 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-14 14:54 EST ------- I will suggest, that you file bugzilla with a regquest for updating libshout. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From ivazquez at ivazquez.net Tue Feb 14 20:05:41 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 14 Feb 2006 15:05:41 -0500 Subject: packaging suggestions. In-Reply-To: <1139946879.19452.15.camel@cosima.et.endace.com> References: <1139946879.19452.15.camel@cosima.et.endace.com> Message-ID: <1139947541.2539.24.camel@ignacio.lan> On Wed, 2006-02-15 at 08:54 +1300, Michael J Knox wrote: > I am attempting to package bro (bro-ids.org) and have a couple of > questions. > > When bro is installed it installs its self into /usr, which is fine, but > it also creates a bunch of directories like: > > /usr/archive > /usr/logs > /usr/policy > /usr/reports > /usr/scripts > /usr/site > /usr/var > /usr/etc > > Now I am using the "%configure" macro. > > Are the any issues, reservations, conflicts of packaging policies that > the above will create? I don't think I've ever seen the FHS so blatantly violated. Most of those things look like they should go under /usr/share/bro, with the exception of logs, var, and etc. And possibly reports. -- 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 Tue Feb 14 20:19:50 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 14 Feb 2006 22:19:50 +0200 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <604aa7910602140825i50884cbfi201bb2df29246d69@mail.gmail.com> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214124313.765c0ca5.bugs.michael@gmx.net> <1139925078.12023.366.camel@mccallum.corsepiu.local> <20060214160016.728239dd.bugs.michael@gmx.net> <1139933804.12023.407.camel@mccallum.corsepiu.local> <604aa7910602140825i50884cbfi201bb2df29246d69@mail.gmail.com> Message-ID: <1139948390.10711.7.camel@bobcat.mine.nu> On Tue, 2006-02-14 at 11:25 -0500, Jeff Spaleta wrote: > the repoquery isn't enough to provide the necessary information to > learn about dependancy chains to allow for maintainer coordination? It's too bad that at the time when repoquery would be most useful, it's shipped broken in FE5 :(. Pointers how to fix it locally are at https://bugzilla.redhat.com/175335 From nicolas.mailhot at laposte.net Tue Feb 14 20:20:36 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 14 Feb 2006 21:20:36 +0100 Subject: packaging suggestions. In-Reply-To: <1139946879.19452.15.camel@cosima.et.endace.com> References: <1139946879.19452.15.camel@cosima.et.endace.com> Message-ID: <1139948437.8933.2.camel@rousalka.dyndns.org> Le mercredi 15 f?vrier 2006 ? 08:54 +1300, Michael J Knox a ?crit : > I am attempting to package bro (bro-ids.org) and have a couple of > questions. > > When bro is installed it installs its self into /usr, which is fine, but > it also creates a bunch of directories like: > > /usr/archive > /usr/logs > /usr/policy > /usr/reports > /usr/scripts > /usr/site > /usr/var > /usr/etc > > Now I am using the "%configure" macro. > > Are the any issues, reservations, conflicts of packaging policies that > the above will create? You need to massage it so logs en up in /var/log, conf in /etc, generated bits in /var/something and so on. Time to read http://www.pathname.com/fhs/ again. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From johnp at redhat.com Tue Feb 14 20:21:20 2006 From: johnp at redhat.com (John (J5) Palmieri) Date: Tue, 14 Feb 2006 15:21:20 -0500 Subject: packaging suggestions. In-Reply-To: <1139947541.2539.24.camel@ignacio.lan> References: <1139946879.19452.15.camel@cosima.et.endace.com> <1139947541.2539.24.camel@ignacio.lan> Message-ID: <1139948480.30456.57.camel@remedyz.boston.redhat.com> On Tue, 2006-02-14 at 15:05 -0500, Ignacio Vazquez-Abrams wrote: > On Wed, 2006-02-15 at 08:54 +1300, Michael J Knox wrote: > > I am attempting to package bro (bro-ids.org) and have a couple of > > questions. > > > > When bro is installed it installs its self into /usr, which is fine, but > > it also creates a bunch of directories like: > > > > /usr/archive > > /usr/logs > > /usr/policy > > /usr/reports > > /usr/scripts > > /usr/site > > /usr/var > > /usr/etc > > > > Now I am using the "%configure" macro. > > > > Are the any issues, reservations, conflicts of packaging policies that > > the above will create? > > I don't think I've ever seen the FHS so blatantly violated. Most of > those things look like they should go under /usr/share/bro, with the > exception of logs, var, and etc. And possibly reports. Bro-ids has some seriously messed up Makefile.am files. Instead of using automake to determine directories they hardcode everything to ${prefix}/. I'm wondering if it even honors DESTDIR. They install a VERSION file into ${prefix}/etc. I haven't looked at the code but my guess is it hard codes the locations of its data files. I would say this all needs to be fixed to use the proper autotools macros before it can be packaged correctly. -- John (J5) Palmieri From bugzilla at redhat.com Tue Feb 14 20:16:25 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 15:16:25 -0500 Subject: [Bug 179904] Review Request: icecast In-Reply-To: Message-ID: <200602142016.k1EKGPnO020189@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: icecast https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179904 holbrookbw at users.sourceforge.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |holbrookbw at users.sourceforge | |.net ------- Additional Comments From holbrookbw at users.sourceforge.net 2006-02-14 15:16 EST ------- I have submitted a bug requesting libshout be updated in devel for FE5, bugID 181523. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181523 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From michael at knox.net.nz Tue Feb 14 20:23:15 2006 From: michael at knox.net.nz (Michael J Knox) Date: Wed, 15 Feb 2006 09:23:15 +1300 Subject: packaging suggestions. In-Reply-To: <1139948480.30456.57.camel@remedyz.boston.redhat.com> References: <1139946879.19452.15.camel@cosima.et.endace.com> <1139947541.2539.24.camel@ignacio.lan> <1139948480.30456.57.camel@remedyz.boston.redhat.com> Message-ID: <1139948600.19452.21.camel@cosima.et.endace.com> On Tue, 2006-02-14 at 15:21 -0500, John (J5) Palmieri wrote: > On Tue, 2006-02-14 at 15:05 -0500, Ignacio Vazquez-Abrams wrote: > > On Wed, 2006-02-15 at 08:54 +1300, Michael J Knox wrote: > > > I am attempting to package bro (bro-ids.org) and have a couple of > > > questions. > > > > > > When bro is installed it installs its self into /usr, which is fine, but > > > it also creates a bunch of directories like: > > > > > > /usr/archive > > > /usr/logs > > > /usr/policy > > > /usr/reports > > > /usr/scripts > > > /usr/site > > > /usr/var > > > /usr/etc > > > > > > Now I am using the "%configure" macro. > > > > > > Are the any issues, reservations, conflicts of packaging policies that > > > the above will create? > > > > I don't think I've ever seen the FHS so blatantly violated. Most of > > those things look like they should go under /usr/share/bro, with the > > exception of logs, var, and etc. And possibly reports. > > Bro-ids has some seriously messed up Makefile.am files. Instead of > using automake to determine directories they hardcode everything to > ${prefix}/. I'm wondering if it even honors DESTDIR. They install > a VERSION file into ${prefix}/etc. I haven't looked at the code but my > guess is it hard codes the locations of its data files. I would say > this all needs to be fixed to use the proper autotools macros before it > can be packaged correctly. Sounds like what I was thinking. Guess I will take a stab at it today, since work is rather quiet. Michael From orion at cora.nwra.com Tue Feb 14 20:39:43 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 14 Feb 2006 13:39:43 -0700 Subject: hammer1/2 not right Message-ID: <43F2400F.7010902@cora.nwra.com> Only appear to be building 1 job each: hammer1.fedora.redhat.com (2/2) x86_64, amd64, ia32e, noarch, i386, i486, i586, i686, athlon Job: 4329 (ginac/i386) Status: running/downloaded hammer2.fedora.redhat.com (2/2) i386, i486, i586, i686, athlon, noarch, x86_64, amd64, ia32e Job: 4329 (ginac/x86_64) Status: running/downloaded -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From jspaleta at gmail.com Tue Feb 14 20:30:05 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 14 Feb 2006 15:30:05 -0500 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139948390.10711.7.camel@bobcat.mine.nu> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214124313.765c0ca5.bugs.michael@gmx.net> <1139925078.12023.366.camel@mccallum.corsepiu.local> <20060214160016.728239dd.bugs.michael@gmx.net> <1139933804.12023.407.camel@mccallum.corsepiu.local> <604aa7910602140825i50884cbfi201bb2df29246d69@mail.gmail.com> <1139948390.10711.7.camel@bobcat.mine.nu> Message-ID: <604aa7910602141230k596a09c3u264e105d1e7c308a@mail.gmail.com> On 2/14/06, Ville Skytt? wrote: > It's too bad that at the time when repoquery would be most useful, it's > shipped broken in FE5 :(. Pointers how to fix it locally are at > https://bugzilla.redhat.com/175335 Sadly true, I've been doing repoquery --repoid=development --repoid=extras-development on an fc4 box as needed. Is mock working on a rawhide install again yet? I've been doing all my repoquery and mock work on an fc4 machine to avoid the complications associated with the move to yum 2.5.x when it entered rawhide. -jef From orion at cora.nwra.com Tue Feb 14 20:52:44 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 14 Feb 2006 13:52:44 -0700 Subject: [Fwd: Build Error (Job 4112): libstatgrab-0_12-1_fc5 on fedora-development-extras] In-Reply-To: <43F11E0B.4030906@linux-kernel.at> References: <43F119A4.8010503@linux-kernel.at> <20060213235313.GA23216@osiris.silug.org> <43F11E0B.4030906@linux-kernel.at> Message-ID: <43F2431C.3080302@cora.nwra.com> Oliver Falk wrote: > Steven Pritchard wrote: >> On Tue, Feb 14, 2006 at 12:43:32AM +0100, Oliver Falk wrote: >>> libtool: link: `../src/libstatgrab/libstatgrab.la' is not a valid >>> libtool archive >> >> I got that *exact* same error on a build last week. The thing builds >> fine here under mock. >> >> >> http://buildsys.fedoraproject.org/logs/fedora-development-extras/3811-cone-0.66.20060203-1.fc5/ >> > > I also received quite the same error for graphviz... Both (libstatgrab > and graphviz) build fine on my local smp-i686 machine... > Seems to have been temporary? My package was requeued and built successfully. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From bugzilla at redhat.com Tue Feb 14 20:49:03 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 15:49:03 -0500 Subject: [Bug 181534] New: Review Request: kst - plots scientific data Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181534 Summary: Review Request: kst - plots scientific data Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: matt at truch.net QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://matt.truch.net/fedora/kst.spec SRPM Name or Url: http://matt.truch.net/fedora/kst-1.2.0-1.src.rpm Description: Kst is a real-time data viewing and plotting tool with basic data analysis functionality. Kst contains many powerful built-in features and is expandable with plugins and extensions. Kst is a KDE application. Main features of kst include: * Robust plotting of live "streaming" data. * Powerful keyboard and mouse plot manipulation. * Powerful plugins and extensions support. * Large selection of built-in plotting and data manipulation functions, such as histograms, equations, and power spectra. * Color mapping and contour mapping capabilities for three-dimensional data. * Monitoring of events and notifications support. * Filtering and curve fitting capabilities. * Convenient command-line interface. * Powerful graphical user interface. * Support for several popular data formats. * Multiple tabs or windows. ------------------------------------------------ I've split kst up into kst, kst-docs, kst-devel, kst-fits, and kst-netcdf. I'm not sure if I should do more or less. Thanks in advance for the review! -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 14 21:50:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 16:50:16 -0500 Subject: [Bug 178310] Review Request: w3c-libwww - An HTTP library of common code In-Reply-To: Message-ID: <200602142150.k1ELoGPA011052@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: w3c-libwww - An HTTP library of common code https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178310 ------- Additional Comments From pertusus at free.fr 2006-02-14 16:50 EST ------- - rpmlint shows those warnings. Maybe the no-version-in-last-changelog could be acted upon? Can be done after commit. W: w3c-libwww invalid-license W3C (see: http://www.w3.org/Consortium/Legal/copyright-software.html) W: w3c-libwww no-version-in-last-changelog W: w3c-libwww-apps no-documentation W: w3c-libwww-devel no-documentation - name meets the guidelines - meets the packaging guidelines - a diff against a cvs checkout give no difference - everything looks good Previous version was allready checked by Ian Burrell. APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 14 22:15:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 17:15:50 -0500 Subject: [Bug 165932] Review Request: An SMTP Client In-Reply-To: Message-ID: <200602142215.k1EMFoc3015824@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: An SMTP Client https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165932 ------- Additional Comments From taylor at haleph.com 2006-02-14 17:15 EST ------- I'm not an Extras Contributor and thus cannot commit it, but anybody who has commit access is welcome to import it. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rc040203 at freenet.de Tue Feb 14 22:24:25 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 14 Feb 2006 23:24:25 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <604aa7910602141031v36483317v7b6f558d3950c32f@mail.gmail.com> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214124313.765c0ca5.bugs.michael@gmx.net> <1139925078.12023.366.camel@mccallum.corsepiu.local> <20060214160016.728239dd.bugs.michael@gmx.net> <1139933804.12023.407.camel@mccallum.corsepiu.local> <604aa7910602140825i50884cbfi201bb2df29246d69@mail.gmail.com> <1139936636.30045.25.camel@mccallum.corsepiu.local> <604aa7910602141031v36483317v7b6f558d3950c32f@mail.gmail.com> Message-ID: <1139955865.30045.29.camel@mccallum.corsepiu.local> On Tue, 2006-02-14 at 13:31 -0500, Jeff Spaleta wrote: > On 2/14/06, Ralf Corsepius wrote: > > I could continue this list with nitpicks, ... > Just as long as everyone in the conversation realizes your are > engaging in nitpicking instead of constructive discussion.. I'm fine > with a full list. PLONK From bugzilla at redhat.com Tue Feb 14 22:20:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 17:20:52 -0500 Subject: [Bug 165932] Review Request: An SMTP Client In-Reply-To: Message-ID: <200602142220.k1EMKq3w016820@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: An SMTP Client https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165932 sundaram at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sundaram at redhat.com ------- Additional Comments From sundaram at redhat.com 2006-02-14 17:20 EST ------- (In reply to comment #6) > I'm not an Extras Contributor and thus cannot commit it, but anybody who has > commit access is welcome to import it. You can become a contributor by going through the process outlined in http://fedoraproject.org/wiki/Extras. Since you submitted the package for review, this would be a good starting point. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 14 22:23:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 17:23:36 -0500 Subject: [Bug 165932] Review Request: An SMTP Client In-Reply-To: Message-ID: <200602142223.k1EMNaX1017618@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: An SMTP Client https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165932 ------- Additional Comments From jonathan.underwood at gmail.com 2006-02-14 17:23 EST ------- What does msmtp bring in terms of functionality that is not already supplied by esmtp (which uses libesmtp, and is available in extras)? Is it worth duplicating functionality? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 14 22:29:25 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 17:29:25 -0500 Subject: [Bug 165932] Review Request: An SMTP Client In-Reply-To: Message-ID: <200602142229.k1EMTPEg018583@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: An SMTP Client https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165932 ------- Additional Comments From jonathan.underwood at gmail.com 2006-02-14 17:29 EST ------- Also, it may be worth using the alternatives system to set this as the system mailer - see the esmtp spec for an example. But then again, given that neither msmtp and esmtp do local delivery, I wonder if this breaks things. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 14 22:32:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 17:32:30 -0500 Subject: [Bug 181369] Review Request: libedit - The NetBSD Editline library In-Reply-To: Message-ID: <200602142232.k1EMWUeq019373@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libedit - The NetBSD Editline library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181369 ------- Additional Comments From michael at knox.net.nz 2006-02-14 17:32 EST ------- I forgot to mention that this is my first package and that I am seeking a sponors. Thanks! -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 14 22:33:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 17:33:48 -0500 Subject: [Bug 165932] Review Request: An SMTP Client In-Reply-To: Message-ID: <200602142233.k1EMXmSO019782@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: An SMTP Client https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165932 ------- Additional Comments From ivazquez at ivazquez.net 2006-02-14 17:33 EST ------- (In reply to comment #8) > What does msmtp bring in terms of functionality that is not already supplied by > esmtp (which uses libesmtp, and is available in extras)? Is it worth duplicating > functionality? Duplicated functionality doesn't matter in Extras, only in Core. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 14 22:54:14 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 17:54:14 -0500 Subject: [Bug 178951] Review Request: environment-modules - Provides dynamic modification of a user's environment In-Reply-To: Message-ID: <200602142254.k1EMsEEv023379@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: environment-modules - Provides dynamic modification of a user's environment https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178951 orion at cora.nwra.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From orion at cora.nwra.com 2006-02-14 17:54 EST ------- - checked in - added to owners.list - builds on devel -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 15 00:33:39 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 19:33:39 -0500 Subject: [Bug 180068] Review Request: geoip - Library for mapping IP/hostname to a country/city/organization In-Reply-To: Message-ID: <200602150033.k1F0XdX1006196@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: geoip - Library for mapping IP/hostname to a country/city/organization https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180068 ------- Additional Comments From rc040203 at freenet.de 2006-02-14 19:33 EST ------- (In reply to comment #2) > (some warnings re: > the .so symlinks, but that's about all.) This is a blocker, please fix (lib*.so must go to *-devel, lib*.so.* to non-devel) Also arguable: Obsoletes: geoip Provides: geoip This should probably be: Obsoletes: geoip < %{version}-%{release} Provides: geoip = %{version}-%{release} Also missing in the *-devel package: Provides: geoip-devel = %{version}-%{release} Alternatively, you could consider to drop supporting "geoip". -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 15 00:48:04 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 19:48:04 -0500 Subject: [Bug 165932] Review Request: An SMTP Client In-Reply-To: Message-ID: <200602150048.k1F0m4xU008057@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: An SMTP Client https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165932 ------- Additional Comments From pertusus at free.fr 2006-02-14 19:48 EST ------- (In reply to comment #9) > Also, it may be worth using the alternatives system to set this as the system > mailer - see the esmtp spec for an example. > > But then again, given that neither msmtp and esmtp do local delivery, I wonder > if this breaks things. I do agree that using the alternative system may be a bad thing as there is no fallback (although I am the esmtp maintainer, so I did it for esmtp ;-), so I think that the choice to use or not to use the alternative system should be left to the packager. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 15 03:10:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 22:10:02 -0500 Subject: [Bug 181599] New: Review Request: gallery: web based photo album software Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 Summary: Review Request: gallery: web based photo album software Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: jwb at redhat.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.berningeronline.net/gallery.spec SRPM Name or Url: http://www.berningeronline.net/gallery-2.0.2-1.src.rpm Description: Customizable photo gallery web site This is a packaging of the gallery2-minimal tarball from http://gallery.menalto.com into an installable package for Fedora Extras. This is the first package I've done for Fedora, so I'll need a sponsor for this to go further. I made this package relocatable, as it is intended upstream to be installable to a ~/public_html directory as well as /var/www/html, although I won't complain if it needs to be made unrelocatable. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From smooge at gmail.com Wed Feb 15 04:12:17 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Tue, 14 Feb 2006 21:12:17 -0700 Subject: packaging suggestions. In-Reply-To: <1139946879.19452.15.camel@cosima.et.endace.com> References: <1139946879.19452.15.camel@cosima.et.endace.com> Message-ID: <80d7e4090602142012r3b224fd0kb7a1ddecf862b67@mail.gmail.com> On 2/14/06, Michael J Knox wrote: > I am attempting to package bro (bro-ids.org) and have a couple of > questions. > > When bro is installed it installs its self into /usr, which is fine, but > it also creates a bunch of directories like: > I did this a while back... BRO is built around a BSD flavor and expects these things to be there. It is very linux/SYS-V un-friendly.. I had to patch several things to get 0.9a8 to work, and then forced everything under /usr/lib/bro and /usr/share/bro. In some ways.. it might actually work better under the /svr/ tree (that is /svr/bro/ as the root). Looking at this old patched version. I had to make some changes to Bro that I sent upstream, and could not use the %configure but had to add some entries to make it do what it should and not what it wanted. If the /svr/bro tree is allowed in extras.. that would clean up most of the problems. Bro is a server/service. If it isnt.. expect to do a bunch of cleanup. I think that most of my patch doesnt work with the later versions due to offsets and such. -- Stephen J Smoogen. CSIRT/Linux System Administrator From bugzilla at redhat.com Wed Feb 15 04:32:54 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 14 Feb 2006 23:32:54 -0500 Subject: [Bug 180747] Review Request: powerman In-Reply-To: Message-ID: <200602150432.k1F4WsnY009854@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: powerman https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180747 ------- Additional Comments From woodard at redhat.com 2006-02-14 23:32 EST ------- Thank you for taking the time to review powerman's rpm. I fixed the things mentioned in your review. There is now a new src.rmp and a new spec file up there now. http://osdn.dl.sourceforge.net/sourceforge/powerman/powerman-1.0.22-3.src.rpm http://osdn.dl.sourceforge.net/sourceforge/powerman/powerman.spec I'm not yet sure that it will compile perfectly on FC4 and do not have a test machine available to test that this evening. I'm working with the upstream author to make sure that this will work and as soon as I can verify this. I'll update this ticket. In the mean time, will you please verify that the spec file is now done to your satisfaction. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From skvidal at linux.duke.edu Wed Feb 15 04:42:19 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 14 Feb 2006 23:42:19 -0500 Subject: packaging suggestions. In-Reply-To: <80d7e4090602142012r3b224fd0kb7a1ddecf862b67@mail.gmail.com> References: <1139946879.19452.15.camel@cosima.et.endace.com> <80d7e4090602142012r3b224fd0kb7a1ddecf862b67@mail.gmail.com> Message-ID: <1139978539.11728.5.camel@cutter> > Looking at this old patched version. I had to make some changes to Bro > that I sent upstream, and could not use the %configure but had to add > some entries to make it do what it should and not what it wanted. > > If the /svr/bro tree is allowed in extras.. that would clean up most > of the problems. Bro is a server/service. If it isnt.. expect to do a > bunch of cleanup. I think that most of my patch doesnt work with the > later versions due to offsets and such. > just for clarity - the fhs approved path is /srv/ - not /svr/ -sv From buildsys at fedoraproject.org Wed Feb 15 05:04:35 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 15 Feb 2006 00:04:35 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060215050435.A8D338011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 3 freehdl-0.0.1-2.fc3 krusader-1.70.0-1.fc3 qucs-0.0.8-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed Feb 15 05:05:33 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 15 Feb 2006 00:05:33 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060215050533.AB6938011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 7 apcupsd-3.12.2-1.fc4 freehdl-0.0.1-2.fc4 glpk-4.9-1.fc4 krusader-1.70.0-1.fc4 qucs-0.0.8-1.fc4 scorched3d-39.1-4.fc4 stellarium-0.7.1-5.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed Feb 15 05:15:37 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 15 Feb 2006 00:15:37 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060215051537.B95528011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 59 Glide3-libGL-6.2.1-5.fc5 Maelstrom-3.0.6-10 autossh-1.3-3.fc5 celestia-1.4.0.20060210cvs-1.fc5 cone-0.66.20060203-1.fc5 digikam-0.8.1-3.fc5 digikamimageplugins-0.8.0-2.fc5 drgeo-1.1.0-7.fc5 drgeo-doc-1.6-7.fc5 enca-1.9-2.fc5 enchant-1.2.2-2.fc5 environment-modules-3.2.0p1-1.fc5 fping-2.4b2-6.fc5 gai-temp-0.1.1-4.fc5 ginac-1.3.3-4.fc5 git-1.2.0-1.fc5 gkrellmms-2.1.22-5.fc5 gnomad2-2.8.2-2.fc5 gnome-applet-timer-1.2-3.fc5 gperiodic-2.0.8-4.fc5 gqview-2.0.1-3 gtk-gnutella-0.96-2.fc5 ircd-hybrid-7.2.0-6.fc5 kphone-4.2-8.fc5 libgda-1.9.100-4.fc5 libupnp-1.2.1a-6.fc5 lirc-0.8.0-3.fc5 meanwhile-1.0.2-2.fc5 mmv-1.01b-5.fc5 nazghul-0.5.3-4.fc5 net6-1.2.2-2.fc5 notemeister-0.1.7-8.fc5 openvpn-2.1-0.6.beta8.fc5 pcsc-lite-1.2.0-14.fc5 perl-GD-2.30-3.fc5 perl-IO-Tty-1.02-5.fc5 perl-XML-LibXSLT-1.58-2.fc5 pgp-tools-0.4.4-3.20060212svn.fc5 python-clientform-0.1.17-4.fc5 python-crypto-2.0.1-2.fc5 python-numarray-1.5.1-1.fc5 python-reportlab-1.20-5.fc5 qucs-0.0.8-1.fc5 regexxer-0.8-3.fc5 scorched3d-39.1-4.fc5 smb4k-0.6.7-2.fc5 snownews-1.5.7-4.fc5 srecord-1.23-2.fc5 stellarium-0.7.1-7.fc5 supertux-0.1.3-3.fc5 sylpheed-2.0.4-2.fc5 syslog-ng-1.6.9-3.fc5 tiobench-0.3.3-3.fc5 ushare-0.9.5-6.fc5 wesnoth-1.0.2-2.fc5 wp_tray-0.5.1-2.fc5 xmms-alarm-0.3.7-2.fc5 xmms-modplug-2.05-5.fc5 xscorch-0.2.0-7.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From smooge at gmail.com Wed Feb 15 05:25:04 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Tue, 14 Feb 2006 22:25:04 -0700 Subject: packaging suggestions. In-Reply-To: <1139978539.11728.5.camel@cutter> References: <1139946879.19452.15.camel@cosima.et.endace.com> <80d7e4090602142012r3b224fd0kb7a1ddecf862b67@mail.gmail.com> <1139978539.11728.5.camel@cutter> Message-ID: <80d7e4090602142125g57540631q4c04f6a7a4caf6e9@mail.gmail.com> On 2/14/06, seth vidal wrote: > > Looking at this old patched version. I had to make some changes to Bro > > that I sent upstream, and could not use the %configure but had to add > > some entries to make it do what it should and not what it wanted. > > > > If the /svr/bro tree is allowed in extras.. that would clean up most > > of the problems. Bro is a server/service. If it isnt.. expect to do a > > bunch of cleanup. I think that most of my patch doesnt work with the > > later versions due to offsets and such. > > > Talked to Seth on IRC, and /srv is also not the correct place for it either from the FHS.. The bro package is going to need a lot of little patches to match the FHS I think. -- Stephen J Smoogen. CSIRT/Linux System Administrator From michael at knox.net.nz Wed Feb 15 05:42:25 2006 From: michael at knox.net.nz (Michael J Knox) Date: Wed, 15 Feb 2006 18:42:25 +1300 (NZDT) Subject: packaging suggestions. In-Reply-To: <80d7e4090602142125g57540631q4c04f6a7a4caf6e9@mail.gmail.com> References: <1139946879.19452.15.camel@cosima.et.endace.com><80d7e4090602142012r3b224fd0kb7a1ddecf862b67@mail.gmail.com><1139978539.11728.5.camel@cutter> <80d7e4090602142125g57540631q4c04f6a7a4caf6e9@mail.gmail.com> Message-ID: <51112.219.89.109.32.1139982145.squirrel@www.knox.net.nz> Stephen J. Smoogen said: > On 2/14/06, seth vidal wrote: >> > Looking at this old patched version. I had to make some changes to Bro >> > that I sent upstream, and could not use the %configure but had to add >> > some entries to make it do what it should and not what it wanted. >> > >> > If the /svr/bro tree is allowed in extras.. that would clean up most >> > of the problems. Bro is a server/service. If it isnt.. expect to do a >> > bunch of cleanup. I think that most of my patch doesnt work with the >> > later versions due to offsets and such. >> > >> > > Talked to Seth on IRC, and /srv is also not the correct place for it > either from the FHS.. The bro package is going to need a lot of little > patches to match the FHS I think. > > Could /opt/bro be a possability? I have started the trek of patching up bro to be a little more FHS friendly, but no idea as to when I will be finished. Michael. From skvidal at linux.duke.edu Wed Feb 15 06:13:10 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 15 Feb 2006 01:13:10 -0500 Subject: packaging suggestions. In-Reply-To: <51112.219.89.109.32.1139982145.squirrel@www.knox.net.nz> References: <1139946879.19452.15.camel@cosima.et.endace.com> <80d7e4090602142012r3b224fd0kb7a1ddecf862b67@mail.gmail.com> <1139978539.11728.5.camel@cutter> <80d7e4090602142125g57540631q4c04f6a7a4caf6e9@mail.gmail.com> <51112.219.89.109.32.1139982145.squirrel@www.knox.net.nz> Message-ID: <1139983991.11728.7.camel@cutter> On Wed, 2006-02-15 at 18:42 +1300, Michael J Knox wrote: > Stephen J. Smoogen said: > > On 2/14/06, seth vidal wrote: > >> > Looking at this old patched version. I had to make some changes to Bro > >> > that I sent upstream, and could not use the %configure but had to add > >> > some entries to make it do what it should and not what it wanted. > >> > > >> > If the /svr/bro tree is allowed in extras.. that would clean up most > >> > of the problems. Bro is a server/service. If it isnt.. expect to do a > >> > bunch of cleanup. I think that most of my patch doesnt work with the > >> > later versions due to offsets and such. > >> > > >> > > > > Talked to Seth on IRC, and /srv is also not the correct place for it > > either from the FHS.. The bro package is going to need a lot of little > > patches to match the FHS I think. > > > > > > Could /opt/bro be a possability? > > I have started the trek of patching up bro to be a little more FHS > friendly, but no idea as to when I will be finished. > /opt is discouraged for package-managed software. right now I think your only hope is patching bro and/or deeply abusing the authors to use the various tools available to them more effectively. -sv From joost at soeterbroek.com Wed Feb 15 08:11:13 2006 From: joost at soeterbroek.com (Joost Soeterbroek) Date: Wed, 15 Feb 2006 09:11:13 +0100 Subject: Package heartbeat needs a reviewer Message-ID: <1139991074.3662.3.camel@alexandria> Hi, Package heartbeat needs a reviewer. Who would like to step up to the task? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 Regards, Joost fedora at soeterbroek.com From rc040203 at freenet.de Wed Feb 15 08:11:20 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 15 Feb 2006 09:11:20 +0100 Subject: packaging suggestions. In-Reply-To: <1139983991.11728.7.camel@cutter> References: <1139946879.19452.15.camel@cosima.et.endace.com> <80d7e4090602142012r3b224fd0kb7a1ddecf862b67@mail.gmail.com> <1139978539.11728.5.camel@cutter> <80d7e4090602142125g57540631q4c04f6a7a4caf6e9@mail.gmail.com> <51112.219.89.109.32.1139982145.squirrel@www.knox.net.nz> <1139983991.11728.7.camel@cutter> Message-ID: <1139991080.30045.68.camel@mccallum.corsepiu.local> On Wed, 2006-02-15 at 01:13 -0500, seth vidal wrote: > On Wed, 2006-02-15 at 18:42 +1300, Michael J Knox wrote: > > Stephen J. Smoogen said: > > > On 2/14/06, seth vidal wrote: > > Could /opt/bro be a possability? > > > > I have started the trek of patching up bro to be a little more FHS > > friendly, but no idea as to when I will be finished. > > > > /opt is discouraged for package-managed software. Correction: for OS-vendor supplied packages. There isn't anything wrong in using /opt rsp. /opt/ for package-vendor supplied packages. Ralf From bugzilla at redhat.com Wed Feb 15 08:33:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 03:33:47 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602150833.k1F8XlH2010515@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From imlinux at gmail.com 2006-02-15 03:33 EST ------- -Provide full path to source -Don't use Requires(hint) -Inconsitant use of $RPM_BUILD_ROOT (also used as ${RPM_BUILD_ROOT}) -defattr in %files is way off. You'll end up with dir's that aren't executable. put one %defattr(-,root,root,-) right under %files, get rid of the two that are there. -empty %build section (remove it) -Don't use hard coded paths, use macros: http://fedoraproject.org/wiki/Extras/RPMMacros -Group Applicaton/System is not a valid Fedora group -Put a version/release tag in your change logs -If this is a gallery2-minimal tarbal why not make a gallery2-minimal rpm? -Are you sponsored? -Please download rpmlint and run it against the rpm you generate -Take a look at: http://fedoraproject.org/wiki/Packaging/ReviewGuidelines It'll help if you know all the criteria that we review on. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From paul at city-fan.org Wed Feb 15 11:33:51 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 15 Feb 2006 11:33:51 +0000 Subject: rpms/gcfilms/devel gcfilms.spec,1.7,1.8 In-Reply-To: <200602151046.k1FAkbVx027681@cvs-int.fedora.redhat.com> References: <200602151046.k1FAkbVx027681@cvs-int.fedora.redhat.com> Message-ID: <1140003232.8444.7.camel@laurel.intra.city-fan.org> On Wed, 2006-02-15 at 05:46 -0500, Christian Jodar wrote: > Author: tian > > Update of /cvs/extras/rpms/gcfilms/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv27662 > > Modified Files: > gcfilms.spec > Log Message: > Update epoch for a cvs problem > > > > Index: gcfilms.spec > =================================================================== > RCS file: /cvs/extras/rpms/gcfilms/devel/gcfilms.spec,v > retrieving revision 1.7 > retrieving revision 1.8 > diff -u -r1.7 -r1.8 > --- gcfilms.spec 15 Feb 2006 10:42:00 -0000 1.7 > +++ gcfilms.spec 15 Feb 2006 10:46:05 -0000 1.8 > @@ -1,6 +1,6 @@ > Name: gcfilms > Version: 6.0 > -Release: 3%{?dist} > +Release: 4%{?dist} That's "release" you've updated, not "epoch". It's the right thing to do, you just used the wrong terminology. Paul. From tian at c-sait.net Wed Feb 15 12:44:28 2006 From: tian at c-sait.net (Christian Jodar) Date: Wed, 15 Feb 2006 13:44:28 +0100 Subject: Problems during a PPC build (Was Re: rpms/gcfilms/devel gcfilms.spec,1.7,1.8) In-Reply-To: <1140003232.8444.7.camel@laurel.intra.city-fan.org> References: <200602151046.k1FAkbVx027681@cvs-int.fedora.redhat.com> <1140003232.8444.7.camel@laurel.intra.city-fan.org> Message-ID: <20060215134428.33346d5a@tianbox> Hello, > That's "release" you've updated, not "epoch". > It's the right thing to do, you just used the wrong terminology. Oops. Sorry about that. I had a problem during build of this package. The log could be found here: http://buildsys.fedoraproject.org/logs/fedora-development-extras/4417-gcfilms-6.0-4.fc5/noarch/root.log It seems there is a problem with cpio which is needed to create the build environment. I can't remember a message on this mailing list dealing with this problem. Has someone information about this? (Or maybe I did something wrong). Christian Jodar. From bugs.michael at gmx.net Wed Feb 15 14:33:06 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 15 Feb 2006 15:33:06 +0100 Subject: Problems during a PPC build (Was Re: rpms/gcfilms/devel gcfilms.spec,1.7,1.8) In-Reply-To: <20060215134428.33346d5a@tianbox> References: <200602151046.k1FAkbVx027681@cvs-int.fedora.redhat.com> <1140003232.8444.7.camel@laurel.intra.city-fan.org> <20060215134428.33346d5a@tianbox> Message-ID: <20060215153306.43ec75de.bugs.michael@gmx.net> On Wed, 15 Feb 2006 13:44:28 +0100, Christian Jodar wrote: > Hello, > > > That's "release" you've updated, not "epoch". > > It's the right thing to do, you just used the wrong terminology. > > Oops. Sorry about that. > > I had a problem during build of this package. The log could be found here: > > http://buildsys.fedoraproject.org/logs/fedora-development-extras/4417-gcfilms-6.0-4.fc5/noarch/root.log > > It seems there is a problem with cpio which is needed to create the build > environment. I can't remember a message on this mailing list dealing with this > problem. Has someone information about this? (Or maybe I did something wrong). Most likely the Rawhide repository is broken temporarily. But you don't need to bump Release just to re-try the build. Just requeue the build job with plague-client. From bugzilla at redhat.com Wed Feb 15 14:36:00 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 09:36:00 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602151436.k1FEa0jm010184@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From jwb at redhat.com 2006-02-15 09:35 EST ------- Clarification requested: 1. Full path to source - should this be in the URL tag or the Source0 tag - and should I refer to the Gallery home page or to the Sourceforge downloadable tarball? 2. How do I specify that the RPM requires (MySQL or PostgreSQL) as opposed to needing both? The only documentation I could find involved using Requires(hint). 3. Should the installation path macro be defined in the specfile itself or in ~/.rpmmacros ? 4. My intent in using the gallery-minimal tarall was to package just the base set of files, creating add-on packages for additional themes / modules that would otherwise be in upstream's -typical, -full, or -developer tarball distributions. This would allow for removal of optional themes/modules normally contained in upstream's -typical -full and -developer packages without causing rpm -V to complain. 5. I am currently not sponsored; this is the first Fedora package I've attempted. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From skvidal at linux.duke.edu Wed Feb 15 14:45:47 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 15 Feb 2006 09:45:47 -0500 Subject: packaging suggestions. In-Reply-To: <1139991080.30045.68.camel@mccallum.corsepiu.local> References: <1139946879.19452.15.camel@cosima.et.endace.com> <80d7e4090602142012r3b224fd0kb7a1ddecf862b67@mail.gmail.com> <1139978539.11728.5.camel@cutter> <80d7e4090602142125g57540631q4c04f6a7a4caf6e9@mail.gmail.com> <51112.219.89.109.32.1139982145.squirrel@www.knox.net.nz> <1139983991.11728.7.camel@cutter> <1139991080.30045.68.camel@mccallum.corsepiu.local> Message-ID: <1140014747.13764.0.camel@cutter> On Wed, 2006-02-15 at 09:11 +0100, Ralf Corsepius wrote: > On Wed, 2006-02-15 at 01:13 -0500, seth vidal wrote: > > On Wed, 2006-02-15 at 18:42 +1300, Michael J Knox wrote: > > > Stephen J. Smoogen said: > > > > On 2/14/06, seth vidal wrote: > > > > Could /opt/bro be a possability? > > > > > > I have started the trek of patching up bro to be a little more FHS > > > friendly, but no idea as to when I will be finished. > > > > > > > /opt is discouraged for package-managed software. > Correction: for OS-vendor supplied packages. > > There isn't anything wrong in using /opt rsp. /opt/ for > package-vendor supplied packages. > okay -but surely we count as os-vendor not package-vendor, right? -sv From bugs.michael at gmx.net Wed Feb 15 14:46:53 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 15 Feb 2006 09:46:53 -0500 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-02-15 Message-ID: <200602151446.k1FEkr4c026051@mx1.redhat.com> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- sblim-cmpi-base-test 1.5.4-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- gnome-applet-sensors 1.4-3.fc4.ppc sblim-cmpi-base-test 1.5.4-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- sblim-cmpi-base-test 1.5.4-3.fc4.x86_64 ---------------------------------------------------------------------- New report for: hamzy AT us.ibm.com package: sblim-cmpi-base-test - 1.5.4-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: sblim-testsuite From bugs.michael at gmx.net Wed Feb 15 14:47:22 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 15 Feb 2006 09:47:22 -0500 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-02-15 Message-ID: <200602151447.k1FElM2e026270@mx1.redhat.com> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- amarok 1.3.6-1.fc5.i386 at-poke 0.2.2-2.i386 cyrus-imapd 2.2.12-6.fc4.i386 cyrus-imapd-murder 2.2.12-6.fc4.i386 cyrus-imapd-nntp 2.2.12-6.fc4.i386 cyrus-imapd-utils 2.2.12-6.fc4.i386 gnomebaker 0.5.1-2.fc5.i386 gstreamer08-python 0.8.3-1.fc5.i386 istanbul 0.1.1-5.i386 libgdamm 1.3.7-2.fc5.i386 octave-forge 2005.06.13-4.fc5.i386 pam_mount 0.9.25-4.i386 perl-Cyrus 2.2.12-6.fc4.i386 pgadmin3 1.0.2-5.i386 sabayon-admin 2.12.1-2.i386 scalapack 1.7-7.fc4.i386 seahorse 0.7.9-1.fc5.i386 soundconverter 0.8.3-1.fc5.noarch tidy-devel 0.99.0-8.20051025.fc5.i386 tripwire 2.3.1-22.i386 up-imapproxy 1.2.4-4.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- amarok 1.3.6-1.fc5.ppc at-poke 0.2.2-2.ppc cyrus-imapd 2.2.12-6.fc4.ppc cyrus-imapd-murder 2.2.12-6.fc4.ppc cyrus-imapd-nntp 2.2.12-6.fc4.ppc cyrus-imapd-utils 2.2.12-6.fc4.ppc gnomebaker 0.5.1-2.fc5.ppc gstreamer08-python 0.8.3-1.fc5.ppc istanbul 0.1.1-5.ppc libgdamm 1.3.7-2.fc5.ppc octave-forge 2005.06.13-4.fc5.ppc pam_mount 0.9.25-4.ppc perl-Cyrus 2.2.12-6.fc4.ppc pgadmin3 1.0.2-5.ppc sabayon-admin 2.12.1-2.ppc scalapack 1.7-7.fc4.ppc seahorse 0.7.9-1.fc5.ppc soundconverter 0.8.3-1.fc5.noarch tidy-devel 0.99.0-8.20051025.fc5.ppc up-imapproxy 1.2.4-4.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- amarok 1.3.6-1.fc5.x86_64 at-poke 0.2.2-2.x86_64 cernlib 2005-7.fc5.x86_64 cernlib-packlib 2005-7.fc5.x86_64 cyrus-imapd 2.2.12-6.fc4.x86_64 cyrus-imapd-murder 2.2.12-6.fc4.x86_64 cyrus-imapd-nntp 2.2.12-6.fc4.x86_64 cyrus-imapd-utils 2.2.12-6.fc4.x86_64 gnomebaker 0.5.1-2.fc5.x86_64 gstreamer08-python 0.8.3-1.fc5.x86_64 istanbul 0.1.1-5.x86_64 libgdamm 1.3.7-2.fc5.x86_64 octave-forge 2005.06.13-4.fc5.x86_64 pam_mount 0.9.25-4.x86_64 paw 2005-7.fc5.x86_64 perl-Cyrus 2.2.12-6.fc4.x86_64 pgadmin3 1.0.2-5.x86_64 sabayon-admin 2.12.1-2.x86_64 scalapack 1.7-7.fc4.x86_64 seahorse 0.7.9-1.fc5.x86_64 soundconverter 0.8.3-1.fc5.noarch tidy-devel 0.99.0-8.20051025.fc5.x86_64 up-imapproxy 1.2.4-4.fc5.x86_64 ---------------------------------------------------------------------- New report for: ghenry AT suretecsystems.com package: pgadmin3 - 1.0.2-5.i386 from fedora-extras-development-i386 unresolved deps: libssl.so.5 libcrypto.so.5 ---------------------------------------------------------------------- New report for: extras-orphan AT fedoraproject.org package: at-poke - 0.2.2-2.i386 from fedora-extras-development-i386 unresolved deps: libpixman.so.1 libcairo.so.1 ---------------------------------------------------------------------- New report for: markmc AT redhat.com package: sabayon-admin - 2.12.1-2.i386 from fedora-extras-development-i386 unresolved deps: xorg-x11-Xnest ---------------------------------------------------------------------- New report for: skvidal AT phy.duke.edu package: seahorse - 0.7.9-1.fc5.i386 from fedora-extras-development-i386 unresolved deps: libpixman.so.1 libcairo.so.1 ---------------------------------------------------------------------- New report for: tripwire-devel AT genesis-x.nildram.co.uk package: tripwire - 2.3.1-22.i386 from fedora-extras-development-i386 unresolved deps: libcrypto.so.5 ---------------------------------------------------------------------- New report for: qspencer AT ieee.org package: octave-forge - 2005.06.13-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgfortran.so.0 libcln.so.3 octave = 6:2.9.3 ---------------------------------------------------------------------- New report for: redhat AT flyn.org package: pam_mount - 0.9.25-4.i386 from fedora-extras-development-i386 unresolved deps: libcrypto.so.5 libssl.so.5 ---------------------------------------------------------------------- New report for: pertusus AT free.fr package: paw - 2005-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libXm.so.3()(64bit) ---------------------------------------------------------------------- New report for: tcallawa AT redhat.com package: libgdamm - 1.3.7-2.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgda-2.so.3 package: scalapack - 1.7-7.fc4.i386 from fedora-extras-development-i386 unresolved deps: libgfortran.so.0 ---------------------------------------------------------------------- New report for: jdennis AT redhat.com package: cyrus-imapd - 2.2.12-6.fc4.i386 from fedora-extras-development-i386 unresolved deps: libssl.so.5 libcrypto.so.5 ---------------------------------------------------------------------- New report for: jeff AT ultimateevil.org package: up-imapproxy - 1.2.4-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libssl.so.5 libcrypto.so.5 ---------------------------------------------------------------------- New report for: jspaleta AT gmail.com package: istanbul - 0.1.1-5.i386 from fedora-extras-development-i386 unresolved deps: gstreamer-plugins >= 0:0.8.9 From mmcgrath at fedoraproject.org Wed Feb 15 14:51:31 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 15 Feb 2006 08:51:31 -0600 Subject: Package heartbeat needs a reviewer In-Reply-To: <1139991074.3662.3.camel@alexandria> References: <1139991074.3662.3.camel@alexandria> Message-ID: <3237e4410602150651l64d731edx600ff3ec08548fda@mail.gmail.com> > Package heartbeat needs a reviewer. Who would like to step up to the > task? > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 > > Regards, > > Joost > fedora at soeterbroek.com > Someone will get to it, in the meantime you can help out by reviewing other peoples packages. Notice how many packages need to be reviewed and where yours is :-D https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=FE-NEW&hide_resolved=1 Today's review day though, so join the IRC channel and knock yourself out. -Mike From bugzilla at redhat.com Wed Feb 15 15:18:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 10:18:27 -0500 Subject: [Bug 181534] Review Request: kst - plots scientific data In-Reply-To: Message-ID: <200602151518.k1FFIRAt016722@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kst - plots scientific data https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181534 ------- Additional Comments From somlo at cmu.edu 2006-02-15 10:18 EST ------- In the main package file list, you have: %{_libdir}/lib*.so.* Then, in the devel package file list, you have this: %{_libdir}/lib*.so Without building the package myself, I'm wondering if this is right. Typically, programs look for the *.so files, which end up being symlinks to the *.so.X.Y.Z files, and therefore they all (both *.so symlinks AND *.so.X.Y.Z library files) belong in the main package. Typically, the devel package will contain only the static libraries (*.a) in addition to the includes. Anyway, just wondering... :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From Jochen at herr-schmitt.de Wed Feb 15 15:30:06 2006 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 15 Feb 2006 16:30:06 +0100 Subject: Adopting package lincvs Message-ID: <20060215153006.GA3550@myhome> Hello, I want to adopt the package lincvs. I have updated it to version 1.4.4 and create a patch which you will need for compile lincvs on gcc41. Best Regards: Jochen Schmitt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Wed Feb 15 15:30:38 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 15 Feb 2006 16:30:38 +0100 Subject: packaging suggestions. In-Reply-To: <1140014747.13764.0.camel@cutter> References: <1139946879.19452.15.camel@cosima.et.endace.com> <80d7e4090602142012r3b224fd0kb7a1ddecf862b67@mail.gmail.com> <1139978539.11728.5.camel@cutter> <80d7e4090602142125g57540631q4c04f6a7a4caf6e9@mail.gmail.com> <51112.219.89.109.32.1139982145.squirrel@www.knox.net.nz> <1139983991.11728.7.camel@cutter> <1139991080.30045.68.camel@mccallum.corsepiu.local> <1140014747.13764.0.camel@cutter> Message-ID: <1140017438.11538.35.camel@mccallum.corsepiu.local> On Wed, 2006-02-15 at 09:45 -0500, seth vidal wrote: > On Wed, 2006-02-15 at 09:11 +0100, Ralf Corsepius wrote: > > On Wed, 2006-02-15 at 01:13 -0500, seth vidal wrote: > > > On Wed, 2006-02-15 at 18:42 +1300, Michael J Knox wrote: > > > > Stephen J. Smoogen said: > > > > > On 2/14/06, seth vidal wrote: > > > > > > Could /opt/bro be a possability? > > > > > > > > I have started the trek of patching up bro to be a little more FHS > > > > friendly, but no idea as to when I will be finished. > > > > > > > > > > /opt is discouraged for package-managed software. > > Correction: for OS-vendor supplied packages. > > > > There isn't anything wrong in using /opt rsp. /opt/ for > > package-vendor supplied packages. > > > > okay -but surely we count as os-vendor not package-vendor, right? Yep, at least that's how all FE packages currently are being packaged. Ralf From bugzilla at redhat.com Wed Feb 15 15:37:40 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 10:37:40 -0500 Subject: [Bug 181534] Review Request: kst - plots scientific data In-Reply-To: Message-ID: <200602151537.k1FFbeL5020753@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kst - plots scientific data https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181534 ------- Additional Comments From matt at truch.net 2006-02-15 10:37 EST ------- (In reply to comment #1) > In the main package file list, you have: > > %{_libdir}/lib*.so.* > > Then, in the devel package file list, you have this: > > %{_libdir}/lib*.so > > Without building the package myself, I'm wondering if this is right. Typically, > programs look for the *.so files, which end up being symlinks to the *.so.X.Y.Z > files, and therefore they all (both *.so symlinks AND *.so.X.Y.Z library files) > belong in the main package. Typically, the devel package will contain only the > static libraries (*.a) in addition to the includes. > > Anyway, just wondering... :) I'm not a library package expert, and don't know which .so files the program looks for. However, I'm following the protocol outlined in http://fedoraproject.org/wiki/Packaging/ReviewGuidelines , specifically the line "MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package." Furthermore, I have tested that kst runs fine without the kst-devel pacakge installed. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 15 15:41:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 10:41:27 -0500 Subject: [Bug 181534] Review Request: kst - plots scientific data In-Reply-To: Message-ID: <200602151541.k1FFfR8V021375@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kst - plots scientific data https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181534 ------- Additional Comments From rc040203 at freenet.de 2006-02-15 10:41 EST ------- In reply to comment #1) > In the main package file list, you have: > > %{_libdir}/lib*.so.* > > Then, in the devel package file list, you have this: > > %{_libdir}/lib*.so > > Without building the package myself, I'm wondering if this is right. Unless the package is broken and correctly applies SONAMES, it normally is. > Typically, > programs look for the *.so files, No. Very oversimplified, ld.so at runtime looks for a library providing an SONAME. A properly build shared library normally uses libXXXX.so. as SONAME. This is where the *.so symlink points to. The *.so symlink normally only is being used by the linker, when linking a package. => *.so go to *-devel => *.so.* to the run-time package. > Anyway, just wondering... :) You're in error ;) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From pertusus at free.fr Wed Feb 15 16:04:34 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 15 Feb 2006 17:04:34 +0100 Subject: shared versus static for numerical and plotting Message-ID: <20060215160434.GI3649@free.fr> Hello, I think that we should make an exception for not shipping static library for plotting or numerical stuff. Indeed the arguments to avoid static libraries in that case don't hold as security/bugfixes/nss/glibc are not an issue in that case. At least the arguments listed at http://people.redhat.com/drepper/no_static_linking.html don't seem to be relevant for such cases. Moreover the shared libs will be picked up in priority, so the user must link on purpose with static libraries. On the other hand it is very handy to be able to rerun a model or a program that do a graph 5 years later and on other linux boxes. Any thoughts on this? If it is agreed, could it be stated on the wiki? http://fedoraproject.org/wiki/Packaging/Guidelines#head-2302ec1e1f44202c9cc4bcce24cb711266557ad7 I don't think that we should ship static libraries in general, for example I believe that this should be avoided for network stuff, image or text processing, basic system stuff and so on... -- Pat From bugzilla at redhat.com Wed Feb 15 16:15:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 11:15:16 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602151615.k1FGFG7a027492@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From bugs.michael at gmx.net 2006-02-15 11:15 EST ------- "URL" tag for the web page, "Source" for the tarball download location. > %defattr(-,root,root-) Typo. There is no system group "root-". You want "root". > %{installprefix}/gallery2/* With that, directory "gallery2" is not included. To include the directory and everything in it recursively, use just: %{installprefix}/gallery2/ > I made this package relocatable, as it is intended upstream to > be installable to a ~/public_html directory as well as /var/www/html, Questionable. The package has several dependencies. A normal user with an own RPM database could not simply install the package without using the --nodeps option. > %install > [ "${RPM_BUILD_ROOT}" != "/" ] && rm -rf ${RPM_BUILD_ROOT} This check doesn't make much sense. You provide a default build root at the top. There is no evidence that anybody ever builds rpms as superuser and overrides the build root at the same time. > GraphicsMagick>=1 Is this available in Core or Extras? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rc040203 at freenet.de Wed Feb 15 16:22:35 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 15 Feb 2006 17:22:35 +0100 Subject: shared versus static for numerical and plotting In-Reply-To: <20060215160434.GI3649@free.fr> References: <20060215160434.GI3649@free.fr> Message-ID: <1140020555.11538.49.camel@mccallum.corsepiu.local> On Wed, 2006-02-15 at 17:04 +0100, Patrice Dumas wrote: > Hello, > > I think that we should make an exception for not shipping static library > for plotting or numerical stuff. Indeed the arguments to avoid static > libraries in that case don't hold as security/bugfixes/nss/glibc are not > an issue in that case. At least the arguments listed at > > http://people.redhat.com/drepper/no_static_linking.html > > don't seem to be relevant for such cases. Moreover the shared libs will be > picked up in priority, so the user must link on purpose with static libraries. > On the other hand it is very handy to be able to rerun a model or a program > that do a graph 5 years later and on other linux boxes. > > Any thoughts on this? Yes, IMNSO, there should not be any exceptions, unless you can prove a significant speed up (say 25%) of static linkage vs. shared libs in a particular case. Ralf From nicolas.mailhot at laposte.net Wed Feb 15 16:23:40 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 15 Feb 2006 17:23:40 +0100 (CET) Subject: packaging suggestions. In-Reply-To: <1140017438.11538.35.camel@mccallum.corsepiu.local> References: <1139946879.19452.15.camel@cosima.et.endace.com> <80d7e4090602142012r3b224fd0kb7a1ddecf862b67@mail.gmail.com> <1139978539.11728.5.camel@cutter> <80d7e4090602142125g57540631q4c04f6a7a4caf6e9@mail.gmail.com> <51112.219.89.109.32.1139982145.squirrel@www.knox.net.nz> <1139983991.11728.7.camel@cutter> <1139991080.30045.68.camel@mccallum.corsepiu.local> <1140014747.13764.0.camel@cutter> <1140017438.11538.35.camel@mccallum.corsepiu.local> Message-ID: <23377.192.54.193.25.1140020620.squirrel@rousalka.dyndns.org> Le Mer 15 f?vrier 2006 16:30, Ralf Corsepius a ?crit : > On Wed, 2006-02-15 at 09:45 -0500, seth vidal wrote: >> On Wed, 2006-02-15 at 09:11 +0100, Ralf Corsepius wrote: >> > On Wed, 2006-02-15 at 01:13 -0500, seth vidal wrote: >> > > On Wed, 2006-02-15 at 18:42 +1300, Michael J Knox wrote: >> > > > Stephen J. Smoogen said: >> > > > > On 2/14/06, seth vidal wrote: >> > >> > > > Could /opt/bro be a possability? >> > > > >> > > > I have started the trek of patching up bro to be a little more FHS >> > > > friendly, but no idea as to when I will be finished. >> > > > >> > > >> > > /opt is discouraged for package-managed software. >> > Correction: for OS-vendor supplied packages. >> > >> > There isn't anything wrong in using /opt rsp. /opt/ for >> > package-vendor supplied packages. >> > >> >> okay -but surely we count as os-vendor not package-vendor, right? > Yep, at least that's how all FE packages currently are being packaged. Also /opt is just a loophole the big closed app vendors that compose LSB requested. It should not be used on a clean system -- Nicolas Mailhot From qspencer at ieee.org Wed Feb 15 16:28:44 2006 From: qspencer at ieee.org (Quentin Spencer) Date: Wed, 15 Feb 2006 10:28:44 -0600 Subject: [Fwd: Build Error (Job 4431): glpk-4_9-2_fc5 on fedora-development-extras] Message-ID: <43F356BC.9040501@ieee.org> I got this error yesterday and got it again today when I tried to build this package. What's going on? -Quentin -------------- next part -------------- An embedded message was scrubbed... From: buildsys at fedoraproject.org Subject: Build Error (Job 4431): glpk-4_9-2_fc5 on fedora-development-extras Date: Wed, 15 Feb 2006 11:22:01 -0500 (EST) Size: 4944 URL: From rc040203 at freenet.de Wed Feb 15 16:31:31 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 15 Feb 2006 17:31:31 +0100 Subject: packaging suggestions. In-Reply-To: <23377.192.54.193.25.1140020620.squirrel@rousalka.dyndns.org> References: <1139946879.19452.15.camel@cosima.et.endace.com> <80d7e4090602142012r3b224fd0kb7a1ddecf862b67@mail.gmail.com> <1139978539.11728.5.camel@cutter> <80d7e4090602142125g57540631q4c04f6a7a4caf6e9@mail.gmail.com> <51112.219.89.109.32.1139982145.squirrel@www.knox.net.nz> <1139983991.11728.7.camel@cutter> <1139991080.30045.68.camel@mccallum.corsepiu.local> <1140014747.13764.0.camel@cutter> <1140017438.11538.35.camel@mccallum.corsepiu.local> <23377.192.54.193.25.1140020620.squirrel@rousalka.dyndns.org> Message-ID: <1140021091.11538.53.camel@mccallum.corsepiu.local> On Wed, 2006-02-15 at 17:23 +0100, Nicolas Mailhot wrote: > Le Mer 15 f?vrier 2006 16:30, Ralf Corsepius a ?crit : > > On Wed, 2006-02-15 at 09:45 -0500, seth vidal wrote: > >> On Wed, 2006-02-15 at 09:11 +0100, Ralf Corsepius wrote: > >> > On Wed, 2006-02-15 at 01:13 -0500, seth vidal wrote: > >> > > On Wed, 2006-02-15 at 18:42 +1300, Michael J Knox wrote: > >> > > > Stephen J. Smoogen said: > >> > > > > On 2/14/06, seth vidal wrote: > >> > > >> > > > Could /opt/bro be a possability? > >> > > > > >> > > > I have started the trek of patching up bro to be a little more FHS > >> > > > friendly, but no idea as to when I will be finished. > >> > > > > >> > > > >> > > /opt is discouraged for package-managed software. > >> > Correction: for OS-vendor supplied packages. > >> > > >> > There isn't anything wrong in using /opt rsp. /opt/ for > >> > package-vendor supplied packages. > >> > > >> > >> okay -but surely we count as os-vendor not package-vendor, right? > > Yep, at least that's how all FE packages currently are being packaged. > > Also /opt is just a loophole the big closed app vendors that compose LSB > requested. It should not be used on a clean system ?!? A bizarre statement ?!? /opt's primary purpose is to take "large add-on packages" and has a long tradition serving as such. Ralf From pertusus at free.fr Wed Feb 15 16:31:57 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 15 Feb 2006 17:31:57 +0100 Subject: shared versus static for numerical and plotting In-Reply-To: <1140020555.11538.49.camel@mccallum.corsepiu.local> References: <20060215160434.GI3649@free.fr> <1140020555.11538.49.camel@mccallum.corsepiu.local> Message-ID: <20060215163157.GJ3649@free.fr> > Yes, IMNSO, there should not be any exceptions, unless you can prove a > significant speed up (say 25%) of static linkage vs. shared libs in a > particular case. I didn't told anything about speed. I advocated static libs to for portability reasons. To let the user the possibility to link statically. Even if the speed is reduced by 90%, my point still holds. Maybe I wasn't clear about one thing. I think that the fedora packages should never be linked against static libs when shared libs exist, but that the static libs should be shipped if a user want to link statically (for numerical and plotting libs). -- Pat From bugzilla at redhat.com Wed Feb 15 16:30:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 11:30:34 -0500 Subject: [Bug 181444] Review Request: lcov -- process gcov output into nice html pages In-Reply-To: Message-ID: <200602151630.k1FGUY20030752@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: lcov -- process gcov output into nice html pages https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181444 ------- Additional Comments From dan at danny.cz 2006-02-15 11:30 EST ------- only one note to the spec - empty %build => should be omitted And as this looks as a uncomplicated package I could do a my first formal package review. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From dan at danny.cz Wed Feb 15 16:44:55 2006 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Wed, 15 Feb 2006 17:44:55 +0100 Subject: [Fwd: Build Error (Job 4431): glpk-4_9-2_fc5 on fedora-development-extras] In-Reply-To: <43F356BC.9040501@ieee.org> References: <43F356BC.9040501@ieee.org> Message-ID: <1140021895.3392.7.camel@eagle.danny.cz> Quentin Spencer p??e v St 15. 02. 2006 v 10:28 -0600: > I got this error yesterday and got it again today when I tried to build > this package. What's going on? > I saw the same output in my yesterday's build of tinyerp, but today's build was OK. It is probably some inconsistency between rawhide mirrors/primary sites. Dan From bugzilla at redhat.com Wed Feb 15 17:14:05 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 12:14:05 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602151714.k1FHE5JJ007859@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From jwb at redhat.com 2006-02-15 12:14 EST ------- Source tag now contains the full link to the sourceforge download tarball, with the caveat that sourceforge will ask you what mirror you want to use. %defattr typo has been fixed, removed trailing * from %{installprefix}/gallery2/ ${RPM_BUILD_ROOT} check removed from %install section GraphicsMagick package removed from Requires - not provided in Core or Extras - it was mentioned on the Gallery home page. SRPM and spec file have been updated. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 15 17:33:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 12:33:49 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602151733.k1FHXn3G011729@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From paul at city-fan.org 2006-02-15 12:33 EST ------- (In reply to comment #4) > Source tag now contains the full link to the sourceforge download tarball, with > the caveat that sourceforge will ask you what mirror you want to use. If you change Source0: to: http://dl.sf.net/gallery/gallery-%{version}-minimal.tar.gz then it will work properly, without the mirror selection page. Since you're making the package relocatable by including a Prefix: tag, you should add comments in the spec to justify this (relocatable packages are not the norm in Extras). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 15 17:52:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 12:52:56 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602151752.k1FHquSe015309@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From jwb at redhat.com 2006-02-15 12:52 EST ------- Comment added, hostname for URL in Source0 tag changed, SRPM/spec file updated. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 15 19:01:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 14:01:33 -0500 Subject: [Bug 181534] Review Request: kst - plots scientific data In-Reply-To: Message-ID: <200602151901.k1FJ1XKT031475@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kst - plots scientific data https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181534 orion at cora.nwra.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bugzilla-sink at leemhuis.info |orion at cora.nwra.com OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From orion at cora.nwra.com 2006-02-15 14:01 EST ------- Good: - package meets naming guidelines - package meets packaging guidelines - license (GPL) OK, text in %doc, matches source - spec file legible, in am. english - source matches upstream - no missing BR - uses %find_lang - not relocatable - no duplicate files - permissions ok - %clean ok - macro use consistent - code, not content - nothing in %doc affects runtime - devel package ok - post/postun ldconfig ok - devel requires base package n-v-r Bad: - This needs to compile on devel first, so it needs to handle modular X. BR xorg-x11-devel needs to be removed. - Unnecessary BR: qt-devel,kdelibs-devel (required by kdebindings-devel) - Needs to owns all directories that it creates: %{_datadir}/apps/kst/ %{_datadir}/services/kst/ %{_datadir}/servicetypes/ %{_libdir}/kde3/kstplugins/ Other notes: - Might want to change Source0 to: ftp://ftp.kde.org/pub/kde/stable/apps/KDE3.x/scientific/kst-%{version}.tar.gz - I'll need to take a look at the desktop files later - Still working on building in mock and running rpmlint. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From buildsys at fedoraproject.org Wed Feb 15 19:37:15 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 15 Feb 2006 14:37:15 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060215193715.572138031@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 1 galculator-1.2.5-4.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed Feb 15 19:37:29 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 15 Feb 2006 14:37:29 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060215193729.EC3D58031@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 6 fftw-3.1-2.fc4 galculator-1.2.5-4.fc4 lighttpd-1.4.10-1.fc4 lincvs-1.4.4-1.fc4 ppracer-0.3.1-4.fc4.1 python-numarray-1.5.1-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed Feb 15 19:37:54 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 15 Feb 2006 14:37:54 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060215193754.6FD608031@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 22 SIBsim4-0.9-2.fc5 ccid-0.4.1-7.fc5 crack-5.0a-3.fc5 gnuchess-5.07-9.fc5 hmmer-2.3.2-5.fc5 koffice-langpack-1.4.2-2.fc5 lagan-1.21-2.fc5 libAfterImage-1.07-7.fc5 libetpan-0.42-2.fc5 nfswatch-4.99.5-3.fc5 numlockx-1.0-9.fc5 openct-0.6.6-4.fc5 pcsc-perl-1.3.1-8.fc5 perl-Class-Loader-2.03-2.fc5 perl-Pod-Escapes-1.04-4.fc5 perl-Time-modules-2003.1126-3.fc5 pyxdg-0.15-2.fc5 qascade-0.1-5.fc5 qgo-1.0.4r2-1.fc5 rbldnsd-0.995-5.fc5 spamass-milter-0.3.0-9.fc5 tinyerp-3.2.1-2.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Wed Feb 15 19:40:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 14:40:11 -0500 Subject: [Bug 181450] Review Request: clamav-exim - Clam AV support files for Exim In-Reply-To: Message-ID: <200602151940.k1FJeB0P008223@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: clamav-exim - Clam AV support files for Exim https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181450 orion at cora.nwra.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bugzilla-sink at leemhuis.info |orion at cora.nwra.com OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From orion at cora.nwra.com 2006-02-15 14:40 EST ------- - rpmlint checks return: W: clamav-exim no-url-tag W: clamav-exim no-documentation E: clamav-exim incoherent-logrotate-file /etc/logrotate.d/clamd.exim E: clamav-exim non-standard-uid /var/run/clamd.exim clamexim E: clamav-exim non-standard-gid /var/run/clamd.exim exim E: clamav-exim non-standard-dir-perm /var/run/clamd.exim 0750 E: clamav-exim non-standard-gid /var/log/clamd.exim exim E: clamav-exim non-root-group-log-file /var/log/clamd.exim exim W: clamav-exim dangerous-command-in-%post chmod ^ If you really need a log file, perhaps create in %install? E: clamav-exim init-script-name-with-dot /etc/rc.d/init.d/clamd.exim E: clamav-exim no-status-entry /etc/rc.d/init.d/clamd.exim W: clamav-exim no-reload-entry /etc/rc.d/init.d/clamd.exim E: clamav-exim subsys-not-used /etc/rc.d/init.d/clamd.exim W: clamav-exim incoherent-init-script-name clamd.exim - license (GPL) OK, need text in %doc. ? - No upstream, is this okay? - macro use not consistent between %var and %{var} Good: - package meets naming guidelines - package meets packaging guidelines - spec file legible, in am. english - package compiles on devel (x86) - no missing BR - no unnecessary BR - no locales - not relocatable - owns all directories that it creates - no duplicate files - %clean ok - code, not content - no need for -docs - nothing in %doc affects runtime - no need for .desktop file -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 15 20:01:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 15:01:50 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602152001.k1FK1o6D013913@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 orion at cora.nwra.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bugzilla-sink at leemhuis.info |orion at cora.nwra.com OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From orion at cora.nwra.com 2006-02-15 15:01 EST ------- Not full review yet, but close. - rpmlint checks return: W: heartbeat non-standard-group Networking/Daemons E: heartbeat hardcoded-library-path in $RPM_BUILD_ROOT/usr/lib/heartbeat/crmtest/helper.sh E: heartbeat hardcoded-library-path in /usr/lib/libhbmgmt.* E: heartbeat hardcoded-library-path in /usr/lib/libhbmgmtclient.* E: heartbeat hardcoded-library-path in /usr/lib/libhbmgmtcommon.* E: heartbeat hardcoded-library-path in /usr/lib/libhbmgmttls.* Needs work: * Spec file: some paths are not replaced with RPM macros (wiki: QAChecklist item 7) * The BuildRoot must be cleaned at the beginning of %install - Why split into -stonith and -pils packages but have the base package require them? Good: - package meets naming guidelines - package meets packaging guidelines - license (GPL/LGPL) OK, text in %doc, matches source - spec file legible, in am. english - source matches upstream - package compiles on devel (x86) - no missing BR - no unnecessary BR - no locales - not relocatable - owns all directories that it creates - no duplicate files - permissions ok - %clean ok - macro use consistent - code, not content - no need for -docs - nothing in %doc affects runtime - no need for .desktop file Nitpicks: - use %setup -q -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From fedora at leemhuis.info Wed Feb 15 19:30:43 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 15 Feb 2006 20:30:43 +0100 Subject: plague-client requeue (Was: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1139851362.2904.79.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> Message-ID: <1140031843.4205.20.camel@localhost.localdomain> Hi all! Am Montag, den 13.02.2006, 18:22 +0100 schrieb Thorsten Leemhuis: >[...] > The last rawhide mass-rebuild is mostly done now so it's time for us to > also rebuild **all packages** in the Fedora Extras development tree > before it becomes Fedora Extras 5 (FE) when Fedora Core 5 is > branched/released. Just FYI: - The rawhide breakage that resulted in a lot of failed builds in the past hours seems to be fixed now - If you have a failed build due to a temporary rawhide breakage just run "plague-client requeue " to requeue the job in the buildsys -- this way is a little bit cleaner then running "make build" again. CU thl -- Thorsten Leemhuis From kevin-fedora-extras at scrye.com Wed Feb 15 20:55:21 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Wed, 15 Feb 2006 13:55:21 -0700 (MST) Subject: REMINDER: Review Day is today! Message-ID: <20060215.135521.251070052.kevin@scrye.com> Just a reminder that today is Review Day http://fedoraproject.org/wiki/Extras/ReviewDay Come join us on #fedora-extras and get some reviews going. :) kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugzilla at redhat.com Wed Feb 15 20:59:22 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 15:59:22 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602152059.k1FKxMli024428@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From fedora at soeterbroek.com 2006-02-15 15:59 EST ------- Spec Name or Url: http://www.soeterbroek.com/linux/fedora/extras/heartbeat/heartbeat.spec SRPM Name or Url: http://www.soeterbroek.com/linux/fedora/extras/heartbeat/heartbeat-2.0.3-2.src.rpm * Wed Feb 15 2006 Joost Soeterbroek - 2.0.3-2 - enable mgmt option - fixes for various rpmlint errors and warnings: - fixed setup -q - make subpackages depend on basepackage, not reverse - clean buildroot at beginning of install - replaced a number of hardcoded paths with RPM macros - Changed Group from Networking/Daemons to System Environment/Daemons -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 15 21:16:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 16:16:53 -0500 Subject: [Bug 181534] Review Request: kst - plots scientific data In-Reply-To: Message-ID: <200602152116.k1FLGreb027398@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kst - plots scientific data https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181534 ------- Additional Comments From matt at truch.net 2006-02-15 16:16 EST ------- Updated spec to address above (I hope): http://matt.truch.net/fedora/kst.spec http://matt.truch.net/fedora/kst-1.2.0-2.src.rpm Removed un-needed build requires. Ownes directories. Changed Source0 as requested. I don't have access to a machine running devel, so I can't confirm that it can build there. :-( Thanks for the comments thus far. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 15 21:24:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 16:24:28 -0500 Subject: [Bug 181534] Review Request: kst - plots scientific data In-Reply-To: Message-ID: <200602152124.k1FLOSVF029359@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kst - plots scientific data https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181534 ------- Additional Comments From ed at eh3.com 2006-02-15 16:24 EST ------- Hi Matt, with mock you can specify a buildroot such as: mock -r fedora-5-i386-core ${YOUR_SRPM} so that, even on an FC4 system, you can test builds on a devel/FC5 system -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 15 21:31:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 16:31:18 -0500 Subject: [Bug 181534] Review Request: kst - plots scientific data In-Reply-To: Message-ID: <200602152131.k1FLVIa5030755@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kst - plots scientific data https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181534 ------- Additional Comments From orion at cora.nwra.com 2006-02-15 16:31 EST ------- It builds fine for me on devel with xorg-x11-devel removed. - Get rid of: --disable-debug and CXXFLAGS=-g CFLAGS=-g debuginfo packages are created automatically and your mucking with the RPM optimization flags. $ rpmlint kst-docs W: kst-docs dangling-symlink /usr/share/doc/HTML/sv/kst/common /usr/share/doc/HTML/sv/common W: kst-docs symlink-should-be-relative /usr/share/doc/HTML/sv/kst/common /usr/share/doc/HTML/sv/common W: kst-docs dangling-symlink /usr/share/doc/HTML/et/kst/common /usr/share/doc/HTML/et/common W: kst-docs symlink-should-be-relative /usr/share/doc/HTML/et/kst/common /usr/share/doc/HTML/et/common W: kst-docs dangling-symlink /usr/share/doc/HTML/en/kst/common /usr/share/doc/HTML/en/common W: kst-docs symlink-should-be-relative /usr/share/doc/HTML/en/kst/common /usr/share/doc/HTML/en/common W: kst-docs dangling-symlink /usr/share/doc/HTML/fr/kst/common /usr/share/doc/HTML/fr/common W: kst-docs symlink-should-be-relative /usr/share/doc/HTML/fr/kst/common /usr/share/doc/HTML/fr/common W: kst-docs dangling-symlink /usr/share/doc/HTML/pt/kst/common /usr/share/doc/HTML/pt/common W: kst-docs symlink-should-be-relative /usr/share/doc/HTML/pt/kst/common /usr/share/doc/HTML/pt/common W: kst-docs dangling-symlink /usr/share/doc/HTML/it/kst/common /usr/share/doc/HTML/it/common W: kst-docs symlink-should-be-relative /usr/share/doc/HTML/it/kst/common /usr/share/doc/HTML/it/common W: kst-docs dangling-symlink /usr/share/doc/HTML/nl/kst/common /usr/share/doc/HTML/nl/common W: kst-docs symlink-should-be-relative /usr/share/doc/HTML/nl/kst/common /usr/share/doc/HTML/nl/common W: kst-docs dangling-symlink /usr/share/doc/HTML/da/kst/common /usr/share/doc/HTML/da/common W: kst-docs symlink-should-be-relative /usr/share/doc/HTML/da/kst/common /usr/share/doc/HTML/da/common I generally fix with: #Fix doc link ln -sf ../common $RPM_BUILD_ROOT%{_defaultdocdir}/HTML/en/%{name} Looks like I end up with a new menu tree: Applications -> Sciences -> kst. Not sure if this is kosher for FE. I'll poke around. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 15 21:40:42 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 16:40:42 -0500 Subject: [Bug 176373] Review Request: ytalk In-Reply-To: Message-ID: <200602152140.k1FLegvb000855@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ytalk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176373 kevin at tummy.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |kevin at tummy.com OtherBugsDependingO|163776, 177841 |163779 nThis| | ------- Additional Comments From kevin at tummy.com 2006-02-15 16:40 EST ------- Greetings, heres a review: MUST items: OK - package name good. OK - license ok. (GPL) OK - spec file matches. OK - spec in english. OK - spec legible. OK - md5sum matches: c043a8d854638b293a3b645d8600aa38 ytalk-3.3.0.tar.gz c043a8d854638b293a3b645d8600aa38 ytalk-3.3.0.tar.gz.1 OK - files and dirs ok. OK - clean section good. OK - macros good. OK - builds ok in fc4. OK - compiles and builds under devel. OK - builds ok in mock on devel. OK - rpmlint has no output. Minor/non blockers: - Might include COPYING, README, AUTHORS, Changelog as docs? APPROVED. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 15 22:01:43 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 17:01:43 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602152201.k1FM1hM2005988@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From orion at cora.nwra.com 2006-02-15 17:01 EST ------- - Get rid of: Requires: python Requires: gnutls rpmbuild auto-detects this Do you really need: Requires: sysklogd Requires: python-gtk >= 2.4 Requires: gettext Requires: swig nothing seems to reference them for run time. - Instead of echo '#!/bin/sh' > /tmp/tmp.$$ ; cat $RPM_BUILD_ROOT/%{_libdir}/heartbeat/crmtest/helper.sh >> \ /tmp/tmp.$$ ; mv /tmp/tmp.$$ $RPM_BUILD_ROOT/%{_libdir}/heartbeat/crmtest/helper.sh how about: sed -i -e '1i#!/bin/sh' $RPM_BUILD_ROOT/%{_libdir}/heartbeat/crmtest/helper.sh - ocf stuff gets installed to /usr/lib on 64-bit, so: %{_prefix}/lib/ocf though perhaps /usr/share/heartbeat/ocf would be a better location. Not sure what heartbeats requirements are. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 15 22:10:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 17:10:10 -0500 Subject: [Bug 181450] Review Request: clamav-exim - Clam AV support files for Exim In-Reply-To: Message-ID: <200602152210.k1FMAAn9007471@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: clamav-exim - Clam AV support files for Exim https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181450 ------- Additional Comments From rpm at timj.co.uk 2006-02-15 17:10 EST ------- Thanks very much for the review. I should have mentioned that I knew rpmlint barfed lots, mostly due to this being a very weird package. > W: clamav-exim no-url-tag There isn't a relevant URL. > W: clamav-exim no-documentation There are no docs, though maybe I should write a short README. > E: clamav-exim incoherent-logrotate-file /etc/logrotate.d/clamd.exim Is this the filename (i.e. clamd.exim) that it's complaining about? If so, I know it's not the same as the package but the convention wasn't invented by me but does make sense. > E: clamav-exim non-standard-uid /var/run/clamd.exim clamexim > E: clamav-exim non-standard-gid /var/run/clamd.exim exim > E: clamav-exim non-standard-dir-perm /var/run/clamd.exim 0750 > E: clamav-exim non-standard-gid /var/log/clamd.exim exim I don't really understand these; the uid/gid/perms are intended and correct. > E: clamav-exim non-root-group-log-file /var/log/clamd.exim exim So, clamexim.root then? Howveer, users in the "exim" group might conceivably want read-access to the logs. > W: clamav-exim dangerous-command-in-%post chmod > ^ If you really need a log file, perhaps create in %install? I could do. However, this stuff all came from the original spec fragments that were checked into the clamav package by David Woodhouse (dwmw2 at redhat). Given that David is more experienced than me I was deferring to his judgement. Any other thoughts from others would be welcome. > E: clamav-exim init-script-name-with-dot /etc/rc.d/init.d/clamd.exim See above discussion about the clamd.exim convention. > E: clamav-exim no-status-entry /etc/rc.d/init.d/clamd.exim > W: clamav-exim no-reload-entry /etc/rc.d/init.d/clamd.exim > E: clamav-exim subsys-not-used /etc/rc.d/init.d/clamd.exim These are all bogus considering that the init script is essentially just a pointer to the main clamav one. > W: clamav-exim incoherent-init-script-name clamd.exim See above discusion about the clamd.exim convention. > license (GPL) OK, need text in %doc. Well, there is no text "upstream" (because there isn't an upstream) so this isn't essential. > No upstream, is this okay? Well, there's no upstream to have, this package is really not much more than metadata for packaging consistency > macro use not consistent between %var and %{var} I'll review, though I didn't think there was a problem with %x and %{x} where used for clarity. Thanks again. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 15 22:23:14 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 17:23:14 -0500 Subject: [Bug 181450] Review Request: clamav-exim - Clam AV support files for Exim In-Reply-To: Message-ID: <200602152223.k1FMNEoV010296@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: clamav-exim - Clam AV support files for Exim https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181450 ------- Additional Comments From orion at cora.nwra.com 2006-02-15 17:23 EST ------- (In reply to comment #2) > Thanks very much for the review. I should have mentioned that I knew rpmlint > barfed lots, mostly due to this being a very weird package. Yeah, we'll have to muddle through... :-) > > W: clamav-exim no-documentation > > There are no docs, though maybe I should write a short README. I think that would be good - explicitly stating the license as well as a copy of the GPL. > > E: clamav-exim incoherent-logrotate-file /etc/logrotate.d/clamd.exim > > Is this the filename (i.e. clamd.exim) that it's complaining about? If so, I > know it's not the same as the package but the convention wasn't invented by me > but does make sense. I think you need to use clamd-exim here and elsewhere (init.d). "." usually implies a meaningful suffix. > > E: clamav-exim non-standard-uid /var/run/clamd.exim clamexim > > E: clamav-exim non-standard-gid /var/run/clamd.exim exim > > E: clamav-exim non-standard-dir-perm /var/run/clamd.exim 0750 > > E: clamav-exim non-standard-gid /var/log/clamd.exim exim > > I don't really understand these; the uid/gid/perms are intended and correct. > Yeah, looks like this is what clamav does. > > E: clamav-exim non-root-group-log-file /var/log/clamd.exim exim > > So, clamexim.root then? Howveer, users in the "exim" group might conceivably > want read-access to the logs. Well, others seem to do this too, and seems sensible. > > W: clamav-exim dangerous-command-in-%post chmod > > ^ If you really need a log file, perhaps create in %install? > > I could do. However, this stuff all came from the original spec fragments that > were checked into the clamav package by David Woodhouse (dwmw2 at redhat). Given > that David is more experienced than me I was deferring to his judgement. Any > other thoughts from others would be welcome. Okay, looks like this is what clamav spec does too. > > E: clamav-exim init-script-name-with-dot /etc/rc.d/init.d/clamd.exim > > See above discussion about the clamd.exim convention. Yeah, should be clamd-exim > > E: clamav-exim no-status-entry /etc/rc.d/init.d/clamd.exim > > W: clamav-exim no-reload-entry /etc/rc.d/init.d/clamd.exim > > E: clamav-exim subsys-not-used /etc/rc.d/init.d/clamd.exim > > These are all bogus considering that the init script is essentially just a > pointer to the main clamav one. > > > W: clamav-exim incoherent-init-script-name clamd.exim > > See above discusion about the clamd.exim convention. > > > license (GPL) OK, need text in %doc. > > Well, there is no text "upstream" (because there isn't an upstream) so this > isn't essential. > > > No upstream, is this okay? > > Well, there's no upstream to have, this package is really not much more than > metadata for packaging consistency I'll ask some questions on the list. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From orion at cora.nwra.com Wed Feb 15 22:34:59 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 15 Feb 2006 15:34:59 -0700 Subject: Package with no "upstream" source - clamav-exim Message-ID: <43F3AC93.3070107@cora.nwra.com> I'm reviewing clamav-exim (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181450) This is essentially some wrapper scripts and configuration files for setting up a clamav daemon for exim. So: - Do we need an COPYING file with the GPL license? Or are all the provided Source files assumed to be GPL? - Is a package with no upstream source acceptable? (I would think so, but...) -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From bugzilla at redhat.com Wed Feb 15 22:46:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 17:46:02 -0500 Subject: [Bug 180164] Review Request: muine In-Reply-To: Message-ID: <200602152246.k1FMk20X015411@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: muine https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180164 katzj at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katzj at redhat.com ------- Additional Comments From katzj at redhat.com 2006-02-15 17:45 EST ------- Hmm, at this point, gstreamer08 is no longer included in Core and hasn't yet been imported into Extras. Checking upstream, there's not yet a release that builds against gstreamer-0.10, although the support is in SVN. Other preliminary thoughts * Why package the trayicon and dashboard support separately? They're not going to be big and people will probably expect the trayicon at least to just work if they install the package * Does it make sense to include the dashboard plugin when dashboard isn't shipped anywhere yet? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 15 22:56:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 17:56:53 -0500 Subject: [Bug 178900] Review Request: monodoc In-Reply-To: Message-ID: <200602152256.k1FMur5A017474@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: monodoc https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178900 katzj at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katzj at redhat.com ------- Additional Comments From katzj at redhat.com 2006-02-15 17:56 EST ------- Note that the mono packages in Core have everything in %{_libdir} with nothing in /usr/lib without problems. So what exactly is the problem with /usr/lib? It's not clear to me at all from your comments on the wiki, you just say "you have to do it this way" And note that mono on x86_64 is broken with kernels between test2 and something like 1939 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 15 23:03:26 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 18:03:26 -0500 Subject: [Bug 179758] Review Request: Eiciel (ACL editor) In-Reply-To: Message-ID: <200602152303.k1FN3Qq4018567@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Eiciel (ACL editor) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179758 katzj at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katzj at redhat.com ------- Additional Comments From katzj at redhat.com 2006-02-15 18:03 EST ------- The strange objdump stuff is because your %files section includes %{_libdir}/* -- this then picks up the stuff under /usr/lib/debug which should only be in the -debuginfo package. Changing your files section to list things more explicitly should help there. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 15 23:31:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 18:31:27 -0500 Subject: [Bug 177276] Review Request: perl-DBD-AnyData : DBI access to XML, CSV and other formats In-Reply-To: Message-ID: <200602152331.k1FNVRM0023217@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-DBD-AnyData : DBI access to XML, CSV and other formats https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177276 ------- Additional Comments From orion at cora.nwra.com 2006-02-15 18:31 EST ------- - I like long descriptions. Some or all of: The DBD::AnyData module provides a DBI/SQL interface to data in many formats and from many sources. Currently supported formats include general format flatfiles (CSV, Fixed Length, Tab or Pipe "delimited", etc.), specific formats (passwd files, web logs, etc.), a variety of other kinds of formats (XML, Mp3, HTML tables), and, for some operations, any DBI accessible database. The number of supported formats will continue to grow rapidly since there is an open API making it easy for any author to create additional format parsers which can be plugged in to AnyData. Data in these various formats can come from local files, from remote files, or from perl data structures such as strings and arrays. Regardless of the format or source of the data, it may be accessed and/or modified using all standard DBI methods and a subset of SQL syntax. In addition to standard database access to files, the module also supports in-memory tables which allow you to create temporary views; to combine data from a number of sources; to quickly prototype database systems; and to display or save the data in any of the supported formats (e.g. to display data in a CSV file as an HTML table). These in-memory tables can be created from any combination of DBI databases or files of any format. They may also be created from perl data structures which means it's possible to quickly prototype a database system without any file access or rdbms backend. The module also supports converting files between any of the supported formats (e.g. save selected data from MySQL or Oracle to an XML file). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 15 23:41:38 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 18:41:38 -0500 Subject: [Bug 176528] Review Request: MochiKit: A lightweight JavaScript library In-Reply-To: Message-ID: <200602152341.k1FNfcHG025003@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: MochiKit: A lightweight JavaScript library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176528 ivazquez at ivazquez.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From ivazquez at ivazquez.net 2006-02-15 18:41 EST ------- Built under FC4 and devel. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 15 23:50:39 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 18:50:39 -0500 Subject: [Bug 180743] Review Request: pdsh In-Reply-To: Message-ID: <200602152350.k1FNodid026701@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: pdsh https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180743 ------- Additional Comments From woodard at redhat.com 2006-02-15 18:50 EST ------- Jochen, I don't understand what the warning about xinetd means: W: pdsh prereq-use xinetd Yes pdsh needs xinetd. I don't see why that is a warning. What is supposed to be done about it? re: %{?_smp_mflags} that was borrowed long ago from enlightenment and the upstream maintainer and I decided to remove that whole blurb. Working on the rest. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 00:12:41 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 19:12:41 -0500 Subject: [Bug 181534] Review Request: kst - plots scientific data In-Reply-To: Message-ID: <200602160012.k1G0CfBb029873@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kst - plots scientific data https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181534 ------- Additional Comments From matt at truch.net 2006-02-15 19:12 EST ------- (In reply to comment #7) > It builds fine for me on devel with xorg-x11-devel removed. Great. > - Get rid of: > > --disable-debug and CXXFLAGS=-g CFLAGS=-g > > debuginfo packages are created automatically and your mucking with the RPM > optimization flags. Unfortunatly, with kst, if you don't have --disable-debug, then a bunch of 'crap' may be spewed out on stdout and/or stderr when using kst. I don't know how else to disable this 'debugging text output' while keeping the debugging info in the binaries (so debuginfo packages) are useful. > $ rpmlint kst-docs > W: kst-docs dangling-symlink /usr/share/doc/HTML/sv/kst/common > /usr/share/doc/HTML/sv/common > W: kst-docs symlink-should-be-relative /usr/share/doc/HTML/sv/kst/common > /usr/share/doc/HTML/sv/common > W: kst-docs dangling-symlink /usr/share/doc/HTML/et/kst/common > /usr/share/doc/HTML/et/common > W: kst-docs symlink-should-be-relative /usr/share/doc/HTML/et/kst/common > /usr/share/doc/HTML/et/common > W: kst-docs dangling-symlink /usr/share/doc/HTML/en/kst/common > /usr/share/doc/HTML/en/common > W: kst-docs symlink-should-be-relative /usr/share/doc/HTML/en/kst/common > /usr/share/doc/HTML/en/common > W: kst-docs dangling-symlink /usr/share/doc/HTML/fr/kst/common > /usr/share/doc/HTML/fr/common > W: kst-docs symlink-should-be-relative /usr/share/doc/HTML/fr/kst/common > /usr/share/doc/HTML/fr/common > W: kst-docs dangling-symlink /usr/share/doc/HTML/pt/kst/common > /usr/share/doc/HTML/pt/common > W: kst-docs symlink-should-be-relative /usr/share/doc/HTML/pt/kst/common > /usr/share/doc/HTML/pt/common > W: kst-docs dangling-symlink /usr/share/doc/HTML/it/kst/common > /usr/share/doc/HTML/it/common > W: kst-docs symlink-should-be-relative /usr/share/doc/HTML/it/kst/common > /usr/share/doc/HTML/it/common > W: kst-docs dangling-symlink /usr/share/doc/HTML/nl/kst/common > /usr/share/doc/HTML/nl/common > W: kst-docs symlink-should-be-relative /usr/share/doc/HTML/nl/kst/common > /usr/share/doc/HTML/nl/common > W: kst-docs dangling-symlink /usr/share/doc/HTML/da/kst/common > /usr/share/doc/HTML/da/common > W: kst-docs symlink-should-be-relative /usr/share/doc/HTML/da/kst/common > /usr/share/doc/HTML/da/common > > I generally fix with: > > #Fix doc link > ln -sf ../common $RPM_BUILD_ROOT%{_defaultdocdir}/HTML/en/%{name} This only fixes the "symlink-should-be-relative" warning, but doesn't remove the "dangling-symlink" warning. Is that correct? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 00:35:43 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 19:35:43 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602160035.k1G0ZhTp001010@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 jvdias at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |jvdias at redhat.com ------- Additional Comments From jvdias at redhat.com 2006-02-15 19:35 EST ------- I'm currently trying to get the openmpi-1.0.1 into FC-5 (or at least FC Rawhide post FC-5), based on Orion's latest openmpi-1.0.1-3.src.rpm , and with a modified lam to install conflicting files with /usr/sbin/alternatives . Depending on the decision on which FC distro openmpi goes into, we still may need openmpi Extras releases for the other FC distros. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From qspencer at ieee.org Tue Feb 7 17:27:07 2006 From: qspencer at ieee.org (Quentin Spencer) Date: Tue, 07 Feb 2006 11:27:07 -0600 Subject: FE package status Tue Feb 7 2006 In-Reply-To: <200602071718.k17HI7fL011115@ludwig-alpha.unil.ch> References: <200602071718.k17HI7fL011115@ludwig-alpha.unil.ch> Message-ID: <43E8D86B.3020106@ieee.org> Christian.Iseli at licr.org wrote: >We have 58 packages not available in extras devel or release: >GiNaC qspencer > > GiNaC is now renamed to ginac and has been removed from CVS. Is there an official list of discontinued packages that this should be put on? -Quentin From bugzilla at redhat.com Thu Feb 16 01:20:38 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 20:20:38 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602160120.k1G1KcV9006730@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From kevin at tummy.com 2006-02-15 20:20 EST ------- Not a review yet, but some comments: - Make sure to increment your release each time you make changes, even in this pre-accepted state. It helps keep track of what issues were fixed and what changes were made. - Removing the "Requires(hint)" is good (it's not supported by any shipping Fedora rpm (AFAICT). - Not sure what the best solution is to requiring a database backend. Since you must manually setup the database in any case I would think just noting it in the description as you have should be enough. Anyone else have a more clever solution? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 01:45:41 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 20:45:41 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602160145.k1G1jfMZ010771@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From ed at eh3.com 2006-02-15 20:45 EST ------- Hi Jason, is there any chance that you (and the other Red Hat packagers) would consider using environment-modules for side-by-side installs of different MPI implementations? Compared to the alternatives system, environment-modules is far superior. Alternatives does not (and probably never will) gracefully handle situations such as multiple implementations of the same API. For instance, what do you do with the LAM, MPICH, etc. man pages? If you use environment-modules, its very easy to install as many different MPI implimentations (and their corresponding MAN pages, etc.) as you want and then define multiple MPI "modules" (that is, scripts within the environment-modules system) that each set the correct MANPATH and any other values. And I mention man pages only as an example -- the idea readily entends to binaries, libs, headers, what-have-you... Further, the use of environment-modules is a __de facto__ standard. The vast majority of (super-)computing centers, clusters, etc. where MPI is chiefly used also use environment-modules. Its popular at these locations exactly because it works so smoothly. Its a simple, easily understood, extensible, and elegant approach. And it provides end users with maximal flexibility and choice. To the best of my knowledge, not a *single* system on this planet uses alternatives for MPI. Its borderline moronic. Why would you folks want to ignore the hard-won wisdom of an entire field and go with some clunky, inferior alternatives-based approach when you can have something so much better? PS: Orion has very helpfully packaged environment-modules for Extras so its *very* easy for you folks to adopt... [Hint-hint...!] PPS: I'll be glad to discuss this further with anyone who has questions. Feel free to contact me by email, etc. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 02:15:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 21:15:09 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602160215.k1G2F9Et014232@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-15 21:15 EST ------- (In reply to comment #7) > > - Not sure what the best solution is to requiring a database backend. Since you > must manually setup the database in any case I would think just noting it in the > description as you have should be enough. Anyone else have a more clever solution? You could have a "Requires: gallery-database" and then have gallery-mysql and gallery-postgresql submodules (possibly empty, except for maybe some READMEs) that both have "Provide: gallery-database". The submodules would then require php-mysql or pgp-pgsql, which is a more appropriate requirement anyway. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 02:46:19 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 21:46:19 -0500 Subject: [Bug 181404] Review Request: emacs-muse In-Reply-To: Message-ID: <200602160246.k1G2kJPh018414@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 ------- Additional Comments From kevin at tummy.com 2006-02-15 21:46 EST ------- Not a full review yet, but a few comments: - Should name the package 'muse' as thats the name of the upstream source file. - Using %package -n emacs-muse and %package xemacs-muse should allow you to do XEmacs and Emacs packages from this same spec file. You should be able to use a sed command in there to set the EMACS= variable to the right thing. - Don't include the .jgu in Release. :) Will try and look at doing a full review soon. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 03:13:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 22:13:28 -0500 Subject: [Bug 181445] Review Request: php-shout In-Reply-To: Message-ID: <200602160313.k1G3DSEK022381@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-shout https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181445 ------- Additional Comments From holbrookbw at users.sourceforge.net 2006-02-15 22:13 EST ------- I should also mention that this is my first submission, so I need a sponsor / mentor :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 03:24:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 22:24:21 -0500 Subject: [Bug 174325] Review Request: mod_spin Apache module In-Reply-To: Message-ID: <200602160324.k1G3OLZn024620@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mod_spin Apache module https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174325 ------- Additional Comments From bojan at rexursive.com 2006-02-15 22:24 EST ------- Sorry about the delay Mike. I'm not sure when I'll be able to do this - really tight schedule these days... But don't worry, it's not very urgent anyway. Will keep you posted. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 03:36:37 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 22:36:37 -0500 Subject: [Bug 179707] Review Request: dap-server - Basic request handling for DAP servers In-Reply-To: Message-ID: <200602160336.k1G3abQ2027490@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: dap-server - Basic request handling for DAP servers https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179707 ed at eh3.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |ed at eh3.com OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From ed at eh3.com 2006-02-15 22:36 EST ------- Hi Patrice, I've been meaning to look at this so, since today is the first scheduled FE "review day", heres a quick review: good: + source matches upstream + license is correctly included + spec is very legible--no obvious errors + builds on FC4 (not in mock) + rpmlint reports: E: dap-server non-standard-uid /var/cache/dap-server apache E: dap-server non-standard-gid /var/cache/dap-server apache W: dap-server-cgi no-documentation E: dap-server-cgi non-standard-uid \ /etc/httpd/conf.d/opendap_apache.conf apache ...and a few more of the same apache uid/gid errors... which can probably be safely ignored + dir ownership is OK + no shared libs + clean(s) are properly done nits: - License is LGPL not GPL - fails to build with "mock -r fedora-development-i386-core $SRPM" and returns the following error message: make[2]: Entering directory `/builddir/build/BUILD/dap-server-3.5.3' if g++ -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include/libdap -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -MT usage.o -MD -MP -MF ".deps/usage.Tpo" -c -o usage.o usage.cc; \ then mv -f ".deps/usage.Tpo" ".deps/usage.Po"; else rm -f ".deps/usage.Tpo"; exit 1; fi /usr/include/libdap/GNURegex.h:45: error: extra qualification 'Regex::' on member 'init' Do you know whats the matter with devel at the moment? I realize its not a blocker, I'm just curious whats causing the problem -- and don't have a lot of time right now to look at the syntax... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 03:42:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 22:42:15 -0500 Subject: [Bug 179710] Review Request: netcdf_handler - NetCDF 3 data handler for the OPeNDAP Data server In-Reply-To: Message-ID: <200602160342.k1G3gFFj028880@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: netcdf_handler - NetCDF 3 data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179710 ed at eh3.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |ed at eh3.com ------- Additional Comments From ed at eh3.com 2006-02-15 22:42 EST ------- Hi Patrice, I took a quick look at this package and noticed two blockers: - License is LGPL not GPL - The package naming does not follow the packaging guidelines in two ways: 1) the "_" delimiter is not permitted 2) this is an addon package so its name should be "dap-server-netcdf-handler" or similar -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 04:09:12 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 23:09:12 -0500 Subject: [Bug 172755] Review Request: xcompmgr - X11 composite manager In-Reply-To: Message-ID: <200602160409.k1G49CIR001591@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xcompmgr - X11 composite manager https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172755 ------- Additional Comments From dakingun at gmail.com 2006-02-15 23:08 EST ------- Sorry for responding so promptly. i can't really confirm the specific license here, but i daresay it's definitely not GPL, see the last entry in the changelog for that. In keeping with other products (apps, libs, and drivers) available from xorg, I'll say MIT/X11 is okay. Description line in the spec file is fixed and changelog shipped as doc. ftp://czar.eas.yorku.ca/pub/xcompmgr/xcompmgr.spec ftp://czar.eas.yorku.ca/pub/xcompmgr/xcompmgr-1.1.3-2.src.rpm Thanks for doing the review. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 04:56:55 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 15 Feb 2006 23:56:55 -0500 Subject: [Bug 179904] Review Request: icecast In-Reply-To: Message-ID: <200602160456.k1G4utS2009427@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: icecast https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179904 ------- Additional Comments From holbrookbw at users.sourceforge.net 2006-02-15 23:56 EST ------- [[ This review is only for icecast. ices will be considered later pending the upgrade of libshout to 2.x ]] I assume you know why you specified: BuildRequires: automake16 ...but it's not obvious Now onto the checklist... rpmlint's only complaint: W: icecast strange-permission icecast.init 0755 But init scripts need to be executable, so rpmlint is retarded naming guidelines: OK name matches base package: OK specfile matches base package: OK packaging guidelines: OK GPL License: OK COPYING file matches (and included in %doc): OK legible: OK md5: OK 2d80a249fa8529f82d018c6216108ea8 SOURCES/icecast-2.3.1.tar.gz 2d80a249fa8529f82d018c6216108ea8 icecast-2.3.1.tar.gz successful build: i386=OK ppc=OK x64=UNKNOWN ( Nothing to try it on :-/ ) BuildRequires: OK ownership/permissions: OK no duplicate %files: OK %clean: OK consistent macros: OK IMO, APPROVED! -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From ed at eh3.com Thu Feb 16 05:02:21 2006 From: ed at eh3.com (Ed Hill) Date: Thu, 16 Feb 2006 00:02:21 -0500 Subject: Packaging review guidelines clarification Message-ID: <1140066142.3004.297.camel@ernie> Hi folks, I'm reviewing a package that builds on FC4 but not on devel due to recent GCC issues. According to http://fedoraproject.org/wiki/Packaging/ReviewGuidelines : "MUST: The package must successfully compile and build into binary rpms on at least one supported architecture." but, unfortunately, this says nothing about *which* version(s) of FC should be used. I think "one supported architecture on either FC-current or FC-devel" would be appropriate but thats just my opinion. And I could appreciate the reasoning behind "must build on FC-devel" since its where all FE packages are initially imported. So would someone (Spot?) please clarify? 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 bugzilla at redhat.com Thu Feb 16 05:00:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 00:00:59 -0500 Subject: [Bug 172755] Review Request: xcompmgr - X11 composite manager In-Reply-To: Message-ID: <200602160500.k1G50xnj009993@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xcompmgr - X11 composite manager https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172755 ------- Additional Comments From kevin at tummy.com 2006-02-16 00:00 EST ------- ok, I did some searching around. It appears the license is really a SGI/STL license ( something like: http://www.mcda.org/help/stl.html ). >From what I could gather this is a very close variant of the MIT license, so it should be ok to ship. Note that rpmlint only has "MIT" as a valid license, not MIT/X11. I would say change the License to just MIT and then it's APPROVED. Thanks for your patience. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 05:15:05 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 00:15:05 -0500 Subject: [Bug 172755] Review Request: xcompmgr - X11 composite manager In-Reply-To: Message-ID: <200602160515.k1G5F5qC012004@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xcompmgr - X11 composite manager https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172755 ------- Additional Comments From wart at kobold.org 2006-02-16 00:14 EST ------- (In reply to comment #11) > ok, I did some searching around. It appears the license is really a SGI/STL > license ( something like: http://www.mcda.org/help/stl.html ). > > From what I could gather this is a very close variant of the MIT license, > so it should be ok to ship. > > Note that rpmlint only has "MIT" as a valid license, not MIT/X11. > > I would say change the License to just MIT and then it's APPROVED. I disagree. IMHO, I don't think we should be changing license tags just to silence rpmlint warnings. If rpmlint warns about it then make a note of it in the spec file, file a bug with rpmlint, and live with the warning. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 05:21:29 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 00:21:29 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602160521.k1G5LTpE013036@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From orion at cora.nwra.com 2006-02-16 00:21 EST ------- I have to second Ed's comments. I tried to shoe horn lam, mpich, and openmpi into an alternatives style system and it just doesn't fit. I might be acceptable to use it for binaries and have, for example: /usr/bin/mpif77.{name} /usr/bin/mpirun.{name} ... with alternatives for those, but not for anything else. Everything else should be in: /usr/include/{name} /usr/lib/{name} /usr/share/{name}/man ... with environment-modules files to select. There are still unresolved issues though: - Do we still want a default implementation accessible with no configuration by the user? If so, how to update /etc/ld.so.conf.d/ to point to the various libraries, or do we instead load a particular module (how?). - Can we guarantee that different mpi programs get the proper set of libraries when started remotely? - Others? Ed - do most places get around the library issues by linking statically? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 05:27:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 00:27:48 -0500 Subject: [Bug 172755] Review Request: xcompmgr - X11 composite manager In-Reply-To: Message-ID: <200602160527.k1G5RmQD014069@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xcompmgr - X11 composite manager https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172755 ------- Additional Comments From kevin at tummy.com 2006-02-16 00:27 EST ------- The License is very close to the MIT license. It's even closer to the STL license. However, it's not exactly either of them as it has the name of the author in some places. Best I suppose would be to make the License field "STL" as thats what it's closest to, and file a RFE against rpmlint to add that license. I think rpmlint only recognizes the MIT tag as thats what OSI calls the MIT/X11 license. gnu.org calls it only the X11 license and says "This license is sometimes called the "MIT" license, but that term is misleading, since MIT has used many licenses for software." I guess I do see a number of packages using X11/MIT, so I guess rpmlint should recognize either of the forms of this same license (X11, MIT/X11, MIT). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From buildsys at fedoraproject.org Thu Feb 16 05:38:23 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 16 Feb 2006 00:38:23 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060216053823.0B9297FD1@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 2 nagios-2.0-0.6.rc2.fc3 quilt-0.44-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu Feb 16 05:38:36 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 16 Feb 2006 00:38:36 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060216053836.5E0397FD1@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 11 MochiKit-1.2-1.fc4 atlas-3.6.0-9.fc4 nagios-2.0-0.6.rc2.fc4 nazghul-0.5.3-4.fc4 pth-2.0.6-1.fc4 python-setuptools-0.6a10-1.fc4 quilt-0.44-1.fc4 repoview-0.5.1-1.fc4 sblim-cmpi-devel-1.0.4-1.fc4 sblim-testsuite-1.2.4-1.fc4 sblim-wbemcli-1.5.1-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu Feb 16 05:40:07 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 16 Feb 2006 00:40:07 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060216054007.BFB6A7FD1@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 53 MochiKit-1.2-1.fc5 azureus-2.4.0.0-0.20060209cvs_1.fc5 bazaar-1.4.2-6.fc5 cabextract-1.1-4.fc5 cd-discid-0.9-5.fc5 cvsps-2.1-3.fc5 ez-ipupdate-3.0.11-0.9.b8.fc5 feh-1.3.4-3.fc5 freedroid-1.0.2-4.fc5 gaim-meanwhile-1.2.8-2.fc5 gkrellm-volume-2.1.13-3.fc5 gkrellm-weather-2.0.7-2.fc5 glpk-4.9-2.fc5 gnome-applet-sensors-1.6-3.fc5 gobby-0.3.0-4.fc5 graphviz-2.6-4.fc5 jabberd-2.0-0.s10.9.fc5 ksensors-0.7.3-5.fc5 libsidplay-1.36.57-10.fc5 libstatgrab-0.12-1.fc5 lincvs-1.4.4-1.fc5 link-grammar-4.1.3-4.fc5 moodss-21.0-2.fc5 moomps-5.4-2.fc5 nagios-2.0-0.6.rc2.fc5 nethack-3.4.3-9.fc5 obby-0.3.0-3.fc5 octave-2.9.4-7.fc5 opensc-0.10.1-2.fc5 perl-Config-IniFiles-2.39-4.fc5 perl-Data-Buffer-0.04-2.fc5 perl-Digest-BubbleBabble-0.01-3.fc5 perl-Digest-MD2-2.03-2.fc5 perl-ExtUtils-CBuilder-0.15-2.fc5 perl-ExtUtils-Depends-0.205-4.fc5 perl-ExtUtils-ParseXS-2.15-2.fc5 perl-Pod-Simple-3.04-2.fc5 pork-0.99.8.1-5.fc5 pth-2.0.6-1.fc5 python-dateutil-1.1-2.fc5 python-irclib-0.4.5-2.fc5 python-setuptools-0.6a10-1.fc5 quilt-0.44-1.fc5 repoview-0.5.1-1.fc5 revelation-0.4.7-3.fc5 sobby-0.3.0-2.fc5 ufsparse-0.93-2.fc5 upx-1.25-5.fc5 uqm-0.5.0-1.fc5 uqm-content-0.5.0-1 xboard-4.2.7-12.fc5 xdaliclock-2.23-2.fc5 xprobe2-0.3-5.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Thu Feb 16 05:41:22 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 00:41:22 -0500 Subject: [Bug 179439] Review Request: linux-libertine-fonts - TrueType serif fonts In-Reply-To: Message-ID: <200602160541.k1G5fMjh016539@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: linux-libertine-fonts - TrueType serif fonts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179439 kevin at tummy.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|gdk at redhat.com |kevin at tummy.com OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From kevin at tummy.com 2006-02-16 00:41 EST ------- Greetings, heres a review: MUST items: OK - licence ok (GPL). OK - no rpmlint output OK - package name good. OK - spec file matches. OK - spec in english. OK - spec legible. OK - md5sum matches: be31789d2bcb0d01f1755491d28d72a3 LinLibertineSRC.tgz be31789d2bcb0d01f1755491d28d72a3 LinLibertineSRC.tgz.1 OK - compiles and builds under devel. OK - files and dirs ok. OK - clean section good. OK - macros good. OK - builds ok in mock on devel. As far as the name goes, that bug refered to in comment #7 says (in part): "For example Debian uses ttf-fontname for the package names. Fedora so far uses fontname-fonts. However, this is a very minor issue, which could go either way. Since it is not a policy it is up to you to decide the package name." It might be good to post to fedora-extras-list and ask for some thoughts on font package naming? That should be added to the wiki on http://fedoraproject.org/wiki/Packaging/NamingGuidelines once it's decided. Nice looking fonts BTW. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 05:46:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 00:46:09 -0500 Subject: [Bug 177270] Review Request: libresample - A real-time library for audio sampling rate conversion In-Reply-To: Message-ID: <200602160546.k1G5k9px017152@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libresample - A real-time library for audio sampling rate conversion https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177270 ------- Additional Comments From holbrookbw at users.sourceforge.net 2006-02-16 00:45 EST ------- (This goes along with Packaging Guidelines) Your %description is a copy-and-paste of Summary, very brief... Anything else you can say in Description? rpmlint: OK naming guidelines: OK NOTE: FE caveats use "Release: 1%{?dist}" instead of just "Release: 1" name matches base package: OK specfile matches base package: OK Note: your .spec file in the SRPM is named correctly, but the one you linked here "libresample-0.1.3-1.spec" is not packaging guidelines: OK LGPL License: OK LICENCE.txt file matches (and included in %doc): OK Might consider renaming to "COPYING" and dropping the ".txt" off of "README.txt" legible: OK md5: OK 99bc5ea15ef76b83e5655a10968f674b SOURCES/libresample-0.1.3.tgz 99bc5ea15ef76b83e5655a10968f674b libresample-0.1.3.tgz successful build: i386=OK ppc=OK x64=UNKNOWN ( Nothing to try it on :-/ ) BuildRequires: NONE ldconfig: OK ownership/permissions: OK no duplicate %files: OK %clean: OK consistent macros: OK libraries in -devel package: OK NOTE: -devel does NOT require the base package, because there is no base package :) No blocking issues, APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 05:53:42 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 00:53:42 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602160553.k1G5rggj018033@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From ed at eh3.com 2006-02-16 00:53 EST ------- Hi Orion, most environment-module scripts that I've seen use syntax such as: prepend-path PATH $SOMEPACKAGE_HOME/bin prepend-path MANPATH $SOMEPACKAGE_HOME/man prepend-path LD_LIBRARY_PATH $SOMEPACKAGE_HOME/lib ...etc... which takes care of the binaries, libs, headers, etc. And, if the Core packagers choose to avoid environment-modules and select one particular MPI implimentation as the "standard" for Core, thats still perfectly OK. The "standard" or "preferred" MPI implimentation can be installed exactly as LAM is currently installed and then environment- modules can be used in conjunction with any other MPI implimentatons (say, multiple one within Fedora Extras) per the above. I know this works because many folks do this on their clustersand/or networks of workstations. For instance, we have the Core-supplied LAM installed and we have $N$ other MPI implementations installed and they all work. And users are free to *dynamically* select (whenever they want) which MPI bits they'd like to use for a particular task with either environment- modules (which is, ultimately, just a convenience) or by manually selecting the desireed paths for builds, execution, etc. Its that easy! And it doesn't require any nasty static linking or other ugly hacks. Its very clean. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 06:54:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 01:54:34 -0500 Subject: [Bug 180743] Review Request: pdsh In-Reply-To: Message-ID: <200602160654.k1G6sYX7026055@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: pdsh https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180743 ------- Additional Comments From ville.skytta at iki.fi 2006-02-16 01:54 EST ------- (In reply to comment #3) > W: pdsh prereq-use xinetd > > Yes pdsh needs xinetd. I don't see why that is a warning. What is supposed to > be done about it? Use rpmlint -i to get an explanation. PreReq is deprecated; in this case it sounds (without looking at the package) like it could be replaced by plain Requires. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 07:06:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 02:06:48 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602160706.k1G76mdE027513@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From andreas at bawue.net 2006-02-16 02:06 EST ------- Jeff? I haven't heard back from Peter yet. Shall we go ahead and do a review of the package as is? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 07:12:40 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 02:12:40 -0500 Subject: [Bug 178900] Review Request: monodoc In-Reply-To: Message-ID: <200602160712.k1G7CeEF028202@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: monodoc https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178900 ------- Additional Comments From paul at all-the-johnsons.co.uk 2006-02-16 02:12 EST ------- When I installed mono on my x86_64 boxes, everything defaulted to /usr/lib, hense the warning. There isn't a problem (as such) with 64 bit stuff going into /usr/lib. I was under the impression though that anything 64 bit should really go in /usr/lib64 until such time that use of 64 bit was far more widespread. I kind of assumed there was a problem with the 64 bit version between test2 and some of the newer kernels due to the find file bug (or whatever it was called). However, even on kernel 1948 there is a problem with compilation (try compiling gtksourceview-sharp and you'll see what I mean (it complains that /usr/lib64/pkgconfig/../../share/gapi-2.0/gnome-api.xml doesn't exist when it does - this could be down to a configure problem but the file does exist on my machines). Thanks for the comments -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 07:34:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 02:34:13 -0500 Subject: [Bug 179904] Review Request: icecast In-Reply-To: Message-ID: <200602160734.k1G7YD5c031612@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: icecast https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179904 andreas at bawue.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From andreas at bawue.net 2006-02-16 02:34 EST ------- Thanks for the review. I removed the Require for automake16. That was needed back when the package had to be built from CVS, as no release existed and automake had to run first. At that time, automake 1.6 was needed to successfully create the autoconf scripts. As that's not needed anymore, the dependency is moot. Thx for spotting that. ;) Closing bug, icecast is uploaded and sucessfully built. FYI: It does build on x86. ;) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 07:46:54 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 02:46:54 -0500 Subject: [Bug 181753] New: Review Request: mm - Shared memory allocation library Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181753 Summary: Review Request: mm - Shared memory allocation library Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: andreas at bawue.net QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://helena.bawue.de/~ixs/mm/mm.spec SRPM Name or Url: http://helena.bawue.de/~ixs/mm/mm-1.4.0-1.src.rpm Description: OSSP mm is a 2-layer abstraction library which simplifies the usage of shared memory between forked (and this way strongly related) processes under Unix platforms. On the first layer it hides all platform dependent implementation details (allocation and locking) when dealing with shared memory segments and on the second layer it provides a high-level malloc(3)-style API for a convenient and well known way to work with data structures inside those shared memory segments. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 07:50:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 02:50:16 -0500 Subject: [Bug 179439] Review Request: linux-libertine-fonts - TrueType serif fonts In-Reply-To: Message-ID: <200602160750.k1G7oGBL001293@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: linux-libertine-fonts - TrueType serif fonts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179439 ------- Additional Comments From frank at scirocco-5v-turbo.de 2006-02-16 02:50 EST ------- Thank you for the review. /me sees one NOT OK - it's not the latest release. So let's fix it... Spec: http://www.scirocco-5v-turbo.de/fedora/font-linux-libertine.spec SRPM: http://www.scirocco-5v-turbo.de/fedora/font-linux-libertine-2.0.4-1.src.rpm Changelog: * Wed Feb 13 2006 Frank Arnold 2.0.4-1 - Updated to 2.0.4 - Removed handling of fonts.cache-2 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 07:50:37 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 02:50:37 -0500 Subject: [Bug 179904] Review Request: icecast In-Reply-To: Message-ID: <200602160750.k1G7obvC001333@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: icecast https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179904 ------- Additional Comments From paul at city-fan.org 2006-02-16 02:50 EST ------- (In reply to comment #4) > rpmlint's only complaint: > W: icecast strange-permission icecast.init 0755 > > But init scripts need to be executable, so rpmlint is retarded Actually it's not retarded. It's complaining about the permissions of icecast.init in the SRPM, and it doesn't need to be executable there because the initscript is installed with the correct permissions regardless of the permissions in the SRPM: install -D -m 755 %{SOURCE2} %{buildroot}%{_initrddir}/icecast -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 07:55:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 02:55:50 -0500 Subject: [Bug 181444] Review Request: lcov -- process gcov output into nice html pages In-Reply-To: Message-ID: <200602160755.k1G7toxv001966@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: lcov -- process gcov output into nice html pages https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181444 ------- Additional Comments From dan at danny.cz 2006-02-16 02:55 EST ------- The file for Source0 at URL http://ltp.sourceforge.net/coverage/tools/lcov-%{version}.tar.gz doesn't exist, use http://dl.sf.net/ltp/lcov-%{version}.tar.gz instead. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 07:57:00 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 02:57:00 -0500 Subject: [Bug 179904] Review Request: icecast In-Reply-To: Message-ID: <200602160757.k1G7v0UK002164@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: icecast https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179904 paul at city-fan.org changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From paul at city-fan.org 2006-02-16 02:56 EST ------- (In reply to comment #4) > IMO, APPROVED! Please change the blocker bug from FE-NEW or FE-REVIEW to FE-ACCEPT when approving a package. Otherwise you'll get a special mention at http://fedoraproject.org/wiki/Extras/PackageStatus ;-) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 07:58:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 02:58:28 -0500 Subject: [Bug 179707] Review Request: dap-server - Basic request handling for DAP servers In-Reply-To: Message-ID: <200602160758.k1G7wSLF002405@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: dap-server - Basic request handling for DAP servers https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179707 ------- Additional Comments From pertusus at free.fr 2006-02-16 02:58 EST ------- It is certainly a non conformant construct revealed by the newer gcc. It is in fact in the libdap package and I have reported it upstream. (and the libdap package cannot be rebuilt in devel). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 08:18:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 03:18:20 -0500 Subject: [Bug 179710] Review Request: netcdf_handler - NetCDF 3 data handler for the OPeNDAP Data server In-Reply-To: Message-ID: <200602160818.k1G8IKDQ005730@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: netcdf_handler - NetCDF 3 data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179710 ------- Additional Comments From pertusus at free.fr 2006-02-16 03:18 EST ------- There is an exception when there is a _ in the upstream name: "packages where the upstream name naturally contains an underscore are excluded from this." But I agree that there should be dap somewhere in the name. After some thinking, I am not convinced anymore that the handlers should depend on dap-server. Although it is unlikely, they could be used as stand alone apps, so I propose removing dependency on dap-server and calling the handler dap-netcdf_handler and so on, to retain the upstream _ but have a more informative name. Would this suit you? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From frank at scirocco-5v-turbo.de Thu Feb 16 08:26:08 2006 From: frank at scirocco-5v-turbo.de (Frank Arnold) Date: Thu, 16 Feb 2006 09:26:08 +0100 Subject: Naming of font packages Message-ID: <1140078368.19816.28.camel@localhost> Hi, I need some opinions about the naming of font packages, and finally a decision. At the moment all font packages in Fedora are named FONTNAME-fonts. Ignacio suggested a change to font-FONTNAME. Debian obviously uses ttf-FONTNAME. For me it makes sense to have a prefix instead of a suffix. Lookup for different fonts in a sorted package list would be much easier. But this would mean a renaming of all existing font packages in Core and Extras. So what to do? Link to my review request: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179439 TIA, Frank From fedora at camperquake.de Thu Feb 16 08:31:26 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 16 Feb 2006 09:31:26 +0100 Subject: Naming of font packages In-Reply-To: <1140078368.19816.28.camel@localhost> References: <1140078368.19816.28.camel@localhost> Message-ID: <20060216093126.4d8f0f88@dhcp05.addix.net> Hi. On Thu, 16 Feb 2006 09:26:08 +0100, Frank Arnold wrote: > At the moment all font packages in Fedora are named FONTNAME-fonts. Most font packages are called fonts- in Core. There are others which do not follow this, though. From nicolas.mailhot at laposte.net Thu Feb 16 08:45:27 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 16 Feb 2006 09:45:27 +0100 (CET) Subject: Naming of font packages In-Reply-To: <1140078368.19816.28.camel@localhost> References: <1140078368.19816.28.camel@localhost> Message-ID: <51498.192.54.193.35.1140079527.squirrel@rousalka.dyndns.org> Le Jeu 16 f?vrier 2006 09:26, Frank Arnold a ?crit : > Hi, > > I need some opinions about the naming of font packages, and finally a > decision. > > At the moment all font packages in Fedora are named FONTNAME-fonts. > Ignacio suggested a change to font-FONTNAME. Debian obviously uses > ttf-FONTNAME. > For me it makes sense to have a prefix instead of a suffix. Lookup for > different fonts in a sorted package list would be much easier. But this > would mean a renaming of all existing font packages in Core and Extras. > > So what to do? Live and let live. There are good arguments on boths sides, and renaming one way or the other is not worth the pain. -- Nicolas Mailhot From bugzilla at redhat.com Thu Feb 16 09:05:42 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 04:05:42 -0500 Subject: [Bug 176373] Review Request: ytalk In-Reply-To: Message-ID: <200602160905.k1G95g5b016534@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ytalk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176373 imlinux at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From imlinux at gmail.com 2006-02-16 04:05 EST ------- I've added the doc's. Thanks for the review. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 09:35:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 04:35:49 -0500 Subject: [Bug 179707] Review Request: dap-server - Basic request handling for DAP servers In-Reply-To: Message-ID: <200602160935.k1G9ZnZq022390@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: dap-server - Basic request handling for DAP servers https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179707 ------- Additional Comments From jamatos at fc.up.pt 2006-02-16 04:35 EST ------- (In reply to comment #1) > Do you know whats the matter with devel at the moment? I realize its > not a blocker, I'm just curious whats causing the problem -- and don't > have a lot of time right now to look at the syntax... See https://www.redhat.com/archives/fedora-test-list/2005-December/msg00382.html for an explanation of the problem, as Patrice tells this is a problem of the code and the fix is simple, remove the offending code. :-) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From mmcgrath at fedoraproject.org Thu Feb 16 10:16:12 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 16 Feb 2006 04:16:12 -0600 Subject: Packaging review guidelines clarification In-Reply-To: <1140066142.3004.297.camel@ernie> References: <1140066142.3004.297.camel@ernie> Message-ID: <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> > > Hi folks, > > I'm reviewing a package that builds on FC4 but not on devel due to > recent GCC issues. According to > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines : > > "MUST: The package must successfully compile and build into > binary rpms on at least one supported architecture." > > but, unfortunately, this says nothing about *which* version(s) of FC > should be used. I think "one supported architecture on either > FC-current or FC-devel" would be appropriate but thats just my opinion. > And I could appreciate the reasoning behind "must build on FC-devel" > since its where all FE packages are initially imported. So would > someone (Spot?) please clarify? > > Ed > I've always used "a current supported version of Fedora Core" as a rule of thumb. I also treat the should build on mock as a must build on mock unless the contributor can provide a good reason as to why it won't build on mock. -Mike From wart at kobold.org Thu Feb 16 10:20:03 2006 From: wart at kobold.org (Michael Thomas) Date: Thu, 16 Feb 2006 15:50:03 +0530 Subject: Packaging review guidelines clarification In-Reply-To: <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> Message-ID: <43F451D3.3080503@kobold.org> Mike McGrath wrote: >>Hi folks, >> >>I'm reviewing a package that builds on FC4 but not on devel due to >>recent GCC issues. According to >>http://fedoraproject.org/wiki/Packaging/ReviewGuidelines : >> >> "MUST: The package must successfully compile and build into >> binary rpms on at least one supported architecture." >> >>but, unfortunately, this says nothing about *which* version(s) of FC >>should be used. I think "one supported architecture on either >>FC-current or FC-devel" would be appropriate but thats just my opinion. >>And I could appreciate the reasoning behind "must build on FC-devel" >>since its where all FE packages are initially imported. So would >>someone (Spot?) please clarify? >> >>Ed >> > > > I've always used "a current supported version of Fedora Core" as a > rule of thumb. I also treat the should build on mock as a must build > on mock unless the contributor can provide a good reason as to why it > won't build on mock. +1 I also think that the version and arch which was used in the review should be clearly noted, as well as any disclaimers about known build failures or non-attempts on other versions/arches. --Mike From paul at city-fan.org Thu Feb 16 10:29:15 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 16 Feb 2006 10:29:15 +0000 Subject: Packaging review guidelines clarification In-Reply-To: <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> Message-ID: <1140085756.8444.14.camel@laurel.intra.city-fan.org> On Thu, 2006-02-16 at 04:16 -0600, Mike McGrath wrote: > > > > Hi folks, > > > > I'm reviewing a package that builds on FC4 but not on devel due to > > recent GCC issues. According to > > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines : > > > > "MUST: The package must successfully compile and build into > > binary rpms on at least one supported architecture." > > > > but, unfortunately, this says nothing about *which* version(s) of FC > > should be used. I think "one supported architecture on either > > FC-current or FC-devel" would be appropriate but thats just my opinion. > > And I could appreciate the reasoning behind "must build on FC-devel" > > since its where all FE packages are initially imported. So would > > someone (Spot?) please clarify? > > > > Ed > > > > I've always used "a current supported version of Fedora Core" as a > rule of thumb. I also treat the should build on mock as a must build > on mock unless the contributor can provide a good reason as to why it > won't build on mock. I think a failure to build in mock is a blocker, unless the reason is either a deficiency in mock (in which case there should be a reference to the bugzilla ticket for the issue raised on mock), or a dependency not available in Core or Extras yet (which can easily be worked around by adding a local repo containing the missing dependency to the reviewer's mock configuration). Remember that the build system uses mock, so if it won't build in mock, it won't get built for Extras at all. Paul. From bugzilla at redhat.com Thu Feb 16 10:29:46 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 05:29:46 -0500 Subject: [Bug 179707] Review Request: dap-server - Basic request handling for DAP servers In-Reply-To: Message-ID: <200602161029.k1GATkgJ031246@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: dap-server - Basic request handling for DAP servers https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179707 ------- Additional Comments From pertusus at free.fr 2006-02-16 05:29 EST ------- This is fixed in upstream libdap svn. It also seems that a new libdap version is on tracks. I'll update libdap as soon as it is out and this should build in devel then. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 10:32:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 05:32:07 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602161032.k1GAW7Vs031829@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From alanr at unix.sh 2006-02-16 05:32 EST ------- The reasons for having the pils package separate is that this is a general purpose library - usable without heartbeat. The same is true of the stonith libraries. Indeed, Red Hat has historically used these same packages in some of their products. We probably need to re-do some of these subpackages, but being compatible with how the project distributes them is also helpful. (i.e., if it's a mistake, at least it's a consistent mistake). The project distributes everything as RPMs, so having the RH RPMs consistent with the other RPMs we distribute has some value, IMHO... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 10:36:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 05:36:08 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602161036.k1GAa8rf032251@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From alanr at unix.sh 2006-02-16 05:36 EST ------- AFAIK, we do indeed use SWIG, and python-gtk, but I don't know about the version issues, but I suspect they?re there for a reason. I'm sure he's just copying what Huang Zhen (the developer of this code) put in the project's RPM. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 12:04:42 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 07:04:42 -0500 Subject: [Bug 181445] Review Request: php-shout In-Reply-To: Message-ID: <200602161204.k1GC4gj4012846@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-shout https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181445 ------- Additional Comments From dmitry at butskoy.name 2006-02-16 07:04 EST ------- Just some remarks: - it is better to do "phpize --clean; phpize" anyway, as it adjust the source to the appropriate php-devel build system (4.3, or 5.0, or 5.1 etc...) - Specifying "requires: libshout >= 2.0.0" is extra, as "BR: libshout-devel >= 2.0.0" is already present, which cause to build with and autodepend by the needed library version. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From mmcgrath at fedoraproject.org Thu Feb 16 12:20:35 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 16 Feb 2006 06:20:35 -0600 Subject: Packaging review guidelines clarification In-Reply-To: <1140085756.8444.14.camel@laurel.intra.city-fan.org> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> <1140085756.8444.14.camel@laurel.intra.city-fan.org> Message-ID: <3237e4410602160420t7c8ffc8fta0546df263bd2661@mail.gmail.com> > I think a failure to build in mock is a blocker, unless the reason is > either a deficiency in mock (in which case there should be a reference > to the bugzilla ticket for the issue raised on mock), or a dependency > not available in Core or Extras yet (which can easily be worked around > by adding a local repo containing the missing dependency to the > reviewer's mock configuration). > > Remember that the build system uses mock, so if it won't build in mock, > it won't get built for Extras at all. > > Paul. I'm all for it, should we move 'should build on mock' to 'must build on mock' in the wiki? -Mike From vijaya.krishnan at wipro.com Thu Feb 16 12:46:23 2006 From: vijaya.krishnan at wipro.com (vijaya.krishnan at wipro.com) Date: Thu, 16 Feb 2006 18:16:23 +0530 Subject: Kernel debugging Message-ID: <5CD91656651C314194F28DFB1116ED89BDFC6C@blr-m2-msg.wipro.com> Hi, currently i am working with Fedora core 4. kernel 2.6.11-1.1369_FC4-i686. I wanted to have kernel debugging with kdb. But i couldnt find the patch for it. Could someone help me find the location and how to apply the patch and make my kernel support kernel debugging. Thanks & Regards, Vijay. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla at redhat.com Thu Feb 16 14:00:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 09:00:30 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602161400.k1GE0U7F001359@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-16 09:00 EST ------- (In reply to comment #15) > Jeff? I haven't heard back from Peter yet. Shall we go ahead and do a review of > the package as is? I'll try and do the full review sometime today, but it might be this evening before I can get to it. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From paul at city-fan.org Thu Feb 16 14:08:29 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 16 Feb 2006 14:08:29 +0000 Subject: Packaging review guidelines clarification In-Reply-To: <3237e4410602160420t7c8ffc8fta0546df263bd2661@mail.gmail.com> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> <1140085756.8444.14.camel@laurel.intra.city-fan.org> <3237e4410602160420t7c8ffc8fta0546df263bd2661@mail.gmail.com> Message-ID: <1140098910.8444.21.camel@laurel.intra.city-fan.org> On Thu, 2006-02-16 at 06:20 -0600, Mike McGrath wrote: > > I think a failure to build in mock is a blocker, unless the reason is > > either a deficiency in mock (in which case there should be a reference > > to the bugzilla ticket for the issue raised on mock), or a dependency > > not available in Core or Extras yet (which can easily be worked around > > by adding a local repo containing the missing dependency to the > > reviewer's mock configuration). > > > > Remember that the build system uses mock, so if it won't build in mock, > > it won't get built for Extras at all. > > > > Paul. > > I'm all for it, should we move 'should build on mock' to 'must build > on mock' in the wiki? The problem with that is that not every reviewer has the bandwidth to support a mock build environment (particularly for development), so it's probably left as a "should", but a failure being a blocker. Paul. From bugzilla at redhat.com Thu Feb 16 14:32:58 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 09:32:58 -0500 Subject: [Bug 179904] Review Request: icecast In-Reply-To: Message-ID: <200602161432.k1GEWwM6008456@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: icecast https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179904 ------- Additional Comments From holbrookbw at users.sourceforge.net 2006-02-16 09:32 EST ------- I'll be sure to do that in the future: #1 - This was my first review, so the "APPROVED" was more of a personal suggestion than a final approval, and I didn't know if a plain-ol' reviewer could change it to accept or if a sponsor had to do that #2 - I assumed I didn't have the appropriate bugzilla permissions -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 14:44:12 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 09:44:12 -0500 Subject: [Bug 179904] Review Request: icecast In-Reply-To: Message-ID: <200602161444.k1GEiCSs010935@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: icecast https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179904 ------- Additional Comments From andreas at bawue.net 2006-02-16 09:44 EST ------- (In reply to comment #8) > #1 - This was my first review, so the "APPROVED" was more of a personal > suggestion than a final approval, and I didn't know if a plain-ol' reviewer > could change it to accept or if a sponsor had to do that Whoapsi. The review guidelines at http://fedoraproject.org/wiki/Packaging/ReviewGuidelines state: "A Reviewer is defined as the person who chooses to review a package. For the sake of clarity, one person takes ownership of the review. Other people are encouraged to comment on the review as well, either in the bug or on the mailing list. The primary Reviewer can be any current package owner, unless the Contributor is a first timer." Thus in general, any FE-contributor can review packages. > #2 - I assumed I didn't have the appropriate bugzilla permissions You do not need special permissions for that. It's just a regular tracker, everyone can change that. regards, andreas -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From Jochen at herr-schmitt.de Thu Feb 16 14:52:06 2006 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 16 Feb 2006 15:52:06 +0100 Subject: Package with no "upstream" source - clamav-exim In-Reply-To: <43F3AC93.3070107@cora.nwra.com> References: <43F3AC93.3070107@cora.nwra.com> Message-ID: <0MKwh2-1F9kVF1PTs-0000WV@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 15 Feb 2006 15:34:59 -0700, you wrote: >I'm reviewing clamav-exim >(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181450) > >This is essentially some wrapper scripts and configuration files for >setting up a clamav daemon for exim. So: > >- Do we need an COPYING file with the GPL license? Or are all the >provided Source files assumed to be GPL? > >- Is a package with no upstream source acceptable? (I would think so, >but...) - From my point of view you should include a COPYING file with the verbatin GPL to clarify the license terms of the files which are dstribute with your package. I you case you are the packager and the upstream author in the same person. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBQ/SRvk9gByurcX4MEQIFTgCg3akN0KP1WE52dsG6whhTmqOn3y4AoJuU zpjsITWMpTCuglUeuBFMnyYX =s7L4 -----END PGP SIGNATURE----- From pmatilai at laiskiainen.org Thu Feb 16 15:02:43 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 16 Feb 2006 07:02:43 -0800 (PST) Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139948390.10711.7.camel@bobcat.mine.nu> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214124313.765c0ca5.bugs.michael@gmx.net> <1139925078.12023.366.camel@mccallum.corsepiu.local> <20060214160016.728239dd.bugs.michael@gmx.net> <1139933804.12023.407.camel@mccallum.corsepiu.local> <604aa7910602140825i50884cbfi201bb2df29246d69@mail.gmail.com> <1139948390.10711.7.camel@bobcat.mine.nu> Message-ID: On Tue, 14 Feb 2006, Ville Skytt? wrote: > On Tue, 2006-02-14 at 11:25 -0500, Jeff Spaleta wrote: > >> the repoquery isn't enough to provide the necessary information to >> learn about dependancy chains to allow for maintainer coordination? > > It's too bad that at the time when repoquery would be most useful, it's > shipped broken in FE5 :(. Pointers how to fix it locally are at > https://bugzilla.redhat.com/175335 What's stopping people from applying the one-liner patch repoquery in the yum-utils FE package if it's considered that important? - Panu - From bugzilla at redhat.com Thu Feb 16 15:00:57 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 10:00:57 -0500 Subject: [Bug 181777] New: Review Request: CCfits A C++ interface for cfitsio (FITS File Subroutine Library) Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181777 Summary: Review Request: CCfits A C++ interface for cfitsio (FITS File Subroutine Library) Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: spr at astrax.fis.ucm.es QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://t-rex.fis.ucm.es/~spr/CCfits.spec SRPM Name or Url: http://t-rex.fis.ucm.es/~spr/CCfits-1.4-0.fc4.src.rpm Description: CCfits is an object oriented interface to the cfitsio library. It is designed to make the capabilities of cfitsio available to programmers working in C++. It is written in ANSI C++ and implemented using the C++ Standard Library with namespaces, exception handling, and member template functions. This is my first request for a review, so I'm also in need of a sponsor. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From pmatilai at laiskiainen.org Thu Feb 16 15:07:14 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 16 Feb 2006 07:07:14 -0800 (PST) Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139936636.30045.25.camel@mccallum.corsepiu.local> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214124313.765c0ca5.bugs.michael@gmx.net> <1139925078.12023.366.camel@mccallum.corsepiu.local> <20060214160016.728239dd.bugs.michael@gmx.net> <1139933804.12023.407.camel@mccallum.corsepiu.local> <604aa7910602140825i50884cbfi201bb2df29246d69@mail.gmail.com> <1139936636.30045.25.camel@mccallum.corsepiu.local> Message-ID: On Tue, 14 Feb 2006, Ralf Corsepius wrote: >> >> the repoquery isn't enough to provide the necessary information to >> learn about dependancy chains to allow for maintainer coordination? > No. > > [Personal side-note: I hate repoquery. Heh, care to elaborate? I'm open to suggestions you know :) > It's way less useable than its apt-get counterparts] What apt-get counterparts? Sure you can dig out quite a bit of information from apt-cache but it has nothing like the formatting capabilities of repoquery etc. - Panu - From rc040203 at freenet.de Thu Feb 16 15:08:22 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 16 Feb 2006 16:08:22 +0100 Subject: Packaging review guidelines clarification In-Reply-To: <1140098910.8444.21.camel@laurel.intra.city-fan.org> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> <1140085756.8444.14.camel@laurel.intra.city-fan.org> <3237e4410602160420t7c8ffc8fta0546df263bd2661@mail.gmail.com> <1140098910.8444.21.camel@laurel.intra.city-fan.org> Message-ID: <1140102502.21764.84.camel@mccallum.corsepiu.local> On Thu, 2006-02-16 at 14:08 +0000, Paul Howarth wrote: > On Thu, 2006-02-16 at 06:20 -0600, Mike McGrath wrote: > > > I think a failure to build in mock is a blocker, unless the reason is > > > either a deficiency in mock (in which case there should be a reference > > > to the bugzilla ticket for the issue raised on mock), or a dependency > > > not available in Core or Extras yet (which can easily be worked around > > > by adding a local repo containing the missing dependency to the > > > reviewer's mock configuration). > > > > > > Remember that the build system uses mock, so if it won't build in mock, > > > it won't get built for Extras at all. > > > > > > Paul. > > > > I'm all for it, should we move 'should build on mock' to 'must build > > on mock' in the wiki? > > The problem with that is that not every reviewer has the bandwidth to > support a mock build environment (particularly for development), Set up a local one, that's what I'm doing ... > so it's > probably left as a "should", but a failure being a blocker. Must be "must", because the buildsys uses mock, so a Review without mock build isn't worth the bandwidth and time it requires. Ralf From paul at city-fan.org Thu Feb 16 15:16:19 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 16 Feb 2006 15:16:19 +0000 Subject: Packaging review guidelines clarification In-Reply-To: <1140102502.21764.84.camel@mccallum.corsepiu.local> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> <1140085756.8444.14.camel@laurel.intra.city-fan.org> <3237e4410602160420t7c8ffc8fta0546df263bd2661@mail.gmail.com> <1140098910.8444.21.camel@laurel.intra.city-fan.org> <1140102502.21764.84.camel@mccallum.corsepiu.local> Message-ID: <1140102979.8444.38.camel@laurel.intra.city-fan.org> On Thu, 2006-02-16 at 16:08 +0100, Ralf Corsepius wrote: > On Thu, 2006-02-16 at 14:08 +0000, Paul Howarth wrote: > > On Thu, 2006-02-16 at 06:20 -0600, Mike McGrath wrote: > > > > I think a failure to build in mock is a blocker, unless the reason is > > > > either a deficiency in mock (in which case there should be a reference > > > > to the bugzilla ticket for the issue raised on mock), or a dependency > > > > not available in Core or Extras yet (which can easily be worked around > > > > by adding a local repo containing the missing dependency to the > > > > reviewer's mock configuration). > > > > > > > > Remember that the build system uses mock, so if it won't build in mock, > > > > it won't get built for Extras at all. > > > > > > > > Paul. > > > > > > I'm all for it, should we move 'should build on mock' to 'must build > > > on mock' in the wiki? > > > > The problem with that is that not every reviewer has the bandwidth to > > support a mock build environment (particularly for development), > Set up a local one, that's what I'm doing ... It's what I do too, but it still needs lots of bandwidth to keep the rawhide and FE development mirrors up to date. > > so it's > > probably left as a "should", but a failure being a blocker. > Must be "must", because the buildsys uses mock, so a Review without mock > build isn't worth the bandwidth and time it requires. It's much more useful to test builds in mock, I agree, but much of what's needed in a review doesn't need mock and I think just about everything *could* be done a different way (e.g. by using things like fedora-rmdevelrpms to check buildreqs). Paul. From jspaleta at gmail.com Thu Feb 16 15:25:28 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 16 Feb 2006 10:25:28 -0500 Subject: Packaging review guidelines clarification In-Reply-To: <1140098910.8444.21.camel@laurel.intra.city-fan.org> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> <1140085756.8444.14.camel@laurel.intra.city-fan.org> <3237e4410602160420t7c8ffc8fta0546df263bd2661@mail.gmail.com> <1140098910.8444.21.camel@laurel.intra.city-fan.org> Message-ID: <604aa7910602160725i66b0ae16s17a643839214e91b@mail.gmail.com> On 2/16/06, Paul Howarth wrote: > The problem with that is that not every reviewer has the bandwidth to > support a mock build environment (particularly for development), so it's > probably left as a "should", but a failure being a blocker. there was a discussion at somepoint about scratch build trees in the buildsystem to help with update builds. Would it be a worthwhile to extend that discussion about the value of enhancing the build system to have scratch areas so reviewers could submit srpms that aren't in cvs yet to spin up rpms using the dedicated buildsystem hardware without having to pull the build environment down locally? I have no idea how much work that would entail.. but its thing I think which would most greatly impact the quality of the review process for binaries. Not having access to all build arches and not having the bandwidth to pull down the development tree are large obstacles to doing quality review builds, at least for me. -jef From rc040203 at freenet.de Thu Feb 16 15:29:23 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 16 Feb 2006 16:29:23 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214124313.765c0ca5.bugs.michael@gmx.net> <1139925078.12023.366.camel@mccallum.corsepiu.local> <20060214160016.728239dd.bugs.michael@gmx.net> <1139933804.12023.407.camel@mccallum.corsepiu.local> <604aa7910602140825i50884cbfi201bb2df29246d69@mail.gmail.com> <1139936636.30045.25.camel@mccallum.corsepiu.local> Message-ID: <1140103763.21764.100.camel@mccallum.corsepiu.local> On Thu, 2006-02-16 at 07:07 -0800, Panu Matilainen wrote: > On Tue, 14 Feb 2006, Ralf Corsepius wrote: > >> > >> the repoquery isn't enough to provide the necessary information to > >> learn about dependancy chains to allow for maintainer coordination? > > No. > > > > [Personal side-note: I hate repoquery. > > Heh, care to elaborate? I'm open to suggestions you know :) Speed, usability, package deps (of yum and yum-utils). > > It's way less useable than its apt-get counterparts] > > What apt-get counterparts? apt-get build-dep apt-get --build source Do you need anything else? > Sure you can dig out quite a bit of information > from apt-cache but it has nothing like the formatting capabilities of > repoquery etc. I don't have much use for these. What I need is a simple way to rebuild packages without having to dig into details, basically apt-get build-dep apt-get source rpm -U package.src.rpm edit package.spec [rebuild package] This even works sufficiently well on underpowered machines with low bandwidth connections, and is much less resource demanding than yum is. Ralf From jwboyer at jdub.homelinux.org Thu Feb 16 14:30:24 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 16 Feb 2006 09:30:24 -0500 (EST) Subject: Packaging review guidelines clarification In-Reply-To: <604aa7910602160725i66b0ae16s17a643839214e91b@mail.gmail.com> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> <1140085756.8444.14.camel@laurel.intra.city-fan.org> <3237e4410602160420t7c8ffc8fta0546df263bd2661@mail.gmail.com> <1140098910.8444.21.camel@laurel.intra.city-fan.org> <604aa7910602160725i66b0ae16s17a643839214e91b@mail.gmail.com> Message-ID: <19090.129.42.161.36.1140100224.squirrel@jdub.homelinux.org> > On 2/16/06, Paul Howarth wrote: >> The problem with that is that not every reviewer has the bandwidth to >> support a mock build environment (particularly for development), so it's >> probably left as a "should", but a failure being a blocker. > > there was a discussion at somepoint about scratch build trees in the > buildsystem to help with update builds. > > Would it be a worthwhile to extend that discussion about the value of > enhancing the build system to have scratch areas so reviewers could > submit srpms that aren't in cvs yet to spin up rpms using the > dedicated buildsystem hardware without having to pull the build > environment down locally? > > I have no idea how much work that would entail.. but its thing I think > which would most greatly impact the quality of the review process for > binaries. Not having access to all build arches and not having the > bandwidth to pull down the development tree are large obstacles to > doing quality review builds, at least for me. +1 josh From ed at eh3.com Thu Feb 16 15:32:35 2006 From: ed at eh3.com (Ed Hill) Date: Thu, 16 Feb 2006 10:32:35 -0500 Subject: Packaging review guidelines clarification In-Reply-To: <604aa7910602160725i66b0ae16s17a643839214e91b@mail.gmail.com> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> <1140085756.8444.14.camel@laurel.intra.city-fan.org> <3237e4410602160420t7c8ffc8fta0546df263bd2661@mail.gmail.com> <1140098910.8444.21.camel@laurel.intra.city-fan.org> <604aa7910602160725i66b0ae16s17a643839214e91b@mail.gmail.com> Message-ID: <1140103955.3004.333.camel@ernie> On Thu, 2006-02-16 at 10:25 -0500, Jeff Spaleta wrote: > On 2/16/06, Paul Howarth wrote: > > The problem with that is that not every reviewer has the bandwidth to > > support a mock build environment (particularly for development), so it's > > probably left as a "should", but a failure being a blocker. > > there was a discussion at somepoint about scratch build trees in the > buildsystem to help with update builds. > > Would it be a worthwhile to extend that discussion about the value of > enhancing the build system to have scratch areas so reviewers could > submit srpms that aren't in cvs yet to spin up rpms using the > dedicated buildsystem hardware without having to pull the build > environment down locally? > > I have no idea how much work that would entail.. but its thing I think > which would most greatly impact the quality of the review process for > binaries. Not having access to all build arches and not having the > bandwidth to pull down the development tree are large obstacles to > doing quality review builds, at least for me. +1 This is a excellent idea and I hope someone can find some time to (please!) look into 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 ed at eh3.com Thu Feb 16 15:40:23 2006 From: ed at eh3.com (Ed Hill) Date: Thu, 16 Feb 2006 10:40:23 -0500 Subject: Packaging review guidelines clarification In-Reply-To: <1140102502.21764.84.camel@mccallum.corsepiu.local> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> <1140085756.8444.14.camel@laurel.intra.city-fan.org> <3237e4410602160420t7c8ffc8fta0546df263bd2661@mail.gmail.com> <1140098910.8444.21.camel@laurel.intra.city-fan.org> <1140102502.21764.84.camel@mccallum.corsepiu.local> Message-ID: <1140104423.3004.343.camel@ernie> On Thu, 2006-02-16 at 16:08 +0100, Ralf Corsepius wrote: > On Thu, 2006-02-16 at 14:08 +0000, Paul Howarth wrote: > > The problem with that is that not every reviewer has the bandwidth to > > support a mock build environment (particularly for development), > Set up a local one, that's what I'm doing ... Hi Ralf, Are there any brief HOWTOs for setting up local Fedora mirrors that you could point us towards? Or, if not, perhaps some advice that you could put on a wiki page on how you speed up mock builds? I'd be grateful and I'm sure other people would, too! Also, I know some folks are using local squid proxies to amortize the package download costs over multiple mock builds. Any thoughts on what would be the easiest/quickest/most-efficient-for-local-storage setup? 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 sundaram at fedoraproject.org Thu Feb 16 15:47:50 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 16 Feb 2006 21:17:50 +0530 Subject: Packaging review guidelines clarification In-Reply-To: <1140104423.3004.343.camel@ernie> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> <1140085756.8444.14.camel@laurel.intra.city-fan.org> <3237e4410602160420t7c8ffc8fta0546df263bd2661@mail.gmail.com> <1140098910.8444.21.camel@laurel.intra.city-fan.org> <1140102502.21764.84.camel@mccallum.corsepiu.local> <1140104423.3004.343.camel@ernie> Message-ID: <43F49EA6.9020507@fedoraproject.org> Ed Hill wrote: >On Thu, 2006-02-16 at 16:08 +0100, Ralf Corsepius wrote: > > >>On Thu, 2006-02-16 at 14:08 +0000, Paul Howarth wrote: >> >> >>>The problem with that is that not every reviewer has the bandwidth to >>>support a mock build environment (particularly for development), >>> >>> >> Set up a local one, that's what I'm doing ... >> >> > >Hi Ralf, > >Are there any brief HOWTOs for setting up local Fedora mirrors that you >could point us towards? > http://fedora.redhat.com/docs/mirror/ -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From bugzilla at redhat.com Thu Feb 16 15:49:29 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 10:49:29 -0500 Subject: [Bug 181404] Review Request: emacs-muse In-Reply-To: Message-ID: <200602161549.k1GFnTrv025892@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 ------- Additional Comments From jonathan.underwood at gmail.com 2006-02-16 10:49 EST ------- Thanks for taking a look at the package, Kevin. Regarding the package name issue: fedora-extras package naming guidelines state that "If a new package is considered an "addon" package that enhances or adds a new functionality to an existing Fedora Core or Fedora Extras package without being useful on its own, its name should reflect this fact. The new package ("child") should prepend the "parent" package in its name, in the format: %{parent}-%{child}." muse is an add-on package for emacs (it doesn't function without emacs), and I think I have have followed the convention accordingly. This is the same as for other emacs add-on packages, for example emacs-auctex. It's not the same though as packages that used to be in core, eg. mew, which IMHO the fact that they don't follow fedora-extras guidelines is a bug. Regarding Xemacs: I could produce xemacs-muse and emacs-muse from the same spec file, however this brings complexity and makes it a bigger job to maintain. Complexity comes because I would have to do two makes and make installs, with both makes in the %install section of the spec (see eg. muse) - this is messy, I think Also, I would end up with emacs-muse, xemacs-muse, emacs-muse-el, xemacs-muse-el packages, from a emacs-muse src rpm - I'm not sure this is desireable, a SRPM producing packages with different names. I don't wish to be disagreeable, but I think I'm doing the right thing with regard to naming, or the guidelines should be re-written. Since eg. emacs-auctex doesn't support xemacs, I don't think a lack of an xemacs package should be a blocker - I am prepared to add in the xemacs stuff though, once we've resolved the package naming issue. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 16:19:54 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 11:19:54 -0500 Subject: [Bug 174377] Review Request:gnu-smalltalk - GNU Smalltalk In-Reply-To: Message-ID: <200602161619.k1GGJsnO032679@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request:gnu-smalltalk - GNU Smalltalk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174377 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-16 11:19 EST ------- When I look at the build output I saw a lot oth -rpath. But when I look in the Makefiles I have trouble to find the rpath options: Perhaps someone have any idea, how the rpath will be generated in the Makefile. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From Christian.Iseli at licr.org Thu Feb 16 16:27:10 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 16 Feb 2006 17:27:10 +0100 Subject: FE Package Status of Feb 16, 2006 Message-ID: <200602161627.k1GGRAOi020957@ludwig-alpha.unil.ch> Hi folks, Here's the weekly status. I had a quick email exchange with Jef and I agreed to add some stats about CVS repo and open bugs. I unexpectedly found some time to look into it and added some lines to the report. Comments welcome... Cheers, Christian --- FE Package Status of Feb 16, 2006 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 1433 packages - 58 orphans - 48 packages not available in extras devel or release - 12 packages not available in extras devel but present in release - 2 packages which have not yet been FE-APPROVE'd... - 15 packages present in the development repo which have no owners entry - 47 orphaned packages, yet available in extras devel - 33 packages that moved to core FE-ACCEPT packages stats: - 510 accepted, closed package reviews - 8 accepted, closed package reviews not in repo - 8 accepted, closed package reviews not in owners - 14 accepted, open package reviews older than 4 weeks; - 11 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 61 open tickets - 14 tickets with no activity in eight weeks - 9 tickets with no activity in four weeks - 3 closed tickets FE-NEW packages stats: - 121 open tickets - 11 tickets with no activity in eight weeks - 30 tickets with no activity in four weeks - 8 closed tickets FE-NEEDSPONSOR packages stats: - 35 open tickets - 12 tickets with no activity in four weeks OPEN-BUGS packages stats: - 281 open tickets - 108 tickets with no activity in eight weeks - 40 tickets with no activity in four weeks CVS stats: - 1420 packages with a devel directory - 20 packages with no owners entry - 520 packages with no CVS activity in the last 12 weeks From bugzilla at redhat.com Thu Feb 16 16:23:41 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 11:23:41 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602161623.k1GGNf1d001205@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From jvdias at redhat.com 2006-02-16 11:23 EST ------- I'll investigate using environment-modules / finding the best way to let OpenMPI and LAM co-exist. I don't think it is an option to completely replace LAM with OpenMPI, as software currently linked with LAM will break. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From mmcgrath at fedoraproject.org Thu Feb 16 16:34:37 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 16 Feb 2006 10:34:37 -0600 Subject: Packaging review guidelines clarification In-Reply-To: <43F49EA6.9020507@fedoraproject.org> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> <1140085756.8444.14.camel@laurel.intra.city-fan.org> <3237e4410602160420t7c8ffc8fta0546df263bd2661@mail.gmail.com> <1140098910.8444.21.camel@laurel.intra.city-fan.org> <1140102502.21764.84.camel@mccallum.corsepiu.local> <1140104423.3004.343.camel@ernie> <43F49EA6.9020507@fedoraproject.org> Message-ID: <3237e4410602160834q63df0178w95577cfbad0d3ad@mail.gmail.com> The point could be made that mock should remain a should because if it does fail, its not getting in FE anyway until its fixed. //devils advocate. -Mike From bugzilla at redhat.com Thu Feb 16 16:35:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 11:35:07 -0500 Subject: [Bug 178668] Review Request: numpy: A fast multidimensional array facility for Python In-Reply-To: Message-ID: <200602161635.k1GGZ7Y5003524@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: numpy: A fast multidimensional array facility for Python https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178668 ivazquez at ivazquez.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From ivazquez at ivazquez.net 2006-02-16 11:34 EST ------- Built under FC4 and devel. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rc040203 at freenet.de Thu Feb 16 16:41:35 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 16 Feb 2006 17:41:35 +0100 Subject: Packaging review guidelines clarification In-Reply-To: <3237e4410602160834q63df0178w95577cfbad0d3ad@mail.gmail.com> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> <1140085756.8444.14.camel@laurel.intra.city-fan.org> <3237e4410602160420t7c8ffc8fta0546df263bd2661@mail.gmail.com> <1140098910.8444.21.camel@laurel.intra.city-fan.org> <1140102502.21764.84.camel@mccallum.corsepiu.local> <1140104423.3004.343.camel@ernie> <43F49EA6.9020507@fedoraproject.org> <3237e4410602160834q63df0178w95577cfbad0d3ad@mail.gmail.com> Message-ID: <1140108095.21764.106.camel@mccallum.corsepiu.local> On Thu, 2006-02-16 at 10:34 -0600, Mike McGrath wrote: > The point could be made that mock should remain a should because if it > does fail, its not getting in FE anyway until its fixed. > > //devils advocate. Not quite - The question would be: Why does mock fail? If it's because a BR: is missing then it wouldn't be a biggy, but if it's because a package is missing or has changed in FC or FE, then the review process has failed. Ralf From nicolas.mailhot at laposte.net Thu Feb 16 16:45:27 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 16 Feb 2006 17:45:27 +0100 Subject: Packaging review guidelines clarification In-Reply-To: <19090.129.42.161.36.1140100224.squirrel@jdub.homelinux.org> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> <1140085756.8444.14.camel@laurel.intra.city-fan.org> <3237e4410602160420t7c8ffc8fta0546df263bd2661@mail.gmail.com> <1140098910.8444.21.camel@laurel.intra.city-fan.org> <604aa7910602160725i66b0ae16s17a643839214e91b@mail.gmail.com> <19090.129.42.161.36.1140100224.squirrel@jdub.homelinux.org> Message-ID: <1140108327.5699.0.camel@rousalka.dyndns.org> Le jeudi 16 f?vrier 2006 ? 09:30 -0500, Josh Boyer a ?crit : > > On 2/16/06, Paul Howarth wrote: > >> The problem with that is that not every reviewer has the bandwidth to > >> support a mock build environment (particularly for development), so it's > >> probably left as a "should", but a failure being a blocker. > > > > there was a discussion at somepoint about scratch build trees in the > > buildsystem to help with update builds. > > > > Would it be a worthwhile to extend that discussion about the value of > > enhancing the build system to have scratch areas so reviewers could > > submit srpms that aren't in cvs yet to spin up rpms using the > > dedicated buildsystem hardware without having to pull the build > > environment down locally? > > > > I have no idea how much work that would entail.. but its thing I think > > which would most greatly impact the quality of the review process for > > binaries. Not having access to all build arches and not having the > > bandwidth to pull down the development tree are large obstacles to > > doing quality review builds, at least for me. > > +1 +1 -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From bugzilla at redhat.com Thu Feb 16 16:47:17 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 11:47:17 -0500 Subject: [Bug 181753] Review Request: mm - Shared memory allocation library In-Reply-To: Message-ID: <200602161647.k1GGlHOH006503@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mm - Shared memory allocation library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181753 Jochen at herr-schmitt.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-16 11:47 EST ------- Good: + md5sum of source tar file ok. + Local build workes fine. * Build on mock (fedora-devel) workes fine. Bad: - Please use make %{?smp_mlfags} if possible. - inconsitent use of $RPM_BUILD_ROOT and %{buildroot} - Don't put .a file in devel package. - /usr/lib/libmm.so.14.0.20 is not stripped. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 16:56:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 11:56:35 -0500 Subject: [Bug 181035] Review Request: luks-tools In-Reply-To: Message-ID: <200602161656.k1GGuZTB008951@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: luks-tools https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181035 Jochen at herr-schmitt.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-16 11:56 EST ------- Local build failed: checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking whether make sets $(MAKE)... (cached) yes checking whether ln -s works... yes checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... 64 checking for _LARGE_FILES value needed for large files... no checking for pkg-config... /usr/bin/pkg-config checking for GLIB - version >= 2.0.0... yes (version 2.7.4) checking for cryptsetup... no configure: error: cryptsetup executable not found in your path Fehler: Bad exit status from /var/tmp/rpm-tmp.78258 (%build) RPM build errors: InstallSourcePackage: Header V3 DSA signature: NOKEY, key ID cb278bd5 user mike does not exist - using root group mike does not exist - using root user mike does not exist - using root group mike does not exist - using root Bad exit status from /var/tmp/rpm-tmp.78258 (%build) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 17:02:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 12:02:15 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602161702.k1GH2FkA010399@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From orion at cora.nwra.com 2006-02-16 12:02 EST ------- (In reply to comment #17) > The reasons for having the pils package separate is that this is a general > purpose library - usable without heartbeat. > > The same is true of the stonith libraries. Indeed, Red Hat has historically > used these same packages in some of their products. So, an install of heartbeart *must* have -pils and -stonith, but -pils and -stonith can be used independently for other things? Then the original Requires was correct. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 17:05:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 12:05:52 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602161705.k1GH5qC5011688@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From orion at cora.nwra.com 2006-02-16 12:05 EST ------- (In reply to comment #18) > AFAIK, we do indeed use SWIG, and python-gtk, but I don't know about the version > issues, but I suspect they?re there for a reason. I'm sure he's just copying > what Huang Zhen (the developer of this code) put in the project's RPM. swig is definitely used during compile (hence the BR), but I see no runtine dependency (so no Requires). Okay, found the pygtk requirement, so Requires: python-gtk stays. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From fedora at leemhuis.info Thu Feb 16 17:12:35 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 16 Feb 2006 18:12:35 +0100 Subject: Packaging review guidelines clarification In-Reply-To: <1140108327.5699.0.camel@rousalka.dyndns.org> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> <1140085756.8444.14.camel@laurel.intra.city-fan.org> <3237e4410602160420t7c8ffc8fta0546df263bd2661@mail.gmail.com> <1140098910.8444.21.camel@laurel.intra.city-fan.org> <604aa7910602160725i66b0ae16s17a643839214e91b@mail.gmail.com> <19090.129.42.161.36.1140100224.squirrel@jdub.homelinux.org> <1140108327.5699.0.camel@rousalka.dyndns.org> Message-ID: <1140109955.2904.28.camel@localhost.localdomain> Am Donnerstag, den 16.02.2006, 17:45 +0100 schrieb Nicolas Mailhot: > Le jeudi 16 f?vrier 2006 ? 09:30 -0500, Josh Boyer a ?crit : > > > On 2/16/06, Paul Howarth wrote: > > > there was a discussion at somepoint about scratch build trees in the > > > buildsystem to help with update builds. > > +1 > +1 Enough votes ;-) I like the idea also and added it already to http://www.fedoraproject.org/wiki/Extras/Schedule/IdeasContainer I put things like this there where I agree that they should be done for fedora-extras sooner or later. I'm also willing to put it on the FESCo Schedule -- but first I'd like to have someone who drives this whole thing forward. Means: Ask dcbw and the other buildsys people (skvidal,?) if this is is possible in general, what is needed to get this running, help with doing the work that might be needed, report and discuss details with FESCo and fedora-extras-list and organize all other stuff that might show up to realize this idea. Any volunteers? No, it does not have to be someone from FESCo. Everybody interested in this task can work on this. If nobody shows up I'll try to drive that forward myself sooner or later -- but I don't know when. That depends on my free time and how many other things are on the ToDo list that might be more important. CU thl -- Thorsten Leemhuis From pmatilai at laiskiainen.org Thu Feb 16 17:19:39 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 16 Feb 2006 19:19:39 +0200 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1140103763.21764.100.camel@mccallum.corsepiu.local> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214124313.765c0ca5.bugs.michael@gmx.net> <1139925078.12023.366.camel@mccallum.corsepiu.local> <20060214160016.728239dd.bugs.michael@gmx.net> <1139933804.12023.407.camel@mccallum.corsepiu.local> <604aa7910602140825i50884cbfi201bb2df29246d69@mail.gmail.com> <1139936636.30045.25.camel@mccallum.corsepiu.local> <1140103763.21764.100.camel@mccallum.corsepiu.local> Message-ID: <1140110380.8099.23.camel@weasel.turre.laiskiainen.org> On Thu, 2006-02-16 at 16:29 +0100, Ralf Corsepius wrote: > On Thu, 2006-02-16 at 07:07 -0800, Panu Matilainen wrote: > > On Tue, 14 Feb 2006, Ralf Corsepius wrote: > > >> > > >> the repoquery isn't enough to provide the necessary information to > > >> learn about dependancy chains to allow for maintainer coordination? > > > No. > > > > > > [Personal side-note: I hate repoquery. > > > > Heh, care to elaborate? I'm open to suggestions you know :) > > Speed, usability, package deps (of yum and yum-utils). Speed and dependencies I can't help directly, usability suggestions are most welcome. Repoquery started with some sort of "rpm -q" compatibility in mind and that's why it's the way it is. Suggestions are most welcome, the rpm -q compatibility is an illusion at best anyway. > > > It's way less useable than its apt-get counterparts] > > > > What apt-get counterparts? > > apt-get build-dep > apt-get --build source > > Do you need anything else? Repoquery isn't inteded for that, so no wonder you don't like it for these purposes :) It's an utility to allow extracting every piece of info there is in a repository/repositories (ultimately). You can get the build dependencies out of it ('repoquery --requires foo.src') but it won't install them for you, yum-builddep from yum-utils exists for that purpose (hint: I missed apt-get build-dep too :) Retrieving the source can be done with yumdownloader, but for the build part there doesn't exist any yum counterpart, mostly because nobody has wanted one bad enough I guess. > > Sure you can dig out quite a bit of information > > from apt-cache but it has nothing like the formatting capabilities of > > repoquery etc. > I don't have much use for these. > > What I need is a simple way to rebuild packages without having to dig > into details, basically > > apt-get build-dep yum-builddep (package can be local or in a repo) > apt-get source yumdownloader --source Of course the problem with these has been that the SRPM repositories haven't really existed at all (in FC4 and earlier), never mind being set up by default. > rpm -U package.src.rpm > edit package.spec > [rebuild package] > > This even works sufficiently well on underpowered machines with low > bandwidth connections, and is much less resource demanding than yum is. I haven't done any actual comparisons memory-wise between apt and yum in long time, but yum >= 2.4 has far lower memory requirements than it used to have, thanks to sqlite. Rpm headers are the really costly part for memory consumption - apt might be able to complete that in less memory because it doesn't use the full headers but for the final transaction memory requirements should be about the same these days. Unless rpm-python causes some significant overhead wrt that - dunno. - Panu - From bugzilla at redhat.com Thu Feb 16 17:13:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 12:13:48 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602161713.k1GHDmqI013991@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From orion at cora.nwra.com 2006-02-16 12:13 EST ------- I think we can use modules with someling like: alias mpirun mpirun.{name} alias mpicc mpicc.{name} prepend-path MANPATH $SOMEPACKAGE_HOME/man prepend-path LD_LIBRARY_PATH $SOMEPACKAGE_HOME/lib ...etc... to coexist with alternatives/FHS compliance for binaries. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From jspaleta at gmail.com Thu Feb 16 17:23:51 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 16 Feb 2006 12:23:51 -0500 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1140110380.8099.23.camel@weasel.turre.laiskiainen.org> References: <1139851362.2904.79.camel@localhost.localdomain> <20060214124313.765c0ca5.bugs.michael@gmx.net> <1139925078.12023.366.camel@mccallum.corsepiu.local> <20060214160016.728239dd.bugs.michael@gmx.net> <1139933804.12023.407.camel@mccallum.corsepiu.local> <604aa7910602140825i50884cbfi201bb2df29246d69@mail.gmail.com> <1139936636.30045.25.camel@mccallum.corsepiu.local> <1140103763.21764.100.camel@mccallum.corsepiu.local> <1140110380.8099.23.camel@weasel.turre.laiskiainen.org> Message-ID: <604aa7910602160923x35f5116w74254a28e62126bc@mail.gmail.com> On 2/16/06, Panu Matilainen wrote: > Of course the problem with these has been that the SRPM repositories > haven't really existed at all (in FC4 and earlier), never mind being set > up by default. Where is Core and Extras policy stand on how the repo metadata for SRPM is going to be handled now? is repodata for SRPM split off in its own repodata structure that requires additional repo entries? Last time a look..awhile ago... it seemed to be handled inconsistently across base and updates-released and extras for fc4. Is there going to be a consistent handling across base,updates,extras for fc5? Is there a need for something like an fedora-release-srpm package to provide supplimental yum repo configurations to add srpms back into repository calculations for base,updates and extras those who want it? -jef From notting at redhat.com Thu Feb 16 17:33:08 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 16 Feb 2006 12:33:08 -0500 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <604aa7910602160923x35f5116w74254a28e62126bc@mail.gmail.com> References: <20060214124313.765c0ca5.bugs.michael@gmx.net> <1139925078.12023.366.camel@mccallum.corsepiu.local> <20060214160016.728239dd.bugs.michael@gmx.net> <1139933804.12023.407.camel@mccallum.corsepiu.local> <604aa7910602140825i50884cbfi201bb2df29246d69@mail.gmail.com> <1139936636.30045.25.camel@mccallum.corsepiu.local> <1140103763.21764.100.camel@mccallum.corsepiu.local> <1140110380.8099.23.camel@weasel.turre.laiskiainen.org> <604aa7910602160923x35f5116w74254a28e62126bc@mail.gmail.com> Message-ID: <20060216173308.GE8686@devserv.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > On 2/16/06, Panu Matilainen wrote: > > Of course the problem with these has been that the SRPM repositories > > haven't really existed at all (in FC4 and earlier), never mind being set > > up by default. > > Where is Core and Extras policy stand on how the repo metadata for > SRPM is going to be handled now? is repodata for SRPM split off in its > own repodata structure that requires additional repo entries? Last > time a look..awhile ago... it seemed to be handled inconsistently > across base and updates-released and extras for fc4. Is there going > to be a consistent handling across base,updates,extras for fc5? See http://cvs.fedora.redhat.com/viewcvs/fedora-release/?root=fedora - this has been changed around some in the past couple of days. Bill From bugzilla at redhat.com Thu Feb 16 17:29:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 12:29:27 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602161729.k1GHTRVt016746@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From ed at eh3.com 2006-02-16 12:29 EST ------- Hi Jason and Orion, Thank you for the responses -- I'm thrilled that other folks are interested in MPI on Fedora! When installing multiple MPI implementations, its best if you avoid putting headers and libs into, for instance, /usr/include and /usr/lib. If you instead put them into, for example, /usr/include/openmpi or /usr/lib/lam then compilers will have to use some sort of environment variables or other build-time information to find them. And thats desirable when installing multiple implementations because it means that, for instance, a particular software build won't accidentally include a lam-provided /usr/include/mpif.h when what you really want is the version at /usr/include/mpich-2/mpif.h. Basically, if we do our best to avoid "polluting" the standard locations then users are much less likely to have problems with side-by-side installs. And yes, I realize that these problems can be fixed by improving the build systems for all the software out there that uses MPI. Good build systems can make it easy to ensure that you get the headers, libs, etc. that you want. But file layout can also make it easier when dealing with the vast number of thrown-together-with-duct-tape build systems that seem to be the norm in the real world. :-) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 17:31:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 12:31:16 -0500 Subject: [Bug 181534] Review Request: kst - plots scientific data In-Reply-To: Message-ID: <200602161731.k1GHVGwu017131@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kst - plots scientific data https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181534 ------- Additional Comments From orion at cora.nwra.com 2006-02-16 12:31 EST ------- (In reply to comment #8) > (In reply to comment #7) > > - Get rid of: > > > > --disable-debug and CXXFLAGS=-g CFLAGS=-g > > > > debuginfo packages are created automatically and your mucking with the RPM > > optimization flags. > > Unfortunatly, with kst, if you don't have --disable-debug, then a bunch of > 'crap' may be spewed out on stdout and/or stderr when using kst. I don't know > how else to disable this 'debugging text output' while keeping the debugging > info in the binaries (so debuginfo packages) are useful. > Well, CCFLAGS and CXXFLAGS automatically have -g in them when you use %configure, but by setting them you wipe out the optimization flags. So keep --disable-debug but drop the flags. > This only fixes the "symlink-should-be-relative" warning, but doesn't remove the > "dangling-symlink" warning. Is that correct? Well, I think ln -sf ../../common $RPM_BUILD_ROOT%{_defaultdocdir}/HTML/sv/kst/%{name} should handle that, right? What is the /sv/kst/ directory for though? I don't have any other packages using %{_defaultdocdir}/HTML/sv/. You'll need to own that too. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From jspaleta at gmail.com Thu Feb 16 17:40:12 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 16 Feb 2006 12:40:12 -0500 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <20060216173308.GE8686@devserv.devel.redhat.com> References: <20060214124313.765c0ca5.bugs.michael@gmx.net> <20060214160016.728239dd.bugs.michael@gmx.net> <1139933804.12023.407.camel@mccallum.corsepiu.local> <604aa7910602140825i50884cbfi201bb2df29246d69@mail.gmail.com> <1139936636.30045.25.camel@mccallum.corsepiu.local> <1140103763.21764.100.camel@mccallum.corsepiu.local> <1140110380.8099.23.camel@weasel.turre.laiskiainen.org> <604aa7910602160923x35f5116w74254a28e62126bc@mail.gmail.com> <20060216173308.GE8686@devserv.devel.redhat.com> Message-ID: <604aa7910602160940l22f34c56j2789f4f6bf11af2d@mail.gmail.com> On 2/16/06, Bill Nottingham wrote: > See http://cvs.fedora.redhat.com/viewcvs/fedora-release/?root=fedora - > this has been changed around some in the past couple of days. yippie! to celebrate, I'm going to have a 3 day old subway sandwich i just found in the back of the fridge! -jef From bugzilla at redhat.com Thu Feb 16 17:38:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 12:38:50 -0500 Subject: [Bug 181404] Review Request: emacs-muse In-Reply-To: Message-ID: <200602161738.k1GHcodr018668@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 ------- Additional Comments From ville.skytta at iki.fi 2006-02-16 12:38 EST ------- auctex is not a good example; it is shipped for XEmacs in the xemacs-sumo package. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 17:42:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 12:42:11 -0500 Subject: [Bug 180743] Review Request: pdsh In-Reply-To: Message-ID: <200602161742.k1GHgBeM019343@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: pdsh https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180743 ------- Additional Comments From woodard at redhat.com 2006-02-16 12:42 EST ------- OK this should have everything that you mentioned fixed: http://osdn.dl.sourceforge.net/sourceforge/pdsh/pdsh-2.8.1-3.src.rpm http://osdn.dl.sourceforge.net/sourceforge/pdsh/pdsh.spec -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From ville.skytta at iki.fi Thu Feb 16 17:52:48 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 16 Feb 2006 19:52:48 +0200 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214124313.765c0ca5.bugs.michael@gmx.net> <1139925078.12023.366.camel@mccallum.corsepiu.local> <20060214160016.728239dd.bugs.michael@gmx.net> <1139933804.12023.407.camel@mccallum.corsepiu.local> <604aa7910602140825i50884cbfi201bb2df29246d69@mail.gmail.com> <1139948390.10711.7.camel@bobcat.mine.nu> Message-ID: <1140112368.16146.3.camel@bobcat.mine.nu> On Thu, 2006-02-16 at 07:02 -0800, Panu Matilainen wrote: > What's stopping people from applying the one-liner patch repoquery in the > yum-utils FE package if it's considered that important? Quite frankly, that's something I'd expect from the package maintainer. Or alternatively, an indication that someone else can go ahead if he's too busy to take care of it. From eric.tanguy at univ-nantes.fr Thu Feb 16 18:00:22 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Thu, 16 Feb 2006 19:00:22 +0100 Subject: Hammer3 seems to hang ? Message-ID: <1140112822.3115.0.camel@bureau.maison> I have 2 pakages building in hammer3 since a too long time. Is it hanging ? Thanks Eric From jamatos at fc.up.pt Thu Feb 16 18:10:20 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Thu, 16 Feb 2006 18:10:20 +0000 Subject: Requiring a versioned R in rpy Message-ID: <200602161810.20613.jamatos@fc.up.pt> Hi all, rpy requires the version of R for which it is compiled, is there any way to get that automatically or do I need to set manually each time? I have tried Requires: \ R = %(%{_bindir}/R --version | head -n 1 | sed -e 's/.* \(.*\) .*/\1/') but it seems that R is not installed at that point. Is there any way back? Thanks, -- Jos? Ab?lio From bugzilla at redhat.com Thu Feb 16 18:16:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 13:16:33 -0500 Subject: [Bug 181801] New: Review Request: zeroinstall-injector Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181801 Summary: Review Request: zeroinstall-injector Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: michel.salim at gmail.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://hircus.org/fedora/zeroinstall-injector/zeroinstall-injector.spec SRPM Name or Url: http://hircus.org/fedora/zeroinstall-injector/zeroinstall-injector-0.18-1.src.rpm Description: A running process is created by combining many different libraries (and other components). In the Zero Install world, we have all versions of each library available at all times. The problem then is how to choose which versions to use. The injector solves this problem by selecting components to meet a program's requirements, according to a policy you give it. The injector finds out which versions are available, and downloads and runs the ones you choose. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 18:17:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 13:17:56 -0500 Subject: [Bug 181753] Review Request: mm - Shared memory allocation library In-Reply-To: Message-ID: <200602161817.k1GIHuY3026781@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mm - Shared memory allocation library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181753 ------- Additional Comments From andreas at bawue.net 2006-02-16 13:17 EST ------- (In reply to comment #1) > Bad: > - Please use make %{?smp_mlfags} if possible. > - inconsitent use of $RPM_BUILD_ROOT and %{buildroot} > - Don't put .a file in devel package. > - /usr/lib/libmm.so.14.0.20 is not stripped. fixed. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 18:18:41 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 13:18:41 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602161818.k1GIIfrr026992@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From jonathan.underwood at gmail.com 2006-02-16 13:18 EST ------- Yes - as an MPI user, I would also add to the plea not to use alternatives for solving this issue. I think you'd be creating a maintainence nightmare across the packages for each MPI implementation. Plus, alternatives isn't something that users should be fiddling with, I'd have thought. Environment modules seems like a much better solution. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From michel.salim at gmail.com Thu Feb 16 18:25:31 2006 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 16 Feb 2006 13:25:31 -0500 Subject: GNU Smalltalk review needs assistance Message-ID: <883cfe6d0602161025l2663f9c7s@mail.gmail.com> My review of GNU Smalltalk is stalled on the upstream configure script not respecting the flag to disable rpath, and also a bizarre failure in one of the test cases if the build scripts are modified to rename smalltalk to gnu-smalltalk. Could someone more familiar with build scripts take a look? Thanks in advance, - Michel Salim ---------- Forwarded message ---------- From: bugzilla at redhat.com Date: 29-Nov-2005 12:12 Subject: [Bug 174377] Review Request:gnu-smalltalk - GNU Smalltalk To: fedora-extras-list at redhat.com Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request:gnu-smalltalk - GNU Smalltalk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174377 Jochen at herr-schmitt.de changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request:gst - GNU |Review Request:gnu-smalltalk |Smalltalk |- GNU Smalltalk URL|http://www.herr- |http://www.herr- |schmitt.de/pub/gst/ |schmitt.de/pub/gnu-smalltalk Status|NEEDINFO |ASSIGNED ------- Additional Comments From Jochen at herr-schmitt.de 2005-11-29 12:11 EST ------- I have uploaded a updated version of the package: SPEC: http://www.herr-schmitt.de/pub/gnu-smalltalk/gnu-smalltalk.spec SRPM: http://www.herr-schmitt.de/pub/gnu-smalltalk/gnu-smalltalk-2.2-2.src.rpm Best Regards: Jochen Schmitt -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. -- fedora-extras-list mailing list fedora-extras-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-extras-list -- Michel Salim ??? http://www.cs.indiana.edu/~msalim From jspaleta at gmail.com Thu Feb 16 18:27:45 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 16 Feb 2006 13:27:45 -0500 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1140112368.16146.3.camel@bobcat.mine.nu> References: <1139851362.2904.79.camel@localhost.localdomain> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214124313.765c0ca5.bugs.michael@gmx.net> <1139925078.12023.366.camel@mccallum.corsepiu.local> <20060214160016.728239dd.bugs.michael@gmx.net> <1139933804.12023.407.camel@mccallum.corsepiu.local> <604aa7910602140825i50884cbfi201bb2df29246d69@mail.gmail.com> <1139948390.10711.7.camel@bobcat.mine.nu> <1140112368.16146.3.camel@bobcat.mine.nu> Message-ID: <604aa7910602161027p25ad9916mf3584ba7876e293b@mail.gmail.com> On 2/16/06, Ville Skytt? wrote: > Quite frankly, that's something I'd expect from the package maintainer. > Or alternatively, an indication that someone else can go ahead if he's > too busy to take care of it. This issue highlights one of the weaker points of how contributors in Extras are expected to behave when interacting with packages owned by other maintainers. We have a culture of being very cautious when touching other people's packages to do fixes and deferring to the owner's peragotive on how to handle things to prevent unwanted changes from the package owner's pov. Is this causing a bottleneck in getting packages in shape for fe5? -jef From bugzilla at redhat.com Thu Feb 16 18:23:06 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 13:23:06 -0500 Subject: [Bug 171597] Review Request: spandsp - A DSP library for telephony In-Reply-To: Message-ID: <200602161823.k1GIN6gp028386@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: spandsp - A DSP library for telephony https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171597 ------- Additional Comments From erik at ilsw.com 2006-02-16 13:22 EST ------- The spec looks pretty good to me and compiles clean on centos 3. I'll test it and your asterisk package soon(TM). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From dcbw at redhat.com Thu Feb 16 18:37:03 2006 From: dcbw at redhat.com (Dan Williams) Date: Thu, 16 Feb 2006 13:37:03 -0500 Subject: Hammer3 seems to hang ? In-Reply-To: <1140112822.3115.0.camel@bureau.maison> References: <1140112822.3115.0.camel@bureau.maison> Message-ID: <1140115023.10832.1.camel@dhcp83-74.boston.redhat.com> On Thu, 2006-02-16 at 19:00 +0100, Eric Tanguy wrote: > I have 2 pakages building in hammer3 since a too long time. Is it > hanging ? > Thanks > Eric Congrats, you caught a traceback that hasn't been triggered before :) Should be fixed now, I'll kick the buildsys and it should start rebuilding freehdl along with the rest. Dan From bugzilla at redhat.com Thu Feb 16 18:36:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 13:36:01 -0500 Subject: [Bug 181803] New: Review Request: scrub Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181803 Summary: Review Request: scrub Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: woodard at redhat.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://osdn.dl.sourceforge.net/sourceforge/diskscrub/scrub.spec SRPM Name or Url: http://osdn.dl.sourceforge.net/sourceforge/diskscrub/scrub-1.7-2.src.rpm Description: This utility writes patterns on files or disk devices to make retrieving the data more difficult. It operates in one of three modes: 1) the special file corresponding to an entire disk is scrubbed and all data on it is destroyed; 2) a regular file is scrubbed and only the data in the file (and optionally its name in the directory entry) is destroyed; or 3) a regular file is created, expanded until the file system is full, then scrubbed as in 2). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 18:39:17 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 13:39:17 -0500 Subject: [Bug 181803] Review Request: scrub In-Reply-To: Message-ID: <200602161839.k1GIdH4B000355@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: scrub https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181803 ------- Additional Comments From woodard at redhat.com 2006-02-16 13:39 EST ------- I forgot to mention that I will need a sponsor. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From michel.salim at gmail.com Thu Feb 16 18:44:36 2006 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 16 Feb 2006 13:44:36 -0500 Subject: FE package status Tue Feb 7 2006 In-Reply-To: <200602071718.k17HI7fL011115@ludwig-alpha.unil.ch> References: <200602071718.k17HI7fL011115@ludwig-alpha.unil.ch> Message-ID: <883cfe6d0602161044p6e30aacar@mail.gmail.com> If nobody else is interested, I'd like to take over gnugo. Regards, - Michel On 07/02/06, Christian.Iseli at licr.org wrote: > We have 53 orphaned packages available in extras devel: > abe anjuta apg apt arc at-poke camstream cgoban cksfv conglomerate duplicity > freedroidrpg gdeskcal gkrellm-themes gnofract4d gnome-password-generator > gnome-telnet gnome-themes-extras gnugo gonvert gpa gtkglarea2 gurlchecker > hping2 libzvt lincvs lua manedit mknbi netdiag nget ots p0f parchive > perl-Net-SCP perl-Net-SSH perl-Parse-Yapp prozilla putty rpmproc screem sirius > synaptic tdl tetex-arabtex tetex-armtex tetex-font-tipa tetex-lgrind tla > wbxml2 wesnoth xmms-cdread xtide > From bugzilla at redhat.com Thu Feb 16 19:03:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 14:03:11 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602161903.k1GJ3BKL006392@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From jvdias at redhat.com 2006-02-16 14:02 EST ------- Perhaps the simplest solution may be to simply ship openmpi in a way that does not clash at all with lam, and that allows users to select use of either alternatives(8), or environment-modules, or home-grown solutions, but that does not depend on the new environment-modules package or use alternatives(8) in the .spec file. For example: the 6 mpi* clashing binaries could be installed as: /usr/bin/om-$bin (eg. /usr/bin/om-mpicc) , The clashing libraries could be installed in /usr/lib/openmpi . These are: libmpi*.so ( clashes with lam RPM ) libopal.so ( clashes with opal RPM - the "Open Phone Abstraction Library"!) Proably it is simpler just to put all openmpi libs in /usr/lib/openmpi . and includes in /usr/include/openmpi. Then links could be created in: /usr/share/openmpi/{bin,lib,include} so that e.g. /usr/share/openmpi/bin/mpicc -> /usr/bin/om-mpicc /usr/share/openmpi/lib/libmpi.so -> /usr/lib/openmpi/mpi.so etc. There are as yet NO man-pages shipped in the openmpi distribution (another reason why openmpi is still of "experimental" status IMHO). Then existing lam users and the existing lam package would be totally unaffected. The openmpi package should also provide pkg-config openmpi.pc files to easily provide the linker library and compiler include options to openmpi using builds . Users could decide to use alternatives ( ie. move the lam clashing executables to /usr/bin/lam-*, and make /usr/bin/mpicc an alternative between /usr/bin/om-mpicc and /usr/bin/lam-mpicc ), or could use environment-modules (set PATH, LD_LIBRARY_PATH to select between /usr/{lib,bin,include} and /usr/share/openmpi/{bin,lib,include} with modules). The environment-modules scripts could actually be shipped in /usr/share/openmpi/environment-modules and used at users' discretion, and we could also ship a script to setup alternatives(8). But the existing lam package could stay the same, and no new packages would be required by the new openmpi package. I think the above is what I'll be aiming for with the Core release, unless there are any objections. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 19:20:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 14:20:20 -0500 Subject: [Bug 174377] Review Request:gnu-smalltalk - GNU Smalltalk In-Reply-To: Message-ID: <200602161920.k1GJKKDO011954@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request:gnu-smalltalk - GNU Smalltalk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174377 toshio at tiki-lounge.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |toshio at tiki-lounge.com ------- Additional Comments From toshio at tiki-lounge.com 2006-02-16 14:20 EST ------- I'd help but there's no SRPM. Could you roll a new one with Michel's --with-pic=yes suggestion and upload so I can take a look at what's going on? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 19:35:23 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 14:35:23 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602161935.k1GJZNfk016466@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From ed at eh3.com 2006-02-16 14:35 EST ------- Hi Jason, I think most of comment #21 is fine but I have one objection: *** PLEASE *** move the lam-supplied files [I'll refrain from using the word "crap" here :-)] currently in /usr/include/* to /usr/include/lam/* and from /usr/lib/* to /usr/lib/lam/*. Its something we really ought to do. In fact, if lam were submitted to Fedora Extras in its current shape it would not pass review for exactly these reasons. And yes, the above lam changes would require some *small* changes to the packages that depend upon it. Not a big deal. Whatever small pain it causes now, the benefits for end users and Extras packagers dwarf it. [And whoever decided it was a good idea to put files named "freq.h", "boot.h", "net.h", and "args.h" in /usr/include should be banished to rotating backup tapes in a cold machine room for the next month or two.] -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 19:37:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 14:37:53 -0500 Subject: [Bug 174377] Review Request:gnu-smalltalk - GNU Smalltalk In-Reply-To: Message-ID: <200602161937.k1GJbrBP017055@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request:gnu-smalltalk - GNU Smalltalk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174377 ------- Additional Comments From toshio at tiki-lounge.com 2006-02-16 14:37 EST ------- The glanced at the tarball and RPATH is probably being snuck in via libtool. This might work for you: BuildRequires: libtool [...] make %{?_smp_mflags} LIBTOOL=/usr/bin/libtool -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From j.w.r.degoede at hhs.nl Thu Feb 16 19:53:07 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 16 Feb 2006 20:53:07 +0100 Subject: FE package status Tue Feb 7 2006 In-Reply-To: <883cfe6d0602161044p6e30aacar@mail.gmail.com> References: <200602071718.k17HI7fL011115@ludwig-alpha.unil.ch> <883cfe6d0602161044p6e30aacar@mail.gmail.com> Message-ID: <43F4D823.9070702@hhs.nl> Michel Salim wrote: > If nobody else is interested, I'd like to take over gnugo. > > Regards, > > - Michel > > On 07/02/06, Christian.Iseli at licr.org wrote: > >> We have 53 orphaned packages available in extras devel: >> abe anjuta apg apt arc at-poke camstream cgoban cksfv conglomerate duplicity >> freedroidrpg gdeskcal gkrellm-themes gnofract4d gnome-password-generator >> gnome-telnet gnome-themes-extras gnugo gonvert gpa gtkglarea2 gurlchecker >> hping2 libzvt lincvs lua manedit mknbi netdiag nget ots p0f parchive >> perl-Net-SCP perl-Net-SSH perl-Parse-Yapp prozilla putty rpmproc screem sirius >> synaptic tdl tetex-arabtex tetex-armtex tetex-font-tipa tetex-lgrind tla >> wbxml2 wesnoth xmms-cdread xtide >> > You seem to be using an old owners.list, I've added Glide3-libGL days ago and your reports still say its not in owners.list Besides that great work. Regards, Hans From Christian.Iseli at licr.org Thu Feb 16 19:55:06 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 16 Feb 2006 20:55:06 +0100 Subject: FE package status Tue Feb 7 2006 In-Reply-To: Your message of "Thu, 16 Feb 2006 20:53:07 +0100." <43F4D823.9070702@hhs.nl> Message-ID: <200602161955.k1GJtGS8007581@mx1.redhat.com> j.w.r.degoede at hhs.nl said: > You seem to be using an old owners.list, Nope, it's up to date :-) > I've added Glide3-libGL days ago > and your reports still say its not in owners.list The problem is in the upper/lower case mix: Glide3-libGL - package name as entered in CVS Glide3-libGl - owners.list entry the last L is different... > Besides that great work. Thanks. From bugzilla at redhat.com Thu Feb 16 20:06:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 15:06:35 -0500 Subject: [Bug 174866] Review Request: polypaudio: Improved Linux sound server In-Reply-To: Message-ID: <200602162006.k1GK6Z0V023368@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: polypaudio: Improved Linux sound server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174866 ------- Additional Comments From drzeus-bugzilla at drzeus.cx 2006-02-16 15:06 EST ------- (shameless plug) This might be of interest: :) http://article.gmane.org/gmane.linux.alsa.devel/31738 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 16 20:11:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 15:11:48 -0500 Subject: [Bug 181534] Review Request: kst - plots scientific data In-Reply-To: Message-ID: <200602162011.k1GKBmSt024488@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kst - plots scientific data https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181534 ------- Additional Comments From matt at truch.net 2006-02-16 15:11 EST ------- (In reply to comment #9) > > Well, CCFLAGS and CXXFLAGS automatically have -g in them when you use > %configure, but by setting them you wipe out the optimization flags. So keep > --disable-debug but drop the flags. Done. > > This only fixes the "symlink-should-be-relative" warning, but doesn't remove the > > "dangling-symlink" warning. Is that correct? > > Well, I think > > ln -sf ../../common $RPM_BUILD_ROOT%{_defaultdocdir}/HTML/sv/kst/%{name} > > should handle that, right? What is the /sv/kst/ directory for though? I don't > have any other packages using %{_defaultdocdir}/HTML/sv/. You'll need to own > that too. Directories owned. The sv (and other) directories are for different translations of the documentation. If people have other documentation (in specific) languages installed, those directories will contain translated docs for other apps. The dangling symlinks will be un-dangling if kde documentation for the specific language is installed. I don't know if this is the best thing, but I'd really rather not have a separate package for each documentation translation. Updated spec and SRPM: http://matt.truch.net/fedora/kst.spec http://matt.truch.net/fedora/kst-1.2.0-4.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 20:20:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 15:20:07 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602162020.k1GKK7G0026160@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From fedora at soeterbroek.com 2006-02-16 15:20 EST ------- Spec Name or Url: http://www.soeterbroek.com/linux/fedora/extras/heartbeat/heartbeat.spec SRPM Name or Url: http://www.soeterbroek.com/linux/fedora/extras/heartbeat/heartbeat-2.0.3-3.src.rpm * Thu Feb 16 2006 Joost Soeterbroek - 2.0.3-3 - removed Requires: python and gnutls - changed _libdir/ocf -> _prefix/lib/ocf - reversed subpackages depend on basepackage - removed Req swig (kept BuildReq) - added Req pygtk2 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From mmcgrath at fedoraproject.org Thu Feb 16 20:18:35 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 16 Feb 2006 14:18:35 -0600 Subject: OTRS Review for Fedora Infrastructure Message-ID: <3237e4410602161218l602aaa29wfeeb66b8890f8c4e@mail.gmail.com> Hey guys, Fedora-admin has decided to use OTRS as our official ticketing system. The only problem is its not in Core or Extras yet. If anyone gets a moment to do an official review we'd be very grateful. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180015 This system will also help us track issues like when the buildsys needs kicking or if a new feature is requested. That type of thing. -Mike From bugzilla at redhat.com Thu Feb 16 21:13:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 16:13:21 -0500 Subject: [Bug 181801] Review Request: zeroinstall-injector In-Reply-To: Message-ID: <200602162113.k1GLDLOD004216@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: zeroinstall-injector https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181801 Jochen at herr-schmitt.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-16 16:13 EST ------- Good: + Local build works. Bad: - Source contains not a fullqualified URL. - Use of %{_datadir}/man instead of %{_mandir} Questions: Why do you set CFLAGS for a noarch package? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 21:24:04 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 16:24:04 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602162124.k1GLO4le006974@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From lemenkov at newmail.ru 2006-02-16 16:23 EST ------- > About the different packages: > But about the jabber, cpl-c and pa modules, I'm not so sure. All they depend > on are libxml2, expat and pthread. I think that in any case it's a generally a good idea to split a package into a subpackages especialy if authors provide plugin-mechanism for their application. I personally prefer splitting to as many packages as could. Why break modularization and provide one big rpm? Actually, I think that the question must be "why not to split SER into subackages" rather than "why split...?" :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 21:27:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 16:27:47 -0500 Subject: [Bug 181824] New: Review Request: gstreamer08 Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181824 Summary: Review Request: gstreamer08 Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: bdpepple at ameritech.net QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://piedmont.homelinux.org/fedora/gstreamer/gstreamer08.spec SRPM Name or Url: http://piedmont.homelinux.org/fedora/gstreamer/gstreamer08-0.8.12-1.src.rpm Description: GStreamer is a streaming-media framework, based on graphs of filters which operate on media data. Applications using this library can do anything from real-time sound processing to playing videos, and just about anything else media-related. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From j.w.r.degoede at hhs.nl Thu Feb 16 21:37:20 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 16 Feb 2006 22:37:20 +0100 Subject: Help/advice with new goffice with soname change Message-ID: <43F4F090.3050008@hhs.nl> Hi, Before rebuilding gnumeric for FE I first checked for a new version, which there is, unfortunatly this needs a new goffice: 0.2.0 (current in the repo is 0.1.2) I don't know if any other packages actually uses goffice and I can't check because repoview is broken :| Anyways the problem is that 0.2.0 has changed soname. Making things more complicated is the fact that this soname change was not nescesarry at all, upstream only fixed a few bugs, they didn't even touch .h files (except version.h GRRRRR) so no abi and not even api changes. I did a full diff and this soname change was 100% not needed. So how to proceed, I would like to upgrade to 0.2.0 soon, so that if I break anything this happens before FC5. I'm actually concedering switching to 0.2.0 but applying a patch to keep the 0.1.2 soname, this seems the best to me, opinions? Regards, Hans From bugzilla at redhat.com Thu Feb 16 21:33:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 16:33:01 -0500 Subject: [Bug 180164] Review Request: muine In-Reply-To: Message-ID: <200602162133.k1GLX1sL009428@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: muine https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180164 ------- Additional Comments From foolish at guezz.net 2006-02-16 16:32 EST ------- Guess the missing gstreamer08 means we're waiting for the package to arrive in Extras, or for a new relase of muine that uses gstreamer 0.10, which ever comes first. 1. Not including the tray icon by default was a decision made upstream. My opinion is that the tray icon is shouldn't be included in the Fedora package when it's not included by default upstream, I can be convinced otherwise though. 2. Removing the dashboard plugin for now is fine by me. Updates spec, without the dashboard stuff: http://folk.ntnu.no/sindrb/packages/muine.spec SRPM: http://folk.ntnu.no/sindrb/packages/muine-0.8.4-2.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 21:40:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 16:40:59 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602162140.k1GLexhx013079@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From orion at cora.nwra.com 2006-02-16 16:40 EST ------- Okay, moving on.. :-) %package ldirectord Summary: Monitor daemon for maintaining high availability resources Group: System Environment/Daemons Requires: perl-libwww-perl Requires: perl-Crypt-SSLeay Requires: ipvsadm Requires: perl-HTML-Parser Requires: perl-LDAP #Requires: perl-Mail-IMAPClient Requires: perl-Net-DNS None of the perl stuff is needed as rpmbuild automatically picks up perl module dependencies. - Trying to install heartbeat gave me: useradd: cannot create directory /home/hacluster error: %pre(heartbeat-2.0.3-3.fc5.i386) scriptlet failed, exit status 12 error: install: %pre scriptlet failed (2), skipping heartbeat-2.0.3-3.fc5 The user creation section has to be changed. Fedora Extras packages can't create system users. You might check out http://fedoraproject.org/wiki/Packaging/UserCreation?action=show&redirect=PackageUserCreation Also, I get: useradd: cannot create directory /var/lib/heartbeat/cores/hacluster with the current useradd command, so I think you need to create the directory as part of the package (perhaps useradd doesn't use mkdir -p). - rpmlint: # rpmlint heartbeat-pils W: heartbeat-pils devel-file-in-non-devel-package /usr/lib/libpils.so ^ this should be in heartbeat-devel (or heartbeat-pils-devel) E: heartbeat-pils library-without-ldconfig-postin /usr/lib/libpils.so.1.0.0 E: heartbeat-pils library-without-ldconfig-postun /usr/lib/libpils.so.1.0.0 ^ needs: %post pils -p /sbin/ldconfig %postun pils -p /sbin/ldconfig # rpmlint heartbeat-stonith E: heartbeat-stonith library-without-ldconfig-postin /usr/lib/libstonith.so.1.0.0 E: heartbeat-stonith library-without-ldconfig-postun /usr/lib/libstonith.so.1.0.0 ^ needs: %post stonith -p /sbin/ldconfig %postun stonith -p /sbin/ldconfig W: heartbeat-stonith devel-file-in-non-devel-package /usr/lib/libstonith.so ^ should be in heartbeat-devel (or heartbeat-stonith-devel) # rpmlint -i heartbeat-ldirectord W: heartbeat-ldirectord devel-file-in-non-devel-package /usr/sbin/supervise-ldirectord-config A development file (usually source code) is located in a non-devel package. If you want to include source code in your package, be sure to create a development package. E: heartbeat-ldirectord incoherent-logrotate-file /etc/logrotate.d/ldirectord Your logrotate file should be named /etc/logrotate.d/. W: heartbeat-ldirectord non-conffile-in-etc /etc/logrotate.d/ldirectord A non-executable file in your package is being installed in /etc, but is not a configuration file. All non-executable files in /etc should be configuration files. Mark the file as %config in the spec file. E: heartbeat-ldirectord init-script-without-chkconfig-postin /etc/init.d/ldirectord The package contains an init script but doesn't contain a %post with a call to chkconfig. E: heartbeat-ldirectord init-script-without-chkconfig-preun /etc/init.d/ldirectord The package contains an init script but doesn't contain a %preun with a call to chkconfig. W: heartbeat-ldirectord service-default-enabled /etc/init.d/ldirectord The service is enabled by default after "chkconfig --add"; for security reasons, most services should not be. Use "-" as the default runlevel in the init script's chkconfig line to fix this if appropriate for this service. E: heartbeat-ldirectord subsys-not-used /etc/init.d/ldirectord While your daemon is running, you have to put a lock file in /var/lock/subsys/. To see an example, look at this directory on your machine and examine the corresponding init scripts. W: heartbeat-ldirectord incoherent-init-script-name ldirectord The init script name should be the same as the package name in lower case. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 21:46:43 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 16:46:43 -0500 Subject: [Bug 179510] Review Request: Nautilus-Flac-Converter In-Reply-To: Message-ID: <200602162146.k1GLkhDi015339@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Nautilus-Flac-Converter https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179510 bdpepple at ameritech.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From bdpepple at ameritech.net 2006-02-16 16:46 EST ------- Packages built. Thanks. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From jspaleta at gmail.com Thu Feb 16 21:56:29 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 16 Feb 2006 16:56:29 -0500 Subject: Help/advice with new goffice with soname change In-Reply-To: <43F4F090.3050008@hhs.nl> References: <43F4F090.3050008@hhs.nl> Message-ID: <604aa7910602161356g28ba5d7dldbed317cb65407d2@mail.gmail.com> On 2/16/06, Hans de Goede wrote: > I don't know if any other packages actually uses goffice and I can't > check because repoview is broken :| from my fc4 box repoquery --whatrequires --alldeps --repoid=development --repoid=extras-development goffice goffice-0:0.1.2-4.fc5.i386 gnumeric-1:1.6.1-3.i386 goffice-devel-0:0.1.2-3.i386 Looks to me like there are no other packages in Extras which hang on goffice. > So how to proceed, I would like to upgrade to 0.2.0 soon, so that if I > break anything this happens before FC5. I'm actually concedering > switching to 0.2.0 but applying a patch to keep the 0.1.2 soname, this > seems the best to me, opinions? I've no comment about how to handle this. From bugzilla at redhat.com Thu Feb 16 21:51:22 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 16:51:22 -0500 Subject: [Bug 177818] Review Request: adplug In-Reply-To: Message-ID: <200602162151.k1GLpMRL016668@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: adplug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177818 ------- Additional Comments From triad at df.lth.se 2006-02-16 16:51 EST ------- Copied in from upstream: Date: 2006-02-04 13:51 Sender: dynamite Project Admin Logged In: YES user_id=31101 adplug.db is a platform-independent file, even though it's binary. Although, indeed, it should maybe be placed into /var/lib/adplug, as the super-user is able to modify it, using adplugdb. The policy for AdPlug frontends is to always merge the system-wide database with the database in the user's home, giving preference to user-made changes. adplugdb is used by users to change their home databases. The superuser can use it (with the -s option) to change the system-wide database. The system-wide database should provide a default source for common database entries, any user should want to have in their database, so it is probably very seldomly written to. What does the FHS say to such files? Do they go to /var/lib? If so, i will change it in AdPlug's CVS. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From notting at redhat.com Thu Feb 16 21:57:32 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 16 Feb 2006 16:57:32 -0500 Subject: Help/advice with new goffice with soname change In-Reply-To: <604aa7910602161356g28ba5d7dldbed317cb65407d2@mail.gmail.com> References: <43F4F090.3050008@hhs.nl> <604aa7910602161356g28ba5d7dldbed317cb65407d2@mail.gmail.com> Message-ID: <20060216215732.GA7802@devserv.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > > So how to proceed, I would like to upgrade to 0.2.0 soon, so that if I > > break anything this happens before FC5. I'm actually concedering > > switching to 0.2.0 but applying a patch to keep the 0.1.2 soname, this > > seems the best to me, opinions? > > I've no comment about how to handle this. Bad idea. Just upgrade and deal with the apps that need it. Bill From bugzilla at redhat.com Thu Feb 16 22:03:25 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 17:03:25 -0500 Subject: [Bug 180164] Review Request: muine In-Reply-To: Message-ID: <200602162203.k1GM3PNo020103@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: muine https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180164 ------- Additional Comments From bdpepple at ameritech.net 2006-02-16 17:03 EST ------- I just submitted the gstreamer 0.8 package for review, since I also need it for gnomebaker. Any reviews would be welcome. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181824 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From buildsys at fedoraproject.org Thu Feb 16 22:12:36 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 16 Feb 2006 17:12:36 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060216221236.5A4758011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 3 acpitool-0.4.4-1.fc3.1 freehdl-0.0.1-3.fc3 git-1.2.1-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu Feb 16 22:12:53 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 16 Feb 2006 17:12:53 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060216221253.D7AA28011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 10 acpitool-0.4.4-1.fc4.1 bittorrent-4.4.0-1.fc4 freehdl-0.0.1-3.fc4 fuse-encfs-1.2.5-1.fc4 git-1.2.1-1.fc4 libibverbs-1.0-0.5.rc7.fc4 lyx-1.3.7-5.fc4 nautilus-flac-converter-0.0.2-2.fc4 rlog-1.3.7-1.fc4 trac-0.9.4-2.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu Feb 16 22:14:00 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 16 Feb 2006 17:14:00 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060216221400.7AAA78011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 100 acpitool-0.4.4-1.fc5 acpitool-0.4.4-1.fc5.1 aiksaurus-1.2.1-11 alacarte-0.8-7.fc5 asa-1.2-2.fc5 bluefish-1.0.5-2.fc5 cvsgraph-1.6.0-2.fc5 digikamimageplugins-0.8.1-1.fc5 dumpasn1-20050404-2.fc5 dvdisaster-0.65-2.fc5 freehdl-0.0.1-3.fc5 galculator-1.2.5-4.fc5 gentium-fonts-1.02-3 ghdl-0.22-0.39svn.0.fc5 git-1.2.1-1.fc5 gkrellm-hddtemp-0.2-0.5.beta.fc5 gnome-applet-netspeed-0.13-5.fc5 gnome-common-2.12.0-2.fc5 gnome-translate-0.99-6.fc5 gnotime-2.2.2-4.fc5 gnupg2-1.9.20-2.fc5 grace-5.1.19-3.fc5 grace-5.1.19-4.fc5 grepmail-5.3032-3.fc5 gtkmathview-0.7.6-3.fc5 gtkwave-1.3.83-2.fc5 http_ping-20050629-3.fc5 icecast-2.3.1-1.fc5 ipxripd-0.8-3.fc5 itcl-3.3-0.4.RC1.fc5 jlint-1.21-5.fc5 lft-2.5-2.fc5 libgnomedb-1.9.100-5.fc5 libibverbs-1.0-0.5.rc7.fc5 libresample-0.1.3-2.fc5 libtranslate-0.99-5.fc5 libxfce4mcs-4.2.3-5.fc5 libxfce4util-4.2.3.2-2.fc5 libxfcegui4-4.2.3-4.fc5 makebootfat-1.4-3.fc5 nail-11.25-6.fc5 netmask-2.3.7-5.fc5 newscache-1.2-0.3.rc6.fc5 pam_usb-0.3.3-4.fc5 perl-Crypt-DH-0.06-4.fc5 perl-Crypt-SmbHash-0.12-3.fc5 perl-Date-Simple-3.02-3.fc5 perl-Devel-Cycle-1.04-4.fc5 perl-FileHandle-Unget-0.1621-2.fc5 perl-FreezeThaw-0.43-4.fc5 perl-GDTextUtil-0.86-7.fc5 perl-IPC-SharedCache-1.3-6.fc5 perl-Image-Base-1.07-6.fc5 perl-Mail-Mbox-MessageParser-1.4002-2.fc5 perl-Math-GMP-2.04-3.fc5 perl-TeX-Hyphen-0.140-4.fc5 perl-Text-Iconv-1.4-4.fc5 perl-Text-Template-1.44-3.fc5 perl-Tie-IxHash-1.21-5.fc5 pexpect-2.0-2.fc5 pgadmin3-1.4.1-2.fc5 phpldapadmin-0.9.7.2-3 pscan-1.2-2.fc5 pygsl-0.3.2-5.fc5 python-docutils-0.4-2.fc5 qa-assistant-0.4.1-4.fc5 tcllib-1.8-4.fc5 tkcon-2.4-3.fc5 tklib-0.4.1-4.fc5 trac-0.9.4-1.fc5 translate-toolkit-0.8-0.9.rc6.fc5 ttf2pt1-3.4.4-7.fc5 verbiste-0.1.14-1.1.fc5 vpnc-0.3.3-6 workrave-1.8.2-2.fc5 xfce-mcs-manager-4.2.3-2.fc5 xfce4-battery-plugin-0.3.0-5.fc5 xfce4-clipman-plugin-0.4.1-5.fc5 xfce4-cpugraph-plugin-0.2.2-5.fc5 xfce4-datetime-plugin-0.3.1-6.fc5 xfce4-diskperf-plugin-1.5-5.fc5 xfce4-fsguard-plugin-0.2.1-3.fc5 xfce4-genmon-plugin-1.1-5.fc5 xfce4-minicmd-plugin-0.3.0-5.fc5 xfce4-modemlights-plugin-0.1.1-6.fc5 xfce4-notes-plugin-0.11.1-3.fc5 xfce4-quicklauncher-plugin-0.81-3.fc5 xfce4-screenshooter-plugin-0.0.8-2.fc5 xfce4-showdesktop-plugin-0.4.0-5.fc5 xfce4-systemload-plugin-0.3.6-5.fc5 xfce4-taskbar-plugin-0.2.2-5.fc5 xfce4-taskmanager-0.3.1-3.fc5 xfce4-wavelan-plugin-0.4.1-5.fc5 xfce4-weather-plugin-0.4.9-5.fc5 xfce4-websearch-plugin-0.1.0-5.fc5 xfce4-windowlist-plugin-0.1.0-5.fc5 xfce4-xkb-plugin-0.3.2-6.fc5 xfce4-xmms-plugin-0.3.1-5.fc5 ytalk-3.3.0-3 yumex-0.99.9-1.0.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Thu Feb 16 22:19:58 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 17:19:58 -0500 Subject: [Bug 181035] Review Request: luks-tools In-Reply-To: Message-ID: <200602162219.k1GMJwl0024197@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: luks-tools https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181035 ------- Additional Comments From redhat at flyn.org 2006-02-16 17:19 EST ------- Spec Name or Url: http://www.flyn.org/SRPMS/luks-tools.spec SRPM Name or Url: http://www.flyn.org/SRPMS/luks-tools-0.0.8-2.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 22:21:42 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 17:21:42 -0500 Subject: [Bug 181445] Review Request: php-shout In-Reply-To: Message-ID: <200602162221.k1GMLg9N024724@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-shout https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181445 ------- Additional Comments From holbrookbw at users.sourceforge.net 2006-02-16 17:21 EST ------- Spec Name or Url: http://prdownloads.sourceforge.net/phpshout/php-shout.spec?download SRPM Name or Url: http://prdownloads.sourceforge.net/phpshout/php-shout-0.1.4-1.src.rpm?download Thanks for the review! Both of these issues have been fixed in this next release. I also made some other ./configure fixes to better detect libshout's compile-time dependencies with pkg-config and link in the appropriate libraries, resulting in release 0.1.4 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From j.w.r.degoede at hhs.nl Thu Feb 16 22:52:58 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 16 Feb 2006 23:52:58 +0100 Subject: goffice upgrade notice Message-ID: <43F5024A.70700@hhs.nl> Hi all, I've just had a trainride home from work and thus had the time to think about this and I've come to the same conclusion as Bill Nottingham in reply to my previous post on this: Even though upstream shouldn't have unnecessary changed the soname, patching the newer version to keep the old soname is a _bad_ idea, this will cause problems with non FE prebuilt binaries and packages from other repos. Also since there really are no changes only bugfixes in this new release, fixen any broken deps will require just a rebuild and since we're already doing the rebuild limbo I'll add goffice in the mix :) Thus I'm pushing a new goffice asap, with a new soname. AFAIK besides gnumeric wich will get pushed immediatly after goffice there are no packages depending on this, if there are: -a rebuild will be nescesarry (sorry) -please let me know, for future reference Regards, Hans From bugzilla at redhat.com Thu Feb 16 22:53:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 17:53:01 -0500 Subject: [Bug 181445] Review Request: php-shout In-Reply-To: Message-ID: <200602162253.k1GMr1dQ032693@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-shout https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181445 ------- Additional Comments From holbrookbw at users.sourceforge.net 2006-02-16 17:52 EST ------- One other thing, when I started this PHP extension project, I named it "phpShout", and registered as such under sourceforge. However, when packaging it up for Fedora, it made much more sense to name the package "php-shout", in the age-old 'package-subpackage' format. Is this a violation of FE's Naming Guidelines, that the RPM doesn't match the tarball? The Wiki told me to "use your best judgment", and that "other developers will help in the final decision." I'd much prefer to call it php-shout, and CAN rename the upstream source for future versions. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 23:05:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 18:05:07 -0500 Subject: [Bug 181831] New: Review Request: bitbake - Build Tool Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181831 Summary: Review Request: bitbake - Build Tool Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: andreas at bawue.net QAContact: fedora-extras-list at redhat.com Spec Name or http://helena.bawue.de/~ixs/bitbake/bitbake.spec SRPM Name or Url: http://helena.bawue.de/~ixs/bitbake/bitbake-1.3.3-1.src.rpm Description: BitBake is a simple tool for the execution of tasks. It is derived from Portage, which is the package management system used by the Gentoo Linux distribution. It is most commonly used to build packages, and is used as the basis of the OpenEmbedded project. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From pmatilai at laiskiainen.org Thu Feb 16 23:18:33 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 17 Feb 2006 01:18:33 +0200 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1140112368.16146.3.camel@bobcat.mine.nu> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214124313.765c0ca5.bugs.michael@gmx.net> <1139925078.12023.366.camel@mccallum.corsepiu.local> <20060214160016.728239dd.bugs.michael@gmx.net> <1139933804.12023.407.camel@mccallum.corsepiu.local> <604aa7910602140825i50884cbfi201bb2df29246d69@mail.gmail.com> <1139948390.10711.7.camel@bobcat.mine.nu> <1140112368.16146.3.camel@bobcat.mine.nu> Message-ID: <1140131913.8099.41.camel@weasel.turre.laiskiainen.org> On Thu, 2006-02-16 at 19:52 +0200, Ville Skytt? wrote: > On Thu, 2006-02-16 at 07:02 -0800, Panu Matilainen wrote: > > > What's stopping people from applying the one-liner patch repoquery in the > > yum-utils FE package if it's considered that important? > > Quite frankly, that's something I'd expect from the package maintainer. > Or alternatively, an indication that someone else can go ahead if he's > too busy to take care of it. Yum-utils in FE seems to be a bit of an orphan... Quite a bit of stuff happens upstream but getting a new release out has been hanging between to-fork-or-not-to-fork from 2.4.x for months now (feel free to blame me for that) Really, if people think having working yumdownloader + repoquery in rawhide *right now* is important, somebody just apply the patches from https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175335 to yum-utils in FE, and do that two months ago if you ask me :) A new yum-utils release will come sooner or later but right now I'm having a handful with my current project(s) with little time for anything else. - Panu - From bugzilla at redhat.com Thu Feb 16 23:11:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 18:11:28 -0500 Subject: [Bug 181831] Review Request: bitbake - Build Tool In-Reply-To: Message-ID: <200602162311.k1GNBSun004753@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: bitbake - Build Tool https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181831 ------- Additional Comments From andreas at bawue.net 2006-02-16 18:11 EST ------- JFTR: rpmlint complains about some .py scripts not being set to executable. This makes sense, as not all of these scripts have the #!/usr/bin/python header included. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 16 23:47:39 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 18:47:39 -0500 Subject: [Bug 180747] Review Request: powerman In-Reply-To: Message-ID: <200602162347.k1GNld1u012004@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: powerman https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180747 ------- Additional Comments From woodard at redhat.com 2006-02-16 18:47 EST ------- The upstream author fixed powerman so that it will compile on FC4 cleanly. I rolled a new release of the packages. Could you run this through the review process again. http://osdn.dl.sourceforge.net/sourceforge/powerman/powerman.spec http://osdn.dl.sourceforge.net/sourceforge/powerman/powerman-1.0.23-2.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From nman64 at n-man.com Fri Feb 17 00:06:24 2006 From: nman64 at n-man.com (Patrick Barnes) Date: Thu, 16 Feb 2006 18:06:24 -0600 Subject: [ANN] Fedora Project Wiki Policy Change Message-ID: <200602161806.29490.nman64@n-man.com> The Fedora Foundation has decided that all Fedora documentation, including the fedoraproject.org wiki, will be licensed under the terms of the Open Publication License 1.0[1] without options. Unfortunately, the Fedora Project does not have copyright privileges over the wiki's existing content. Since we have allowed anyone to edit the wiki without any sort of licensing or copyright assignment, we cannot cover the existing content without the agreement of each contributor. To solve this issue, we have come up with a plan[2]. Our plan will require that all contributors complete the CLA in the Fedora Account System[3] before joining the EditGroup. In order to facilitate our new changes, the EditGroup will be frozen effective immediately and through the weekend. Those of you who are in the EditGroup can continue to make edits during that time, but no new contributors are to be added to the EditGroup during the freeze. Everyone who is in the EditGroup but has not completed the CLA will be removed after this weekend. If you are currently in the EditGroup and have not completed the CLA, please take the time to do so now. This agreement will allow us to license your contributions under the OPL. If you have completed the CLA, but are removed after the weekend, contact someone in the revised EditGroup to add you again. All current EditGroup members who are removed will have their name added to a tracking page[4]. If your name is moved to that list, you will need to complete the CLA and remove yourself from the list to indicate that you agree to having your past contributions licensed under the OPL. DO NOT REMOVE OTHERS from this list. It will be monitored. After an undetermined waiting period, all contributions made by names still on this list will be removed from the wiki. If you would like to learn more about our licensing and other legal terms, visit the Legal page[5] on the wiki. [1] http://fedoraproject.org/wiki/Legal/Licenses/OPL [2] http://fedoraproject.org/wiki/WikiLicenseTalk [3] http://fedoraproject.org/wiki/Infrastructure/AccountSystem [4] http://fedoraproject.org/wiki/UnlicensedGroup [5] http://fedoraproject.org/wiki/Legal -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ -- Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -------------- 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 Fri Feb 17 01:18:47 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 16 Feb 2006 20:18:47 -0500 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-02-17 Message-ID: <200602170118.k1H1Il8E024147@mx1.redhat.com> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- aiksaurus-devel 1:1.2.1-11.i386 aiksaurus-gtk 1:1.2.1-11.i386 aiksaurus-gtk-devel 1:1.2.1-11.i386 amarok 1.3.6-1.fc5.i386 at-poke 0.2.2-2.i386 cyrus-imapd 2.2.12-6.fc4.i386 cyrus-imapd-murder 2.2.12-6.fc4.i386 cyrus-imapd-nntp 2.2.12-6.fc4.i386 cyrus-imapd-utils 2.2.12-6.fc4.i386 gnomebaker 0.5.1-2.fc5.i386 gstreamer08-python 0.8.3-1.fc5.i386 istanbul 0.1.1-5.i386 libgdamm 1.3.7-2.fc5.i386 octave-forge 2005.06.13-4.fc5.i386 pam_mount 0.9.25-4.i386 perl-Cyrus 2.2.12-6.fc4.i386 sabayon-admin 2.12.1-2.i386 scalapack 1.7-7.fc4.i386 seahorse 0.7.9-1.fc5.i386 soundconverter 0.8.3-1.fc5.noarch tidy-devel 0.99.0-8.20051025.fc5.i386 tripwire 2.3.1-22.i386 up-imapproxy 1.2.4-4.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- aiksaurus-devel 1:1.2.1-11.ppc aiksaurus-gtk 1:1.2.1-11.ppc aiksaurus-gtk-devel 1:1.2.1-11.ppc amarok 1.3.6-1.fc5.ppc at-poke 0.2.2-2.ppc cyrus-imapd 2.2.12-6.fc4.ppc cyrus-imapd-murder 2.2.12-6.fc4.ppc cyrus-imapd-nntp 2.2.12-6.fc4.ppc cyrus-imapd-utils 2.2.12-6.fc4.ppc gnomebaker 0.5.1-2.fc5.ppc gstreamer08-python 0.8.3-1.fc5.ppc istanbul 0.1.1-5.ppc libgdamm 1.3.7-2.fc5.ppc octave-forge 2005.06.13-4.fc5.ppc pam_mount 0.9.25-4.ppc perl-Cyrus 2.2.12-6.fc4.ppc sabayon-admin 2.12.1-2.ppc scalapack 1.7-7.fc4.ppc seahorse 0.7.9-1.fc5.ppc soundconverter 0.8.3-1.fc5.noarch tidy-devel 0.99.0-8.20051025.fc5.ppc up-imapproxy 1.2.4-4.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- aiksaurus-devel 1:1.2.1-11.x86_64 aiksaurus-gtk 1:1.2.1-11.x86_64 aiksaurus-gtk-devel 1:1.2.1-11.x86_64 amarok 1.3.6-1.fc5.x86_64 at-poke 0.2.2-2.x86_64 cernlib 2005-7.fc5.x86_64 cernlib-packlib 2005-7.fc5.x86_64 cyrus-imapd 2.2.12-6.fc4.x86_64 cyrus-imapd-murder 2.2.12-6.fc4.x86_64 cyrus-imapd-nntp 2.2.12-6.fc4.x86_64 cyrus-imapd-utils 2.2.12-6.fc4.x86_64 gnomebaker 0.5.1-2.fc5.x86_64 gstreamer08-python 0.8.3-1.fc5.x86_64 istanbul 0.1.1-5.x86_64 libgdamm 1.3.7-2.fc5.x86_64 octave-forge 2005.06.13-4.fc5.x86_64 pam_mount 0.9.25-4.x86_64 paw 2005-7.fc5.x86_64 perl-Cyrus 2.2.12-6.fc4.x86_64 sabayon-admin 2.12.1-2.x86_64 scalapack 1.7-7.fc4.x86_64 seahorse 0.7.9-1.fc5.x86_64 soundconverter 0.8.3-1.fc5.noarch tidy-devel 0.99.0-8.20051025.fc5.x86_64 up-imapproxy 1.2.4-4.fc5.x86_64 ---------------------------------------------------------------------- New report for: uwog AT uwog.net package: aiksaurus-devel - 1:1.2.1-11.i386 from fedora-extras-development-i386 unresolved deps: aiksaurus = 0:1.2.1-11 From kevin-fedora-extras at scrye.com Fri Feb 17 01:42:55 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Thu, 16 Feb 2006 18:42:55 -0700 (MST) Subject: apg and p0f maintainership References: <20060208.172244.480637624.kevin@scrye.com> Message-ID: <20060216.184255.565480992.kevin@scrye.com> >>>>> "Kevin" == Kevin Fenzi writes: Kevin> I see that apg and p0f are orphaned currently. Kevin> If no one else would like to maintain them I would be happy to Kevin> do so. Neither package has any open bugs in bugzilla. Kevin> The upsteam apg web page appears to be down, but hopefully Kevin> thats transitory. Kevin> Will wait a few days and see if anyone else is interested Kevin> before taking them on. To follow up on myself... Since I haven't seen anyone jump in, I am going to take ownership of them and fire off some fc5 rebuilds for them. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugzilla at redhat.com Fri Feb 17 01:40:12 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 20:40:12 -0500 Subject: [Bug 175502] Review Request: perl-Gtk2-Spell In-Reply-To: Message-ID: <200602170140.k1H1eCDX032581@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Gtk2-Spell https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175502 ------- Additional Comments From cweyl at alumni.drew.edu 2006-02-16 20:40 EST ------- Updated spec/srpm: Spec Name or Url: http://www.mindspring.com/~cweyl/perl-Gtk2-Spell/perl-Gtk2-Spell.spec SRPM Name or Url: http://www.mindspring.com/~cweyl/perl-Gtk2-Spell/perl-Gtk2-Spell-1.03-1.ckw.fc4.src.rpm TODOs from #3 addressed; release tag reset to 1. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 17 01:52:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 20:52:09 -0500 Subject: [Bug 177584] Review Request: zaptel In-Reply-To: Message-ID: <200602170152.k1H1q9P4001501@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: zaptel https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177584 ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-16 20:52 EST ------- Updated Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/zaptel-1.2.4-1.spec SRPM Name or Url: http://www.ocjtech.us/zaptel-1.2.4-1.src.rpm %changelog * Wed Feb 15 2006 Jeffrey C. Ollie - 1.2.4-1 - Update to 1.2.4 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 17 01:54:43 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 20:54:43 -0500 Subject: [Bug 177583] Review Request: zaptel-kmod In-Reply-To: Message-ID: <200602170154.k1H1sh5U001834@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: zaptel-kmod https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177583 ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-16 20:54 EST ------- Updated Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.4-1.2.6.15_1.1939_FC5.spec SRPM Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.4-1.2.6.15_1.1939_FC5.src.rpm %changelog * Wed Feb 15 2006 Jeffrey C. Ollie - 1.2.4-1 - Update to 1.2.4. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From dennis at ausil.us Fri Feb 17 02:10:53 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 16 Feb 2006 20:10:53 -0600 Subject: Snort Message-ID: <200602162010.58313.dennis@ausil.us> Just letting people know im taking ove maintainership of snort -- Dennis Gilmore, RHCE http://www.ausil.us Proud Australian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From michael at knox.net.nz Fri Feb 17 02:15:39 2006 From: michael at knox.net.nz (Michael J Knox) Date: Fri, 17 Feb 2006 15:15:39 +1300 Subject: Snort In-Reply-To: <200602162010.58313.dennis@ausil.us> References: <200602162010.58313.dennis@ausil.us> Message-ID: <1140142539.5231.4.camel@cosima.et.endace.com> On Thu, 2006-02-16 at 20:10 -0600, Dennis Gilmore wrote: > Just letting people know im taking ove maintainership of snort > Snort inline fails to build, it was talked about on -devel@ and I think the jist was that glibc-kernheaders did not provide what was needed. Michael From dennis at ausil.us Fri Feb 17 02:22:36 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 16 Feb 2006 20:22:36 -0600 Subject: Snort In-Reply-To: <1140142539.5231.4.camel@cosima.et.endace.com> References: <200602162010.58313.dennis@ausil.us> <1140142539.5231.4.camel@cosima.et.endace.com> Message-ID: <200602162022.41704.dennis@ausil.us> Once upon a time Thursday 16 February 2006 8:15 pm, Michael J Knox wrote: > On Thu, 2006-02-16 at 20:10 -0600, Dennis Gilmore wrote: > > Just letting people know im taking ove maintainership of snort > > Snort inline fails to build, it was talked about on -devel@ and I think > the jist was that glibc-kernheaders did not provide what was needed. > > Michael ok ill look at it the package from extras does not build inline -- Dennis Gilmore, RHCE http://www.ausil.us Proud Australian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugzilla at redhat.com Fri Feb 17 04:59:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2006 23:59:16 -0500 Subject: [Bug 180015] Review Request: OTRS - Open Ticket Request System In-Reply-To: Message-ID: <200602170459.k1H4xGwK004180@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: OTRS - Open Ticket Request System https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180015 ------- Additional Comments From tibbs at math.uh.edu 2006-02-16 23:59 EST ------- >From a quick scan, I think you might need to alter the way the otrs user is created. http://fedoraproject.org/wiki/Packaging/UserCreation -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 17 06:00:22 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 01:00:22 -0500 Subject: [Bug 175844] Review Request: wmx -- really simple and basic X window manager In-Reply-To: Message-ID: <200602170600.k1H60MjX018443@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: wmx -- really simple and basic X window manager https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175844 ivazquez at ivazquez.net changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |177841 nThis| | ------- Additional Comments From ivazquez at ivazquez.net 2006-02-17 01:00 EST ------- Built under FC4 and devel, but the sponsorship process isn't complete. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 17 06:49:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 01:49:11 -0500 Subject: [Bug 181445] Review Request: php-shout In-Reply-To: Message-ID: <200602170649.k1H6nBQB029024@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-shout https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181445 ------- Additional Comments From ville.skytta at iki.fi 2006-02-17 01:49 EST ------- php-shout is fine. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 17 08:27:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 03:27:59 -0500 Subject: [Bug 166547] Review Request: multisync - Calendar (and other PIM data) synchronization program In-Reply-To: Message-ID: <200602170827.k1H8RxDK014520@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multisync - Calendar (and other PIM data) synchronization program https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166547 ------- Additional Comments From andreas.bierfert at lowlatency.de 2006-02-17 03:27 EST ------- I think it is quiet unstable at this point altough I managed to get some data of my synce device (the plugin is not release yet). Tough due to a lack of alternatives I rather get this into the repo (otherwise libopensync-* is kind of useless)... I will add a desktop file and repost a new rpm... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rc040203 at freenet.de Fri Feb 17 10:30:07 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 17 Feb 2006 11:30:07 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1140110380.8099.23.camel@weasel.turre.laiskiainen.org> References: <1139851362.2904.79.camel@localhost.localdomain> <20060213195503.776b3aee.bugs.michael@gmx.net> <1139898018.19586.40.camel@thl.ct.heise.de> <20060214124313.765c0ca5.bugs.michael@gmx.net> <1139925078.12023.366.camel@mccallum.corsepiu.local> <20060214160016.728239dd.bugs.michael@gmx.net> <1139933804.12023.407.camel@mccallum.corsepiu.local> <604aa7910602140825i50884cbfi201bb2df29246d69@mail.gmail.com> <1139936636.30045.25.camel@mccallum.corsepiu.local> <1140103763.21764.100.camel@mccallum.corsepiu.local> <1140110380.8099.23.camel@weasel.turre.laiskiainen.org> Message-ID: <1140172207.21764.285.camel@mccallum.corsepiu.local> On Thu, 2006-02-16 at 19:19 +0200, Panu Matilainen wrote: > On Thu, 2006-02-16 at 16:29 +0100, Ralf Corsepius wrote: > > On Thu, 2006-02-16 at 07:07 -0800, Panu Matilainen wrote: > > > On Tue, 14 Feb 2006, Ralf Corsepius wrote: > > > >> > > > >> the repoquery isn't enough to provide the necessary information to > > > >> learn about dependancy chains to allow for maintainer coordination? > > > > No. > > > > > > > > [Personal side-note: I hate repoquery. > > > > > > Heh, care to elaborate? I'm open to suggestions you know :) > > > > Speed, usability, package deps (of yum and yum-utils). > > Speed and dependencies I can't help directly, usability suggestions are > most welcome. Repoquery started with some sort of "rpm -q" compatibility > in mind and that's why it's the way it is. Suggestions are most welcome, > the rpm -q compatibility is an illusion at best anyway. > > > > > It's way less useable than its apt-get counterparts] > > > > > > What apt-get counterparts? > > > > apt-get build-dep > > apt-get --build source > > > > Do you need anything else? > > Repoquery isn't inteded for that, so no wonder you don't like it for > these purposes :) I am using "apt-get build-deps" and "apt-get source" as "poor man's fast mock/package depchecker" and as part of scripts for local mass rebuilds (Basically the same working principle as mach used to use, but without the chroot). > > rpm -U package.src.rpm > > edit package.spec > > [rebuild package] > > > > This even works sufficiently well on underpowered machines with low > > bandwidth connections, and is much less resource demanding than yum is. > > I haven't done any actual comparisons memory-wise between apt and yum in > long time, Neither have I. Half a year ago or so, yum's memory requirements were highly sensible on my old i586/166MHz 64MB notebook (Very slow HD w/o DMA). The typical "yum update w/ FC and FE enabled" was in the 1/2+ hours range. Trying an upgrade from an older FC to a newer FC (IIRC it was FC3->FC4) took ca 4 hours per yum invocation (until it finally aborted with unresolvable deps). The primary cause for this slowlyness obviously had been yum's memory requirement, which had caused this machine to swap permanently. Meanwhile, yum's memory requirements seem to have shrunk, because now (FC4/FE4 + all updates) a "yum update" doesn't cause this machine to swap anymore and yum/apt's turn-around times are in the same magnitude. > but yum >= 2.4 has far lower memory requirements than it used > to have, thanks to sqlite. Yes, with yum-2.4, yum finally became usable on my old notebook ;) Ralf From bugzilla at redhat.com Fri Feb 17 10:42:41 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 05:42:41 -0500 Subject: [Bug 181753] Review Request: mm - Shared memory allocation library In-Reply-To: Message-ID: <200602171042.k1HAgfFb010915@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mm - Shared memory allocation library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181753 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-17 05:42 EST ------- In general: Please increase the release count for eatch new relase of your package. You should do this even for the review process. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 17 10:50:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 05:50:30 -0500 Subject: [Bug 175502] Review Request: perl-Gtk2-Spell In-Reply-To: Message-ID: <200602171050.k1HAoUOZ012260@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Gtk2-Spell https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175502 ------- Additional Comments From rc040203 at freenet.de 2006-02-17 05:50 EST ------- Please remove the perl_* stuff at the very beginning of the spec. Also, please don't reset the release tag, and increment it instead even during reviews. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 17 12:00:43 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 07:00:43 -0500 Subject: [Bug 181445] Review Request: php-shout In-Reply-To: Message-ID: <200602171200.k1HC0hMS024160@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-shout https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181445 ------- Additional Comments From dmitry at butskoy.name 2006-02-17 07:00 EST ------- The Fedora style of the name of the php-module-packages is "php-MODULE_NAME", irrespective of how they are named upstream. (It seems to be some precedent rule). php-shout is fine. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 17 12:36:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 07:36:49 -0500 Subject: [Bug 178310] Review Request: w3c-libwww - An HTTP library of common code In-Reply-To: Message-ID: <200602171236.k1HCan1g031780@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: w3c-libwww - An HTTP library of common code https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178310 ------- Additional Comments From andreas.bierfert at lowlatency.de 2006-02-17 07:36 EST ------- Hm before I go out and push this: wmweather+ does not build because a header is missing (actually the config header from w3c-libww). I will see if I can fix this in wmweather+ or if it really should be fixed here before publishing it... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 17 15:26:06 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 10:26:06 -0500 Subject: [Bug 176532] Review Request: TurboGears: Back-to-front web development in Python In-Reply-To: Message-ID: <200602171526.k1HFQ6Yr004726@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: TurboGears: Back-to-front web development in Python https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176532 ------- Additional Comments From jpmahowald at gmail.com 2006-02-17 10:25 EST ------- Keeps failing with: Reading http://www.turbogears.org/download/index.html error: Download error: (-3, 'Temporary failure in name resolution') error: Bad exit status from /var/tmp/rpm-tmp.31584 (%install) Even if the Internet should be working here, I don't think a web site should have to be up for package building to continue. Web site is referenced in the setup.cfg file. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 17 15:58:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 10:58:28 -0500 Subject: [Bug 169717] Review Request: Internode DSL usage applet In-Reply-To: Message-ID: <200602171558.k1HFwSa7013222@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Internode DSL usage applet https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169717 ------- Additional Comments From jpmahowald at gmail.com 2006-02-17 10:58 EST ------- Also, I may not be able to make this noarch, because bonobo is installed at %{_libdir}. Even though the only thing it puts there is a single text file. I will have to rework the setup patch. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 17 16:17:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 11:17:21 -0500 Subject: [Bug 181803] Review Request: scrub In-Reply-To: Message-ID: <200602171617.k1HGHLt9017242@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: scrub https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181803 ------- Additional Comments From bdpepple at ameritech.net 2006-02-17 11:17 EST ------- I don't have permission to sponser you, but here's an initial package review. MD5Sum: faf66a307afbd06d57f617fa3176870f scrub-1.7.tar.bz2 Good: * Source URL is canonical * Upstream source tarball verified * Package name conforms to the Fedora Naming Guidelines * Buildroot has all required elements * All paths begin with macros * All necessary BuildRequires listed. * Files have appropriate permissions and owners * Package builds fine in Mock for FC5. * Rpmlint does not find problems Bad: * Missing (rm -rf $RPM_BUILD_ROOT) at beginning of %install section. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From buildsys at fedoraproject.org Fri Feb 17 17:03:15 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 17 Feb 2006 12:03:15 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060217170315.5B6F48011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 3 lyx-1.3.7-5.fc3.2 snort-2.4.3-1.fc3 wine-docs-0.9.8-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri Feb 17 17:04:05 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 17 Feb 2006 12:04:05 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060217170405.79AEF8011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 10 Glide3-20050815-1.fc4 cernlib-2005-12.fc4 gajim-0.9.1-1.fc4 ghdl-0.22-0.39svn.0.fc4 libmthca-1.0-0.5.rc7.fc4 numpy-0.9.5-1.fc4 qhull-2003.1-5.fc4 rpy-0.4.6-6.fc4 snort-2.4.3-1.fc4 wmx-6pl1-7.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Fri Feb 17 17:00:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 12:00:30 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602171700.k1HH0US4028138@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From orion at cora.nwra.com 2006-02-17 12:00 EST ------- I'll second Ed's comments. As for man pages, while it's not an issue for openmpi/lam at the moment, it will be, and it is for lam/mpich. So, how do you handle the conflicting man pages? Can we install in /usr/share//man? Is that acceptable? I'm facing the same issue with ncarg conflicting with some generic man3 names from allegro. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From buildsys at fedoraproject.org Fri Feb 17 17:06:07 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 17 Feb 2006 12:06:07 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060217170607.13E728011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 92 Terminal-0.2.4-7.fc5 WindowMaker-0.92.0-6.fc5 abiword-2.4.2-6.fc5 aiksaurus-1.2.1-12 aiksaurus-1.2.1-13 apg-2.3.0b-3.fc5 aterm-1.0.0-3.fc5 bochs-2.2.6-1.fc5 bzflag-2.0.4-3 cdo-0.9.6-5.fc5 centericq-4.21.0-5.fc5 cernlib-2005-13.fc5 cppunit-1.11.4-2.fc5 dbh-1.0.24-4.fc5 deskbar-applet-2.13.91-2.fc5 esmtp-0.5.1-11.fc5 exo-0.3.0-12.fc5 freealut-1.0.0-3.fc5 gnumeric-1.6.2-1.fc5 goffice-0.2.0-1.fc5 grads-1.9b4-8.fc5 gtk-xfce-engine-2.2.8-2.fc5 intuitively-0.7-8.fc5 libnet-1.1.2.1-8.fc5 libnet10-1.0.2a-10.fc5 libopensync-0.18-6.fc5 libopensync-plugin-evolution2-0.18-6.fc5 libopensync-plugin-file-0.18-4.fc5 libopensync-plugin-irmc-0.18-5.fc5 libopensync-plugin-palm-0.18-3.fc5 libopensync-plugin-python-0.18-4.fc5 libpolyxmass-0.9.0-6.fc5 libpqxx-2.5.5-7.fc5 moin-latex-0-0.20051126.2.fc5 munin-1.2.4-6.fc5 ncmpc-0.11.1-5.fc5 nco-3.0.2-2.fc5 ncview-1.92e-7.fc5 netcdf-3.6.0-10.p1.fc5 numpy-0.9.5-1.fc5 openal-0.0.9-0.3.20060204cvs.fc5 osiv-0.1.1-4.fc5 p0f-2.0.5-4.fc5 pam_ssh-1.91-14.fc5 perl-Parse-Yapp-1.05-35.fc5 perl-String-Ediff-0.08-3.fc5 perl-Tk-804.027-9.fc5 polyxmass-bin-0.9.0-2.fc5 polyxmass-common-0.8.7-5.fc5 polyxmass-data-0.8.6-4.fc5 polyxmass-doc-0.8.8-2.fc5 ppracer-0.3.1-6 python-cheetah-1.0-2.fc5 qhull-2003.1-5.fc5 qiv-2.0-4 rpy-0.4.6-6.fc5 rxvt-2.7.10-9.fc5 rxvt-unicode-7.6-2.fc5 scribus-1.2.4.1-4.fc5 scribus-templates-1.2.1-3 smb4k-0.6.7-3.fc5 snort-2.4.3-1.fc5 sword-1.5.8-7.fc5 sylpheed-claws-2.0.0-2.fc5 sylpheed-claws-plugins-2.0.0-2.fc5 torsmo-0.18-5.fc5 treecc-0.3.8-2.fc5 ufraw-0.6-2 unshield-0.5-3.fc5 wine-docs-0.9.8-1.fc5 wmCalClock-1.25-6.fc5 wmacpi-1.34-6.fc5 wmapmload-0.3.4-4.fc5 wmx-6pl1-7.fc5 wv2-0.2.2-7.fc5 xfcalendar-4.2.3-2.fc5 xfce-mcs-plugins-4.2.3-3.fc5 xfce-utils-4.2.3-3.fc5 xfce4-appfinder-4.2.3-2.fc5 xfce4-icon-theme-4.2.3-2.fc5 xfce4-iconbox-4.2.3-3.fc5 xfce4-mixer-4.2.3-2.fc5 xfce4-panel-4.2.3-3.fc5 xfce4-session-4.2.3-3.fc5 xfce4-systray-4.2.3-2.fc5 xfce4-toys-4.2.3-2.fc5 xfce4-trigger-launcher-4.2.3-2.fc5 xfdesktop-4.2.3-3.fc5 xffm-4.2.3-3.fc5 xfprint-4.2.3-2.fc5 xfwm4-4.2.3.2-4.fc5 xfwm4-themes-4.2.3-2.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Fri Feb 17 17:51:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 12:51:09 -0500 Subject: [Bug 181803] Review Request: scrub In-Reply-To: Message-ID: <200602171751.k1HHp9Ar008656@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: scrub https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181803 ------- Additional Comments From woodard at redhat.com 2006-02-17 12:51 EST ------- Here is a new version of the spec file and the srpm which fixes the missing rm -rf in the install section. http://osdn.dl.sourceforge.net/sourceforge/diskscrub/scrub.spec http://osdn.dl.sourceforge.net/sourceforge/diskscrub/scrub-1.7-3.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From qspencer at ieee.org Fri Feb 17 18:13:17 2006 From: qspencer at ieee.org (Quentin Spencer) Date: Fri, 17 Feb 2006 12:13:17 -0600 Subject: static libs ... again Message-ID: <43F6123D.2060900@ieee.org> So, not too long ago someone asked why I still had static libs in one of my packages since they are "banned" or at least strongly discouraged, so I started removing them from my packages. All of the libraries I maintain are math libraries, so security concerns are a non-issue. After removing the static libs from fftw-devel, it took less than 24 hours to get a bug report asking for them back. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181897 for the reasoning. At this point, here are my options: 1. tell the user that static libs are bad and to go use another distro 2. put them back in 3. create a -static package I'm not going to do option 1. Option 2 seems to be frowned upon, but is there really any official policy against it? Option 3 has been proposed, but it never seemed like anyone agreed on it. What do you all think I should do. -Quentin From orion at cora.nwra.com Fri Feb 17 18:18:50 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 17 Feb 2006 11:18:50 -0700 Subject: mock/yum/buildsys problems Message-ID: <43F6138A.5030202@cora.nwra.com> I'm trying to build a package in mock for fedora-development-i386-core. The problem is that yum is trying to pull in an x86_64 package from the buildsystem repository: /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core/root resolvedep 'readline-devel' 'ncurses-devel' 'netcdf-devel' 'gettext' 'cfitsio-devel' 'kdebindings-devel' 'kdebase-devel' 'gsl-devel' 0:readline-devel-5.0-3.2.1.i386 0:ncurses-devel-5.5-18.2.i386 0:netcdf-devel-3.6.0-10.p1.fc5.x86_64 0:gettext-0.14.5-2.2.2.i386 0:cfitsio-devel-3.005-0.1.beta.fc5.i386 0:kdebindings-devel-3.5.1-1.2.i386 6:kdebase-devel-3.5.1-2.2.i386 0:gsl-devel-1.7-1.2.1.i386 0:readline-devel-5.0-3.2.1.i386 0:ncurses-devel-5.5-18.2.i386 0:netcdf-devel-3.6.0-10.p1.fc5.x86_64 0:gettext-0.14.5-2.2.2.i386 0:cfitsio-devel-3.005-0.1.beta.fc5.i386 0:kdebindings-devel-3.5.1-1.2.i386 6:kdebase-devel-3.5.1-2.2.i386 0:gsl-devel-1.7-1.2.1.i386 ensuring dir /var/lib/mock/fedora-development-i386-core/root/proc ensuring dir /var/lib/mock/fedora-development-i386-core/root/dev/pts /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core/root install 'readline-devel' 'ncurses-devel' 'netcdf-devel' 'gettext' 'cfitsio-devel' 'kdebindings-devel' 'kdebase-devel' 'gsl-devel' Error: Missing Dependency: libc.so.6(GLIBC_2.2.5)(64bit) is needed by package netcdf Error: Missing Dependency: libc.so.6(GLIBC_2.4)(64bit) is needed by package netcdf Error: Missing Dependency: libc.so.6(GLIBC_2.3.4)(64bit) is needed by package netcdf Error: Missing Dependency: libc.so.6()(64bit) is needed by package netcdf pulled from the buildsys repo: [local] name=local baseurl=http://buildsys.fedoraproject.org/plague-results/fedora-development-extras/ -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From rdieter at math.unl.edu Fri Feb 17 18:23:22 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 17 Feb 2006 12:23:22 -0600 Subject: static libs ... again In-Reply-To: <43F6123D.2060900@ieee.org> References: <43F6123D.2060900@ieee.org> Message-ID: Quentin Spencer wrote: > See > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181897 for the > reasoning. At this point, here are my options: > > 1. tell the user that static libs are bad and to go use another distro > 2. put them back in > 3. create a -static package > > I'm not going to do option 1. Corrolary: As I don't understand the users' precise requirements for static libs, perhaps asking them why dynamic linking is not sufficient? > Option 2 seems to be frowned upon, but is > there really any official policy against it? No. > Option 3 has been proposed, but it never seemed like anyone agreed on it. What do you all think I > should do. If you're going to provide the static libs anyway, AFAICT, there's not much point in packaging them separately, so go with Option 2. -- Rex From icon at fedoraproject.org Fri Feb 17 19:04:44 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Fri, 17 Feb 2006 14:04:44 -0500 Subject: static libs ... again In-Reply-To: <43F6123D.2060900@ieee.org> References: <43F6123D.2060900@ieee.org> Message-ID: <43F61E4C.5050404@fedoraproject.org> Quentin Spencer wrote: > So, not too long ago someone asked why I still had static libs in one of > my packages since they are "banned" or at least strongly discouraged, so > I started removing them from my packages. All of the libraries I > maintain are math libraries, so security concerns are a non-issue. After > removing the static libs from fftw-devel, it took less than 24 hours to > get a bug report asking for them back. See > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181897 for the > reasoning. It seems theirs is a rather specific and unique case. Should we change policy to accommodate corner cases like that? Regards, -- Konstantin Ryabitsev McGill University WSG Mal: "Can I come in?" Inara: "No." Mal: "See, that's why I usually don't ask." --Episode #6, "Our Mrs Reynolds" From icon at fedoraproject.org Fri Feb 17 19:20:48 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Fri, 17 Feb 2006 14:20:48 -0500 Subject: Bittorrent license Message-ID: <43F62210.9040802@fedoraproject.org> Part of a recent discussion with a Debianista(R) revealed that they don't ship the official bittorrent client because it has the following restriction in the license: 6. [...] You cannot charge for, sell, accept donations or otherwise receive compensation for the Source Code. Since bittorrent is written in Python, this more or less applies to "binary" RPMs as well. Not that anyone is packaging and selling stuff in Extras, but it's something to mull over. Or is it? Regards, -- Konstantin Ryabitsev McGill University WSG Mal: "Can I come in?" Inara: "No." Mal: "See, that's why I usually don't ask." --Episode #6, "Our Mrs Reynolds" From rdieter at math.unl.edu Fri Feb 17 19:26:20 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 17 Feb 2006 13:26:20 -0600 Subject: static libs ... again In-Reply-To: References: <43F6123D.2060900@ieee.org> Message-ID: Rex Dieter wrote: > Quentin Spencer wrote: > >> See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181897 for >> the reasoning. At this point, here are my options: >> >> 1. tell the user that static libs are bad and to go use another distro >> 2. put them back in >> 3. create a -static package >> >> I'm not going to do option 1. > > > Corrolary: As I don't understand the users' precise requirements for > static libs, perhaps asking them why dynamic linking is not sufficient? I read up a bit on Condor, and nowhere have I seen that it (or it's checkpointing feature) requires the use of statically-linked binaries (only that binaries be statically linked with the Condor libs). I'd ask the submitter for clarification. -- Rex From rc040203 at freenet.de Fri Feb 17 19:28:28 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 17 Feb 2006 20:28:28 +0100 Subject: static libs ... again In-Reply-To: References: <43F6123D.2060900@ieee.org> Message-ID: <1140204509.21764.324.camel@mccallum.corsepiu.local> On Fri, 2006-02-17 at 12:23 -0600, Rex Dieter wrote: > Quentin Spencer wrote: > > See > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181897 for the > > reasoning. At this point, here are my options: > > > > 1. tell the user that static libs are bad and to go use another distro > > 2. put them back in > > 3. create a -static package > > > > I'm not going to do option 1. > > Corrolary: As I don't understand the users' precise requirements for > static libs, A USER never has any requirements for static libs. Some DEVELOPERS have, but I've never found any of them who was able to provide an rationale for this demand. Ralf From skvidal at linux.duke.edu Fri Feb 17 19:31:00 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 17 Feb 2006 14:31:00 -0500 Subject: Bittorrent license In-Reply-To: <43F62210.9040802@fedoraproject.org> References: <43F62210.9040802@fedoraproject.org> Message-ID: <1140204660.9671.10.camel@cutter> On Fri, 2006-02-17 at 14:20 -0500, Konstantin Ryabitsev wrote: > Part of a recent discussion with a Debianista(R) revealed that they > don't ship the official bittorrent client because it has the following > restriction in the license: > > 6. [...] You cannot charge for, sell, accept donations or otherwise > receive compensation for the Source Code. > > Since bittorrent is written in Python, this more or less applies to > "binary" RPMs as well. Not that anyone is packaging and selling stuff in > Extras, but it's something to mull over. > > Or is it? > The rest of the license seems to countermand this one line but to be clear it is not an issue for -extras-list. This is for red hat legal counsel to look at. Curiousity - is this a recent addition to their license? -sv From rc040203 at freenet.de Fri Feb 17 19:30:43 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 17 Feb 2006 20:30:43 +0100 Subject: static libs ... again In-Reply-To: <43F61E4C.5050404@fedoraproject.org> References: <43F6123D.2060900@ieee.org> <43F61E4C.5050404@fedoraproject.org> Message-ID: <1140204644.21764.328.camel@mccallum.corsepiu.local> On Fri, 2006-02-17 at 14:04 -0500, Konstantin Ryabitsev wrote: > Quentin Spencer wrote: > > So, not too long ago someone asked why I still had static libs in one of > > my packages since they are "banned" or at least strongly discouraged, so > > I started removing them from my packages. All of the libraries I > > maintain are math libraries, so security concerns are a non-issue. After > > removing the static libs from fftw-devel, it took less than 24 hours to > > get a bug report asking for them back. See > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181897 for the > > reasoning. > It seems theirs is a rather specific and unique case. Should we change > policy to accommodate corner cases like that? Why? Because a user says he can't build some applications statically? What kind of rationale is this? Where is the technical explanation? Ralf From fedora at leemhuis.info Fri Feb 17 19:39:41 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 17 Feb 2006 20:39:41 +0100 Subject: Summary from yesterdays fesco meeting Message-ID: <1140205181.2904.20.camel@localhost.localdomain> Also in the wiki at: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060217 === Summary === Present from Fesco: thl, scop, warren, jeremy, ensc, jpo Topics: * Kernel module standardization * We need support in the buildsys. thl posted a mail to buildsys-list last week to get the ball running, but was not successful. warren will poke dcbw so we at least know how to get the whole thing running. * Should archs be hardcoded with a "ExclusiveArch: i586 i686 x86_64 ppc" or similar entries? That's how it is done in beehive, but scop doesn't like that idea to much. Warren will ask dcbw if there are alternatives. * Mass rebuild of Extras for FC5 * no decision yet if we want to rebuild the noarch packages, too. We continue with the current plan: Rebuild everything binary, and noarch is a lower priority * suggestion from scop: {{{ wait until $date, assemble a list of not rebuilt to Wiki, have packagers either rebuild packages, note in Wiki why not, and if nothing happens before $date+N, "someone" rebuilds }}} * jpo mentions problems with perl noarch packages on FC5; appears to be perl 5.8.8 related; He placed a warning in the Perl SIGs page. * related topic: With the current use scheme (rebuild everything by maintainer) we force people to show up. Are there any other ways to make sure that all packages in general and especially those that enter FE6 have a active maintainer? Ideas anyone? thl will write a mail with the subject "How to find out if maintainers are still active" to fedora-extras-list. * warren> I think *all* extras bugs should go to extras-bugs-list, and people can optionally subscribe to that. * Where should the bugzilla-spam for review bugs be send to? fedora-extras-list or extras-bugs-list? Both? Seems some people have been increasingly complaining about too much mail on fedora-extras-list. * Feedback appreciated! * Encourage Extras reviews * Review day. Highlights from the discussion: {{{ 19:37 < nirik> | thl: didn't work too well. Not much activity... I guess we could try again with more advertisement. I only mailed extras list 19:37 < nirik> | also a weekend time might work better. 19:38 < warren> | I personally don't think this campaign has any chance of making a real long term difference. 19:40 < warren> | however I personally would rather invest that time into long-term benefit tools, like more documentation and examples. Review day education is only a short-term solution, maybe even band-aid. 19:44 < warren> | I think better documentation and training tools, and more explicitly listed examples of tracks toward sponsorship would be helpful 19:44 < warren> | "review day" needs active participation from the limited time of sponsors, actively engaged in training, so this might be a losing proposition and a short-term solution 19:48 < |Jef|> | warren: i see your point about tracks... i honestly dont have a clear understanding of how to get sponsorship as a pure reviewer 19:49 < thl> | |Jef|, could you help to write a "How to become a sponsor" page in the wiki 19:50 < |Jef|> | thl: i can make up a process to become a sponsor and write a work of fiction 19:51 < |Jef|> | thl: i'll write something up for the list tonite }}} Site note: everybody can suggest new sponsors. Just drop thl a mail with the name(s) and he'll discuss them with FESCo and the other sponsors privately. * Free discussion. Highlights: {{{ 20:00 < jwb> | wondering about the 'scratch' repo idea that was resurfaced on the extras list today 20:00 < thl> | jwb, I send a mail to the list; I like the idea 20:00 < thl> | jwb, But somebody has to work out the details 20:00 < jwb> | was just about to say i'll wait to see how conversation goes and then go to fesco :) 20:00 < thl> | jwb, "somebody" can be any active extras contributor 20:01 < |Jef|> | thl: the deeper question is, is it worth making mock builds a hard requirement for review passing 20:01 < thl> | is a 'scratch' repo possible at all? 20:01 < jwb> | i'll see if i can look at what would be needed in plague itself 20:02 < |Jef|> | thl: once something is submitted... that would just be a special branch 20:02 < jwb> | i don't think we want to go that route 20:02 < |Jef|> | thl: for pre-submission review... i have no idea 20:03 < thl> | |Jef|, who checks what is uploaded to the buildsys? 20:03 < thl> | |Jef|, security is the buzz-word here 20:04 < |Jef|> | thl: i realize... and reviewer who already has cvs commit access would have to pushing it in 20:05 < thl> | and we'll see if there comes out anything further from the current discussion on the list }}} === Full Log === {{{ 18:53 --> | scop (Ville Skytta) has joined #fedora-extras 18:56 < warren> | *poof* 18:58 * | jeremy is about 50% here 18:59 --> | ensc|w (Enrico Scholz) has joined #fedora-extras 19:00 --- | thl has changed the topic to: FESCo Meeting in Progress 19:00 < thl> | Hello everyone 19:00 < thl> | who'S around? 19:00 * | scop waves 19:00 * | ensc|w 19:01 < thl> | okay, let's start 19:01 --- | thl has changed the topic to: FESCo Meeting in Progress -- Kernel module standardization 19:01 < thl> | scop, jeremy, did you see my mail? 19:01 < jeremy> | thl: haven't seen any mail from you 19:01 < thl> | regarding the xen- kernels? 19:01 < scop> | nope 19:01 * | thl wonders where that one got lost 19:01 < thl> | okay, I'll send it again 19:02 < thl> | we still have no plan how to get the buildsys running for the kmods 19:02 < thl> | jeremy, warren could you poke dcbw after FC5T3 is out? 19:02 < warren> | sure 19:02 < scop> | the absolute minimum IMO is that we'd have a way of telling it the archs to build for 19:03 < scop> | everything else can be temporarily hardcoded in specfiles 19:03 * | thl send the mail out 19:03 < warren> | why not hard-code archs in specfiles like any other package? 19:03 < thl> | warren, are you on buildsys-list? 19:03 < scop> | warren, how? 19:03 < warren> | ExclusiveArch: i586 i686 x86_64 19:04 < warren> | explicitly list the archs you want 19:04 < scop> | ah, that abuse 19:04 < warren> | and it goes through the list 19:04 < warren> | Core does it with beehive 19:04 < thl> | scop, but that's how plague works afaik 19:04 < thl> | I'm also for the ExclusiveArch solution 19:04 < scop> | does it? there was a discussion about this on the FE list some time ago, with no clear conclusion 19:05 < thl> | I tested it once -- worked fine 19:05 < warren> | Core and beehive works exactly this way. It builds once for each listed arch. 19:05 < warren> | no mistaking if you supply it an explicit list 19:06 < scop> | I'd like to point out that doing that based on ExclusiveArch is plain _wrong_ (but an acceptable workaround for now if no better way exists) 19:06 < warren> | why wrong? 19:06 < warren> | we've been doing it that way in Core for years 19:07 < scop> | it is not a buildsys directive, it's a property of the packaged software 19:08 < thl> | warren, can you ask dcbw if another solution would be possible somehow? 19:08 < thl> | otherwise I suggest that we go for ExclusiveArch for now 19:08 < thl> | okay for everybody? 19:08 < warren> | realistically, you ask the buildsys to build only the archs that work, or the desired archs. The buildsys could build any listed archs that buildhosts are supported, and ignore any others (like s390x) if they are listed. 19:09 < warren> | This is a simple solution. 19:09 < warren> | thl, OK, I will ask dcbw 19:09 < thl> | warren, thx 19:09 < warren> | and maybe I'm missing context here, maybe there is a better way, I'll find out. 19:10 < thl> | warren, I posted to buildsys-list some days ago 19:10 < thl> | there are some questions / open issues 19:10 < thl> | where we need help from dcbw 19:10 < thl> | afaics 19:10 --> | jpo (Unknown) has joined #fedora-extras 19:10 < warren> | dcbw must be pretty swamped, but I or jeremy will corner him and get answers. 19:10 * | warren evil grin 19:10 --- | thl has changed the topic to: FESCo Meeting in Progress -- Mass rebuild of Extras for FC5 19:11 < thl> | I'm working on a script that shows how far we are 19:11 < scop> | the problem with exclusivearch is that let's say you list i586 i686 x86_64 ppc and someone wants to rebuild it for alpha -> won't build, even if the package/software would work 19:11 <-- | fitheach has left #fedora-extras ( ) 19:11 < thl> | should be ready tomorrow 19:11 < warren> | scop, you can include other archs in the list, buildsys can simply ignore Extras non-supported archs. 19:12 < thl> | well, do we want to rebuild the SRPMS? 19:12 < thl> | I know that SRPM don't need a rebuild per se. But I still think that we should rebuild them, too, because this was me make sure that: 19:12 < thl> | - they still build 19:12 < thl> | - they still have a maintainer 19:12 < thl> | - we have no remaining packages in the distro that have "fc4" in the name due to using "%{dist}" 19:12 < thl> | - hopefully someone looked at the older packages and checked if the update patch FC -> FC5 works 19:12 < warren> | ExclusiveArch behaving in this manner has the benefit of also allowing glibc or openssl like multi-arch building, giving you i386 and i686 of a performance intensive (proven by benchmarks) package. 19:13 < scop> | warren, it's abuse of the tag nevertheless 19:13 < warren> | scop, I'd personally disagree, but either way this is very simple and it already behaves similar to this in Core literally forever. 19:14 < warren> | more importantly the simplicity of this allows us to move forward sooner 19:14 < warren> | (assuming dcbw doesn't have a better idea) 19:14 < scop> | that I agree with 19:15 < thl> | okay, now proceed to Mass rebuild? 19:15 < warren> | thl, I'd say find out what isn't rebuilt, and that list can serve more than one purpose 19:15 < scop> | thl, I can say that the packages I maintain are checked for those 19:15 < warren> | thl, 1) Who isn't responsible in maintaining? (probably me) 2) And we decide if we rebuild it anyway, just like Core. 19:16 < bpepple> | Has gstreamer-08 been imported in extras yet. There's about 3 or 4 packages dependent on that for a rebuild. 19:16 < thl> | scop, I now that you checked your packages 19:16 < jeremy> | bpepple: I don't remember seeing it in the "needs review" queue yesterday 19:16 < thl> | But just remember comptons packages 19:17 < thl> | they probably would never have entered FE4 19:17 < scop> | of course, that's a completely different scenario 19:17 < thl> | yeah 19:17 * | nirik needs to find time to fire off rebuilds for all his. Pesky lack of time. 19:17 < thl> | But that's why I would like that every maintainers shows up 19:17 < thl> | and rebuilds all his packages 19:18 < warren> | realistically, a volunteer driven project will have people disappear and reappear, and we cannot expect everyone to be there always. 19:18 < bpepple> | jeremy: Does it need a formal review, since it was just removed from Core? 19:18 < thl> | warren, sure 19:18 < thl> | warren, but we need to know if they disapeear 19:18 < warren> | thl, and even Core is mass rebuilt by the technical leaders without input from the individual package maintainres. 19:18 < thl> | disappear 19:18 < warren> | thl, yes, the list after voluntary rebuilds can tell us. 19:18 < jeremy> | bpepple: everything needs have a review to be imported into extras 19:18 < scop> | I have some 50+ packages not yet rebuilt this week, the vast majority of which are noarch and would have _no_ practical benefits from a rebuild to anyone but me, and I've checked most of them locally already 19:18 < warren> | thl, however more simply, parsing the extras-commits-list can tell us the same. 19:19 --> | monkey- (michael) has joined #fedora-extras 19:19 < warren> | I personally see no benefit to rebuilding noarch. Actually there is no benefit in rebuilding i386 and x86_64 IIRC. The ABI change was only ppc? Gotta fact check... 19:19 * | warren reads mail 19:19 < thl> | well, we IMHO should discuss the noarch issue now 19:19 < bpepple> | jeremy: Rule must have changed. Use to be that if it was in Core, that it could be imported into Extras. 19:19 < thl> | otherwise we are running out of time 19:19 < jeremy> | bpepple: yeah, that changed a few months ago 19:20 < jeremy> | warren: there are security features in 4.1 that help i386 and x86_64 19:20 < thl> | even core seems to rebuild the noarch packages afaik 19:20 * | scop needs to flee in about 15 or so minutes, btw 19:20 < warren> | jeremy, oh right 19:20 < thl> | well, do we want to vote on the noarch issue? 19:21 < thl> | Or wait another week? 19:21 < warren> | How about this... rebuild everything binary, and noarch is a lower priority, we can decide to do that next week or later. 19:21 < jpo> | Build noarch: +1 19:21 < thl> | warren, that's the current situation already 19:21 < scop> | -1 19:21 < warren> | Build noarch: Decide later, low priority +1 19:21 < jpo> | I am having problems with a perl noarch packages 19:21 --> | cwickert (Christoph Wickert) has joined #fedora-extras 19:21 < warren> | jpo, no longer compatible with FC5 perl for some reason? 19:22 < jpo> | appears to be perl 5.8.8 related 19:22 < warren> | should compat symlinks in 5.8.8 be removed? 19:22 < warren> | jpo, any bugzilla to track this issue? 19:22 < scop> | wait until $date, assemble a list of not rebuilt to Wiki, have packagers either rebuild packages, note in Wiki why not, and if nothing happens before $date+N, "someone" rebuilds 19:23 < warren> | thl, scop: Note that "didn't voluntarily rebuild" is not the only way to figure out who isn't active anymore. extras-commits-list can tell us too. 19:23 < jpo> | I don't think so. I still haven't figured out the problem. 19:23 < jpo> | warren: I placed a warning in the Perl SIGs page. 19:24 < thl> | warren, how should that work in extras-commits-list? 19:24 < thl> | warren, we have some packages that have selfdom upstream updates 19:24 < thl> | take bonnie++ or tiobench for example 19:24 < thl> | they are both older than 2 years already 19:24 < warren> | thl, something to do with package owner, and did they checkin since 19:25 < warren> | thl, isn't bonnie++ me? ^^ 19:25 < thl> | warren, and tiobench is mine ;-) 19:25 < thl> | but they serv as good example 19:25 < warren> | I know that I'm behind 5,000 mail 19:25 < warren> | I personally don't think this is a big issue, eventually we should do what we do in Core in every cycle, just rebuild everything and poke all maintainers. 19:26 < warren> | However the level of expectation of responsibility for maintainers disappearing in Extras is different than core. 19:26 < thl> | yeah 19:27 < warren> | Maybe we can consider an automatic timeout, like "If you don't respond in X amount of time, package goes automatically into orphan." However I wouldn't want bugzilla to stop going to the maintainer. 19:27 < warren> | orphan mail should be going to a list for multiple people to watch.... 19:27 < thl> | warren, sound like a plan 19:27 < warren> | arguably that should be extras-list along with all other extras bugs, in addition to package reviews, however some people have been increasingly complaining about too much mail on that list. 19:28 < warren> | Other teams have began using another list like foo-bugs-list, maybe we should split it out. 19:28 < thl> | maybe 19:28 < |Jef|> | thl: whoa are you talking about the orphans thing i brought up? 19:28 < thl> | |Jef|, not directly 19:29 < thl> | I think I'm going to send a separate mail to fedora-extras-list 19:29 < thl> | "How to find out if maintainers are still active" 19:29 < thl> | and we wait what comes out of the discussion 19:29 < thl> | and we proceed with the rebuild as announced 19:29 < thl> | that okay for everybody for now? 19:30 < thl> | we can talk about hte noarch packages in the next meeting again 19:30 < |Jef|> | thl: the stats guy is starting to poke at scripts to try to narrow potential orphaned items 19:30 < |Jef|> | thl: in private email with me 19:31 < warren> | separate discussion and decision item, I think *all* extras bugs should go to extras-bugs-list, and people can optionally subscribe to that. 19:31 < thl> | |Jef|, k, thx, I'll talk to him 19:32 < thl> | warren, I know somebody that will complain if we do that 19:32 < warren> | thl, eh? 19:32 < thl> | warren, he'll say "we need as much people as possible to watch the reviewers" 19:32 < thl> | But I tend to agree 19:32 < warren> | thl, when I say *all* extras bug mail, I don't mean removing the maintainers from direct mail, this is an additional auto-CC 19:33 < warren> | thl, "we need as much people as possible to watch the reviewers" I don't understand what this means. 19:33 < thl> | warren, with the current scheme (everything to one list) everybody see the comments in the review-bugs 19:33 < thl> | If we have a separate mailinglist for bugzilla-spam 19:34 < thl> | then only a few will subscribe 19:34 < thl> | and no one watches the reviewers if they do a good job 19:34 < warren> | ah 19:34 < thl> | But I tend to agree 19:34 < thl> | A separte mailinglist has benefits 19:34 < warren> | I think bug mail should go either to extras-list, or extras-bugs-list 19:34 < warren> | I don't care which 19:35 < thl> | warren, I'll note that in the summary 19:35 < thl> | we can revisit this next week 19:35 < |Jef|> | thl: on a personal note.. i already filter out the review items in extras-list into a seperate category 19:35 < warren> | thl, thanks 19:35 < thl> | |Jef|, hehe, you're probably not the only one doing this 19:35 < |Jef|> | thl: i doubt highly actively people read extras-list in timestamp order without filtering 19:36 < thl> | okay, done with this? 19:36 --- | thl has changed the topic to: FESCo Meeting in Progress -- Encourage Extras reviews 19:36 < thl> | nirik, what's your opinion on the review day after the first one is done? 19:36 < |Jef|> | thl: seperate lists for reviews have the advantge of web archive threading readability...if we had good web archives 19:37 < |Jef|> | thl: opps...nevermind topic changed 19:37 < nirik> | thl: didn't work too well. Not much activity... I guess we could try again with more advertisement. I only mailed extras list 19:37 < nirik> | also a weekend time might work better. 19:37 < nirik> | or we could just forget it. ;) 19:37 < |Jef|> | nirik: let me strongly suggest..from my very experient trying to do bug days...back in the day.... you'll have to advertise more 19:38 < thl> | nirik, yeah, we should try this further 19:38 < warren> | I personally don't think this campaign has any chance of making a real long term difference. 19:38 < nirik> | yeah, probibly true. 19:38 < warren> | Realistically this goes back to the motivation of volunteers. Volunteers only do what interests them. 19:38 < warren> | we should instead be focusing on education 19:38 < |Jef|> | warren: unless there is a way to get more reviewers into the pool as part of the process 19:39 < nirik> | I can try again in a few weeks? before fc5? 19:39 < nirik> | warren: one advantage of review days is that it might help educate people on how to do them... 19:39 < |Jef|> | warren: what if activity during review days...helped towards getting contributor status? 19:39 < warren> | perhaps yes 19:40 < scop> | I need to run now. CU 19:40 < |Jef|> | warren: so people who dont have the ability to approve could earn that ability by participating in organized review days 19:40 < warren> | however I personally would rather invest that time into long-term benefit tools, like more documentation and examples. Review day education is only a short-term solutoin, maybe even band-aid. 19:40 <-- | scop has quit ("Leaving") 19:40 < warren> | |Jef|, maybe, I don't know for sure 19:41 < warren> | (about effectiveness) 19:41 < |Jef|> | warren: is there a mechanism in place right now to get approval status that doesn't involve submitting your own package and becoming a package maintainer? 19:41 < |Jef|> | warren: realistically 19:41 < warren> | technically getting approval status is proving to a sponsor that you read all documentation and understand all the rules, and are technically sound. You prove it somehow. 19:42 < warren> | packaging just was a simple way to do it in the past 19:42 < |Jef|> | warren: "somehow" 19:42 < warren> | we can probably expand that into example tracks 19:42 < |Jef|> | warren: what im saying is i dont see a realistic way to do that as a reviewer 19:42 < warren> | track A, track B, track C, only examples 19:42 < |Jef|> | warren: review days..organized specifically to build a track record sponsors can use when judging a sponsorship request seem usefule to me 19:42 < warren> | |Jef|, please educate me, but have you ever packaged anything or done a review yourself in Extras? 19:43 < |Jef|> | warren: yes 19:43 < warren> | ok, I haven't been folllowing all traffic, I don't know. 19:43 < warren> | |Jef|, I personally as a sponsor watch activity of folks over the span of days or weeks and search google to see level of clue before making decisions. 19:43 < |Jef|> | warren: my ratio right now is 2/1 reviews to maintained packages :-> 19:44 < |Jef|> | warren: and im trying to keep that ratio 19:44 < warren> | I think better documentation and training tools, and more explicitly listed examples of tracks toward sponsorship would be helpful 19:44 < warren> | "review day" needs active participation from the limited time of sponsors, actively engaged in training, so this might be a losing proposition and a short-term solution 19:45 < thl> | warren, it's better then nothing 19:45 < |Jef|> | warren: indeed.. review days would need to have sponsors participating to be used for recruitment 19:45 < warren> | sorry, I shouldn't be discouraging. I'll attempt to attack the problem from the other side. 19:45 < warren> | multiple fronts... 19:45 < |Jef|> | warren: and my answer to that is... more sponsors ! 19:46 < thl> | |Jef|, nominate them 19:46 < |Jef|> | thl: i can nominate sponsors? 19:46 < thl> | |Jef|, drop me a mail with some names 19:46 < thl> | Sure 19:46 < |Jef|> | thl: i dont have to be a sponsor to nominate more sponsors? 19:46 < warren> | |Jef|, more sponsors alone cannot solve the problem, you need the right people with the right motivation, and the only way to do that is by education 19:46 < thl> | I don't think that is required 19:47 < warren> | I don't particularly see review days as being effective in that. It is too time consuming for the existing experts. 19:47 < thl> | |Jef|, but the sponsors and/or FESCo will discuss the names 19:47 <-- | cweyl has quit (Read error: 104 (Connection reset by peer)) 19:47 < thl> | guys, we're running out of time 19:47 < warren> | |Jef|, thl: I do see value in a nomination list, but perhaps collecting info and URLs of their work would help FESCO make quicker decisions with low time overhead 19:47 < thl> | does anyone want has anything else important to that topic? 19:48 --> | JSchmitt (Jochen Schmitt) has joined #fedora-extras 19:48 < |Jef|> | warren: i see your point about tracks... i honestly dont have a clear understanding of how to get sponsorship as a pure reviewer 19:48 < |Jef|> | warren: its much more clear how to get it by trying to be a package maintainer 19:48 < warren> | |Jef|, then examples of that can be added in tracks 19:48 < warren> | being a package maintainer has never been a hard and fast requirement, the documentation now is very unclear on that and maybe contradcitory to what I've always been thinking 19:49 < |Jef|> | warren: no not a requirement... but its more clear how to work towards sponsership as a maintainer 19:49 < thl> | |Jef|, could you help to write a "How to become a sponsor" page in the wiki 19:49 < thl> | |Jef|, I can help if you need input 19:49 < |Jef|> | thl: if i knew how 19:49 < warren> | I think perhaps that owning a package gives you a stake in it, it is difficult to get someone involved enthusiastically if they don't "own" something. Volunteer motivation 19:50 < |Jef|> | thl: i can make up a process to become a sponsor and write a work of fiction 19:50 < warren> | |Jef|, write to the list first please, I can combine the problem with my thoughts then redo the existing doc 19:50 < thl> | warren, sounds like a good idea 19:51 < thl> | |Jef| ? 19:51 < |Jef|> | thl: i'll write something up for the list tonite 19:51 < thl> | |Jef|, thx 19:52 < thl> | okay, moving on 19:52 < warren> | I'm almost out of time 19:52 --- | thl has changed the topic to: FESCo Meeting in Progress -- Weekly sponsorship nomination 19:52 < thl> | John Mahowald / jpmahowald ? 19:52 < thl> | warren? 19:52 < warren> | He's doing OK, I need to look deeper 19:53 < warren> | (one benefit of manually approving branches is it force me to read all reviews. One detriment is that I'm letting ignacio's work stagnate...) 19:53 < thl> | hehe 19:53 < thl> | okay, any other nominations? 19:53 < warren> | thl, don't ask me to decide alone, but I can make a decision by next week. If I'm silent then then I'm +1 19:54 < thl> | warren, scop also said +1 on FESCo list 19:54 < thl> | and he remindet me to mention jpmahowald 19:55 < thl> | reminded 19:55 < thl> | okay, then next week 19:55 <-- | finalzone has quit ("Download Gaim: http://gaim.sourceforge.net/") 19:55 --- | thl has changed the topic to: FESCo Meeting in Progress -- free discussion 19:56 < warren> | thl, I'm liking your meeting organizational style and following up on points. 19:56 < nirik> | yeah... you're doing great thl. :) 19:56 < thl> | well, the meetings were shorted in gregdek's days 19:57 < warren> | thl, you're inspiring us to get to conclusions 19:57 < thl> | warren, thx :) 19:57 < thl> | nirik, thx, too 19:57 < warren> | I'm out of time 19:57 < warren> | thanks 19:57 < warren> | everyone 19:57 < jwb> | thl, i especially like the summary notes being sent to the -extras list 19:57 < thl> | I's good to also get some positive feedback now and then ;-) 19:57 < warren> | I like the /topic changing 19:58 < jwb> | that too 19:58 < thl> | anyway: does anyone have anything left to discuss? 19:58 < thl> | Or can we call it a day? 19:59 * | thl will close the meeting in 30 19:59 * | thl will close the meeting in 15 19:59 * | thl will close the meeting in 10 19:59 * | thl will close the meeting in 5 19:59 < jwb> | one thing 19:59 < thl> | :) 19:59 < jwb> | oh, nevermind 19:59 * | thl waits 19:59 < jwb> | i'll wait for next week 19:59 < thl> | jwb, shoot 20:00 < jwb> | wondering about the 'scratch' repo idea that was resurfaced on the extras list today 20:00 < thl> | jwb, I send a mail to the list 20:00 < thl> | jwb, I like the idea 20:00 < thl> | jwb, But somebody has to work out the details 20:00 < jwb> | was just about to say i'll wait to see how conversation goes and then go to fesco :) 20:00 < thl> | jwb, "somebody" can be any active extras contributor 20:01 < |Jef|> | thl: the deeper question is, is it worth making mock builds a hard requirement for review passing 20:01 < thl> | |Jef|, the real question imho is: 20:01 < thl> | is a 'scratch' repo possible at all? 20:01 < jwb> | i'll see if i can look at what would be needed in plague itself 20:02 < |Jef|> | thl: once something is submitted... that would just be a special branch 20:02 < jwb> | i don't think we want to go that route 20:02 < |Jef|> | thl: for pre-submission review... i have no idea 20:02 < thl> | |Jef|, well, I'm not sure on this 20:03 < thl> | |Jef|, who checks what is uploaded to the buildsys? 20:03 < thl> | |Jef|, security is the buzz-word here 20:04 < |Jef|> | thl: i realize... and reviewer who already has cvs commit access would have to pushing it in 20:04 < thl> | |Jef|, yeah, that could work 20:04 < thl> | |Jef|, I'll mention it in the summary 20:05 <-- | kbsingh has quit ("HomeTime") 20:05 < thl> | and we'll see if there comes out anything further from the current discussion on the list 20:05 < thl> | okay for everybody? 20:05 * | thl will close the meeting in 15 20:05 < |Jef|> | thl: scratch post-submission might be more tractable 20:06 < thl> | |Jef|, yeah 20:06 < thl> | well, let's stop for today 20:06 * | thl will close the meeting in 5 20:06 < thl> | MARK Meeting end 20:06 < thl> | thx everybody }}} -- Thorsten Leemhuis From icon at fedoraproject.org Fri Feb 17 19:46:00 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Fri, 17 Feb 2006 14:46:00 -0500 Subject: Bittorrent license In-Reply-To: <1140204660.9671.10.camel@cutter> References: <43F62210.9040802@fedoraproject.org> <1140204660.9671.10.camel@cutter> Message-ID: <43F627F8.50804@fedoraproject.org> seth vidal wrote: >> 6. [...] You cannot charge for, sell, accept donations or otherwise >> receive compensation for the Source Code. > > The rest of the license seems to countermand this one line but to be > clear it is not an issue for -extras-list. This is for red hat legal > counsel to look at. > > Curiousity - is this a recent addition to their license? It's been there since version 4.0 and comes from the JOSL-1.0 license, on which this one is based. -- Konstantin Ryabitsev McGill University WSG Mal: "Can I come in?" Inara: "No." Mal: "See, that's why I usually don't ask." --Episode #6, "Our Mrs Reynolds" From fedora at leemhuis.info Fri Feb 17 19:51:32 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 17 Feb 2006 20:51:32 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139851362.2904.79.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> Message-ID: <1140205892.2904.30.camel@localhost.localdomain> This time also: Replies to fedora-extras-list please, tia! Am Montag, den 13.02.2006, 18:22 +0100 schrieb Thorsten Leemhuis: > Hi Fedora Maintainers! > > The last rawhide mass-rebuild is mostly done now so it's time for us to > also rebuild **all packages** in the Fedora Extras development tree > before it becomes Fedora Extras 5 (FE) when Fedora Core 5 is > branched/released. Guys, please keep the buildsys busy. There are a lot of packages that are still not rebuild afaics. I wrote a small script "buildcheck" (attached) that can check what packages are not yet rebuild. The script is far from perfect but it works quite well afaics. Maybe it has some bugs -- I'm sure you guys will find some and tell me about it. How does it work? Rough version: It checks the buildtime of all srpms in extras/development and prints the name and the email of all those that were rebuild before the official mass-rebuild was announced. The script found the following packages in extras/development for which no entry in the owners.list could be found: fftw3, umfpack, perl-Gtk2-GladeXML, perl-Imager, perl-Gnome2-Canvas, html-xml-utils, dia, libdsk, libspectrum, lib765 The following 565 arch specific packages still need a rebuild according to the script. There might be some false positives in the list like for example "icu" -- that was moved to core, but still is in the repo and found by the script. Simply ignore those false positives. aaron.bennett at olin.edu ifplugd ad+rh-bugzilla at uni-x.org pam_abl adrian at lisas.de cvsup adrian at lisas.de jhead adrian at lisas.de kover adrian at lisas.de libcdio adrian at lisas.de most adrian at lisas.de nexuiz adrian at lisas.de ninja adrian at lisas.de sopwith adrian at lisas.de source-highlight adrian at lisas.de tin adrian at lisas.de uudeview adrian at lisas.de vnstat adrian at lisas.de xdesktopwaves adrian at lisas.de xlockmore adrian at lisas.de xmlindent a.kurtz at hardsun.net libdaemon andreas at bawue.net barcode andreas at bawue.net commoncpp2 andreas at bawue.net ddrescue andreas at bawue.net mod_suphp andreas at bawue.net perl-Crypt-Blowfish andreas at bawue.net scmxx andreas.bierfert at lowlatency.de fbdesk andreas.bierfert at lowlatency.de fluxbox andreas.bierfert at lowlatency.de lcms andreas.bierfert at lowlatency.de orange andreas.bierfert at lowlatency.de synce andreas.bierfert at lowlatency.de synce-gnomevfs andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de wine anvil at livna.org aalib anvil at livna.org bin2iso anvil at livna.org id3lib anvil at livna.org imlib2 anvil at livna.org irssi anvil at livna.org libcddb anvil at livna.org libebml anvil at livna.org libmatroska anvil at livna.org libsamplerate anvil at livna.org libsndfile anvil at livna.org libtar anvil at livna.org lzo aportal at univ-montp2.fr gpsim aportal at univ-montp2.fr gputils aportal at univ-montp2.fr gtk+extra aportal at univ-montp2.fr utrac bdpepple at ameritech.net gnomebaker bdpepple at ameritech.net tagtool bojan at rexursive.com libapreq2 bressers at redhat.com nmh bugs.michael at gmx.net abicheck bugs.michael at gmx.net aide bugs.michael at gmx.net bchunk bugs.michael at gmx.net chkrootkit bugs.michael at gmx.net mhash bugs.michael at gmx.net xmms-sid caillon at redhat.com epiphany-extensions ch.nolte at fh-wolfenbuettel.de kbibtex chris at chrisgrau.com frotz chris at chrisgrau.com ifm chris at chrisgrau.com perl-Time-Piece chrisw at redhat.com git-core colin at fedoraproject.org adns colin at fedoraproject.org gaim-guifications colin at fedoraproject.org MagicPoint colin at fedoraproject.org python-adns danken at cs.technion.ac.il bidiv danken at cs.technion.ac.il hspell danken at cs.technion.ac.il taarich davidhart at tqmcube.com leafnode davidz at redhat.com NetworkManager-vpnc denis at poolshark.org galeon denis at poolshark.org gconfmm26 denis at poolshark.org glibmm24 denis at poolshark.org gnome-vfsmm26 denis at poolshark.org gtkmm24 denis at poolshark.org inkscape denis at poolshark.org libglademm24 denis at poolshark.org libgnomecanvasmm26 denis at poolshark.org libgnomemm26 denis at poolshark.org libgnomeuimm26 denis at poolshark.org libsigc++ denis at poolshark.org libsigc++20 dennis at ausil.us krecipes dgregor at redhat.com perl-Class-MethodMaker dwmw2 at infradead.org ctrlproxy dwmw2 at redhat.com exim dwmw2 at redhat.com hfsplusutils endur at bennewitz.com streamtuner enrico.scholz at informatik.tu-chemnitz.de cfs enrico.scholz at informatik.tu-chemnitz.de clamav enrico.scholz at informatik.tu-chemnitz.de dhcp-forwarder enrico.scholz at informatik.tu-chemnitz.de dietlibc enrico.scholz at informatik.tu-chemnitz.de gif2png enrico.scholz at informatik.tu-chemnitz.de hunt enrico.scholz at informatik.tu-chemnitz.de ip-sentinel enrico.scholz at informatik.tu-chemnitz.de libtasn1 enrico.scholz at informatik.tu-chemnitz.de milter-greylist enrico.scholz at informatik.tu-chemnitz.de mimetic enrico.scholz at informatik.tu-chemnitz.de opencdk enrico.scholz at informatik.tu-chemnitz.de util-vserver enrico.scholz at informatik.tu-chemnitz.de xca enrico.scholz at informatik.tu-chemnitz.de xmlrpc-c extras-orphan at fedoraproject.org abe extras-orphan at fedoraproject.org anjuta extras-orphan at fedoraproject.org arc extras-orphan at fedoraproject.org at-poke extras-orphan at fedoraproject.org camstream extras-orphan at fedoraproject.org cgoban extras-orphan at fedoraproject.org cksfv extras-orphan at fedoraproject.org conglomerate extras-orphan at fedoraproject.org duplicity extras-orphan at fedoraproject.org freedroidrpg extras-orphan at fedoraproject.org gnofract4d extras-orphan at fedoraproject.org gnome-telnet extras-orphan at fedoraproject.org gnugo extras-orphan at fedoraproject.org gpa extras-orphan at fedoraproject.org gtkglarea2 extras-orphan at fedoraproject.org gurlchecker extras-orphan at fedoraproject.org libzvt extras-orphan at fedoraproject.org lua extras-orphan at fedoraproject.org manedit extras-orphan at fedoraproject.org mknbi extras-orphan at fedoraproject.org netdiag extras-orphan at fedoraproject.org nget extras-orphan at fedoraproject.org ots extras-orphan at fedoraproject.org parchive extras-orphan at fedoraproject.org prozilla extras-orphan at fedoraproject.org putty extras-orphan at fedoraproject.org sirius extras-orphan at fedoraproject.org tdl extras-orphan at fedoraproject.org tetex-lgrind extras-orphan at fedoraproject.org tla extras-orphan at fedoraproject.org wbxml2 extras-orphan at fedoraproject.org xmms-cdread extras-orphan at fedoraproject.org xtide fedora at leemhuis.info icu fedora.wickert at arcor.de emelfm2 fedora.wickert at arcor.de xfce4-mount-plugin fedora.wickert at arcor.de xfce4-netload-plugin fedora.wickert at arcor.de xfce4-sensors-plugin fredrik at dolda2000.com icmpdn gajownik at gmail.com athcool gauret at free.fr amarok gauret at free.fr amaya gauret at free.fr apachetop gauret at free.fr basket gauret at free.fr colorscheme gauret at free.fr elmo gauret at free.fr gmpc gauret at free.fr grisbi gauret at free.fr gwenview gauret at free.fr iftop gauret at free.fr libkexif gauret at free.fr libkipi gauret at free.fr libvisual gauret at free.fr mpc gauret at free.fr pdftohtml gauret at free.fr perl-Jcode gauret at free.fr perl-Unicode-Map gauret at free.fr perl-Unicode-Map8 gauret at free.fr perl-Unicode-String gauret at free.fr psi gauret at free.fr pure-ftpd gauret at free.fr qca gauret at free.fr qca-tls gauret at free.fr showimg gauret at free.fr taglib gauret at free.fr ulogd gauret at free.fr unrtf gauret at free.fr wv gauret at free.fr xbindkeys gauret at free.fr xlhtml gauret at free.fr zope gemi at bluewin.ch abcm2ps gemi at bluewin.ch audacity gemi at bluewin.ch bigloo gemi at bluewin.ch clisp gemi at bluewin.ch cook gemi at bluewin.ch erlang gemi at bluewin.ch gforth gemi at bluewin.ch global gemi at bluewin.ch graveman gemi at bluewin.ch GtkAda gemi at bluewin.ch lablgl gemi at bluewin.ch lablgtk gemi at bluewin.ch ocaml gemi at bluewin.ch pl gemi at bluewin.ch plt-scheme gemi at bluewin.ch qcad gemi at bluewin.ch skencil gemi at bluewin.ch TeXmacs gemi at bluewin.ch unison gemi at bluewin.ch yap ghenry at suretecsystems.com john ghenry at suretecsystems.com librsync ghenry at suretecsystems.com rdiff-backup green at redhat.com itext green at redhat.com jakarta-commons-cli green at redhat.com jogl green at redhat.com kawa green at redhat.com rssowl grenier at cgsecurity.org testdisk hamzy at us.ibm.com sblim-cmpi-base hamzy at us.ibm.com sblim-cmpi-devel hamzy at us.ibm.com sblim-wbemcli i at stingr.net flow-tools i at stingr.net pyflowtools i at stingr.net rzip ivazquez at ivazquez.net hamlib ivazquez at ivazquez.net lock-keys-applet ivazquez at ivazquez.net sqlite2 jamatos at fc.up.pt fftw2 jamatos at fc.up.pt R-mAr jcarpenter at condell.org ks3switch jcarpenter at condell.org lrmi jcarpenter at condell.org s3switch jcarpenter at condell.org tpb jcarpenter at condell.org xosd jdennis at redhat.com cyrus-imapd jeff.gilchrist at gmail.com pbzip2 jeff at ollie.clive.ia.us byzanz jeff at ollie.clive.ia.us libeXosip2 jeff at ultimateevil.org up-imapproxy jeff at ultimateevil.org zile jfontain at free.fr blt jfontain at free.fr tktable jnovy at redhat.com allegro jnovy at redhat.com cproto jnovy at redhat.com nedit Jochen at herr-schmitt.de blender joost at cnoc.nl fpc jpo at di.uminho.pt libol jpo at di.uminho.pt perl-AppConfig jpo at di.uminho.pt perl-Compress-Bzip2 jpo at di.uminho.pt perl-DBD-SQLite jpo at di.uminho.pt perl-DBD-XBase jpo at di.uminho.pt perl-Digest-MD4 jpo at di.uminho.pt perl-Error jpo at di.uminho.pt perl-ExtUtils-PkgConfig jpo at di.uminho.pt perl-Gtk2 jpo at di.uminho.pt perl-Image-Size jpo at di.uminho.pt perl-Image-Xbm jpo at di.uminho.pt perl-Image-Xpm jpo at di.uminho.pt perl-MLDBM jpo at di.uminho.pt perl-Net-SSLeay jpo at di.uminho.pt perl-Pod-Coverage jpo at di.uminho.pt perl-Test-Pod jpo at di.uminho.pt perl-Text-CSV_XS jspaleta at gmail.com glabels jspaleta at gmail.com istanbul j.w.r.degoede at hhs.nl Glide3 j.w.r.degoede at hhs.nl lacewing j.w.r.degoede at hhs.nl overgod j.w.r.degoede at hhs.nl svgalib jylitalo at iki.fi python-imaging jylitalo at iki.fi xplanet karsten at redhat.com x3270 katzj at redhat.com mercurial lemenkov at newmail.ru chmlib lemenkov at newmail.ru fuse lemenkov at newmail.ru fuse-encfs lemenkov at newmail.ru fuse-sshfs lemenkov at newmail.ru rlog lemenkov at newmail.ru wavpack llch at redhat.com libtabe llch at redhat.com xcin lmacken at redhat.com naim lmacken at redhat.com valknut luya256 at yahoo.com gdesklets mattdm at mattdm.org wxPythonGTK2 matthias at rpmforge.net advancecomp matthias at rpmforge.net bbkeys matthias at rpmforge.net blackbox matthias at rpmforge.net boa matthias at rpmforge.net camE matthias at rpmforge.net csmash matthias at rpmforge.net d4x matthias at rpmforge.net diradmin matthias at rpmforge.net djvulibre matthias at rpmforge.net easytag matthias at rpmforge.net fillets-ng matthias at rpmforge.net gcombust matthias at rpmforge.net gentoo matthias at rpmforge.net giblib matthias at rpmforge.net gkrellm-aclock matthias at rpmforge.net gkrellm-freq matthias at rpmforge.net Gtk-Perl matthias at rpmforge.net gtktalog matthias at rpmforge.net gtweakui matthias at rpmforge.net hackedbox matthias at rpmforge.net hercules matthias at rpmforge.net i8kutils matthias at rpmforge.net js matthias at rpmforge.net kannel matthias at rpmforge.net libcaca matthias at rpmforge.net liboil matthias at rpmforge.net lighttpd matthias at rpmforge.net linux_logo matthias at rpmforge.net lmarbles matthias at rpmforge.net metakit matthias at rpmforge.net ncftp matthias at rpmforge.net oidentd matthias at rpmforge.net p7zip matthias at rpmforge.net php-eaccelerator matthias at rpmforge.net php-pecl-mailparse matthias at rpmforge.net php-pecl-pdo matthias at rpmforge.net php-pecl-pdo-sqlite matthias at rpmforge.net plib matthias at rpmforge.net plib16 matthias at rpmforge.net portaudio matthias at rpmforge.net powermanga matthias at rpmforge.net proftpd matthias at rpmforge.net rrdtool matthias at rpmforge.net SDL_gfx matthias at rpmforge.net starfighter matthias at rpmforge.net synergy matthias at rpmforge.net thttpd matthias at rpmforge.net torcs matthias at rpmforge.net ucarp matthias at rpmforge.net udftools matthias at rpmforge.net viruskiller matthias at rpmforge.net xmms matthias at rpmforge.net xmms-acme matthias at rpmforge.net xmms-arts matthias at rpmforge.net xmms-crossfade matthias at rpmforge.net xmms-flac matthias at rpmforge.net xmms-lirc matthias at rpmforge.net xmms-speex matthias at rpmforge.net xvattr matthias at rpmforge.net yasm matthias at rpmforge.net zziplib matt at truch.net cfitsio matt at truch.net hpic mccann0011 at hotmail.com geos mccann0011 at hotmail.com proj meme at daughtersoftiresias.org nethack-vultures mfleming+rpm at enlartenment.com mlmmj mfleming+rpm at enlartenment.com mod_security michel.salim at gmail.com gai michel.salim at gmail.com gai-pal michel.salim at gmail.com grhino michel.salim at gmail.com quarry mihai at xcyb.org htb-util mitr at redhat.com foobillard mitr at redhat.com python-4Suite-XML mpeters at mac.com firestarter mpeters at mac.com gfontview mpeters at mac.com gnomesword mpeters at mac.com lcdf-typetools mpeters at mac.com libvisual-plugins mpeters at mac.com pan nhorman at redhat.com iozone nos at utelsystems.com dillo nos at utelsystems.com gktools nos at utelsystems.com gtkterm nos at utelsystems.com neverball nos at utelsystems.com soundtracker nos at utelsystems.com whowatch oliver.andrich at gmail.com ruby-mysql oliver at linux-kernel.at banner oliver at linux-kernel.at bwm-ng oliver at linux-kernel.at fish oliver at linux-kernel.at libdnet oliver at linux-kernel.at ngrep oliver at linux-kernel.at perl-Mail-Alias oliver at linux-kernel.at perl-Unix-Statgrab oliver at linux-kernel.at rblcheck oliver at linux-kernel.at scanssh oliver at linux-kernel.at syck orion at cora.nwra.com gdl orion at cora.nwra.com hdf5 orion at cora.nwra.com kompose orion at cora.nwra.com ncarg orion at cora.nwra.com perl-Cflow orion at cora.nwra.com perl-Net-IP-CMatch orion at cora.nwra.com perl-Net-Patricia orion at cora.nwra.com plplot orion at cora.nwra.com python-basemap orion at cora.nwra.com python-matplotlib otaylor at redhat.com libuninameslist paul at city-fan.org pptp paul at xtdnet.nl fetchlog paul at xtdnet.nl gaim-otr paul at xtdnet.nl l2tpd paul at xtdnet.nl ldns paul at xtdnet.nl libotr paul at xtdnet.nl nsd pawsa at theochem.kth.se balsa pawsa at theochem.kth.se libesmtp pertusus at free.fr BibTool pertusus at free.fr docbook2X pertusus at free.fr libdap pertusus at free.fr libnc-dap pertusus at free.fr libsx pertusus at free.fr tetex-tex4ht petersen at redhat.com darcs petersen at redhat.com FreeWnn petersen at redhat.com ghc petersen at redhat.com haddock petersen at redhat.com scim-fcitx pvrabec at redhat.com licq qspencer at ieee.org octave-forge rc040203 at freenet.de Coin2 rc040203 at freenet.de Inventor rc040203 at freenet.de lib3ds rc040203 at freenet.de OpenSceneGraph rc040203 at freenet.de perl-gettext rc040203 at freenet.de perl-Params-Validate rc040203 at freenet.de perl-Test-Taint rc040203 at freenet.de perl-Want rc040203 at freenet.de SIMVoleon rc040203 at freenet.de SoQt rdieter at math.unl.edu akode rdieter at math.unl.edu apollon rdieter at math.unl.edu dxpc rdieter at math.unl.edu factory rdieter at math.unl.edu gc rdieter at math.unl.edu geomview rdieter at math.unl.edu gift rdieter at math.unl.edu gift-openft rdieter at math.unl.edu gpgme rdieter at math.unl.edu gsview rdieter at math.unl.edu gtk-qt-engine rdieter at math.unl.edu jasper rdieter at math.unl.edu kasablanca rdieter at math.unl.edu kdocker rdieter at math.unl.edu kickpim rdieter at math.unl.edu kile rdieter at math.unl.edu kimdaba rdieter at math.unl.edu kiosktool rdieter at math.unl.edu kipi-plugins rdieter at math.unl.edu kmymoney2 rdieter at math.unl.edu kxdocker rdieter at math.unl.edu libassuan rdieter at math.unl.edu libfac rdieter at math.unl.edu libksba rdieter at math.unl.edu libsigsegv rdieter at math.unl.edu libtunepimp rdieter at math.unl.edu lyx rdieter at math.unl.edu Macaulay2 rdieter at math.unl.edu maxima rdieter at math.unl.edu openslp rdieter at math.unl.edu pinentry rdieter at math.unl.edu sbcl rdieter at math.unl.edu tidy rdieter at math.unl.edu uw-imap rdieter at math.unl.edu xforms redhat-bugzilla at camperquake.de bmp redhat-bugzilla at camperquake.de bmp-flac2 redhat-bugzilla at camperquake.de fwbuilder redhat-bugzilla at camperquake.de libfwbuilder redhat at flyn.org gnonlin redhat at flyn.org linkchecker redhat at flyn.org new redhat at flyn.org pam_mount redhat at flyn.org roundup rolandd at cisco.com libmthca roland at redhat.com monotone rpm at timj.co.uk altermime rvokal at redhat.com nuttcp ryo-dairiki at users.sourceforge.net scim-input-pad ryo-dairiki at users.sourceforge.net scim-skk ryo-dairiki at users.sourceforge.net scim-tomoe ryo-dairiki at users.sourceforge.net tomoe shahms at shahms.com python-psycopg sheltren at cs.ucsb.edu cfengine sheltren at cs.ucsb.edu fortune-mod simonb at thoughtpolice.co.uk fdupes skvidal at phy.duke.edu mock skvidal at phy.duke.edu seahorse steve at silug.org gl-117 steve at silug.org perl-BerkeleyDB steve at silug.org perl-Crypt-DES steve at silug.org perl-DateTime steve at silug.org perl-IPC-ShareLite steve at silug.org perl-Unix-Syslog steve at silug.org tuxpaint steve at silug.org tuxtype2 stickster at gmail.com drivel stickster at gmail.com nautilus-open-terminal stickster at gmail.com xmldiff stickster at gmail.com xmlstarlet tagoh at redhat.com Canna tagoh at redhat.com kakasi tagoh at redhat.com kinput2 tagoh at redhat.com mew tagoh at redhat.com namazu tagoh at redhat.com paps tagoh at redhat.com perl-Text-Kakasi tagoh at redhat.com uim tagoh at redhat.com w3m-el tcallawa at redhat.com alsamixergui tcallawa at redhat.com blacs tcallawa at redhat.com c-ares tcallawa at redhat.com check tcallawa at redhat.com comical tcallawa at redhat.com compat-wxGTK tcallawa at redhat.com gambas tcallawa at redhat.com gxemul tcallawa at redhat.com jam tcallawa at redhat.com lapack tcallawa at redhat.com libgdamm tcallawa at redhat.com libmcrypt tcallawa at redhat.com librx tcallawa at redhat.com lincity-ng tcallawa at redhat.com logjam tcallawa at redhat.com mcrypt tcallawa at redhat.com mfstools tcallawa at redhat.com netgo tcallawa at redhat.com perl-Clone tcallawa at redhat.com perl-DBD-SQLite2 tcallawa at redhat.com perl-Template-Toolkit tcallawa at redhat.com perl-version tcallawa at redhat.com physfs tcallawa at redhat.com QuantLib tcallawa at redhat.com R tcallawa at redhat.com rekall tcallawa at redhat.com R-gnomeGUI tcallawa at redhat.com rocksndiamonds tcallawa at redhat.com rootsh tcallawa at redhat.com scalapack tcallawa at redhat.com udunits tcallawa at redhat.com wlassistant tcallawa at redhat.com xbase tcallawa at redhat.com xbsql tcallawa at redhat.com xkeycaps tcallawa at redhat.com xsupplicant thomas at apestaart.org directfb thomas at apestaart.org flumotion thomas at apestaart.org gstreamer08-python thomas at apestaart.org gstreamer-python thomas at apestaart.org Hermes thomas at apestaart.org ladspa thomas at apestaart.org libannodex thomas at apestaart.org libcmml thomas at apestaart.org liboggz thomas at apestaart.org libshout thomas at apestaart.org mach thomas at apestaart.org mod_annodex thomas at apestaart.org python-twisted toniw at iki.fi silky tripwire-devel at genesis-x.nildram.co.uk tripwire ville.skytta at iki.fi dvb-apps ville.skytta at iki.fi hddtemp ville.skytta at iki.fi id3v2 ville.skytta at iki.fi jikes ville.skytta at iki.fi kid3 ville.skytta at iki.fi pcsc-tools ville.skytta at iki.fi xemacs wart at kobold.org tcldom wart at kobold.org tclhttpd wart at kobold.org tclxml wart at kobold.org xpilot-ng wtogami at redhat.com bonnie++ wtogami at redhat.com ccache wtogami at redhat.com lvcool wtogami at redhat.com perl-Digest-Nilsimsa wtogami at redhat.com perl-Razor-Agent wtogami at redhat.com scponly z.kota at gmx.net python-bibtex z.kota at gmx.net recode -- Thorsten Leemhuis -------------- next part -------------- A non-text attachment was scrubbed... Name: buildcheck Type: application/x-shellscript Size: 1857 bytes Desc: not available URL: -------------- next part -------------- [buildcheck-extras-development-x86] name=Fedora Extras $releasever - Development Tree baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/ enabled=0 gpgcheck=0 [buildcheck-extras-development-x64] name=Fedora Extras $releasever - Development Tree baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/x86_64/ enabled=0 gpgcheck=0 [buildcheck-extras-development-ppc] name=Fedora Extras $releasever - Development Tree baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/ppc/ enabled=0 gpgcheck=0 [buildcheck-extras-development-sources] name=Fedora Extras $releasever - Development Tree baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/ enabled=0 gpgcheck=0 [buildcheck-extras-development-buildsys] name=Fedora Extras $releasever - Development Tree baseurl=http://buildsys.fedoraproject.org/plague-results/fedora-development-extras/ enabled=0 gpgcheck=0 From jpo at di.uminho.pt Fri Feb 17 20:06:35 2006 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Fri, 17 Feb 2006 20:06:35 -0000 (WET) Subject: Please rebuild your packages in the development tree of FedoraExtras In-Reply-To: <1140205892.2904.30.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> Message-ID: <54305.192.168.82.254.1140206795.squirrel@webmail.lsd.di.uminho.pt> > Am Montag, den 13.02.2006, 18:22 +0100 schrieb Thorsten Leemhuis: > ... > The script found the following packages in extras/development for which > no entry in the owners.list could be found: fftw3, umfpack, > perl-Gtk2-GladeXML, perl-Imager, perl-Gnome2-Canvas, html-xml-utils, > dia, libdsk, libspectrum, lib765 I believe perl-Gtk2-GladeXML, perl-Imager, and perl-Gnome2-Canvas belong to Gavin Henry (ghenry at suretecsystems.com). IIRC they are sprog requirements. 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 * From j.w.r.degoede at hhs.nl Fri Feb 17 20:31:53 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 17 Feb 2006 21:31:53 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1140205892.2904.30.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> Message-ID: <43F632B9.40904@hhs.nl> Thorsten Leemhuis wrote: > This time also: Replies to fedora-extras-list please, tia! > > Am Montag, den 13.02.2006, 18:22 +0100 schrieb Thorsten Leemhuis: > >> Hi Fedora Maintainers! >> >> The last rawhide mass-rebuild is mostly done now so it's time for us to >> also rebuild **all packages** in the Fedora Extras development tree >> before it becomes Fedora Extras 5 (FE) when Fedora Core 5 is >> branched/released. > > Guys, please keep the buildsys busy. There are a lot of packages that > are still not rebuild afaics. > > I wrote a small script "buildcheck" (attached) that can check what > packages are not yet rebuild. The script is far from perfect but it > works quite well afaics. Maybe it has some bugs -- I'm sure you guys > will find some and tell me about it. > > How does it work? Rough version: It checks the buildtime of all srpms in > extras/development and prints the name and the email of all those that > were rebuild before the official mass-rebuild was announced. > Erm, It seems to check the wrong time/date though, its listing a few of my packages which have all been rebuild, take Glide3 as an example from the changelog: * Mon Feb 13 2006 Hans de Goede 20050815-3 - Bump release and rebuild for new gcc4.1 and glibc. - add %%{?dist} for consistency with my other packages And -3 is on the mirrors dated feb 13, so it has definetly been build and pushed. Regards, Hans From pertusus at free.fr Fri Feb 17 20:34:44 2006 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 17 Feb 2006 21:34:44 +0100 Subject: static libs ... again In-Reply-To: <1140204509.21764.324.camel@mccallum.corsepiu.local> References: <43F6123D.2060900@ieee.org> <1140204509.21764.324.camel@mccallum.corsepiu.local> Message-ID: <20060217203444.GA2977@free.fr> > A USER never has any requirements for static libs. As I said in another thread, there is a demand for static libs, especially math stuff, to have portable binaries, in time and accross linux distributions. It is really handy to be able to compile a model statically and then put the executable on any computer to run it. And it may also be nice to be able to rerun a model some time after, without a need to recompile. I don't have discussed about that subject with a lot of people but in the team I work with we like to compile statically math and plotting stuff. I have absolutely no idea about the number of people interested by static libs, but I don't see any reason to avoid them when there is no security issue, as it allows to build portable binaries. -- Pat From rc040203 at freenet.de Fri Feb 17 20:58:50 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 17 Feb 2006 21:58:50 +0100 Subject: static libs ... again In-Reply-To: <20060217203444.GA2977@free.fr> References: <43F6123D.2060900@ieee.org> <1140204509.21764.324.camel@mccallum.corsepiu.local> <20060217203444.GA2977@free.fr> Message-ID: <1140209930.21764.343.camel@mccallum.corsepiu.local> On Fri, 2006-02-17 at 21:34 +0100, Patrice Dumas wrote: > > A USER never has any requirements for static libs. > > As I said in another thread, there is a demand for static libs, especially > math stuff, to have portable binaries, in time and accross linux > distributions. And you failed to explain :) > It is really handy to be able to compile a model statically > and then put the executable on any computer to run it. And what if your compiled binaries are buggy? What if the ABI to the libraries underneath your libraries change? You'd have to recompile everything. Any what makes math libraries special wrt. to shared libs? Except that they may suffer from some speed penalty, because math apps typically call them frequently, I don't see what makes them different from other "computational expensive" libraries. > And it may also > be nice to be able to rerun a model some time after, without a need to > recompile. I don't have discussed about that subject with a lot of people > but in the team I work with we like to compile statically math and plotting > stuff. Your argumentation is the same as many people come up with when it comes to this topic. IMO, you guys are just trying to "sanction" your malpractice/bad habits (no punt intended). Bundle the shared math libs you had used to compile your applications with your applications, or better package them into packages allowing parallel installation (compat-packages) and all you say will be resolve, except that your application binaries will be (much?) smaller. > I have absolutely no idea about the number of people interested by static > libs, but I don't see any reason to avoid them when there is no security > issue, as it allows to build portable binaries. Cf. above. Security only is one aspect, there are many more. Ralf From dcbw at redhat.com Fri Feb 17 21:16:36 2006 From: dcbw at redhat.com (Dan Williams) Date: Fri, 17 Feb 2006 16:16:36 -0500 Subject: Summary from yesterdays fesco meeting In-Reply-To: <1140205181.2904.20.camel@localhost.localdomain> References: <1140205181.2904.20.camel@localhost.localdomain> Message-ID: <1140210997.6735.22.camel@localhost.localdomain> On Fri, 2006-02-17 at 20:39 +0100, Thorsten Leemhuis wrote: > * Kernel module standardization > * Should archs be hardcoded with a "ExclusiveArch: i586 i686 x86_64 > ppc" or similar entries? That's how it is done in beehive, but scop > doesn't like that idea to much. Warren will ask dcbw if there are > alternatives. Warren poked me, here's my response: ------------------------------------------------------- In the end, it might just be best to leave this up to the buildsystem, since there's a "canonical" list of arches that a particular Distro maintains. There's two factors here: 1) The list of arches a _distro_ supports 2) The list of arches a particular package supports The two are not identical. And even though, for example, all of FC3 was compiled for ppc internally, the original FC3 was not released for ppc at all, and so therefore kernel modules should not be built for FC3/ppc either. Control over the package set that the distro supports is up to the distro maintainers and the build system. So what I think we should end up doing here is to: a) Let packages do whatever the heck they want with their Exclusive, Exclude, BuildArch tags, including using %{ix86} as Mike suggests b) Have the buildsystem recognize kmod packages somehow (which we have to do anyway), then filter kmod packages through a "supported" list of sub-arches, including i586, i686, x86_64, ppc, athlon. There's some support for this already in the buildsystem. This puts a minimum burden on maintainers since lots of this arch stuff is black magic anyway, and should probably be kept in the same place. The nobody gets confused about arches, and there doesn't need to be a 50ft long wiki page about it. Of course, all this is completely separate from the whole xen/hugemem/smp/up fiasco, and much simpler IMHO than those. Let me know what you think. Dan From bugzilla at redhat.com Fri Feb 17 21:23:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 16:23:35 -0500 Subject: [Bug 181534] Review Request: kst - plots scientific data In-Reply-To: Message-ID: <200602172123.k1HLNZeN030427@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kst - plots scientific data https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181534 ------- Additional Comments From orion at cora.nwra.com 2006-02-17 16:23 EST ------- Needs work: * Use of buildroot is not consistant (wiki: PackagingGuidelines#UsingBuildRootOptFlags) = sorry - this was introduced by my ln suggestion (I use RPM_BUILD_ROOT instead of %buildroot). You might try: for x in %{buildroot}%{_defaultdocdir}/HTML/*/%{name}/ do ln -sf ../common $x done Will handle any new languages automatically in the future. I think the dangling link for other languages is fine. - You need to install the .desktop file properly. See http://fedoraproject.org/wiki/Packaging/Guidelines?highlight=%28.desktop%29#head-254ddf07aae20a23ced8cecc219d8f73926e9755 I would also use --delete-original to remove the original. The Applications/Scientific directory structure is not used in Fedora. e.g. (from my kdesvn package): desktop-file-install --vendor=fedora \ --add-category=Qt \ --add-category=KDE \ --add-category=Application \ --add-category=Development \ --add-category=X-Fedora \ --delete-original --dir $RPM_BUILD_ROOT%{_datadir}/applications \ $RPM_BUILD_ROOT%{_datadir}/applications/kde/%{name}.desktop I think that may be it :-)! -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From s.mako at gmx.net Fri Feb 17 21:32:30 2006 From: s.mako at gmx.net (Zoltan Kota) Date: Fri, 17 Feb 2006 22:32:30 +0100 (CET) Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <43F632B9.40904@hhs.nl> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <43F632B9.40904@hhs.nl> Message-ID: On Fri, 17 Feb 2006, Hans de Goede wrote: > It seems to check the wrong time/date though, its listing a few of my > packages which have all been rebuild, take Glide3 as an example from the > changelog: > * Mon Feb 13 2006 Hans de Goede 20050815-3 > - Bump release and rebuild for new gcc4.1 and glibc. > - add %%{?dist} for consistency with my other packages Same for me (Feb 13). Packages: recode, python-bibtex, pybliographer. Zoltan From denis at poolshark.org Fri Feb 17 21:32:26 2006 From: denis at poolshark.org (Denis Leroy) Date: Fri, 17 Feb 2006 13:32:26 -0800 Subject: static libs ... again In-Reply-To: <1140204644.21764.328.camel@mccallum.corsepiu.local> References: <43F6123D.2060900@ieee.org> <43F61E4C.5050404@fedoraproject.org> <1140204644.21764.328.camel@mccallum.corsepiu.local> Message-ID: <43F640EA.6020307@poolshark.org> Ralf Corsepius wrote: > On Fri, 2006-02-17 at 14:04 -0500, Konstantin Ryabitsev wrote: > >>Quentin Spencer wrote: >> >>>So, not too long ago someone asked why I still had static libs in one of >>>my packages since they are "banned" or at least strongly discouraged, so >>>I started removing them from my packages. All of the libraries I >>>maintain are math libraries, so security concerns are a non-issue. After >>>removing the static libs from fftw-devel, it took less than 24 hours to >>>get a bug report asking for them back. See >>>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181897 for the >>>reasoning. > > >>It seems theirs is a rather specific and unique case. Should we change >>policy to accommodate corner cases like that? > > Why? Because a user says he can't build some applications statically? > > What kind of rationale is this? Where is the technical explanation? I've also had a request for reinstating static libs : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178853 I can see how profiling is important here, especially libsigc++ which is a low-level library that is typically used all over C++ code... -denis From pertusus at free.fr Fri Feb 17 21:43:12 2006 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 17 Feb 2006 22:43:12 +0100 Subject: static libs ... again In-Reply-To: <1140209930.21764.343.camel@mccallum.corsepiu.local> References: <43F6123D.2060900@ieee.org> <1140204509.21764.324.camel@mccallum.corsepiu.local> <20060217203444.GA2977@free.fr> <1140209930.21764.343.camel@mccallum.corsepiu.local> Message-ID: <20060217214312.GB2977@free.fr> > > It is really handy to be able to compile a model statically > > and then put the executable on any computer to run it. > And what if your compiled binaries are buggy? What if the ABI to the > libraries underneath your libraries change? I don't understand your point. When I compile statically I get an executable that is statically compiled and not bound to any ABI. And of course if the library is buggy I'll have to recompile (but most of the time math libs have tests that allows to verify that they do the correct thing). > Any what makes math libraries special wrt. to shared libs? > Except that they may suffer from some speed penalty, because math apps > typically call them frequently, I don't see what makes them different > from other "computational expensive" libraries. The math libs are frequently used to compile binaries that don't have security issues. And in my case portability may be convenient, see below. > Your argumentation is the same as many people come up with when it comes > to this topic. IMO, you guys are just trying to "sanction" your > malpractice/bad habits (no punt intended). > > Bundle the shared math libs you had used to compile your applications > with your applications, or better package them into packages allowing > parallel installation (compat-packages) and all you say will be resolve, > except that your application binaries will be (much?) smaller. I think that you don't get the point. I don't want to install the shared lib on another computer that run a maybe completely unrelated linux distro. I just want to run the executable. And it is much less practical to have to bundle the shared libs with the executable to have portability when it is so simple to commpile statically. I will elaborate on my needs. I do numerical models that use math libraries. If they are compiled statically, I can take my binary and run it on another linux distro running, say, a debian stable. Or a redhat 6.1 that still run on a computer which is not connected to the internet, but still in use (unbelievable, isn't it?). I have to compile statically to be able to do that. Even from a fedora core to an older RHEL there are binary incompatibilities. And maybe between fc5 and fc4 for some arches. Another case is that I have a binary, and I want to run it 5 years later, for example to verify a result I found 5 years back. If I don't keep the statically linked executable, I won't be able to reproduce the results (be them right or wrong). As I said this need for portability of binaries may only be a need for a small subset of users, but I can't see how you may achieve the same degree of portability with shared libs. I can't see how you practically handle the above cases (except by bundling the shared libs with the binary, and this is not very practical, and you must also bundle the loader...). -- Pat From triad at df.lth.se Fri Feb 17 22:19:19 2006 From: triad at df.lth.se (Linus Walleij) Date: Fri, 17 Feb 2006 23:19:19 +0100 (CET) Subject: static libs ... again In-Reply-To: <43F6123D.2060900@ieee.org> References: <43F6123D.2060900@ieee.org> Message-ID: I think I get the users point by guessing and extrapolating: Some large-scale installations will have something like /usr/local mounted onto a share in order to provide common applications for all users through this share. This is an old (IMHO bad) habit especially of former SunOS sysadmins. It is especially comfortable when installing a lot of 3rd party binary-only software. Many will use something like "modules" to set up a lot of userland variables to get this going etc. This means a user of several distributions and different versions of the same distribution will need to compile things statically to get them work somewhat on all Linux machines that mounts this share, given that their ABI:s may vary wildly. So while these people appreciate dynamic linking for the most common stuff that sits on the local client, they still want static linking available for their sysadmin daily tasks like this. While such people have a niche use of static libs, we all know that the actual USE of static libs require a lot of hands-on and funny compiler flags. For this reason I think these people are very able of installing the whole shebang and its dependencies from source and not ask their distributor to provide them with tools for this. Alternatively use another distribution which love to build things from source (Slackware, Gentoo) for this work: it is more fitted and not Fedora's ecological niche. So if reasons like this is behind these request, IMHO we should just say "no" to static libs... My Euro 0.01 Linus From ville.skytta at iki.fi Fri Feb 17 22:22:33 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 18 Feb 2006 00:22:33 +0200 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1140205892.2904.30.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> Message-ID: <1140214953.19147.9.camel@bobcat.mine.nu> On Fri, 2006-02-17 at 20:51 +0100, Thorsten Leemhuis wrote: > Guys, please keep the buildsys busy. There are a lot of packages that > are still not rebuild afaics. FYI, all my packages from the list except jikes, which I'll push in a jiffy, are waiting for something (dependency rebuild/update, any-time-now upstream update for stuff in the package) and will be pushed as soon as that "something" is available. From pertusus at free.fr Fri Feb 17 22:33:50 2006 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 17 Feb 2006 23:33:50 +0100 Subject: static libs ... again In-Reply-To: References: <43F6123D.2060900@ieee.org> Message-ID: <20060217223350.GC2977@free.fr> > While such people have a niche use of static libs, we all know that the > actual USE of static libs require a lot of hands-on and funny compiler > flags. I never had to do anything funny to compile statically my numerical models. But it is very possible that my use (scientific numerical models) are not a target for Fedora, which is more targeted for network and desktop? (and yes, of course I can recompile myself the numerical libs I use, liek gsl, lapack, fftw, and redistribute them at the labs where I have some fedora, as rpm or with other mean). But it is a waste of time and resources if there is a more widespread use. -- Pat From bugzilla at redhat.com Fri Feb 17 22:47:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 17:47:21 -0500 Subject: [Bug 177166] Review Request: perl-Compress-Bzip2 - Interface to Bzip2 compression library In-Reply-To: Message-ID: <200602172247.k1HMlLjG018532@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Compress-Bzip2 - Interface to Bzip2 compression library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177166 ------- Additional Comments From ville.skytta at iki.fi 2006-02-17 17:47 EST ------- This package has been in the repo for some time now. Is this report being kept open intentionally? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From jspaleta at gmail.com Fri Feb 17 22:51:48 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 17 Feb 2006 17:51:48 -0500 Subject: static libs ... again In-Reply-To: <20060217223350.GC2977@free.fr> References: <43F6123D.2060900@ieee.org> <20060217223350.GC2977@free.fr> Message-ID: <604aa7910602171451o6fb7fcfm7630ee47715b5a8e@mail.gmail.com> On 2/17/06, Patrice Dumas wrote: < But it is a waste of time and resources > if there is a more widespread use. I produce horribly bad scientific code for a living, and while not having static libs out of the box is an inconvience to what I do. I do not think Fedora should be catering to what is a systemicly broken model of code development which I and other casual scientific code writers participate in. When I use static libraries to do crappy code development I want to make very sure that the static libraries I use are a specific version.. i do not want and can not rely on static libraries from versions which may differ over time from the OS vendor. Having Fedora Extras provide static versions means Extras will be forced to supply compatibility versions of those static libraries forever to meet the needs of this highly technically skilled set of users that make up the scientific programming community. There are deeply systemic problems in the scientific coding practises that I participate in, and I don't want to see progressive projects bending policies to help rather smart people be even lazier about their coding habits. -jef"so very lazy"spaleta From bugzilla at redhat.com Fri Feb 17 23:32:55 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 18:32:55 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602172332.k1HNWtRi026075@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From jvdias at redhat.com 2006-02-17 18:32 EST ------- OK, I've now imported openmpi-1.0.1-1 into rawhide (it remains to be seen whether it will make FC-5) . The SRPM and i386 RPMS are at: http://people.redhat.com/~jvdias/openmpi/ Please test this out and let me know of any issues ASAP - thanks . I've also built lam-7.1.1-10.FC5, with the suggested changes - it should be in tomorrow's rawhide - the srpm is also at the people page above. LAM headers now all live under /usr/include/lam , libraries under /usr/lib/lam, and man-pages in /usr/share/lam/man . There are directory structures that could be used for environment-modules in /usr/share/{lam,openmpi}/{bin,lib,include,man}, and an attempt at module files in /usr/share/{lam,openmpi}/*.module. The binaries which clash between lam and openmpi are shipped named with a prefix that differentiates them: /usr/bin/{om-,lam-}{mpirun,mpiexec,mpicc,mpic++,mpiCC,mpif77} By default, the lam package creates links to its /usr/bin/lam-* files, without the 'lam-' prefix - it will still be the default MPI implementation. There are now pkg-config files for lam and openmpi, and openmpi now contains an /usr/sbin/mpi-alternatives script that can be used to create alternatives for lam / openmpi: $ pkg-config --libs --cflags lam -I/usr/include/lam -L/usr/lib/lam -lmpi $ pkg-config --libs --cflags openmpi -I/usr/include/openmpi -L/usr/lib/openmpi -lmpi $ mpi_alternatives Usage: mpi_alternatives < install | display | remove | set> Sets up alternatives for MPI (Message Passing Interface) between LAM and OpenMPI implementations. $ mpi_alternatives install $ mpi_alternatives display mpi - status is manual. link currently points to /usr/bin/lam-mpirun /usr/bin/om-mpirun - priority 50 slave mpiCC: /usr/bin/om-mpic++ slave mpic++: /usr/bin/om-mpic++ slave mpicc: /usr/bin/om-mpicc slave mpiexec: /usr/bin/om-mpiexec slave mpif77: /usr/bin/om-mpif77 /usr/bin/lam-mpirun - priority 50 slave mpiCC: /usr/bin/lam-mpic++ slave mpic++: /usr/bin/lam-mpic++ slave mpicc: /usr/bin/lam-mpicc slave mpiexec: /usr/bin/lam-mpiexec slave mpif77: /usr/bin/lam-mpif77 Current `best' version is /usr/bin/om-mpirun. $ mpi_alternatives set openmpi $ mpi_alternatives display mpi - status is manual. link currently points to /usr/bin/om-mpirun /usr/bin/om-mpirun - priority 50 slave mpiCC: /usr/bin/om-mpic++ slave mpic++: /usr/bin/om-mpic++ slave mpicc: /usr/bin/om-mpicc slave mpiexec: /usr/bin/om-mpiexec slave mpif77: /usr/bin/om-mpif77 /usr/bin/lam-mpirun - priority 50 slave mpiCC: /usr/bin/lam-mpic++ slave mpic++: /usr/bin/lam-mpic++ slave mpicc: /usr/bin/lam-mpicc slave mpiexec: /usr/bin/lam-mpiexec slave mpif77: /usr/bin/lam-mpif77 Current `best' version is /usr/bin/om-mpirun. $ mpi_alternatives set lam $ mpi_alternatives display mpi - status is manual. link currently points to /usr/bin/lam-mpirun /usr/bin/om-mpirun - priority 50 slave mpiCC: /usr/bin/om-mpic++ slave mpic++: /usr/bin/om-mpic++ slave mpicc: /usr/bin/om-mpicc slave mpiexec: /usr/bin/om-mpiexec slave mpif77: /usr/bin/om-mpif77 /usr/bin/lam-mpirun - priority 50 slave mpiCC: /usr/bin/lam-mpic++ slave mpic++: /usr/bin/lam-mpic++ slave mpicc: /usr/bin/lam-mpicc slave mpiexec: /usr/bin/lam-mpiexec slave mpif77: /usr/bin/lam-mpif77 Current `best' version is /usr/bin/om-mpirun. Please let me know of any issues / problems with the above - thanks. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 18 00:19:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 19:19:30 -0500 Subject: [Bug 181534] Review Request: kst - plots scientific data In-Reply-To: Message-ID: <200602180019.k1I0JUZ3004846@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kst - plots scientific data https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181534 ------- Additional Comments From matt at truch.net 2006-02-17 19:19 EST ------- (In reply to comment #11) > Needs work: > * Use of buildroot is not consistant > > for x in %{buildroot}%{_defaultdocdir}/HTML/*/%{name}/ > do > ln -sf ../common $x > done Done. I like that. > - You need to install the .desktop file properly. See Done. > I think that may be it :-)! Cool. New packages at the usual place: http://matt.truch.net/fedora/kst.spec http://matt.truch.net/fedora/kst-1.2.0-6.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 18 02:11:25 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 21:11:25 -0500 Subject: [Bug 180068] Review Request: geoip - Library for mapping IP/hostname to a country/city/organization In-Reply-To: Message-ID: <200602180211.k1I2BPcG021396@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: geoip - Library for mapping IP/hostname to a country/city/organization https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180068 ------- Additional Comments From mfleming+rpm at enlartenment.com 2006-02-17 21:11 EST ------- Another round o' SRPMS :-) http://www.enlartenment.com/extras/GeoIP.spec http://www.enlartenment.com/extras/GeoIP-1.3.14-3.src.rpm (In reply to comment #3) > (In reply to comment #2) > > (some warnings re: > > the .so symlinks, but that's about all.) > > This is a blocker, please fix (lib*.so must go to *-devel, lib*.so.* to non-devel) Done. > > > Also arguable: > Obsoletes: geoip > Provides: geoip > > This should probably be: > Obsoletes: geoip < %{version}-%{release} > Provides: geoip = %{version}-%{release} Done, with a similar pairing for -devel to ensure it's handled reasonably cleanly. > Also missing in the *-devel package: > Provides: geoip-devel = %{version}-%{release} > > Alternatively, you could consider to drop supporting "geoip". Doable, but given that both I and Rudolf Kastl have shipped packages as "geoip" in the past I felt it best to go with the above suggestions and give the user a clean upgrade path (working on the principle of least surprise) Michael. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From ed at eh3.com Sat Feb 18 02:38:24 2006 From: ed at eh3.com (Ed Hill) Date: Fri, 17 Feb 2006 21:38:24 -0500 Subject: static libs ... again In-Reply-To: References: <43F6123D.2060900@ieee.org> Message-ID: <1140230304.31903.54.camel@ernie> Hi folks, Is there is a middle ground in this static libs discussion? For instance, are there technical solutions such as: - all static libs should or perhaps must be in a -static sub-package - no -static sub-packages are allowed as BuildRequires for other FC or FE packages - the -static packages are strictly optional so maintainers may provide them or not at their own discretion that would be acceptable to everyone? Ed ps - I realize that I'm currently part of the static libs problem. The netcdf package, for now, only provides static libs and other packages (eg. ncview, nco, cdo) use them. I've created patches to netcdf3 that allow it to build shared libs and will either apply them or move to netcdf4 (which has shared lib support) if it gets out of beta relatively soon. -- 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 bugzilla at redhat.com Sat Feb 18 03:01:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 22:01:07 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602180301.k1I316Tr027775@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From dakingun at gmail.com 2006-02-17 22:00 EST ------- Oops, no mpif90 ?? I'm very sure gfortran in rawhide compiles the f90 module just fine, please include it. Anyway thanks for this nice new structure. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 18 04:31:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 23:31:09 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602180431.k1I4V9hq012590@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-17 23:31 EST ------- Here's the full review: - MUST: rpmlint must be run on every package. The output should be posted in the review. Not OK: [jcollie at lt16585 result]$ rpmlint ser-*.i386.rpm | grep -v debuginfo W: ser-postgresql doc-file-dependency /usr/share/doc/ser-postgresql-0.9.6/copy_to_psql /usr/bin/perl Remove execute permission from this script and dependency shouldn't be picked up. - MUST: The package must be named according to the Package Naming Guidelines. OK - MUST: The spec file name must match the base package %{name}, in the format %{name}.spec OK - MUST: The package must meet the Packaging Guidelines. OK, with the following notes: Could the serweb html files be moved to /var/www/html/serweb? This could potentially be a problem with SELinux, as well as conforming more to existing practice. I see that serweb includes an (old) copy of the Smarty templating system. Smarty is already in FE. Is it possible to remove the copy from serweb and use the newer version from FE? It looks like you could delete everything but smarty_serweb.php. After patching up that file (and manybe some others) you should be able to use the FE version. - MUST: The package must be licensed with an open-source compatible license and meet other legal requirements as defined in the legal section of Packaging Guidelines. OK (GPL) - MUST: The License field in the package spec file must match the actual license. OK - MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc. OK - MUST: The spec file must be written in American English. OK - MUST: The spec file for the package MUST be legible. If the reviewer is unable to read the spec file, it will be impossible to perform a review. Fedora Extras is not the place for entries into the Obfuscated Code Contest ([WWW] http://www.ioccc.org/). OK - MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. OK 31031225d483c0d5ac43e8eb5d0428e0 originals/ser-0.9.6_src.tar.gz fa0647598c9370c91650386befd63fba originals/serweb-0.9.4.tar.gz 31031225d483c0d5ac43e8eb5d0428e0 sources/ser-0.9.6_src.tar.gz fa0647598c9370c91650386befd63fba sources/serweb-0.9.4.tar.gz - MUST: The package must successfully compile and build into binary rpms on at least one supported architecture. OK (builds on i386/devel & i386/FC4) - MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch needs to have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number should then be placed in a comment, next to the corresponding ExcludeArch line. New packages will not have bugzilla entries during the review process, so they should put this description in the comment until the package is approved, then file the bugzilla entry, and replace the long explanation with the bug number. The bug should be marked as blocking one (or more) of the following bugs to simplify tracking such issues: [WWW] FE-ExcludeArch-x86, [WWW] FE-ExcludeArch-x64, [WWW] FE-ExcludeArch-ppc OK - MUST: A package must not contain any BuildRequires that are listed in the exceptions section of Packaging Guidelines. OK - MUST: All other Build dependencies must be listed in BuildRequires. OK - MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden. OK (no localized files) - MUST: If the package contains shared library files located in the dynamic linker's default paths, that package must call ldconfig in %post and %postun. If the package has multiple subpackages with libraries, each subpackage should also have a %post/%postun section that calls /sbin/ldconfig. An example of the correct syntax for this is: %post -p /sbin/ldconfig %postun -p /sbin/ldconfig OK - MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. OK (not relocatable) - MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. The exception to this are directories listed explicitly in the Filesystem Hierarchy Standard ([WWW] http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to assume that those directories exist. Not OK (/etc/ser not owned by main package.) - MUST: A package must not contain any duplicate files in the %files listing. Not OK (/etc/ser/serweb is duplicated between main package and serweb subpackage.) - MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. OK - MUST: Each package must have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). OK - MUST: Each package must consistently use macros, as described in the macros section of Packaging Guidelines. Not OK (%clean section uses $RPM_BUILD_ROOT while %{buildroot} is used elsewhere.) - MUST: The package must contain code, or permissable content. This is described in detail in the code vs. content section of Packaging Guidelines. OK - MUST: Large documentation files should go in a -docs subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity) OK - MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. OK - MUST: Header files or static libraries must be in a -devel package. OK - MUST: Files used by pkgconfig (.pc files) must be in a -devel package. OK - MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. OK - MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency. OK - MUST: Packages must NOT contain any .la libtool archives, these should be removed in the spec. OK - MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. This is described in detail in the desktop files section of Packaging Guidelines. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. OK - MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora Extras should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. OK - SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. OK - SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available. OK - SHOULD: The reviewer should test that the package builds in mock. OK (build in mock devel/i386) - SHOULD: The package should compile and build into binary rpms on all supported architectures. Tested i386/devel and i386/FC4. - SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example. OK (only main package tested) - SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity. OK - SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency. OK Needs a bit more work, and then I'll approve it... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 18 04:32:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 23:32:44 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602180432.k1I4Wi4M012943@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-17 23:32 EST ------- Also, it would be nice to have the radius modules, but since that appears to need the radiusclient-ng package that can wait until radiusclient-ng is included in FE. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 18 04:46:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 17 Feb 2006 23:46:15 -0500 Subject: [Bug 180068] Review Request: geoip - Library for mapping IP/hostname to a country/city/organization In-Reply-To: Message-ID: <200602180446.k1I4kF1q014851@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: geoip - Library for mapping IP/hostname to a country/city/organization https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180068 rc040203 at freenet.de changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From rc040203 at freenet.de 2006-02-17 23:46 EST ------- APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rdieter at math.unl.edu Sat Feb 18 05:02:26 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 17 Feb 2006 23:02:26 -0600 Subject: static libs ... again In-Reply-To: <1140230304.31903.54.camel@ernie> References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> Message-ID: Ed Hill wrote: > Is there is a middle ground in this static libs discussion? > > For instance, are there technical solutions such as: > > - all static libs should or perhaps must be in a -static > sub-package IMO, no point. If a packager really wants them, put 'em in -devel. > - no -static sub-packages are allowed as BuildRequires for > other FC or FE packages In general, agreed. > - the -static packages are strictly optional so maintainers > may provide them or not at their own discretion I'd argue the general rule should be that static libs be omitted, unless there is (very) good reason to include otherwise. -- Rex From pertusus at free.fr Fri Feb 17 23:06:17 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 18 Feb 2006 00:06:17 +0100 Subject: static libs ... again In-Reply-To: <604aa7910602171451o6fb7fcfm7630ee47715b5a8e@mail.gmail.com> References: <43F6123D.2060900@ieee.org> <20060217223350.GC2977@free.fr> <604aa7910602171451o6fb7fcfm7630ee47715b5a8e@mail.gmail.com> Message-ID: <20060217230617.GE2977@free.fr> > writers participate in. When I use static libraries to do crappy code > development I want to make very sure that the static libraries I use > are a specific version.. i do not want and can not rely on static > libraries from versions which may differ over time from the OS vendor. It is not the use I do, nor advocate ;-). As I said above it is to achieve portability of the executable. And I certainly don't advocate especially compat libs. > Having Fedora Extras provide static versions means Extras will be > forced to supply compatibility versions of those static libraries > forever to meet the needs of this highly technically skilled set of I don't think so nor advocate it. Providing the static library doesn't mean having compat libraries. (as a side note I don't see anything wrong in providing compat libraries if they are properly packaged and there is a maintainer). > users that make up the scientific programming community. There are > deeply systemic problems in the scientific coding practises that I > participate in, and I don't want to see progressive projects bending > policies to help rather smart people be even lazier about their coding > habits. It is not by not providing static libs that better coding practices will be used. Once more I advocate static libs for their portability, and in the cases when the reasons to use shared libs don't hold. -- Pat From orion at cora.nwra.com Sat Feb 18 05:47:45 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 17 Feb 2006 22:47:45 -0700 Subject: PLEASE HELP - We need a policy for preventing man page name conflicts Message-ID: <43F6B501.1040105@cora.nwra.com> Many packages provide man3 (and other) man pages with generic names. The case in question in ncarg-devel and allegro-devel which both provide man3/line.3.gz. So, what do we do? - package in /usr/share//man/? If so, how to we update MANPATH? How does man handle finding both (all) of the man pages? - rename to something like _? Do we always do this? Only if a file conflicts? Is there an easy way to find conflicts before packaging? - suffixes .3 ? Can man handle this? Please help! -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From pertusus at free.fr Fri Feb 17 22:44:02 2006 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 17 Feb 2006 23:44:02 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1140205892.2904.30.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> Message-ID: <20060217224402.GD2977@free.fr> > pertusus at free.fr libdap > pertusus at free.fr libnc-dap This doesn't build in extras, it is fixed in upstream cvs, so I am waiting for a release. Other have been rebuilt. -- Pat From bugzilla at redhat.com Sat Feb 18 05:53:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 00:53:50 -0500 Subject: [Bug 180068] Review Request: geoip - Library for mapping IP/hostname to a country/city/organization In-Reply-To: Message-ID: <200602180553.k1I5rolF023556@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: geoip - Library for mapping IP/hostname to a country/city/organization https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180068 mfleming+rpm at enlartenment.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NEXTRELEASE AssignedTo|rc040203 at freenet.de |bugzilla-sink at leemhuis.info ------- Additional Comments From mfleming+rpm at enlartenment.com 2006-02-18 00:53 EST ------- Imported into CVS and a devel branch build kicked off. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 18 06:18:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 01:18:13 -0500 Subject: [Bug 181974] New: Review Request: mod_geoip - Apache module for GeoIP lookups Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181974 Summary: Review Request: mod_geoip - Apache module for GeoIP lookups Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: mfleming+rpm at enlartenment.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.enlartenment.com/extras/mod_geoip.spec SRPM Name or Url: http://www.enlartenment.com/extras/mod_geoip-1.1.7-2.src.rpm Description: mod_geoip is an Apache module for finding the country that a web request originated from. It uses the GeoIP library and database to perform the lookup. It is free software, licensed under the Apache license. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rc040203 at freenet.de Sat Feb 18 06:25:07 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 18 Feb 2006 07:25:07 +0100 Subject: static libs ... again In-Reply-To: References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> Message-ID: <1140243907.21764.402.camel@mccallum.corsepiu.local> On Fri, 2006-02-17 at 23:02 -0600, Rex Dieter wrote: > Ed Hill wrote: > > > Is there is a middle ground in this static libs discussion? > > > > For instance, are there technical solutions such as: > > > > - all static libs should or perhaps must be in a -static > > sub-package > > IMO, no point. I disagree. *-static would make packages using these static libs clearly identifiable from examining these packages' spec or src.rpm. "Lumping together" static and shared libs into *-devel, hides away usage of static libs from packaging. > If a packager really wants them, put 'em in -devel. Cf. above. > > - no -static sub-packages are allowed as BuildRequires for > > other FC or FE packages > > In general, agreed. ACK. > > - the -static packages are strictly optional so maintainers > > may provide them or not at their own discretion > > I'd argue the general rule should be that static libs be omitted, unless > there is (very) good reason to include otherwise. ACK. Ralf From wtogami at redhat.com Sat Feb 18 07:43:10 2006 From: wtogami at redhat.com (Warren Togami) Date: Sat, 18 Feb 2006 02:43:10 -0500 Subject: static libs ... again In-Reply-To: <20060217223350.GC2977@free.fr> References: <43F6123D.2060900@ieee.org> <20060217223350.GC2977@free.fr> Message-ID: <43F6D00E.5020905@redhat.com> Patrice Dumas wrote: >> While such people have a niche use of static libs, we all know that the >> actual USE of static libs require a lot of hands-on and funny compiler >> flags. > > I never had to do anything funny to compile statically my numerical models. > But it is very possible that my use (scientific numerical models) are not > a target for Fedora, which is more targeted for network and desktop? > (and yes, of course I can recompile myself the numerical libs I use, liek > gsl, lapack, fftw, and redistribute them at the labs where I have some > fedora, as rpm or with other mean). But it is a waste of time and resources > if there is a more widespread use. IMHO, if you are building your own numerical crunching apps, then you probably would be better off controlling all aspects of building each static portion of it. This means writing your own scripts and tuning compile flags of portions of the app to maximize performance. This may also mean applying your own patches that may be unsuitable for a more general purpose distribution. If you rely on a distribution's static libraries, then there is no guarantee in the future that those static libs will remain unchanged in API, so if you ever need to rebuild your app with a tiny change you could be affected by far more than the change that you expected. Warren Togami wtogami at redhat.com From bugzilla at redhat.com Sat Feb 18 07:40:42 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 02:40:42 -0500 Subject: [Bug 180068] Review Request: geoip - Library for mapping IP/hostname to a country/city/organization In-Reply-To: Message-ID: <200602180740.k1I7eguS005668@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: geoip - Library for mapping IP/hostname to a country/city/organization https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180068 wtogami at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wtogami at redhat.com, | |lmacken at redhat.com, | |skvidal at phy.duke.edu, | |katzj at redhat.com ------- Additional Comments From wtogami at redhat.com 2006-02-18 02:40 EST ------- Interesting, would something like this be useful to aid in smarter auto-mirror selection for yum? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From buildsys at fedoraproject.org Sat Feb 18 07:48:51 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 18 Feb 2006 02:48:51 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060218074851.DE3298011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 2 lcdf-typetools-2.37-1.fc3 scponly-4.6-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat Feb 18 07:49:19 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 18 Feb 2006 02:49:19 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060218074919.0F7388011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 3 grads-1.9b4-7.fc4.1 lcdf-typetools-2.37-1.fc4 scponly-4.6-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat Feb 18 07:51:26 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 18 Feb 2006 02:51:26 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060218075126.C14C28011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 62 GeoIP-1.3.14-3.fc5 GtkAda-2.4.0-11.fc5 abcm2ps-4.12.8-2.fc5 altermime-0.3.6-2.fc5 cfengine-2.1.18-2.fc5 clisp-2.38-2.fc5 cook-2.26-2.fc5 docbook2X-0.8.5-2.fc5 drivel-2.0.2-2.fc5 epiphany-extensions-1.9.7-1 firestarter-1.0.3-10.fc5 gfontview-0.5.0-5.fc5 gforth-0.6.2-6.fc5 gl-117-1.3.2-2.fc5 global-4.8.7-3.fc5 gnonlin-0.10.0.5-6 graveman-0.3.12.4-3.fc5 gtkglarea2-1.99.0-5.fc5 jikes-1.22-5.fc5 lcdf-typetools-2.37-1.fc5 libvisual-plugins-0.2.0-3.fc5 linkchecker-3.3-3 mercurial-0.8-2.fc5 nautilus-open-terminal-0.6-3.fc5 new-1.3.7-2 ocaml-3.09.1-2.fc5 octave-forge-2006.01.28-5.fc5 pan-0.14.2.91-4.fc5 perl-AppConfig-1.56-4.fc5 perl-Authen-SASL-2.09-4.fc5 perl-Class-MethodMaker-2.08-2 perl-DBD-XBase-0.241-3.fc5 perl-Digest-MD4-1.5-2.fc5 perl-Error-0.15-4.fc5 perl-ExtUtils-PkgConfig-1.07-4.fc5 perl-Hook-LexWrap-0.20-3.fc5 perl-Image-Size-2.992-5.fc5 perl-Image-Xbm-1.08-5.fc5 perl-Image-Xpm-1.09-5.fc5 perl-Locale-Maketext-Fuzzy-0.02-3.fc5 perl-MLDBM-2.01-4.fc5 perl-Mail-Sender-0.8.10-3.fc5 perl-Mail-Sendmail-0.79-8.fc5 perl-Pod-Coverage-0.17-5.fc5 perl-Test-Pod-1.24-2.fc5 pl-5.6.3-2.fc5 plt-scheme-301-2.fc5 qcad-2.0.5.0-4.fc5 roundup-0.8.4-7 rpmlint-0.75-1.fc5 scons-0.96-6.fc5 scponly-4.6-1.fc5 skencil-0.6.17-7.fc5 smb4k-0.6.7-4.fc5 tagtool-0.12.2-3.fc5 tetex-tex4ht-1.0.2006_02_15_1234-1.fc5 tkcvs-8.0.2-2.fc5 tuxtype2-1.5.3-1.fc5 x3270-3.3.4p6-5.fc5 xmldiff-0.6.7-10.fc5 xmlstarlet-1.0.1-3.fc5 yap-5.0.1-2.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Sat Feb 18 07:52:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 02:52:07 -0500 Subject: [Bug 180068] Review Request: geoip - Library for mapping IP/hostname to a country/city/organization In-Reply-To: Message-ID: <200602180752.k1I7q7fg007082@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: geoip - Library for mapping IP/hostname to a country/city/organization https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180068 ------- Additional Comments From mfleming+rpm at enlartenment.com 2006-02-18 02:52 EST ------- Probably, I know the PHP devs use it for mirror selection so it's definitely possible. Would you like me to package up the Python bindings too? They're fairly small and would seem very appropriate. (I've got the Apache module submitted and have done the Perl bindings before, but that latter spec needs some *serious* love before I let reviewers rip into it.) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 18 08:02:26 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 03:02:26 -0500 Subject: [Bug 180068] Review Request: geoip - Library for mapping IP/hostname to a country/city/organization In-Reply-To: Message-ID: <200602180802.k1I82QBu008313@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: geoip - Library for mapping IP/hostname to a country/city/organization https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180068 ------- Additional Comments From wtogami at redhat.com 2006-02-18 03:02 EST ------- Python bindings would be very appropriate and useful. Apache module sounds useful too, but it should be a separate package. Perl is not too useful for Fedora specifically, but some people might like it. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From fedora at leemhuis.info Sat Feb 18 08:34:16 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Feb 2006 09:34:16 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <43F632B9.40904@hhs.nl> Message-ID: <1140251657.2904.24.camel@localhost.localdomain> Hello Hans, Zoltan, everybody else. Am Freitag, den 17.02.2006, 22:32 +0100 schrieb Zoltan Kota: > On Fri, 17 Feb 2006, Hans de Goede wrote: > > It seems to check the wrong time/date though, its listing a few of my > > packages which have all been rebuild, take Glide3 as an example from the > > changelog: > > * Mon Feb 13 2006 Hans de Goede 20050815-3 > > - Bump release and rebuild for new gcc4.1 and glibc. > > - add %%{?dist} for consistency with my other packages > > Same for me (Feb 13). Packages: recode, python-bibtex, pybliographer. Well, I had to define a point in time *somewhere*. I took the obvious one: The time when I announced the mass rebuild. The exact one. I know that the rawhide push with the results from the mass rebuild was done some hours earlier, but it also takes some time until it hits the buildsys afaik. Yes, that was Feb 13, but to be precise it was: $ date --date='2006-02-13 18:22:00 CET' +%s 1139851320 Then I looked at the repoquery-output from $ repoquery -a --repoid=buildcheck-extras-development-sources --repoid=buildcheck-extras-development-buildsys --qf='%{buildtime} %{name}' *.src | sort [...] 1139849567 ngrep 1139850811 syck 1139851916 ttywatch 1139851945 contact-lookup-applet 1139852218 dkms [...] So I took everything above ttywatch in this list as "needs rebuild". Hans, Zoltan, sorry, but your packages were rebuild just before that point of time: $ repoquery -a --repoid=buildcheck-extras-development-sources --repoid=buildcheck-extras-development-buildsys --qf='%{buildtime} %{name}' *.src | sort | grep -e Glide3$ -e recode$ -e python-bibtex$ -e pybliographer$ 1139826189 recode 1139828260 python-bibtex 1139829715 pybliographer 1139845307 Glide3 Okay. We can revisit that point in time and can set i back some hours -- but where exactly? And wherever we put it, there will probably always be someone who'll say "My package was rebuild just minutes earlier then , why does it need a rebuild?" This could soon lead to and endless discussion that might take a lot of more time then it takes to just rebuild the packages in question... But Hans, Zoltan, if you come up with a new point of time that is acceptable for everyone I'm willing to change the script to that one. CU thl -- Thorsten Leemhuis From seg at haxxed.com Sat Feb 18 08:51:19 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 18 Feb 2006 02:51:19 -0600 Subject: static libs ... again In-Reply-To: <20060217230617.GE2977@free.fr> References: <43F6123D.2060900@ieee.org> <20060217223350.GC2977@free.fr> <604aa7910602171451o6fb7fcfm7630ee47715b5a8e@mail.gmail.com> <20060217230617.GE2977@free.fr> Message-ID: <1140252679.21695.8.camel@localhost> On Sat, 2006-02-18 at 00:06 +0100, Patrice Dumas wrote: > It is not the use I do, nor advocate ;-). As I said above it is to > achieve portability of the executable. I really don't buy this argument. If you're really wanting to move a binary from one system to another, you can just as easily move the libraries it depends on as well. Use LD_LIBRARY_PATH. I did this on several occasions years ago, to run a binary compiled on Red Hat on a Debian system. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From bugzilla at redhat.com Sat Feb 18 08:40:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 03:40:49 -0500 Subject: [Bug 180068] Review Request: geoip - Library for mapping IP/hostname to a country/city/organization In-Reply-To: Message-ID: <200602180840.k1I8enZD016545@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: geoip - Library for mapping IP/hostname to a country/city/organization https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180068 ------- Additional Comments From rc040203 at freenet.de 2006-02-18 03:40 EST ------- (In reply to comment #9) > Python bindings would be very appropriate and useful. If these are a packaged as a separate add-on package, yes. Please file separate review request. > Apache module sounds > useful too, but it should be a separate package. Perl is not too useful for > Fedora specifically, but some people might like it. I love this kind of biased missionary statements. Perl might not be much of RH's interest (Yours), but it definitely is in Fedora Project's interest (e.g. mine). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 18 09:13:55 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 04:13:55 -0500 Subject: [Bug 180068] Review Request: geoip - Library for mapping IP/hostname to a country/city/organization In-Reply-To: Message-ID: <200602180913.k1I9Dt4x023233@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: geoip - Library for mapping IP/hostname to a country/city/organization https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180068 ------- Additional Comments From mfleming+rpm at enlartenment.com 2006-02-18 04:13 EST ------- (In reply to comment #10) > (In reply to comment #9) > > Python bindings would be very appropriate and useful. > If these are a packaged as a separate add-on package, yes. > Please file separate review request. Yes, I'll be making seperate requests once I'm satisfied they're sane and fit for Extras consumption. For GeoIP-Python, I'm running a local build of a quick spec built off the python template. It's not a huge package so should not take long to build (and hopefully review) > > Apache module sounds > > useful too, but it should be a separate package. Perl is not too useful for > > Fedora specifically, but some people might like it. > I love this kind of biased missionary statements. Perl might not be much of RH's > interest (Yours), but it definitely is in Fedora Project's interest (e.g. mine). I get the impression Warren was referring to it being of lesser interest to Fedora in the sense of the core package engineers / tools developers et. al - it would see less usage as a significant amount of "innards and internals" code (yum, anaconda etc.) is in Python rather than Perl. I'm sure it's useful to at least some Fedora / Extras users :-P My primary reason for mentioning it (GeoIP perl bindings) was as a nice complement to Extras' AWStats package - the geoip plugin uses it for more accurate country lookups, which I've got working quite nicely over here with minimal effort. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 18 09:59:57 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 04:59:57 -0500 Subject: [Bug 176532] Review Request: TurboGears: Back-to-front web development in Python In-Reply-To: Message-ID: <200602180959.k1I9xv6L029947@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: TurboGears: Back-to-front web development in Python https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176532 ------- Additional Comments From ivazquez at ivazquez.net 2006-02-18 04:59 EST ------- I've updated the package a bit. See if that error still happens. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From pertusus at free.fr Sat Feb 18 10:09:28 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 18 Feb 2006 11:09:28 +0100 Subject: static libs ... again In-Reply-To: <1140230304.31903.54.camel@ernie> References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> Message-ID: <20060218100928.GC2977@free.fr> > ps - I realize that I'm currently part of the static libs > problem. The netcdf package, for now, only provides > static libs and other packages (eg. ncview, nco, cdo) > use them. I've created patches to netcdf3 that allow > it to build shared libs and will either apply them or > move to netcdf4 (which has shared lib support) if it > gets out of beta relatively soon. netcdf package only providing static libs is a completly different issue. In that case there is no shared libs upstream. In my opinion, it is nice if you add support for shared libs in the fedora version, but this is certainly not a requirement as it may be a fair amount of work, and may conflict later with what is done upstream. My personal advice in that case is that it should also be worked out with the upstream and avoid doing specific things in fedora core, in case the upstream is willing to cooperate. The case I am discussed is when there are static and dynamic libraries, and I am advocating, in some case, to distribute the libraries (be it in -devel or -static). -- Pat From bugzilla at redhat.com Sat Feb 18 10:13:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 05:13:48 -0500 Subject: [Bug 181979] New: Review Request: python-geoip - Python bindings for the GeoIP geographical lookup libraries Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181979 Summary: Review Request: python-geoip - Python bindings for the GeoIP geographical lookup libraries Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: mfleming+rpm at enlartenment.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.enlartenment.com/extras/python-geoip.spec SRPM Name or Url: http://www.enlartenment.com/extras/python-geoip-1.2.1-1.src.rpm Description: This package contains the Python bindings for the GeoIP API, allowing IP to location lookups to country, city and organization level within Python code -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From paul at city-fan.org Sat Feb 18 10:45:52 2006 From: paul at city-fan.org (Paul Howarth) Date: Sat, 18 Feb 2006 10:45:52 +0000 Subject: static libs ... again In-Reply-To: <1140230304.31903.54.camel@ernie> References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> Message-ID: <1140259552.11256.10.camel@laurel.intra.city-fan.org> On Fri, 2006-02-17 at 21:38 -0500, Ed Hill wrote: > Hi folks, > > Is there is a middle ground in this static libs discussion? > > For instance, are there technical solutions such as: > > - all static libs should or perhaps must be in a -static > sub-package > - no -static sub-packages are allowed as BuildRequires for > other FC or FE packages Wouldn't this be a problem for building lib-A-static, which depends on lib-B-static? Without a BR of lib-B-static, lib-A-static would be dynamically linked to lib-B, rather defeating the purpose of having lib-A-static? Or am I horribly confused? Paul. From andreas.bierfert at lowlatency.de Sat Feb 18 11:26:58 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sat, 18 Feb 2006 12:26:58 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1140205892.2904.30.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> Message-ID: <43F70482.3070500@lowlatency.de> Thorsten Leemhuis wrote: > andreas.bierfert at lowlatency.de fbdesk > andreas.bierfert at lowlatency.de fluxbox These two don't build with gcc4.1. The issue has been reported upstream and I hope fixes are on their way... > andreas.bierfert at lowlatency.de lcms Moved to core... > andreas.bierfert at lowlatency.de orange > andreas.bierfert at lowlatency.de synce-gnomevfs > andreas.bierfert at lowlatency.de synce-software-manager > andreas.bierfert at lowlatency.de synce-trayicon Waiting for synce... > andreas.bierfert at lowlatency.de synce Does not like stack protector again... need to do some work there > andreas.bierfert at lowlatency.de wine Should be underway soon... =) - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred From liljencrantz at gmail.com Sat Feb 18 11:28:10 2006 From: liljencrantz at gmail.com (Axel Liljencrantz) Date: Sat, 18 Feb 2006 12:28:10 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1140251657.2904.24.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <43F632B9.40904@hhs.nl> <1140251657.2904.24.camel@localhost.localdomain> Message-ID: <7dad0d770602180328j5c29e31bkc46b7d0705054d9c@mail.gmail.com> What packages replace xorg-x11-devel in FC5? Specifically, what packages provide: * X11/StringDefs.h * X11/Xlib.h * X11/Intrinsic.h * X11/Xatom.h -- Axel From andreas.bierfert at lowlatency.de Sat Feb 18 11:36:33 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sat, 18 Feb 2006 12:36:33 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <7dad0d770602180328j5c29e31bkc46b7d0705054d9c@mail.gmail.com> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <43F632B9.40904@hhs.nl> <1140251657.2904.24.camel@localhost.localdomain> <7dad0d770602180328j5c29e31bkc46b7d0705054d9c@mail.gmail.com> Message-ID: <43F706C1.9030106@lowlatency.de> Axel Liljencrantz wrote: > What packages replace xorg-x11-devel in FC5? > > Specifically, what packages provide: > > * X11/StringDefs.h > * X11/Xlib.h > * X11/Intrinsic.h > * X11/Xatom.h > > > -- > Axel > libXt-devel.x86_64 1.0.0-2.2 development Matched from: /usr/include/X11/StringDefs.h Importing Additional filelist information for dependency resolution libX11-devel.x86_64 1.0.0-2.2 development Matched from: /usr/include/X11/Xlib.h Importing Additional filelist information for dependency resolution libXt-devel.x86_64 1.0.0-2.2 development Matched from: /usr/include/X11/Intrinsic.h Importing Additional filelist information for dependency resolution xorg-x11-proto-devel.x86_64 7.0-1 development Matched from: /usr/include/X11/Xatom.h - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred From fedora at leemhuis.info Sat Feb 18 12:00:09 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Feb 2006 13:00:09 +0100 Subject: FE Package Status of Feb 16, 2006 In-Reply-To: <200602161627.k1GGRAOi020957@ludwig-alpha.unil.ch> References: <200602161627.k1GGRAOi020957@ludwig-alpha.unil.ch> Message-ID: <1140264009.2904.119.camel@localhost.localdomain> Am Donnerstag, den 16.02.2006, 17:27 +0100 schrieb Christian.Iseli at licr.org: > Here's the weekly status. > Again: Thanks for you great work Christian. > I had a quick email exchange with Jef and I agreed > to add some stats about CVS repo and open bugs. I unexpectedly found some > time to look into it and added some lines to the report. > >FE Package Status of Feb 16, 2006 > > The full report can be found here: > http://fedoraproject.org/wiki/Extras/PackageStatus > Quite long now. That's a bit problematic afaics. I really would like to have the important stuff more highlighted. For example, the stuff that really needs fixing (or at least needs a explanation why it's broken) should also be sent to the list IMHO. Or maybe directly to the E-Mail addresses listed. Maybe both. I mean the following sections: - "Packages not present in the development repo" -- There are a lot of good reasons why this is the case. We maintain http://www.fedoraproject.org/wiki/Extras/PackagesNoLongerInDevel for those. But a lot of those that are still in the report look a bit suspect -- maybe some are orphaned in fact? For example qemu -- dwmw2 probably has other things to do and forgot about it. He needs to be poked. And I'm optimistic that someone else is interested in it and would like to take over ownership of it in case dwmw2 lost interest. - "Packages missing in owners.list" -- I send a mail out on that ropic an hour ago. If all owners react we should get rid of those soon. - "Orphaned packages present in the development repo" -- They normally should be removed IMHO. Might be a bit to late for FE5, but I still think we have enough time (BTW, why are they still there? We agreed in one of the past FESCo meeting that they should be removed *before* the mass rebuild) There are some other sections like - "Packages that have not yet completed review", - "Potential problems: 'We have X accepted, closed packages where I'm unable to find the package in the development repo' and 'We have 8 accepted, closed packages where I'm unable to find the package in the owners file'" - "Some cleanup needed" - ...and maybe some other sections, too Those should be trivial to fix for the owners. They just needed to be poked by someone -- in an ideal world the script would do that directly. Christian, would that be possible? CU thl -- Thorsten Leemhuis From pertusus at free.fr Sat Feb 18 12:01:34 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 18 Feb 2006 13:01:34 +0100 Subject: Please help comment on hdf/netcdf compatability In-Reply-To: <43E3C33D.3030403@cora.nwra.com> References: <43E3C33D.3030403@cora.nwra.com> Message-ID: <20060218120134.GF2977@free.fr> > I also maintain gdl, which can be linked against both hdf and netcdf, > but I get complaints. I don't know if gdl can use the netcdf API in the > hdf library or not - looking into it (if you know, tell me!). I have read the code (now that I understand a bit more those issues), and it seems to me that - for netcdf gdl uses the netcdf 3 api exclusively. - for hdf, gdl uses the SD* api, and not the netcdf-2 api. So, as long as static libs are used it seems possible to mix hdf library containing the netcdf 2 api and netcdf libray also containing the netcdf 2 api, as gdl don't use any of those api. I have tested, ld gives warnings about symbols that changed size, but none of those symbols are used. I have only tested on i386 maybe it breaks on other platform. Once shared libs are used, it is likely that using the sd_ interface will be required for gdl. So I believe keeping -DHAVE_NETCDF is the right thing to do. > Those of you who use both, what would you like to see? grads uses the netcdf API of hdf, so I could not rebuild it anymore. However I think that grads should be able to detect that it should use the sd_ variant (that is hdf compiled with -DHAVE_NETCDF). I have allready contacted the upstream about that. I also have fixed grads to use both hdf versions. So it is fine with me. Maybe the best solution would be to have 2 libraries coming with hdf, one that defines sd_ symbols, which could be the allready existing mfhdf lib, and another that only defines the netcdf 2 api symbols. Some C preprocessing could be used to generate 2 object files from the same source, and the library that only defines the netcdf 2 api could be named otherwise, for example dfnetcdf. And the headers should be rearranged accordingly. note1: unrelated, but if you contact the gdl upstream, tests for missing numarray/numarray.h (from python-numarray) are not in configure, so it fails during make). note2: I made autoconf macros for hdf and netcdf detection, I personally think that they are better than the one in gdl, as they search in more places, and try to find the right version for the netcdf api. But they are much more complicated and would require a change in the configure.in, so... (I think i allready did my advertising, but I don't abandon so easily now that I know that these macros could really be usefull for gdl...). -- Pat -------------- next part -------------- dnl AC_CHECK_HDF : Check for hdf4 dnl args : action-if-yes, action-if-no AC_DEFUN([AC_CHECK_HDF4], [ AC_ARG_WITH([hdf4], [AS_HELP_STRING([--with-hdf4=ARG],[hdf4 directory])], [HDF4_PATH=$withval], [HDF4_PATH=""]) AC_ARG_WITH([hdf4_include], [AS_HELP_STRING([--with-hdf4-include=ARG],[hdf 4 include directory])], [HDF4_PATH_INC=$withval], [HDF4_PATH_INC=""]) AC_ARG_WITH([hdf4_libdir], [AS_HELP_STRING([--with-hdf4-libdir=ARG],[hdf 4 library directory])], [HDF4_PATH_LIBDIR=$withval], [HDF4_PATH_LIBDIR=""]) dnl This is a very common location for the hdf4 code. jhrg 10/11/05 dnl AS_IF([test -d /usr/local/hdf], [HDF4_PATH="/usr/local/hdf"]) AS_IF([test "z$HDF4_PATH" != "z"], [ AS_IF([test "z$HDF4_PATH_LIBDIR" = "z"], [HDF4_PATH_LIBDIR="$HDF4_PATH/lib"]) AS_IF([test "z$HDF4_PATH_INC" = "z"], [HDF4_PATH_INC="$HDF4_PATH/include"]) ]) ac_hdf4_lib_ok='no' ac_hdf4_save_LDFLAGS=$LDFLAGS HDF4_LIBS= AS_IF([test "z$HDF4_PATH_LIBDIR" != "z"], [ HDF4_LDFLAGS="-L$HDF4_PATH_LIBDIR" LDFLAGS="$LDFLAGS $HDF4_LDFLAGS" AC_CHECK_HDF4_LIB([ac_hdf4_lib_ok='yes']) ], [ for ac_hdf4_libdir in "" /usr/local/hdf4.2r1/lib /opt/hdf4.2r1/lib \ /usr/hdf4.2r1/lib /usr/local/lib/hdf4.2r1 /opt/lib/hdf4.2r1 \ /usr/lib/hdf4.2r1 /usr/local/hdf/lib/ /opt/hdf/lib /usr/hdf/lib \ /usr/local/lib/hdf /opt/lib/hdf /usr/lib/hdf ; do AS_IF([test "z$ac_hdf4_libdir" = 'z'], [HDF4_LDFLAGS=], [ AC_MSG_NOTICE([searching hdf libraries in $ac_hdf4_libdir]) HDF4_LDFLAGS="-L$ac_hdf4_libdir" ]) LDFLAGS="$LDFLAGS $HDF4_LDFLAGS" AC_CHECK_HDF4_LIB([ac_hdf4_lib_ok='yes']) AS_IF([test $ac_hdf4_lib_ok = 'yes'],[break]) LDFLAGS=$ac_hdf4_save_LDFLAGS done ]) LDFLAGS=$ac_hdf4_save_LDFLAGS ac_hdf4_h='no' HDF4_CPPFLAGS= ac_hdf4_save_CPPFLAGS=$CPPFLAGS AS_IF([test "z$HDF4_PATH_INC" != "z"], [ HDF4_CPPFLAGS="-I$HDF4_PATH_INC" CPPFLAGS="$CPPFLAGS $HDF4_CPPFLAGS" AC_CHECK_HEADER_NOCACHE_HDF4([mfhdf.h],[ac_hdf4_h='yes']) ], [ for ac_hdf4_incdir in "" /usr/local/hdf4.2r1/include /opt/hdf4.2r1/include \ /usr/hdf4.2r1/include /usr/local/include/hdf4.2r1 \ /opt/include/hdf4.2r1 /usr/include/hdf4.2r1 /usr/local/hdf/include \ /opt/hdf/include /usr/hdf/include /usr/local/include/hdf \ /opt/include/hdf /usr/include/hdf ; do AS_IF([test "z$ac_hdf4_incdir" = 'z'], [HDF4_CPPFLAGS=], [ AC_MSG_NOTICE([searching hdf includes in $ac_hdf4_incdir]) HDF4_CPPFLAGS="-I$ac_hdf4_incdir" ]) CPPFLAGS="$CPPFLAGS $HDF4_CPPFLAGS" AC_CHECK_HEADER_NOCACHE_HDF4([mfhdf.h],[ac_hdf4_h='yes']) AS_IF([test $ac_hdf4_h = 'yes'],[break]) CPPFLAGS=$ac_hdf4_save_CPPFLAGS done ]) CPPFLAGS=$ac_hdf4_save_CPPFLAGS AS_IF([test "$ac_hdf4_h" = 'yes' -a "$ac_hdf4_lib_ok" = 'yes'], [m4_if([$1], [], [:], [$1])], [m4_if([$2], [], [:], [$2])]) AC_SUBST([HDF4_LIBS]) AC_SUBST([HDF4_CPPFLAGS]) AC_SUBST([HDF4_LDFLAGS]) ]) dnl check for the netcdf 2 interface provided by hdf dnl it defines the C preprocessor macro HDF_NETCDF_NAME(name) which dnl prepends sd_ to name if needed and otherwise keep the name dnl as is. dnl dnl args action-if-found, dnl action-if-found with sd_ appended to netcdf symbols, dnl action-if-no-found dnl dnl in case it is detected that sd_ should be appended, the C preprocessor dnl symbol HDF_SD_NETCDF is defined. AC_DEFUN([AC_CHECK_HDF4_NETCDF], [ ac_hdf4_netcdf_lib='no' ac_hdf4_sd_netcdf_lib='no' ac_hdf4_netcdf_h='no' AC_CHECK_HDF4([ ac_hdf4_netcdf_save_LDFLAGS=$LDFLAGS ac_hdf4_netcdf_save_LIBS=$LIBS LIBS="$LIBS $HDF4_LIBS" LDFLAGS="$LDFLAGS $HDF4_LDFLAGS" AC_MSG_CHECKING([for sd_ncopen]) AC_LINK_IFELSE([AC_LANG_CALL([],[sd_ncopen])], [ AC_MSG_RESULT([yes]) ac_hdf4_sd_netcdf_lib='yes' ], [ AC_MSG_RESULT([no]) ac_hdf4_sd_netcdf_lib='no' ]) AS_IF([test "$ac_hdf4_sd_netcdf_lib" = 'no'], [ AC_MSG_CHECKING([for ncopen with hdf link flags]) AC_LINK_IFELSE([AC_LANG_CALL([],[ncopen])], [ AC_MSG_RESULT([yes]) ac_hdf4_netcdf_lib='yes' ], [ AC_MSG_RESULT([no]) ac_hdf4_netcdf_lib='no' ]) ]) LDFLAGS=$ac_hdf4_netcdf_save_LDFLAGS LIBS=$ac_hdf4_netcdf_save_LIBS ac_hdf4_netcdf_save_CPPFLAGS=$CPPFLAGS CPPFLAGS="$CPPFLAGS $HDF4_CPPFLAGS" AC_CHECK_NETCDF_HEADER([],[ac_hdf4_netcdf_h='yes']) CPPFLAGS=$ac_hdf4_netcdf_save_CPPFLAGS ]) AH_TEMPLATE([HDF_NETCDF_NAME],[A macro that append sd_ to netcdf symbols if needed]) AS_IF([test $ac_hdf4_netcdf_h = 'yes' -a $ac_hdf4_sd_netcdf_lib = 'yes'], [ AC_DEFINE([HDF_SD_NETCDF],[],[Define if hdf prefixes netcdf symbols by sd]) AC_DEFINE([HDF_NETCDF_NAME(name)], [sd_ ## name]) m4_if([$2], [], [:], [$2]) ], [ AC_DEFINE([HDF_NETCDF_NAME(name)], [name]) AS_IF([test $ac_hdf4_netcdf_h = 'yes' -a $ac_hdf4_netcdf_lib = 'yes'], [m4_if([$1], [], [:], [$1])], [m4_if([$3], [], [:], [$3])]) ]) ]) AC_DEFUN([AC_CHECK_HDF4_LIB], [ HDF4_LIBS= ac_hdf4_save_LIBS=$LIBS AC_CHECK_LIB_NOCACHE_HDF4([sz], [SZ_BufftoBuffCompress], [ LIBS="$LIBS -lsz" HDF4_LIBS='-lsz' ]) dnl -lsz is not required because due to licencing it may not be present dnl nor required everywhere ac_hdf4_lib='no' AC_CHECK_LIB_NOCACHE_HDF4([z],[deflate], [ AC_CHECK_LIB_NOCACHE_HDF4([jpeg],[jpeg_start_compress], [ AC_CHECK_LIB_NOCACHE_HDF4([df],[Hopen], [ AC_CHECK_LIB_NOCACHE_HDF4([mfhdf],[SDstart], [ ac_hdf4_lib="yes" HDF4_LIBS="-lmfhdf -ldf -ljpeg -lz $HDF4_LIBS" ],[],[-ldf -ljpeg -lz]) ],[],[-ljpeg -lz]) ]) ]) LIBS=$ac_hdf4_save_LIBS AS_IF([test "$ac_hdf4_lib" = 'yes'], [m4_if([$1], [], [:], [$1])], [m4_if([$2], [], [:], [$2])]) ]) AC_DEFUN([AC_CHECK_LIB_NOCACHE_HDF4], [ AS_TR_SH([ac_check_lib_nocache_ok_$1_$2])='no' AS_TR_SH([ac_check_lib_nocache_$1_$2_LIBS])=$LIBS LIBS="-l$1 $5 $LIBS" AC_MSG_CHECKING([for $2 in -l$1]) AC_LINK_IFELSE([AC_LANG_CALL([], [$2])], [ AS_TR_SH([ac_check_lib_nocache_ok_$1_$2])='yes' AC_MSG_RESULT([yes]) ],[ AC_MSG_RESULT([no]) ]) LIBS=$AS_TR_SH([ac_check_lib_nocache_$1_$2_LIBS]) AS_IF([test $AS_TR_SH([ac_check_lib_nocache_ok_$1_$2]) = 'yes'], [m4_if([$3], [], [:], [$3])], [m4_if([$4], [], [:], [$4])]) ]) AC_DEFUN([AC_CHECK_HEADER_NOCACHE_HDF4], [ AS_TR_SH([ac_check_header_nocache_compile_$1])='no' AS_TR_SH([ac_check_header_nocache_preproc_$1])='no' AC_MSG_CHECKING([for $1 with compiler]) AC_COMPILE_IFELSE([AC_LANG_SOURCE([[#include <$1>]])], [ AC_MSG_RESULT([yes]) AS_TR_SH([ac_check_header_nocache_compile_$1])='yes' ], [ AC_MSG_RESULT([no]) ]) AC_MSG_CHECKING([for $1 with preprocessor]) AC_PREPROC_IFELSE([AC_LANG_SOURCE([[#include <$1>]])], [ AC_MSG_RESULT([yes]) AS_TR_SH([ac_check_header_nocache_preproc_$1])='yes' ], [ AC_MSG_RESULT([no]) AS_IF([test "$AS_TR_SH([ac_check_header_nocache_compile_$1])" = 'yes'], [AC_MSG_WARN([trusting compiler result, ignoring preprocessor error])]) ]) AS_IF([test "$AS_TR_SH([ac_check_header_nocache_compile_$1])" = 'yes'], [m4_if([$2], [], [:], [$2])], [m4_if([$3], [], [:], [$3])]) ]) -------------- next part -------------- # Check for the netcdf header. # AC_CHECK_NETCDF_HEADER([INCLUDE-DIR],[ACTION-IF-FOUND], # [ACTION-IF-NOT-FOUND],[INTERFACE-NR]) # if interface number is given, check for a specific interface # sets NC_CPPFLAGS and maybe NC_NETCDF_3_CPPFLAG AC_DEFUN([AC_CHECK_NETCDF_HEADER], [ NC_CPPFLAGS= ac_netcdf_h='no' ac_netcdf_h_compile='no' ac_netcdf_h_preproc='no' ac_nc_include_dir= ac_nc_header_interface= ac_nc_save_CPPFLAGS=$CPPFLAGS m4_if([$1],[],[:],[ ac_nc_include_dir="$1" AS_IF([test "z$ac_nc_include_dir" != "z"], [CPPFLAGS="$CPPFLAGS -I$ac_nc_include_dir"]) ]) m4_if([$4],[],[:],[ac_nc_header_interface=$4]) dnl dont use AC_CHECK_HEADERS to avoid autoconf internal caching AC_MSG_CHECKING([for netcdf.h with compiler]) AC_COMPILE_IFELSE([AC_LANG_SOURCE([[#include ]])], [ AC_MSG_RESULT([yes]) ac_netcdf_h_compile='yes' ], [ AC_MSG_RESULT([no]) ac_netcdf_h_compile='no' ]) AC_MSG_CHECKING([for netcdf.h with preprocessor]) AC_PREPROC_IFELSE([AC_LANG_SOURCE([[#include ]])], [ AC_MSG_RESULT([yes]) ac_netcdf_h_preproc='yes' ], [ AC_MSG_RESULT([no]) ac_netcdf_h_preproc='no' ]) CPPFLAGS="$ac_nc_save_CPPFLAGS" AS_IF([test $ac_netcdf_h_compile = 'yes'], [ac_netcdf_h='yes' AS_IF([test "z$ac_nc_header_interface" = 'z3'], [AC_CHECK_NETCDF_3_HEADER([$1], [ac_netcdf_h='yes'],[ac_netcdf_h='no'])]) ]) AS_IF([test "$ac_netcdf_h" = 'yes'], [ AS_IF([test "z$ac_nc_include_dir" != "z"], [NC_CPPFLAGS="-I$ac_nc_include_dir"]) m4_if([$2], [], [:], [$2]) ], [m4_if([$3], [], [:], [$3])]) AC_SUBST([NC_CPPFLAGS]) ]) AC_DEFUN([AC_CHECK_NETCDF_3_HEADER], [ NC_NETCDF_3_CPPFLAG= ac_check_netcdf_3_include= ac_check_netcdf_3_header='no' ac_nc_save_CPPFLAGS=$CPPFLAGS AC_MSG_CHECKING([for netcdf 3 interface]) m4_if([$1],[],[:],[ ac_check_netcdf_3_include="$1" ]) AS_IF([test "z$ac_check_netcdf_3_include" != "z"], [CPPFLAGS="$CPPFLAGS -I$ac_check_netcdf_3_include"]) AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include ]], [[int status; int ncid; status = nc_open("foo.nc", 0, &ncid); char vernum; vernum = *nc_inq_libvers();]])], [ AS_IF([test "z$ac_check_netcdf_3_include" != "z"], [NC_NETCDF_3_CPPFLAG="-I$ac_check_netcdf_3_include"]) ac_check_netcdf_3_header='yes' ],[ac_check_netcdf_3_header='no']) CPPFLAGS=$ac_nc_save_CPPFLAGS AS_IF([test "$ac_check_netcdf_3_header" = 'yes'], [ AC_MSG_RESULT([yes]) m4_if([$2], [], [:], [$2]) ], [ AC_MSG_RESULT([no]) m4_if([$3], [], [:], [$3]) ]) AC_SUBST([NC_NETCDF_3_CPPFLAG]) ]) -------------- next part -------------- dnl example of use dnl AC_CHECK_NETCDF( dnl [ dnl LIBS="$LIBS $NC_LIBS" dnl LDFLAGS="$LDFLAGS $NC_LDFLAGS" dnl CPPFLAGS="$CPPFLAGS $NC_CPPFLAGS" dnl ], dnl [ dnl echo "*** Use --with-netcdf for the root netcdf directory." dnl echo "*** Otherwise use --with-netcdf-include switch for includes directory" dnl echo "*** and --with-netcdf-libdir switch for libraries directory." dnl AC_MSG_ERROR([netcdf library and netcdf headers are required.]) dnl ] dnl ) # Check for the netcdf library. # AC_CHECK_NETCDF([ACTION-IF-FOUND],[ACTION-IF-NOT-FOUND],[INTERFACE-NR]) # if interface number is given, check for a specific interface # sets NC_LDFLAGS, NC_LIBS, and, by calling other macros # NC_CPPFLAGS and maybe NC_NETCDF_3_CPPFLAG AC_DEFUN([AC_CHECK_NETCDF], [ AC_ARG_WITH([netcdf], [AS_HELP_STRING([--with-netcdf=ARG],[netcdf directory])], [NC_PATH=$withval], [NC_PATH=""]) AC_ARG_WITH([netcdf_include], [AS_HELP_STRING([--with-netcdf-include=ARG],[netcdf include directory])], [NC_PATH_INC=$withval], [NC_PATH_INC=""]) AC_ARG_WITH([netcdf_libdir], [AS_HELP_STRING([--with-netcdf-libdir=ARG],[netcdf library directory])], [NC_PATH_LIBDIR=$withval], [NC_PATH_LIBDIR=""]) AS_IF([test "z$NC_PATH" != "z"], [ AS_IF([test "z$NC_PATH_LIBDIR" = "z"],[NC_PATH_LIBDIR="$NC_PATH/lib"]) AS_IF([test "z$NC_PATH_INC" = "z"],[NC_PATH_INC="$NC_PATH/include"]) ]) ac_netcdf_ok='no' NC_LIBS= NC_LDFLAGS= ac_nc_save_LDFLAGS=$LDFLAGS ac_nc_save_LIBS=$LIBS ac_check_nc_func_checked='ncopen' ac_check_nc_interface= dnl the interface number isn't quoted with "" otherwise a newline dnl following the number isn't stripped. m4_if([$3],[],[ac_check_nc_interface=2],[ac_check_nc_interface=$3]) AS_IF([test "z$ac_check_nc_interface" = 'z3'], [ac_check_nc_func_checked='nc_open']) AS_IF([test "z$NC_PATH_LIBDIR" != "z"], [ NC_LDFLAGS="-L$NC_PATH_LIBDIR" LDFLAGS="$LDFLAGS $NC_LDFLAGS" dnl the autoconf internal cache isn't avoided because we really check for dnl libnetcdf, other libraries that implement the same api have other names dnl AC_LINK_IFELSE([AC_LANG_CALL([],[$ac_check_func_checked])], AC_CHECK_LIB([netcdf],[$ac_check_nc_func_checked], [ NC_LIBS='-lnetcdf' ac_netcdf_ok='yes' ]) ], [ for ac_netcdf_libdir in "" \ /usr/local/netcdf-${ac_check_nc_interface}/lib \ /opt/netcdf-${ac_check_nc_interface}/lib \ /usr/netcdf-${ac_check_nc_interface}/lib \ /usr/local/lib/netcdf-${ac_check_nc_interface} \ /opt/lib/netcdf-${ac_check_nc_interface} \ /usr/lib/netcdf-${ac_check_nc_interface} \ /usr/local/netcdf/lib /opt/netcdf/lib \ /usr/netcdf/lib /usr/local/lib/netcdf /opt/lib/netcdf \ /usr/lib/netcdf ; do AS_IF([test "z$ac_netcdf_libdir" = 'z'], [NC_LDFLAGS=], [ AC_MSG_CHECKING([for netcdf libraries in $ac_netcdf_libdir]) NC_LDFLAGS="-L$ac_netcdf_libdir" ]) LDFLAGS="$LDFLAGS $NC_LDFLAGS" LIBS="$LIBS -lnetcdf" dnl we have to avoid the autoconf internal cache in that case AC_LINK_IFELSE([AC_LANG_CALL([],[$ac_check_nc_func_checked])], [ NC_LIBS='-lnetcdf' ac_netcdf_ok='yes' AS_IF([test "z$ac_netcdf_libdir" != 'z'],[AC_MSG_RESULT([yes])]) ], [ AS_IF([test "z$ac_netcdf_libdir" != 'z'],[AC_MSG_RESULT([no])]) ]) AS_IF([test $ac_netcdf_ok = 'yes'],[break]) LDFLAGS=$ac_nc_save_LDFLAGS LIBS=$ac_nc_save_LIBS done ]) LDFLAGS=$ac_nc_save_LDFLAGS LIBS=$ac_nc_save_LIBS AC_SUBST([NC_LDFLAGS]) AC_SUBST([NC_LIBS]) ac_netcdf_header='no' AS_IF([test "z$NC_PATH_INC" != "z"], [ AC_CHECK_NETCDF_HEADER([$NC_PATH_INC], [ac_netcdf_header='yes'], [ac_netcdf_header='no'], [$ac_check_nc_interface]) ], [ for ac_netcdf_incdir in "" \ /usr/local/netcdf-${ac_check_nc_interface}/include \ /opt/netcdf-${ac_check_nc_interface}/include \ /usr/netcdf-${ac_check_nc_interface}/include \ /usr/local/include/netcdf-${ac_check_nc_interface} \ /opt/include/netcdf-${ac_check_nc_interface} \ /usr/include/netcdf-${ac_check_nc_interface} \ /usr/local/netcdf/include \ /opt/netcdf/include /usr/netcdf/include /usr/local/include/netcdf \ /opt/include/netcdf /usr/include/netcdf ; do AC_MSG_NOTICE([searching netcdf includes in $ac_netcdf_incdir]) AC_CHECK_NETCDF_HEADER([$ac_netcdf_incdir],[ac_netcdf_header='yes'], [ac_netcdf_header='no'],[$ac_check_nc_interface]) AS_IF([test $ac_netcdf_header = 'yes'],[break]) done ]) AS_IF([test "$ac_netcdf_ok" = 'no' -o "$ac_netcdf_header" = 'no'], [m4_if([$2], [], [:], [$2])], [m4_if([$1], [], [:], [$1])]) ]) From fedora at leemhuis.info Sat Feb 18 12:14:47 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Feb 2006 13:14:47 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <43F70482.3070500@lowlatency.de> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <43F70482.3070500@lowlatency.de> Message-ID: <1140264888.2904.131.camel@localhost.localdomain> Am Samstag, den 18.02.2006, 12:26 +0100 schrieb Andreas Bierfert: > Thorsten Leemhuis wrote: > > andreas.bierfert at lowlatency.de lcms > Moved to core... I added it to http://www.fedoraproject.org/wiki/Extras/FC5Status so it gets removed. >[...] >These two don't build with gcc4.1. The issue has been reported upstream >and I hope fixes are on their way... >[...] > Waiting for synce... >[...] > Does not like stack protector again... need to do some work there >[...] > Should be underway soon... =) thx for the explanations. We probably need a way to track those issues when the release of of FC5 get closer. Guys, what would you prefer? bugzilla or wiki-based? I suspect that some people would prefer bugzilla, but on the other hand the wiki solution is easier to handle. How about this: Use the wiki for now until "date of FC5 release minus one week"? After that bugzilla? CU thl -- Thorsten Leemhuis From fedora at leemhuis.info Sat Feb 18 12:18:59 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Feb 2006 13:18:59 +0100 Subject: Packages in CVS with no entry in the owners.list (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1140262149.2904.90.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140262149.2904.90.camel@localhost.localdomain> Message-ID: <1140265140.2904.135.camel@localhost.localdomain> Uhgh, sending this mail again without everyone in the CC -- mailman didn't like that. Those that were in the CC should have received the mail nevertheless. Am Samstag, den 18.02.2006, 12:29 +0100 schrieb Thorsten Leemhuis: > Note: If your E-Mail address is in the CC of this mail please read it! > > Am Freitag, den 17.02.2006, 20:51 +0100 schrieb Thorsten Leemhuis: > > Am Montag, den 13.02.2006, 18:22 +0100 schrieb Thorsten Leemhuis: > [...] > > The script found the following packages in extras/development for which > > no entry in the owners.list could be found: fftw3, umfpack, > > perl-Gtk2-GladeXML, perl-Imager, perl-Gnome2-Canvas, html-xml-utils, > > dia, libdsk, libspectrum, lib765 > > I looked a bit closer at this list and that one maintained from > Christian and his scripts in the wiki at > http://fedoraproject.org/wiki/Extras/PackageStatus#head-7ad8ccfb3d8a18c22476e20d7ddaab55b4b9cfe1 > > Find below a list of people that seemed to be interested in these > packages in the past. I've CCed all them. So if you are CCed to this > mail and (still) want to maintain the package(s) please add the required > details to the owners.list -- see > http://fedoraproject.org/wiki/Extras/Contributors#head-f6f080b4c48fe519c98a29364a740953f90179e7 > for details. > > If I don't hear anything until Wednesday, Feb. 22 I'll assume that they > are orphaned. I will add them to the orphaned page in the wiki and add a > corresponding entry to the owners.list so others can take the packages > over. > > These are in the extras/devel but have no entry in owners.list > > - Caolan McNamara : dia > - Gavin Henry : perl-Gtk2-GladeXML, > perl-Imager, perl-Gnome2-Canvas, html-xml-utils > - Matt Domsch : gpp > - Paul F. Johnson : libdsk, lib765, > libspectrum > - Quentin Spencer : umfpack > > > These are only in cvs and have no entry in owners.list > > - Jeffrey C. Ollie : libresample > - Rex Dieter : kile-i18n > - Tom "spot" Callaway : perl-Maypole > - Paul F. Johnson : z88dk > - Good Question: wxPython (Matt Miller, maybe could you take care off > this?) > > These packages should be removed from the extras/devel (I added them to > http://www.fedoraproject.org/wiki/Extras/FC5Status ): > > - fftw3 -- It is no longer needed as fftw is now upgraded to version > 3.x, and a fftw2 package has been created for the old API. (I found this > text in http://fedoraproject.org/wiki/Extras/CVSSyncNeeded ) > > > CU > thl -- Thorsten Leemhuis From jamatos at fc.up.pt Sat Feb 18 12:24:36 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Sat, 18 Feb 2006 12:24:36 +0000 Subject: Packages in CVS with no entry in the owners.list (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1140265140.2904.135.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140262149.2904.90.camel@localhost.localdomain> <1140265140.2904.135.camel@localhost.localdomain> Message-ID: <200602181224.37131.jamatos@fc.up.pt> On Saturday 18 February 2006 12:18, Thorsten Leemhuis wrote: > > These packages should be removed from the extras/devel (I added them to > > http://www.fedoraproject.org/wiki/Extras/FC5Status ): Not only devel but FC-4 as well, we have created fftw2 for FC-4 and devel, so fftw3 is completly useless now. AFAIR, fftw was in Core for FC-3 and previous. > > - fftw3 -- It is no longer needed as fftw is now upgraded to version > > 3.x, and a fftw2 package has been created for the old API. (I found this > > text in http://fedoraproject.org/wiki/Extras/CVSSyncNeeded ) -- Jos? Ab?lio From j.w.r.degoede at hhs.nl Sat Feb 18 12:43:35 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 18 Feb 2006 13:43:35 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1140251657.2904.24.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <43F632B9.40904@hhs.nl> <1140251657.2904.24.camel@localhost.localdomain> Message-ID: <43F71677.2080506@hhs.nl> Thorsten Leemhuis wrote: > Hello Hans, Zoltan, everybody else. > > Am Freitag, den 17.02.2006, 22:32 +0100 schrieb Zoltan Kota: >> On Fri, 17 Feb 2006, Hans de Goede wrote: >>> It seems to check the wrong time/date though, its listing a few of my >>> packages which have all been rebuild, take Glide3 as an example from the >>> changelog: >>> * Mon Feb 13 2006 Hans de Goede 20050815-3 >>> - Bump release and rebuild for new gcc4.1 and glibc. >>> - add %%{?dist} for consistency with my other packages >> Same for me (Feb 13). Packages: recode, python-bibtex, pybliographer. > > Well, I had to define a point in time *somewhere*. I took the obvious > one: The time when I announced the mass rebuild. The exact one. I know > that the rawhide push with the results from the mass rebuild was done > some hours earlier, but it also takes some time until it hits the > buildsys afaik. Yes, that was Feb 13, but to be precise it was: > $ date --date='2006-02-13 18:22:00 CET' +%s > 1139851320 > The obvious time would be 13 feb 00:00 UTC, quoting yourself from: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060209 "Packages not rebuild before the 12th of February will be removed before FC5 is shipped to start with a clean tree with old cruft removed" This is what I took as "start the rebuild on or after the 12th" since there was an extra core rebuild I waited for this to complete, I started my rebuilds after receiving the last rawhide changes mail for the core rebuild. I don't know what the time is between the rawhide changes mail and the buildsys picking up said changes though. Regards, Hans From fedora at leemhuis.info Sat Feb 18 12:46:14 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Feb 2006 13:46:14 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <43F71677.2080506@hhs.nl> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <43F632B9.40904@hhs.nl> <1140251657.2904.24.camel@localhost.localdomain> <43F71677.2080506@hhs.nl> Message-ID: <1140266775.2904.149.camel@localhost.localdomain> Am Samstag, den 18.02.2006, 13:43 +0100 schrieb Hans de Goede: > Thorsten Leemhuis wrote: > > Hello Hans, Zoltan, everybody else. > > Am Freitag, den 17.02.2006, 22:32 +0100 schrieb Zoltan Kota: > >> On Fri, 17 Feb 2006, Hans de Goede wrote: > >>> It seems to check the wrong time/date though, its listing a few of my > >>> packages which have all been rebuild, take Glide3 as an example from the > >>> changelog: > >>> * Mon Feb 13 2006 Hans de Goede 20050815-3 > >>> - Bump release and rebuild for new gcc4.1 and glibc. > >>> - add %%{?dist} for consistency with my other packages > >> Same for me (Feb 13). Packages: recode, python-bibtex, pybliographer. > > Well, I had to define a point in time *somewhere*. I took the obvious > > one: The time when I announced the mass rebuild. The exact one. I know > > that the rawhide push with the results from the mass rebuild was done > > some hours earlier, but it also takes some time until it hits the > > buildsys afaik. Yes, that was Feb 13, but to be precise it was: > > $ date --date='2006-02-13 18:22:00 CET' +%s > > 1139851320 > > The obvious time would be 13 feb 00:00 UTC, quoting yourself from: > http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060209 > > "Packages not rebuild before the 12th of February will be removed before > FC5 is shipped to start with a clean tree with old cruft removed" Quoting that page, too: Mass rebuild of Extras for FC5 A separate mail will follow. This is the rough version: Can probably start on Sunday.[...] Note the words "separate mail will follow" and "probably". Because some hours later this came: https://www.redhat.com/archives/fedora-maintainers/2006-February/msg00031.html > A late breaking bug was found that affects ppc32/64 systems, and so I > have to rebuild every package that is built on these arches over the > weekend. Please wait on rebuilding Extras until this is done. And I waited until f13 gave his okay to start. CU thl -- Thorsten Leemhuis From fedora at leemhuis.info Sat Feb 18 12:32:47 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Feb 2006 13:32:47 +0100 Subject: Packages in CVS with no entry in the owners.list (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <200602181224.37131.jamatos@fc.up.pt> References: <1139851362.2904.79.camel@localhost.localdomain> <1140262149.2904.90.camel@localhost.localdomain> <1140265140.2904.135.camel@localhost.localdomain> <200602181224.37131.jamatos@fc.up.pt> Message-ID: <1140265967.2904.142.camel@localhost.localdomain> Am Samstag, den 18.02.2006, 12:24 +0000 schrieb Jose' Matos: > On Saturday 18 February 2006 12:18, Thorsten Leemhuis wrote: > > > These packages should be removed from the extras/devel (I added them to > > > http://www.fedoraproject.org/wiki/Extras/FC5Status ): > > Not only devel but FC-4 as well, we have created fftw2 for FC-4 and devel, > so fftw3 is completly useless now. I added it to http://www.fedoraproject.org/wiki/Extras/FC5Status at the same time, but did not specify that in the mail. Sorry. CU thl -- Thorsten Leemhuis From bugzilla at redhat.com Sat Feb 18 13:21:00 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 08:21:00 -0500 Subject: [Bug 180068] Review Request: geoip - Library for mapping IP/hostname to a country/city/organization In-Reply-To: Message-ID: <200602181321.k1IDL0Z0021094@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: geoip - Library for mapping IP/hostname to a country/city/organization https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180068 ------- Additional Comments From Nicolas.Mailhot at laPoste.net 2006-02-18 08:20 EST ------- I seem to remember spamassassin could use something like the perl GeoIP bindings -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From j.w.r.degoede at hhs.nl Sat Feb 18 13:26:21 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 18 Feb 2006 14:26:21 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1140266775.2904.149.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <43F632B9.40904@hhs.nl> <1140251657.2904.24.camel@localhost.localdomain> <43F71677.2080506@hhs.nl> <1140266775.2904.149.camel@localhost.localdomain> Message-ID: <43F7207D.3080605@hhs.nl> Thorsten Leemhuis wrote: > Am Samstag, den 18.02.2006, 13:43 +0100 schrieb Hans de Goede: >> Thorsten Leemhuis wrote: >>> Hello Hans, Zoltan, everybody else. >>> Am Freitag, den 17.02.2006, 22:32 +0100 schrieb Zoltan Kota: >>>> On Fri, 17 Feb 2006, Hans de Goede wrote: >>>>> It seems to check the wrong time/date though, its listing a few of my >>>>> packages which have all been rebuild, take Glide3 as an example from the >>>>> changelog: >>>>> * Mon Feb 13 2006 Hans de Goede 20050815-3 >>>>> - Bump release and rebuild for new gcc4.1 and glibc. >>>>> - add %%{?dist} for consistency with my other packages >>>> Same for me (Feb 13). Packages: recode, python-bibtex, pybliographer. >>> Well, I had to define a point in time *somewhere*. I took the obvious >>> one: The time when I announced the mass rebuild. The exact one. I know >>> that the rawhide push with the results from the mass rebuild was done >>> some hours earlier, but it also takes some time until it hits the >>> buildsys afaik. Yes, that was Feb 13, but to be precise it was: >>> $ date --date='2006-02-13 18:22:00 CET' +%s >>> 1139851320 >> The obvious time would be 13 feb 00:00 UTC, quoting yourself from: >> http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060209 >> >> "Packages not rebuild before the 12th of February will be removed before >> FC5 is shipped to start with a clean tree with old cruft removed" > > Quoting that page, too: > > Mass rebuild of Extras for FC5 > A separate mail will follow. This is the rough version: Can probably > start on Sunday.[...] > > Note the words "separate mail will follow" and "probably". Because some > hours later this came: > https://www.redhat.com/archives/fedora-maintainers/2006-February/msg00031.html > >> A late breaking bug was found that affects ppc32/64 systems, and so I >> have to rebuild every package that is built on these arches over the >> weekend. Please wait on rebuilding Extras until this is done. > > And I waited until f13 gave his okay to start. > As I already wrote in the part of my mail you didn't quote I delayed my rebuilds because of the extra rebuild, once this was done I started it. Appereantly the discussion is when the extra rebuild was complete, in my view this was done when the last rawhide changelog mail was send. + maybe some time for the buildsys to pick up the changes I don't know how/when the buildsys syncs to rawhide. Regards, Hans From buildsys at fedoraproject.org Sat Feb 18 13:35:20 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 18 Feb 2006 08:35:20 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060218133520.F37448011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 4 Glide3-libGL-6.2.1-5.fc4 conglomerate-0.9.1-1.fc4 rpmlint-0.75-1.fc4 rpy-0.4.6-7.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat Feb 18 13:35:57 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 18 Feb 2006 08:35:57 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060218133557.8EC868011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 20 ccache-2.4-4.fc5 cfs-1.4.1-7.fc5 clamav-0.88-2.fc5 conglomerate-0.9.1-1.fc5 fdupes-1.40-6.fc5 fedora-usermgmt-0.8-2.fc5 fftw2-2.1.5-12.fc5 gcfilms-6.0-4.fc5 gif2png-2.5.1-2.fc5 gnomesword-2.1.5-2.fc5 hunt-1.5-5.fc5 id3lib-3.8.3-13.fc5 mantis-1.0.0-1.fc5 milter-greylist-2.0.2-3.fc5 mimetic-0.8.9-4.fc5 opencdk-0.5.8-1.fc5 pcsc-tools-1.4.1-2.fc5 rpy-0.4.6-7.fc5 xca-0.5.1-5.fc5 xmlrpc-c-1.04-2.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From fedora at leemhuis.info Sat Feb 18 14:05:03 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Feb 2006 15:05:03 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <43F7207D.3080605@hhs.nl> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <43F632B9.40904@hhs.nl> <1140251657.2904.24.camel@localhost.localdomain> <43F71677.2080506@hhs.nl> <1140266775.2904.149.camel@localhost.localdomain> <43F7207D.3080605@hhs.nl> Message-ID: <1140271503.2904.173.camel@localhost.localdomain> Am Samstag, den 18.02.2006, 14:26 +0100 schrieb Hans de Goede: > > Thorsten Leemhuis wrote: > > Am Samstag, den 18.02.2006, 13:43 +0100 schrieb Hans de Goede: > >> Thorsten Leemhuis wrote: > >>> Hello Hans, Zoltan, everybody else. > >>> Am Freitag, den 17.02.2006, 22:32 +0100 schrieb Zoltan Kota: > >>>> On Fri, 17 Feb 2006, Hans de Goede wrote: > >>>>> It seems to check the wrong time/date though, its listing a few of my > >>>>> packages which have all been rebuild, take Glide3 as an example from the > >>>>> changelog: > >>>>> * Mon Feb 13 2006 Hans de Goede 20050815-3 > >>>>> - Bump release and rebuild for new gcc4.1 and glibc. > >>>>> - add %%{?dist} for consistency with my other packages > >>>> Same for me (Feb 13). Packages: recode, python-bibtex, pybliographer. > >>> Well, I had to define a point in time *somewhere*. I took the obvious > >>> one: The time when I announced the mass rebuild. The exact one. I know > >>> that the rawhide push with the results from the mass rebuild was done > >>> some hours earlier, but it also takes some time until it hits the > >>> buildsys afaik. Yes, that was Feb 13, but to be precise it was: > >>> $ date --date='2006-02-13 18:22:00 CET' +%s > >>> 1139851320 > >> The obvious time would be 13 feb 00:00 UTC, quoting yourself from: > >> http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060209 > >> > >> "Packages not rebuild before the 12th of February will be removed before > >> FC5 is shipped to start with a clean tree with old cruft removed" > > > > Quoting that page, too: > > > > Mass rebuild of Extras for FC5 > > A separate mail will follow. This is the rough version: Can probably > > start on Sunday.[...] > > > > Note the words "separate mail will follow" and "probably". Because some > > hours later this came: > > https://www.redhat.com/archives/fedora-maintainers/2006-February/msg00031.html > > > >> A late breaking bug was found that affects ppc32/64 systems, and so I > >> have to rebuild every package that is built on these arches over the > >> weekend. Please wait on rebuilding Extras until this is done. > > > > And I waited until f13 gave his okay to start. > > > > As I already wrote in the part of my mail you didn't quote I delayed my > rebuilds because of the extra rebuild, once this was done I started it. > Appereantly the discussion is when the extra rebuild was complete, in my > view this was done when the last rawhide changelog mail was send. + > maybe some time for the buildsys to pick up the changes I don't know > how/when the buildsys syncs to rawhide. That's okay. And I wrote earlier in this thread: > Okay. We can revisit that point in time and can set i back some hours -- > but where exactly? And wherever we put it, there will probably always be > someone who'll say "My package was rebuild just between 1 and 1440> minutes earlier then , why does > it need a rebuild?" This could soon lead to and endless discussion that > might take a lot of more time then it takes to just rebuild the packages > in question... > > But Hans, Zoltan, if you come up with a new point of time that is > acceptable for everyone I'm willing to change the script to that one. Hans, so simply *give me a time* and this discussion can end. Just make sure that the packages after that time were probably be build after the buildsys picked up the latest rawhide changes. CU thl -- Thorsten Leemhuis From ville.skytta at iki.fi Sat Feb 18 14:08:23 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 18 Feb 2006 16:08:23 +0200 Subject: buildsys and kernel modules (was: Re: Summary from yesterdays fesco meeting) In-Reply-To: <1140210997.6735.22.camel@localhost.localdomain> References: <1140205181.2904.20.camel@localhost.localdomain> <1140210997.6735.22.camel@localhost.localdomain> Message-ID: <1140271703.20024.23.camel@bobcat.mine.nu> On Fri, 2006-02-17 at 16:16 -0500, Dan Williams wrote: > a) Let packages do whatever the heck they want with their Exclusive, > Exclude, BuildArch tags, including using %{ix86} as Mike suggests > b) Have the buildsystem recognize kmod packages somehow (which we have > to do anyway), then filter kmod packages through a "supported" list of > sub-arches, including i586, i686, x86_64, ppc, athlon. There's some > support for this already in the buildsystem. +1 Attached is a couple of rough patches I have had in my local working dir for some time; they add support for passing arbitrary arguments to builds and makes the build archs configurable in local "make foo" builds. plague/mock will need changes too, but I think this could be useful; it already allows eg. "make i686" in local checkouts to do the right thing wrt. kmod packages, and plague/mock could probably take advantage of the buildarchs and buildargs targets: $ pwd /home/scop/cvs/fedora/extras/lirc-kmod/devel $ make buildarchs i586 i686 x86_64 ppc $ make buildargs ARCH=i686 --define 'kver 2.6.15-1.1955_FC5' --define 'variants "" smp' $ make buildargs ARCH=x86_64 --define 'kver 2.6.15-1.1955_FC5' --define 'variants ""' # etc The kmod patch obviously needs updating wrt. xen* and possibly other variants, so it's informational only for now. One nice "side effect" of this is that it would be applicable to all packages that need non-default build archs or arguments for whatever reason, not just kmod-*. -------------- next part -------------- A non-text attachment was scrubbed... Name: kmod.patch Type: text/x-patch Size: 608 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: common.patch Type: text/x-patch Size: 3815 bytes Desc: not available URL: From fedora at leemhuis.info Sat Feb 18 14:34:38 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Feb 2006 15:34:38 +0100 Subject: Summary from yesterdays fesco meeting In-Reply-To: <1140210997.6735.22.camel@localhost.localdomain> References: <1140205181.2904.20.camel@localhost.localdomain> <1140210997.6735.22.camel@localhost.localdomain> Message-ID: <1140273278.2904.178.camel@localhost.localdomain> Am Freitag, den 17.02.2006, 16:16 -0500 schrieb Dan Williams: > On Fri, 2006-02-17 at 20:39 +0100, Thorsten Leemhuis wrote: > > * Kernel module standardization > > * Should archs be hardcoded with a "ExclusiveArch: i586 i686 x86_64 > > ppc" or similar entries? That's how it is done in beehive, but scop > > doesn't like that idea to much. Warren will ask dcbw if there are > > alternatives. > > Warren poked me, here's my response: > ------------------------------------------------------- >[...] > a) Let packages do whatever the heck they want with their Exclusive, > Exclude, BuildArch tags, including using %{ix86} as Mike suggests > b) Have the buildsystem recognize kmod packages somehow (which we have > to do anyway), then filter kmod packages through a "supported" list of > sub-arches, including i586, i686, x86_64, ppc, athlon. There's some > support for this already in the buildsystem. >[...] > Let me know what you think. Sound good to me. Any ideas what we need to achieve b) ? There is nothing in the current kernel-module proposal that would help with that (besides the "kmod" in the name). CU thl -- Thorsten Leemhuis From bugzilla at redhat.com Sat Feb 18 14:42:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 09:42:07 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602181442.k1IEg7OY031347@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From andreas at bawue.net 2006-02-18 09:42 EST ------- > W: ser-postgresql doc-file-dependency /usr/share/doc/ser-postgresql-0.9.6/copy_to_psql /usr/bin/perl Thanks. That's fixed now. > Not OK (/etc/ser not owned by main package.) Fixed. > Could the serweb html files be moved to /var/www/html/serweb? This > could potentially be a problem with SELinux, as well as conforming > more to existing practice. Let me look into this. I oriented myself at the squirrelmail package, which is one of the few webapps included in RHEL and Fedora. This package has its datafiles in /usr/share/%{name}. But the part about depending on smarty and removing the internal smarty_template system is a good idea. I'll see to it, that this part is changed. Good idea security-wise. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From j.w.r.degoede at hhs.nl Sat Feb 18 15:19:41 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 18 Feb 2006 16:19:41 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1140271503.2904.173.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <43F632B9.40904@hhs.nl> <1140251657.2904.24.camel@localhost.localdomain> <43F71677.2080506@hhs.nl> <1140266775.2904.149.camel@localhost.localdomain> <43F7207D.3080605@hhs.nl> <1140271503.2904.173.camel@localhost.localdomain> Message-ID: <43F73B0D.4000608@hhs.nl> Thorsten Leemhuis wrote: > Am Samstag, den 18.02.2006, 14:26 +0100 schrieb Hans de Goede: >> Thorsten Leemhuis wrote: >>> Am Samstag, den 18.02.2006, 13:43 +0100 schrieb Hans de Goede: >> >> As I already wrote in the part of my mail you didn't quote I delayed my >> rebuilds because of the extra rebuild, once this was done I started it. >> Appereantly the discussion is when the extra rebuild was complete, in my >> view this was done when the last rawhide changelog mail was send. + >> maybe some time for the buildsys to pick up the changes I don't know >> how/when the buildsys syncs to rawhide. > > That's okay. And I wrote earlier in this thread: > >> Okay. We can revisit that point in time and can set i back some hours -- >> but where exactly? And wherever we put it, there will probably always be >> someone who'll say "My package was rebuild just > between 1 and 1440> minutes earlier then , why does >> it need a rebuild?" This could soon lead to and endless discussion that >> might take a lot of more time then it takes to just rebuild the packages >> in question... >> >> But Hans, Zoltan, if you come up with a new point of time that is >> acceptable for everyone I'm willing to change the script to that one. > > Hans, so simply *give me a time* and this discussion can end. Just make > sure that the packages after that time were probably be build after the > buildsys picked up the latest rawhide changes. > Thats the problem, I don't know how long it takes for the buildsys to pick up rawhide changes, so I'm suggesting to use the time of the rawhide changelog mail + some extra time , hoping that someone who knows the buildsys can tell us what amount of extra time is needed after the rawhide changelog mail. Regards, Hans From bugzilla at redhat.com Sat Feb 18 15:13:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 10:13:08 -0500 Subject: [Bug 173368] Review Request: planetplanet In-Reply-To: Message-ID: <200602181513.k1IFD8kD002378@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: planetplanet https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173368 ------- Additional Comments From rich at phekda.gotadsl.co.uk 2006-02-18 10:13 EST ------- Thanks for the further review! Response to items needing attention: 1. The Python licence is listed as GPL-compatible by the FSF -- see . So no problem there. 2. I've updated my rpms: http://homepages.nildram.co.uk/~phekda/richdawe/fedora/FC4/planet.spec http://homepages.nildram.co.uk/~phekda/richdawe/fedora/FC4/planet-1.0-0.5.20060218pre.src.rpm http://homepages.nildram.co.uk/~phekda/richdawe/fedora/FC4/i386/planet-1.0-0.5.20060218pre.noarch.rpm These are built off planet--devel--1.0--patch-20, which I got using: baz register-archive http://www.gnome.org/~jdub/arch baz get jdub at perkypants.org--projects/planet--devel--1.0--patch-20 I've put MD5 sums of the files I downloaded in planet--devel--1.0--patch-20 here: http://homepages.nildram.co.uk/~phekda/richdawe/fedora/FC4/MD5SUM.planet--devel--1.0--patch-20 The 1.0 release was due to appear two weeks ago...but hasn't. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From mattdm at mattdm.org Sat Feb 18 15:32:01 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 18 Feb 2006 10:32:01 -0500 Subject: Packages in CVS with no entry in the owners.list (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1140262149.2904.90.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140262149.2904.90.camel@localhost.localdomain> Message-ID: <20060218153201.GA24889@jadzia.bu.edu> On Sat, Feb 18, 2006 at 12:29:09PM +0100, Thorsten Leemhuis wrote: > - Good Question: wxPython (Matt Miller, maybe could you take care off > this?) That has an entry in the owners.list, though, yeah? My plan is that wxPythonGTK2 is going away and wxPython is coming back. However, no version of wxPython exists that will build against the current wxGTK, leaving the package in a Bad State. I talked with the wxPython author, and he says wxGTK 2.6.2.3 and wxPython 2.6.2.3 are scheduled to happen very shortly and that everything will be corrected at that point. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Sat Feb 18 15:34:09 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 18 Feb 2006 10:34:09 -0500 Subject: FE package status Thu Feb 2 2006 In-Reply-To: <604aa7910602031339h482216a8ocd2dff851d438792@mail.gmail.com> References: <200602021655.k12GtJYb003950@ludwig-alpha.unil.ch> <604aa7910602031339h482216a8ocd2dff851d438792@mail.gmail.com> Message-ID: <20060218153409.GA25323@jadzia.bu.edu> On Fri, Feb 03, 2006 at 04:39:32PM -0500, Jeff Spaleta wrote: > wxPython is in the list why? wxPythonGTK2 now exists which provides wxPython > Its not in fc4 either. > repoquery -q --provides wxPythonGTK2 > ... > wxPython = 2.4.2.4-7 > wxPythonGTK2 = 2.4.2.4-7 I'm planning to move back to the name "wxPython" to match the upstream source. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From bugzilla at redhat.com Sat Feb 18 15:43:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 10:43:52 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602181543.k1IFhq3C006537@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From jvdias at redhat.com 2006-02-18 10:43 EST ------- Yes, there is mpif90 in openmpi-devel : /usr/bin/om-mpif90 /usr/share/openmpi/bin/mpif90 It was a mistake to name it om-mpif90 in /usr/bin as it does not clash with LAM - I'll name it /usr/bin/mpif90 in the release that gets submitted to FC. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From fedora at leemhuis.info Sat Feb 18 15:50:43 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Feb 2006 16:50:43 +0100 Subject: Packages in CVS with no entry in the owners.list (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <20060218153201.GA24889@jadzia.bu.edu> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140262149.2904.90.camel@localhost.localdomain> <20060218153201.GA24889@jadzia.bu.edu> Message-ID: <1140277844.6634.9.camel@localhost.localdomain> Am Samstag, den 18.02.2006, 10:32 -0500 schrieb Matthew Miller: > On Sat, Feb 18, 2006 at 12:29:09PM +0100, Thorsten Leemhuis wrote: > > - Good Question: wxPython (Matt Miller, maybe could you take care off > > this?) > That has an entry in the owners.list, though, yeah? Yes. > My plan is that wxPythonGTK2 is going away and wxPython is coming back. [...] Well, in that case could you please add a entry for wxPython now -- just for the sake of completeness and for clarification? You need such a entry sooner or later anyway if I understood your plans correctly. CU thl -- Thorsten Leemhuis From mattdm at mattdm.org Sat Feb 18 15:52:25 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 18 Feb 2006 10:52:25 -0500 Subject: Packages in CVS with no entry in the owners.list (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1140277844.6634.9.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140262149.2904.90.camel@localhost.localdomain> <20060218153201.GA24889@jadzia.bu.edu> <1140277844.6634.9.camel@localhost.localdomain> Message-ID: <20060218155225.GA26066@jadzia.bu.edu> On Sat, Feb 18, 2006 at 04:50:43PM +0100, Thorsten Leemhuis wrote: > > That has an entry in the owners.list, though, yeah? > Yes. > > My plan is that wxPythonGTK2 is going away and wxPython is coming back. [...] > Well, in that case could you please add a entry for wxPython now -- just > for the sake of completeness and for clarification? You need such a > entry sooner or later anyway if I understood your plans correctly. That's the part I'm confused about. I'm look at the file and I see an entry there already with my name on it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From bugs.michael at gmx.net Sat Feb 18 15:54:48 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 18 Feb 2006 16:54:48 +0100 Subject: FE Package Status of Feb 16, 2006 In-Reply-To: <1140264009.2904.119.camel@localhost.localdomain> References: <200602161627.k1GGRAOi020957@ludwig-alpha.unil.ch> <1140264009.2904.119.camel@localhost.localdomain> Message-ID: <20060218165448.30fbb45c.bugs.michael@gmx.net> On Sat, 18 Feb 2006 13:00:09 +0100, Thorsten Leemhuis wrote: > - "Packages missing in owners.list" -- I send a mail out on that ropic > an hour ago. If all owners react we should get rid of those soon. owners.list is "Step 9" of the NewPackageProcess! It is inacceptable that during package review the bugzilla ticket is CLOSED before an entry to owners.list has been added. I've had no luck contacting the owner of "at-poke" by mail and neither via maintainers-list. So this issue is one that "sucks very much" IMO. > - "Orphaned packages present in the development repo" -- They normally > should be removed IMHO. Might be a bit to late for FE5, but I still > think we have enough time (BTW, why are they still there? We agreed in > one of the past FESCo meeting that they should be removed *before* the > mass rebuild) Did we? Then that was a misunderstanding. The one thing *I* promised to do (and have done several days ago) is to purge broken binary orphans from the repo. I did not suggest removing any other orphans from the repo. That would break post-install yum upgrades: libs upgraded, exe upgrades not available => transaction check => *boom* Further, there are some packages marked as orphans, which are not really orphans. And some have been added to Extras through the new package process and appear as orphaned nevertheless, e.g. "hula"? Uh? From bugzilla at redhat.com Sat Feb 18 15:58:00 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 10:58:00 -0500 Subject: [Bug 181993] New: Review Request: charis-fonts - Charis SIL fonts Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181993 Summary: Review Request: charis-fonts - Charis SIL fonts Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: roozbeh at farsiweb.info QAContact: fedora-extras-list at redhat.com Spec Url: http://guava.farsiweb.info/~roozbeh/charis-fonts.spec SRPM Url: http://guava.farsiweb.info/~roozbeh/charis-fonts-4.0.02-1.src.rpm Description: Charis SIL provides glyphs for a wide range of Latin and Cyrillic characters. Charis is similar to Bitstream Charter, one of the first fonts designed specifically for laser printers. It is highly readable and holds up well in less-than-ideal reproduction environments. It also has a full set of styles - regular, italic, bold, bold italic - and so is more useful in general publishing than Doulos SIL. Charis is a serif proportionally spaced font optimized for readability in long printed documents. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From fedora at leemhuis.info Sat Feb 18 16:05:28 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Feb 2006 17:05:28 +0100 Subject: Packages in CVS with no entry in the owners.list (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <20060218155225.GA26066@jadzia.bu.edu> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140262149.2904.90.camel@localhost.localdomain> <20060218153201.GA24889@jadzia.bu.edu> <1140277844.6634.9.camel@localhost.localdomain> <20060218155225.GA26066@jadzia.bu.edu> Message-ID: <1140278728.6634.17.camel@localhost.localdomain> Am Samstag, den 18.02.2006, 10:52 -0500 schrieb Matthew Miller: > On Sat, Feb 18, 2006 at 04:50:43PM +0100, Thorsten Leemhuis wrote: > > > That has an entry in the owners.list, though, yeah? > > Yes. > > > My plan is that wxPythonGTK2 is going away and wxPython is coming back. [...] > > Well, in that case could you please add a entry for wxPython now -- just > > for the sake of completeness and for clarification? You need such a > > entry sooner or later anyway if I understood your plans correctly. > > That's the part I'm confused about. I'm look at the file and I see an entry > there already with my name on it. Matthew, sorry, I was fooled by http://www.fedoraproject.org/wiki/Extras/PackageStatus#head-7ad8ccfb3d8a18c22476e20d7ddaab55b4b9cfe1 where it is listed below "Packages in CVS with no entry in the owners.list" Might be a bug in Christian's script. Sorry for the noise. -- Thorsten Leemhuis From bugzilla at redhat.com Sat Feb 18 15:59:05 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 10:59:05 -0500 Subject: [Bug 181994] New: Review Request: doulos-fonts Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181994 Summary: Review Request: doulos-fonts Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: roozbeh at farsiweb.info QAContact: fedora-extras-list at redhat.com Spec Url: http://guava.farsiweb.info/~roozbeh/doulos-fonts.spec SRPM Url: http://guava.farsiweb.info/~roozbeh/doulos-fonts-4.0.14-1.src.rpm Description: Doulos SIL provides glyphs for a wide range of Latin and Cyrillic characters. Doulos is very similar to Times/Times New Roman, but only has a single regular face. It is intended for use alongside other Times-like fonts where a range of styles (italic, bold) are not needed. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 18 16:10:14 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 11:10:14 -0500 Subject: [Bug 177166] Review Request: perl-Compress-Bzip2 - Interface to Bzip2 compression library In-Reply-To: Message-ID: <200602181610.k1IGAEV1009619@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Compress-Bzip2 - Interface to Bzip2 compression library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177166 jpo at di.uminho.pt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From jpo at di.uminho.pt 2006-02-18 11:10 EST ------- Ville, I kept it opened in order to remember to look into the second item of your list in comment #1 (just added a item in my FE task list). Closing ticket. jpo -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From fedora at leemhuis.info Sat Feb 18 16:25:24 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Feb 2006 17:25:24 +0100 Subject: FE Package Status of Feb 16, 2006 In-Reply-To: <20060218165448.30fbb45c.bugs.michael@gmx.net> References: <200602161627.k1GGRAOi020957@ludwig-alpha.unil.ch> <1140264009.2904.119.camel@localhost.localdomain> <20060218165448.30fbb45c.bugs.michael@gmx.net> Message-ID: <1140279924.6634.35.camel@localhost.localdomain> Am Samstag, den 18.02.2006, 16:54 +0100 schrieb Michael Schwendt: > On Sat, 18 Feb 2006 13:00:09 +0100, Thorsten Leemhuis wrote: > > > - "Packages missing in owners.list" -- I send a mail out on that ropic > > an hour ago. If all owners react we should get rid of those soon. > > owners.list is "Step 9" of the NewPackageProcess! It is inacceptable that > during package review the bugzilla ticket is CLOSED before an entry to > owners.list has been added. Well, seems it happen nevertheless. Not nice, but that's life. If we take a look at it now and then and fix it the unowned packages it's should sort out. >[...] > > - "Orphaned packages present in the development repo" -- They normally > > should be removed IMHO. Might be a bit to late for FE5, but I still > > think we have enough time (BTW, why are they still there? We agreed in > > one of the past FESCo meeting that they should be removed *before* the > > mass rebuild) > > Did we? Then that was a misunderstanding. That happens. That's life, too ;-) > The one thing *I* promised to do > (and have done several days ago) is to purge broken binary orphans from > the repo. I did not suggest removing any other orphans from the repo. That > would break post-install yum upgrades: libs upgraded, exe upgrades not > available => transaction check => *boom* Well, we need to deal with that somehow. For example a "Rebuild the orphan packages task force" -- but who will do that? And who will maintain them later during lifetime of FE6? And how long are we going to do that? Forever? I don't think that will work. Maybe we should remove the orphaned packages and add a meta-package that "Obsoletes" and thus removes all the orphans during yum update. Also not nice, but at least a bit better. Has anybody a better idea? > Further, there are some packages marked as orphans, which are not really > orphans. Yeah, I suspected something like that. But how to we find out which? The rebuild might help a bit here, too. At least gtkglarea2 and wesnoth seem to be orphaned according to owners.list, but they were both rebuild by somebody. /me looks closer gtkglarea2 -- Gerard Milmeister wesnoth -- Michael Schwendt (sigh ;-) ) > And some have been added to Extras through the new package process > and appear as orphaned nevertheless, e.g. "hula"? Uh? Interesting. I more and more like the "rebuild by maintainer" solution -- we find a lot of stuff this way that needs a closer look or even "fixing". It's a sort of "Fedora Extras inventory and cleanup just in time for a new release". CU thl -- Thorsten Leemhuis From bugzilla at redhat.com Sat Feb 18 16:25:43 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 11:25:43 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602181625.k1IGPh5P011583@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From fedora at soeterbroek.com 2006-02-18 11:25 EST ------- (In reply to comment #22) Some questions regarding last comment #22: > None of the perl stuff is needed as rpmbuild automatically picks up perl module > dependencies. > Ok, fair enough. I did not know rpmbuild did this. > > - Trying to install heartbeat gave me: > > useradd: cannot create directory /home/hacluster > error: %pre(heartbeat-2.0.3-3.fc5.i386) scriptlet failed, exit status 12 > error: install: %pre scriptlet failed (2), skipping heartbeat-2.0.3-3.fc5 > > The user creation section has to be changed. Fedora Extras packages can't > create system users. You might check out > http://fedoraproject.org/wiki/Packaging/UserCreation?action=show&redirect=PackageUserCreation > I am not sure I understand what you mean by this. I think you want me to change this line: USEROPT="-g haclient -u 17 -d /var/lib/heartbeat/cores/hacluster" to: USEROPT="-g haclient -u $[ $(cat /etc/fedora/usermgmt/baseuid) + 17 ] -d /var/lib/heartbeat/cores/hacluster" Correct? > - rpmlint: > > # rpmlint heartbeat-pils > W: heartbeat-pils devel-file-in-non-devel-package /usr/lib/libpils.so > ^ this should be in heartbeat-devel (or heartbeat-pils-devel) > I am unsure what to do here: * Do *.so files always go in a seperate -devel package or just in this case? What to do with /usr/lib/pils/plugins/InterfaceMgr/generic.so file? * You know that /usr/lib/libpils.so symlinks to /usr/lib/libpils.so.1.0.0; should this also go in -devel package? > E: heartbeat-pils library-without-ldconfig-postin /usr/lib/libpils.so.1.0.0 > E: heartbeat-pils library-without-ldconfig-postun /usr/lib/libpils.so.1.0.0 > ^ needs: > %post pils -p /sbin/ldconfig > %postun pils -p /sbin/ldconfig If these files go to -devel package, then it should be %post devel -p /sbin/ldconfig correct? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 18 16:27:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 11:27:52 -0500 Subject: [Bug 175502] Review Request: perl-Gtk2-Spell In-Reply-To: Message-ID: <200602181627.k1IGRqt2011865@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Gtk2-Spell https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175502 ------- Additional Comments From cweyl at alumni.drew.edu 2006-02-18 11:27 EST ------- Updated spec/srpm: Spec Name or Url: http://www.mindspring.com/~cweyl/perl-Gtk2-Spell/perl-Gtk2-Spell.spec SRPM Name or Url: http://www.mindspring.com/~cweyl/perl-Gtk2-Spell/perl-Gtk2-Spell-1.03-4.ckw.fc4.src.rpm Updated per #5. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 18 16:39:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 11:39:35 -0500 Subject: [Bug 180532] Review Request: perl-UNIVERSAL-can In-Reply-To: Message-ID: <200602181639.k1IGdZm2013651@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-UNIVERSAL-can https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180532 jpo at di.uminho.pt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From jpo at di.uminho.pt 2006-02-18 11:39 EST ------- Built for devel only. I am also targeting the perl-test-MockObject to devel only. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 18 16:51:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 11:51:08 -0500 Subject: [Bug 174952] Review Request: lightning - GNU Lightning In-Reply-To: Message-ID: <200602181651.k1IGp826014866@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: lightning - GNU Lightning https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174952 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |jpmahowald at gmail.com OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-18 11:51 EST ------- Will not build: Arch not included. You probably want %{ix86} macro for ExclusiveArch. Which does make sense for so much assembly. And when it does compile, it fails with error: Installed (but unpackaged) file(s) found: /usr/share/info/dir This is probably due to the make install step putting an entry in the top node, but we want that done in %post and deleted in %postun http://www.gnu.org/software/lightning/lightning.html is a more relevant URL. Small typo in %description: programms -> programs -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugs.michael at gmx.net Sat Feb 18 16:57:56 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 18 Feb 2006 17:57:56 +0100 Subject: FE Package Status of Feb 16, 2006 In-Reply-To: <1140279924.6634.35.camel@localhost.localdomain> References: <200602161627.k1GGRAOi020957@ludwig-alpha.unil.ch> <1140264009.2904.119.camel@localhost.localdomain> <20060218165448.30fbb45c.bugs.michael@gmx.net> <1140279924.6634.35.camel@localhost.localdomain> Message-ID: <20060218175756.4577d6f2.bugs.michael@gmx.net> On Sat, 18 Feb 2006 17:25:24 +0100, Thorsten Leemhuis wrote: > > The one thing *I* promised to do > > (and have done several days ago) is to purge broken binary orphans from > > the repo. I did not suggest removing any other orphans from the repo. That > > would break post-install yum upgrades: libs upgraded, exe upgrades not > > available => transaction check => *boom* > > Well, we need to deal with that somehow. For example a "Rebuild the > orphan packages task force" -- but who will do that? And who will > maintain them later during lifetime of FE6? And how long are we going to > do that? Forever? I don't think that will work. No, but this time we announce them on the FC5Status page as officially orphaned, remove them from devel after FC-5 branch is available, and then move on. Remember, we've used those FCXStatus pages like that before. > > Further, there are some packages marked as orphans, which are not really > > orphans. > > Yeah, I suspected something like that. But how to we find out which? The > rebuild might help a bit here, too. At least gtkglarea2 and wesnoth seem > to be orphaned according to owners.list, but they were both rebuild by > somebody. > > /me looks closer > > gtkglarea2 -- Gerard Milmeister > wesnoth -- Michael Schwendt (sigh ;-) ) Well, in owners.list I'm in Cc. I've taken over wesnoth quite some time ago from Panu and continued up to their first final release (1.0.x series). But that's it. It remains a potentially orphaned package. Just recently, however, somebody has raised interest in taking it. I just don't remember who it was. ;) From jwboyer at jdub.homelinux.org Sat Feb 18 15:05:05 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 18 Feb 2006 10:05:05 -0500 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1140205892.2904.30.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> Message-ID: <1140275105.15568.14.camel@yoda.jdub.homelinux.org> On Fri, 2006-02-17 at 20:51 +0100, Thorsten Leemhuis wrote: > This time also: Replies to fedora-extras-list please, tia! > > Guys, please keep the buildsys busy. There are a lot of packages that > are still not rebuild afaics. > The following 565 arch specific packages still need a rebuild according > to the script. There might be some false positives in the list like for > example "icu" -- that was moved to core, but still is in the repo and > found by the script. Simply ignore those false positives. > dwmw2 at infradead.org ctrlproxy I've kicked off a rebuild for this one. David can yell at me later if he cares, but it hasn't been a problem in the past :). josh From jwboyer at jdub.homelinux.org Sat Feb 18 14:59:58 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 18 Feb 2006 09:59:58 -0500 Subject: Packaging review guidelines clarification In-Reply-To: <1140109955.2904.28.camel@localhost.localdomain> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> <1140085756.8444.14.camel@laurel.intra.city-fan.org> <3237e4410602160420t7c8ffc8fta0546df263bd2661@mail.gmail.com> <1140098910.8444.21.camel@laurel.intra.city-fan.org> <604aa7910602160725i66b0ae16s17a643839214e91b@mail.gmail.com> <19090.129.42.161.36.1140100224.squirrel@jdub.homelinux.org> <1140108327.5699.0.camel@rousalka.dyndns.org> <1140109955.2904.28.camel@localhost.localdomain> Message-ID: <1140274799.15568.10.camel@yoda.jdub.homelinux.org> On Thu, 2006-02-16 at 18:12 +0100, Thorsten Leemhuis wrote: > Am Donnerstag, den 16.02.2006, 17:45 +0100 schrieb Nicolas Mailhot: > > Le jeudi 16 f?vrier 2006 ? 09:30 -0500, Josh Boyer a ?crit : > > > > On 2/16/06, Paul Howarth wrote: > > > > there was a discussion at somepoint about scratch build trees in the > > > > buildsystem to help with update builds. > > > +1 > > +1 > > Enough votes ;-) I like the idea also and added it already to > http://www.fedoraproject.org/wiki/Extras/Schedule/IdeasContainer > > I put things like this there where I agree that they should be done for > fedora-extras sooner or later. > > I'm also willing to put it on the FESCo Schedule -- but first I'd like > to have someone who drives this whole thing forward. Means: Ask dcbw and > the other buildsys people (skvidal,?) if this is is possible in general, > what is needed to get this running, help with doing the work that might > be needed, report and discuss details with FESCo and fedora-extras-list > and organize all other stuff that might show up to realize this idea. > > Any volunteers? No, it does not have to be someone from FESCo. Everybody > interested in this task can work on this. Ok, I did some digging in the plague code this morning. It seems that plague 0.4 already has support built into it for a testing/scratch repo. Namely, if the target is said repo, it changes the status of the build job to done after building and skips the addtorepo step. (Unless I read some code wrong). So... it's more a question of can we enable this on the FE buildsys and if so what method should we use? Some options: 1) Plague has the ability to allow building from an SRPM itself. We could allow folks to specify the SRPM for a package which will then be uploaded and built on the scratch repo. I believe this option is disabled at the moment on the server config side of things. Doing this would help people ensure that new packages build correctly on all arches, etc before actually being imported into CVS. The idea is that it'll catch some things that a simple review wouldn't and help fixup the package that much earlier. 2) Enable the scratch repo and add a 'make scratch' target to the makefiles. Same advantages as above, just that it requires the package to be in CVS already. The issues with both of these options are: how do we make sure scratch builds aren't holding up real builds (or if that will even be a problem) and if option 1) is used, are there security issues at all with allowing people to upload SRPMs directly. josh From fedora at leemhuis.info Sat Feb 18 17:13:37 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Feb 2006 18:13:37 +0100 Subject: FE Package Status of Feb 16, 2006 In-Reply-To: <20060218175756.4577d6f2.bugs.michael@gmx.net> References: <200602161627.k1GGRAOi020957@ludwig-alpha.unil.ch> <1140264009.2904.119.camel@localhost.localdomain> <20060218165448.30fbb45c.bugs.michael@gmx.net> <1140279924.6634.35.camel@localhost.localdomain> <20060218175756.4577d6f2.bugs.michael@gmx.net> Message-ID: <1140282817.6634.47.camel@localhost.localdomain> Am Samstag, den 18.02.2006, 17:57 +0100 schrieb Michael Schwendt: > On Sat, 18 Feb 2006 17:25:24 +0100, Thorsten Leemhuis wrote: > > > The one thing *I* promised to do > > > (and have done several days ago) is to purge broken binary orphans from > > > the repo. I did not suggest removing any other orphans from the repo. That > > > would break post-install yum upgrades: libs upgraded, exe upgrades not > > > available => transaction check => *boom* > > Well, we need to deal with that somehow. For example a "Rebuild the > > orphan packages task force" -- but who will do that? And who will > > maintain them later during lifetime of FE6? And how long are we going to > > do that? Forever? I don't think that will work. > No, but this time we announce them on the FC5Status page as officially > orphaned, remove them from devel after FC-5 branch is available, and then > move on. Remember, we've used those FCXStatus pages like that before. Sorry, seems I can't follow here. Wouldn't that also result in "that would break post-install yum upgrades [in FC6]: libs upgraded, exe upgrades not available => transaction check => *boom* "? I'd really like to get rid of the orphans sooner than later. At least until we have a security team that at least updates orphans with known security problems. BTW: What do other packages think? Remove them now or after branching? > > > Further, there are some packages marked as orphans, which are not really > > > orphans. > > Yeah, I suspected something like that. But how to we find out which? The > > rebuild might help a bit here, too. At least gtkglarea2 and wesnoth seem > > to be orphaned according to owners.list, but they were both rebuild by > > somebody. > > > > /me looks closer > > > > gtkglarea2 -- Gerard Milmeister > > wesnoth -- Michael Schwendt (sigh ;-) ) > > Well, in owners.list I'm in Cc. I've taken over wesnoth quite some time > ago from Panu and continued up to their first final release (1.0.x > series). But that's it. It remains a potentially orphaned package. > Just recently, however, somebody has raised interest in taking it. > I just don't remember who it was. ;) Ahh, okay. :) Cu thl -- Thorsten Leemhuis From jpmahowald at gmail.com Sat Feb 18 17:13:16 2006 From: jpmahowald at gmail.com (John Mahowald) Date: Sat, 18 Feb 2006 11:13:16 -0600 Subject: Requiring a versioned R in rpy In-Reply-To: <200602161810.20613.jamatos@fc.up.pt> References: <200602161810.20613.jamatos@fc.up.pt> Message-ID: <3ea997540602180913r6549c2d1y892138b12ca4b064@mail.gmail.com> On 2/16/06, Jose' Matos wrote: > Hi all, > rpy requires the version of R for which it is compiled, is there any way to > get that automatically or do I need to set manually each time? > rpy README indicates at least R 1.5 and python 2., both of which Fedora provides http://rpy.sourceforge.net/rpy/README > I have tried > > Requires: \ > R = %(%{_bindir}/R --version | head -n 1 | sed -e 's/.* \(.*\) .*/\1/') > > but it seems that R is not installed at that point. > > Is there any way back? > You need to add a "BuildRequires: R-devel" line if you are going to build against R. Also, you can version these dependencies with operators, >, =, etc. See the rpm book for reference: http://rpm.org/max-rpm-snapshot/ From bugzilla at redhat.com Sat Feb 18 17:42:17 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 12:42:17 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602181742.k1IHgHCH021134@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From andreas at bawue.net 2006-02-18 12:42 EST ------- Uhm. I just tried removing smarty from serweb in favour of using the system-installed one. Unfortunately, I failed horribly. ;) The default smarty code is extended quite a bit by different plugins included by serweb. This might pose a problem. Thus I'd suggest, we postpone the smarty work a bit and include the ser package as is for now. I just updated the spec, to fix the remaining problems but left the smarty work for later. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 18 17:42:39 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 12:42:39 -0500 Subject: [Bug 181997] New: Review Request: gpc - The GNU Pascal compiler Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181997 Summary: Review Request: gpc - The GNU Pascal compiler Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: tibbs at math.uh.edu QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.math.uh.edu/~tibbs/rpms/gpc/gpc.spec SRPM Name or Url: http://www.math.uh.edu/~tibbs/rpms/gpc/gpc-3.4.5_20060215-3.src.rpm Description: The GNU Pascal Compiler (GPC) is, as the name says, the Pascal compiler of the GNU family (http://www.gnu.org/software/gcc/). It: * can act as a native or as a cross compiler between all supported systems, * produces highly optimized code for all these systems, * is Free Software (Open-Source Software) according to the GNU General Public License, * is compatible to other GNU languages and tools such as GNU C and the GNU debugger. The compiler supports the following language standards and quasi-standards: * ISO 7185 Pascal (see Resources), * most of ISO 10206 Extended Pascal, * Borland Pascal 7.0, * parts of Borland Delphi, Mac Pascal and Pascal-SC (PXSC). Comments: This is a nontrivial package, complicated by the facts that I'm no GCC expert and I haven't programmed in Pascal for a couple of decades. One of my users requires it, so.... GPC is built against a release of GCC, but will not build against GCC 4.x. If built against the same release of GCC as is installed on the system, the package must take care to avoid conflicts. The normal %configure process doesn't work, and the package will not build with _smp_mflags. Once the package is installed, most of the files must be deleted because it is not possible to just install the Pascal compiler without installing the GCC it is built against. This has been built and tested on i386 and x86_64. Here is the rpmlint output (on i386): E: gpc devel-dependency gmp-devel W: gpc unstripped-binary-or-object /usr/bin/gpidump W: gpc unstripped-binary-or-object /usr/bin/gpc W: gpc unstripped-binary-or-object /usr/bin/binobj W: gpc unstripped-binary-or-object /usr/libexec/gcc/i386-redhat-linux/3.4.5/gpc1 W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/units/crtx.c W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/libgcc.a W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/libgcc_eh.a W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/units/intlc.c W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/units/regexc.c W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/libgpc.a W: gpc file-not-utf8 /usr/share/info/gpcs-de.info.gz W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/units/crtdjgpp.h W: gpc file-not-utf8 /usr/share/info/gpc.info.gz W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/units/crtc.h W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/units/crtlinux386.h W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/units/crtc.c W: gpc file-not-utf8 /usr/share/info/gpcs-es.info.gz W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/units/pipesc.c W: gpc file-not-utf8 /usr/share/info/gpcs-hr.info.gz W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/units/trapc.c W: gpc non-standard-dir-in-usr libexec Since this is a compiler, it's allowed to include devel files and dependencies in the base package. I don't know what is wrong with /usr/libexec but several packages put things there. Older gpc/gcc releases didn't put gpc1 under libexec, but recently they've started doing so. I don't know about the non-utf8-ness of the info files, nor do I understand why rpmbuild did not strip the binaries. I welcome any assistance in getting this package into shape. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From dcbw at redhat.com Sat Feb 18 17:54:36 2006 From: dcbw at redhat.com (Dan Williams) Date: Sat, 18 Feb 2006 12:54:36 -0500 Subject: Packaging review guidelines clarification In-Reply-To: <1140274799.15568.10.camel@yoda.jdub.homelinux.org> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> <1140085756.8444.14.camel@laurel.intra.city-fan.org> <3237e4410602160420t7c8ffc8fta0546df263bd2661@mail.gmail.com> <1140098910.8444.21.camel@laurel.intra.city-fan.org> <604aa7910602160725i66b0ae16s17a643839214e91b@mail.gmail.com> <19090.129.42.161.36.1140100224.squirrel@jdub.homelinux.org> <1140108327.5699.0.camel@rousalka.dyndns.org> <1140109955.2904.28.camel@localhost.localdomain> <1140274799.15568.10.camel@yoda.jdub.homelinux.org> Message-ID: <1140285276.9486.15.camel@localhost.localdomain> On Sat, 2006-02-18 at 09:59 -0500, Josh Boyer wrote: > On Thu, 2006-02-16 at 18:12 +0100, Thorsten Leemhuis wrote: > > Am Donnerstag, den 16.02.2006, 17:45 +0100 schrieb Nicolas Mailhot: > > > Le jeudi 16 f?vrier 2006 ? 09:30 -0500, Josh Boyer a ?crit : > > > > > On 2/16/06, Paul Howarth wrote: > > > > > there was a discussion at somepoint about scratch build trees in the > > > > > buildsystem to help with update builds. > > > > +1 > > > +1 > > > > Enough votes ;-) I like the idea also and added it already to > > http://www.fedoraproject.org/wiki/Extras/Schedule/IdeasContainer > > > > I put things like this there where I agree that they should be done for > > fedora-extras sooner or later. > > > > I'm also willing to put it on the FESCo Schedule -- but first I'd like > > to have someone who drives this whole thing forward. Means: Ask dcbw and > > the other buildsys people (skvidal,?) if this is is possible in general, > > what is needed to get this running, help with doing the work that might > > be needed, report and discuss details with FESCo and fedora-extras-list > > and organize all other stuff that might show up to realize this idea. > > > > Any volunteers? No, it does not have to be someone from FESCo. Everybody > > interested in this task can work on this. > > Ok, I did some digging in the plague code this morning. It seems that > plague 0.4 already has support built into it for a testing/scratch repo. > Namely, if the target is said repo, it changes the status of the build > job to done after building and skips the addtorepo step. (Unless I read > some code wrong). (note that I renamed "scratch" to "testing" to reduce confusion. If "scratch" is still in the 0.5 code I should fix that.) No, you read the code correctly. However, there's a big gaping hole for scratch/testing builds; dependencies. Since the packages don't get added to the distro repository or the buildsystem repository, you can't build a testing package B that depends on a testing package A. You can only build single packages into a testing repo. Oversight on my part perhaps. We figured this out right before we were going to enable testing targets last year. To fix this, we have to make testing targets full-fledged repositories in their own right, that inherit from the normal distro repo too, and then periodically purge packages over a day or two old. > So... it's more a question of can we enable this on the FE buildsys and > if so what method should we use? Some options: > > 1) > > Plague has the ability to allow building from an SRPM itself. We could > allow folks to specify the SRPM for a package which will then be > uploaded and built on the scratch repo. I believe this option is > disabled at the moment on the server config side of things. Correct, you can either do SRPM _or_ CVS builds, but not both. In the context of testing targets/repos, perhaps SRPMs would be a good thing. But I'm not entirely sure of that. At least if all the files are in CVS, there's a slightly higher accountability so that people don't just shove crap or any old SRPM through the buildsys. It's more "open" and transparent what people are trying to build from a security perspective too. I guess I'd discourage SRPM building for these reasons in the context of Fedora. Remember, you can create arbitrary tags and branches with package CVS, and the buildsys doesn't really care what tag the package comes from as long as the tag exists. > Doing this would help people ensure that new packages build correctly on > all arches, etc before actually being imported into CVS. The idea is > that it'll catch some things that a simple review wouldn't and help > fixup the package that much earlier. You bring up a good point here. But how do we gate this? We probably shouldn't be handing out buildsys accounts some new person 5 minutes after they submit a package just so they can build some random SRPM they found online. > 2) > > Enable the scratch repo and add a 'make scratch' target to the > makefiles. Same advantages as above, just that it requires the package > to be in CVS already. I think this is the more likely scenario. We fix the testing/scratch targets by making them real targets that just don't get their packages moved over to the "official" repository ever. We add cronjobs to kill packages in the testing targets after two days. > The issues with both of these options are: how do we make sure scratch > builds aren't holding up real builds (or if that will even be a problem) > and if option 1) is used, are there security issues at all with allowing > people to upload SRPMs directly. Priorities are going to take a little work in the buildsys. Currently every job has the same importance, and testing targets shouldn't. So I propose that at some point in March we do a major buildsys upgrade to grab plague 0.5 and give us: 1) depsolving (done) 2) real testing targets (needs a bit more work) 3) job priorities (to be done) 4) build preference (to be done) Dan From dcbw at redhat.com Sat Feb 18 17:59:51 2006 From: dcbw at redhat.com (Dan Williams) Date: Sat, 18 Feb 2006 12:59:51 -0500 Subject: Summary from yesterdays fesco meeting In-Reply-To: <1140273278.2904.178.camel@localhost.localdomain> References: <1140205181.2904.20.camel@localhost.localdomain> <1140210997.6735.22.camel@localhost.localdomain> <1140273278.2904.178.camel@localhost.localdomain> Message-ID: <1140285592.9486.19.camel@localhost.localdomain> On Sat, 2006-02-18 at 15:34 +0100, Thorsten Leemhuis wrote: > Am Freitag, den 17.02.2006, 16:16 -0500 schrieb Dan Williams: > > On Fri, 2006-02-17 at 20:39 +0100, Thorsten Leemhuis wrote: > > > * Kernel module standardization > > > * Should archs be hardcoded with a "ExclusiveArch: i586 i686 x86_64 > > > ppc" or similar entries? That's how it is done in beehive, but scop > > > doesn't like that idea to much. Warren will ask dcbw if there are > > > alternatives. > > > > Warren poked me, here's my response: > > ------------------------------------------------------- > >[...] > > a) Let packages do whatever the heck they want with their Exclusive, > > Exclude, BuildArch tags, including using %{ix86} as Mike suggests > > b) Have the buildsystem recognize kmod packages somehow (which we have > > to do anyway), then filter kmod packages through a "supported" list of > > sub-arches, including i586, i686, x86_64, ppc, athlon. There's some > > support for this already in the buildsystem. > >[...] > > Let me know what you think. > > Sound good to me. Any ideas what we need to achieve b) ? There is > nothing in the current kernel-module proposal that would help with that > (besides the "kmod" in the name). A custom specfile tag? :) Seriously though, if there are some simple rules for -kmod, like (these are just suggestions): 1) The string '-kmod' MUST be the last part of the package name 2) The package MUST BuildRequire the 'kernel' and 'kernel-devel' packages That would help. We can pull and analyze any tags we want out of the SRPM headers, we just need to rules use in recognition. Dan From fedora at leemhuis.info Sat Feb 18 18:23:27 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Feb 2006 19:23:27 +0100 Subject: Summary from yesterdays fesco meeting In-Reply-To: <1140285592.9486.19.camel@localhost.localdomain> References: <1140205181.2904.20.camel@localhost.localdomain> <1140210997.6735.22.camel@localhost.localdomain> <1140273278.2904.178.camel@localhost.localdomain> <1140285592.9486.19.camel@localhost.localdomain> Message-ID: <1140287008.6634.67.camel@localhost.localdomain> Am Samstag, den 18.02.2006, 12:59 -0500 schrieb Dan Williams: > On Sat, 2006-02-18 at 15:34 +0100, Thorsten Leemhuis wrote: > > Am Freitag, den 17.02.2006, 16:16 -0500 schrieb Dan Williams: > > > On Fri, 2006-02-17 at 20:39 +0100, Thorsten Leemhuis wrote: > > > > * Kernel module standardization > > > > * Should archs be hardcoded with a "ExclusiveArch: i586 i686 x86_64 > > > > ppc" or similar entries? That's how it is done in beehive, but scop > > > > doesn't like that idea to much. Warren will ask dcbw if there are > > > > alternatives. > > > > > > Warren poked me, here's my response: > > > ------------------------------------------------------- > > >[...] > > > a) Let packages do whatever the heck they want with their Exclusive, > > > Exclude, BuildArch tags, including using %{ix86} as Mike suggests > > > b) Have the buildsystem recognize kmod packages somehow (which we have > > > to do anyway), then filter kmod packages through a "supported" list of > > > sub-arches, including i586, i686, x86_64, ppc, athlon. There's some > > > support for this already in the buildsystem. > > >[...] > > > Let me know what you think. > > Sound good to me. Any ideas what we need to achieve b) ? There is > > nothing in the current kernel-module proposal that would help with that > > (besides the "kmod" in the name). > A custom specfile tag? :) :) > Seriously though, if there are some simple rules for -kmod, like (these > are just suggestions): > > 1) The string '-kmod' MUST be the last part of the package name That's the case already. > 2) The package MUST BuildRequire the 'kernel' and 'kernel-devel' > packages Well, we of course BuildRequire 'kernel-devel' already -- mkodtool takes care that there is a BuildRequire: kernel-devel-i686 = 2.6.14-1.1776_FC4 for example. But a generic BuildRequire: kernel-devel in the static part of the SRPM shouldn't hurt afaics. Dan, just say what you prefer and we go for it. CU thl -- Thorsten Leemhuis From nicolas.mailhot at laposte.net Sat Feb 18 18:22:51 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 18 Feb 2006 19:22:51 +0100 Subject: FE Package Status of Feb 16, 2006 In-Reply-To: <20060218175756.4577d6f2.bugs.michael@gmx.net> References: <200602161627.k1GGRAOi020957@ludwig-alpha.unil.ch> <1140264009.2904.119.camel@localhost.localdomain> <20060218165448.30fbb45c.bugs.michael@gmx.net> <1140279924.6634.35.camel@localhost.localdomain> <20060218175756.4577d6f2.bugs.michael@gmx.net> Message-ID: <1140286971.19313.10.camel@rousalka.dyndns.org> Le samedi 18 f?vrier 2006 ? 17:57 +0100, Michael Schwendt a ?crit : > On Sat, 18 Feb 2006 17:25:24 +0100, Thorsten Leemhuis wrote: > > > > The one thing *I* promised to do > > > (and have done several days ago) is to purge broken binary orphans from > > > the repo. I did not suggest removing any other orphans from the repo. That > > > would break post-install yum upgrades: libs upgraded, exe upgrades not > > > available => transaction check => *boom* > > > > Well, we need to deal with that somehow. For example a "Rebuild the > > orphan packages task force" -- but who will do that? And who will > > maintain them later during lifetime of FE6? And how long are we going to > > do that? Forever? I don't think that will work. > > No, but this time we announce them on the FC5Status page as officially > orphaned, remove them from devel after FC-5 branch is available, and then > move on. Remember, we've used those FCXStatus pages like that before. Well, as long as they rebuild as-is and no one complains of the result, why not let them in FE ? It's not black-and-white, we should take into account the level of maintenance needed on a package-per-package basis. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From fedora at leemhuis.info Sat Feb 18 18:30:14 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Feb 2006 19:30:14 +0100 Subject: Again: EOL Policy for Fedora Extras Message-ID: <1140287414.6634.70.camel@localhost.localdomain> Hi all! We still have no defined EOL Policy for Fedora Extras -- there were some ideas and concepts floating around, but no real policy came out of it so far. I'd really like to get this solved somehow soon. That's why I'm writing this mail. First I'll try to summarize all the important parts of the past discussions. Please tell me if I forgot anything important. Note, I tried to keep the list short and only covered the most important parts without going into the details. Some general ideas, thoughts and quotes I found in the IRC and mailinglist-archives: - Now that FC3 was transfered to Legacy we need some kind of policy for FE3, too -- users want to know if FE3 is still completely supported. - We are a voluntary driven project -- we can't force any packages to still maintain FE3 if he has no interest in it. If we try it will fail. On the other hand: We are volunteers, and if volunteers want to do something, you shouldn't prevent them from doing it -- You should make it as easy as possible, otherwise they will feel peed. - We have no security team (yet); It's unclear how many packages in FE3 might have well known security problems atm (but the same is true for FE4 and FE-devel, too) - Core has a fairly clear policy, we need a long term policy for Extras, too. Even if we might need to revisit parts of it if something does not work out as planed. - We cannot offer an old FE which is out-of-date or possible insecure at least partially. - It's not helpful, when some packagers still maintain it [FE3] while others don't -- either the full show or none at all - It would be a disservice to the community to pretend that [FE3] it's as maintained as FE4/FE5 - It's Extras. It's unsupported by nature. - How many fire and forget packages are sitting in Extras? And some concrete plans: - keep FE3 fully alive -- it's of interest for RHEL4/CentOS and/or Aurora - shove FE3 into a Maintenance state for now -- no new packages, no big updates but still updates in case of security problems - shove FE3 to Fedora Legacy - drop FE3 at the same time when FC3 is moved to Fedora Legacy - we create an extras legacy team that takes over FE3 when FC3 is transfered to legacy So, how do we get out of the dilemma? I looks like some of the ideas are quite contrary, so we probably can't find a solution that fits everyone. Sigh -- this mail will probably result in a long discussion again. That's okay, but please keep in mind that we should come out of the discussion with a workable policy in the end. We can revisit that later if things change. So, let's look at some of the concrete plans a bit closer: - Shove FE3 to Fedora Legacy Fedora Legacy has indicated that they neither are interested nor have the manpower to also maintain FE. Seems like a dead end. - Drop FE3 completely Well, that has to happen at some point in time. But doing it at the same time when the corresponding Core release is transferred to legacy sounds "a bit to early" for me. A later time like "One {week,month} after FC5 was released" is also quite early, but with the current state of this discussions it seems like a acceptable solution for now until we have a better plan. - keep FE3 fully alive for RHEL4/CentOS and/or Aurora; some people that suggested this even want to take over the complete maintainer-ship for all packages in FE3 ( https://www.redhat.com/archives/fedora-extras-list/2006-February/msg00652.html ) Well, I can understand this idea. But there are some things that I don't like: -- Maintaining FE3 is a job that needs more then one packager. Two or three is a minimum IMHO and AFAICS. -- Maybe the next is only a result of my conservative mind, but I'll write it down here anyway: IMHO most people that still use FC3 due it often for one reason: They have a stable system or web-server that does everything what they want -- they don't want fancy new stuff or updates that bear a risk of breaking things. Those people shouldn't get fancy new stuff -- they should only get security updates for such "old" distros. If they need newer stuff a updated Fedora Core is the way to go. - We create an Extras Legacy Team that takes over FE3 when FC3 is transfered to legacy I don't think that we find enough people for it. But maybe I'm wrong. If a Team/SIG/Task Force shows up that is willing and *capable* to to this (maybe in arrangement with the current extras maintainers if those are still interested in maintaining their packages for FE3) then I think this is a acceptable option. But I don't see such a group anywhere ATM. - shove FE3 into a Maintenance state for now -- no new packages, no big updates but still updates from the usual maintainers in case of security problems Sound like the best idea so far -- but how to we make sure that the Extras packagers still maintain their stuff? We can't. We need a Security SIG that oversees this and jumps in when the maintainer forgets to fix his package. FE4 would benefit from such a Security SIG, too. And even if we shove FE3 into a Maintenance state -- we need to define a EOL date for FE3 in any case. When? Release of FC6? FC7? When legacy drops the belonging Fedora Core? Opinions please. tia! CU thl -- Thorsten Leemhuis From fedora at leemhuis.info Sat Feb 18 18:45:14 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Feb 2006 19:45:14 +0100 Subject: Do we want extras/testing/{4,5} repos (was Re: Packaging review guidelines clarification) In-Reply-To: <1140285276.9486.15.camel@localhost.localdomain> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> <1140085756.8444.14.camel@laurel.intra.city-fan.org> <3237e4410602160420t7c8ffc8fta0546df263bd2661@mail.gmail.com> <1140098910.8444.21.camel@laurel.intra.city-fan.org> <604aa7910602160725i66b0ae16s17a643839214e91b@mail.gmail.com> <19090.129.42.161.36.1140100224.squirrel@jdub.homelinux.org> <1140108327.5699.0.camel@rousalka.dyndns.org> <1140109955.2904.28.camel@localhost.localdomain> <1140274799.15568.10.camel@yoda.jdub.homelinux.org> <1140285276.9486.15.camel@localhost.localdomain> Message-ID: <1140288314.6634.85.camel@localhost.localdomain> Am Samstag, den 18.02.2006, 12:54 -0500 schrieb Dan Williams: > On Sat, 2006-02-18 at 09:59 -0500, Josh Boyer wrote: > > On Thu, 2006-02-16 at 18:12 +0100, Thorsten Leemhuis wrote: >[...] > > Ok, I did some digging in the plague code this morning. It seems that > > plague 0.4 already has support built into it for a testing/scratch repo. > > Namely, if the target is said repo, it changes the status of the build > > job to done after building and skips the addtorepo step. (Unless I read > > some code wrong). > > (note that I renamed "scratch" to "testing" to reduce confusion. If > "scratch" is still in the 0.5 code I should fix that.) > > No, you read the code correctly. However, there's a big gaping hole for > scratch/testing builds; dependencies. Since the packages don't get > added to the distro repository or the buildsystem repository, you can't > build a testing package B that depends on a testing package A. You can > only build single packages into a testing repo. Oversight on my part > perhaps. We figured this out right before we were going to enable > testing targets last year. [...] Site note: If this code soon works for real should we consider to put the public extras/testing/ repo "back to life" (or let's say: start using this old idea again)? We could use it with a scheme like "All new or updated packages should hang out some days in extras/testing/ before they get pushed over to the official trees automatically; only important updates that for fix security problems go directly to the official tree". Opinions? CU thl -- Thorsten Leemhuis From nicolas.mailhot at laposte.net Sat Feb 18 18:48:53 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 18 Feb 2006 19:48:53 +0100 Subject: Again: EOL Policy for Fedora Extras In-Reply-To: <1140287414.6634.70.camel@localhost.localdomain> References: <1140287414.6634.70.camel@localhost.localdomain> Message-ID: <1140288533.19313.27.camel@rousalka.dyndns.org> IMHO : 1. we should formally create an FE Legacy team. FEL would be composed of the Aurora/Centos/FCL/FE people that want to maintain old releases. Some poor sucker should be nominated to serve as initial fearless leader (surely of all the Aurora/Centos/FC3 users one is ready to take charge?) 2. the handover from FE to FEL should be synchronized with the one from FC to FCL. It's the only sane solution WRT users, they have other things to do than track multiple overlapping Fedora schedules (also from a marketing POW its probably saner to advertise to users the move at FCn+1 time, and let the FCn+1 -> FCn+2T2 be the grace period that was always intended) 3. we should let FEL define its own policies. Today we don't know the number of people interested in FEL and their level of involvement. It's useless to dictate rules to a team which is not assembled yet. People who want to do it should first go to 1. and create some form of entity 4. If in X months no one has stepped to 1. we should recognise the level of community support to create a FEL is not here yet, and announce loudly no one maintains FE3 anymore. Keep the repo for historical reasons but move it to a freezer so non one mistakenly use it on actual systems. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Sat Feb 18 18:52:08 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 18 Feb 2006 19:52:08 +0100 Subject: Do we want extras/testing/{4,5} repos (was Re: Packaging review guidelines clarification) In-Reply-To: <1140288314.6634.85.camel@localhost.localdomain> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> <1140085756.8444.14.camel@laurel.intra.city-fan.org> <3237e4410602160420t7c8ffc8fta0546df263bd2661@mail.gmail.com> <1140098910.8444.21.camel@laurel.intra.city-fan.org> <604aa7910602160725i66b0ae16s17a643839214e91b@mail.gmail.com> <19090.129.42.161.36.1140100224.squirrel@jdub.homelinux.org> <1140108327.5699.0.camel@rousalka.dyndns.org> <1140109955.2904.28.camel@localhost.localdomain> <1140274799.15568.10.camel@yoda.jdub.homelinux.org> <1140285276.9486.15.camel@localhost.localdomain> <1140288314.6634.85.camel@localhost.localdomain> Message-ID: <1140288728.19313.31.camel@rousalka.dyndns.org> Le samedi 18 f?vrier 2006 ? 19:45 +0100, Thorsten Leemhuis a ?crit : > Site note: If this code soon works for real should we consider to put > the public extras/testing/ repo "back to life" (or let's say: start > using this old idea again)? > > We could use it with a scheme like "All new or updated packages should > hang out some days in extras/testing/ before they get pushed over to the > official trees automatically; only important updates that for fix > security problems go directly to the official tree". > > Opinions? The only interest of a scratchpad is it's not mandatory/automatic, if you force it on everyone the situation won't be any better than we have now. Let packagers decide when they need to use the scratchpad and to whom they advertise the result for testing purposes. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From fedora at leemhuis.info Sat Feb 18 19:04:32 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Feb 2006 20:04:32 +0100 Subject: Do we want extras/testing/{4,5} repos (was Re: Packaging review guidelines clarification) In-Reply-To: <1140288728.19313.31.camel@rousalka.dyndns.org> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> <1140085756.8444.14.camel@laurel.intra.city-fan.org> <3237e4410602160420t7c8ffc8fta0546df263bd2661@mail.gmail.com> <1140098910.8444.21.camel@laurel.intra.city-fan.org> <604aa7910602160725i66b0ae16s17a643839214e91b@mail.gmail.com> <19090.129.42.161.36.1140100224.squirrel@jdub.homelinux.org> <1140108327.5699.0.camel@rousalka.dyndns.org> <1140109955.2904.28.camel@localhost.localdomain> <1140274799.15568.10.camel@yoda.jdub.homelinux.org> <1140285276.9486.15.camel@localhost.localdomain> <1140288314.6634.85.camel@localhost.localdomain> <1140288728.19313.31.camel@rousalka.dyndns.org> Message-ID: <1140289472.6634.91.camel@localhost.localdomain> Am Samstag, den 18.02.2006, 19:52 +0100 schrieb Nicolas Mailhot: > Le samedi 18 f?vrier 2006 ? 19:45 +0100, Thorsten Leemhuis a ?crit : > > Site note: If this code soon works for real should we consider to put > > the public extras/testing/ repo "back to life" (or let's say: start > > using this old idea again)? > > > > We could use it with a scheme like "All new or updated packages should > > hang out some days in extras/testing/ before they get pushed over to the > > official trees automatically; only important updates that for fix > > security problems go directly to the official tree". > > > > Opinions? > > The only interest of a scratchpad is it's not mandatory/automatic, if > you force it on everyone the situation won't be any better than we have > now. [...] I disagree -- with testing repos that only testers have enabled packages get at least a bit of testing before they hit the masses. This way packages for example get tested on x86_64 and ppc before going public, even if the packager only has access to i386. I know, it doesn't work to well with update-testing in core -- but it's IMHO better then no testing at all. CU thl -- Thorsten Leemhuis From bugs.michael at gmx.net Sat Feb 18 19:23:47 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 18 Feb 2006 20:23:47 +0100 Subject: FE Package Status of Feb 16, 2006 In-Reply-To: <1140282817.6634.47.camel@localhost.localdomain> References: <200602161627.k1GGRAOi020957@ludwig-alpha.unil.ch> <1140264009.2904.119.camel@localhost.localdomain> <20060218165448.30fbb45c.bugs.michael@gmx.net> <1140279924.6634.35.camel@localhost.localdomain> <20060218175756.4577d6f2.bugs.michael@gmx.net> <1140282817.6634.47.camel@localhost.localdomain> Message-ID: <20060218202347.2d064fe2.bugs.michael@gmx.net> On Sat, 18 Feb 2006 18:13:37 +0100, Thorsten Leemhuis wrote: > > No, but this time we announce them on the FC5Status page as officially > > orphaned, remove them from devel after FC-5 branch is available, and then > > move on. Remember, we've used those FCXStatus pages like that before. > > Sorry, seems I can't follow here. Wouldn't that also result in "that > would break post-install yum upgrades [in FC6]: libs upgraded, exe > upgrades not available => transaction check => *boom* "? At some point in time, yes. The difference is that we remove them at the beginning of a development stage, not at the end. There is no silver bullet. Every package, which is removed from the repository but is still installed on a user's machine, breaks a yum upgrade badly as soon as dependencies change in incompatible ways (e.g. soname changes). > I'd really like to get rid of the orphans sooner than later. The following are without maintainer for a longer time, i.e. in 2005 and before Dec 2005 (and tracked in the Wiki): arc camstream cksfv diag-ether doctorj freedroidrpg gnome-telnet gpa hping2 manedit mknbi netdiag nget parchive perl-Net-SCP perl-Net-SSH prozilla putty rpmproc tdl tetex-arabtex tetex-armtex tetex-font-tipa tetex-lgrind tla xmms-cdread xtide From jspaleta at gmail.com Sat Feb 18 19:28:38 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 18 Feb 2006 14:28:38 -0500 Subject: Do we want extras/testing/{4, 5} repos (was Re: Packaging review guidelines clarification) In-Reply-To: <1140289472.6634.91.camel@localhost.localdomain> References: <1140066142.3004.297.camel@ernie> <604aa7910602160725i66b0ae16s17a643839214e91b@mail.gmail.com> <19090.129.42.161.36.1140100224.squirrel@jdub.homelinux.org> <1140108327.5699.0.camel@rousalka.dyndns.org> <1140109955.2904.28.camel@localhost.localdomain> <1140274799.15568.10.camel@yoda.jdub.homelinux.org> <1140285276.9486.15.camel@localhost.localdomain> <1140288314.6634.85.camel@localhost.localdomain> <1140288728.19313.31.camel@rousalka.dyndns.org> <1140289472.6634.91.camel@localhost.localdomain> Message-ID: <604aa7910602181128y6cb2ea28o82fb5c6d88db8051@mail.gmail.com> On 2/18/06, Thorsten Leemhuis wrote: > I know, it doesn't work to well with update-testing in core -- but it's > IMHO better then no testing at all. If this policy goes in I'd want an established loophole that allows hot fix updates to fix brokenness that made it through the "testing" timeout without comment and not just security updates. And yo have to watch out for how this mandatory tree complicates the building of other packages which depend on packages sitting in the testing tree awaiting the timeout to expire. If the buildsystem automatically uses packages in this tree, then you'll have to have a way to expidite packages out of this tree before the timeout if a security hotfix for a depedant package needs to get released to keep depchains clean. If this tree is not automatically included in the buildsystem you'll have to have some mechanism by which maintainers can request it be included when they are doing a set of packages in a dependacy chain, to avoid the mandatory timeout from getting in the way. I'd like to see this implemented on a probational basis and then re-evaluated to see if the timeout based testing tree is a net benefit or a net hinderance. The non-published scratch tree idea I think is good regardless of what happens with a pre-release testing tree. -jef"I am still working on my wtf is up with becoming a sponsers draft..I haven't forgotten"spaleta From buildsys at fedoraproject.org Sat Feb 18 19:32:13 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 18 Feb 2006 14:32:13 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060218193213.B7ED38011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 7 GeoIP-1.3.14-3.fc4 dejavu-fonts-2.2-4.fc4 fontforge-20060125-2.fc4 gcfilms-6.1-1.fc4 gossip-0.10-2.fc4 kid3-0.6-2.fc4 opencdk-0.5.8-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat Feb 18 19:32:21 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 18 Feb 2006 14:32:21 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060218193221.CC0C58011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 12 ctrlproxy-2.6.2-6.fc5 gcfilms-6.1-1.fc5 gossip-0.10-2.fc5 id3v2-0.1.11-3.fc5 kid3-0.6-2.fc5 krecipes-0.9.1-4.fc5 perl-Config-Tiny-2.04-2.fc5 perl-HTML-Scrubber-0.08-3.fc5 perl-HTML-Template-2.8-2.fc5 perl-Module-Versions-Report-1.02-3.fc5 perl-Test-Pod-Coverage-1.08-2.fc5 xmms-sid-0.8.0-0.1.beta15.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From mattdm at mattdm.org Sat Feb 18 19:49:35 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 18 Feb 2006 14:49:35 -0500 Subject: Packages in CVS with no entry in the owners.list (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1140278728.6634.17.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140262149.2904.90.camel@localhost.localdomain> <20060218153201.GA24889@jadzia.bu.edu> <1140277844.6634.9.camel@localhost.localdomain> <20060218155225.GA26066@jadzia.bu.edu> <1140278728.6634.17.camel@localhost.localdomain> Message-ID: <20060218194935.GA2956@jadzia.bu.edu> On Sat, Feb 18, 2006 at 05:05:28PM +0100, Thorsten Leemhuis wrote: > Matthew, sorry, I was fooled by > http://www.fedoraproject.org/wiki/Extras/PackageStatus#head-7ad8ccfb3d8a18c22476e20d7ddaab55b4b9cfe1 > where it is listed below "Packages in CVS with no entry in the owners.list" > Might be a bug in Christian's script. Sorry for the noise. No problem. It's definitely true that there's some current weirdness with the package. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From bugs.michael at gmx.net Sat Feb 18 19:59:13 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 18 Feb 2006 20:59:13 +0100 Subject: Again: EOL Policy for Fedora Extras In-Reply-To: <1140287414.6634.70.camel@localhost.localdomain> References: <1140287414.6634.70.camel@localhost.localdomain> Message-ID: <20060218205913.2bc8fa29.bugs.michael@gmx.net> On Sat, 18 Feb 2006 19:30:14 +0100, Thorsten Leemhuis wrote: > We still have no defined EOL Policy for Fedora Extras -- there were some > ideas and concepts floating around, but no real policy came out of it so > far. I'd really like to get this solved somehow soon. That's why I'm > writing this mail. Long mail, short story: Do we agree on common goals with regard to FE? I'm not sure we do. Instead of discussing EOL policy bottom-up for FE3, how about we discuss in general _what_ we at Fedora Extras _try_ to offer? > mailinglist-archives: > > > - Now that FC3 was transfered to Legacy we need some kind of policy for > FE3, too -- users want to know if FE3 is still completely supported. Reason: package maintainers often move on to the current if not latest release of FC and don't run an older FC anymore. So they don't do any run-time evaluation of upgrades/updates anymore. Unless they are the "if it builds, push it" type of packagers, they don't release any upgrades which they don't use regularly themselves. Further, the older a release of FC gets, the more difficult security related version upgrades become, if they require upgraded dependencies. This also leads to coordination and compatibility requirements between FE and Fedora Legacy. > - We cannot offer an old FE which is out-of-date or possible insecure at > least partially. Which means, there's no need to shut down a repo, but the project ought to announce the "updates support level users can expect" compared with Extras for the current release of FC. > - It's Extras. It's unsupported by nature. That's brain-fart type of comment. Suitable for flame-wars, not for serious attempts at discussing this issue. Hopefully we all know what kind of "support" Fedora Extras is about. > - How many fire and forget packages are sitting in Extras? Same here. :( Let's shut down the whole show just because of a few black sheep. > And some concrete plans: > - shove FE3 into a Maintenance state for now -- no new packages, no big > updates but still updates in case of security problems What is "concrete" about this suggestion? It's just another proposal which doesn't suggest _who_ performs the updates. Assume that some packagers will _refuse_ releasing updates for a legacy FC. > - we create an extras legacy team that takes over FE3 when FC3 is > transfered to legacy +1 This is the only realistic suggestion. No community developer interest, no show. From bugzilla at redhat.com Sat Feb 18 19:54:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 14:54:53 -0500 Subject: [Bug 181993] Review Request: charis-fonts - Charis SIL fonts In-Reply-To: Message-ID: <200602181954.k1IJsrIB005260@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: charis-fonts - Charis SIL fonts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181993 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From tibbs at math.uh.edu 2006-02-18 14:54 EST ------- This is a nice, clean package; you should consider submitting a specfile template for fonts. Upstream's download system is annoying, but that's not your fault and you at least provided instructions for getting the source. rpmlint says: W: charis-fonts invalid-license SIL Open Font License W: charis-fonts wrong-file-end-of-line-encoding /usr/share/doc/charis-fonts-4.0.02/CharisSIL4FontDocumentation.pdf The license is acceptable; it's probably worth opening a bug against rpmlint to get it added. The second warning is just rpmlint being dumb; there's no point in paying attention to line endings in a PDF file. Anyway: rpmlint output is fine. The package meets the naming and packaging guidelines. The specfile is properly named and follows rather exactly that of a previously accepted package. The source file matches upstream. The license is appropriate and included as %doc. Approved. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bdpepple at ameritech.net Sat Feb 18 20:10:51 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Sat, 18 Feb 2006 15:10:51 -0500 Subject: Again: EOL Policy for Fedora Extras In-Reply-To: <20060218205913.2bc8fa29.bugs.michael@gmx.net> References: <1140287414.6634.70.camel@localhost.localdomain> <20060218205913.2bc8fa29.bugs.michael@gmx.net> Message-ID: <1140293452.15240.0.camel@shuttle.273piedmont.org> On Sat, 2006-02-18 at 20:59 +0100, Michael Schwendt wrote: > On Sat, 18 Feb 2006 19:30:14 +0100, Thorsten Leemhuis wrote: > > - we create an extras legacy team that takes over FE3 when FC3 is > > transfered to legacy > > +1 This is the only realistic suggestion. No community developer > interest, no show. +1. /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: 191 bytes Desc: This is a digitally signed message part URL: From bugzilla at redhat.com Sat Feb 18 20:05:57 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 15:05:57 -0500 Subject: [Bug 181994] Review Request: doulos-fonts - Doulos SIL fonts In-Reply-To: Message-ID: <200602182005.k1IK5v5r006710@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: doulos-fonts - Doulos SIL fonts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181994 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From tibbs at math.uh.edu 2006-02-18 15:05 EST ------- There's essentially no difference between this package and charis-fonts (bug #181993), so here's a boring cut and paste. rpmlint says: W: doulos-fonts invalid-license SIL Open Font License W: doulos-fonts wrong-file-end-of-line-encoding /usr/share/doc/doulos-fonts-4.0.14/DoulosSIL4FontDocumentation.pdf The license is acceptable; it's probably worth opening a bug against rpmlint to get it added. The second warning is just rpmlint being dumb; there's no point in paying attention to line endings in a PDF file. Anyway: rpmlint output is fine. The package meets the naming and packaging guidelines. The specfile is properly named and follows rather exactly that of a previously accepted package. The source file matches upstream. The license is appropriate and included as %doc. Approved. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From fedora at leemhuis.info Sat Feb 18 20:43:07 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Feb 2006 21:43:07 +0100 Subject: Again: EOL Policy for Fedora Extras In-Reply-To: <20060218205913.2bc8fa29.bugs.michael@gmx.net> References: <1140287414.6634.70.camel@localhost.localdomain> <20060218205913.2bc8fa29.bugs.michael@gmx.net> Message-ID: <1140295387.6634.110.camel@localhost.localdomain> Am Samstag, den 18.02.2006, 20:59 +0100 schrieb Michael Schwendt: > On Sat, 18 Feb 2006 19:30:14 +0100, Thorsten Leemhuis wrote: > > > We still have no defined EOL Policy for Fedora Extras -- there were some > > ideas and concepts floating around, but no real policy came out of it so > > far. I'd really like to get this solved somehow soon. That's why I'm > > writing this mail. > > Long mail, short story: Do we agree on common goals with regard to FE? Well, we're a lot of packagers now and in such a large group the goals that people have will always be a bit ^w^w different. > I'm not sure we do. Instead of discussing EOL policy bottom-up for FE3, > how about we discuss in general _what_ we at Fedora Extras _try_ to offer? Feel free to start a detailed discussion. I wrote enough long mails already today ;-) I'll see what comes out of the discussion or jump in when I feel a need for it. > [...] > > - It's Extras. It's unsupported by nature. > That's brain-fart type of comment. Suitable for flame-wars, not for > serious attempts at discussing this issue. Hopefully we all know what kind > of "support" Fedora Extras is about. I can agree here, but... > > - How many fire and forget packages are sitting in Extras? > > Same here. :( Let's shut down the whole show just because of a few black > sheep. ...I have to disagree here. Nobody talked about "shutting down the whole show" (well, not until now). We have no security SIG or something similar yet that watches security mailing-lists or fixes packages if the maintainer does not act im time. So this question is okay here IMHO (and was not from me in the beging, I just quoted it). > > And some concrete plans: > > > - shove FE3 into a Maintenance state for now -- no new packages, no big > > updates but still updates in case of security problems > > What is "concrete" about this suggestion? This part at the end of my original mail: - shove FE3 into a Maintenance state for now -- no new packages, no big updates but still updates from the usual maintainers in case of security problems [...] but how to we make sure that the Extras packagers still maintain their stuff? We can't. We need a Security SIG that oversees this and jumps in when the maintainer forgets to fix his package. FE4 would benefit from such a Security SIG, too. And even if we shove FE3 into a Maintenance state -- we need to define a EOL date for FE3 in any case. When? Release of FC6? FC7? When legacy drops the belonging Fedora Core? > It's just another proposal > which doesn't suggest _who_ performs the updates. Maintainer -> If not the security SIG jumps in -- we need such a SIG anyway afaics. > Assume that some > packagers will _refuse_ releasing updates for a legacy FC. Sure. > > - we create an extras legacy team that takes over FE3 when FC3 is > > transfered to legacy > > +1 This is the only realistic suggestion. No community developer > interest, no show. Well, we already have community interest in a Security SIG and some maintainer that still want to maintain FE3. But we'll see, maybe enough people step up for FEL (Fedora Extras Legacy). We just need to find a solution -- even if that is "There was no community developer interest, so Fedora Extras 3 is EOL from now on." CU thl -- Thorsten Leemhuis From wtogami at redhat.com Sat Feb 18 20:45:34 2006 From: wtogami at redhat.com (Warren Togami) Date: Sat, 18 Feb 2006 15:45:34 -0500 Subject: Blend Fedora Objectives (was Re: Again: EOL Policy for Fedora Extras) In-Reply-To: <1140288533.19313.27.camel@rousalka.dyndns.org> References: <1140287414.6634.70.camel@localhost.localdomain> <1140288533.19313.27.camel@rousalka.dyndns.org> Message-ID: <43F7876E.7050501@redhat.com> Nicolas Mailhot wrote: > IMHO : > > 1. we should formally create an FE Legacy team. FEL would be composed of > the Aurora/Centos/FCL/FE people that want to maintain old releases. Some > poor sucker should be nominated to serve as initial fearless leader > (surely of all the Aurora/Centos/FC3 users one is ready to take charge?) > > 2. the handover from FE to FEL should be synchronized with the one from > FC to FCL. It's the only sane solution WRT users, they have other things > to do than track multiple overlapping Fedora schedules (also from a > marketing POW its probably saner to advertise to users the move at FCn+1 > time, and let the FCn+1 -> FCn+2T2 be the grace period that was always > intended) FE to FEL has no realistic relation to the schedule of FC to FCL. > > 3. we should let FEL define its own policies. Today we don't know the > number of people interested in FEL and their level of involvement. It's > useless to dictate rules to a team which is not assembled yet. People > who want to do it should first go to 1. and create some form of entity > I think it is entirely broken to "hand over" the entire Extras and expect some other volunteer to take care of it. This will create a guaranteed failure situation for a community group because the set of packages is potentially infinite and the natural problem that security is difficult to maintain with only volunteers (even Debian struggles). It is a *fantasy* for maintainers to expect they hand over responsibility to some theoretical entity and expect it to actually work. Instead I suggest key changes to existing Fedora projects to better facilitate communication and responsibility. Included in this is having formal package update announcements for Extras exactly as we have in Core. We must also create hard machine countable metrics for retiring an old volunteer abandoned distribution. Finally (the most difficult problem) we must blend the differences between Core, Extras, and Legacy so people don't care what it is called, as long as *somebody* is maintaining the packages then it is OK. These are lofty goals, but I believe we can achieve these ideas if we slowly change the project through a series of objectives. Some examples: 1) Task: All new bug reports in Extras should go to a list Timeframe: ASAP This easy change already discussed in FESCO would increase the chances of new issues reported against Extras packages to be handled by somebody in a timely manner. There currently isn't agreement whether we should have this mail go to the existing fedora-extras-list and further overload those subscribers, or create a new extras-bugs-list limited only to people interested enough to subscribe. I am leaning towards the latter. It is clear to me however that this is not a feasible long-term solution. The amount of mail will never stop growing, and it will become more and more detrimental over time for any person to attempt to read everything. I think that we should always keep subscribing to a bug list as an *option*, however we should move toward the next goal. 2) Task: All Packages in Core and Extras should officially have multiple owners in the database Timeframe: Early FC6 cycle This key change would be useful for both Core and Extras, because often packages would benefit from multiple eyes watching and owning new bug reports. It should also have the ability to say "I maintain only FE4 and newer." or "I maintain only FE3 of this package." We can also have the ability to subscribe to "categories" of packages where clear sub-communities can be identified, like the existing Fedora Perl team. The idea behind this objective is to compartmentalize the growing infeasible bulk of bug mail to the people best suited to deal with it. 3) Task: Organize formal security status tracking of Fedora Extras similarly to how Core is tracked. Timeframe: FC6 cycle Who: ??? Yes, security is a hard problem for volunteers for many reasons... I think the primary responsibility of the security people is to *track* security issues in some fashion in some database. They cannot be expected to both track and fix all packages. Not all package maintainers will abandon their older versions of packages, and they should have the first opportunity to fix stuff that they own if they are identified as vulnerable. A tracking system would allow the community to quickly see what isn't fixed and somebody else can take care of it if the original maintainer isn't responding quickly or if the package is marked as abandoned. One huge complication here is how we handle embargoed security issues. I have no clue how we would do this currently. The database would allow *any* Fedora contributor to add stuff to the security tracking system, as anybody is really capable of doing this and they might as well help. However the key to success here is for somebody to be responsible for it. This is a difficult problem because of the differing motivations between volunteer contributors and commercial interests... 4) Task: Formal package update announcements for Extras Timeframe: After security team is defined and running These should first go into a database, and from that different media feeds can be generated on-demand. Static web pages, RSS feeds, and e-mail are a couple examples. === WARNING: PURELY THEORETICAL STUFF BELOW === 5) Task: Allow direct participation in Core from Fedora community Timeframe: ??? This is only my personal idea at this point so don't get excited yet. I have some ideas for differential requirements below, but these are only off the top of my head and of course we can discuss and improve it. It will be a hard sell because we don't have the infrastructure (CVS, buildsystem, etc.) and security mechanisms in place to adequately do this yet. This currently is not possible unless Core moves to an entirely different build and source tracking infrastructure than what is currently used today. Don't hold your breath. This wont happen anytime soon. If you have improvements to contribute to core, especially rawhide, please continue to submit Bugzilla reports. Even if this objective is achieved many changes may benefit from discussion and consensus building between multiple maintainers so Bugzilla reports would be useful even then too. Keep in mind that this objective refers entirely to "rawhide" Fedora development and current Fedora releases. Potential Requirements: 1. We may accept contributors who have proven themselves through many months of technical skill or leadership in Extras. This barrier of entry is much higher than cvsextras sponsorship requirements. 2. We may accept upstream contributors of individual Core packages if they are willing to work with and not conflict with the desires of the Core package maintainer. 3. Membership here is on a per-package ACL basis. Or in some cases maybe an entire package group, like perl*. 4. Membership here is ultimately a decision of the individual Core package owner, if they want to allow a Fedora community contributor to be co-owner of a Core package. 6) Legacy contribution goes directly into older Core Timeframe: ??? The previous objective enables Legacy to directly contribute and build directly into Core, but on an ACL basis only for the releases that Red Hat engineering no longer supports. Same idea as the current Legacy, except using similar infrastructure as Core itself. It could be another instance of the Core/Extras buildsystem, or maybe the same, or maybe it doesn't matter. We can figure out the specifics later as the project will look entirely different by this time. Perhaps a database flag and e-mail announcements can clearly note somehow that the update came from fully community sources rather than Red Hat engineering. The same could be true of the previous objective. 7) Possibly Abolish "Legacy" name Maybe the "Legacy" name has a negative connotation. Instead "Fedora Security" could be the organizational entity name, and it doesn't matter who did the actual work. Leaders can emerge to be overseers of "Fedora Security" but anybody can do work. The actual "name" of the project doesn't matter so much as what work is actually done, so the Legacy team themselves should decide if they really want this objective. > 4. If in X months no one has stepped to 1. we should recognise the level > of community support to create a FEL is not here yet, and announce > loudly no one maintains FE3 anymore. Keep the repo for historical > reasons but move it to a freezer so non one mistakenly use it on actual > systems. I support the idea of retirement if community interest in maintaining it is gone. This is exactly how Legacy currently operates. Warren Togami wtogami at redhat.com From bugzilla at redhat.com Sat Feb 18 20:43:46 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 15:43:46 -0500 Subject: [Bug 180571] Review Request: puppet In-Reply-To: Message-ID: <200602182043.k1IKhkBg011354@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: puppet https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180571 ------- Additional Comments From tibbs at math.uh.edu 2006-02-18 15:43 EST ------- Just took a quick look. I can't sponsor so someone else will need to do the formal review. Firstly, you really should submit a separate review request for facter and make this one bug depend on it. Secondly, I don't think you can't just pick UID 317 like that. Extras has fedora-usermgmt for handling this; see http://fedoraproject.org/wiki/Packaging/UserCreation and http://fedoraproject.org/wiki/Packaging/UserRegistry -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From fedora at leemhuis.info Sat Feb 18 21:35:29 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Feb 2006 22:35:29 +0100 Subject: Blend Fedora Objectives (was Re: Again: EOL Policy for Fedora Extras) In-Reply-To: <43F7876E.7050501@redhat.com> References: <1140287414.6634.70.camel@localhost.localdomain> <1140288533.19313.27.camel@rousalka.dyndns.org> <43F7876E.7050501@redhat.com> Message-ID: <1140298529.6634.135.camel@localhost.localdomain> Am Samstag, den 18.02.2006, 15:45 -0500 schrieb Warren Togami: > Nicolas Mailhot wrote: > > 3. we should let FEL define its own policies. Today we don't know the > > number of people interested in FEL and their level of involvement. It's > > useless to dictate rules to a team which is not assembled yet. People > > who want to do it should first go to 1. and create some form of entity > > I think it is entirely broken to "hand over" the entire Extras and > expect some other volunteer to take care of it. This will create a > guaranteed failure situation for a community group because the set of > packages is potentially infinite and the natural problem that security > is difficult to maintain with only volunteers (even Debian struggles). > It is a *fantasy* for maintainers to expect they hand over > responsibility to some theoretical entity and expect it to actually work. +1 >[...] > 1) Task: All new bug reports in Extras should go to a list > Timeframe: ASAP > > This easy change already discussed in FESCO would increase the chances > of new issues reported against Extras packages to be handled by somebody > in a timely manner. There currently isn't agreement whether we should > have this mail go to the existing fedora-extras-list and further > overload those subscribers, or create a new extras-bugs-list limited > only to people interested enough to subscribe. I am leaning towards the > latter. Me too. But I'm wondering bugzilla-spam should go; Maybe we even need three mailinglists: fedora-extras-list -> for discussions and questions regarding FE fedora-extras-reviews-list -> bugzilla spam from review bugs fedora-extras-bugs-list -> all other extras bugs > It is clear to me however that this is not a feasible long-term > solution. The amount of mail will never stop growing, and it will > become more and more detrimental over time for any person to attempt to > read everything. I think that we should always keep subscribing to a > bug list as an *option*, however we should move toward the next goal. The section "About OPEN-BUGS packages" in http://www.fedoraproject.org/wiki/Extras/PackageStatus#head-b08e03806e3ec607e04e9dc478d2e97caed889f1 is a great help IMHO. We just need to start using and enhancing it. > 2) Task: All Packages in Core and Extras should officially have multiple > owners in the database > Timeframe: Early FC6 cycle [...] Nice idea. Related: We should have a policy that regulates when Fedora Extras packages should be allowed to touch packages that are owned by somebody else (in case of security fixes for example) > 3) Task: Organize formal security status tracking of Fedora Extras > similarly to how Core is tracked. > Timeframe: FC6 cycle > Who: ??? Yes, security is a hard problem for volunteers for many reasons... [...] A security SIG/Team/Task Force is already in the works. Still in the early planing stages. I asked Hans for a status update an hour ago. >[...] > === WARNING: PURELY THEORETICAL STUFF BELOW === > > 5) Task: Allow direct participation in Core from Fedora community > Timeframe: ??? Side note: openSuse plans to simplify participation to their "Core-Distro" afaik, too. It's high on their todo-list iirc. > 6) Legacy contribution goes directly into older Core > Timeframe: ??? [...] Don't forget "Updates build by 'Legacy' should be uploaded to the same place where Core updates from Red Hat were uploaded to before -> no yum re-configuration, no special 'legacy' repos for yum/pirut" > 7) Possibly Abolish "Legacy" name +1 > [...] Cu thl -- Thorsten Leemhuis From qspencer at ieee.org Sat Feb 18 21:49:47 2006 From: qspencer at ieee.org (Quentin Spencer) Date: Sat, 18 Feb 2006 15:49:47 -0600 Subject: Packages in CVS with no entry in the owners.list (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1140262149.2904.90.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140262149.2904.90.camel@localhost.localdomain> Message-ID: <43F7967B.5050204@ieee.org> Thorsten Leemhuis wrote: >Note: If your E-Mail address is in the CC of this mail please read it! > >Am Freitag, den 17.02.2006, 20:51 +0100 schrieb Thorsten Leemhuis: > > >>Am Montag, den 13.02.2006, 18:22 +0100 schrieb Thorsten Leemhuis: >> >> >[...] > > >>The script found the following packages in extras/development for which >>no entry in the owners.list could be found: fftw3, umfpack, >>perl-Gtk2-GladeXML, perl-Imager, perl-Gnome2-Canvas, html-xml-utils, >>dia, libdsk, libspectrum, lib765 >> >> > >I looked a bit closer at this list and that one maintained from >Christian and his scripts in the wiki at >http://fedoraproject.org/wiki/Extras/PackageStatus#head-7ad8ccfb3d8a18c22476e20d7ddaab55b4b9cfe1 > >Find below a list of people that seemed to be interested in these >packages in the past. I've CCed all them. So if you are CCed to this >mail and (still) want to maintain the package(s) please add the required >details to the owners.list -- see >http://fedoraproject.org/wiki/Extras/Contributors#head-f6f080b4c48fe519c98a29364a740953f90179e7 >for details. > >If I don't hear anything until Wednesday, Feb. 22 I'll assume that they >are orphaned. I will add them to the orphaned page in the wiki and add a >corresponding entry to the owners.list so others can take the packages >over. > >These are in the extras/devel but have no entry in owners.list > >- Caolan McNamara : dia >- Gavin Henry : perl-Gtk2-GladeXML, >perl-Imager, perl-Gnome2-Canvas, html-xml-utils >- Matt Domsch : gpp >- Paul F. Johnson : libdsk, lib765, >libspectrum >- Quentin Spencer : umfpack > > umfpack has been obsoleted by ufsparse (it is a subset of the libraries provided in ufsparse). It was removed from CVS a long time ago, but there might still be some packages in the repos, which can be removed. -Quentin From bugzilla at redhat.com Sat Feb 18 21:58:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 16:58:59 -0500 Subject: [Bug 177359] Review Request: itk - object oriented extensions for Tk In-Reply-To: Message-ID: <200602182158.k1ILwxqR020022@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: itk - object oriented extensions for Tk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177359 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |jpmahowald at gmail.com OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-18 16:58 EST ------- Good: - rpmlint checks return: rpmlint of itk-devel-3.3-0.2.RC1.fc4.i386.rpm: W: itk-devel no-documentation - package meets naming guidelines - follows guidlines for release canidate - package meets packaging guidelines - license (BSD) OK, text in %doc, matches source - spec file legible, in am. english - source matches upstream - package compiles on FC4 i386 - no missing BR - no unnecessary BR - no locales - not relocatable - owns all directories that it creates - no duplicate files - permissions ok - %clean ok - macro use consistent - code, not content - no need for -docs - nothing in %doc affects runtime - no need for .desktop file - devel package ok - no .la files - devel requires base package n-v-r APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From nicolas.mailhot at laposte.net Sat Feb 18 22:10:42 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 18 Feb 2006 23:10:42 +0100 Subject: Blend Fedora Objectives (was Re: Again: EOL Policy for Fedora Extras) In-Reply-To: <43F7876E.7050501@redhat.com> References: <1140287414.6634.70.camel@localhost.localdomain> <1140288533.19313.27.camel@rousalka.dyndns.org> <43F7876E.7050501@redhat.com> Message-ID: <1140300642.19313.68.camel@rousalka.dyndns.org> Le samedi 18 f?vrier 2006 ? 15:45 -0500, Warren Togami a ?crit : > > 3. we should let FEL define its own policies. Today we don't know the > > number of people interested in FEL and their level of involvement. It's > > useless to dictate rules to a team which is not assembled yet. People > > who want to do it should first go to 1. and create some form of entity > > > > I think it is entirely broken to "hand over" the entire Extras and > expect some other volunteer to take care of it. This will create a > guaranteed failure situation for a community group because the set of > packages is potentially infinite and the natural problem that security > is difficult to maintain with only volunteers (even Debian struggles). > It is a *fantasy* for maintainers to expect they hand over > responsibility to some theoretical entity and expect it to actually work. The fantasy is to continue not acknowledging the problem. I'm very sceptical about the viability of a FEL. I write so openly. If we create one it will suck the first releases just like it did for FCL (and this is the optimistic scenario). But at least users will know where they stand and not expect that because no one dared announce an EOL FE will somehow continue to be maintained indefinitely (and the problem is *not* specifically FC3. Given Fedora's short release cycles the number of releases to maintain is potentially much higher). As far as I'm concerned my part of FE3 was EOLed at FC5T2 time. You can argue all day about FEL or not FEL, but no FEL doesn't mean FE maintainers will magically continue maintaining FE3. It means there's no one to pick up the ball, and the FE3 EOL is final. I say create a FEL team. It will fly or sink. Either way users and maintainers will know what to expect. Sometimes life is tough. That's no reason to play the ostrich. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From katzj at redhat.com Sat Feb 18 22:52:40 2006 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 18 Feb 2006 17:52:40 -0500 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <43F73B0D.4000608@hhs.nl> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <43F632B9.40904@hhs.nl> <1140251657.2904.24.camel@localhost.localdomain> <43F71677.2080506@hhs.nl> <1140266775.2904.149.camel@localhost.localdomain> <43F7207D.3080605@hhs.nl> <1140271503.2904.173.camel@localhost.localdomain> <43F73B0D.4000608@hhs.nl> Message-ID: <1140303160.17151.98.camel@bree.local.net> On Sat, 2006-02-18 at 16:19 +0100, Hans de Goede wrote: > Thats the problem, I don't know how long it takes for the buildsys to > pick up rawhide changes, so I'm suggesting to use the time of the > rawhide changelog mail + some extra time , hoping that someone who knows > the buildsys can tell us what amount of extra time is needed after the > rawhide changelog mail. The changelog mail should be sent at pretty much the same time as the packages are available for the build system. Jeremy From bugzilla at redhat.com Sat Feb 18 22:51:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 17:51:47 -0500 Subject: [Bug 181444] Review Request: lcov -- process gcov output into nice html pages In-Reply-To: Message-ID: <200602182251.k1IMpl2l029890@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: lcov -- process gcov output into nice html pages https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181444 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tibbs at math.uh.edu ------- Additional Comments From tibbs at math.uh.edu 2006-02-18 17:51 EST ------- Dan, were you going to review this? It's still unassigned and blocking FE-NEW. You should assign it to yourself and make it block FW-REVIEW instead, or let me know and I'll review it. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From pertusus at free.fr Sat Feb 18 23:10:34 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 19 Feb 2006 00:10:34 +0100 Subject: Again: EOL Policy for Fedora Extras In-Reply-To: <1140287414.6634.70.camel@localhost.localdomain> References: <1140287414.6634.70.camel@localhost.localdomain> Message-ID: <20060218231034.GA10536@free.fr> > - We are a voluntary driven project -- we can't force any packages to > still maintain FE3 if he has no interest in it. If we try it will fail. > On the other hand: We are volunteers, and if volunteers want to do > something, you shouldn't prevent them from doing it -- You should make > it as easy as possible, otherwise they will feel peed. Why not just keep the infrastructure (enabling the fedora legacy repo) and let everybody do whatever they want? If a maintainer wants to keep a package alive he keeps it alive, if another only wants to correct security flaws only he does it. If somebody wants to correct security issues in other's packages he does it and so on. Only communication is required, then, meaning that a packager could be able to communicate that he stops maintaining a package. It could involve something similar with the orphan page. And also something like the owners file, but with distribution versions, such that it is possible to have different maintainer for different fedora versions. Adding packages that are also added to devel should be easy, the only complicated issue being adding a package to FE3 only. -- Pat From bugzilla at redhat.com Sat Feb 18 23:33:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 18:33:34 -0500 Subject: [Bug 167147] Review Request: Aqsis In-Reply-To: Message-ID: <200602182333.k1INXYa5003333@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Aqsis https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167147 ------- Additional Comments From tibbs at math.uh.edu 2006-02-18 18:33 EST ------- I can't even download the proposed spec or SRPM to take a look. Should this review request be considered withdrawn? (Is there even a procedure for withdrawing a review request?) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From dcbw at redhat.com Sat Feb 18 23:54:54 2006 From: dcbw at redhat.com (Dan Williams) Date: Sat, 18 Feb 2006 18:54:54 -0500 Subject: Do we want extras/testing/{4, 5} repos (was Re: Packaging review guidelines clarification) In-Reply-To: <604aa7910602181128y6cb2ea28o82fb5c6d88db8051@mail.gmail.com> References: <1140066142.3004.297.camel@ernie> <604aa7910602160725i66b0ae16s17a643839214e91b@mail.gmail.com> <19090.129.42.161.36.1140100224.squirrel@jdub.homelinux.org> <1140108327.5699.0.camel@rousalka.dyndns.org> <1140109955.2904.28.camel@localhost.localdomain> <1140274799.15568.10.camel@yoda.jdub.homelinux.org> <1140285276.9486.15.camel@localhost.localdomain> <1140288314.6634.85.camel@localhost.localdomain> <1140288728.19313.31.camel@rousalka.dyndns.org> <1140289472.6634.91.camel@localhost.localdomain> <604aa7910602181128y6cb2ea28o82fb5c6d88db8051@mail.gmail.com> Message-ID: <1140306894.11069.5.camel@localhost.localdomain> On Sat, 2006-02-18 at 14:28 -0500, Jeff Spaleta wrote: > On 2/18/06, Thorsten Leemhuis wrote: > > I know, it doesn't work to well with update-testing in core -- but it's > > IMHO better then no testing at all. > > If this policy goes in I'd want an established loophole that allows > hot fix updates to fix brokenness that made it through the "testing" > timeout without comment and not just security updates. So this is appearing to get more and more complicated. I'm not sure adding more process onto this is the best thing; more process is (a) confusing and (b) a damper on participation. Though we don't want crap packages getting through, is the situation all that bad now? > And yo have to watch out for how this mandatory tree complicates the > building of other packages which depend on packages sitting in the > testing tree awaiting the timeout to expire. If the buildsystem > automatically uses packages in this tree, then you'll have to have a > way to expidite packages out of this tree before the timeout if a > security hotfix for a depedant package needs to get released to keep > depchains clean. Exactly; we get into a situation where somebody gets to decide whether the package is important enough to be expedited, and then either an admin of Extras or the person themselves gets to move the package to the main repo. That's more process. > If this tree is not automatically included in the buildsystem you'll > have to have some mechanism by which maintainers can request it be > included when they are doing a set of packages in a dependacy chain, > to avoid the mandatory timeout from getting in the way. Whee, more layers of complexity. > I'd like to see this implemented on a probational basis and then > re-evaluated to see if the timeout based testing tree is a net benefit > or a net hinderance. What Red Hat has, in many circumstances, found with the -testing repos of Fedora Core is that packages there don't really get the testing they deserve. Not enough people actually test them or use them to make it all that worthwhile. There just isn't that much response to -testing. > The non-published scratch tree idea I think is good regardless of what > happens with a pre-release testing tree. Yeah, this is still a good idea I think. Again though, I don't think adding more complexity and forking multiple repos and package sets here is the answer. I guess I view the scratchpad/testing stuff as more of a ground for making sure your package compiles on PPC before you do the final build. Dan From jspaleta at gmail.com Sun Feb 19 00:08:31 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 18 Feb 2006 19:08:31 -0500 Subject: Do we want extras/testing/{4, 5} repos (was Re: Packaging review guidelines clarification) In-Reply-To: <1140306894.11069.5.camel@localhost.localdomain> References: <1140066142.3004.297.camel@ernie> <1140108327.5699.0.camel@rousalka.dyndns.org> <1140109955.2904.28.camel@localhost.localdomain> <1140274799.15568.10.camel@yoda.jdub.homelinux.org> <1140285276.9486.15.camel@localhost.localdomain> <1140288314.6634.85.camel@localhost.localdomain> <1140288728.19313.31.camel@rousalka.dyndns.org> <1140289472.6634.91.camel@localhost.localdomain> <604aa7910602181128y6cb2ea28o82fb5c6d88db8051@mail.gmail.com> <1140306894.11069.5.camel@localhost.localdomain> Message-ID: <604aa7910602181608i70b704caxc852b2f8589116d5@mail.gmail.com> On 2/18/06, Dan Williams wrote: > Whee, more layers of complexity. A mandatory pre-publish testing pretty much demands the complications, in a way that a scratch area does not. But even a scratch area will need to be integrated into the buildsystem for maximum benefit. Anyone wanting to test that a set of packages that make up a dependancy chain work.. will need to turn on the scratch area to fill deps as they walk through the chain. Example: if a new update to application bar needs an update to package libfoo and the current release of application bar wont work with the new libfoo. As a maintainer you'd like to use a scratch build on the buildsystem to make sure the new set of foo and bar both build as expected so you can push both packages to the release tree so noone experiences am unrecoverable dep problem if they are not pushed together. Testing the new libfoo by itself isnt useful because if you push it but the new application bar doesn't build.. you have broken the deps for the old version of bar. And you can't scratch test the new version of bar with the released version of libfoo. You'd have to scratch test the set or you don't get value from the scratch. -jef From jonathan.underwood at gmail.com Sun Feb 19 00:41:57 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 19 Feb 2006 00:41:57 +0000 Subject: Please help comment on hdf/netcdf compatability In-Reply-To: <20060218120134.GF2977@free.fr> References: <43E3C33D.3030403@cora.nwra.com> <20060218120134.GF2977@free.fr> Message-ID: <645d17210602181641g3987a2acg@mail.gmail.com> On 18/02/06, Patrice Dumas wrote: > note2: I made autoconf macros for hdf and netcdf detection, I personally > think that they are better than the one in gdl, as they search in more > places, and try to find the right version for the netcdf api. But they are > much more complicated and would require a change in the configure.in, > so... (I think i allready did my advertising, but I don't abandon so > easily now that I know that these macros could really be usefull for > gdl...). Have you tried getting these incoorporated upstream? From jwboyer at jdub.homelinux.org Sun Feb 19 00:46:28 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 18 Feb 2006 19:46:28 -0500 Subject: Packaging review guidelines clarification In-Reply-To: <1140285276.9486.15.camel@localhost.localdomain> References: <1140066142.3004.297.camel@ernie> <3237e4410602160216k5821a2fapd16562e9b792062c@mail.gmail.com> <1140085756.8444.14.camel@laurel.intra.city-fan.org> <3237e4410602160420t7c8ffc8fta0546df263bd2661@mail.gmail.com> <1140098910.8444.21.camel@laurel.intra.city-fan.org> <604aa7910602160725i66b0ae16s17a643839214e91b@mail.gmail.com> <19090.129.42.161.36.1140100224.squirrel@jdub.homelinux.org> <1140108327.5699.0.camel@rousalka.dyndns.org> <1140109955.2904.28.camel@localhost.localdomain> <1140274799.15568.10.camel@yoda.jdub.homelinux.org> <1140285276.9486.15.camel@localhost.localdomain> Message-ID: <1140309988.15568.30.camel@yoda.jdub.homelinux.org> On Sat, 2006-02-18 at 12:54 -0500, Dan Williams wrote: > On Sat, 2006-02-18 at 09:59 -0500, Josh Boyer wrote: > > > > Ok, I did some digging in the plague code this morning. It seems that > > plague 0.4 already has support built into it for a testing/scratch repo. > > Namely, if the target is said repo, it changes the status of the build > > job to done after building and skips the addtorepo step. (Unless I read > > some code wrong). > > (note that I renamed "scratch" to "testing" to reduce confusion. If > "scratch" is still in the 0.5 code I should fix that.) I noticed that. But I personally think it's more confusing. We aren't looking for a testing repo, we're looking for a scratch repo. A testing repo implies some policy, etc to go along with it. (Two minutes pass after reading some more of this thread.) See, I told you ;) > No, you read the code correctly. However, there's a big gaping hole for > scratch/testing builds; dependencies. Since the packages don't get > added to the distro repository or the buildsystem repository, you can't > build a testing package B that depends on a testing package A. You can > only build single packages into a testing repo. Oversight on my part > perhaps. We figured this out right before we were going to enable > testing targets last year. > > To fix this, we have to make testing targets full-fledged repositories > in their own right, that inherit from the normal distro repo too, and > then periodically purge packages over a day or two old. Ok, that makes sense. > > So... it's more a question of can we enable this on the FE buildsys and > > if so what method should we use? Some options: > > > > 1) > > > > Plague has the ability to allow building from an SRPM itself. We could > > allow folks to specify the SRPM for a package which will then be > > uploaded and built on the scratch repo. I believe this option is > > disabled at the moment on the server config side of things. > > Correct, you can either do SRPM _or_ CVS builds, but not both. In the > context of testing targets/repos, perhaps SRPMs would be a good thing. > But I'm not entirely sure of that. At least if all the files are in > CVS, there's a slightly higher accountability so that people don't just > shove crap or any old SRPM through the buildsys. It's more "open" and > transparent what people are trying to build from a security perspective > too. I guess I'd discourage SRPM building for these reasons in the > context of Fedora. > > Remember, you can create arbitrary tags and branches with package CVS, > and the buildsys doesn't really care what tag the package comes from as > long as the tag exists. Yes, and I agree with this. I forgot about the arbitrary tags, which would make some things easier. > > Doing this would help people ensure that new packages build correctly on > > all arches, etc before actually being imported into CVS. The idea is > > that it'll catch some things that a simple review wouldn't and help > > fixup the package that much earlier. > > You bring up a good point here. But how do we gate this? We probably > shouldn't be handing out buildsys accounts some new person 5 minutes > after they submit a package just so they can build some random SRPM they > found online. My original thinking was that only those with cvsextras access would be able to do this so the "new person" part wouldn't apply. There would already be some level of trust. But I've since talked myself out of this, since it just complicates things. > > 2) > > > > Enable the scratch repo and add a 'make scratch' target to the > > makefiles. Same advantages as above, just that it requires the package > > to be in CVS already. > > I think this is the more likely scenario. We fix the testing/scratch > targets by making them real targets that just don't get their packages > moved over to the "official" repository ever. We add cronjobs to kill > packages in the testing targets after two days. Yep, exactly. > > > The issues with both of these options are: how do we make sure scratch > > builds aren't holding up real builds (or if that will even be a problem) > > and if option 1) is used, are there security issues at all with allowing > > people to upload SRPMs directly. > > Priorities are going to take a little work in the buildsys. Currently > every job has the same importance, and testing targets shouldn't. More than just the code is the policy... unless we just imply priority based on target. Trying to do something where package authors attempt to set priority seems overkill and complicated. If we keep it simple and base priority on the target (e.g. FC-4 over testing/scratch) I think it'll work out well. > So I propose that at some point in March we do a major buildsys upgrade > to grab plague 0.5 and give us: > > 1) depsolving (done) > 2) real testing targets (needs a bit more work) > 3) job priorities (to be done) > 4) build preference (to be done) That sounds like a plan to me. We can take some of this to the -buildsys list after some more discussion I think. josh From bugzilla at redhat.com Sun Feb 19 01:41:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 20:41:52 -0500 Subject: [Bug 178922] Review Request: asterisk - The Open Source PBX In-Reply-To: Message-ID: <200602190141.k1J1fqae018551@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: asterisk - The Open Source PBX https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178922 rmo at sunnmore.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rmo at sunnmore.net ------- Additional Comments From rmo at sunnmore.net 2006-02-18 20:41 EST ------- chan_skinny listen by default on port 2000/tcp, and most people would never use the skinny protocol with asterisk. Asterisk should either not load this module, not listen on the port or put chan_skinny in its own package. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From tibbs at math.uh.edu Sun Feb 19 04:02:11 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 18 Feb 2006 22:02:11 -0600 Subject: %{SOURCEn} versus $RPM_SOURCE_DIR Message-ID: Say a package has a source file: Source1: blah Is there a preference between referring to %{SOURCE1} and using $RPM_SOURCE_DIR/blah? - J< From ivazquez at ivazquez.net Sun Feb 19 04:14:52 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 18 Feb 2006 23:14:52 -0500 Subject: %{SOURCEn} versus $RPM_SOURCE_DIR In-Reply-To: References: Message-ID: <1140322492.2714.8.camel@ignacio.lan> On Sat, 2006-02-18 at 22:02 -0600, Jason L Tibbitts III wrote: > Say a package has a source file: > > Source1: blah > > Is there a preference between referring to %{SOURCE1} and using > $RPM_SOURCE_DIR/blah? %{SOURCE1} will always refer to Source1 regardless of what "blah" may be. It's also more concise. -- 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 bugzilla at redhat.com Sun Feb 19 04:21:04 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 18 Feb 2006 23:21:04 -0500 Subject: [Bug 181801] Review Request: zeroinstall-injector In-Reply-To: Message-ID: <200602190421.k1J4L4Ze005663@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: zeroinstall-injector https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181801 ------- Additional Comments From michel.salim at gmail.com 2006-02-18 23:20 EST ------- The upstream source is self-signed with GPG, and there's no unsigned tarball I can link to for the Source field. CFLAGS removed and mandir changed to use %{_mandir}, thanks. http://hircus.org/fedora/zeroinstall-injector/zeroinstall-injector.spec http://hircus.org/fedora/zeroinstall-injector/zeroinstall-injector-0.18-2.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rc040203 at freenet.de Sun Feb 19 04:36:45 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 19 Feb 2006 05:36:45 +0100 Subject: Again: EOL Policy for Fedora Extras In-Reply-To: <20060218205913.2bc8fa29.bugs.michael@gmx.net> References: <1140287414.6634.70.camel@localhost.localdomain> <20060218205913.2bc8fa29.bugs.michael@gmx.net> Message-ID: <1140323806.21764.479.camel@mccallum.corsepiu.local> On Sat, 2006-02-18 at 20:59 +0100, Michael Schwendt wrote: > On Sat, 18 Feb 2006 19:30:14 +0100, Thorsten Leemhuis wrote: > > > We still have no defined EOL Policy for Fedora Extras -- there were some > > ideas and concepts floating around, but no real policy came out of it so > > far. I'd really like to get this solved somehow soon. That's why I'm > > writing this mail. > > Long mail, short story: Do we agree on common goals with regard to FE? > I'm not sure we do. IMO, there is no doubt: No, we don't, we can't and there isn't any need to do so - Community projects happen or starve. > Instead of discussing EOL policy bottom-up for FE3, > how about we discuss in general _what_ we at Fedora Extras _try_ to offer? Quite simple: That what happens to happen and what people are contributing. > > mailinglist-archives: > > > > > > - Now that FC3 was transfered to Legacy we need some kind of policy for > > FE3, too -- users want to know if FE3 is still completely supported. > > Reason: package maintainers often move on to the current if not latest > release of FC and don't run an older FC anymore. So they don't do any > run-time evaluation of upgrades/updates anymore. Unless they are the "if > it builds, push it" type of packagers, they don't release any upgrades > which they don't use regularly themselves. Further, the older a release of > FC gets, the more difficult security related version upgrades become, if > they require upgraded dependencies. This also leads to coordination > and compatibility requirements between FE and Fedora Legacy. Right, but this applies to all releases of FE, regardless of whether an FE release is officially announced "dead" or "alive". > > - We cannot offer an old FE which is out-of-date or possible insecure at > > least partially. Nothing prevents us from doing so and in fact nothing will prevent it from happening. It's a natural life cycle, with all stages of a life cycle in place: Infancy, youth, maturity, age and death. > Which means, there's no need to shut down a repo, but the project ought to > announce the "updates support level users can expect" compared with Extras > for the current release of FC. Agreed - This is how I would like to see "EOL'ing FE" to be interpreted. > > And some concrete plans: > > > - shove FE3 into a Maintenance state for now -- no new packages, no big > > updates but still updates in case of security problems > > What is "concrete" about this suggestion? Agreed, this is what will happen naturally, no matter who _claims_ to be doing the work. Have a look into current FE3 and FE4, and you'll notice that this already happens, even on "live FE". > > - we create an extras legacy team that takes over FE3 when FC3 is > > transfered to legacy. No community developer interest, no show. > +1 This is the only realistic suggestion. +1, if this legacy team is works inside of FE's infrastructure and collaborates with FE upstream maintainers. -1, if this legacy team works outside of FE. My proposal: Establish a legacy team inside of FE with "card blanche privileges" on FE < FC(EOL), whose task it would be to process PRs on old FE's. Then, maintainers, who are aren't interested or unable to fix PRs on old FEs, could assign such PRs to them, instead of closing them as "won't fix" as they can't avoid having to do now. Ralf From dennis at ausil.us Sun Feb 19 05:05:38 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 18 Feb 2006 23:05:38 -0600 Subject: Again: EOL Policy for Fedora Extras In-Reply-To: <1140287414.6634.70.camel@localhost.localdomain> References: <1140287414.6634.70.camel@localhost.localdomain> Message-ID: <200602182305.52470.dennis@ausil.us> Once upon a time Saturday 18 February 2006 12:30 pm, Thorsten Leemhuis wrote: > Hi all! > > > We still have no defined EOL Policy for Fedora Extras -- there were some > ideas and concepts floating around, but no real policy came out of it so > far. I'd really like to get this solved somehow soon. That's why I'm > writing this mail. I think that extras should follow Core, well i really think there should be no core and extras there should be Fedora, which is fully supported by the community. Kind of like what Warren Suggested as his dream. > - keep FE3 fully alive for RHEL4/CentOS and/or Aurora; some people that > suggested this even want to take over the complete maintainer-ship for > all packages in FE3 > ( > https://www.redhat.com/archives/fedora-extras-list/2006-February/msg00652.h >tml ) > > Well, I can understand this idea. But there are some things that I don't > like: > > -- Maintaining FE3 is a job that needs more then one packager. Two or > three is a minimum IMHO and AFAICS. > I know i cant do it by myself. But i am willing to stand up and say hey I want this to work. What i would suggest is that once core move to legacy extras follows suit. What will this mean. no big updates Just security fixes and major bug fixes, though there shouldnt be many of the latter. I maintain 3 FC3 servers and have no plans to update the os any time soon. how would i see it working? by using the existing infrastructure. package maintainers who want to still maintain there packages should be allowed to. What is hardest is know who is and who is not going to maintain there packages. we have a couple of ways that we can know this. but it all boils down to we need a database that has the information in it. how do we get it? 1) when submitting packages the maintainer states i will support development and current or i will support only current or development and 2 releases or I will support indefinetly. 2) When a package maintainer decides he no longer wishes to maintain a package for a release he/she fills out a form updating the info so that someone wanting to jump in can. One thing i realise now is that some people may not want to or have the resources to support the development branch. Its a huge moving target. not only do you get frequent changes in extras you get it in core also. and some people just cant or dont want to keep up. we kinda assume that they will. So im going to step up and say i want in, but it will take more than me. The more people that continue to maintain there packages the better. If people are not going to maintain them then step up and say so. Lets make this work for all. I see that a clear time to say ok thats all she wrote in this book in when Legacy stops supporting core. based on stated legacy policy of 1-2-3 out fc3 would live until legacy takes over from fc7 if i read it correctly. the one thing that bothers me about legacy is that it supports only x86 no x86_64 and no ppc I personally use all those arches in addition to sparc. So will anybody else help? -- Dennis Gilmore, RHCE http://www.ausil.us Proud Australian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From rc040203 at freenet.de Sun Feb 19 04:47:24 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 19 Feb 2006 05:47:24 +0100 Subject: Do we want extras/testing/{4, 5} repos (was Re: Packaging review guidelines clarification) In-Reply-To: <1140306894.11069.5.camel@localhost.localdomain> References: <1140066142.3004.297.camel@ernie> <604aa7910602160725i66b0ae16s17a643839214e91b@mail.gmail.com> <19090.129.42.161.36.1140100224.squirrel@jdub.homelinux.org> <1140108327.5699.0.camel@rousalka.dyndns.org> <1140109955.2904.28.camel@localhost.localdomain> <1140274799.15568.10.camel@yoda.jdub.homelinux.org> <1140285276.9486.15.camel@localhost.localdomain> <1140288314.6634.85.camel@localhost.localdomain> <1140288728.19313.31.camel@rousalka.dyndns.org> <1140289472.6634.91.camel@localhost.localdomain> <604aa7910602181128y6cb2ea28o82fb5c6d88db8051@mail.gmail.com> <1140306894.11069.5.camel@localhost.localdomain> Message-ID: <1140324445.21764.488.camel@mccallum.corsepiu.local> On Sat, 2006-02-18 at 18:54 -0500, Dan Williams wrote: > On Sat, 2006-02-18 at 14:28 -0500, Jeff Spaleta wrote: > > On 2/18/06, Thorsten Leemhuis wrote: > > > I know, it doesn't work to well with update-testing in core -- but it's > > > IMHO better then no testing at all. > > > > If this policy goes in I'd want an established loophole that allows > > hot fix updates to fix brokenness that made it through the "testing" > > timeout without comment and not just security updates. > > So this is appearing to get more and more complicated. I'm not sure > adding more process onto this is the best thing; more process is (a) > confusing and (b) a damper on participation. I agree with your concerns and do not see much benefits. Why can't we have a maintainer must give explicit clearance to release a successfully built package policy instead of automatically releasing a package? That would mean, a successfully built package would end up in a publically accessible repo (or directory), but maintainers would have to explicitly give clearance for a package to be pushed to the official FE repos. > Though we don't want crap > packages getting through, is the situation all that bad now? Not "that bad", but definitely improvable. Ralf From notting at redhat.com Sun Feb 19 05:22:37 2006 From: notting at redhat.com (Bill Nottingham) Date: Sun, 19 Feb 2006 00:22:37 -0500 Subject: Blend Fedora Objectives (was Re: Again: EOL Policy for Fedora Extras) In-Reply-To: <1140300642.19313.68.camel@rousalka.dyndns.org> References: <1140287414.6634.70.camel@localhost.localdomain> <1140288533.19313.27.camel@rousalka.dyndns.org> <43F7876E.7050501@redhat.com> <1140300642.19313.68.camel@rousalka.dyndns.org> Message-ID: <20060219052237.GD13300@devserv.devel.redhat.com> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > I say create a FEL team. It will fly or sink. Either way users and > maintainers will know what to expect. Sometimes life is tough. That's no > reason to play the ostrich. I agree; right now, there is *nowhere* for people to know how long FEx will have updates pushed, and there are various issues that simply cause confusion: - divergent policies betwee Core and Extras - if it's at maintainer discretion, it's divergent policies *within* Extras Eventually, I think Core and Extras need to converge, and things like legacy support (or however you want to term it) would need to be part of that. Bill From bugzilla at redhat.com Sun Feb 19 05:36:17 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 00:36:17 -0500 Subject: [Bug 176532] Review Request: TurboGears: Back-to-front web development in Python In-Reply-To: Message-ID: <200602190536.k1J5aH9O015115@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: TurboGears: Back-to-front web development in Python https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176532 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |jpmahowald at gmail.com OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-19 00:36 EST ------- Builds now. Not running without python-setuptools, another Requires perhaps. Otherwise I get on FC4: $ tg-admin Traceback (most recent call last): File "/usr/bin/tg-admin", line 5, in ? from pkg_resources import load_entry_point ImportError: No module named pkg_resources rpmlint has a bunch of empty file and permission warnings that can be ignored: rpmlint of TurboGears-0.8a5-1.fc4.noarch.rpm:E: TurboGears zero-length /usr/lib/python2.4/site-packages/turbogears/quickstart/projectname/static/javascript/empty E: TurboGears zero-length /usr/lib/python2.4/site-packages/TurboGears-0.8a5-py2.4.egg-info/not-zip-safe E: TurboGears zero-length /usr/lib/python2.4/site-packages/turbogears/quickstart/projectname/static/css/empty E: TurboGears zero-length /usr/lib/python2.4/site-packages/turbogears/quickstart/projectname/static/images/empty E: TurboGears non-executable-script /usr/lib/python2.4/site-packages/turbogears/quickstart/project-start.py.source 0644 E: TurboGears zero-length /usr/lib/python2.4/site-packages/turbogears/quickstart/projectname/sqlobject-history/empty - package meets naming guidelines - package meets packaging guidelines - license (MIT) OK, text in %doc, matches source - spec file legible, in am. english - source matches upstream - package compiles on FC4 i386 - no missing BR (however still needs python-setuptools to run tg-admin) - no unnecessary BR - no locales - not relocatable - owns all directories that it creates - no duplicate files - permissions ok - %clean ok - macro use consistent - code, not content - no need for -docs - nothing in %doc affects runtime - no need for .desktop file Can create a project and see the test page. Only remaining blocker is the setuptools requirement. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 19 05:40:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 00:40:20 -0500 Subject: [Bug 180430] Review Request: Tong - a game of skill In-Reply-To: Message-ID: <200602190540.k1J5eKsR015750@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Tong - a game of skill https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180430 ------- Additional Comments From tibbs at math.uh.edu 2006-02-19 00:40 EST ------- The source grabbed from http://www.nongnu.org/tong/tong-1.0.tar.gz doesn't match what's in your SRPM. Did upstream change their tarball recently? rpmlint says: E: tong-data only-non-binary-in-usr-lib W: tong-data no-documentation The stuff that tong-data installs really should go into /usr/share and the binary should go into /usr/bin. I know the program is broken in that it requires the media directory to be in the same place as the binary, but honestly I think it's simpler to apply a tiny patch to chdir("/usr/share/tong") at the start of main() than to hack around the deficiency of the program. A five-minute hack is at: http://www.math.uh.edu/~tibbs/rpms/tong/tong.spec http://www.math.uh.edu/~tibbs/rpms/tong/tong-1.0-3.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From pertusus at free.fr Sat Feb 18 09:39:01 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 18 Feb 2006 10:39:01 +0100 Subject: static libs ... again In-Reply-To: <1140252679.21695.8.camel@localhost> References: <43F6123D.2060900@ieee.org> <20060217223350.GC2977@free.fr> <604aa7910602171451o6fb7fcfm7630ee47715b5a8e@mail.gmail.com> <20060217230617.GE2977@free.fr> <1140252679.21695.8.camel@localhost> Message-ID: <20060218093901.GA2977@free.fr> > I really don't buy this argument. If you're really wanting to move a > binary from one system to another, you can just as easily move the > libraries it depends on as well. Use LD_LIBRARY_PATH. I did this on > several occasions years ago, to run a binary compiled on Red Hat on a > Debian system. Of course this is possible, but much less convenient than just copying the executable. -- Pat From pertusus at free.fr Sat Feb 18 10:00:52 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 18 Feb 2006 11:00:52 +0100 Subject: static libs ... again In-Reply-To: <43F6D00E.5020905@redhat.com> References: <43F6123D.2060900@ieee.org> <20060217223350.GC2977@free.fr> <43F6D00E.5020905@redhat.com> Message-ID: <20060218100052.GB2977@free.fr> > IMHO, if you are building your own numerical crunching apps, then you > probably would be better off controlling all aspects of building each > static portion of it. This means writing your own scripts and tuning > compile flags of portions of the app to maximize performance. This may > also mean applying your own patches that may be unsuitable for a more > general purpose distribution. This is not my use. I just do numerical models, and I don't care that much about speed. But I need some functions provided by libraries (lapack for linear algebra, fftw for fourier transforms, and general purpose math libs like gsl or the cernlib for other utilities). I don't want to customize them, just use them. > If you rely on a distribution's static libraries, then there is no > guarantee in the future that those static libs will remain unchanged in > API, so if you ever need to rebuild your app with a tiny change you > could be affected by far more than the change that you expected. Indeed in case of heavy customization having static libs from fedora may be unneeded, as you said, if a given version is needed or static libs are tweaked. But this is not the use I have for math libs. All in all this is another case than mine (not that it doesn't exist, though). In my case I can rebuild when there is an api change, I don't want to use a given version, I really don't want to mess with those libs internals nor compile settings. But I want to generate an executable that I can run on any linux distribution and rerun later, without the burden to have to bundle shared libs with my executable. I understand that my need may be particular. It is possible that the benefit from being able to have a portable executable statically compiled against libs is outweight by the cost in term of space wasted by static libraries. But if static libs are excluded it must be for that reason, not because static libs are intrinsically bad, as I hope my personnal use show that it is untrue. And not that I don't advocate to keep all the static libs, but those that can be used in contexts where security is not an issue. This includes low level libraries (glibc, libstdc++...) math libs, plotting libs, and maybe others, but no network libs or pure desktop stuff. -- Pat From rc040203 at freenet.de Sun Feb 19 06:33:14 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 19 Feb 2006 07:33:14 +0100 Subject: static libs ... again In-Reply-To: <20060218093901.GA2977@free.fr> References: <43F6123D.2060900@ieee.org> <20060217223350.GC2977@free.fr> <604aa7910602171451o6fb7fcfm7630ee47715b5a8e@mail.gmail.com> <20060217230617.GE2977@free.fr> <1140252679.21695.8.camel@localhost> <20060218093901.GA2977@free.fr> Message-ID: <1140330794.21764.498.camel@mccallum.corsepiu.local> On Sat, 2006-02-18 at 10:39 +0100, Patrice Dumas wrote: > > I really don't buy this argument. If you're really wanting to move a > > binary from one system to another, you can just as easily move the > > libraries it depends on as well. Use LD_LIBRARY_PATH. If the application and the libraries it depends upon are implemented properly, there there even isn't a need to do so. Then, just tar'ing the apps and their run-time libs should work pretty smoothly. If you want to do it in perfectionistic clean way, package them into rpms (This is what I occasionally do). Ralf From fedora at leemhuis.info Sun Feb 19 06:57:27 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 19 Feb 2006 07:57:27 +0100 Subject: Do we want extras/testing/{4, 5} repos (was Re: Packaging review guidelines clarification) In-Reply-To: <1140324445.21764.488.camel@mccallum.corsepiu.local> References: <1140066142.3004.297.camel@ernie> <604aa7910602160725i66b0ae16s17a643839214e91b@mail.gmail.com> <19090.129.42.161.36.1140100224.squirrel@jdub.homelinux.org> <1140108327.5699.0.camel@rousalka.dyndns.org> <1140109955.2904.28.camel@localhost.localdomain> <1140274799.15568.10.camel@yoda.jdub.homelinux.org> <1140285276.9486.15.camel@localhost.localdomain> <1140288314.6634.85.camel@localhost.localdomain> <1140288728.19313.31.camel@rousalka.dyndns.org> <1140289472.6634.91.camel@localhost.localdomain> <604aa7910602181128y6cb2ea28o82fb5c6d88db8051@mail.gmail.com> <1140306894.11069.5.camel@localhost.localdomain> <1140324445.21764.488.camel@mccallum.corsepiu.local> Message-ID: <1140332247.2904.15.camel@localhost.localdomain> Am Sonntag, den 19.02.2006, 05:47 +0100 schrieb Ralf Corsepius: > On Sat, 2006-02-18 at 18:54 -0500, Dan Williams wrote: > > On Sat, 2006-02-18 at 14:28 -0500, Jeff Spaleta wrote: > > > On 2/18/06, Thorsten Leemhuis wrote: > > > > I know, it doesn't work to well with update-testing in core -- but it's > > > > IMHO better then no testing at all. > > > > > > If this policy goes in I'd want an established loophole that allows > > > hot fix updates to fix brokenness that made it through the "testing" > > > timeout without comment and not just security updates. > > > > So this is appearing to get more and more complicated. I'm not sure > > adding more process onto this is the best thing; more process is (a) > > confusing and (b) a damper on participation. > I agree with your concerns and do not see much benefits. > > Why can't we have a maintainer must give explicit clearance to release a > successfully built package policy instead of automatically releasing a > package? > > That would mean, a successfully built package would end up in a > publically accessible repo (or directory), but maintainers would have to > explicitly give clearance for a package to be pushed to the official FE > repos. We did this in fedora.us -- it worked, but didn't worked too well IMHO. Some packages stayed in the "pending" repo for weeks or even months because nobody checked them. This is probably even more process then a testing-repo and adds more bureaucracy for the maintainer; so it probably (a) confusing and (b) a damper on participation. A defined testing repo with a automatic move to the public trees could have the benefit that (a) multiple people can check the package easily (just enable extras-testing, they get the packages with the next yum update), (b) a package might be checked on multiple archs this way and (c) it will be pushed even if the maintainer does nothing. > > Though we don't want crap > > packages getting through, is the situation all that bad now? > Not "that bad", but definitely improvable. Agreed. -- Thorsten Leemhuis From fedora at leemhuis.info Sun Feb 19 07:04:10 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 19 Feb 2006 08:04:10 +0100 Subject: Blend Fedora Objectives (was Re: Again: EOL Policy for Fedora Extras) In-Reply-To: <1140300642.19313.68.camel@rousalka.dyndns.org> References: <1140287414.6634.70.camel@localhost.localdomain> <1140288533.19313.27.camel@rousalka.dyndns.org> <43F7876E.7050501@redhat.com> <1140300642.19313.68.camel@rousalka.dyndns.org> Message-ID: <1140332650.2904.20.camel@localhost.localdomain> Am Samstag, den 18.02.2006, 23:10 +0100 schrieb Nicolas Mailhot: > Le samedi 18 f?vrier 2006 ? 15:45 -0500, Warren Togami a ?crit : > > > > 3. we should let FEL define its own policies. Today we don't know the > > > number of people interested in FEL and their level of involvement. It's > > > useless to dictate rules to a team which is not assembled yet. People > > > who want to do it should first go to 1. and create some form of entity > > > > > > > I think it is entirely broken to "hand over" the entire Extras and > > expect some other volunteer to take care of it. This will create a > > guaranteed failure situation for a community group because the set of > > packages is potentially infinite and the natural problem that security > > is difficult to maintain with only volunteers (even Debian struggles). > > It is a *fantasy* for maintainers to expect they hand over > > responsibility to some theoretical entity and expect it to actually work. > > The fantasy is to continue not acknowledging the problem. I'm very > sceptical about the viability of a FEL. I write so openly. If we create > one it will suck the first releases just like it did for FCL (and this > is the optimistic scenario). [...] And then we have the same problem that Fedora Legacy currently has taken to Fedora Extras (Legacy) -- it works, but it has a bad (or "not the best") reputation because it sucked in the beginning. Do we want that? I would prefer a EOL call over a badly working Fedora Extras Legacy. CU thl -- Thorsten Leemhuis From fedora at leemhuis.info Sun Feb 19 07:08:01 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 19 Feb 2006 08:08:01 +0100 Subject: Packages in CVS with no entry in the owners.list (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <43F7967B.5050204@ieee.org> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140262149.2904.90.camel@localhost.localdomain> <43F7967B.5050204@ieee.org> Message-ID: <1140332881.2904.24.camel@localhost.localdomain> Am Samstag, den 18.02.2006, 15:49 -0600 schrieb Quentin Spencer: > Thorsten Leemhuis wrote: > >Am Freitag, den 17.02.2006, 20:51 +0100 schrieb Thorsten Leemhuis: > >>Am Montag, den 13.02.2006, 18:22 +0100 schrieb Thorsten Leemhuis: > >[...] > >>The script found the following packages in extras/development for which > >>no entry in the owners.list could be found: fftw3, umfpack, > >>perl-Gtk2-GladeXML, perl-Imager, perl-Gnome2-Canvas, html-xml-utils, > >>dia, libdsk, libspectrum, lib765 > >I looked a bit closer at this list and that one maintained from > >Christian and his scripts in the wiki at > >http://fedoraproject.org/wiki/Extras/PackageStatus#head-7ad8ccfb3d8a18c22476e20d7ddaab55b4b9cfe1 > >These are in the extras/devel but have no entry in owners.list > >- Quentin Spencer : umfpack > > umfpack has been obsoleted by ufsparse (it is a subset of the libraries > provided in ufsparse). It was removed from CVS a long time ago, but > there might still be some packages in the repos, which can be removed. Quentin, then please put the names of these packages in the section "Remove Request" on: http://www.fedoraproject.org/wiki/Extras/FC4Status http://www.fedoraproject.org/wiki/Extras/FC5Status tia! -- Thorsten Leemhuis From rc040203 at freenet.de Sun Feb 19 07:25:32 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 19 Feb 2006 08:25:32 +0100 Subject: Do we want extras/testing/{4, 5} repos (was Re: Packaging review guidelines clarification) In-Reply-To: <1140332247.2904.15.camel@localhost.localdomain> References: <1140066142.3004.297.camel@ernie> <604aa7910602160725i66b0ae16s17a643839214e91b@mail.gmail.com> <19090.129.42.161.36.1140100224.squirrel@jdub.homelinux.org> <1140108327.5699.0.camel@rousalka.dyndns.org> <1140109955.2904.28.camel@localhost.localdomain> <1140274799.15568.10.camel@yoda.jdub.homelinux.org> <1140285276.9486.15.camel@localhost.localdomain> <1140288314.6634.85.camel@localhost.localdomain> <1140288728.19313.31.camel@rousalka.dyndns.org> <1140289472.6634.91.camel@localhost.localdomain> <604aa7910602181128y6cb2ea28o82fb5c6d88db8051@mail.gmail.com> <1140306894.11069.5.camel@localhost.localdomain> <1140324445.21764.488.camel@mccallum.corsepiu.local> <1140332247.2904.15.camel@localhost.localdomain> Message-ID: <1140333932.21764.528.camel@mccallum.corsepiu.local> On Sun, 2006-02-19 at 07:57 +0100, Thorsten Leemhuis wrote: > Am Sonntag, den 19.02.2006, 05:47 +0100 schrieb Ralf Corsepius: > > On Sat, 2006-02-18 at 18:54 -0500, Dan Williams wrote: > > > On Sat, 2006-02-18 at 14:28 -0500, Jeff Spaleta wrote: > > > > On 2/18/06, Thorsten Leemhuis wrote: > > > > > I know, it doesn't work to well with update-testing in core -- but it's > > > > > IMHO better then no testing at all. > > > > > > > > If this policy goes in I'd want an established loophole that allows > > > > hot fix updates to fix brokenness that made it through the "testing" > > > > timeout without comment and not just security updates. > > > > > > So this is appearing to get more and more complicated. I'm not sure > > > adding more process onto this is the best thing; more process is (a) > > > confusing and (b) a damper on participation. > > I agree with your concerns and do not see much benefits. > > > > Why can't we have a maintainer must give explicit clearance to release a > > successfully built package policy instead of automatically releasing a > > package? > > > > That would mean, a successfully built package would end up in a > > publically accessible repo (or directory), but maintainers would have to > > explicitly give clearance for a package to be pushed to the official FE > > repos. > > We did this in fedora.us -- it worked, but didn't worked too well IMHO. You seem to forget about fedora.us's underdeveloped infrastructure. > Some packages stayed in the "pending" repo for weeks or even months > because nobody checked them. This is probably even more process then a > testing-repo and adds more bureaucracy for the maintainer; so it > probably (a) confusing and (b) a damper on participation. > > A defined testing repo with a automatic move to the public trees could > have the benefit that (a) multiple people can check the package easily > (just enable extras-testing, they get the packages with the next yum > update), (b) a package might be checked on multiple archs this way and > (c) it will be pushed even if the maintainer does nothing. If don't see much sense in this and don't see any need for it. What I sense as missing is: * Maintainers currently have no means to withdraw a miss-built package, even in obvious cases (E.g. package completed building successfully, but a configure check for an optional feature had failed, because another package had changed). * Maintainers have no means to provide "packages for testing" to individuals who reported a bug on their particular situation. Maintainers have to resort to shipping such testing packages from their private sites, and ... thereby don't have any means to provide binaries for archs they don't have access too. * Maintainers have no means to test building packages on archs they don't have access to. * In most cases, "testing" packages will not be connected to other packages, but will be try-n-error packages addressing issues against packages in FE(released). Setting up a testing _repo_ therefore is highly useless, because it would contain functionally broken packages. If we had a "pending" directory (no repodata), maintainers could initiate builds, check the built packages [1], direct individuals to manually downloading this package and to try a particular change they have applied for this built. Ralf [1] A problem I am frequently facing is: Buildsystem reported a successful built, but I didn't have any chance to look into the ppc-rpm before it has been released. From wtogami at redhat.com Sun Feb 19 07:42:59 2006 From: wtogami at redhat.com (Warren Togami) Date: Sun, 19 Feb 2006 02:42:59 -0500 Subject: Blend Fedora Objectives (was Re: Again: EOL Policy for Fedora Extras) In-Reply-To: <1140332650.2904.20.camel@localhost.localdomain> References: <1140287414.6634.70.camel@localhost.localdomain> <1140288533.19313.27.camel@rousalka.dyndns.org> <43F7876E.7050501@redhat.com> <1140300642.19313.68.camel@rousalka.dyndns.org> <1140332650.2904.20.camel@localhost.localdomain> Message-ID: <43F82183.4050102@redhat.com> Thorsten Leemhuis wrote: > > And then we have the same problem that Fedora Legacy currently has taken > to Fedora Extras (Legacy) -- it works, but it has a bad (or "not the > best") reputation because it sucked in the beginning. > > Do we want that? I would prefer a EOL call over a badly working Fedora > Extras Legacy. > I don't agree here. We should at least give the community a chance to maintain the collection, and EOL or retirement only happens if the community fails on a particular distribution. I have a feeling that FE3 will continue to have users long after FE4 for various reasons for example. Warren From bugzilla at redhat.com Sun Feb 19 07:43:03 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 02:43:03 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602190743.k1J7h3RK030191@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 wtogami at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wtogami at redhat.com ------- Additional Comments From wtogami at redhat.com 2006-02-19 02:42 EST ------- Maybe do not require a database at all, because the user must configure it anyway after installation? This avoids some needless complication with little benefit of having dependencies that may not actually be needed. MySQL and PostgreSQL are not the only options. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 19 07:48:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 02:48:36 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602190748.k1J7mahU030762@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From wtogami at redhat.com 2006-02-19 02:48 EST ------- NEEDSWORK - Relocatable in this RPM has absolutely no value, because normal users don't have a RPM database. Am I incorrect? - Please add "-q" to the %setup line. - You simply wildcard everything in the %files section. Isn't part of installing this usually modifying one of those files to configure the database and other stuff? Your package will overwrite and blow away manual changes upon every upgrade. There may be other problems... I don't know yet because I haven't tried the software itself. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 19 07:53:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 02:53:35 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602190753.k1J7rZch031256@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From wtogami at redhat.com 2006-02-19 02:53 EST ------- - http://codex.gallery2.org/index.php/Downloads:GHCC Including this in the package might be useful, because default settings of PHP and the environment are not compatible with gallery2. - You should probably change the package Name to "gallery2" because some people might still be using gallery as the 1.x version, and they are very incompatible with each other. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From fedora at leemhuis.info Sun Feb 19 08:08:10 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 19 Feb 2006 09:08:10 +0100 Subject: Blend Fedora Objectives (was Re: Again: EOL Policy for Fedora Extras) In-Reply-To: <43F82183.4050102@redhat.com> References: <1140287414.6634.70.camel@localhost.localdomain> <1140288533.19313.27.camel@rousalka.dyndns.org> <43F7876E.7050501@redhat.com> <1140300642.19313.68.camel@rousalka.dyndns.org> <1140332650.2904.20.camel@localhost.localdomain> <43F82183.4050102@redhat.com> Message-ID: <1140336490.3583.8.camel@localhost.localdomain> Am Sonntag, den 19.02.2006, 02:42 -0500 schrieb Warren Togami: > Thorsten Leemhuis wrote: > > > > And then we have the same problem that Fedora Legacy currently has taken > > to Fedora Extras (Legacy) -- it works, but it has a bad (or "not the > > best") reputation because it sucked in the beginning. > > > > Do we want that? I would prefer a EOL call over a badly working Fedora > > Extras Legacy. > > > > I don't agree here. We should at least give the community a chance to > maintain the collection, and EOL or retirement only happens if the > community fails on a particular distribution. I have a feeling that FE3 > will continue to have users long after FE4 for various reasons for example. I fully agree that we should give the community a chance to maintain the collection. But earlier in this thread I got the impression "start a fedora extras legacy even if it is foreseeable that it will suck and fail" -- I don't like that idea to much. CU thl -- Thorsten Leemhuis From bugzilla at redhat.com Sun Feb 19 08:36:41 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 03:36:41 -0500 Subject: [Bug 181013] Review Request: qgit - a GUI browser for local git repositories In-Reply-To: Message-ID: <200602190836.k1J8af3C005713@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: qgit - a GUI browser for local git repositories https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181013 ------- Additional Comments From dan at danny.cz 2006-02-19 03:36 EST ------- update for final release 1.1 spec Name or Url: http://www.danny.cz/qgit.spec SRPM Name or Url: http://www.danny.cz/qgit-1.1-1.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 19 09:47:00 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 04:47:00 -0500 Subject: [Bug 176532] Review Request: TurboGears: Back-to-front web development in Python In-Reply-To: Message-ID: <200602190947.k1J9l09v026144@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: TurboGears: Back-to-front web development in Python https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176532 ------- Additional Comments From ivazquez at ivazquez.net 2006-02-19 04:46 EST ------- Updated. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From nicolas.mailhot at laposte.net Sun Feb 19 10:05:16 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 19 Feb 2006 11:05:16 +0100 Subject: Blend Fedora Objectives (was Re: Again: EOL Policy for Fedora Extras) In-Reply-To: <1140336490.3583.8.camel@localhost.localdomain> References: <1140287414.6634.70.camel@localhost.localdomain> <1140288533.19313.27.camel@rousalka.dyndns.org> <43F7876E.7050501@redhat.com> <1140300642.19313.68.camel@rousalka.dyndns.org> <1140332650.2904.20.camel@localhost.localdomain> <43F82183.4050102@redhat.com> <1140336490.3583.8.camel@localhost.localdomain> Message-ID: <1140343516.11703.7.camel@rousalka.dyndns.org> Le dimanche 19 f?vrier 2006 ? 09:08 +0100, Thorsten Leemhuis a ?crit : > Am Sonntag, den 19.02.2006, 02:42 -0500 schrieb Warren Togami: > > Thorsten Leemhuis wrote: > > > > > > And then we have the same problem that Fedora Legacy currently has taken > > > to Fedora Extras (Legacy) -- it works, but it has a bad (or "not the > > > best") reputation because it sucked in the beginning. > > > > > > Do we want that? I would prefer a EOL call over a badly working Fedora > > > Extras Legacy. > > > > > > > I don't agree here. We should at least give the community a chance to > > maintain the collection, and EOL or retirement only happens if the > > community fails on a particular distribution. I have a feeling that FE3 > > will continue to have users long after FE4 for various reasons for example. > > I fully agree that we should give the community a chance to maintain the > collection. But earlier in this thread I got the impression "start a > fedora extras legacy even if it is foreseeable that it will suck and > fail" -- I don't like that idea to much. Well, you know even if we had the forethought to prepare this team months ago FEL3 would have sucked. It takes time for a new team to find its marks. We could mitigate this fact by announcing FEL3 is a beta or something like this. The real milestone if we get the ball rolling now is FEL4. Even Red Hat took a few releases to find a new working model after RHL 7.3 -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Sun Feb 19 10:50:31 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 19 Feb 2006 11:50:31 +0100 Subject: Again: EOL Policy for Fedora Extras In-Reply-To: <200602182305.52470.dennis@ausil.us> References: <1140287414.6634.70.camel@localhost.localdomain> <200602182305.52470.dennis@ausil.us> Message-ID: <1140346231.11703.47.camel@rousalka.dyndns.org> Le samedi 18 f?vrier 2006 ? 23:05 -0600, Dennis Gilmore a ?crit : > One thing i realise now is that some people may not want to or have the > resources to support the development branch. Its a huge moving target. not > only do you get frequent changes in extras you get it in core also. and > some people just cant or dont want to keep up. we kinda assume that they > will. I totally agree most maintainers have a range of releases they're prepared to work on, for some this range centers on devel for others on legacy. I thoroughly disagree we should treat all releases the same and let people contribute to whichever random FE release they want to. This is what the kernel team used to do in 2.4+2.5 days, and the result is dispersion of efforts and massive frustration on part of everyone (2.4 contributors complaining core team does not care about them, core team complaining freeloaders want them to review 2.4 stuff and won't help get 2.5 out of the door). Devel should be mandatory for new functionality. If we don't do that we betray Fedora goals, because most contributors will do the current release only. This will mean no one will run/test rawhide and the various FCn+1Tx, leading to a FCn+1 that slips or sucks, and harming the whole project (after a while people won't be contributing to current FC but current FC + a few stabilizing months and so on). Also, devel packaging is when you see rawhide is missing some crucial bits and when you can ask for them to be pulled in. After release it's *too* *late*. RH people have moved to the next release. (this is my main beef with the other external repositories. They all say devel is too much work, and in practical terms their influence with users and upstream is used to focus efforts on FCn-x, diverting efforts that should be used on rawhide) People not interested in devel can join FEL. That means they also have no say in what new features get in FE. We should have three levels of support (more would be nicer for packagers, but do you imagine the level of frustration of users which have to evaluate support on a package per package basis ?) 1. partial maintenance -> devel only or devel+FCn, and only if some needed features are not present in FCn or FCn-1 2. "standard" maintenance -> same as FC, from devel to FCn-1 till devel graduates to FCn+1T2 3. "long-term" maintenance -> for packages that are picked up by FEL at FCn+1T2 time. And FEL should draw a red line after which *no* packages are maintained anymore (iterate if there is the will and resources to create a FEL++ team charged with "extended long term" maintenance) And I absolutely do not mean FEL should be a separate entity with no access to FE ressources. It could be a FE SIG or something else within FE. But there must be some coordinating structure, and package lifetimes should not be decorrelated. Pick up when you want and abandon whenever you feel so is fine and dandy for packagers, but it's also user hell. One big part of distribution work is to make something coherent out of random pieces of software. That includes coherent support durations. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From bugzilla at redhat.com Sun Feb 19 10:47:55 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 05:47:55 -0500 Subject: [Bug 182027] New: Review Request: postgrey Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182027 Summary: Review Request: postgrey Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: rcoker at redhat.com QAContact: fedora-extras-list at redhat.com SRPM Name or Url: http://www.coker.com.au/postgrey/ Description: Postgrey is a Postfix policy server implementing greylisting. When a request for delivery of a mail is received by Postfix via SMTP, the triplet CLIENT_IP / SENDER / RECIPIENT is built. If it is the first time that this triplet is seen, or if the triplet was first seen less than 5 minutes, then the mail gets rejected with a temporary error. Hopefully spammers or viruses will not try again later, as it is however required per RFC. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From nicolas.mailhot at laposte.net Sun Feb 19 10:55:42 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 19 Feb 2006 11:55:42 +0100 Subject: Do we want extras/testing/{4, 5} repos (was Re: Packaging review guidelines clarification) In-Reply-To: <1140306894.11069.5.camel@localhost.localdomain> References: <1140066142.3004.297.camel@ernie> <604aa7910602160725i66b0ae16s17a643839214e91b@mail.gmail.com> <19090.129.42.161.36.1140100224.squirrel@jdub.homelinux.org> <1140108327.5699.0.camel@rousalka.dyndns.org> <1140109955.2904.28.camel@localhost.localdomain> <1140274799.15568.10.camel@yoda.jdub.homelinux.org> <1140285276.9486.15.camel@localhost.localdomain> <1140288314.6634.85.camel@localhost.localdomain> <1140288728.19313.31.camel@rousalka.dyndns.org> <1140289472.6634.91.camel@localhost.localdomain> <604aa7910602181128y6cb2ea28o82fb5c6d88db8051@mail.gmail.com> <1140306894.11069.5.camel@localhost.localdomain> Message-ID: <1140346543.11703.52.camel@rousalka.dyndns.org> Le samedi 18 f?vrier 2006 ? 18:54 -0500, Dan Williams a ?crit : > Again though, I don't think adding more complexity and forking multiple > repos and package sets here is the answer. I guess I view the > scratchpad/testing stuff as more of a ground for making sure your > package compiles on PPC before you do the final build. Specialized testing repositories (like the kernel, netdev, selinux ones on p.r.c work fine). Blanket testing repositories do *not*. People are ready to test bleeding edge, but only bleeding edge in the few parts of the distro they're most interested in and which packagers they trust. (also you'll note none of the given examples are for packages with big dependency trees) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From bugzilla at redhat.com Sun Feb 19 11:36:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 06:36:27 -0500 Subject: [Bug 182027] Review Request: postgrey In-Reply-To: Message-ID: <200602191136.k1JBaRVD007369@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: postgrey https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182027 mfleming+rpm at enlartenment.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|bugzilla-sink at leemhuis.info |mfleming+rpm at enlartenment.co | |m OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From mfleming+rpm at enlartenment.com 2006-02-19 06:36 EST ------- Ah, I was wondering when someone would submit a Postfix policy service :-). I'll give this a spin (I personally use Cami's policyd, more through familiarity than anything else). Small nit - when submitting these packages can the .spec be split out of the source package and get it's own URL in the submission / update? It makes life a little simpler for the reviewer that wants to check from scratch. Cheers. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From roozbeh at farsiweb.info Sun Feb 19 12:30:51 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Sun, 19 Feb 2006 16:00:51 +0330 Subject: Bittorrent license In-Reply-To: <43F62210.9040802@fedoraproject.org> References: <43F62210.9040802@fedoraproject.org> Message-ID: <1140352252.3121.5.camel@tameshk.farsiweb.info> ??? ????? 2006-02-17 ???? 14:20 -0500? Konstantin Ryabitsev ????: > [...] Not that anyone is packaging and selling stuff in > Extras, but it's something to mull over. Well, my company does that. It provides a GNU/Linux distribution based on Fedora Core that also pulls a few things from Extras and Livna. roozbeh From rc040203 at freenet.de Sun Feb 19 12:37:58 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 19 Feb 2006 13:37:58 +0100 Subject: Again: EOL Policy for Fedora Extras In-Reply-To: <1140346231.11703.47.camel@rousalka.dyndns.org> References: <1140287414.6634.70.camel@localhost.localdomain> <200602182305.52470.dennis@ausil.us> <1140346231.11703.47.camel@rousalka.dyndns.org> Message-ID: <1140352678.21764.538.camel@mccallum.corsepiu.local> On Sun, 2006-02-19 at 11:50 +0100, Nicolas Mailhot wrote: > Le samedi 18 f?vrier 2006 ? 23:05 -0600, Dennis Gilmore a ?crit : > And I absolutely do not mean FEL should be a separate entity with no > access to FE ressources. It could be a FE SIG or something else within > FE. But there must be some coordinating structure, and package lifetimes > should not be decorrelated. Pick up when you want and abandon whenever > you feel so is fine and dandy for packagers, but it's also user hell. Why? A user gets what he gets, when it's done - done by others. > One big part of distribution work is to make something coherent out of > random pieces of software. No. All that is required is consistency of a "distribution at a point in time" - With rolling distributions like Fedora, in an ideal world, each point in time should be consistent. > That includes coherent support durations. Why? Technically, nothing prevents you to fix bugs at any point in time for any distribution, as long as the changes are compatible and consistent to the rest. Ralf From bugs.michael at gmx.net Sun Feb 19 12:41:35 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 19 Feb 2006 13:41:35 +0100 Subject: Blend Fedora Objectives (was Re: Again: EOL Policy for Fedora Extras) In-Reply-To: <1140336490.3583.8.camel@localhost.localdomain> References: <1140287414.6634.70.camel@localhost.localdomain> <1140288533.19313.27.camel@rousalka.dyndns.org> <43F7876E.7050501@redhat.com> <1140300642.19313.68.camel@rousalka.dyndns.org> <1140332650.2904.20.camel@localhost.localdomain> <43F82183.4050102@redhat.com> <1140336490.3583.8.camel@localhost.localdomain> Message-ID: <20060219134135.56d988d0.bugs.michael@gmx.net> On Sun, 19 Feb 2006 09:08:10 +0100, Thorsten Leemhuis wrote: > Am Sonntag, den 19.02.2006, 02:42 -0500 schrieb Warren Togami: > > Thorsten Leemhuis wrote: > > > > > > And then we have the same problem that Fedora Legacy currently has taken > > > to Fedora Extras (Legacy) -- it works, but it has a bad (or "not the > > > best") reputation because it sucked in the beginning. > > > > > > Do we want that? I would prefer a EOL call over a badly working Fedora > > > Extras Legacy. > > > > > > > I don't agree here. We should at least give the community a chance to > > maintain the collection, and EOL or retirement only happens if the > > community fails on a particular distribution. I have a feeling that FE3 > > will continue to have users long after FE4 for various reasons for example. > > I fully agree that we should give the community a chance to maintain the > collection. But earlier in this thread I got the impression "start a > fedora extras legacy even if it is foreseeable that it will suck and > fail" -- I don't like that idea to much. It's quite a bit different compared with Fedora Legacy as it's the community already which does [most of] the packaging in Fedora Extras. For FL the start was like "we [Red Hat] stop here, you may continue with these 1600+ packages, using your own infrastructure, your own guidelines, your own resources". At FE, it _could_ be a quickstart for every interested [additional] contributor, who has not signed up before. Essential infrastructure is available. Plus the existing FE packagers, who volunteer to do maintenance for legacy releases. There are only a few difficulties like "how to share bugzilla component ownership among multiple people?" (where for the short term, Cc should suffice) and "whether version upgrades will be done with upgrade paths in mind". From bugs.michael at gmx.net Sun Feb 19 12:41:42 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 19 Feb 2006 13:41:42 +0100 Subject: Again: EOL Policy for Fedora Extras In-Reply-To: <20060218231034.GA10536@free.fr> References: <1140287414.6634.70.camel@localhost.localdomain> <20060218231034.GA10536@free.fr> Message-ID: <20060219134142.704f5872.bugs.michael@gmx.net> On Sun, 19 Feb 2006 00:10:34 +0100, Patrice Dumas wrote: > > - We are a voluntary driven project -- we can't force any packages to > > still maintain FE3 if he has no interest in it. If we try it will fail. > > On the other hand: We are volunteers, and if volunteers want to do > > something, you shouldn't prevent them from doing it -- You should make > > it as easy as possible, otherwise they will feel peed. > > Why not just keep the infrastructure (enabling the fedora legacy repo) and > let everybody do whatever they want? If a maintainer wants to keep a > package alive he keeps it alive, if another only wants to correct security > flaws only he does it. If somebody wants to correct security issues in > other's packages he does it and so on. Only communication is required, Because this is not much different from "Fedora Legacy Team"-style maintenance. It needs coordination. Essentially, you end up with dedicated contributors, who are responsible for a set of packages and who do as much package development as is necessary to not break something during upgrades and to stay compatible/close with the non-legacy packages for current releases of FC/FE. [You won't find many package developers who would backport security fixes. Most would prefer shipping the latest upstream release, even if it is a major version upgrade, which might require upgrades of build requirements.] > then, meaning that a packager could be able to communicate that he stops > maintaining a package. It could involve something similar with the orphan > page. With the orphans it is simply like "no community interest, no package in FE". Mind you, some packages are only in FE because they are build requirements. Further, we already do quite some reviews of packages just to support eachother. Why should a package, which doesn't find a maintainer for several months, be kept in the repository? Do we even know whether anybody uses it? We don't have "potentially orphaned packages" without reason. It's the only way for a packager to drop a package gradually, giving others an early chance to take over package ownership. > And also something like the owners file, but with distribution > versions, such that it is possible to have different maintainer for > different fedora versions. I don't think this would be a good idea, as I see all releases of package "foo" as a family of packages, belonging together. So all package maintainers of "foo" at least ought to receive copies of all bug reports about "foo", regardless of the release version. A vulnerability in an old version could affect the latest version and vice versa. From j.w.r.degoede at hhs.nl Sun Feb 19 13:03:24 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 19 Feb 2006 14:03:24 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1140303160.17151.98.camel@bree.local.net> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <43F632B9.40904@hhs.nl> <1140251657.2904.24.camel@localhost.localdomain> <43F71677.2080506@hhs.nl> <1140266775.2904.149.camel@localhost.localdomain> <43F7207D.3080605@hhs.nl> <1140271503.2904.173.camel@localhost.localdomain> <43F73B0D.4000608@hhs.nl> <1140303160.17151.98.camel@bree.local.net> Message-ID: <43F86C9C.9040301@hhs.nl> Jeremy Katz wrote: > On Sat, 2006-02-18 at 16:19 +0100, Hans de Goede wrote: >> Thats the problem, I don't know how long it takes for the buildsys to >> pick up rawhide changes, so I'm suggesting to use the time of the >> rawhide changelog mail + some extra time , hoping that someone who knows >> the buildsys can tell us what amount of extra time is needed after the >> rawhide changelog mail. > > The changelog mail should be sent at pretty much the same time as the > packages are available for the build system. > > Jeremy > In that case, Thorsten you asked for a time may I suggest to use the time from the changelog mail. Regards, Hans From nicolas.mailhot at laposte.net Sun Feb 19 13:10:45 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 19 Feb 2006 14:10:45 +0100 Subject: Again: EOL Policy for Fedora Extras In-Reply-To: <1140352678.21764.538.camel@mccallum.corsepiu.local> References: <1140287414.6634.70.camel@localhost.localdomain> <200602182305.52470.dennis@ausil.us> <1140346231.11703.47.camel@rousalka.dyndns.org> <1140352678.21764.538.camel@mccallum.corsepiu.local> Message-ID: <1140354645.11703.58.camel@rousalka.dyndns.org> Le dimanche 19 f?vrier 2006 ? 13:37 +0100, Ralf Corsepius a ?crit : > On Sun, 2006-02-19 at 11:50 +0100, Nicolas Mailhot wrote: > > Le samedi 18 f?vrier 2006 ? 23:05 -0600, Dennis Gilmore a ?crit : > > > And I absolutely do not mean FEL should be a separate entity with no > > access to FE ressources. It could be a FE SIG or something else within > > FE. But there must be some coordinating structure, and package lifetimes > > should not be decorrelated. Pick up when you want and abandon whenever > > you feel so is fine and dandy for packagers, but it's also user hell. > Why? A user gets what he gets, when it's done - done by others. Because installing any given linux distribution is an investment by the user. You can tell the user: at date $foo the repo is not maintained anymore. He can plan for it to minimise the EOL pain. This is quite different from "we'll drop maintenance whenever we feel like and we won't maintain repo consistency, sorry if problems happen when you depend on your system and have no time to upgrade it". -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pertusus at free.fr Sun Feb 19 13:10:44 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 19 Feb 2006 14:10:44 +0100 Subject: Again: EOL Policy for Fedora Extras In-Reply-To: <20060219134142.704f5872.bugs.michael@gmx.net> References: <1140287414.6634.70.camel@localhost.localdomain> <20060218231034.GA10536@free.fr> <20060219134142.704f5872.bugs.michael@gmx.net> Message-ID: <20060219131044.GA4058@free.fr> > Because this is not much different from "Fedora Legacy Team"-style > maintenance. It needs coordination. Essentially, you end up with dedicated > contributors, who are responsible for a set of packages and who do as much > package development as is necessary to not break something during upgrades > and to stay compatible/close with the non-legacy packages for current I can't see why there should be more coordination in extras with eol fedora core than with current or devel extras? > > then, meaning that a packager could be able to communicate that he stops > > maintaining a package. It could involve something similar with the orphan > > page. > > With the orphans it is simply like "no community interest, no package in > FE". Mind you, some packages are only in FE because they are build > requirements. Further, we already do quite some reviews of packages just > to support eachother. Why should a package, which doesn't find a > maintainer for several months, be kept in the repository? Do we even know > whether anybody uses it? We don't have "potentially orphaned packages" > without reason. It's the only way for a packager to drop a package > gradually, giving others an early chance to take over package ownership. I was thinking that something similar could be done for fedora extras for eol fedora core versions. I.e. there could be a wiki page where maintainers declare that they are not interested in eol fedora core versions. Potentially if possible and the completely. And the packages could be then removed from the fe corresponding with fc eol. > I don't think this would be a good idea, as I see all releases of package > "foo" as a family of packages, belonging together. So all package > maintainers of "foo" at least ought to receive copies of all bug reports > about "foo", regardless of the release version. A vulnerability in an > old version could affect the latest version and vice versa. Yep, that's true. -- Pat From bugzilla at redhat.com Sun Feb 19 13:12:26 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 08:12:26 -0500 Subject: [Bug 182027] Review Request: postgrey In-Reply-To: Message-ID: <200602191312.k1JDCQ1q018376@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: postgrey https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182027 ------- Additional Comments From mfleming+rpm at enlartenment.com 2006-02-19 08:12 EST ------- NEEDSWORK Review for release 1: * RPM name is OK * Source postgrey-1.24.tar.gz is the same as upstream * This is the latest version * Builds fine in mock (FC4) * File list of postgrey looks OK * Hasn't made my test instance explode. Needs work: * BuildRoot should be %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) (wiki: PackagingGuidelines#BuildRoot) * Spec file: some paths are not replaced with RPM macros (wiki: QAChecklist item 7) - Noticed some uses of %{_var} vs. %{_localstatedir} in there.. * rpmlint of postgrey: rpmlint of postgrey-1.24-1.noarch.rpm E: postgrey zero-length /etc/postgrey/postgrey_whitelist_clients.local - %ghost this and make the user add it themselves once they've RTFM, IMO E: postgrey non-standard-gid /var/run/postgrey postfix E: postgrey non-standard-dir-perm /var/run/postgrey 0750 E: postgrey non-standard-uid /var/lib/postgrey postgrey E: postgrey non-standard-gid /var/lib/postgrey postgrey E: postgrey non-standard-dir-perm /var/lib/postgrey 0750 - These can be ignored IMHO W: postgrey dangerous-command-in-%post chown - Do it via %attr instead if you have to, I get the jitters when I see this. W: postgrey service-default-enabled /etc/rc.d/init.d/postgrey - Please don't give explosives to newbies. :-) * The package should contain the text of the license (wiki: Packaging/ReviewGuidelines) - Yank a copy from an appropriate site, even as a SourceX if you want, Conversely, ask upstream to put it in the tarball. * Missing dependancy on service for %postun (package initscripts) * Missing dependancy on service for %preun (package initscripts) * Missing dependancy on chkconfig for %post (package chkconfig) * Missing dependancy on chkconfig for %preun (package chkconfig) - The Requires and pre/post install scriptlets need fixing. - Drop the PreReq entirely. Is this a holdover from MDK or something else? - Requires: postfix >= 2.1.0 (no policy server capability in older versions AFAIK. Again, no explosives for the newbs.) - For Requires(%post) etc, use the defaults from the Services part of http://www.fedoraproject.org/wiki/ScriptletSnippets Notes: Other blockers: - Don't use %define for Name/Version/Release, use them directly. It also makes the spec little cleaner. If possible avoid %defines at all unless you really need them. - Use install rather than mkdir/cp for moving files around and creating your extra dirs. "Would be nice if..." - Any reason to move the defaults around? - upstream likes it's configs and spool in /etc/postfix & $postfix_spooldir respectively. - "Starting/Stopping $prog" in the init file looks a little ugly, when compared to other init files (not that most sysadmins *care*, but it stuck out for me :-)) Perhaps a simple "Starting/Stopping Postgrey:" would suffice? - Toss a %{?dist} in Release as good practice and to make distro upgrades simpler and cleaner. Stuff I liked: - Generated manpages. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 19 13:36:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 08:36:27 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602191336.k1JDaRd2021544@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From jwb at redhat.com 2006-02-19 08:36 EST ------- Fixes: - Removed package relocatability - Added -q to %setup - Added ghosted config files. These files are actually created at setup time, after installation (which simply consists of unrolling the tarball in place), they are not present in the download tarball at all. Issues: - GHCC is a compatibility checker for Gallery 1.x, not 2.x. Gallery2 includes compatibility checking as part of the initial setup process, so I'm not sure there's any value to adding GHCC to this package - I've changed the name to gallery2, but I don't think there would be a major compatibility problem as G2 installs to a different directory, and can transparently import G1 albums into G2. I'd prefer the name be 'gallery' but I'm not adamant about that. New spec file / srpm locations: SPEC: http://www.berningeronline.net/gallery2.spec SRPM: http://www.berningeronline.net/gallery2-2.0.2-2.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 19 13:43:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 08:43:21 -0500 Subject: [Bug 179802] Review Request: seamonkey In-Reply-To: Message-ID: <200602191343.k1JDhLLv022206@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: seamonkey https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179802 ------- Additional Comments From kengert at redhat.com 2006-02-19 08:43 EST ------- Summary of the previous comments. Chris, from all your comments, only one issue is left: > > - You probably ought to have the FindExternalProvides stuff that the Firefox and > > Thunderbird package does. Since the libraries provided aren't versioned, this > > can cause problems when two packages provide the same libraries (mozilla also > > provides these for now, and when xulrunner eventually takes over, it will do so). > > Are you suggesting to add the following 3 lines? > AutoProv: 0 > %define _use_internal_dependency_generator 0 > %define __find_requires %{SOURCE100} As said before, that didn't work for me. You also proposed > Does it work if you Require: seamonkey (it should be Require anyway, and please > one Require per line.) But that didn't work either. What should we do? Is there an easy way to make the dependency/provides system use absolute pathes, so your predicted ambiguity won't occur, or could we skip this for now? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From hunter at userfriendly.net Sun Feb 19 13:59:02 2006 From: hunter at userfriendly.net (Michael Weiner) Date: Sun, 19 Feb 2006 08:59:02 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: <200602191336.k1JDaRd2021544@www.beta.redhat.com> References: <200602191336.k1JDaRd2021544@www.beta.redhat.com> Message-ID: On 2/19/06, bugzilla at redhat.com wrote: > > Please do not reply directly to this email. All additional > comments should be made in the comments box of this bug report. > > Summary: Review Request: gallery: web based photo album software > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 > > > > > > ------- Additional Comments From jwb at redhat.com 2006-02-19 08:36 EST > ------- > Fixes: > - Removed package relocatability > - Added -q to %setup > - Added ghosted config files. These files are actually created at setup > time, > after installation (which simply consists of unrolling the tarball in > place), > they are not present in the download tarball at all. > > Issues: > - GHCC is a compatibility checker for Gallery 1.x, not 2.x. Gallery2 > includes > compatibility checking as part of the initial setup process, so I'm not > sure > there's any value to adding GHCC to this package > - I've changed the name to gallery2, but I don't think there would be a > major > compatibility problem as G2 installs to a different directory, and can > transparently import G1 albums into G2. I'd prefer the name be 'gallery' > but > I'm not adamant about that. > > New spec file / srpm locations: > SPEC: http://www.berningeronline.net/gallery2.spec > SRPM: http://www.berningeronline.net/gallery2-2.0.2-2.src.rpm > > -- This does not rebuild correctly as illustrated below: $rpmbuild --rebuild gallery2-2.0.2-2.src.rpm Installing gallery2-2.0.2-2.src.rpm warning: user jwb does not exist - using root warning: group jwb does not exist - using root warning: user jwb does not exist - using root warning: group jwb does not exist - using root Executing(%prep): /bin/sh -e /root/build/redhat/tmp/rpm-tmp.29928 + umask 022 + cd /root/build/redhat/BUILD + LANG=C + export LANG + unset DISPLAY + cd /root/build/redhat/BUILD + rm -rf gallery2 + /usr/bin/gzip -dc /root/build/redhat/SOURCES/gallery-2.0.2-minimal.tar.gz + tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd gallery2 ++ /usr/bin/id -u + '[' 0 = 0 ']' + /bin/chown -Rhf root . ++ /usr/bin/id -u + '[' 0 = 0 ']' + /bin/chgrp -Rhf root . + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + exit 0 Executing(%install): /bin/sh -e /root/build/redhat/tmp/rpm-tmp.88666 + umask 022 + cd /root/build/redhat/BUILD + cd gallery2 + LANG=C + export LANG + unset DISPLAY + mkdir -p /root/build/redhat/tmp/gallery2-2.0.2-2-root-root /var/www/html/gallery2 + cp -pr LICENSE MANIFEST README.html bootstrap.inc docs embed.php images index.php init.inc install lib main.php modules themes upgrade /root/build/redhat/tmp/gallery2-2.0.2-2-root-root/var/www/html/gallery2 + /usr/lib/rpm/redhat/brp-compress + /usr/lib/rpm/redhat/brp-strip /usr/bin/strip + /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip + /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump Processing files: gallery2-2.0.2-2 error: File not found: /root/build/redhat/tmp/gallery2-2.0.2-2-root-root /var/www/html/gallery2/config.php error: File not found: /root/build/redhat/tmp/gallery2-2.0.2-2-root-root /var/www/html/gallery2/login.txt error: File not found: /root/build/redhat/tmp/gallery2-2.0.2-2-root-root /var/www/html/gallery2/.htaccess RPM build errors: user jwb does not exist - using root group jwb does not exist - using root user jwb does not exist - using root group jwb does not exist - using root File not found: /root/build/redhat/tmp/gallery2-2.0.2-2-root-root /var/www/html/gallery2/config.php File not found: /root/build/redhat/tmp/gallery2-2.0.2-2-root-root /var/www/html/gallery2/login.txt File not found: /root/build/redhat/tmp/gallery2-2.0.2-2-root-root /var/www/html/gallery2/.htaccess Michael Weiner -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla at redhat.com Sun Feb 19 14:09:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 09:09:30 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602191409.k1JE9U8U025200@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From jwb at redhat.com 2006-02-19 09:09 EST ------- Rebuild failed due to not creating ghosted config files. Error fixed in updated packages: SPEC: http://www.berningeronline.net/gallery2.spec SRPM: http://www.berningeronline.net/gallery2-2.0.2-3.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 19 14:41:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 09:41:09 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602191441.k1JEf9T6029193@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From bugs.michael at gmx.net 2006-02-19 09:41 EST ------- * %ghost and %config are mutually exclusive. * Verify your package changes: rpm --query --configfiles gallery2 * Are you happy with the results? See: rpm --query --list gallery2-2.0.2-3.i386.rpm | grep htaccess * Also take a look at your build log: warning: File listed twice: /var/www/html/gallery2/.htaccess warning: File listed twice: /var/www/html/gallery2/config.php warning: File listed twice: /var/www/html/gallery2/login.txt -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 19 14:44:12 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 09:44:12 -0500 Subject: [Bug 181803] Review Request: scrub In-Reply-To: Message-ID: <200602191444.k1JEiCwd029523@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: scrub https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181803 ed at eh3.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|bugzilla-sink at leemhuis.info |ed at eh3.com OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From ed at eh3.com 2006-02-19 09:44 EST ------- Hi Ben & Brian, this package looks fine (Brian did a good review), built in mock, and ran without seg-faulting on my system (FC4). So I'd like to sponsor Ben if someone hasn't already. APPROVED. And Ben, have you submitted the account paperwork? I can't seem to locate your username in the account system. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugs.michael at gmx.net Sun Feb 19 15:03:54 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 19 Feb 2006 16:03:54 +0100 Subject: PLEASE HELP - We need a policy for preventing man page name conflicts In-Reply-To: <43F6B501.1040105@cora.nwra.com> References: <43F6B501.1040105@cora.nwra.com> Message-ID: <20060219160354.48c882db.bugs.michael@gmx.net> On Fri, 17 Feb 2006 22:47:45 -0700, Orion Poplawski wrote: > Many packages provide man3 (and other) man pages with generic names. > The case in question in ncarg-devel and allegro-devel which both provide > man3/line.3.gz. So, what do we do? Resolve the conflict. ;) Talk to both upstream developer groups. "line" is a very generic name for a manual page in the API section if to be installed in global search path. > - package in /usr/share//man/? If so, how to we update > MANPATH? How does man handle finding both (all) of the man pages? If you added the separate directory to default MANPATH, you would end up with a conflict at search-time. > - rename to something like _? Do we always do this? > Only if a file conflicts? Is there an easy way to find conflicts before > packaging? > > - suffixes .3 ? Can man handle this? AFAIK, while this can be used to avoid file conflicts ("man" can handle an optional suffix after the section number), there is no way for man to choose either one at the command-line unless you specified the full file name. Like "man /usr/share/man/man3/line.3allegro.gz". ;) > Please help! From ivg2 at cornell.edu Sun Feb 19 15:46:17 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sun, 19 Feb 2006 10:46:17 -0500 Subject: PLEASE HELP - We need a policy for preventing man page name conflicts In-Reply-To: <20060219160354.48c882db.bugs.michael@gmx.net> References: <43F6B501.1040105@cora.nwra.com> <20060219160354.48c882db.bugs.michael@gmx.net> Message-ID: <43F892C9.9020400@cornell.edu> >> Many packages provide man3 (and other) man pages with generic names. >> The case in question in ncarg-devel and allegro-devel which both provide >> man3/line.3.gz. So, what do we do? >> > > Resolve the conflict. ;) Talk to both upstream developer groups. "line" is > a very generic name for a manual page in the API section if to be > installed in global search path. > The manpage is a symptom of the real problem, which is much worse - section (3) of the API indicates library functions. The libraries in question are not using proper namespace. Any attempt to workaround the problem w/ regard to man is working around the real bug. From bugzilla at redhat.com Sun Feb 19 15:49:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 10:49:20 -0500 Subject: [Bug 177881] Review Request: lucidlife In-Reply-To: Message-ID: <200602191549.k1JFnKn3004871@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: lucidlife https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177881 ------- Additional Comments From bdpepple at ameritech.net 2006-02-19 10:49 EST ------- I don't have permission to sponser you, but here's an initial review: MD5Sum: 25bcde0ddbe4f7db4a7ea92fcc36b7bc lucidlife-0.9.tar.gz Good: * Source URL is canonical * Upstream source tarball verified * Package name conforms to the Fedora Naming Guidelines * Buildroot has all required elements * All paths begin with macros * All necessary BuildRequires listed. * Package builds fine in Mock for FC5. * Rpmlint does not find problems * Installs & runs fine. Bad: * Desktop file is not handled correctly. Refer to http://fedoraproject.org/wiki/Packaging/Guidelines#head-254ddf07aae20a23ced8cecc219d8f73926e9755 Minor: * Drop the Requires for gtk2 & gnome-vfs2, the devel sonames will pull these in. * Should probably use %{_datadir}/%{name}/ in the files section in case of problems with file ownership. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 19 15:59:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 10:59:08 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602191559.k1JFx8Ps006085@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From jwb at redhat.com 2006-02-19 10:59 EST ------- Removed %config from %ghost files - The queries on rpm -ql and rpm -qf are behaving as I intended now. This also removes the "File listed twice" warnings. I've also split off the docs/ directory into a -docs package, since it seems to belong there rather than in the main package. New files: SPEC: http://www.berningeronline.net/gallery2.spec SRPM: http://www.berningeronline.net/gallery2-2.0.2-4.src.rpm Opinions requested: should the imagemagick, gd, netpbm, matrix, and siriux modules/themes also be broken out into separate packages, or simply left as separate 'provides' as they are now? Without at least one of each, the gallery will be fairly useless, but it's also useless without a database or image library backend. Breaking it out will allow me to require ImageMagick for the gallery2-imagemagick package, etc., helping to ensure the image library requirements are actually met. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 19 16:06:41 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 11:06:41 -0500 Subject: [Bug 181979] Review Request: python-geoip - Python bindings for the GeoIP geographical lookup libraries In-Reply-To: Message-ID: <200602191606.k1JG6fNl007118@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: python-geoip - Python bindings for the GeoIP geographical lookup libraries https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181979 ------- Additional Comments From tibbs at math.uh.edu 2006-02-19 11:06 EST ------- A clean package, builds fine in mock on i386 and x86_64. However, I don't think the name is proper. By my understanding of the naming guidelines, your package should be python-GeoIP. rpmlint says: W: python-geoip doc-file-dependency /usr/share/doc/python-geoip-1.2.1/test.py /usr/bin/python W: python-geoip doc-file-dependency /usr/share/doc/python-geoip-1.2.1/test_city.py /usr/bin/python W: python-geoip doc-file-dependency /usr/share/doc/python-geoip-1.2.1/test_org.py /usr/bin/python W: python-geoip doc-file-dependency /usr/share/doc/python-geoip-1.2.1/test_region.py /usr/bin/python This is the rpm dependency generator picking up a /usr/bin/python dependency from the executable scripts marked %doc. In this case I believe the added dependency is just redundant since python is required anyway and there's no prohibition against executable documentation that I can fine, but if you want to quiet rpmlint, just chmod -x the files. Note also that three of the example files will not work at all with the (free) GeoIP package in Extras. I don't think this is a blocker, but it may generate bug reports. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From tibbs at math.uh.edu Sun Feb 19 16:19:05 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sun, 19 Feb 2006 10:19:05 -0600 Subject: %{SOURCEn} versus $RPM_SOURCE_DIR In-Reply-To: <1140322492.2714.8.camel@ignacio.lan> (Ignacio Vazquez-Abrams's message of "Sat, 18 Feb 2006 23:14:52 -0500") References: <1140322492.2714.8.camel@ignacio.lan> Message-ID: >>>>> "IV" == Ignacio Vazquez-Abrams writes: IV> %{SOURCE1} will always refer to Source1 regardless of what "blah" IV> may be. It's also more concise. That I agree with, but I guess what I'm really asking is whether use of $RPM_SOURCE_DIR is any kind of impediment to package acceptance. I'm reviewing a package that uses it and frankly I hadn't seen it before. The wiki has no info. - J< From bugzilla at redhat.com Sun Feb 19 16:34:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 11:34:34 -0500 Subject: [Bug 179707] Review Request: dap-server - Basic request handling for DAP servers In-Reply-To: Message-ID: <200602191634.k1JGYY1k010926@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: dap-server - Basic request handling for DAP servers https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179707 ed at eh3.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From ed at eh3.com 2006-02-19 11:34 EST ------- Ok, glad to hear the gcc problem is being fixed upstream. Please change the license to LGPL before checking it in and, since I don't see any other blockers (comment #1), this package is APPROVED. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 19 16:35:24 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 11:35:24 -0500 Subject: [Bug 179710] Review Request: netcdf_handler - NetCDF 3 data handler for the OPeNDAP Data server In-Reply-To: Message-ID: <200602191635.k1JGZO2U011188@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: netcdf_handler - NetCDF 3 data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179710 ------- Additional Comments From ed at eh3.com 2006-02-19 11:35 EST ------- Hi Patrice, yes the "dap-netcdf_handler" name is fine so please go ahead and post an updated SRPM and I'll continue with the review. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 19 16:42:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 11:42:50 -0500 Subject: [Bug 172872] Review Request: sloccount In-Reply-To: Message-ID: <200602191642.k1JGgo0P011975@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: sloccount https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172872 ------- Additional Comments From ed at eh3.com 2006-02-19 11:42 EST ------- Hi Bastien, its been 2+ months since the last comment -- is this submission still active? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rdieter at math.unl.edu Sun Feb 19 17:27:37 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 19 Feb 2006 11:27:37 -0600 Subject: %{SOURCEn} versus $RPM_SOURCE_DIR In-Reply-To: References: <1140322492.2714.8.camel@ignacio.lan> Message-ID: Jason L Tibbitts III wrote: >>>>>> "IV" == Ignacio Vazquez-Abrams writes: > > IV> %{SOURCE1} will always refer to Source1 regardless of what "blah" > IV> may be. It's also more concise. > > That I agree with, but I guess what I'm really asking is whether use > of $RPM_SOURCE_DIR is any kind of impediment to package acceptance. > I'm reviewing a package that uses it and frankly I hadn't seen it > before. The wiki has no info. I can't think of any legitimate use of $RPM_SOURCE_DIR, so IMO, it's use ought to at least be discouraged (unless there is some unknown good reason otherwise) -- Rex From bugzilla at redhat.com Sun Feb 19 17:31:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 12:31:13 -0500 Subject: [Bug 181994] Review Request: doulos-fonts - Doulos SIL fonts In-Reply-To: Message-ID: <200602191731.k1JHVDVh018052@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: doulos-fonts - Doulos SIL fonts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181994 roozbeh at farsiweb.info changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From roozbeh at farsiweb.info 2006-02-19 12:31 EST ------- Thanks a lot for the review. Imported and built. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 19 17:31:24 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 12:31:24 -0500 Subject: [Bug 181993] Review Request: charis-fonts - Charis SIL fonts In-Reply-To: Message-ID: <200602191731.k1JHVOnh018141@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: charis-fonts - Charis SIL fonts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181993 roozbeh at farsiweb.info changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From roozbeh at farsiweb.info 2006-02-19 12:31 EST ------- Thanks a lot for the review. Imported and built. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 19 18:00:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 13:00:53 -0500 Subject: [Bug 182040] New: Review Request: ratpoison - simplified keyboard-only window manager Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182040 Summary: Review Request: ratpoison - simplified keyboard-only window manager Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: jwb at redhat.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.berningeronline.net/ratpoison.spec SRPM Name or Url: http://www.berningeronline.net/ratpoison-1.3.0-1.src.rpm Description: Ratpoison is a simplified window manager designed for use with a keyboard only, without any mouse support, without window decorations, and without large library dependencies. Packaged here for inclusion in FE as a result of an entry on the Extras/WishList. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 19 18:27:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 13:27:08 -0500 Subject: [Bug 181777] Review Request: CCfits A C++ interface for cfitsio (FITS File Subroutine Library) In-Reply-To: Message-ID: <200602191827.k1JIR84A025213@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: CCfits A C++ interface for cfitsio (FITS File Subroutine Library) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181777 ed at eh3.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|bugzilla-sink at leemhuis.info |ed at eh3.com ------- Additional Comments From ed at eh3.com 2006-02-19 13:27 EST ------- Hi Sergio, I started to do a review of this package and got this far: good: + specfile is legible + builds on FC4 (will try in mock later) + dir ownership looks good + *.la files removed needswork: - Something is the matter with the upstream server. All my connections to it are timing out so I can't get a copy of the upstream code to compare. Hopefully, it'll get fixed soon and we'll be able to proceed! - builds on FC4 and rpmlint returns the following: W: CCfits summary-ended-with-dot A C++ interface for cfitsio (FITS File Subroutine Library). W: CCfits invalid-license GPL compatible (see License.txt) E: CCfits binary-or-shlib-defines-rpath /usr/lib/libCCfits.so.0.0.0 ['/usr/lib'] W: CCfits-devel summary-ended-with-dot Headers for developing programs that will use CCfits. W: CCfits-devel invalid-license GPL compatible (see License.txt) W: CCfits-docs invalid-license GPL compatible (see License.txt) E: CCfits-docs script-without-shellbang /usr/share/doc/CCfits-docs-1.4/html/support_subs.pl E: CCfits-docs wrong-script-interpreter /usr/share/doc/CCfits-docs-1.4/html/ccfitschange_sff.pl "/usr1/local/bin/perl5" W: CCfits-docs doc-file-dependency /usr/share/doc/CCfits-docs-1.4/html/ccfitschange_sff.pl /usr1/local/bin/perl5 - The license is essentially BSD without the advertisement clause, so please list it as BSD (which is GPL-compatible) - Please change the main Summary: to "A C++ interface for cfitsio" and remove the trailing "."-s in the others - the "rpath" mentioned above will probably need to be fixed And I'm sorry this isn't a full review -- am going to need to get a copy from upstream to complete it. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 19 18:28:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 13:28:48 -0500 Subject: [Bug 172872] Review Request: sloccount In-Reply-To: Message-ID: <200602191828.k1JISm5Z025370@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: sloccount https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172872 ------- Additional Comments From bnocera at redhat.com 2006-02-19 13:28 EST ------- I really slacked on that. Just need to do some work on it... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 19 18:38:38 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 13:38:38 -0500 Subject: [Bug 182040] Review Request: ratpoison - simplified keyboard-only window manager In-Reply-To: Message-ID: <200602191838.k1JIcc7J027099@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ratpoison - simplified keyboard-only window manager https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182040 ------- Additional Comments From jwb at redhat.com 2006-02-19 13:38 EST ------- Additional note: I'm not yet sponsored, although I have been working on the gallery package in BZ 181599 as well. I'll need a sponsor for this one if 181599 isn't accepted. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 19 19:29:51 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 14:29:51 -0500 Subject: [Bug 181753] Review Request: mm - Shared memory allocation library In-Reply-To: Message-ID: <200602191929.k1JJTpsW002069@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mm - Shared memory allocation library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181753 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-19 14:29 EST ------- Question: Is it realy inpossible to use %{?_smp_mflags}? Bad: - mm-debuginfo contains no debug information. BTW: Sorry for the typo in comment #1. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From nman64 at n-man.com Sun Feb 19 19:39:13 2006 From: nman64 at n-man.com (Patrick Barnes) Date: Sun, 19 Feb 2006 13:39:13 -0600 Subject: [ANN] Fedora Project Wiki Policy Change (Update) In-Reply-To: <200602161806.29490.nman64@n-man.com> References: <200602161806.29490.nman64@n-man.com> Message-ID: <200602191339.15904.nman64@n-man.com> We have completed the shift to our new wiki policy. The Contributor License Agreement is now required for wiki editing privileges. The EditGroup[1] is no longer frozen. EditGroup members who have already completed the CLA do not need to do anything. They should be able to continue editing normally. All former EditGroup members who have not completed the CLA have been moved to the new UnlicensedGroup[2] page. They will be unable to edit the wiki until they have completed the CLA and have removed themselves from the UnlicensedGroup. Once they have done so, they can contact someone currently on the EditGroup to get themselves added again. More details about these changes can be found on the WikiLicenseTalk[3] page. As always, wiki editing details can be found on the WikiEditing[4] page. [1] http://fedoraproject.org/wiki/EditGroup [2] http://fedoraproject.org/wiki/UnlicensedGroup [3] http://fedoraproject.org/wiki/WikiLicenseTalk [4] http://fedoraproject.org/wiki/WikiEditing -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugzilla at redhat.com Sun Feb 19 19:37:29 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 14:37:29 -0500 Subject: [Bug 181753] Review Request: mm - Shared memory allocation library In-Reply-To: Message-ID: <200602191937.k1JJbTel003534@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mm - Shared memory allocation library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181753 ------- Additional Comments From andreas at bawue.net 2006-02-19 14:37 EST ------- (In reply to comment #4) > Bad: > - mm-debuginfo contains no debug information. Uhm. I have absolutely no clue about the debuginfo packages. Got any hints about this problem? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 19 19:41:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 14:41:44 -0500 Subject: [Bug 181801] Review Request: zeroinstall-injector In-Reply-To: Message-ID: <200602191941.k1JJfiw9004004@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: zeroinstall-injector https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181801 Jochen at herr-schmitt.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bugzilla-sink at leemhuis.info |Jochen at herr-schmitt.de ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-19 14:41 EST ------- Bad: - Source0 contains not a full qualiifed URL. - BuildRequires: python should be add. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From buildsys at fedoraproject.org Sun Feb 19 20:18:16 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 19 Feb 2006 15:18:16 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060219201816.F2EA68011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 4 OpenEXR-1.2.2-6.fc3 hamlib-1.2.4-3.fc3 icecast-2.3.1-1.fc3 ushare-0.9.6-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun Feb 19 20:18:23 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 19 Feb 2006 15:18:23 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060219201823.2F63D8011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 10 OpenEXR-1.2.2-6.fc4 gcfilms-6.1-1.fc4 hamlib-1.2.4-3.fc4 icecast-2.3.1-1.fc4 nautilus-search-tool-0.2-1.fc4 perl-DBIx-DBSchema-0.30-1.fc4 perl-Font-TTF-0.37-3.fc4 translate-toolkit-0.8-0.10.rc6.fc4 translate-toolkit-0.8-0.9.rc6.fc4 ushare-0.9.6-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun Feb 19 20:19:15 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 19 Feb 2006 15:19:15 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060219201915.E357F8011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 29 Coin2-2.4.4-9.fc5 Inventor-2.1.5-20.fc5 OpenEXR-1.2.2-7.fc5 OpenSceneGraph-1.0-2.fc5 blender-2.41-3.fc5 charis-fonts-4.0.02-1 doulos-fonts-4.0.14-1 emelfm2-0.1.5-2.fc5 fftw-3.1-3.fc5 flow-tools-0.68-7.fc5 gcfilms-6.1-1.fc5 glabels-2.0.4-2.fc5 hamlib-1.2.4-3.fc5 jhead-2.5-1.fc5 naim-0.11.8.2-2.fc5 nautilus-search-tool-0.2-1.fc5 perl-BerkeleyDB-0.27-2.fc5 perl-Crypt-DES-2.05-2.fc5 perl-DBIx-DBSchema-0.30-1.fc5 perl-DateTime-0.30-2.fc5 perl-Font-TTF-0.38.1-1.fc5 perl-IPC-ShareLite-0.09-7.fc5 perl-Unix-Syslog-0.100-7.fc5 rzip-2.0-2.fc5 translate-toolkit-0.8-0.10.rc6.fc5 ushare-0.9.6-1.fc5 xfce4-mount-plugin-0.3.3-2.fc5 xfce4-netload-plugin-0.3.3-5.fc5 xfce4-sensors-plugin-0.7.0-4.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Sun Feb 19 20:20:22 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 15:20:22 -0500 Subject: [Bug 174952] Review Request: lightning - GNU Lightning In-Reply-To: Message-ID: <200602192020.k1JKKMYn008277@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: lightning - GNU Lightning https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174952 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-19 15:20 EST ------- I could reproduced your complaint about %{_infodir}/dir. The other complaints should be fixed. You can download the correct version from: Spec Name or Url: http://www.herr-schmitt.de/pub/lightning/lightning.spec SRPM Name or Url: http://www.herr-schmitt.de/pub/lightning/lightning-1.2-2.spec -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From wtogami at redhat.com Sun Feb 19 20:30:05 2006 From: wtogami at redhat.com (Warren Togami) Date: Sun, 19 Feb 2006 15:30:05 -0500 Subject: Again: EOL Policy for Fedora Extras In-Reply-To: <1140346231.11703.47.camel@rousalka.dyndns.org> References: <1140287414.6634.70.camel@localhost.localdomain> <200602182305.52470.dennis@ausil.us> <1140346231.11703.47.camel@rousalka.dyndns.org> Message-ID: <43F8D54D.8040309@redhat.com> Nicolas Mailhot wrote: > And I absolutely do not mean FEL should be a separate entity with no > access to FE ressources. It could be a FE SIG or something else within > FE. But there must be some coordinating structure, and package lifetimes I think that there is enough of a negative connotation with the word "Legacy" that we should avoid calling it that. That would effectively shove it aside with the expectation that "somebody else" is supposed to be working on it. Instead a "team" of some sort should work on organizing the security response. The "team" focuses on these tasks: * Tracking where there are vulnerabilties * Notifying existing maintainers Meanwhile, the "team" and everyone else has the option of working on: * obviously orphaned packages * orphaned packages only in older distributions The database created by the "team" is used in judgement of retirement metrics. If it becomes plainly obvious that the community is not willing to maintain an older distribution, then we can go through a warning period and later retire the distro. The bug list(s), multiple owner thing, moving Core and Extras closer together, are all things that would help the above model. Warren From bugzilla at redhat.com Sun Feb 19 20:26:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 15:26:09 -0500 Subject: [Bug 181997] Review Request: gpc - The GNU Pascal compiler In-Reply-To: Message-ID: <200602192026.k1JKQ9rd009074@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gpc - The GNU Pascal compiler https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181997 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-19 15:26 EST ------- Question: do gpc-debuginfo contains any files? If not, what I assume, you have a problem with you build. During your build, the executables should contrains debuging information. This informationen bill be put into the gpc-debuginfo package. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 19 20:56:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 15:56:53 -0500 Subject: [Bug 177881] Review Request: lucidlife In-Reply-To: Message-ID: <200602192056.k1JKurTV012945@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: lucidlife https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177881 ------- Additional Comments From admin at ramshacklestudios.com 2006-02-19 15:56 EST ------- Thanks, Brian. I've updated the .spec file and the source RPM per your suggestions. Spec: http://peter.ramshacklestudios.com/downloads/fedora/extras/lucidlife.spec SRPM: http://peter.ramshacklestudios.com/downloads/fedora/extras/lucidlife-0.9-2.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 19 21:09:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 16:09:11 -0500 Subject: [Bug 180743] Review Request: pdsh In-Reply-To: Message-ID: <200602192109.k1JL9B3r014405@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: pdsh https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180743 Jochen at herr-schmitt.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|bugzilla-sink at leemhuis.info |Jochen at herr-schmitt.de ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-19 16:09 EST ------- Bas: - Please use %{_sysconfdir} instead of /etc - you have not a good argument agains %{_smp_mflags} - rpmlint complaints: rpmlint pdsh-2.8.1-3.i686.rpm W: pdsh unstripped-binary-or-object /usr/bin/pdcp W: pdsh unstripped-binary-or-object /usr/bin/pdsh W: pdsh dangerous-command-in-%post rm pmlint pdsh-rcmd-rsh-2.8.1-3.i686.rpm W: pdsh-rcmd-rsh summary-ended-with-dot Provides bsd rcmd capability to pdsh. W: pdsh-rcmd-rsh no-documentation W: pdsh-rcmd-rsh devel-file-in-non-devel-package /usr/lib/pdsh/xrcmd.a rpmlint pdsh-rcmd-ssh-2.8.1-3.i686.rpm W: pdsh-rcmd-ssh summary-ended-with-dot Provides ssh rcmd capability to pdsh. W: pdsh-rcmd-ssh no-documentation W: pdsh-rcmd-ssh devel-file-in-non-devel-package /usr/lib/pdsh/sshcmd.a - pdsh-debuginfo contains not all debuginformation. Please study the rpmlit errors. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 19 21:14:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 16:14:36 -0500 Subject: [Bug 181997] Review Request: gpc - The GNU Pascal compiler In-Reply-To: Message-ID: <200602192114.k1JLEaEH015034@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gpc - The GNU Pascal compiler https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181997 ------- Additional Comments From tibbs at math.uh.edu 2006-02-19 16:14 EST ------- Well, I just did a build in mock (development branch, i386) and it did create a debuginfo rpm and rpmlint is quieter: E: gpc devel-dependency gmp-devel W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/units/crtx.c W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/libgcc.a W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/libgcc_eh.a W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/units/intlc.c W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/units/regexc.c W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/libgpc.a W: gpc file-not-utf8 /usr/share/info/gpcs-de.info.gz W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/units/crtdjgpp.h W: gpc file-not-utf8 /usr/share/info/gpc.info.gz W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/units/crtc.h W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/units/crtlinux386.h W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/units/crtc.c W: gpc file-not-utf8 /usr/share/info/gpcs-es.info.gz W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/units/pipesc.c W: gpc file-not-utf8 /usr/share/info/gpcs-hr.info.gz W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/units/trapc.c W: gpc non-standard-dir-in-usr libexec I'm not sure what part of my regular build environment is different from what mock sets up, but in any case I guess this isn't a problem with the package. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 19 22:18:12 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 17:18:12 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602192218.k1JMICt6023097@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 dgregor at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dgregor at redhat.com ------- Additional Comments From dgregor at redhat.com 2006-02-19 17:18 EST ------- The FE packaging guidelines suggest using "Documentation" as the Group for a separate -doc package. However, given that the gallery2-docs package only contains 2 files, I'm not sure it's really worth splitting into a separate package. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 19 22:33:25 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 17:33:25 -0500 Subject: [Bug 176532] Review Request: TurboGears: Back-to-front web development in Python In-Reply-To: Message-ID: <200602192233.k1JMXPa1026599@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: TurboGears: Back-to-front web development in Python https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176532 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-19 17:33 EST ------- APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 19 22:47:43 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 17:47:43 -0500 Subject: [Bug 181979] Review Request: python-geoip - Python bindings for the GeoIP geographical lookup libraries In-Reply-To: Message-ID: <200602192247.k1JMlhR5029901@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: python-geoip - Python bindings for the GeoIP geographical lookup libraries https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181979 ------- Additional Comments From mfleming+rpm at enlartenment.com 2006-02-19 17:47 EST ------- Respin now available :-) Spec Name or Url: http://www.enlartenment.com/extras/python-GeoIP.spec SRPM Name or Url: http://www.enlartenment.com/extras/python-GeoIP-1.2.1-2.src.rpm - Name changed per package naming conventions - Execute bit removed from test*.py to keep RPM's dep generator from doing Bad Things. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From ville.skytta at iki.fi Sun Feb 19 22:54:52 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 20 Feb 2006 00:54:52 +0200 Subject: FE Package Status of Feb 16, 2006 In-Reply-To: <20060218202347.2d064fe2.bugs.michael@gmx.net> References: <200602161627.k1GGRAOi020957@ludwig-alpha.unil.ch> <1140264009.2904.119.camel@localhost.localdomain> <20060218165448.30fbb45c.bugs.michael@gmx.net> <1140279924.6634.35.camel@localhost.localdomain> <20060218175756.4577d6f2.bugs.michael@gmx.net> <1140282817.6634.47.camel@localhost.localdomain> <20060218202347.2d064fe2.bugs.michael@gmx.net> Message-ID: <1140389692.12129.33.camel@bobcat.mine.nu> On Sat, 2006-02-18 at 20:23 +0100, Michael Schwendt wrote: > tla I would like to see tla in Extras in the future as it's every now and then needed, but I'd rather stay away from grabbing official maintainership. 1.3.4 is out (released in January) and AFAICT the upstream project is alive again, with a new maintainer. Anyone? From bugzilla at redhat.com Mon Feb 20 00:00:41 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 19:00:41 -0500 Subject: [Bug 179710] Review Request: netcdf_handler - NetCDF 3 data handler for the OPeNDAP Data server In-Reply-To: Message-ID: <200602200000.k1K00f4v007390@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: netcdf_handler - NetCDF 3 data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179710 ------- Additional Comments From pertusus at free.fr 2006-02-19 19:00 EST ------- Here is the updated srpm: http://www.environnement.ens.fr/perso/dumas/fc-srpms/dap-netcdf_handler-3.5.2-1.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 20 01:48:17 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 20:48:17 -0500 Subject: [Bug 179710] Review Request: netcdf_handler - NetCDF 3 data handler for the OPeNDAP Data server In-Reply-To: Message-ID: <200602200148.k1K1mH9f025690@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: netcdf_handler - NetCDF 3 data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179710 ed at eh3.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From ed at eh3.com 2006-02-19 20:48 EST ------- Looks good, I don't see any blockers: 8d4d9ff2cca772f840b3b5449addeefc dap-netcdf_handler-3.5.2-1.src.rpm good: + source matches upstream + builds in mock on FC4 + rpmlint reports no warnings or errors + spec is simple and easily read + dir ownership is good + license is good, and correctly included + no shared libs APPROVED. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 20 02:22:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 21:22:56 -0500 Subject: [Bug 182064] New: Review Request:
Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182064 Summary: Review Request:
Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: dlutter at redhat.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://people.redhat.com/dlutter/yum/spec/facter.spec SRPM Name or Url: http://people.redhat.com/dlutter/yum/SRPMS/facter-1.1.1-3.src.rpm Description: Facter is a module for collecting simple facts about a host Operating system. This (together with bz180571) is my first request and I need to be sponsored -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 02:29:41 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 21:29:41 -0500 Subject: [Bug 180571] Review Request: puppet In-Reply-To: Message-ID: <200602200229.k1K2Tfj8030727@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: puppet https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180571 ------- Additional Comments From dlutter at redhat.com 2006-02-19 21:29 EST ------- - Thanks for taking the time to look at this. I filed a separate request for facter (bz 182064) and this request should only be applied to puppet. - puppet now uses fedora-usermgmt for creating the puppet user/group. - I used the relative uid/gid 24, which is the next free one on http://fedoraproject.org/wiki/Packaging/UserRegistry How do I get that added to that page ? Updated URL's: Spec URL: http://people.redhat.com/dlutter/yum/spec/puppet.spec SRPM URL: http://people.redhat.com/dlutter/yum/SRPMS/puppet-0.13.0-4.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 03:25:38 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 22:25:38 -0500 Subject: [Bug 179709] Review Request: hdf4_handler - HDF4 data handler for the OPeNDAP Data server In-Reply-To: Message-ID: <200602200325.k1K3PcGb005324@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: hdf4_handler - HDF4 data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179709 ed at eh3.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |ed at eh3.com OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From ed at eh3.com 2006-02-19 22:25 EST ------- Hi Patrice, heres a review: good: + license is acceptable for FE and included + source matches upstream + spec file is clean and has no obviuous errors + builds in mock on FC4 + dir ownership and permissions look good + very simple package needswork: - please re-name it to "dap-hdf4_handler" or similar - license is LGPL not GPL -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 20 03:41:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 22:41:16 -0500 Subject: [Bug 181974] Review Request: mod_geoip - Apache module for GeoIP lookups In-Reply-To: Message-ID: <200602200341.k1K3fGMk007556@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mod_geoip - Apache module for GeoIP lookups https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181974 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From tibbs at math.uh.edu 2006-02-19 22:41 EST ------- Looks clean and builds properly in mock (i386, development). rpmlint is silent. The package meets the naming and packaging guidelines. License is appropriate and matches source. Source file matches upstream. The specfile is properly named and is legible and understandable. BuildRequires: are proper. I find the Requires: a bit odd. What's the point of having httpd-mmn = missing /usr/include/httpd/.mmn doesn't exist? In any case, not a blocker. Approved. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 03:47:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 22:47:52 -0500 Subject: [Bug 180571] Review Request: puppet In-Reply-To: Message-ID: <200602200347.k1K3lq2L008312@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: puppet https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180571 ------- Additional Comments From rc040203 at freenet.de 2006-02-19 22:47 EST ------- > puppet now uses fedora-usermgmt for creating the puppet user/group. Please elaborate in detail why the standard usedadd etc. aren't sufficient for this package. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 03:47:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 22:47:44 -0500 Subject: [Bug 179708] Review Request: freeform_handler - FreeForm data handler for the OPeNDAP Data server In-Reply-To: Message-ID: <200602200347.k1K3liNw008280@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: freeform_handler - FreeForm data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179708 ed at eh3.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |ed at eh3.com OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From ed at eh3.com 2006-02-19 22:47 EST ------- Heres a review: 38027c71f44da94fddd3024ff2e6d5d3 freeform_handler-3.5.0-1.src.rpm good: + source matches upstream + license is acceptable for FE and correctly included + very simple and legible spec file + dir ownership and permissions look good + builds in mock on FC4 + rpmlint reports no errors or warnings needswork: - license is LGPL not GPL - please rename to "dap-freeform_handler" or similar -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 20 03:58:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 22:58:48 -0500 Subject: [Bug 179541] Review Request: tinyfugue: A MU* client In-Reply-To: Message-ID: <200602200358.k1K3wmhR009526@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: tinyfugue: A MU* client https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179541 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |177841 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-19 22:58 EST ------- Builds in mock, looking pretty good so far, though I can't sponsor. Blocking FE-NEEDSPONSOR. However, one thing that can be cleaned up, don't use Epoch unless you have to. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From jwboyer at jdub.homelinux.org Mon Feb 20 04:18:14 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 19 Feb 2006 22:18:14 -0600 Subject: FE Package Status of Feb 16, 2006 In-Reply-To: <1140389692.12129.33.camel@bobcat.mine.nu> References: <200602161627.k1GGRAOi020957@ludwig-alpha.unil.ch> <1140264009.2904.119.camel@localhost.localdomain> <20060218165448.30fbb45c.bugs.michael@gmx.net> <1140279924.6634.35.camel@localhost.localdomain> <20060218175756.4577d6f2.bugs.michael@gmx.net> <1140282817.6634.47.camel@localhost.localdomain> <20060218202347.2d064fe2.bugs.michael@gmx.net> <1140389692.12129.33.camel@bobcat.mine.nu> Message-ID: <43F94306.9010107@jdub.homelinux.org> Ville Skytt? wrote: > On Sat, 2006-02-18 at 20:23 +0100, Michael Schwendt wrote: > > >> tla >> > > I would like to see tla in Extras in the future as it's every now and > then needed, but I'd rather stay away from grabbing official > maintainership. 1.3.4 is out (released in January) and AFAICT the > upstream project is alive again, with a new maintainer. Anyone? > There was discussion of having dual maintainers in FE... wanna try it out with this package? I'm willing to try it out.. josh From bugzilla at redhat.com Mon Feb 20 04:14:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 23:14:30 -0500 Subject: [Bug 181997] Review Request: gpc - The GNU Pascal compiler In-Reply-To: Message-ID: <200602200414.k1K4EUl0011314@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gpc - The GNU Pascal compiler https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181997 ------- Additional Comments From rc040203 at freenet.de 2006-02-19 23:14 EST ------- (In reply to comment #2) > Well, I just did a build in mock (development branch, i386) and it did create a > debuginfo rpm and rpmlint is quieter: > > E: gpc devel-dependency gmp-devel > W: gpc devel-file-in-non-devel-package > /usr/lib/gcc/i386-redhat-linux/3.4.5/units/crtx.c BLOCKER: /usr/lib/gcc is reserved to GCC You must not install into it unless GCC is plugin/add-on to GCC. AFAIK, gpc is a fork of GCC, therefore it must not install to this directory. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 04:15:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 23:15:48 -0500 Subject: [Bug 181997] Review Request: gpc - The GNU Pascal compiler In-Reply-To: Message-ID: <200602200415.k1K4Fmei011524@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gpc - The GNU Pascal compiler https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181997 ------- Additional Comments From rc040203 at freenet.de 2006-02-19 23:15 EST ------- (In reply to comment #3) > You must not install into it unless GCC is plugin/add-on to GCC. This should have read ".. unless gpc is a plugin/add-on to GCC." -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 04:25:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2006 23:25:34 -0500 Subject: [Bug 181974] Review Request: mod_geoip - Apache module for GeoIP lookups In-Reply-To: Message-ID: <200602200425.k1K4PYC4012834@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mod_geoip - Apache module for GeoIP lookups https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181974 ------- Additional Comments From rc040203 at freenet.de 2006-02-19 23:25 EST ------- The tarball seems to be called "mod_geoip2". I know too little about this package, but why isn't the rpm called the same rsp. why doesn't the rpm provide a virtual property of this name? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 05:14:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 00:14:56 -0500 Subject: [Bug 181997] Review Request: gpc - The GNU Pascal compiler In-Reply-To: Message-ID: <200602200514.k1K5EuXO019217@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gpc - The GNU Pascal compiler https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181997 ------- Additional Comments From rc040203 at freenet.de 2006-02-20 00:14 EST ------- BLOCKER: package doesn't acknowledge RPM_OPT_FLAGS. In FSF's GCC, this is caused by older GCC's having problems in passing down CFLAGS (rsp. CFLAGS_FOR_HOST etc.) to it's sub-configure scripts. The recommended work-around in FSF-GCC is to override "CC" when invoking configure, i.e. to CC="%{__cc} ${RPM_OPT_FLAGS}" ./configure I'd assume a similar step is necessary to make gpc RPM_OPT_FLAGS-aware. [Beware: FORTIFY is known to detect memory leaks in some versions of GCC. Depending on how clean gpc is, it therefore might be necessary to filter FORTIFY from the CFLAGS being passed to GCC's configure.] -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 05:34:17 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 00:34:17 -0500 Subject: [Bug 181997] Review Request: gpc - The GNU Pascal compiler In-Reply-To: Message-ID: <200602200534.k1K5YHZu022065@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gpc - The GNU Pascal compiler https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181997 ------- Additional Comments From rc040203 at freenet.de 2006-02-20 00:34 EST ------- BLOCKER: Package doesn't build # rpmbuild -ba gpc.spec ... + rm share/info/dir rm: cannot remove `share/info/dir': No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.81410 (%install) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 07:19:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 02:19:01 -0500 Subject: [Bug 174952] Review Request: lightning - GNU Lightning In-Reply-To: Message-ID: <200602200719.k1K7J1RJ002779@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: lightning - GNU Lightning https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174952 ------- Additional Comments From paul at city-fan.org 2006-02-20 02:18 EST ------- (In reply to comment #2) > I could reproduced your complaint about %{_infodir}/dir. The usual fix is to do: rm -f %{buildroot}%{_infodir}/dir at the end of %install This will remove it if it gets installed, and will be harmless otherwise. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 20 07:24:37 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 02:24:37 -0500 Subject: [Bug 179541] Review Request: tinyfugue: A MU* client In-Reply-To: Message-ID: <200602200724.k1K7Obwd003737@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: tinyfugue: A MU* client https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179541 ------- Additional Comments From seg at haxxed.com 2006-02-20 02:24 EST ------- I'm confused about that. I swear I read something ~1 year ago in the Fedora packaging guidelines somewhere about how setting Epoch: 0 was a good idea, but its not there anymore. Might have been a core thing? Bleh. I'll nuke it. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From buildsys at fedoraproject.org Mon Feb 20 07:38:45 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 20 Feb 2006 02:38:45 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060220073845.D09218011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 8 SoQt-1.3.0-2.fc5 dejavu-fonts-2.3-1.fc5 nmh-1.1-18.fc5 perl-HTTP-Server-Simple-Mason-0.09-4.fc5 perl-Params-Validate-0.80-2.fc5 perl-Test-Taint-1.04-2.fc5 perl-Want-0.09-3.fc5 perl-gettext-1.05-8.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon Feb 20 07:38:40 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 20 Feb 2006 02:38:40 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060220073840.780B38011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 3 dejavu-fonts-2.3-1.fc4 gnupg2-1.9.20-2.fc4 perl-Font-TTF-0.38.1-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Mon Feb 20 08:29:14 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 03:29:14 -0500 Subject: [Bug 182077] New: Review Request: cfv - utility to test and create checksums Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182077 Summary: Review Request: cfv - utility to test and create checksums Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: a.kurtz at hardsun.net QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://hardsun.net/fedora/cfv.spec SRPM Name or Url: http://hardsun.net/fedora/cfv-1.18.1-1.src.rpm Description: cfv is a utility to both test and create .sfv, .csv, .crc, .md5(sfv-like), md5sum, bsd md5, sha1sum, and .torrent files. These files are commonly used to ensure the correct retrieval or storage of data. It also has test-only support for PAR and PAR2 files. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From mmcgrath at fedoraproject.org Mon Feb 20 08:46:45 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 20 Feb 2006 02:46:45 -0600 Subject: Crontab and init scripts Message-ID: <3237e4410602200046r3d9f871h2d4ba57c4556a80e@mail.gmail.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182033 What's Fedora policy on this? I guess I'm mostly just interested in being consistant. One option is provided in the bug report. In this instance I could also add an exit to the config with a comment about removing the exit after it has been configured. Yum I know is an example of a script that runs via cron that also has a init startup script. -Mike From bugzilla at redhat.com Mon Feb 20 08:53:38 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 03:53:38 -0500 Subject: [Bug 181974] Review Request: mod_geoip - Apache module for GeoIP lookups In-Reply-To: Message-ID: <200602200853.k1K8rck9018695@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mod_geoip - Apache module for GeoIP lookups https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181974 ------- Additional Comments From mfleming+rpm at enlartenment.com 2006-02-20 03:53 EST ------- I'll answer both questions in one reply - Both are quite valid questions. Jason: The httpd-mmn Requires: is to ensure that the module version matches that of the Apache version you're going to install against. (Something one of the more experienced packagers (Ville?) pointed out while I was working on mod_security) Ralf: I called it mod_geoip to avoid potential confusion ("Where's/What is mod_geoip1?) and ensure some level of clarity. Upstream has different tarballs for Apache 1.3.x and 2.x, the latter is mod_geoip2 but, given that FC doesn't package the older branch anyway, I went for plain "mod_geoip" so even the most inebriated of users could guess what it was for :-D. As for a virtual property, I've never seen anyone package it elsewhere - and if they've called it mod_geoip they'll get cleanly upgraded anyway provided other deps are met. I'll import and build unless anyone has strong "blocker" objections to the name. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 09:03:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 04:03:36 -0500 Subject: [Bug 173692] Review Request: libnotify In-Reply-To: Message-ID: <200602200903.k1K93awh020803@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libnotify https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173692 alexl at users.sourceforge.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexl at users.sourceforge.net ------- Additional Comments From alexl at users.sourceforge.net 2006-02-20 04:03 EST ------- What about a backport to FC-4? Will it even work on FC-4? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 20 09:36:54 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 04:36:54 -0500 Subject: [Bug 181993] Review Request: charis-fonts - Charis SIL fonts In-Reply-To: Message-ID: <200602200936.k1K9as5w028021@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: charis-fonts - Charis SIL fonts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181993 ------- Additional Comments From sarantis at cnl.di.uoa.gr 2006-02-20 04:36 EST ------- Just a reminder that fonts.cache-1 file ghosting is not needed for FC5. See http://www.redhat.com/archives/fedora-extras-list/2006-January/msg00918.html -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 10:10:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 05:10:56 -0500 Subject: [Bug 179709] Review Request: hdf4_handler - HDF4 data handler for the OPeNDAP Data server In-Reply-To: Message-ID: <200602201010.k1KAAucY002173@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: hdf4_handler - HDF4 data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179709 ------- Additional Comments From pertusus at free.fr 2006-02-20 05:10 EST ------- new srpm here: http://www.environnement.ens.fr/perso/dumas/fc-srpms/dap-hdf4_handler-3.5.0-1.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 20 10:20:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 05:20:07 -0500 Subject: [Bug 179708] Review Request: freeform_handler - FreeForm data handler for the OPeNDAP Data server In-Reply-To: Message-ID: <200602201020.k1KAK7uc003831@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: freeform_handler - FreeForm data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179708 ------- Additional Comments From pertusus at free.fr 2006-02-20 05:19 EST ------- new srpm is here: http://www.environnement.ens.fr/perso/dumas/fc-srpms/dap-freeform_handler-3.5.0-1.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From sdl.web at gmail.com Mon Feb 20 10:54:32 2006 From: sdl.web at gmail.com (leon) Date: Mon, 20 Feb 2006 10:54:32 +0000 Subject: abiword desktop file has wrong mimetypes Message-ID: Hi all, I notice that abiword won't open word document by default. The setting in "/usr/share/applications/fedora-abiword.desktop" has: application/vnd.ms-word. but the word document has a mimetype of "application/msword". Is this a bug? Cheers -- Leon From bugzilla at redhat.com Mon Feb 20 11:01:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 06:01:15 -0500 Subject: [Bug 181993] Review Request: charis-fonts - Charis SIL fonts In-Reply-To: Message-ID: <200602201101.k1KB1Fl2014953@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: charis-fonts - Charis SIL fonts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181993 ------- Additional Comments From rdieter at math.unl.edu 2006-02-20 06:01 EST ------- OTOH, ghosting fonts.cache-1 doesn't hurt anything either, and maintains compability with older releases. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rdieter at math.unl.edu Mon Feb 20 11:17:06 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 20 Feb 2006 05:17:06 -0600 Subject: abiword desktop file has wrong mimetypes In-Reply-To: References: Message-ID: leon wrote: > I notice that abiword won't open word document by default. The setting > in "/usr/share/applications/fedora-abiword.desktop" has: > application/vnd.ms-word. but the word document has a mimetype of > "application/msword". Is this a bug? IMO, yes. http://bugzilla.redhat.com against Fedora Extras/abiword. -- Rex From bugzilla at redhat.com Mon Feb 20 11:36:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 06:36:49 -0500 Subject: [Bug 181803] Review Request: scrub In-Reply-To: Message-ID: <200602201136.k1KBanBe026808@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: scrub https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181803 bugs.michael at gmx.net changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163779 |163778 nThis| | ------- Additional Comments From bugs.michael at gmx.net 2006-02-20 06:36 EST ------- Veto. There is "scrub" in FE already. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugs.michael at gmx.net Mon Feb 20 11:43:35 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 20 Feb 2006 06:43:35 -0500 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-02-20 Message-ID: <200602201143.k1KBhZPV022004@mx1.redhat.com> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- amarok 1.3.6-1.fc5.i386 at-poke 0.2.2-2.i386 cyrus-imapd 2.2.12-6.fc4.i386 cyrus-imapd-murder 2.2.12-6.fc4.i386 cyrus-imapd-nntp 2.2.12-6.fc4.i386 cyrus-imapd-utils 2.2.12-6.fc4.i386 gnomebaker 0.5.1-2.fc5.i386 gstreamer08-python 0.8.3-1.fc5.i386 istanbul 0.1.1-5.i386 libgdamm 1.3.7-2.fc5.i386 pam_mount 0.9.25-4.i386 perl-Cyrus 2.2.12-6.fc4.i386 sabayon-admin 2.12.1-2.i386 scalapack 1.7-7.fc4.i386 seahorse 0.7.9-1.fc5.i386 soundconverter 0.8.3-1.fc5.noarch tidy-devel 0.99.0-8.20051025.fc5.i386 tripwire 2.3.1-22.i386 up-imapproxy 1.2.4-4.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- amarok 1.3.6-1.fc5.ppc at-poke 0.2.2-2.ppc cyrus-imapd 2.2.12-6.fc4.ppc cyrus-imapd-murder 2.2.12-6.fc4.ppc cyrus-imapd-nntp 2.2.12-6.fc4.ppc cyrus-imapd-utils 2.2.12-6.fc4.ppc gnomebaker 0.5.1-2.fc5.ppc gstreamer08-python 0.8.3-1.fc5.ppc istanbul 0.1.1-5.ppc libgdamm 1.3.7-2.fc5.ppc pam_mount 0.9.25-4.ppc perl-Cyrus 2.2.12-6.fc4.ppc sabayon-admin 2.12.1-2.ppc scalapack 1.7-7.fc4.ppc seahorse 0.7.9-1.fc5.ppc soundconverter 0.8.3-1.fc5.noarch tidy-devel 0.99.0-8.20051025.fc5.ppc up-imapproxy 1.2.4-4.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- amarok 1.3.6-1.fc5.x86_64 at-poke 0.2.2-2.x86_64 cernlib 2005-7.fc5.x86_64 cernlib-packlib 2005-7.fc5.x86_64 cyrus-imapd 2.2.12-6.fc4.x86_64 cyrus-imapd-murder 2.2.12-6.fc4.x86_64 cyrus-imapd-nntp 2.2.12-6.fc4.x86_64 cyrus-imapd-utils 2.2.12-6.fc4.x86_64 gnomebaker 0.5.1-2.fc5.x86_64 gstreamer08-python 0.8.3-1.fc5.x86_64 istanbul 0.1.1-5.x86_64 libgdamm 1.3.7-2.fc5.x86_64 pam_mount 0.9.25-4.x86_64 paw 2005-7.fc5.x86_64 perl-Cyrus 2.2.12-6.fc4.x86_64 sabayon-admin 2.12.1-2.x86_64 scalapack 1.7-7.fc4.x86_64 seahorse 0.7.9-1.fc5.x86_64 soundconverter 0.8.3-1.fc5.noarch tidy-devel 0.99.0-8.20051025.fc5.x86_64 up-imapproxy 1.2.4-4.fc5.x86_64 From rdieter at math.unl.edu Mon Feb 20 12:39:47 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 20 Feb 2006 06:39:47 -0600 Subject: PLEASE HELP - We need a policy for preventing man page name conflicts In-Reply-To: <43F6B501.1040105@cora.nwra.com> References: <43F6B501.1040105@cora.nwra.com> Message-ID: Orion Poplawski wrote: > Many packages provide man3 (and other) man pages with generic names. The > case in question in ncarg-devel and allegro-devel which both provide > man3/line.3.gz. So, what do we do? > > - package in /usr/share//man/? If so, how to we update > MANPATH? How does man handle finding both (all) of the man pages? IMO, no. It's not worth the extra hassle. > - rename to something like _? +1 > Do we always do this? Only if a file conflicts? Yep. >Is there an easy way to find conflicts before > packaging? Not that I'm aware. It should be rare enough that it can be handled on a case-by-case basis. > - suffixes .3 ? Can man handle this? Another possibility, but I'm unfamiliar with that convention. -- Rex From rdieter at math.unl.edu Mon Feb 20 12:42:06 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 20 Feb 2006 06:42:06 -0600 Subject: Packages in CVS with no entry in the owners.list (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1140265140.2904.135.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140262149.2904.90.camel@localhost.localdomain> <1140265140.2904.135.camel@localhost.localdomain> Message-ID: Thorsten Leemhuis wrote: >These are only in cvs and have no entry in owners.list >- Rex Dieter : kile-i18n FYI, kile-i18n is no longer packaged separately from kile, ie. kile-i18n no longer effectively exists. -- Rex From bugzilla at redhat.com Mon Feb 20 12:41:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 07:41:48 -0500 Subject: [Bug 179707] Review Request: dap-server - Basic request handling for DAP servers In-Reply-To: Message-ID: <200602201241.k1KCfmYT005391@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: dap-server - Basic request handling for DAP servers https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179707 Bug 179707 depends on bug 179710, which changed state. Bug 179710 Summary: Review Request: netcdf_handler - NetCDF 3 data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179710 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NEXTRELEASE Status|ASSIGNED |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rdieter at math.unl.edu Mon Feb 20 12:50:50 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 20 Feb 2006 06:50:50 -0600 Subject: static libs ... again In-Reply-To: <1140243907.21764.402.camel@mccallum.corsepiu.local> References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> <1140243907.21764.402.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius wrote: > On Fri, 2006-02-17 at 23:02 -0600, Rex Dieter wrote: > >>Ed Hill wrote: >>>Is there is a middle ground in this static libs discussion? >>>For instance, are there technical solutions such as: >>> - all static libs should or perhaps must be in a -static >>> sub-package >>IMO, no point. > I disagree. > *-static would make packages using these static libs clearly > identifiable from examining these packages' spec or src.rpm. > > "Lumping together" static and shared libs into *-devel, hides away usage > of static libs from packaging. Ralf, excellent point, and I'm swayed by the argument. If packagers really want to include static libs, make it obvious and place them in a -static subpkg. One question to beg here... I maintain several libraries that come *only* as static libs(*). At the moment, these pkgs provide *only* a -devel pkg (pending upstream fix(es) to allow for shared/dynamic libs). Is that acceptable or should these get split too? -- Rex (*) libassuan-devel, libfac-devel, factory-devel From j.w.r.degoede at hhs.nl Mon Feb 20 13:04:32 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 20 Feb 2006 14:04:32 +0100 Subject: static libs ... again In-Reply-To: References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> <1140243907.21764.402.camel@mccallum.corsepiu.local> Message-ID: <43F9BE60.1090705@hhs.nl> Rex Dieter wrote: > Ralf Corsepius wrote: >> On Fri, 2006-02-17 at 23:02 -0600, Rex Dieter wrote: >> >>> Ed Hill wrote: > >>>> Is there is a middle ground in this static libs discussion? >>>> For instance, are there technical solutions such as: > >>>> - all static libs should or perhaps must be in a -static >>>> sub-package > >>> IMO, no point. > >> I disagree. >> *-static would make packages using these static libs clearly >> identifiable from examining these packages' spec or src.rpm. >> >> "Lumping together" static and shared libs into *-devel, hides away usage >> of static libs from packaging. > > Ralf, excellent point, and I'm swayed by the argument. If packagers > really want to include static libs, make it obvious and place them in a > -static subpkg. > > One question to beg here... I maintain several libraries that come > *only* as static libs(*). At the moment, these pkgs provide *only* a > -devel pkg (pending upstream fix(es) to allow for shared/dynamic libs). > Is that acceptable or should these get split too? > > -- Rex > Not split, but renamed would be a good so replace -devel with -static. Also I wonder how hard is it to add -fpic -DPIC to the cflags and change the link command to generate an .so. The only added trouble would be checking for abi changes on new releases and bumping the .so name a release. Regards, Hans From bugzilla at redhat.com Mon Feb 20 12:56:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 07:56:11 -0500 Subject: [Bug 181803] Review Request: scrub In-Reply-To: Message-ID: <200602201256.k1KCuBrw007711@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: scrub https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181803 ed at eh3.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NOTABUG ------- Additional Comments From ed at eh3.com 2006-02-20 07:56 EST ------- Hi Michael, you're absolutely right. So, I'll mark this entry as "NOTABUG". And if Ben would like to have the existing FE version of scrub upgraded to 1.7 (from the current 1.6 which is available for FC4 and devel) then please file a separate enhancement bug for that. And, in future, I'm going to be more careful and check for existing FE packages so I can hopefully avoid a repeat of this embarrassing situation. :-) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rdieter at math.unl.edu Mon Feb 20 13:02:06 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 20 Feb 2006 07:02:06 -0600 Subject: FE Package Status of Feb 16, 2006 In-Reply-To: <20060218202347.2d064fe2.bugs.michael@gmx.net> References: <200602161627.k1GGRAOi020957@ludwig-alpha.unil.ch> <1140264009.2904.119.camel@localhost.localdomain> <20060218165448.30fbb45c.bugs.michael@gmx.net> <1140279924.6634.35.camel@localhost.localdomain> <20060218175756.4577d6f2.bugs.michael@gmx.net> <1140282817.6634.47.camel@localhost.localdomain> <20060218202347.2d064fe2.bugs.michael@gmx.net> Message-ID: Michael Schwendt wrote: > The following are without maintainer for a longer time, i.e. in 2005 and > before Dec 2005 (and tracked in the Wiki): ... > gpa I can do gpa, since I'm already doing much of the gnupg2/gpgme tool-chain. -- Rex From bugzilla at redhat.com Mon Feb 20 12:56:31 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 07:56:31 -0500 Subject: [Bug 177841] Tracker: New Extras packages that need a sponsor In-Reply-To: Message-ID: <200602201256.k1KCuVf4007806@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Tracker: New Extras packages that need a sponsor Alias: FE-NEEDSPONSOR https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177841 Bug 177841 depends on bug 181803, which changed state. Bug 181803 Summary: Review Request: scrub https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181803 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NOTABUG Status|ASSIGNED |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rdieter at math.unl.edu Mon Feb 20 13:06:04 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 20 Feb 2006 07:06:04 -0600 Subject: [Fedora-packaging] Re: PLEASE HELP - We need a policy for preventing man page name conflicts In-Reply-To: References: <43F6B501.1040105@cora.nwra.com> Message-ID: <43F9BEBC.5080204@math.unl.edu> Rex Dieter wrote: > Orion Poplawski wrote: > >> Many packages provide man3 (and other) man pages with generic names. >> The case in question in ncarg-devel and allegro-devel which both >> provide man3/line.3.gz. So, what do we do? >> ... >> - rename to something like _? >> Do we always do this? Only if a file conflicts? > Yep. Oops, ambiguous answer. Yep, rename for the latter case (only for conflicts). -- Rex From bugzilla at redhat.com Mon Feb 20 13:02:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 08:02:30 -0500 Subject: [Bug 175502] Review Request: perl-Gtk2-Spell In-Reply-To: Message-ID: <200602201302.k1KD2UG4008773@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Gtk2-Spell https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175502 jwboyer at jdub.homelinux.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|jwboyer at jdub.homelinux.org |cweyl at alumni.drew.edu OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From jwboyer at jdub.homelinux.org 2006-02-20 08:02 EST ------- This package is accepted. Chris, you'll need to apply for CVS access here: https://admin.fedora.redhat.com/accounts/ In the meantime, I've imported the SRPM into CVS. Once you get CVS access, you can request a build and create any branches you'd like. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rdieter at math.unl.edu Mon Feb 20 13:10:33 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 20 Feb 2006 07:10:33 -0600 Subject: static libs ... again In-Reply-To: <43F9BE60.1090705@hhs.nl> References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> <1140243907.21764.402.camel@mccallum.corsepiu.local> <43F9BE60.1090705@hhs.nl> Message-ID: Hans de Goede wrote: > Rex Dieter wrote: >> Ralf, excellent point, and I'm swayed by the argument. If packagers >> really want to include static libs, make it obvious and place them in >> a -static subpkg. >> >> One question to beg here... I maintain several libraries that come >> *only* as static libs(*). At the moment, these pkgs provide *only* a >> -devel pkg (pending upstream fix(es) to allow for shared/dynamic >> libs). Is that acceptable or should these get split too? > Not split, but renamed would be a good so replace -devel with -static. Eek. I still think headers and api docs and such still should be in -devel (especially if there's any likelyhood of a real shared lib existing some day), and that -static should Requires: %{name}-devel > Also I wonder how hard is it to add -fpic -DPIC to the cflags and change > the link command to generate an .so. The only added trouble would be > checking for abi changes on new releases and bumping the .so name a > release. Exactly. I'm of the opinion (in most cases) that if upstream isn't able/willing to do something (like generating shared libs), then neither am I (as packager). -- Rex From rc040203 at freenet.de Mon Feb 20 13:24:06 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 20 Feb 2006 14:24:06 +0100 Subject: static libs ... again In-Reply-To: References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> <1140243907.21764.402.camel@mccallum.corsepiu.local> <43F9BE60.1090705@hhs.nl> Message-ID: <1140441846.21764.558.camel@mccallum.corsepiu.local> On Mon, 2006-02-20 at 07:10 -0600, Rex Dieter wrote: > Hans de Goede wrote: > > Rex Dieter wrote: > > >> Ralf, excellent point, and I'm swayed by the argument. If packagers > >> really want to include static libs, make it obvious and place them in > >> a -static subpkg. > >> > >> One question to beg here... I maintain several libraries that come > >> *only* as static libs(*). At the moment, these pkgs provide *only* a > >> -devel pkg (pending upstream fix(es) to allow for shared/dynamic > >> libs). Is that acceptable or should these get split too? > > > Not split, but renamed would be a good so replace -devel with -static. ACK, plus letting -static provide -devel. For packages having both static and shared libraries I'd, put everything but the static libs into *-devel and let *-static "Requires: *-devel". [BTW: we had discussed this in great dep several months ago on one of this too many fedora lists.] > Eek. I still think headers and api docs and such still should be in > -devel (especially if there's any likelyhood of a real shared lib > existing some day), and that -static should Requires: %{name}-devel Hmm, headers without libs in most cases are useless, but shipping docs in *-devel, even for -static only packages is worth a thought. I am not sure. > > Also I wonder how hard is it to add -fpic -DPIC to the cflags and change > > the link command to generate an .so. The only added trouble would be > > checking for abi changes on new releases and bumping the .so name a > > release. I had done so for one package, I am maintaining in FE, but ... meanwhile regret having done so - Upstream maintainers not being able to handle shared libs don't deserve to be played nice ;-) > Exactly. I'm of the opinion (in most cases) that if upstream isn't > able/willing to do something (like generating shared libs), then neither > am I (as packager). Right, in cases upstream ships half-hearted shared libs with broken shared libs or SONAME (Many of using 0.0.0 actually are broken), I meanwhile would vote of not shipping the shared libs or even dropping the package. ;) Ralf From fedora at leemhuis.info Mon Feb 20 13:35:51 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 20 Feb 2006 14:35:51 +0100 Subject: Packages in CVS with no entry in the owners.list (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140262149.2904.90.camel@localhost.localdomain> <1140265140.2904.135.camel@localhost.localdomain> Message-ID: <1140442551.2625.3.camel@thl.ct.heise.de> Am Montag, den 20.02.2006, 06:42 -0600 schrieb Rex Dieter: > Thorsten Leemhuis wrote: > > >These are only in cvs and have no entry in owners.list > > >- Rex Dieter : kile-i18n > > FYI, kile-i18n is no longer packaged separately from kile, ie. kile-i18n > no longer effectively exists. Well, we either should remove kile-i18n from cvs or add a entry to the owners.list -- otherwise the question will come up multiple times again and will just waste other peoples time. Rex, could you take of that? tia CU thl From rc040203 at freenet.de Mon Feb 20 13:38:39 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 20 Feb 2006 14:38:39 +0100 Subject: [Fedora-packaging] Re: PLEASE HELP - We need a policy for preventing man page name conflicts In-Reply-To: References: <43F6B501.1040105@cora.nwra.com> Message-ID: <1140442719.21764.570.camel@mccallum.corsepiu.local> On Mon, 2006-02-20 at 06:39 -0600, Rex Dieter wrote: > Orion Poplawski wrote: > > Many packages provide man3 (and other) man pages with generic names. The > > case in question in ncarg-devel and allegro-devel which both provide > > man3/line.3.gz. So, what do we do? > > - rename to something like _? > > +1 Works for section 3 but not for section 1 (application man packages). There, each man page should match the name of the tool it is trying to describe. But, if section 1 man pages clash, the apps probably also do. > >Is there an easy way to find conflicts before > > packaging? > > Not that I'm aware. It's close to impossible, because man page conflicts normally occur at installation time, due to parallel installations of alternative implementations (or badly designed packages). > > - suffixes .3 ? Can man handle this? > > Another possibility, but I'm unfamiliar with that convention. It's the traditional standard on many non-Linux *nixes. Unfortunately Linux' "man" doesn't handle these sufficiently well. [Install Inventor-devel and Coin2-devel from FE, if you'd like to experiment with this convention. .3iv vs. .3] Ralf From bugzilla at redhat.com Mon Feb 20 13:53:43 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 08:53:43 -0500 Subject: [Bug 179709] Review Request: hdf4_handler - HDF4 data handler for the OPeNDAP Data server In-Reply-To: Message-ID: <200602201353.k1KDrhHQ017460@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: hdf4_handler - HDF4 data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179709 ed at eh3.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From ed at eh3.com 2006-02-20 08:53 EST ------- Both items from comment #2 are fixed so its APPROVED. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 20 13:55:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 08:55:44 -0500 Subject: [Bug 179708] Review Request: freeform_handler - FreeForm data handler for the OPeNDAP Data server In-Reply-To: Message-ID: <200602201355.k1KDtiSW017843@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: freeform_handler - FreeForm data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179708 ed at eh3.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From ed at eh3.com 2006-02-20 08:55 EST ------- Both items from comment #2 are fixed so its APPROVED. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From ivg2 at cornell.edu Mon Feb 20 14:17:41 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 20 Feb 2006 09:17:41 -0500 Subject: [Fedora-packaging] Re: PLEASE HELP - We need a policy for preventing man page name conflicts In-Reply-To: <1140442719.21764.570.camel@mccallum.corsepiu.local> References: <43F6B501.1040105@cora.nwra.com> <1140442719.21764.570.camel@mccallum.corsepiu.local> Message-ID: <43F9CF85.4010502@cornell.edu> > Works for section 3 but not for section 1 (application man packages). > There, each man page should match the name of the tool it is trying to > describe. > > But, if section 1 man pages clash, the apps probably also do. > And in section 3 they don't? I suggest efforts would be better directed at fixing the real problem - i.e. the library namespace. Having an API that calls functions line() and such means it's just a question of time before you run into header conflicts where a program attempts to include two headers with the same function name (or statically link against two libraries with the same symbol, whether the function is used or not)... or link against the library and have a local function called line() defined. I suppose programming language makes a difference here, but at least this should apply to C code. From bugzilla at redhat.com Mon Feb 20 14:34:03 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 09:34:03 -0500 Subject: [Bug 181974] Review Request: mod_geoip - Apache module for GeoIP lookups In-Reply-To: Message-ID: <200602201434.k1KEY35V024906@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mod_geoip - Apache module for GeoIP lookups https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181974 ------- Additional Comments From tibbs at math.uh.edu 2006-02-20 09:34 EST ------- I implicitly understood your reasoning for using mod_geoip and not mod_geoip2 and didn't see it as a problem. The name of the generated module is mod_geoip.so and the upstream name of the package is mod_geoip: http://www.maxmind.com/app/mod_geoip FYI, Mandriva seems to ship this package as mod_geoip as well: http://rpmfind.net/linux/RPM/mandriva/devel/cooker/cooker/media/contrib/Mandriva.html About the Requires:, I understand why it's there but I didn't quite get what use a Requires: of "httpd-mmn = missing" (in the case that /usr/include/httpd/.mmn doesn't exist) is going to be. I suppose it's just defensive programming, which is no problem with me. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rc040203 at freenet.de Mon Feb 20 14:40:25 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 20 Feb 2006 15:40:25 +0100 Subject: [Fedora-packaging] Re: PLEASE HELP - We need a policy for preventing man page name conflicts In-Reply-To: <43F9CF85.4010502@cornell.edu> References: <43F6B501.1040105@cora.nwra.com> <1140442719.21764.570.camel@mccallum.corsepiu.local> <43F9CF85.4010502@cornell.edu> Message-ID: <1140446425.21764.581.camel@mccallum.corsepiu.local> On Mon, 2006-02-20 at 09:17 -0500, Ivan Gyurdiev wrote: > > Works for section 3 but not for section 1 (application man packages). > > There, each man page should match the name of the tool it is trying to > > describe. > > > > But, if section 1 man pages clash, the apps probably also do. > > > And in section 3 they don't? section 3 contains library API docs, corresponding to libraries. While apps must be unique, and libraries and the APIs not necessarily are. There may well be reasons why one API can be implemented by several library. > I suggest efforts would be better directed at fixing the real problem - > i.e. the library namespace. This doesn't work - Check the Inventor and Coin2 examples I tried to point you to. They both implement the same API (Coin2 is a clone of Inventor), both packages can be installed in parallel and do not conflict. Both are licensed differently (LGPL vs. GPL), nor are both libraries technically 100% compatible. I.e. there are good reasons to have them both. Ralf From ivg2 at cornell.edu Mon Feb 20 14:46:02 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 20 Feb 2006 09:46:02 -0500 Subject: [Fedora-packaging] Re: PLEASE HELP - We need a policy for preventing man page name conflicts In-Reply-To: <1140446425.21764.581.camel@mccallum.corsepiu.local> References: <43F6B501.1040105@cora.nwra.com> <1140442719.21764.570.camel@mccallum.corsepiu.local> <43F9CF85.4010502@cornell.edu> <1140446425.21764.581.camel@mccallum.corsepiu.local> Message-ID: <43F9D62A.30408@cornell.edu> >> I suggest efforts would be better directed at fixing the real problem - >> i.e. the library namespace. >> > This doesn't work - Check the Inventor and Coin2 examples I tried to > point you to. > I haven't looked at that issue, but the original poster referred to the bug I filed (allegro-devel vs ncarg-devel), which, as far as I can tell is caused by poor API practices, not by one package cloning another. I guess in your case the situation is different, and a solution at the packaging level would be needed. From bugzilla at redhat.com Mon Feb 20 14:46:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 09:46:48 -0500 Subject: [Bug 181997] Review Request: gpc - The GNU Pascal compiler In-Reply-To: Message-ID: <200602201446.k1KEkmRG027042@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gpc - The GNU Pascal compiler https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181997 ------- Additional Comments From tibbs at math.uh.edu 2006-02-20 09:46 EST ------- Thanks for the patch. I am curious, though: why does share/info/dir not exist for you? The package built everywhere I could test it, including mock on FC3, FC4 and development i386 and x86_64. I didn't use "rm -f" in order to find these kinds of failures. I don't really agree that this should live outside of /usr/lib/gcc, but it's not exactly a big deal. I will apply the path and force a new set of builds (which will take a while) and present a respun package if everything goes OK. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 14:50:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 09:50:52 -0500 Subject: [Bug 181974] Review Request: mod_geoip - Apache module for GeoIP lookups In-Reply-To: Message-ID: <200602201450.k1KEoqaQ027883@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mod_geoip - Apache module for GeoIP lookups https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181974 ------- Additional Comments From rc040203 at freenet.de 2006-02-20 09:50 EST ------- (In reply to comment #4) > I implicitly understood your reasoning for using mod_geoip and not mod_geoip2 > and didn't see it as a problem. The name of the generated module is > mod_geoip.so and the upstream name of the package is mod_geoip: > http://www.maxmind.com/app/mod_geoip I asked because of the mod_perl vs. mod_perl2 idocy. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 14:56:12 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 09:56:12 -0500 Subject: [Bug 181997] Review Request: gpc - The GNU Pascal compiler In-Reply-To: Message-ID: <200602201456.k1KEuCVa028953@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gpc - The GNU Pascal compiler https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181997 ------- Additional Comments From rc040203 at freenet.de 2006-02-20 09:56 EST ------- (In reply to comment #8) > Thanks for the patch. I am curious, though: why does share/info/dir not exist > for you? I don't know, nor did I check. I just rebuilt your src.rpm under my normal build user account (not in mock), which had tripped over this error. > I don't really agree that this should live outside of /usr/lib/gcc, but it's > not exactly a big deal. Your /usr/lib/gcc files would conflict with a native gcc-3.4.5. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 15:05:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 10:05:44 -0500 Subject: [Bug 181997] Review Request: gpc - The GNU Pascal compiler In-Reply-To: Message-ID: <200602201505.k1KF5inV030652@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gpc - The GNU Pascal compiler https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181997 ------- Additional Comments From tibbs at math.uh.edu 2006-02-20 10:05 EST ------- > Your /usr/lib/gcc files would conflict with a native gcc-3.4.5. That's what the whole %{matching_gcc} bit in the spec is about. On FC2 and FC3 I can actually build this package against the same version of GCC that is installed on the system; the package then consists just of the front end and documentation. There is no conflict against the installed GCC. Unfortunately GPC has yet to be ported to GCC4, so there's no chance of doing that on FC4. In any case, it doesn't bother me to change it, but I did go to some effort to ensure that there is no conflict with a native gcc. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 15:23:25 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 10:23:25 -0500 Subject: [Bug 180571] Review Request: puppet In-Reply-To: Message-ID: <200602201523.k1KFNPmp001282@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: puppet https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180571 ------- Additional Comments From tibbs at math.uh.edu 2006-02-20 10:23 EST ------- Uhh, the package has a new user. The wiki has instructions on how this is to be done in Extras. Are you saying that actually following the instructions in the Wiki needs to be justified? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From roozbeh at farsiweb.info Mon Feb 20 15:28:49 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Mon, 20 Feb 2006 18:58:49 +0330 Subject: deciphering a build failure Message-ID: <1140449329.3729.12.camel@tameshk.farsiweb.info> I'm having a build failure that I can't decode, and I guess there may be something wrong with either mock or the ppc1 setup (that builds the noarch packages). http://buildsys.fedoraproject.org/build-status/job.psp?uid=4947 Could someone take a look? My best guess is bad FC-4 packages. roozbeh From j.w.r.degoede at hhs.nl Mon Feb 20 15:47:37 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 20 Feb 2006 16:47:37 +0100 Subject: static libs ... again In-Reply-To: References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> <1140243907.21764.402.camel@mccallum.corsepiu.local> <43F9BE60.1090705@hhs.nl> Message-ID: <43F9E499.9050109@hhs.nl> Rex Dieter wrote: > Hans de Goede wrote: >> Rex Dieter wrote: > >>> Ralf, excellent point, and I'm swayed by the argument. If packagers >>> really want to include static libs, make it obvious and place them in >>> a -static subpkg. >>> >>> One question to beg here... I maintain several libraries that come >>> *only* as static libs(*). At the moment, these pkgs provide *only* a >>> -devel pkg (pending upstream fix(es) to allow for shared/dynamic >>> libs). Is that acceptable or should these get split too? > >> Not split, but renamed would be a good so replace -devel with -static. > > Eek. I still think headers and api docs and such still should be in > -devel (especially if there's any likelyhood of a real shared lib > existing some day), and that -static should Requires: %{name}-devel > >> Also I wonder how hard is it to add -fpic -DPIC to the cflags and >> change the link command to generate an .so. The only added trouble >> would be checking for abi changes on new releases and bumping the .so >> name a release. > > Exactly. I'm of the opinion (in most cases) that if upstream isn't > able/willing to do something (like generating shared libs), then neither > am I (as packager). > Huh, You say "Exactly" as in I agree with you and then you continue with saying that you're not willing todo this, I'm confused now. Regards, hans From buildsys at fedoraproject.org Mon Feb 20 15:48:39 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 20 Feb 2006 10:48:39 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060220154839.8AC988011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 1 dap-server-3.5.3-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon Feb 20 15:48:42 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 20 Feb 2006 10:48:42 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060220154842.2E3948011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 1 dap-server-3.5.3-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon Feb 20 15:48:47 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 20 Feb 2006 10:48:47 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060220154847.8A0048011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 10 byzanz-0.1.0-6.fc5 dap-netcdf_handler-3.5.2-2.fc5 fortune-mod-1.99.1-5.fc5 gnome-applet-rhythmbox-0.1.11-1.fc5 libeXosip2-2.2.2-4.fc5 mgopen-fonts-0.20050515-4.fc5 python-simpy-1.6.1-4.fc5 tetex-font-cm-lgc-0.5-7.fc5 tetex-font-kerkis-2.0-11.fc5 translate-toolkit-0.8-1.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From rdieter at math.unl.edu Mon Feb 20 15:58:21 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 20 Feb 2006 09:58:21 -0600 Subject: static libs ... again In-Reply-To: <43F9E499.9050109@hhs.nl> References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> <1140243907.21764.402.camel@mccallum.corsepiu.local> <43F9BE60.1090705@hhs.nl> <43F9E499.9050109@hhs.nl> Message-ID: Hans de Goede wrote: > Rex Dieter wrote: >> Eek. I still think headers and api docs and such still should be in >> -devel (especially if there's any likelyhood of a real shared lib >> existing some day), and that -static should Requires: %{name}-devel >>> Also I wonder how hard is it to add -fpic -DPIC to the cflags and >>> change the link command to generate an .so. The only added trouble >>> would be checking for abi changes on new releases and bumping the .so >>> name a release. >> Exactly. I'm of the opinion (in most cases) that if upstream isn't >> able/willing to do something (like generating shared libs), then >> neither am I (as packager). > You say "Exactly" as in I agree with you and then you continue with > saying that you're not willing todo this, I'm confused now. Exactly, as in "The only added trouble..." part. (-: As I said, if it's really not so hard, let upstream do it, per Fedora's mantra "Upstream, upstream, upstream..." -- Rex From j.w.r.degoede at hhs.nl Mon Feb 20 16:18:07 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 20 Feb 2006 17:18:07 +0100 Subject: static libs ... again In-Reply-To: References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> <1140243907.21764.402.camel@mccallum.corsepiu.local> <43F9BE60.1090705@hhs.nl> <43F9E499.9050109@hhs.nl> Message-ID: <43F9EBBF.7030904@hhs.nl> Rex Dieter wrote: > Hans de Goede wrote: >> Rex Dieter wrote: > >>> Eek. I still think headers and api docs and such still should be >>> in -devel (especially if there's any likelyhood of a real shared lib >>> existing some day), and that -static should Requires: %{name}-devel > >>>> Also I wonder how hard is it to add -fpic -DPIC to the cflags and >>>> change the link command to generate an .so. The only added trouble >>>> would be checking for abi changes on new releases and bumping the >>>> .so name a release. > >>> Exactly. I'm of the opinion (in most cases) that if upstream isn't >>> able/willing to do something (like generating shared libs), then >>> neither am I (as packager). > >> You say "Exactly" as in I agree with you and then you continue with >> saying that you're not willing todo this, I'm confused now. > > Exactly, as in "The only added trouble..." part. (-: > > As I said, if it's really not so hard, let upstream do it, per Fedora's > mantra "Upstream, upstream, upstream..." > Yes, But sometimes upstream doesn't, because they dont care about this for example, yet it would still be worth the trouble. I believe this needs more discussion we all seem to agree that static libs should be provided if possible, since in most cases even if upstream doesn't do it it isn't all that much work, why don't we do this. I'm planning on packaging some software that uses one of these only has -devel with static libs packages with no .so and I'm actually also planning on filing an RFE against this package for proper .so files. Why shouldn't a packager do this? Upstream is what we want, but unfortunatly is not always what we get. Regards, Hans From bugzilla at redhat.com Mon Feb 20 16:13:23 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 11:13:23 -0500 Subject: [Bug 181997] Review Request: gpc - The GNU Pascal compiler In-Reply-To: Message-ID: <200602201613.k1KGDN53012208@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gpc - The GNU Pascal compiler https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181997 ------- Additional Comments From rc040203 at freenet.de 2006-02-20 11:13 EST ------- (In reply to comment #10) > > Your /usr/lib/gcc files would conflict with a native gcc-3.4.5. > > That's what the whole %{matching_gcc} bit in the spec is about. Well, that's how you adapt gpc to gcc, but you can't control the opposite direction. E.g. FE or FC adding a gcc-3.4.5 to FC4 after gpc had been introduced to FE would raise conflicts. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rdieter at math.unl.edu Mon Feb 20 16:25:03 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 20 Feb 2006 10:25:03 -0600 Subject: static libs ... again In-Reply-To: <43F9EBBF.7030904@hhs.nl> References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> <1140243907.21764.402.camel@mccallum.corsepiu.local> <43F9BE60.1090705@hhs.nl> <43F9E499.9050109@hhs.nl> <43F9EBBF.7030904@hhs.nl> Message-ID: Hans de Goede wrote: > But sometimes upstream doesn't, because they dont care about this for > example, yet it would still be worth the trouble. At the packagers discretion, sure, if they're willing to do the extra work, testing, troubleshooting. > I believe this needs > more discussion we all seem to agree that static libs should be provided > if possible, ??? There have been quite a few dissenters... including my own stance: static libs should in general be omitted, but allowing for exceptions(*) (*) If there is good reason otherwise, and packager is willing. -- Rex From dcbw at redhat.com Mon Feb 20 16:22:15 2006 From: dcbw at redhat.com (Dan Williams) Date: Mon, 20 Feb 2006 11:22:15 -0500 Subject: deciphering a build failure In-Reply-To: <1140449329.3729.12.camel@tameshk.farsiweb.info> References: <1140449329.3729.12.camel@tameshk.farsiweb.info> Message-ID: <1140452536.9676.10.camel@localhost.localdomain> On Mon, 2006-02-20 at 18:58 +0330, Roozbeh Pournader wrote: > I'm having a build failure that I can't decode, and I guess there may be > something wrong with either mock or the ppc1 setup (that builds the > noarch packages). > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=4947 > > Could someone take a look? My best guess is bad FC-4 packages. Wow, that is really wierd. Could you 'requeue' the job and see if it happens again? If so, I'll see what I can find out. I've seen this before, but it's not very reproducible. Dan From notting at redhat.com Mon Feb 20 16:45:54 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 20 Feb 2006 11:45:54 -0500 Subject: Crontab and init scripts In-Reply-To: <3237e4410602200046r3d9f871h2d4ba57c4556a80e@mail.gmail.com> References: <3237e4410602200046r3d9f871h2d4ba57c4556a80e@mail.gmail.com> Message-ID: <20060220164554.GB17008@devserv.devel.redhat.com> Mike McGrath (mmcgrath at fedoraproject.org) said: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182033 > > What's Fedora policy on this? I guess I'm mostly just interested in > being consistant. One option is provided in the bug report. In this > instance I could also add an exit to the config with a comment about > removing the exit after it has been configured. > > Yum I know is an example of a script that runs via cron that also has > a init startup script. While I'm not *that* fond of the yum approach (it's sort of a hack), it's a better solution than running cron scripts for uninstalled things. Bill From skvidal at linux.duke.edu Mon Feb 20 16:47:15 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 20 Feb 2006 11:47:15 -0500 Subject: Crontab and init scripts In-Reply-To: <20060220164554.GB17008@devserv.devel.redhat.com> References: <3237e4410602200046r3d9f871h2d4ba57c4556a80e@mail.gmail.com> <20060220164554.GB17008@devserv.devel.redhat.com> Message-ID: <1140454035.23624.23.camel@cutter> On Mon, 2006-02-20 at 11:45 -0500, Bill Nottingham wrote: > Mike McGrath (mmcgrath at fedoraproject.org) said: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182033 > > > > What's Fedora policy on this? I guess I'm mostly just interested in > > being consistant. One option is provided in the bug report. In this > > instance I could also add an exit to the config with a comment about > > removing the exit after it has been configured. > > > > Yum I know is an example of a script that runs via cron that also has > > a init startup script. > > While I'm not *that* fond of the yum approach (it's sort of a hack), open to suggestions on better ways of making sure cron jobs should or should not run :) -sv From notting at redhat.com Mon Feb 20 16:47:01 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 20 Feb 2006 11:47:01 -0500 Subject: Crontab and init scripts In-Reply-To: <20060220164554.GB17008@devserv.devel.redhat.com> References: <3237e4410602200046r3d9f871h2d4ba57c4556a80e@mail.gmail.com> <20060220164554.GB17008@devserv.devel.redhat.com> Message-ID: <20060220164701.GC17008@devserv.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Mike McGrath (mmcgrath at fedoraproject.org) said: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182033 > > > > What's Fedora policy on this? I guess I'm mostly just interested in > > being consistant. One option is provided in the bug report. In this > > instance I could also add an exit to the config with a comment about > > removing the exit after it has been configured. > > > > Yum I know is an example of a script that runs via cron that also has > > a init startup script. > > While I'm not *that* fond of the yum approach (it's sort of a hack), > it's a better solution than running cron scripts for uninstalled things. Make that 'unconfigured/not running', not 'uninstalled', of course... Bill From bugzilla at redhat.com Mon Feb 20 16:56:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 11:56:47 -0500 Subject: [Bug 181997] Review Request: gpc - The GNU Pascal compiler In-Reply-To: Message-ID: <200602201656.k1KGulTj028654@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gpc - The GNU Pascal compiler https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181997 ------- Additional Comments From tibbs at math.uh.edu 2006-02-20 11:56 EST ------- I applied the patch, fixed some breakage it caused switched $RPM_OPT_FLAGS to %{optflags}, and tested builds in mock (development, i386 and x86_64). rpmlint output is unchanged. New spec: http://www.math.uh.edu/~tibbs/rpms/gpc/gpc.spec New SRPM: http://www.math.uh.edu/~tibbs/rpms/gpc/gpc-3.4.5_20060215-4.src.rpm By the way, could you point me to the proper point in the packaging guidelines where I could find the RPM_OPT_FLAGS requirement? I can't seem to find it. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 17:12:05 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 12:12:05 -0500 Subject: [Bug 181974] Review Request: mod_geoip - Apache module for GeoIP lookups In-Reply-To: Message-ID: <200602201712.k1KHC5rl000912@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mod_geoip - Apache module for GeoIP lookups https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181974 ------- Additional Comments From ville.skytta at iki.fi 2006-02-20 12:11 EST ------- "httpd-mmn = missing" comes from some Core packages, so you'll have to ask there to get a definite answer. But at least it allows the specfile syntax to be ok even when httpd-devel is not installed, enabling for example rpm -q --specfile queries in those scenarios. If the "|| echo missing" part would not be there, it wouldn't work. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 17:17:45 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 12:17:45 -0500 Subject: [Bug 182077] Review Request: cfv - utility to test and create checksums In-Reply-To: Message-ID: <200602201717.k1KHHjkg002136@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cfv - utility to test and create checksums https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182077 Jochen at herr-schmitt.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NEXTRELEASE AssignedTo|bugzilla-sink at leemhuis.info |Jochen at herr-schmitt.de OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-20 12:17 EST ------- Good: * Local build fine. + rpmlint fine. + md5sum of source tar is fine. + mock build fine. + start worked APPROVED. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 17:24:29 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 12:24:29 -0500 Subject: [Bug 181997] Review Request: gpc - The GNU Pascal compiler In-Reply-To: Message-ID: <200602201724.k1KHOTPp003916@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gpc - The GNU Pascal compiler https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181997 ------- Additional Comments From ville.skytta at iki.fi 2006-02-20 12:24 EST ------- (In reply to comment #8) > why does share/info/dir not exist for you? The creation of that file during "make install" in most cases depends on whether install-info is available in $PATH or not. It may or may not be installed depending on the dep chain, and it's not in the default $PATH of regular users even if installed; it's in /sbin. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 17:27:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 12:27:08 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602201727.k1KHR8ca004544@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From ed at eh3.com 2006-02-20 12:27 EST ------- Hi Jason, thank you for looking into this! I've locally built, installed, and started testing the openmpi and lam versions that you list in comment #24 above: # md5sum openmpi-1.0.1-1.src.rpm lam-7.1.1-10.FC5.src.rpm b4fe04dbdd4a3a80a20e9e4d68fd5b85 openmpi-1.0.1-1.src.rpm 80dfb5f422480835013ccc2b1ea7792c lam-7.1.1-10.FC5.src.rpm Both built and installed without any problems (AFAICT) on a "stock" FC4 system (not yet tried builds in mock -- but will next). The first problem I've run into are links such as: cd /usr/share/openmpi/bin/ ls -l mpicc lrwxrwxrwx 1 root root 59 Feb 17 23:13 mpicc -> ../(/var/tmp/openmpi-1.0.1-1-root-edhill//usr/bin)/om-mpicc which seems to be a failed sed invocation. I'll test some more and post a thorough set of comments as soon as I have a chance. And thanks again! -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 20 17:42:17 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 12:42:17 -0500 Subject: [Bug 182077] Review Request: cfv - utility to test and create checksums In-Reply-To: Message-ID: <200602201742.k1KHgH0H007716@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cfv - utility to test and create checksums https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182077 ------- Additional Comments From bdpepple at ameritech.net 2006-02-20 12:42 EST ------- Ummm, any reason why you closed this before it was imported in FE? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 17:50:54 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 12:50:54 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602201750.k1KHosoA009562@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From ed at eh3.com 2006-02-20 12:50 EST ------- Problem in comment #27 exists for the referenced lam version also: ls -l /usr/share/lam/bin returns a directory full of broken links such as: lrwxrwxrwx 1 root root 47 Feb 17 22:30 mpicc -> ../(/var/tmp/lam-7.1.1-root//usr/bin)/lam-mpicc but the lam* binaries in /usr/bin work nicely such as: /usr/bin/lam-mpicc -o mpi_hi mpi_hi.c /usr/bin/lamboot /usr/bin/lam-mpirun -np 2 ./mpi_hi XXX: hello world XXX: hello world -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 20 17:51:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 12:51:49 -0500 Subject: [Bug 182122] New: Review Request: multitail Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 Summary: Review Request: multitail Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: folkert at vanheusden.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.vanheusden.com/multitail/multitail.spec SRPM Name or Url: http://www.vanheusden.com/multitail/multitail-3.8.6-0.src.rpm Description: Lets you view several logfiles at once in a window, with colors and filtering. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 17:53:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 12:53:35 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602201753.k1KHrZ8e010119@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 folkert at vanheusden.com changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Package Review |munin ------- Additional Comments From folkert at vanheusden.com 2006-02-20 12:53 EST ------- MultiTail lets you view one or multiple files like the original tail program. The difference is that it creates multiple windows on your console (with ncurses). It can also monitor wildcards: if another file matching the wildcard has a more recent modification date, it will automatically switch to that file. That way you can, for example, monitor a complete directory of files. Merging of 2 or even more logfiles is possible. It can also use colors while displaying the logfiles (through regular expressions), for faster recognition of what is important and what not. It can also filter lines (again with regular expressions). It has interactive menus for editing given regular expressions and deleting and adding windows. One can also have windows with the output of shell scripts and other software. When viewing the output of external software, MultiTail can mimic the functionality of tools like 'watch' and such. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 18:06:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 13:06:48 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602201806.k1KI6m2F012390@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From jvdias at redhat.com 2006-02-20 13:06 EST ------- Hi - RE: broken links: > lrwxrwxrwx 1 root root 59 Feb 17 23:13 mpicc -> > ../(/var/tmp/openmpi-1.0.1-1-root-edhill//usr/bin)/om-mpicc This appears to be due to a bug in FC-4 bash - on FC-5 / Rawhide, in the openmpi/devel/ directory, I get: $ (. relpath.sh; relpath /a/b/c/d /a/b/d/c/e) ../../../c/d which is correct, and leads to correct links being created (see $rpath in .spec file). But on FC-4, I get: $ (. relpath.sh; relpath /a/b/c/d /a/b/d/c/e) ../(/a/b/c/d) which leads to the incorrect links. I'm now fixing relpath.sh to work correctly on FC-4, and will submit a new version ASAP. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 20 18:10:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 13:10:59 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602201810.k1KIAx2h013293@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From jvdias at redhat.com 2006-02-20 13:10 EST ------- Aha! this fixes relpath.sh on FC-4: $ sed -i 's/local//g' relpath.sh The 'local' feature for variables is not properly implemented in FC-4 bash. I'll submit these changes (and the change to fix the mpif90 link) now. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From ville.skytta at iki.fi Mon Feb 20 18:18:04 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 20 Feb 2006 20:18:04 +0200 Subject: ppc builder problem Message-ID: <1140459484.25870.11.camel@bobcat.mine.nu> Another ppc builder problem, happened twice so far: http://buildsys.fedoraproject.org/logs/fedora-4-extras/4956-perl-Config-General-2.31-1.fc4/noarch/ [...] mailcap noarch 2.1.19-1 warning: findutils-4.2.20-1: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 warning: perl-XML-SAX-0.12-7: Header V3 DSA signature: NOKEY, key ID db42a60e warning: boa-0.94.14-0.2.rc21.fc4: Header V3 DSA signature: NOKEY, key ID 1ac70ce6 warning: waiting for transaction lock on /var/lib/rpm/__db.000 warning: user apache does not exist - using root warning: group apache does not exist - using root ls: readlink:: No such file or directory ls: file: No such file or directory ls: expected: No such file or directory cp: cannot stat `/dev/md1': No such file or directory core 14 k mingetty ppc 1.07-5 core 18 k [...] By the way, the above indicates another problem somewhere: for some reason, boa gets pulled in (probably through the "webserver" Provides), and something relies on the apache user/group being available. This is on FC-4 but I checked devel, and at least mailman seems to have a related issue. I don't see mailman participating in the above transaction though. From bugzilla at redhat.com Mon Feb 20 18:17:41 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 13:17:41 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602201817.k1KIHfYe014641@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 ------- Additional Comments From udovdh at xs4all.nl 2006-02-20 13:17 EST ------- http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions Please remove gcc and make from BuildRequires -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From skvidal at linux.duke.edu Mon Feb 20 18:24:03 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 20 Feb 2006 13:24:03 -0500 Subject: ppc builder problem In-Reply-To: <1140459484.25870.11.camel@bobcat.mine.nu> References: <1140459484.25870.11.camel@bobcat.mine.nu> Message-ID: <1140459843.23624.25.camel@cutter> On Mon, 2006-02-20 at 20:18 +0200, Ville Skytt? wrote: > Another ppc builder problem, happened twice so far: > http://buildsys.fedoraproject.org/logs/fedora-4-extras/4956-perl-Config-General-2.31-1.fc4/noarch/ > > [...] > mailcap noarch 2.1.19-1 warning: > findutils-4.2.20-1: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 > warning: perl-XML-SAX-0.12-7: Header V3 DSA signature: NOKEY, key ID db42a60e > warning: boa-0.94.14-0.2.rc21.fc4: Header V3 DSA signature: NOKEY, key ID 1ac70ce6 > warning: waiting for transaction lock on /var/lib/rpm/__db.000 > warning: user apache does not exist - using root > warning: group apache does not exist - using root > ls: readlink:: No such file or directory > ls: file: No such file or directory > ls: expected: No such file or directory > cp: cannot stat `/dev/md1': No such file or directory > core 14 k > mingetty ppc 1.07-5 core 18 k > [...] > > By the way, the above indicates another problem somewhere: for some > reason, boa gets pulled in (probably through the "webserver" Provides), > and something relies on the apache user/group being available. This is > on FC-4 but I checked devel, and at least mailman seems to have a > related issue. I don't see mailman participating in the above > transaction though. boa gets pulled in b/c it is the package with the shortest username providing 'webserver' -sv From bugzilla at redhat.com Mon Feb 20 18:21:57 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 13:21:57 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602201821.k1KILvhZ016060@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 ------- Additional Comments From folkert at vanheusden.com 2006-02-20 13:21 EST ------- done -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From roozbeh at farsiweb.info Mon Feb 20 18:28:19 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Mon, 20 Feb 2006 21:58:19 +0330 Subject: deciphering a build failure In-Reply-To: <1140452536.9676.10.camel@localhost.localdomain> References: <1140449329.3729.12.camel@tameshk.farsiweb.info> <1140452536.9676.10.camel@localhost.localdomain> Message-ID: <1140460100.3729.15.camel@tameshk.farsiweb.info> ??? ??????? 2006-02-20 ???? 11:22 -0500? Dan Williams ????: > On Mon, 2006-02-20 at 18:58 +0330, Roozbeh Pournader wrote: > > I'm having a build failure that I can't decode, and I guess there may be > > something wrong with either mock or the ppc1 setup (that builds the > > noarch packages). > > > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=4947 > > > > Could someone take a look? My best guess is bad FC-4 packages. > > Wow, that is really wierd. Could you 'requeue' the job and see if it > happens again? If so, I'll see what I can find out. I've seen this > before, but it's not very reproducible. I just requeued the job, and it failed again. So it seems that it's reproducible this time. Would you please take a look? roozbeh From bugzilla at redhat.com Mon Feb 20 18:24:31 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 13:24:31 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602201824.k1KIOVb6016678@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 ------- Additional Comments From udovdh at xs4all.nl 2006-02-20 13:24 EST ------- # rpmlint /usr/src/redhat/SRPMS/multitail-3.8.6-0.src.rpm W: multitail strange-permission multitail-3.8.6.tgz 0750 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From ville.skytta at iki.fi Mon Feb 20 18:31:19 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 20 Feb 2006 20:31:19 +0200 Subject: ppc builder problem In-Reply-To: <1140459843.23624.25.camel@cutter> References: <1140459484.25870.11.camel@bobcat.mine.nu> <1140459843.23624.25.camel@cutter> Message-ID: <1140460279.25870.16.camel@bobcat.mine.nu> On Mon, 2006-02-20 at 13:24 -0500, seth vidal wrote: > On Mon, 2006-02-20 at 20:18 +0200, Ville Skytt? wrote: > > By the way, the above indicates another problem somewhere: for some > > reason, boa gets pulled in (probably through the "webserver" Provides), > > and something relies on the apache user/group being available. This is > > on FC-4 but I checked devel, and at least mailman seems to have a > > related issue. I don't see mailman participating in the above > > transaction though. > > boa gets pulled in b/c it is the package with the shortest username > providing 'webserver' Um, "s/shortest username/shortest package name/" ? The mailman issue is now https://bugzilla.redhat.com/182131 but I think it's not the culprit here. From skvidal at linux.duke.edu Mon Feb 20 18:32:34 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 20 Feb 2006 13:32:34 -0500 Subject: ppc builder problem In-Reply-To: <1140460279.25870.16.camel@bobcat.mine.nu> References: <1140459484.25870.11.camel@bobcat.mine.nu> <1140459843.23624.25.camel@cutter> <1140460279.25870.16.camel@bobcat.mine.nu> Message-ID: <1140460354.23624.27.camel@cutter> On Mon, 2006-02-20 at 20:31 +0200, Ville Skytt? wrote: > On Mon, 2006-02-20 at 13:24 -0500, seth vidal wrote: > > On Mon, 2006-02-20 at 20:18 +0200, Ville Skytt? wrote: > > > > By the way, the above indicates another problem somewhere: for some > > > reason, boa gets pulled in (probably through the "webserver" Provides), > > > and something relies on the apache user/group being available. This is > > > on FC-4 but I checked devel, and at least mailman seems to have a > > > related issue. I don't see mailman participating in the above > > > transaction though. > > > > boa gets pulled in b/c it is the package with the shortest username > > providing 'webserver' > > Um, "s/shortest username/shortest package name/" ? yah - sorry - shortest package name - my brain isn't quite on right now. > > The mailman issue is now https://bugzilla.redhat.com/182131 but I think > it's not the culprit here. -sv From j.w.r.degoede at hhs.nl Mon Feb 20 18:47:58 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 20 Feb 2006 19:47:58 +0100 Subject: static libs ... again In-Reply-To: References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> <1140243907.21764.402.camel@mccallum.corsepiu.local> <43F9BE60.1090705@hhs.nl> <43F9E499.9050109@hhs.nl> <43F9EBBF.7030904@hhs.nl> Message-ID: <43FA0EDE.9020301@hhs.nl> Rex Dieter wrote: >> I believe this needs more discussion we all seem to agree that static >> libs should be provided if possible, > > ??? > There have been quite a few dissenters... including my own stance: > static libs should in general be omitted, but allowing for exceptions(*) > > (*) If there is good reason otherwise, and packager is willing. > > Erm, Big stupid typo-ish mistake: I meant to write (s/provided/avoided/): I believe this needs more discussion we all seem to agree that static libs should be avoided if possible, Regards, Hans From orion at cora.nwra.com Mon Feb 20 18:34:13 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 20 Feb 2006 11:34:13 -0700 Subject: deciphering a build failure In-Reply-To: <1140449329.3729.12.camel@tameshk.farsiweb.info> References: <1140449329.3729.12.camel@tameshk.farsiweb.info> Message-ID: <43FA0BA5.2050405@cora.nwra.com> Roozbeh Pournader wrote: > I'm having a build failure that I can't decode, and I guess there may be > something wrong with either mock or the ppc1 setup (that builds the > noarch packages). > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=4947 > > Could someone take a look? My best guess is bad FC-4 packages. > > roozbeh > > Another one: http://buildsys.fedoraproject.org/logs/fedora-4-extras/4955-hdf-4.2r1-6.fc4/i386/root.log i386 this time. Definitely a bad package somewhere. Would be nice if stdout and stderr were synced in these logs. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From bugzilla at redhat.com Mon Feb 20 18:32:45 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 13:32:45 -0500 Subject: [Bug 182077] Review Request: cfv - utility to test and create checksums In-Reply-To: Message-ID: <200602201832.k1KIWj6v018605@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cfv - utility to test and create checksums https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182077 Jochen at herr-schmitt.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|NEXTRELEASE | ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-20 13:32 EST ------- No, perhaps i thought, that I should close it, when it's ready to import into cvs. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From orion at cora.nwra.com Mon Feb 20 18:38:38 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 20 Feb 2006 11:38:38 -0700 Subject: [Fedora-packaging] Re: PLEASE HELP - We need a policy for preventing man page name conflicts In-Reply-To: <1140442719.21764.570.camel@mccallum.corsepiu.local> References: <43F6B501.1040105@cora.nwra.com> <1140442719.21764.570.camel@mccallum.corsepiu.local> Message-ID: <43FA0CAE.8050309@cora.nwra.com> Ralf Corsepius wrote: > On Mon, 2006-02-20 at 06:39 -0600, Rex Dieter wrote: >> Orion Poplawski wrote: >>> Is there an easy way to find conflicts before >>> packaging? >> Not that I'm aware. > It's close to impossible, because man page conflicts normally occur at > installation time, due to parallel installations of alternative > implementations (or badly designed packages). > I was hoping for some repoquery magic.... Anyone? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From orion at cora.nwra.com Mon Feb 20 18:45:52 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 20 Feb 2006 11:45:52 -0700 Subject: [Fedora-packaging] Re: PLEASE HELP - We need a policy for preventing man page name conflicts In-Reply-To: <43F9CF85.4010502@cornell.edu> References: <43F6B501.1040105@cora.nwra.com> <1140442719.21764.570.camel@mccallum.corsepiu.local> <43F9CF85.4010502@cornell.edu> Message-ID: <43FA0E60.40002@cora.nwra.com> Ivan Gyurdiev wrote: > > I suggest efforts would be better directed at fixing the real problem - > i.e. the library namespace. > > Having an API that calls functions line() and such means it's just a > question of time before you run into header conflicts where a program > attempts to include two headers with the same function name (or > statically link against two libraries with the same symbol, whether the > function is used or not)... or link against the library and have a local > function called line() defined. > > I suppose programming language makes a difference here, but at least > this should apply to C code. > Yes, things should get fixed upstream. But in the meantime, we're packaging this stuff and need a policy for a workaround. I'm inclined to rename all man3 functions to ncarg_ to fix my particular issue. I'll file a note upstream as well. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From bugzilla at redhat.com Mon Feb 20 18:44:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 13:44:01 -0500 Subject: [Bug 182077] Review Request: cfv - utility to test and create checksums In-Reply-To: Message-ID: <200602201844.k1KIi1UR021505@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cfv - utility to test and create checksums https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182077 ------- Additional Comments From bdpepple at ameritech.net 2006-02-20 13:43 EST ------- Might want to review the wiki steps: http://fedoraproject.org/wiki/Extras/Contributors -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From orion at cora.nwra.com Mon Feb 20 18:53:05 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 20 Feb 2006 11:53:05 -0700 Subject: static libs ... again In-Reply-To: <1140441846.21764.558.camel@mccallum.corsepiu.local> References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> <1140243907.21764.402.camel@mccallum.corsepiu.local> <43F9BE60.1090705@hhs.nl> <1140441846.21764.558.camel@mccallum.corsepiu.local> Message-ID: <43FA1011.9000608@cora.nwra.com> Ralf Corsepius wrote: > On Mon, 2006-02-20 at 07:10 -0600, Rex Dieter wrote: >> Hans de Goede wrote: >>> Rex Dieter wrote: >>>> One question to beg here... I maintain several libraries that come >>>> *only* as static libs(*). At the moment, these pkgs provide *only* a >>>> -devel pkg (pending upstream fix(es) to allow for shared/dynamic >>>> libs). Is that acceptable or should these get split too? >>> Not split, but renamed would be a good so replace -devel with -static. > ACK, plus letting -static provide -devel. > > For packages having both static and shared libraries I'd, put > everything but the static libs into *-devel and let *-static "Requires: > *-devel". > > [BTW: we had discussed this in great dep several months ago on one of > this too many fedora lists.] > >> Eek. I still think headers and api docs and such still should be in >> -devel (especially if there's any likelyhood of a real shared lib >> existing some day), and that -static should Requires: %{name}-devel > Hmm, headers without libs in most cases are useless, but shipping docs > in *-devel, even for -static only packages is worth a thought. I am not > sure. > Not sure who I'm agreeing with here :-), but: - Put static libs in -static (so they don't get used accidentally) - Keep -devel for headers and shared libs (if existing) - -devel requires -static if no shared libs so that dependent packages only use BR: -devel. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From rdieter at math.unl.edu Mon Feb 20 19:01:13 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 20 Feb 2006 13:01:13 -0600 Subject: static libs ... again In-Reply-To: <43FA1011.9000608@cora.nwra.com> References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> <1140243907.21764.402.camel@mccallum.corsepiu.local> <43F9BE60.1090705@hhs.nl> <1140441846.21764.558.camel@mccallum.corsepiu.local> <43FA1011.9000608@cora.nwra.com> Message-ID: Orion Poplawski wrote: > Not sure who I'm agreeing with here :-), but: > > - Put static libs in -static (so they don't get used accidentally) > - Keep -devel for headers and shared libs (if existing) > - -devel requires -static if no shared libs so that dependent packages > only use BR: -devel. dunno about you, but I agree with you. -- Rex From tibbs at math.uh.edu Mon Feb 20 19:04:21 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 20 Feb 2006 13:04:21 -0600 Subject: Crontab and init scripts In-Reply-To: <20060220164554.GB17008@devserv.devel.redhat.com> (Bill Nottingham's message of "Mon, 20 Feb 2006 11:45:54 -0500") References: <3237e4410602200046r3d9f871h2d4ba57c4556a80e@mail.gmail.com> <20060220164554.GB17008@devserv.devel.redhat.com> Message-ID: >>>>> "BN" == Bill Nottingham writes: BN> While I'm not *that* fond of the yum approach (it's sort of a BN> hack), it's a better solution than running cron scripts for BN> uninstalled things. The only thing I see as being hackish is that the cron job always runs, but it just doesn't do anything if the service is turned off. With cacti, that means that every five minutes you're writing to cron.log and spawning a shell which will check one file and exit. What are the alternatives, assuming you don't want to modify cron? * You could have the init.d script create and delete the crontab entry. Certainly not much more palatable. * Accept the status quo, where package installation is equated with "I want to run the service". * Don't involve cron at all: start a shell script in the background, which fires off the real job once every five minutes. * Make the admin put the crontab in place and ignore the standard method of specifying what services should run altogether. I prefer the Yum method, myself. - J< From bugzilla at redhat.com Mon Feb 20 19:50:26 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 14:50:26 -0500 Subject: [Bug 181753] Review Request: mm - Shared memory allocation library In-Reply-To: Message-ID: <200602201950.k1KJoQop002833@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mm - Shared memory allocation library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181753 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-20 14:50 EST ------- Of course. the debuginfo package contains the debugging information. This will be created, when you compiled a program with the -g compiler switch. Before the RPM will be created the binaries will be stripped and the debug informations will be stored in seperates files which going to the debuginfo package. When you install a debuginfo package, the content of the package will be installed on /usr/src7debug. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 19:51:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 14:51:34 -0500 Subject: [Bug 181997] Review Request: gpc - The GNU Pascal compiler In-Reply-To: Message-ID: <200602201951.k1KJpYuu003094@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gpc - The GNU Pascal compiler https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181997 ------- Additional Comments From tibbs at math.uh.edu 2006-02-20 14:51 EST ------- OK, something has broken; I thought it had built x86_64 but it didn't. The build fails here: /builddir/build/BUILD/gpc-3.4.5_20060215/gcc-3.4.5/gcc/xgcc -B/builddir/build/BUILD/gpc-3.4.5_20060215/gcc-3.4.5/ gcc/ -B/usr/x86_64-redhat-linux/bin/ -B/usr/x86_64-redhat-linux/lib/ -isystem /usr/x86_64-redhat-linux/include -i system /usr/x86_64-redhat-linux/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissi ng-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT _NOT_NEEDED -I. -I. -I. -I./. -I./../include -m32 -DL_muldi3 -c ./libgcc2.c -o libgcc/32/_muldi3.o In file included from /usr/include/features.h:352, from /usr/include/stdio.h:28, from ./tsystem.h:79, from ./libgcc2.c:41: /usr/include/gnu/stubs.h:7:27: gnu/stubs-32.h: No such file or directory Now, /usr/include/gnu/stubs-32.h is part of glibc-devel.i386. I have glibc-devel as a buildreq and I swear that at one point the x86_64 mock was pulling in both arches but how it doesn't seem to be. So: this package requires glibc-devel.i386 to be installed in order to build on x86_64. How do I indicate that in the spec? I suppose I could require /usr/include/gnu/stubs-32.h, but that turns my stomach somewhat. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From pertusus at free.fr Mon Feb 20 20:04:41 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 20 Feb 2006 21:04:41 +0100 Subject: static libs ... again In-Reply-To: <43FA1011.9000608@cora.nwra.com> References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> <1140243907.21764.402.camel@mccallum.corsepiu.local> <43F9BE60.1090705@hhs.nl> <1140441846.21764.558.camel@mccallum.corsepiu.local> <43FA1011.9000608@cora.nwra.com> Message-ID: <20060220200441.GH2861@free.fr> > Not sure who I'm agreeing with here :-), but: > > - Put static libs in -static (so they don't get used accidentally) static libs are never used when there are static and dynamic libs available (and linking with -l). If they are used accidentally it is a bug. I have never seen this happen. > - Keep -devel for headers and shared libs (if existing) > - -devel requires -static if no shared libs so that dependent packages > only use BR: -devel. I agree that it is usefull but not for the reason mentionned above, as shared libs are used, but because it reduces the size of the devel packages and it seems to me that it is the most important interest of excluding static library. -- Pat From bugzilla at redhat.com Mon Feb 20 20:07:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 15:07:33 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602202007.k1KK7XBO006737@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From jvdias at redhat.com 2006-02-20 15:07 EST ------- The FC4 build and mpif90 issues are now fixed with the openmpi-1.0.1-1 RPMs at: http://people.redhat.com/~jvdias/openmpi these are now submitted to Fedora rawhide CVS. I've had a response from the Fedora "powers-that-be" : openmpi CANNOT go into FC-5, but will be going into FC Rawhide after the release of FC-5 GOLD . So we'll need to put openmpi into Extras for FC-5, and it will be available from the Rawhide/development repos and will be in the FC-6 release (only 6 months away). I'm happy to submit openmpi into FC-5/Extras, unless one of you wants to be the openmpi Extras package owner ... let me know. I don't think we should submit openmpi to FC-4 Extras, which would require respinning the FC-4 LAM, and a rebuild of all LAM using FC-4 RPMs , which is too much churn for a stable FC release. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 20 20:17:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 15:17:56 -0500 Subject: [Bug 180164] Review Request: muine In-Reply-To: Message-ID: <200602202017.k1KKHuhd008846@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: muine https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180164 katzj at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |181824 ------- Additional Comments From katzj at redhat.com 2006-02-20 15:17 EST ------- Even if upstream packages them separately, I think we're far better off packaging them together. From a user experience perspective, it's going to be far better. I'll try to do the more full review checklist later today. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 20:19:26 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 15:19:26 -0500 Subject: [Bug 174952] Review Request: lightning - GNU Lightning In-Reply-To: Message-ID: <200602202019.k1KKJQhi009242@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: lightning - GNU Lightning https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174952 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-20 15:19 EST ------- Event I could not reproduced your issue, I have added your suggestion. the current version could you download from: Spec Name or Url: http://www.herr-schmitt.de/pub/lightning/lightning.spec SRPM Name or Url: http://www.herr-schmitt.de/pub/lightning/lightning-1.2-3.spec -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From paul at cypherpunks.ca Mon Feb 20 20:41:25 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Mon, 20 Feb 2006 21:41:25 +0100 (CET) Subject: source file "already there" but "not found" ? Was: Prep Error (Job 3879)fetchlog-1_0-4_fc5 on fedora-development-extras In-Reply-To: <20060214125005.23461785.bugs.michael@gmx.net> References: <20060214125005.23461785.bugs.michael@gmx.net> Message-ID: On Tue, 14 Feb 2006, Michael Schwendt wrote: > > -rw-rw-rw- 1 root root 339 Feb 6 14:59 fetchlog-build.patch > > rpmbuild --define "_sourcedir /tmp/3879-fetchlog-1_0-4_fc5-1139445759/fetchlog/devel" --define "_builddir /tmp/3879-fetchlog-1_0-4_fc5-1139445759/fetchlog/devel" --define "_srcrpmdir /tmp/3879-fetchlog-1_0-4_fc5-1139445759/fetchlog/devel" --define "_rpmdir /tmp/3879-fetchlog-1_0-4_fc5-1139445759/fetchlog/devel" --define "dist .fc5" --define "fedora 5" --nodeps -bs fetchlog.spec > > error: File /tmp/3879-fetchlog-1_0-4_fc5-1139445759/fetchlog/devel/fetchlog-1.0.tar.gz: No such file or directory > > make: *** [srpm] Error 1 > > > > I am not sure why fetchlog-1.0.tar.gz vanished, since it did not change between releases. And > > the system things it is still there: > > > > [paul at bofh devel]$ make new-sources "FILES=/usr/src/redhat/SOURCES/fetchlog-1.0.tar.gz " > > > > Checking : fetchlog-1.0.tar.gz on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... > > This file (e2ef0a076d1901c489c953fe48e1b2a9 fetchlog-1.0.tar.gz) is already uploaded > > > > Source upload succeeded. Don't forget to commit the new ./sources file > > For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs > > M sources > > M .cvsignore > > The lookaside cache mechanism also takes into account the file's MD5 > checksum when retrieving a file. So make sure your local "sources" > file is up-to-date and correct. Currently it is marked as 'M' > (modified), so possibly contains a wrong checksum. Check out a > fresh copy, try again. "make srpm" for fetchlog-1.0-4.fc5 works here. I commited the sources file and re-issued the build, but that did not seem to be the real issue. Also, the sourcefile contents did not change between builds, so I'm not sure how the previous built would have worked if the checksum was wrong. "make srpm" works fine. But "make plague" still fails with the above error. Paul -- "Happiness is never grand" --- Mustapha Mond, World Controller (Brave New World) From bugzilla at redhat.com Mon Feb 20 20:34:29 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 15:34:29 -0500 Subject: [Bug 181777] Review Request: CCfits A C++ interface for cfitsio (FITS File Subroutine Library) In-Reply-To: Message-ID: <200602202034.k1KKYTOm013088@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: CCfits A C++ interface for cfitsio (FITS File Subroutine Library) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181777 ------- Additional Comments From spr at astrax.fis.ucm.es 2006-02-20 15:34 EST ------- Hi Ed, I have fixed the points you mentioned: * Changed license type to BSD. The license for CCfits is exactly the same as the license of cfitsio, but in that package the license field of the rpm is GPL! * Removed some perl files in the html directory * Removed the trailing dots in Summary and * Removed rpath in the shared library compile instruction. The new spec and srpm are here: http://t-rex.fis.ucm.es/~spr/CCfits.spec http://t-rex.fis.ucm.es/~spr/CCfits-1.4-1.fc4.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 20:46:37 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 15:46:37 -0500 Subject: [Bug 174377] Review Request:gnu-smalltalk - GNU Smalltalk In-Reply-To: Message-ID: <200602202046.k1KKkbm9016174@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request:gnu-smalltalk - GNU Smalltalk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174377 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-20 15:46 EST ------- Thank you for your comment. But unfortunately now I will got the following error message: SMALLTALK_KERNEL="`cd ./kernel; pwd`" \ SMALLTALK_IMAGE="`pwd`" \ ./gst -iQ /dev/null a Smalltalk string:1: Aborted (ip 0)UndefinedObject>>#executeStatements (ip 0) make[2]: *** [gst.im] Aborted but when I remove the LIBTOOL=/usr/bin/libtool from the make step then it's works. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 20 21:19:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 16:19:44 -0500 Subject: [Bug 182173] New: Review Request: eterm - a color vt102 terminal emulator Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182173 Summary: Review Request: eterm - a color vt102 terminal emulator Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: terjeros at phys.ntnu.no QAContact: fedora-extras-list at redhat.com Spec file: http://web.phys.ntnu.no/~terjeros/eterm/eterm.spec SRPM : http://web.phys.ntnu.no/~terjeros/eterm/eterm-0.9.3-1.src.rpm Description: Eterm is a color vt102 terminal emulator intended as a replacement for xterm. Depends on libast which is also submitted. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 20 21:25:04 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 16:25:04 -0500 Subject: [Bug 182175] New: Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182175 Summary: Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: terjeros at phys.ntnu.no QAContact: fedora-extras-list at redhat.com Spec file: http://web.phys.ntnu.no/~terjeros/eterm/libast.spec SRPM: http://web.phys.ntnu.no/~terjeros/eterm/libast-0.7-1.src.rpm Description: LibAST is the Library of Assorted Spiffy Things. It contains various handy routines and drop-in substitutes for some good-but-non-portable functions. It currently has a built-in memory tracking subsystem as well as some debugging aids and other similar tools. The reason to include this package is as needed lib. by eterm, see another Package Review Request. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From s.mako at gmx.net Mon Feb 20 22:07:13 2006 From: s.mako at gmx.net (Zoltan Kota) Date: Mon, 20 Feb 2006 23:07:13 +0100 (CET) Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1140303160.17151.98.camel@bree.local.net> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <43F632B9.40904@hhs.nl> <1140251657.2904.24.camel@localhost.localdomain> <43F71677.2080506@hhs.nl> <1140266775.2904.149.camel@localhost.localdomain> <43F7207D.3080605@hhs.nl> <1140271503.2904.173.camel@localhost.localdomain> <43F73B0D.4000608@hhs.nl> <1140303160.17151.98.camel@bree.local.net> Message-ID: On Sat, 18 Feb 2006, Jeremy Katz wrote: > > Thats the problem, I don't know how long it takes for the buildsys to > > pick up rawhide changes, so I'm suggesting to use the time of the > > rawhide changelog mail + some extra time , hoping that someone who knows > > the buildsys can tell us what amount of extra time is needed after the > > rawhide changelog mail. > > The changelog mail should be sent at pretty much the same time as the > packages are available for the build system. Thorsten, could you please generate a new list of packages to see how things change? Zoltan From bugzilla at redhat.com Mon Feb 20 22:40:05 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 17:40:05 -0500 Subject: [Bug 181974] Review Request: mod_geoip - Apache module for GeoIP lookups In-Reply-To: Message-ID: <200602202240.k1KMe5tY013399@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mod_geoip - Apache module for GeoIP lookups https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181974 mfleming+rpm at enlartenment.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From mfleming+rpm at enlartenment.com 2006-02-20 17:39 EST ------- Imported source RPM into CVS, will request a build when I get home from work. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From orion at cora.nwra.com Mon Feb 20 22:52:03 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 20 Feb 2006 15:52:03 -0700 Subject: deciphering a build failure In-Reply-To: <1140449329.3729.12.camel@tameshk.farsiweb.info> References: <1140449329.3729.12.camel@tameshk.farsiweb.info> Message-ID: <43FA4813.1040205@cora.nwra.com> Roozbeh Pournader wrote: > I'm having a build failure that I can't decode, and I guess there may be > something wrong with either mock or the ppc1 setup (that builds the > noarch packages). > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=4947 > > Could someone take a look? My best guess is bad FC-4 packages. > > roozbeh > > This is weird. There is no indication that yum exited with any errors, yet the build stops. At first I thought the following: ls: readlink:: No such file or directory ls: file: No such file or directory ls: expected: No such file or directory cp: cannot stat `/dev/md1': No such file or directory were relevant, but you find them in logs of successful builds. The problem seems to have occurred between Mon Feb 20 05:06:54 2006 (when the last FC4 job succeeded (4939: dap-server-3.5.3-1.fc4) Mon Feb 20 08:29:27 2006 (when this job failed) At this point I think it points to the build systems. I can't reproduce in mock locally. It might be boa though: warning: user apache does not exist - using root warning: group apache does not exist - using root is new. boa is not installed when I run mock locally. why? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From paul at all-the-johnsons.co.uk Mon Feb 20 22:59:15 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 20 Feb 2006 22:59:15 +0000 Subject: Anjuta - change of maintainer Message-ID: <1140476355.2971.1.camel@T7.Linux> Hi, I am willing to take over the packaging of Anjuta for FE. I've bumped it to version 1.2.4 and applied a fix which should make it work happily under rawhide machines. Once I've tested the rpm, I will do the commit. As this is no longer 1.2.3, do I need to do anything special to have 1.2.3 removed so that only 1.2.4 is on the build sys? TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From chitlesh at fedoraproject.org Mon Feb 20 23:00:28 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 21 Feb 2006 00:00:28 +0100 Subject: Anjuta - change of maintainer In-Reply-To: <1140476355.2971.1.camel@T7.Linux> References: <1140476355.2971.1.camel@T7.Linux> Message-ID: <13dbfe4f0602201500w25dcc9dcp3ba8f1db893e7f7a@mail.gmail.com> go for it :) you can give atry to the 2.0 too Fedora = innovative :) On 2/20/06, Paul wrote: > Hi, > > I am willing to take over the packaging of Anjuta for FE. I've bumped it > to version 1.2.4 and applied a fix which should make it work happily > under rawhide machines. > > Once I've tested the rpm, I will do the commit. As this is no longer > 1.2.3, do I need to do anything special to have 1.2.3 removed so that > only 1.2.4 is on the build sys? > > TTFN > > Paul > -- > "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.1 (GNU/Linux) > > iD8DBQBD+knDusSVe5EZv3wRAqTXAJ9l4N+WviV0+F9n3RQ8au0JUr8eUQCeL9B+ > FZyynaKygM/g1uPp8nbWH6M= > =6wCe > -----END PGP SIGNATURE----- > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > > > -- http://clunixchit.blogspot.com From paul at all-the-johnsons.co.uk Mon Feb 20 23:05:00 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Mon, 20 Feb 2006 23:05:00 +0000 Subject: Anjuta - change of maintainer In-Reply-To: <13dbfe4f0602201500w25dcc9dcp3ba8f1db893e7f7a@mail.gmail.com> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602201500w25dcc9dcp3ba8f1db893e7f7a@mail.gmail.com> Message-ID: <1140476701.2971.3.camel@T7.Linux> Hi, > go for it :) > you can give atry to the 2.0 too > Fedora = innovative :) Yeah, I've already got 2.01 pencilled in, but need to fix a few bits first with my buildsys. TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show From chitlesh at fedoraproject.org Mon Feb 20 23:20:37 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 21 Feb 2006 00:20:37 +0100 Subject: Anjuta - change of maintainer In-Reply-To: <1140476701.2971.3.camel@T7.Linux> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602201500w25dcc9dcp3ba8f1db893e7f7a@mail.gmail.com> <1140476701.2971.3.camel@T7.Linux> Message-ID: <13dbfe4f0602201520v21ee0d3br46b04df50eea092b@mail.gmail.com> I was able to install 1.4 but it crashed On 2/21/06, Paul F. Johnson wrote: > Hi, > > > go for it :) > > you can give atry to the 2.0 too > > Fedora = innovative :) > > Yeah, I've already got 2.01 pencilled in, but need to fix a few bits > first with my buildsys. > > TTFN > > Paul > -- > "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- http://clunixchit.blogspot.com From paul at all-the-johnsons.co.uk Mon Feb 20 23:23:55 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Mon, 20 Feb 2006 23:23:55 +0000 Subject: Anjuta - change of maintainer In-Reply-To: <13dbfe4f0602201520v21ee0d3br46b04df50eea092b@mail.gmail.com> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602201500w25dcc9dcp3ba8f1db893e7f7a@mail.gmail.com> <1140476701.2971.3.camel@T7.Linux> <13dbfe4f0602201520v21ee0d3br46b04df50eea092b@mail.gmail.com> Message-ID: <1140477835.2971.5.camel@T7.Linux> Hi, > I was able to install 1.4 but it crashed Do you mean 1.2.4 or the vsn 2.0x branch? There is a patch available for 1.2.4 which I've applied and is currently being committed to extras. TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show From paul at all-the-johnsons.co.uk Mon Feb 20 23:56:37 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Mon, 20 Feb 2006 23:56:37 +0000 Subject: Anjuta - change of maintainer In-Reply-To: <1140477835.2971.5.camel@T7.Linux> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602201500w25dcc9dcp3ba8f1db893e7f7a@mail.gmail.com> <1140476701.2971.3.camel@T7.Linux> <13dbfe4f0602201520v21ee0d3br46b04df50eea092b@mail.gmail.com> <1140477835.2971.5.camel@T7.Linux> Message-ID: <1140479798.2971.7.camel@T7.Linux> On Mon, 2006-02-20 at 23:23 +0000, Paul F. Johnson wrote: > Hi, > > > I was able to install 1.4 but it crashed > > Do you mean 1.2.4 or the vsn 2.0x branch? There is a patch available for > 1.2.4 which I've applied and is currently being committed to extras. 1.2.4-2 should be in tomorrow FE rawhide update. TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show From michael at knox.net.nz Tue Feb 21 00:04:39 2006 From: michael at knox.net.nz (Michael J Knox) Date: Tue, 21 Feb 2006 13:04:39 +1300 Subject: Changing maintainer in general (WAS Re: Anjuta - change of maintainer) In-Reply-To: <1140476355.2971.1.camel@T7.Linux> References: <1140476355.2971.1.camel@T7.Linux> Message-ID: <1140480279.10765.26.camel@cosima.et.endace.com> On Mon, 2006-02-20 at 22:59 +0000, Paul wrote: > Hi, > > I am willing to take over the packaging of Anjuta for FE. I've bumped it > to version 1.2.4 and applied a fix which should make it work happily > under rawhide machines. > > Once I've tested the rpm, I will do the commit. As this is no longer > 1.2.3, do I need to do anything special to have 1.2.3 removed so that > only 1.2.4 is on the build sys? > > TTFN > > Paul This is great. I am a little disheartened over the whole orphaned taking ownership process. I asked sometime ago about this: https://www.redhat.com/archives/fedora-extras-list/2006-January/msg01457.html And got no response. What is the process of a new comer to take ownership of a package? I have a Fedora account, what else is needed? Michael From paul at all-the-johnsons.co.uk Tue Feb 21 00:09:44 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Tue, 21 Feb 2006 00:09:44 +0000 Subject: Changing maintainer in general (WAS Re: Anjuta - change of maintainer) In-Reply-To: <1140480279.10765.26.camel@cosima.et.endace.com> References: <1140476355.2971.1.camel@T7.Linux> <1140480279.10765.26.camel@cosima.et.endace.com> Message-ID: <1140480584.2971.11.camel@T7.Linux> Hi, > This is great. I am a little disheartened over the whole orphaned taking > ownership process. > > I asked sometime ago about this: > > https://www.redhat.com/archives/fedora-extras-list/2006-January/msg01457.html > > And got no response. Odd - you should have. That said, enquiries about orphaned packages are quite frequent and most of the time, you get pointed to the list below. > What is the process of a new comer to take ownership of a package? http://fedoraproject.org/wiki/Extras/OrphanedPackages Contains all ye shall need > I have a Fedora account, what else is needed? As long as you have the upload certs, you should be good to go (for orphaned packages - these will have already have gone through the review process. New packages need to go through the usual bugzilla system) TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show From chitlesh at fedoraproject.org Tue Feb 21 00:07:06 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 21 Feb 2006 01:07:06 +0100 Subject: Anjuta - change of maintainer In-Reply-To: <1140479798.2971.7.camel@T7.Linux> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602201500w25dcc9dcp3ba8f1db893e7f7a@mail.gmail.com> <1140476701.2971.3.camel@T7.Linux> <13dbfe4f0602201520v21ee0d3br46b04df50eea092b@mail.gmail.com> <1140477835.2971.5.camel@T7.Linux> <1140479798.2971.7.camel@T7.Linux> Message-ID: <13dbfe4f0602201607o1f4a40cg1ecbaad1c5880155@mail.gmail.com> great. do inform me :) if not buildsys will :) On 2/21/06, Paul F. Johnson wrote: > On Mon, 2006-02-20 at 23:23 +0000, Paul F. Johnson wrote: > > Hi, > > > > > I was able to install 1.4 but it crashed > > > > Do you mean 1.2.4 or the vsn 2.0x branch? There is a patch available for > > 1.2.4 which I've applied and is currently being committed to extras. > > 1.2.4-2 should be in tomorrow FE rawhide update. > > TTFN > > Paul > -- > "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- http://clunixchit.blogspot.com From bugzilla at redhat.com Tue Feb 21 00:08:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 19:08:15 -0500 Subject: [Bug 166960] Review Request: Fuse-emulator In-Reply-To: Message-ID: <200602210008.k1L08FC4029290@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Fuse-emulator https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166960 ------- Additional Comments From paul at all-the-johnsons.co.uk 2006-02-20 19:08 EST ------- Earth to spot, come in spot... Earth to spot, come in spot... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From paul at all-the-johnsons.co.uk Tue Feb 21 00:14:51 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Tue, 21 Feb 2006 00:14:51 +0000 Subject: Anjuta - change of maintainer In-Reply-To: <13dbfe4f0602201607o1f4a40cg1ecbaad1c5880155@mail.gmail.com> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602201500w25dcc9dcp3ba8f1db893e7f7a@mail.gmail.com> <1140476701.2971.3.camel@T7.Linux> <13dbfe4f0602201520v21ee0d3br46b04df50eea092b@mail.gmail.com> <1140477835.2971.5.camel@T7.Linux> <1140479798.2971.7.camel@T7.Linux> <13dbfe4f0602201607o1f4a40cg1ecbaad1c5880155@mail.gmail.com> Message-ID: <1140480891.2971.13.camel@T7.Linux> Hi, > great. do inform me :) if not buildsys will :) Buildsys was happy and did make ppc, x86 and x86_64 versions (apparently). Share and enjoy! TTFN Paul (in need of pain killers) -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show From bdpepple at ameritech.net Tue Feb 21 00:22:22 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Mon, 20 Feb 2006 19:22:22 -0500 Subject: Changing maintainer in general (WAS Re: Anjuta - change of maintainer) In-Reply-To: <1140480279.10765.26.camel@cosima.et.endace.com> References: <1140476355.2971.1.camel@T7.Linux> <1140480279.10765.26.camel@cosima.et.endace.com> Message-ID: <1140481342.20465.3.camel@shuttle.273piedmont.org> On Tue, 2006-02-21 at 13:04 +1300, Michael J Knox wrote: > This is great. I am a little disheartened over the whole orphaned taking > ownership process. > > I asked sometime ago about this: > > https://www.redhat.com/archives/fedora-extras-list/2006-January/msg01457.html > > And got no response. > > What is the process of a new comer to take ownership of a package? > > I have a Fedora account, what else is needed? > It is discussed on the wiki, and reads fairly straight-forward to me. http://fedoraproject.org/wiki/Extras/OrphanedPackages#head-34d77024ae3649647741971669f05f188017a686 /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: 191 bytes Desc: This is a digitally signed message part URL: From bugzilla at redhat.com Tue Feb 21 00:28:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 19:28:33 -0500 Subject: [Bug 181753] Review Request: mm - Shared memory allocation library In-Reply-To: Message-ID: <200602210028.k1L0SXgL031945@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mm - Shared memory allocation library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181753 ------- Additional Comments From andreas at bawue.net 2006-02-20 19:28 EST ------- Yeah. But what to do in case the debuginfo package contains no debug information? I surely didn't remove them from the package, so I can't put them back in. ;-D -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From jwboyer at jdub.homelinux.org Mon Feb 20 23:35:30 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 20 Feb 2006 18:35:30 -0500 Subject: ctrlproxy - change of maintainer Message-ID: <1140478530.19186.1.camel@yoda.jdub.homelinux.org> FYI. I spoke with David Woodhouse yesterday, and he agreed to let me maintain ctrlproxy in Extras. This isn't an orphaned package, but I though I would let folks know. josh -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From michael at knox.net.nz Tue Feb 21 00:36:43 2006 From: michael at knox.net.nz (Michael J Knox) Date: Tue, 21 Feb 2006 13:36:43 +1300 Subject: Changing maintainer in general (WAS Re: Anjuta - change of maintainer) In-Reply-To: <1140481342.20465.3.camel@shuttle.273piedmont.org> References: <1140476355.2971.1.camel@T7.Linux> <1140480279.10765.26.camel@cosima.et.endace.com> <1140481342.20465.3.camel@shuttle.273piedmont.org> Message-ID: <1140482203.10765.29.camel@cosima.et.endace.com> On Mon, 2006-02-20 at 19:22 -0500, Brian Pepple wrote: > On Tue, 2006-02-21 at 13:04 +1300, Michael J Knox wrote: > > This is great. I am a little disheartened over the whole orphaned taking > > ownership process. > > > > I asked sometime ago about this: > > > > https://www.redhat.com/archives/fedora-extras-list/2006-January/msg01457.html > > > > And got no response. > > > > What is the process of a new comer to take ownership of a package? > > > > I have a Fedora account, what else is needed? > > > > It is discussed on the wiki, and reads fairly straight-forward to me. > > http://fedoraproject.org/wiki/Extras/OrphanedPackages#head-34d77024ae3649647741971669f05f188017a686 > > /B Right, I had read that. So if no one complains I can assume maintainer's role (read: no feed back at all from the list)? Michael From bugzilla at redhat.com Tue Feb 21 01:09:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 20:09:33 -0500 Subject: [Bug 181444] Review Request: lcov -- process gcov output into nice html pages In-Reply-To: Message-ID: <200602210109.k1L19XIw005266@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: lcov -- process gcov output into nice html pages https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181444 ------- Additional Comments From roland at redhat.com 2006-02-20 20:09 EST ------- I've put a new version in http://people.redhat.com/roland/tmp/ that addresses the reviewers' comments and fixes another bug. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From tibbs at math.uh.edu Tue Feb 21 01:17:47 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 20 Feb 2006 19:17:47 -0600 Subject: Specifying arch in BuildRequires: Message-ID: I'm trying to package GNU Pascal and I'm running into a problem on x86_64. Since x86_64 is a multilib platform, the build process will try to build both 64 and 32 bit libraries. Therefore it needs glibc-devel for both x86_64 and i386 to be installed during the build. (Otherwise the build fails for lack of /usr/include/gnu/stubs-32.h.) So, any ideas on how I can convince mock to install glibc-devel on both architectures? Alternately, is there a GCC build expert in the house? - J< From bugzilla at redhat.com Tue Feb 21 01:21:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 20:21:11 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602210121.k1L1LBVY006907@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From ed at eh3.com 2006-02-20 20:21 EST ------- Hi Jason, not having OpenMPI in either FC5 or FE4 seems very reasonable. And it'll be nice to have it in FE5 along with your lam cleanups. Thank you! If it helps I'll withdraw my openmpi submission and act as a reviewer (and probably Orion will want to help out with reviews and/or patches). So I built (in mock) the newer openmpi version from comment #31 above (it would be less confusing if the release number were bumped with each change but its not a big deal): e78dee1eae42c099c958a8a335ef758a openmpi-1.0.1-1.src.rpm and the soft-links are now fixed--good. Unfortunately, it seems to have problems running the daemon and locating some run-time help files: $ /usr/share/openmpi/bin/mpicc -o om_hi ./mpi_hi.c $ /usr/share/openmpi/bin/orted $ /usr/share/openmpi/bin/mpirun -np 1 om_hi -------------------------------------------------------------------------- Sorry! You were supposed to get help about: orterun:proc-aborted from the file: help-orterun.txt But I couldn't find any file matching that name. Sorry! -------------------------------------------------------------------------- [ernie:05944] ERROR: A daemon on node localhost failed to start as expected. [ernie:05944] ERROR: There may be more information available from [ernie:05944] ERROR: the remote shell (see above). [ernie:05944] The daemon received a signal 11. but its possible that I've botched something. I've got to get some other work done so I'll look into it later this week. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 21 01:41:51 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 20:41:51 -0500 Subject: [Bug 181777] Review Request: CCfits A C++ interface for cfitsio (FITS File Subroutine Library) In-Reply-To: Message-ID: <200602210141.k1L1fpFV010054@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: CCfits A C++ interface for cfitsio (FITS File Subroutine Library) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181777 ------- Additional Comments From ed at eh3.com 2006-02-20 20:41 EST ------- Hi Sergio, please take a look at bug # 172042 where Matt points out that BSD code linked against GPL code becomes GPL-ed. I think thats correct but IANAL. And I'll try to finish the review later this week or the coming weekend. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 21 03:01:25 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 22:01:25 -0500 Subject: [Bug 181979] Review Request: python-geoip - Python bindings for the GeoIP geographical lookup libraries In-Reply-To: Message-ID: <200602210301.k1L31Pmm021496@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: python-geoip - Python bindings for the GeoIP geographical lookup libraries https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181979 ------- Additional Comments From tibbs at math.uh.edu 2006-02-20 22:01 EST ------- Cool. rpmlint is now silent and the name neets the guidelines. The specfile is taken from the Python template and is clean. There are no installed (non-doc) .py or .pyc files, so no .pyo files to ghost. The source file matches upstream. The license is appropriate, matches the spec and is included as %doc. Absolutely minor nitpick: your Description: needs a period. Somewhat less minor nitpick: Requires: GeoIP is redundant. RPM picks up the libGeoIP.so.1 requirement automatically. Sorry I didn't catch those at first glance. Fix them up and it's good to go. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 21 04:02:12 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 23:02:12 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602210402.k1L42CEB001399@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tibbs at math.uh.edu ------- Additional Comments From tibbs at math.uh.edu 2006-02-20 23:02 EST ------- I wanted to provide a full review for this, but the links to the spec and srpm are invalid (no permissions). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From wtogami at redhat.com Tue Feb 21 04:47:48 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 20 Feb 2006 23:47:48 -0500 Subject: Specifying arch in BuildRequires: In-Reply-To: References: Message-ID: <43FA9B74.30606@redhat.com> Jason L Tibbitts III wrote: > I'm trying to package GNU Pascal and I'm running into a problem on > x86_64. Since x86_64 is a multilib platform, the build process will > try to build both 64 and 32 bit libraries. Therefore it needs > glibc-devel for both x86_64 and i386 to be installed during the > build. (Otherwise the build fails for lack of > /usr/include/gnu/stubs-32.h.) > > So, any ideas on how I can convince mock to install glibc-devel on > both architectures? Alternately, is there a GCC build expert in the > house? > It is not possible to do with current RPM. GNU Pascal is just plain wrong in what it is trying to do. You need to patch it so it ignores the other arch and doesn't attempt to build it. Warren Togami wtogami at redhat.com From bugzilla at redhat.com Tue Feb 21 04:50:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2006 23:50:33 -0500 Subject: [Bug 177277] Review Request: perl-SQL-Abstract-Limit : Portable LIMIT Emulation In-Reply-To: Message-ID: <200602210450.k1L4oXOI012040@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-SQL-Abstract-Limit : Portable LIMIT Emulation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177277 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |tibbs at math.uh.edu OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From tibbs at math.uh.edu 2006-02-20 23:50 EST ------- A couple of issues: The %description is, well, not there. I know the upstream package doesn't supply any more detail than that, but perhaps you could write just a couple of descriptive sentences. BuildRequires: perl >= 1:5.6.1 is a bit pointless; Extras only supports back to FC3 which has perl 5.8.5; I think you have to go back to Red Hat 7.2 to find a version that wouldn't satisfy that requirement. Doesn't build in mock (i386, development) due to the inability to resolve a dependency on perl(DBD::AnyData). Perhaps this should depend on bug 177276? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 21 05:04:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 00:04:50 -0500 Subject: [Bug 177277] Review Request: perl-SQL-Abstract-Limit : Portable LIMIT Emulation In-Reply-To: Message-ID: <200602210504.k1L54ooN015386@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-SQL-Abstract-Limit : Portable LIMIT Emulation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177277 ------- Additional Comments From tibbs at math.uh.edu 2006-02-21 00:04 EST ------- Also, can you change %build to: %{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS" make %{?_smp_mflags} I know that technically for a pure Perl module with just one file there's not much point, but sticklers will want the template followed unless something actually breaks when you try. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 21 05:06:06 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 00:06:06 -0500 Subject: [Bug 177276] Review Request: perl-DBD-AnyData : DBI access to XML, CSV and other formats In-Reply-To: Message-ID: <200602210506.k1L566Vo015761@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-DBD-AnyData : DBI access to XML, CSV and other formats https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177276 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |tibbs at math.uh.edu OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From tibbs at math.uh.edu 2006-02-21 00:05 EST ------- Since this seems to be a requirement for bug 177277, I'll review this as well. First off, I agree with Orion. Mostly. It's not really necessary to write a book, but %description %{summary}. doesn't really work. Please at least give a couple of sentences of description. Also, as in 177277, the BuildRequires: perl >= 1:5.6.1 is pointless and needs to go and %build should be: %{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS" make %{?_smp_mflags} unless the package breaks. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From ville.skytta at iki.fi Tue Feb 21 05:20:52 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 21 Feb 2006 07:20:52 +0200 Subject: buildsys and kernel modules (was: Re: Summary from yesterdays fesco meeting) In-Reply-To: <1140271703.20024.23.camel@bobcat.mine.nu> References: <1140205181.2904.20.camel@localhost.localdomain> <1140210997.6735.22.camel@localhost.localdomain> <1140271703.20024.23.camel@bobcat.mine.nu> Message-ID: <1140499252.2466.16.camel@bobcat.mine.nu> On Sat, 2006-02-18 at 16:08 +0200, Ville Skytt? wrote: > Attached is a couple of rough patches I have had in my local working dir > for some time; they add support for passing arbitrary arguments to > builds and makes the build archs configurable in local "make foo" > builds. Hm, I don't know where that kmod patch came from, it needs a s/variants/kvariants/ From bugzilla at redhat.com Tue Feb 21 05:29:37 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 00:29:37 -0500 Subject: [Bug 181753] Review Request: mm - Shared memory allocation library In-Reply-To: Message-ID: <200602210529.k1L5TbfH019922@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mm - Shared memory allocation library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181753 ------- Additional Comments From ville.skytta at iki.fi 2006-02-21 00:29 EST ------- Look for something that strips the binaries during build, and get rid of that. "strip", "install -s", and "ld -s" are common culprits. Oh... I see you're running strip yourself in the specfile, so yes, you _did_ remove that stuff from the package. Don't do that, just have redhat-rpm-config installed and let rpmbuild take care of it. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 21 05:33:00 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 00:33:00 -0500 Subject: [Bug 177276] Review Request: perl-DBD-AnyData : DBI access to XML, CSV and other formats In-Reply-To: Message-ID: <200602210533.k1L5X0Ls020724@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-DBD-AnyData : DBI access to XML, CSV and other formats https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177276 ------- Additional Comments From ville.skytta at iki.fi 2006-02-21 00:32 EST ------- (In reply to comment #2) > %build should be: > %{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS" There's no need to use OPTIMIZE="$RPM_OPT_FLAGS" for noarch packages. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 21 05:53:19 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 00:53:19 -0500 Subject: [Bug 182077] Review Request: cfv - utility to test and create checksums In-Reply-To: Message-ID: <200602210553.k1L5rJ5D023496@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cfv - utility to test and create checksums https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182077 a.kurtz at hardsun.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From a.kurtz at hardsun.net 2006-02-21 00:53 EST ------- Successfully built for rawhide and FC-4 branch requested. Time to close it. Thanks for the review, Jochen. Thanks for the watchful eye, Brian. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rc040203 at freenet.de Tue Feb 21 06:24:30 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 21 Feb 2006 07:24:30 +0100 Subject: static libs ... again In-Reply-To: <43FA1011.9000608@cora.nwra.com> References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> <1140243907.21764.402.camel@mccallum.corsepiu.local> <43F9BE60.1090705@hhs.nl> <1140441846.21764.558.camel@mccallum.corsepiu.local> <43FA1011.9000608@cora.nwra.com> Message-ID: <1140503071.21764.616.camel@mccallum.corsepiu.local> On Mon, 2006-02-20 at 11:53 -0700, Orion Poplawski wrote: > Ralf Corsepius wrote: > > On Mon, 2006-02-20 at 07:10 -0600, Rex Dieter wrote: > >> Hans de Goede wrote: > >>> Rex Dieter wrote: > >>>> One question to beg here... I maintain several libraries that come > >>>> *only* as static libs(*). At the moment, these pkgs provide *only* a > >>>> -devel pkg (pending upstream fix(es) to allow for shared/dynamic > >>>> libs). Is that acceptable or should these get split too? > >>> Not split, but renamed would be a good so replace -devel with -static. > > ACK, plus letting -static provide -devel. > > > > For packages having both static and shared libraries I'd, put > > everything but the static libs into *-devel and let *-static "Requires: > > *-devel". > > > > [BTW: we had discussed this in great dep several months ago on one of > > this too many fedora lists.] > - -devel requires -static if no shared libs so that dependent packages > only use BR: -devel. This would render the whole purpose of this undertaking absurd. The whole idea is to break compatibility between *-devel and *-static packages, such that packages really _needing_ to link against *static libs can't avoid to 'BR: *-static", while package wanting "any library" will get them through "BR: *-devel", no matter whether they are static or shared. I.e. * For packages providing shared libs and static libs: headers and shared libs in *-devel, static libs in *static, *-static requires *-devel. Using shared libs would imply BR: *-devel. Using static libs would imply BR: *-static. * For packages providing stared libs only: headers and shared libs in *-devel. Using shared libs would imply BR: *-devel. * For packages providing static libs only: Headers and shared libs in *-devel + "Provides: *-static". Using libs would imply BR: *-devel. Packages intentionally wanting static libs would: BR: *-static. Ralf From rc040203 at freenet.de Tue Feb 21 06:27:12 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 21 Feb 2006 07:27:12 +0100 Subject: static libs ... again In-Reply-To: <20060220200441.GH2861@free.fr> References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> <1140243907.21764.402.camel@mccallum.corsepiu.local> <43F9BE60.1090705@hhs.nl> <1140441846.21764.558.camel@mccallum.corsepiu.local> <43FA1011.9000608@cora.nwra.com> <20060220200441.GH2861@free.fr> Message-ID: <1140503232.21764.620.camel@mccallum.corsepiu.local> On Mon, 2006-02-20 at 21:04 +0100, Patrice Dumas wrote: > > Not sure who I'm agreeing with here :-), but: > > > > - Put static libs in -static (so they don't get used accidentally) > > static libs are never used when there are static and dynamic libs > available (and linking with -l). Wrong. Wasn't it you who started this thread, because he claims to need linking against static libs? Then you should be familiar with gcc --shared/--static. Ralf From paul at city-fan.org Tue Feb 21 07:47:48 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 21 Feb 2006 07:47:48 +0000 Subject: Changing maintainer in general (WAS Re: Anjuta - change of maintainer) In-Reply-To: <1140480584.2971.11.camel@T7.Linux> References: <1140476355.2971.1.camel@T7.Linux> <1140480279.10765.26.camel@cosima.et.endace.com> <1140480584.2971.11.camel@T7.Linux> Message-ID: <1140508068.2716.1.camel@laurel.intra.city-fan.org> On Tue, 2006-02-21 at 00:09 +0000, Paul F. Johnson wrote: > Hi, > > > This is great. I am a little disheartened over the whole orphaned taking > > ownership process. > > > > I asked sometime ago about this: > > > > https://www.redhat.com/archives/fedora-extras-list/2006-January/msg01457.html > > > > And got no response. > > Odd - you should have. That said, enquiries about orphaned packages are > quite frequent and most of the time, you get pointed to the list below. > > > What is the process of a new comer to take ownership of a package? > > http://fedoraproject.org/wiki/Extras/OrphanedPackages > > Contains all ye shall need > > > I have a Fedora account, what else is needed? > > As long as you have the upload certs, you should be good to go (for > orphaned packages - these will have already have gone through the review > process. New packages need to go through the usual bugzilla system) You do, however, still need to update owners.list to get the bugzilla component assigned to you. The anjuta entry still says it's orphaned: Fedora Extras|anjuta|GNOME IDE for C and C++| extras-orphan at fedoraproject.org|extras-qa at fedoraproject.org| Paul. From mmcgrath at fedoraproject.org Tue Feb 21 07:48:55 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 21 Feb 2006 01:48:55 -0600 Subject: Crontab and init scripts In-Reply-To: References: <3237e4410602200046r3d9f871h2d4ba57c4556a80e@mail.gmail.com> <20060220164554.GB17008@devserv.devel.redhat.com> Message-ID: <3237e4410602202348j6fc83e34o62e1dc5ee2c21cfd@mail.gmail.com> > > * You could have the init.d script create and delete the crontab > entry. Certainly not much more palatable. > > * Accept the status quo, where package installation is equated with > "I want to run the service". > > * Don't involve cron at all: start a shell script in the background, > which fires off the real job once every five minutes. > > * Make the admin put the crontab in place and ignore the standard > method of specifying what services should run altogether. > > I prefer the Yum method, myself. > The other option I've considered is simply not installing the cron job at all and requiring the user to do it. The user already has to configure db connections in /etc/cacti I might just add a step that says "copy the cron script from the cacti doc's to /etc/cron.d/" -Mike From paul at city-fan.org Tue Feb 21 07:54:05 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 21 Feb 2006 07:54:05 +0000 Subject: Specifying arch in BuildRequires: In-Reply-To: References: Message-ID: <1140508445.2716.4.camel@laurel.intra.city-fan.org> On Mon, 2006-02-20 at 19:17 -0600, Jason L Tibbitts III wrote: > I'm trying to package GNU Pascal and I'm running into a problem on > x86_64. Since x86_64 is a multilib platform, the build process will > try to build both 64 and 32 bit libraries. Therefore it needs > glibc-devel for both x86_64 and i386 to be installed during the > build. (Otherwise the build fails for lack of > /usr/include/gnu/stubs-32.h.) > > So, any ideas on how I can convince mock to install glibc-devel on > both architectures? Alternately, is there a GCC build expert in the > house? You might want to check out the ghdl spec, which deals with similar issues. It's a gcc-based VHDL compiler. Paul. From paul at all-the-johnsons.co.uk Tue Feb 21 08:46:07 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Tue, 21 Feb 2006 08:46:07 +0000 Subject: Changing maintainer in general (WAS Re: Anjuta - change of maintainer) In-Reply-To: <1140508068.2716.1.camel@laurel.intra.city-fan.org> References: <1140476355.2971.1.camel@T7.Linux> <1140480279.10765.26.camel@cosima.et.endace.com> <1140480584.2971.11.camel@T7.Linux> <1140508068.2716.1.camel@laurel.intra.city-fan.org> Message-ID: <1140511568.2971.15.camel@T7.Linux> Hi, > The anjuta entry still says it's orphaned: > > Fedora Extras|anjuta|GNOME IDE for C and C++| > extras-orphan at fedoraproject.org|extras-qa at fedoraproject.org| Odd. My local copy says otherwise and I did do a cvs update last night... TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show From paul at all-the-johnsons.co.uk Tue Feb 21 08:47:33 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Tue, 21 Feb 2006 08:47:33 +0000 Subject: Changing maintainer in general (WAS Re: Anjuta - change of maintainer) In-Reply-To: <1140482203.10765.29.camel@cosima.et.endace.com> References: <1140476355.2971.1.camel@T7.Linux> <1140480279.10765.26.camel@cosima.et.endace.com> <1140481342.20465.3.camel@shuttle.273piedmont.org> <1140482203.10765.29.camel@cosima.et.endace.com> Message-ID: <1140511653.2971.18.camel@T7.Linux> Hi, > So if no one complains I can assume maintainer's role (read: no feed > back at all from the list)? Yes. But it's always a good idea to at least mention it (just incase someone has adopted it and forgot to mention it or, as in the case of Wine or wxWidgets, many are working on it) TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show From pertusus at free.fr Tue Feb 21 08:46:55 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 21 Feb 2006 09:46:55 +0100 Subject: static libs ... again In-Reply-To: <1140503232.21764.620.camel@mccallum.corsepiu.local> References: <1140230304.31903.54.camel@ernie> <1140243907.21764.402.camel@mccallum.corsepiu.local> <43F9BE60.1090705@hhs.nl> <1140441846.21764.558.camel@mccallum.corsepiu.local> <43FA1011.9000608@cora.nwra.com> <20060220200441.GH2861@free.fr> <1140503232.21764.620.camel@mccallum.corsepiu.local> Message-ID: <20060221084655.GC3018@free.fr> > Wrong. > > Wasn't it you who started this thread, because he claims to need linking > against static libs? > > Then you should be familiar with gcc --shared/--static. When none of these options are present, shared libs are used in priority, and I believe it is the case for all the fc arches. -- Pat From michael at knox.net.nz Tue Feb 21 08:50:12 2006 From: michael at knox.net.nz (Michael J Knox) Date: Tue, 21 Feb 2006 21:50:12 +1300 Subject: Changing maintainer in general (WAS Re: Anjuta - change of maintainer) In-Reply-To: <1140511653.2971.18.camel@T7.Linux> References: <1140476355.2971.1.camel@T7.Linux> <1140480279.10765.26.camel@cosima.et.endace.com> <1140481342.20465.3.camel@shuttle.273piedmont.org> <1140482203.10765.29.camel@cosima.et.endace.com> <1140511653.2971.18.camel@T7.Linux> Message-ID: <1140511813.4417.11.camel@pingu.homenetwork.lan> On Tue, 2006-02-21 at 08:47 +0000, Paul F. Johnson wrote: > Hi, > > > So if no one complains I can assume maintainer's role (read: no feed > > back at all from the list)? > > Yes. But it's always a good idea to at least mention it (just incase > someone has adopted it and forgot to mention it or, as in the case of > Wine or wxWidgets, many are working on it) > OK, thanks for the clarification. Michael From paul at all-the-johnsons.co.uk Tue Feb 21 08:52:32 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Tue, 21 Feb 2006 08:52:32 +0000 Subject: Changing maintainer in general (WAS Re: Anjuta - change of maintainer) In-Reply-To: <1140511568.2971.15.camel@T7.Linux> References: <1140476355.2971.1.camel@T7.Linux> <1140480279.10765.26.camel@cosima.et.endace.com> <1140480584.2971.11.camel@T7.Linux> <1140508068.2716.1.camel@laurel.intra.city-fan.org> <1140511568.2971.15.camel@T7.Linux> Message-ID: <1140511952.2971.20.camel@T7.Linux> Hi, > > Fedora Extras|anjuta|GNOME IDE for C and C++| > > extras-orphan at fedoraproject.org|extras-qa at fedoraproject.org| > > Odd. My local copy says otherwise and I did do a cvs update last > night... Now updated correctly! TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show From bugzilla at redhat.com Tue Feb 21 08:52:39 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 03:52:39 -0500 Subject: [Bug 181979] Review Request: python-geoip - Python bindings for the GeoIP geographical lookup libraries In-Reply-To: Message-ID: <200602210852.k1L8qdgG018751@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: python-geoip - Python bindings for the GeoIP geographical lookup libraries https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181979 ------- Additional Comments From mfleming+rpm at enlartenment.com 2006-02-21 03:52 EST ------- Spec Name or Url: http://www.enlartenment.com/extras/python-GeoIP.spec SRPM Name or Url: http://www.enlartenment.com/extras/python-GeoIP-1.2.1-3.src.rpm Recommendations noted and updates made. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 21 08:59:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 03:59:53 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602210859.k1L8xrhC020441@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 ------- Additional Comments From folkert at vanheusden.com 2006-02-21 03:59 EST ------- oh darn :-( Ok, I fixed the permissions. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From paul at all-the-johnsons.co.uk Tue Feb 21 09:12:02 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 21 Feb 2006 09:12:02 +0000 Subject: Is there an easier way to do this? Message-ID: <1140513122.2971.29.camel@T7.Linux> Hi, I'm compiling up anjuta-gdl which installs a pile of stuff into /usr/share/gdl (and it's quite a lot). Currently, I have in my specfile %install rm -rf ${RPM_BUILD_ROOT} %makeinstall %find_lang gdl find ${RPM_BUILD_ROOT} -type f -name "*.la" -exec rm -f {} ";" find ${RPM_BUILD_ROOT} -type f -name "*.a" -exec rm -f {} ";" The make part works fine, but the makeinstall fails, but I'm not clear as to why. The first item it tries to install /usr/bin/install -c -m 644 ./layout.glade /var/tmp/anjuta-gdl-0.6.0-2-root-paul /usr/share/gdl/glade/layout.glade goes in fine However, when it comes to installing images into /usr/share/gdl/images it fails. Any ideas? TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From bugzilla at redhat.com Tue Feb 21 09:31:24 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 04:31:24 -0500 Subject: [Bug 166255] Review Request: Sprog In-Reply-To: Message-ID: <200602210931.k1L9VOJJ027611@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Sprog https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166255 ------- Additional Comments From ivazquez at ivazquez.net 2006-02-21 04:31 EST ------- So is this package in limbo or what? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 21 09:52:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 04:52:07 -0500 Subject: [Bug 181753] Review Request: mm - Shared memory allocation library In-Reply-To: Message-ID: <200602210952.k1L9q7Vj000503@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mm - Shared memory allocation library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181753 ------- Additional Comments From andreas at bawue.net 2006-02-21 04:51 EST ------- Ahrgl. Right. I put a strip call in there. Sorry, forgot about that. Now that I think about it, I did this as otherwise rpmlint would complain about "W: mm unstripped-binary-or-object /usr/lib/libmm.so.14.0.20". I thought just stripping the lib would be enough, but didn't think about the debugpackage. The problem were wrong permissions, which made find-debuginfo.sh not pick up the library. Fixed now & spec updated. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From paul at city-fan.org Tue Feb 21 10:04:55 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 21 Feb 2006 10:04:55 +0000 Subject: Changing maintainer in general (WAS Re: Anjuta - change of maintainer) In-Reply-To: <1140511952.2971.20.camel@T7.Linux> References: <1140476355.2971.1.camel@T7.Linux> <1140480279.10765.26.camel@cosima.et.endace.com> <1140480584.2971.11.camel@T7.Linux> <1140508068.2716.1.camel@laurel.intra.city-fan.org> <1140511568.2971.15.camel@T7.Linux> <1140511952.2971.20.camel@T7.Linux> Message-ID: <43FAE5C7.3050903@city-fan.org> Paul F. Johnson wrote: > Hi, > > > >>>Fedora Extras|anjuta|GNOME IDE for C and C++| >>>extras-orphan at fedoraproject.org|extras-qa at fedoraproject.org| >> >>Odd. My local copy says otherwise and I did do a cvs update last >>night... > > > Now updated correctly! I don't think so: $ cd owners $ cvs update -dP For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs Enter passphrase for key '/nis-home/phowarth/.ssh/id_dsa': cvs update: Updating . P owners.list $ grep -F anj owners.list Fedora Extras|anjuta|GNOME IDE for C and C++|extras-orphan at fedoraproject.org|extras-qa at fedoraproject.org| Fedora Extras|ddskk|Daredevil SKK - Simple Kana to Kanji conversion program for Emacs|petersen at redhat.com|extras-qa at fedoraproject.org| Fedora Extras|kinput2|Japanese kanji input server for X11|tagoh at redhat.com|extras-qa at fedoraproject.org| No sign of an update to owners.list by you on fedora-extras-commits either. Did you commit the change? Paul. From paul at city-fan.org Tue Feb 21 10:07:44 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 21 Feb 2006 10:07:44 +0000 Subject: Is there an easier way to do this? In-Reply-To: <1140513122.2971.29.camel@T7.Linux> References: <1140513122.2971.29.camel@T7.Linux> Message-ID: <43FAE670.5000005@city-fan.org> Paul wrote: > Hi, > > I'm compiling up anjuta-gdl which installs a pile of stuff > into /usr/share/gdl (and it's quite a lot). > > Currently, I have in my specfile > > %install > rm -rf ${RPM_BUILD_ROOT} > %makeinstall > %find_lang gdl > find ${RPM_BUILD_ROOT} -type f -name "*.la" -exec rm -f {} ";" > find ${RPM_BUILD_ROOT} -type f -name "*.a" -exec rm -f {} ";" > > The make part works fine, but the makeinstall fails, but I'm not clear > as to why. The first item it tries to install > > /usr/bin/install -c -m > 644 ./layout.glade /var/tmp/anjuta-gdl-0.6.0-2-root-paul /usr/share/gdl/glade/layout.glade > > goes in fine > > However, when it comes to installing images into /usr/share/gdl/images > it fails. > > Any ideas? Try instead of %makeinstall: make DESTDIR=${RPM_BUILD_ROOT} install Some packages require one or the other. In cases where both appear to work, the latter is preferred anyway. Paul. From paul at all-the-johnsons.co.uk Tue Feb 21 10:30:13 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Tue, 21 Feb 2006 10:30:13 +0000 Subject: Changing maintainer in general (WAS Re: Anjuta - change of maintainer) In-Reply-To: <43FAE5C7.3050903@city-fan.org> References: <1140476355.2971.1.camel@T7.Linux> <1140480279.10765.26.camel@cosima.et.endace.com> <1140480584.2971.11.camel@T7.Linux> <1140508068.2716.1.camel@laurel.intra.city-fan.org> <1140511568.2971.15.camel@T7.Linux> <1140511952.2971.20.camel@T7.Linux> <43FAE5C7.3050903@city-fan.org> Message-ID: <1140517813.23265.0.camel@mrwibble.mrwobble> Hi, > No sign of an update to owners.list by you on fedora-extras-commits > either. Did you commit the change? Doh! That should have it... TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From paul at city-fan.org Tue Feb 21 10:40:16 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 21 Feb 2006 10:40:16 +0000 Subject: Changing maintainer in general (WAS Re: Anjuta - change of maintainer) In-Reply-To: <1140517813.23265.0.camel@mrwibble.mrwobble> References: <1140476355.2971.1.camel@T7.Linux> <1140480279.10765.26.camel@cosima.et.endace.com> <1140480584.2971.11.camel@T7.Linux> <1140508068.2716.1.camel@laurel.intra.city-fan.org> <1140511568.2971.15.camel@T7.Linux> <1140511952.2971.20.camel@T7.Linux> <43FAE5C7.3050903@city-fan.org> <1140517813.23265.0.camel@mrwibble.mrwobble> Message-ID: <43FAEE10.7060009@city-fan.org> Paul F. Johnson wrote: > Hi, > > >>No sign of an update to owners.list by you on fedora-extras-commits >>either. Did you commit the change? > > > Doh! > > That should have it... Yep, though the owners.list now has some garbage in it that needs cleaning up: ... Fedora Extras|fslint|FSlint - a utility to find and clean "lint" on a filesystem|P at draigBrady.com|extras-qa at fedoraproject.org| <<<<<<< owners.list Fedora Extras|fuse-emulator|ZX Spectrum emulator|paul at all-the-johnsons.co.uk|extras-qa at fedoraproject.org| ======= Fedora Extras|fuse|File System in Userspace|lemenkov at newmail.ru|extras-qa at fedoraproject.org| >>>>>>> 1.657 Fedora Extras|fuse-encfs|Encrypted pass-thru filesystem in userspace|lemenkov at newmail.ru|extras-qa at fedoraproject.org| <<<<<<< owners.list Fedora Extras|fuse|File System in Userspace|fedora at leemhuis.info|extras-qa at fedoraproject.org| Fedora Extras|fuse-sshfs|FUSE-Filesystem to access remote filesystems via SSH|fedora at leemhuis.info|extras-qa at fedoraproject.org| Fedora Extras|fuse-utils|Utilities for the Fuse-emulator package|paul at all-the-johnsons.co.uk|extras-qa at fedoraproject.org| ======= Fedora Extras|fuse-sshfs|FUSE-Filesystem to access remote filesystems via SSH|lemenkov at newmail.ru|extras-qa at fedoraproject.org| >>>>>>> 1.657 Fedora Extras|fwbuilder|Firewall Builder|redhat-bugzilla at camperquake.de|extras-qa at fedoraproject.org| ... It's good practice to do "cvs update", edit, then "cvs commit" as close as possible to each other for the owners.list file to avoid this sort of problem. You should also edit http://www.fedoraproject.org/wiki/Extras/OrphanedPackages and remove anjuta from it. i'd also check out http://www.fedoraproject.org/wiki/Extras/PackageStatus where some of your packages are mentioned. Paul. From fedora at leemhuis.info Tue Feb 21 10:44:54 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 21 Feb 2006 11:44:54 +0100 Subject: Changing maintainer in general (WAS Re: Anjuta - change of maintainer) In-Reply-To: <1140517813.23265.0.camel@mrwibble.mrwobble> References: <1140476355.2971.1.camel@T7.Linux> <1140480279.10765.26.camel@cosima.et.endace.com> <1140480584.2971.11.camel@T7.Linux> <1140508068.2716.1.camel@laurel.intra.city-fan.org> <1140511568.2971.15.camel@T7.Linux> <1140511952.2971.20.camel@T7.Linux> <43FAE5C7.3050903@city-fan.org> <1140517813.23265.0.camel@mrwibble.mrwobble> Message-ID: <1140518694.28873.59.camel@thl.ct.heise.de> Am Dienstag, den 21.02.2006, 10:30 +0000 schrieb Paul F. Johnson: > Hi, > > > No sign of an update to owners.list by you on fedora-extras-commits > > either. Did you commit the change? > > Doh! > > That should have it... No -- now there are multiple lines in owners.list that shouldn't be there. For example: <<<<<<< owners.list ======= >>>>>>> 1.657 Paul, please fix it. And everyone: Please use "cvs diff -u" to look at the changes that you are going to commit before actually committing them. tia CU thl -------------- next part -------------- An embedded message was scrubbed... From: "Paul F. Johnson" (pfj) Subject: owners owners.list,1.660,1.661 Date: Tue, 21 Feb 2006 05:29:22 -0500 Size: 10744 URL: From paul at all-the-johnsons.co.uk Tue Feb 21 10:47:23 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Tue, 21 Feb 2006 10:47:23 +0000 Subject: find_lang problem Message-ID: <1140518844.23265.11.camel@mrwibble.mrwobble> Hi, As there is already a package called gdl in extras, I've had to rename the gnome gdl package to anjuta-gdl (the other gdl is not the gnome one) - the entry in the .spec file is Name: anjuta-gdl There are a number of translations in the package, so in the %install section, I have the usual %find_lang %{name} However, this is reporting back that there are no translations found in anjuta-gdl-0.6.0-2-root-paul anjuta-gdl Do I need to do something different due to the difference in the name? TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From bugzilla at redhat.com Tue Feb 21 10:46:29 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 05:46:29 -0500 Subject: [Bug 174883] Review Request: distcc -- A free distributed C/C++ compiler system In-Reply-To: Message-ID: <200602211046.k1LAkT7w013178@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: distcc -- A free distributed C/C++ compiler system https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174883 ------- Additional Comments From ivazquez at ivazquez.net 2006-02-21 05:46 EST ------- Is this package in limbo? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From paul at all-the-johnsons.co.uk Tue Feb 21 10:51:25 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Tue, 21 Feb 2006 10:51:25 +0000 Subject: Changing maintainer in general (WAS Re: Anjuta - change of maintainer) In-Reply-To: <43FAEE10.7060009@city-fan.org> References: <1140476355.2971.1.camel@T7.Linux> <1140480279.10765.26.camel@cosima.et.endace.com> <1140480584.2971.11.camel@T7.Linux> <1140508068.2716.1.camel@laurel.intra.city-fan.org> <1140511568.2971.15.camel@T7.Linux> <1140511952.2971.20.camel@T7.Linux> <43FAE5C7.3050903@city-fan.org> <1140517813.23265.0.camel@mrwibble.mrwobble> <43FAEE10.7060009@city-fan.org> Message-ID: <1140519085.23265.13.camel@mrwibble.mrwobble> Hi, > You should also edit > http://www.fedoraproject.org/wiki/Extras/OrphanedPackages and remove > anjuta from it. > > i'd also check out > http://www.fedoraproject.org/wiki/Extras/PackageStatus where some of > your packages are mentioned. Will do tonight. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From ivazquez at ivazquez.net Tue Feb 21 10:53:07 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 21 Feb 2006 05:53:07 -0500 Subject: find_lang problem In-Reply-To: <1140518844.23265.11.camel@mrwibble.mrwobble> References: <1140518844.23265.11.camel@mrwibble.mrwobble> Message-ID: <1140519187.1252.0.camel@ignacio.lan> On Tue, 2006-02-21 at 10:47 +0000, Paul F. Johnson wrote: > Name: anjuta-gdl > %find_lang %{name} > > However, this is reporting back that there are no translations found in > anjuta-gdl-0.6.0-2-root-paul anjuta-gdl > > Do I need to do something different due to the difference in the name? Yes. The parameter to %find_lang should match the .mo filename. -- 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 mmcgrath at fedoraproject.org Tue Feb 21 10:50:54 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 21 Feb 2006 04:50:54 -0600 Subject: deciphering a build failure In-Reply-To: <43FA4813.1040205@cora.nwra.com> References: <1140449329.3729.12.camel@tameshk.farsiweb.info> <43FA4813.1040205@cora.nwra.com> Message-ID: <3237e4410602210250u121e5d82p55e3decf7e5a91e5@mail.gmail.com> > > This is weird. There is no indication that yum exited with any errors, > yet the build stops. At first I thought the following: > > ls: readlink:: No such file or directory > ls: file: No such file or directory > ls: expected: No such file or directory > cp: cannot stat `/dev/md1': No such file or directory > > were relevant, but you find them in logs of successful builds. > > The problem seems to have occurred between > > Mon Feb 20 05:06:54 2006 (when the last FC4 job succeeded (4939: > dap-server-3.5.3-1.fc4) > Mon Feb 20 08:29:27 2006 (when this job failed) > > At this point I think it points to the build systems. I can't reproduce > in mock locally. > > > It might be boa though: > > warning: user apache does not exist - using root > warning: group apache does not exist - using root > > is new. > > boa is not installed when I run mock locally. why? I may be getting the same issue: http://buildsys.fedoraproject.org/logs/fedora-4-extras/5004-ytalk-3.3.0-3.fc4/i386/job.log devel builds fine, FC4 does not. -Mike From paul at all-the-johnsons.co.uk Tue Feb 21 10:57:10 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Tue, 21 Feb 2006 10:57:10 +0000 Subject: find_lang problem In-Reply-To: <1140519187.1252.0.camel@ignacio.lan> References: <1140518844.23265.11.camel@mrwibble.mrwobble> <1140519187.1252.0.camel@ignacio.lan> Message-ID: <1140519430.23265.15.camel@mrwibble.mrwobble> Hi, > > Do I need to do something different due to the difference in the name? > > Yes. The parameter to %find_lang should match the .mo filename. Ah. %find_lang gdl gives the same problem. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From bugzilla at redhat.com Tue Feb 21 10:54:03 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 05:54:03 -0500 Subject: [Bug 174883] Review Request: distcc -- A free distributed C/C++ compiler system In-Reply-To: Message-ID: <200602211054.k1LAs3Ws014778@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: distcc -- A free distributed C/C++ compiler system https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174883 ------- Additional Comments From ch.nolte at fh-wolfenbuettel.de 2006-02-21 05:53 EST ------- So it seems... As there has been no further reply from the original poster, I would offer adopting this package. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From paul at city-fan.org Tue Feb 21 11:04:51 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 21 Feb 2006 11:04:51 +0000 Subject: Changing maintainer in general (WAS Re: Anjuta - change of maintainer) In-Reply-To: <1140519085.23265.13.camel@mrwibble.mrwobble> References: <1140476355.2971.1.camel@T7.Linux> <1140480279.10765.26.camel@cosima.et.endace.com> <1140480584.2971.11.camel@T7.Linux> <1140508068.2716.1.camel@laurel.intra.city-fan.org> <1140511568.2971.15.camel@T7.Linux> <1140511952.2971.20.camel@T7.Linux> <43FAE5C7.3050903@city-fan.org> <1140517813.23265.0.camel@mrwibble.mrwobble> <43FAEE10.7060009@city-fan.org> <1140519085.23265.13.camel@mrwibble.mrwobble> Message-ID: <43FAF3D3.5070500@city-fan.org> Paul F. Johnson wrote: > Hi, > > >>You should also edit >>http://www.fedoraproject.org/wiki/Extras/OrphanedPackages and remove >>anjuta from it. >> >>i'd also check out >>http://www.fedoraproject.org/wiki/Extras/PackageStatus where some of >>your packages are mentioned. > > > Will do tonight. OK, but please fix owners.list right now. Paul. From bugzilla at redhat.com Tue Feb 21 11:09:38 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 06:09:38 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602211109.k1LB9cCn017689@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 beekhof at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |beekhof at gmail.com ------- Additional Comments From beekhof at gmail.com 2006-02-21 06:09 EST ------- Regarding helper.sh It is *never* supposed to be executed on its own and should not have #!/bin/sh added to to it. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From pertusus at free.fr Tue Feb 21 11:14:36 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 21 Feb 2006 12:14:36 +0100 Subject: deciphering a build failure In-Reply-To: <3237e4410602210250u121e5d82p55e3decf7e5a91e5@mail.gmail.com> References: <1140449329.3729.12.camel@tameshk.farsiweb.info> <43FA4813.1040205@cora.nwra.com> <3237e4410602210250u121e5d82p55e3decf7e5a91e5@mail.gmail.com> Message-ID: <20060221111436.GC2729@free.fr> > > boa is not installed when I run mock locally. why? > > I may be getting the same issue: > http://buildsys.fedoraproject.org/logs/fedora-4-extras/5004-ytalk-3.3.0-3.fc4/i386/job.log > devel builds fine, FC4 does not. I also get the same issue on FC-4, FC-3 and devel build fine. Something is certainly broken. -- Pat From bugzilla at redhat.com Tue Feb 21 11:18:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 06:18:01 -0500 Subject: [Bug 166547] Review Request: multisync - Calendar (and other PIM data) synchronization program In-Reply-To: Message-ID: <200602211118.k1LBI1TY019104@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multisync - Calendar (and other PIM data) synchronization program https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166547 ------- Additional Comments From andreas.bierfert at lowlatency.de 2006-02-21 06:17 EST ------- Here is a fixed up version. Sadly it just segfaults here on x86_64/rawhide... http://fedora.lowlatency.de/review/multisync-0.90.18-3.src.rpm http://fedora.lowlatency.de/review/multisync.spec -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 21 11:39:00 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 06:39:00 -0500 Subject: [Bug 174883] Review Request: distcc -- A free distributed C/C++ compiler system In-Reply-To: Message-ID: <200602211139.k1LBd0jY022857@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: distcc -- A free distributed C/C++ compiler system https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174883 ------- Additional Comments From enrico.scholz at informatik.tu-chemnitz.de 2006-02-21 06:38 EST ------- not so fast... there was some silence between my original submission and the first review. Other things toke higher priority and I had no time yet to address the issues from comment #3 completely. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 21 11:42:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 06:42:33 -0500 Subject: [Bug 175425] Review Request: tile - Modern versions of Tk widget set In-Reply-To: Message-ID: <200602211142.k1LBgXjw023682@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: tile - Modern versions of Tk widget set https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175425 ivazquez at ivazquez.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |ivazquez at ivazquez.net OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From ivazquez at ivazquez.net 2006-02-21 06:42 EST ------- - Patch filename has no descriptive quality - Odd spacing in %changelog ? Is the static lib in -devel required? - Include demos, doc/converting.txt, and doc/html in %doc - Install doc/*.n into %{_mandir}/mann -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From gauret at free.fr Tue Feb 21 11:56:51 2006 From: gauret at free.fr (Aurelien Bompard) Date: Tue, 21 Feb 2006 12:56:51 +0100 Subject: Build failure for amarok Message-ID: I have a strange build failure for amarok 1.4beta1 (first one to use gstreamer 0.10) : ----- make[6]: *** No rule to make target `../../../../amarok/src/engine/gst/config/libgstconfig.la', needed by `libamarok_gst10engine_plugin.la'. Stop. ----- There is nothing before that which could make me think of a missing file or so. This error only happens in mock, not on a local build. I am not very familiar with libtool, could someone help me ? (I have to read this autotools manual some day) http://buildsys.fedoraproject.org/logs/fedora-development-extras/5006-amarok-1.4-0.3.beta1.fc5/x86_64/build.log Thanks Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr It is by caffeine alone that I set my mind in motion. It is by the beans of java that the thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone that I set my mind in motion. From bugzilla at redhat.com Tue Feb 21 12:15:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 07:15:27 -0500 Subject: [Bug 175495] Review Request: cgi-util: A C library for creating CGI programs In-Reply-To: Message-ID: <200602211215.k1LCFRH9028413@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cgi-util: A C library for creating CGI programs https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175495 ------- Additional Comments From ivazquez at ivazquez.net 2006-02-21 07:15 EST ------- - %description of -devel is overly verbose ? Why is the patch being used to rename files? - Does not build on mock FC4/i386. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From mmcgrath at fedoraproject.org Tue Feb 21 13:35:47 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 21 Feb 2006 07:35:47 -0600 Subject: Crontab and init scripts In-Reply-To: <3237e4410602202348j6fc83e34o62e1dc5ee2c21cfd@mail.gmail.com> References: <3237e4410602200046r3d9f871h2d4ba57c4556a80e@mail.gmail.com> <20060220164554.GB17008@devserv.devel.redhat.com> <3237e4410602202348j6fc83e34o62e1dc5ee2c21cfd@mail.gmail.com> Message-ID: <3237e4410602210535o3fc86ea8v510220749ab84b96@mail.gmail.com> I'm still open to discussion on this but I'm not convinced that the yum method is best to be used with Cacti. I've decided to leave the cron script in /etc/cron.d/ and simply comment out the line that causes it to run by default. I just think the "dual enable" thing is a little odd. In order for it to run it has to be started and be placed in cron. Also (being real strict here) the Yum method goes against FHS. The requrements for a pid file in /var/run require a PID. Since cron starts the poller regularly it starts and stops and the PID of it would change reqularly. http://www.pathname.com/fhs/pub/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA -Mike From skvidal at linux.duke.edu Tue Feb 21 13:41:37 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 21 Feb 2006 08:41:37 -0500 Subject: Crontab and init scripts In-Reply-To: <3237e4410602210535o3fc86ea8v510220749ab84b96@mail.gmail.com> References: <3237e4410602200046r3d9f871h2d4ba57c4556a80e@mail.gmail.com> <20060220164554.GB17008@devserv.devel.redhat.com> <3237e4410602202348j6fc83e34o62e1dc5ee2c21cfd@mail.gmail.com> <3237e4410602210535o3fc86ea8v510220749ab84b96@mail.gmail.com> Message-ID: <1140529297.28732.53.camel@cutter> On Tue, 2006-02-21 at 07:35 -0600, Mike McGrath wrote: > I'm still open to discussion on this but I'm not convinced that the > yum method is best to be used with Cacti. I've decided to leave the > cron script in /etc/cron.d/ and simply comment out the line that > causes it to run by default. > > I just think the "dual enable" thing is a little odd. In order for it > to run it has to be started and be placed in cron. Also (being real > strict here) the Yum method goes against FHS. The requrements for a > pid file in /var/run require a PID. Since cron starts the poller > regularly it starts and stops and the PID of it would change > reqularly. > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA umm - when did anyone say yum put a pid file in /var/run? lockfile=/var/lock/subsys/yum RETVAL=0 start() { echo -n $"Enabling nightly yum update: " touch "$lockfile" && success || failure RETVAL=$? echo } -sv From mmcgrath at fedoraproject.org Tue Feb 21 14:00:08 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 21 Feb 2006 08:00:08 -0600 Subject: Crontab and init scripts In-Reply-To: <1140529297.28732.53.camel@cutter> References: <3237e4410602200046r3d9f871h2d4ba57c4556a80e@mail.gmail.com> <20060220164554.GB17008@devserv.devel.redhat.com> <3237e4410602202348j6fc83e34o62e1dc5ee2c21cfd@mail.gmail.com> <3237e4410602210535o3fc86ea8v510220749ab84b96@mail.gmail.com> <1140529297.28732.53.camel@cutter> Message-ID: <3237e4410602210600s20d04d3p55ce7b1e3ea699bb@mail.gmail.com> > umm - when did anyone say yum put a pid file in /var/run? > > lockfile=/var/lock/subsys/yum > > RETVAL=0 > > start() { > echo -n $"Enabling nightly yum update: " > touch "$lockfile" && success || failure > RETVAL=$? > echo > } > > > -sv Sorry, I don't know why I thought that. Must...get...more..sleeeeeep..... :-D -Mike From ivg2 at cornell.edu Tue Feb 21 14:03:36 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Tue, 21 Feb 2006 09:03:36 -0500 Subject: Crontab and init scripts In-Reply-To: <3237e4410602210535o3fc86ea8v510220749ab84b96@mail.gmail.com> References: <3237e4410602200046r3d9f871h2d4ba57c4556a80e@mail.gmail.com> <20060220164554.GB17008@devserv.devel.redhat.com> <3237e4410602202348j6fc83e34o62e1dc5ee2c21cfd@mail.gmail.com> <3237e4410602210535o3fc86ea8v510220749ab84b96@mail.gmail.com> Message-ID: <43FB1DB8.3050107@cornell.edu> Mike McGrath wrote: > I'm still open to discussion on this but I'm not convinced that the > yum method is best to be used with Cacti. I've decided to leave the > cron script in /etc/cron.d/ and simply comment out the line that > causes it to run by default. > > I don't understand what's so hard to decide. Whatever method is chosen needs to integrate with system-config-services in one way or another, because that's what the user (me) expects. Certainly I don't want to be editing config files of any kind, that's the Unix way, and seems quite obsolete to me. Currently it seems that many services fail that test - I can tell just looking at the selinux denials - mrtg and munin and suspect. From bugs.michael at gmx.net Tue Feb 21 14:13:37 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 21 Feb 2006 15:13:37 +0100 Subject: source file "already there" but "not found" ? Was: Prep Error (Job 3879)fetchlog-1_0-4_fc5 on fedora-development-extras In-Reply-To: References: <20060214125005.23461785.bugs.michael@gmx.net> Message-ID: <20060221151337.31bcfa13.bugs.michael@gmx.net> On Mon, 20 Feb 2006 21:41:25 +0100 (CET), Paul Wouters wrote: > On Tue, 14 Feb 2006, Michael Schwendt wrote: > > > > -rw-rw-rw- 1 root root 339 Feb 6 14:59 fetchlog-build.patch > > > rpmbuild --define "_sourcedir /tmp/3879-fetchlog-1_0-4_fc5-1139445759/fetchlog/devel" --define "_builddir /tmp/3879-fetchlog-1_0-4_fc5-1139445759/fetchlog/devel" --define "_srcrpmdir /tmp/3879-fetchlog-1_0-4_fc5-1139445759/fetchlog/devel" --define "_rpmdir /tmp/3879-fetchlog-1_0-4_fc5-1139445759/fetchlog/devel" --define "dist .fc5" --define "fedora 5" --nodeps -bs fetchlog.spec > > > error: File /tmp/3879-fetchlog-1_0-4_fc5-1139445759/fetchlog/devel/fetchlog-1.0.tar.gz: No such file or directory > > > make: *** [srpm] Error 1 > > > > > > I am not sure why fetchlog-1.0.tar.gz vanished, since it did not change between releases. And > > > the system things it is still there: > > > > > > [paul at bofh devel]$ make new-sources "FILES=/usr/src/redhat/SOURCES/fetchlog-1.0.tar.gz " > > > > > > Checking : fetchlog-1.0.tar.gz on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... > > > This file (e2ef0a076d1901c489c953fe48e1b2a9 fetchlog-1.0.tar.gz) is already uploaded > > > > > > Source upload succeeded. Don't forget to commit the new ./sources file > > > For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs > > > M sources > > > M .cvsignore > > > > The lookaside cache mechanism also takes into account the file's MD5 > > checksum when retrieving a file. So make sure your local "sources" > > file is up-to-date and correct. Currently it is marked as 'M' > > (modified), so possibly contains a wrong checksum. Check out a > > fresh copy, try again. "make srpm" for fetchlog-1.0-4.fc5 works here. > > I commited the sources file and re-issued the build, but that did not seem > to be the real issue. Also, the sourcefile contents did not change between > builds, so I'm not sure how the previous built would have worked if the > checksum was wrong. > "make srpm" works fine. But "make plague" still fails with the above error. You still face an incorrectly tagged revision of fetchlog in CVS, in which your "sources" file is broken/incomplete and doesn't match the files you want in the .spec file. "make build" (don't use make plague any longer) retrieves the version of fetchlog from CVS, which is tagged as "fetchlog-1_0-4_fc5". It does this when fetchlog.spec in your working-copy contains that version-release 1.0-4%{?dist} in the devel branch. Try it: $ cvs co -r fetchlog-1_0-4_fc5 fetchlog $ cat fetchlog/devel/sources 99228569b122b994b1ab83148a3bd261 fetchlog-build.patch In this version, the tarball is missing, so it is not downloaded. In the untagged fresh checkout, the tarball is present in the "sources" file, but the patch is missing. You modified the files on Feb 21st, but didn't tag them correctly. From bugs.michael at gmx.net Tue Feb 21 14:19:53 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 21 Feb 2006 15:19:53 +0100 Subject: find_lang problem In-Reply-To: <1140518844.23265.11.camel@mrwibble.mrwobble> References: <1140518844.23265.11.camel@mrwibble.mrwobble> Message-ID: <20060221151953.73e9f45f.bugs.michael@gmx.net> On Tue, 21 Feb 2006 10:47:23 +0000, Paul F. Johnson wrote: > Hi, > > As there is already a package called gdl in extras, I've had to rename > the gnome gdl package to anjuta-gdl (the other gdl is not the gnome one) > - the entry in the .spec file is > > Name: anjuta-gdl > > There are a number of translations in the package, so in the %install > section, I have the usual > > %find_lang %{name} > > However, this is reporting back that there are no translations found in > anjuta-gdl-0.6.0-2-root-paul anjuta-gdl Show which translation files are present in the buildroot actually. From bugzilla at redhat.com Tue Feb 21 14:23:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 09:23:13 -0500 Subject: [Bug 177276] Review Request: perl-DBD-AnyData : DBI access to XML, CSV and other formats In-Reply-To: Message-ID: <200602211423.k1LEND0J019033@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-DBD-AnyData : DBI access to XML, CSV and other formats https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177276 ------- Additional Comments From tibbs at math.uh.edu 2006-02-21 09:23 EST ------- Of course you're correct; there's no need to use %{?_smp_mflags} for a package with a single perl file either. But sticklers complain about deviations from the template and I've had a couple of my reviews being second guessed lately, leading me to think that I'm being too lenient in not pointing out such deviations. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 21 14:32:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 09:32:34 -0500 Subject: [Bug 181979] Review Request: python-geoip - Python bindings for the GeoIP geographical lookup libraries In-Reply-To: Message-ID: <200602211432.k1LEWY4x021684@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: python-geoip - Python bindings for the GeoIP geographical lookup libraries https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181979 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From tibbs at math.uh.edu 2006-02-21 09:32 EST ------- Looks great. Approved. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From mmcgrath at fedoraproject.org Tue Feb 21 14:45:05 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 21 Feb 2006 08:45:05 -0600 Subject: Crontab and init scripts In-Reply-To: <43FB1DB8.3050107@cornell.edu> References: <3237e4410602200046r3d9f871h2d4ba57c4556a80e@mail.gmail.com> <20060220164554.GB17008@devserv.devel.redhat.com> <3237e4410602202348j6fc83e34o62e1dc5ee2c21cfd@mail.gmail.com> <3237e4410602210535o3fc86ea8v510220749ab84b96@mail.gmail.com> <43FB1DB8.3050107@cornell.edu> Message-ID: <3237e4410602210645sc263079sd4b8d5239d649d5f@mail.gmail.com> > Whatever method is chosen needs to integrate with system-config-services > in one way or another, because that's what the user (me) expects. > Certainly I don't want to be editing config files of any kind, that's > the Unix way, and seems quite obsolete to me. Currently it seems that > many services fail that test - I can tell just looking at the selinux > denials - mrtg and munin and suspect. > You should take a look at /etc/cron* There's many things listed there that won't show up in services. I'm not saying they shouldn't, but right now it would not be consistant for me to add Cacti to an init script. Logrotate is an excellent example, the logs don't rotate themselves and logrotate does not show up in system-config-services. I'm really not against the idea of using init for cron scripts, or somehow integrating cron into system-config-services. But I don't think its common practice. -Mike From tibbs at math.uh.edu Tue Feb 21 14:45:26 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 21 Feb 2006 08:45:26 -0600 Subject: Specifying arch in BuildRequires: In-Reply-To: <43FA9B74.30606@redhat.com> (Warren Togami's message of "Mon, 20 Feb 2006 23:47:48 -0500") References: <43FA9B74.30606@redhat.com> Message-ID: >>>>> "WT" == Warren Togami writes: WT> It is not possible to do with current RPM. GNU Pascal is just WT> plain wrong in what it is trying to do. It's not GNU Pascal doing the bad stuff, it's the GCC backend. And technically compiling something with -m32 is what it's supposed to be doing, as I understand things. I don't think GCC builds under mock either. WT> You need to patch it so it ignores the other arch and doesn't WT> attempt to build it. Which would result in a broken compiler as I understand things. - J< From bugzilla at redhat.com Tue Feb 21 14:42:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 09:42:33 -0500 Subject: [Bug 182254] New: Review Request: SS5 Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182254 Summary: Review Request: SS5 Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: matteo.ricchetti at libero.it QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://prdownloads.sourceforge.net/ss5/ss5-3.4-mr1.spec?download SRPM Name or Url: http://prdownloads.sourceforge.net/ss5/ss5-3.4-mr1.src.rpm?download Description: SS5 is a socks server that implements the SOCKS v4 and v5 protocol. As a proxy server, SS5 authenticates, profiles and processes network requests for clients. It establishes connections to application hosts for client applications. When the client attempts to access the network, the client connects to the SS5 daemon instead of the application host. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 21 14:43:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 09:43:20 -0500 Subject: [Bug 182255] New: Review Request: SS5 Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182255 Summary: Review Request: SS5 Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: matteo.ricchetti at libero.it QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://prdownloads.sourceforge.net/ss5/ss5-3.4-mr1.spec?download SRPM Name or Url: http://prdownloads.sourceforge.net/ss5/ss5-3.4-mr1.src.rpm?download Description: SS5 is a socks server that implements the SOCKS v4 and v5 protocol. As a proxy server, SS5 authenticates, profiles and processes network requests for clients. It establishes connections to application hosts for client applications. When the client attempts to access the network, the client connects to the SS5 daemon instead of the application host. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From tibbs at math.uh.edu Tue Feb 21 14:48:46 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 21 Feb 2006 08:48:46 -0600 Subject: Specifying arch in BuildRequires: In-Reply-To: <1140508445.2716.4.camel@laurel.intra.city-fan.org> (Paul Howarth's message of "Tue, 21 Feb 2006 07:54:05 +0000") References: <1140508445.2716.4.camel@laurel.intra.city-fan.org> Message-ID: >>>>> "PH" == Paul Howarth writes: PH> You might want to check out the ghdl spec, which deals with PH> similar issues. It's a gcc-based VHDL compiler. Thanks for the clue. I'm guessing it's this line in the configure call: %{!?_without_mock:--disable-multilib} plus the filtering of optflags to take out -m(anything). I'll give it a try. - J< From bugzilla at redhat.com Tue Feb 21 14:43:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 09:43:50 -0500 Subject: [Bug 182256] New: Review Request: Socks Server 5 Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182256 Summary: Review Request: Socks Server 5 Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: matteo.ricchetti at libero.it QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://prdownloads.sourceforge.net/ss5/ss5-3.4-mr1.spec?download SRPM Name or Url: http://prdownloads.sourceforge.net/ss5/ss5-3.4-mr1.src.rpm?download Description: SS5 is a socks server that implements the SOCKS v4 and v5 protocol. As a proxy server, SS5 authenticates, profiles and processes network requests for clients. It establishes connections to application hosts for client applications. When the client attempts to access the network, the client connects to the SS5 daemon instead of the application host. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 21 14:56:46 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 09:56:46 -0500 Subject: [Bug 182255] Review Request: SS5 In-Reply-To: Message-ID: <200602211456.k1LEuk6n027356@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: SS5 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182255 dennis at ausil.us changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |DUPLICATE ------- Additional Comments From dennis at ausil.us 2006-02-21 09:56 EST ------- you really only need to file 1 bug not 3 *** This bug has been marked as a duplicate of 182254 *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 21 14:56:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 09:56:53 -0500 Subject: [Bug 182254] Review Request: SS5 In-Reply-To: Message-ID: <200602211456.k1LEurp7027405@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: SS5 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182254 ------- Additional Comments From dennis at ausil.us 2006-02-21 09:56 EST ------- *** Bug 182255 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 21 14:57:24 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 09:57:24 -0500 Subject: [Bug 182256] Review Request: Socks Server 5 In-Reply-To: Message-ID: <200602211457.k1LEvObh027519@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Socks Server 5 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182256 dennis at ausil.us changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: Socks Server|Review Request: Socks Server |5 |5 Status|NEW |CLOSED Resolution| |DUPLICATE ------- Additional Comments From dennis at ausil.us 2006-02-21 09:57 EST ------- *** This bug has been marked as a duplicate of 182254 *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 21 14:57:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 09:57:30 -0500 Subject: [Bug 182254] Review Request: SS5 In-Reply-To: Message-ID: <200602211457.k1LEvUHe027586@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: SS5 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182254 ------- Additional Comments From dennis at ausil.us 2006-02-21 09:57 EST ------- *** Bug 182256 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From orion at cora.nwra.com Tue Feb 21 15:15:30 2006 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Tue, 21 Feb 2006 08:15:30 -0700 (MST) Subject: FC4 builds are broken - please fix! Message-ID: <26585.70.56.38.46.1140534930.squirrel@www.cora.nwra.com> This is an attempt to get more attention, lest it have fallen through the cracks due to a strange subject line. Please see the thread "deciphering a build failure". FC4 build are breaking. All architectures. I cannot reproduce locally with mock. - Orion From rc040203 at freenet.de Tue Feb 21 15:19:44 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 21 Feb 2006 16:19:44 +0100 Subject: Specifying arch in BuildRequires: In-Reply-To: References: <43FA9B74.30606@redhat.com> Message-ID: <1140535185.14289.71.camel@mccallum.corsepiu.local> On Tue, 2006-02-21 at 08:45 -0600, Jason L Tibbitts III wrote: > >>>>> "WT" == Warren Togami writes: > > WT> It is not possible to do with current RPM. GNU Pascal is just > WT> plain wrong in what it is trying to do. > It's not GNU Pascal doing the bad stuff, it's the GCC backend. And > technically compiling something with -m32 is what it's supposed to be > doing, as I understand things. GCC shouldn't do what you say, unless it being compiled with with multilibs enabled, which unless you compile --with-newlib enabled it should not do (And to my knowledge it doesn't) Do you have a log file of such a build run? I don't have access to x86_64 systems and therefore can't test. > I don't think GCC builds under mock > either. A matter of spec file implementation ... Mine do. Ralf From tibbs at math.uh.edu Tue Feb 21 15:39:34 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 21 Feb 2006 09:39:34 -0600 Subject: Specifying arch in BuildRequires: In-Reply-To: <1140535185.14289.71.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Tue, 21 Feb 2006 16:19:44 +0100") References: <43FA9B74.30606@redhat.com> <1140535185.14289.71.camel@mccallum.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> GCC shouldn't do what you say, unless it being compiled with with RC> multilibs enabled, which unless you compile --with-newlib enabled RC> it should not do (And to my knowledge it doesn't) You've seen the specfile; I don't pass --with-newlib. RC> Do you have a log file of such a build run? I don't have access to RC> x86_64 systems and therefore can't test. I can provide one as soon as my mirror finishes updating. Hopefully the bits I've cribbed from the ghdl package will get this thing building. - J< From rc040203 at freenet.de Tue Feb 21 15:54:42 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 21 Feb 2006 16:54:42 +0100 Subject: Specifying arch in BuildRequires: In-Reply-To: References: <43FA9B74.30606@redhat.com> <1140535185.14289.71.camel@mccallum.corsepiu.local> Message-ID: <1140537283.14289.84.camel@mccallum.corsepiu.local> On Tue, 2006-02-21 at 09:39 -0600, Jason L Tibbitts III wrote: > >>>>> "RC" == Ralf Corsepius writes: > > RC> GCC shouldn't do what you say, unless it being compiled with with > RC> multilibs enabled, which unless you compile --with-newlib enabled > RC> it should not do (And to my knowledge it doesn't) > > You've seen the specfile; I don't pass --with-newlib. --with-newlib or --enable-multilib? In GCC, multilibs are disabled by default, unless configuring --with-newlib, which implicitly enables multilibs and is completely useless for glibc-based targets. > RC> Do you have a log file of such a build run? I don't have access to > RC> x86_64 systems and therefore can't test. > > I can provide one as soon as my mirror finishes updating. Fine. > Hopefully the bits I've cribbed from the ghdl package will get this > thing building. You don't want to know what I think about ghdl.spec ... Ralf From bugzilla at redhat.com Tue Feb 21 16:14:55 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 11:14:55 -0500 Subject: [Bug 179758] Review Request: Eiciel (ACL editor) In-Reply-To: Message-ID: <200602211614.k1LGEtZt014389@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Eiciel (ACL editor) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179758 ------- Additional Comments From paul at city-fan.org 2006-02-21 11:14 EST ------- (In reply to comment #7) > # rpmlint -v eiciel-0.9-5.src.rpm > I: eiciel checking > W: eiciel strange-permission eiciel-gcc41.patch 0646 > > ok, my original file, I did chmod it when passing it between root and another > user, what is normal? 644? Yes. > I see that the template .spec file does use %{?dist} take, but I don't get .fc5 > in make RPMs is that ok for me, will it be ok in buildsys? You'll get them if you build it in mock, which includes the buildsys macros. So it'll be alright in the buildsys. > - MUST: The package must meet the Packaging Guidelines. > > hmm, should I really treat the packaging guidelines as a checklist within a > checklist? Memorise the guidelines and bear them in mind when writing specs ;-) > - MUST: The package must be licensed with an open-source compatible > license and meet other legal requirements as defined in the legal section of > Packaging Guidelines. > > Copying file is GPL2, most cpp/hpp files have explicit GPL2 in them, necessary > to check them all individually? Up to you. If the package has a README or equivalent that says what the license for the package as a whole is, that will usually do. > - MUST: The spec file for the package MUST be legible. If the reviewer is > unable to read the spec file, it will be impossible to perform a review. Fedora > Extras is not the place for entries into the Obfuscated Code Contest ([WWW] > http://www.ioccc.org/). > > I hope it's clean, I'll remove my commented section(s) following advice Comments are OK, particularly if you do something "unusual" in a spec. > - MUST: All other Build dependencies must be listed in BuildRequires. > > hmm, fedora-rmdevelrpms wanted to remove packages that would cause broken > dependencies, I guess I need to setup mock to test this? Yes. A test build in mock revealed that a buildreq of nautilus was needed. > - MUST: If the package contains shared library files located in the > dynamic linker's default paths, that package must call ldconfig in %post and > %postun. > > my .so files stay well clear of /bin and /usr/bin is that enough? The "dynamic linker's default path" are the directories listed in /etc/ld.so.conf, not /bin, /usr/bin etc. > - MUST: A package must own all directories that it creates. If it does not > create a directory that it uses, then it should require a package which does > create that directory. The exception to this are directories listed explicitly > in the Filesystem Hierarchy Standard ([WWW] > http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to assume that > those directories exist. > > is this talking about directories it creates at runtime, or install time, what > about my dirs e.g /usr/share/eiceil ? It's talking about either. You need to own /usr/share/eiceil for instance so that the directory will be removed if the package is removed. > - MUST: Permissions on files must be set properly. Executables should be > set with executable permissions, for example. Every %files section must include > a %defattr(...) line. > > hmmm, I din't make any change from the defattr the template gave me, presume > I've got some work to do here? I don't think so. There don't appear to be any permissions issues that I can see. > - MUST: Each package must consistently use macros, as described in the > macros section of Packaging Guidelines. > > I hope the mix of $XXX and %{xxx} that the template started with is allowed? Yes. Just don't mix variables and macros that do the same thing, e.g. $RPM_BUILD_ROOT and %{buildroot} or $RPM_OPT_FLAGS and %{optflags}. > - MUST: If a package contains library files with a suffix (e.g. > libfoo.so.1.1), then library files that end in .so (without suffix) must go in a > -devel package. > > but softlinks without suffix, pointing to the files with suffix are ok, right? I don't know if /usr/lib/nautilus/extensions-1.0/libeiciel-nautilus.so should be in a -devel package or not; I don't know enough about shared objects to say. > - MUST: Packages must not own files or directories already owned by other > packages. The rule of thumb here is that the first package to be installed > should own the files or directories that other packages may rely upon. This > means, for example, that no package in Fedora Extras should ever share ownership > with any of the files or directories owned by the filesystem or man package. If > you feel that you have a good reason to own a file or directory that another > package owns, then please present that at package review time. > > think i'm clear here I don't think so. You package currently claims everything under %{_libdir}, which includes /usr/lib/nautilus, owned by nautilus. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 21 16:43:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 11:43:56 -0500 Subject: [Bug 182175] Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) In-Reply-To: Message-ID: <200602211643.k1LGhu5L022237@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182175 Jochen at herr-schmitt.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|bugzilla-sink at leemhuis.info |Jochen at herr-schmitt.de OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-21 11:43 EST ------- Bad: - rpmlint of source rpm failed. pmlint libast-0.7-1.src.rpm E: libast tag-not-utf8 %changelog E: libast non-utf8-spec-file libast.spec rpmlint libast-0.7-1.i686.rpm E: libast tag-not-utf8 %changelog rpmlint libast-devel-0.7-1.i686.rpm E: libast-devel tag-not-utf8 %changelog - Local build show following warning: configure: WARNING: *** Imlib2 support has been disabled because Imlib2 *** configure: WARNING: *** was not found or could not be linked. *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 21 16:45:55 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 11:45:55 -0500 Subject: [Bug 181753] Review Request: mm - Shared memory allocation library In-Reply-To: Message-ID: <200602211645.k1LGjtKD022575@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mm - Shared memory allocation library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181753 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-21 11:45 EST ------- When you increase the relase count you should post a link to the new uploaded package. Good: + rpmlint to source rpm is ok. + rpmlint to binary rpms are ok. + mock build worked fine. Bad: - debuginfo package doesn't contains source files for debugging. As far as I can see, you don't use the -g compiler flag. Pless see the following part of my compile run: ./libtool --quiet --mode=compile gcc -c -O2 -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexce ptions -m32 -march=i686 -mtune=pentium4 -fasynchronous-unwind-tables mm_global.c ./libtool --quiet --mode=compile gcc -c -O2 -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexce ptions -m32 -march=i686 -mtune=pentium4 -fasynchronous-unwind-tables mm_alloc.c ./libtool --quiet --mode=compile gcc -c -O2 -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexce -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From tibbs at math.uh.edu Tue Feb 21 16:52:26 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 21 Feb 2006 10:52:26 -0600 Subject: Specifying arch in BuildRequires: In-Reply-To: <1140537283.14289.84.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Tue, 21 Feb 2006 16:54:42 +0100") References: <43FA9B74.30606@redhat.com> <1140535185.14289.71.camel@mccallum.corsepiu.local> <1140537283.14289.84.camel@mccallum.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> --with-newlib or --enable-multilib? Neither. Honestly, until today I didn't know those flags existed. The failed build is at http://www.math.uh.edu/~tibbs/rpms/gpc/x86_64-failed-build.log However, the clues I found in the ghdl package (probably just --disable-multilib) were enough to get things building. My thanks to Paul. I'll respin the package and update bugzilla. - J< From gauret at free.fr Tue Feb 21 17:02:02 2006 From: gauret at free.fr (Aurelien Bompard) Date: Tue, 21 Feb 2006 18:02:02 +0100 Subject: Buildsys needs a kick Message-ID: $ make build /usr/bin/plague-client build apachetop apachetop-0_12_5-3_fc5 devel Package apachetop enqueued. (However, no Job ID was provided in the time required) Please kick the buildsys. Aur?lien -- http://aurelien.bompard.org ~~~~ 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 fedora at leemhuis.info Tue Feb 21 17:07:49 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 21 Feb 2006 18:07:49 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1140205892.2904.30.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> Message-ID: <1140541669.2144.30.camel@localhost.localdomain> Hi All! Background info: Announcement of the mass-rebuild: https://www.redhat.com/archives/fedora-maintainers/2006-February/msg00039.html The script that helped me to generate this lists: https://www.redhat.com/archives/fedora-maintainers/2006-February/msg00053.html This time also: Replies to fedora-extras-list please, tia! > Am Freitag, den 17.02.2006, 20:51 +0100 schrieb Thorsten Leemhuis: > >Am Montag, den 13.02.2006, 18:22 +0100 schrieb Thorsten Leemhuis: > > The last rawhide mass-rebuild is mostly done now so it's time for us to > > also rebuild **all packages** in the Fedora Extras development tree > > before it becomes Fedora Extras 5 (FE) when Fedora Core 5 is > > branched/released. > > Guys, please keep the buildsys busy. There are a lot of packages that > are still not rebuild afaics. That sentence still holds true ;-) > The following 565 arch specific packages still need a rebuild [...] We are down to 453 arch packages (271 noarch) packages now (1242 were build). See below for a list of arch packages that are not yet rebuild. Changes: I set the trigger date a bit back to the time of the rawhide-report on the day before the rebuild was announced. $ date --date='2006-02-13 02:48:00 -0500 ' +%s 1139816880 All arch packages before that point in time should be rebuild. I also looked up those packagers that have not yet rebuild a single package since the mass rebuild was announced (guys, please start): ---- aaron.bennett_AT_olin.edu ad+rh-bugzilla_AT_uni-x.org aportal_AT_univ-montp2.fr bojan_AT_rexursive.com ch.nolte_AT_fh-wolfenbuettel.de chris_AT_chrisgrau.com chrisw_AT_redhat.com colin_AT_fedoraproject.org danken_AT_cs.technion.ac.il davidhart_AT_tqmcube.com davidz_AT_redhat.com denis_AT_poolshark.org dwmw2_AT_redhat.com endur_AT_bennewitz.com fredrik_AT_dolda2000.com gauret_AT_free.fr grenier_AT_cgsecurity.org hamzy_AT_us.ibm.com jcarpenter_AT_condell.org jdennis_AT_redhat.com jeff_AT_ultimateevil.org jeff.gilchrist_AT_gmail.com jnovy_AT_redhat.com joost_AT_cnoc.nl jylitalo_AT_iki.fi llch_AT_redhat.com luya256_AT_yahoo.com matt_AT_truch.net mccann0011_AT_hotmail.com meme_AT_daughtersoftiresias.org michel.salim_AT_gmail.com mihai_AT_xcyb.org mitr_AT_redhat.com nhorman_AT_redhat.com nos_AT_utelsystems.com oliver.andrich_AT_gmail.com otaylor_AT_redhat.com paul_AT_all-the-johnsons.co.uk paul_AT_xtdnet.nl pawsa_AT_theochem.kth.se petersen_AT_redhat.com pvrabec_AT_redhat.com redhat-bugzilla_AT_camperquake.de roland_AT_redhat.com rvokal_AT_redhat.com ryo-dairiki_AT_users.sourceforge.net skvidal_AT_phy.duke.edu tagoh_AT_redhat.com tcallawa_AT_redhat.com thomas_AT_apestaart.org toniw_AT_iki.fi tripwire-devel_AT_genesis-x.nildram.co.uk ---- Below the complete list of arch packages not yet rebuild. If you name and/or package is in the list *and* there is a *good reason* for it then it's okay -- no need to send detailed mails why it is not rebuild yet. But we'll probably start tracking things closer by the end of the week -- then I'll ask for details ;-) aaron.bennett_AT_olin.edu ifplugd ad+rh-bugzilla_AT_uni-x.org pam_abl adrian_AT_lisas.de cvsup adrian_AT_lisas.de kover adrian_AT_lisas.de libcdio adrian_AT_lisas.de most adrian_AT_lisas.de nexuiz adrian_AT_lisas.de ninja adrian_AT_lisas.de sopwith adrian_AT_lisas.de source-highlight adrian_AT_lisas.de tin adrian_AT_lisas.de uudeview adrian_AT_lisas.de vnstat adrian_AT_lisas.de xdesktopwaves adrian_AT_lisas.de xlockmore adrian_AT_lisas.de xmlindent a.kurtz_AT_hardsun.net libdaemon andreas_AT_bawue.net barcode andreas_AT_bawue.net commoncpp2 andreas_AT_bawue.net ddrescue andreas_AT_bawue.net mod_suphp andreas_AT_bawue.net perl-Crypt-Blowfish andreas_AT_bawue.net scmxx andreas.bierfert_AT_lowlatency.de fbdesk andreas.bierfert_AT_lowlatency.de fluxbox andreas.bierfert_AT_lowlatency.de orange andreas.bierfert_AT_lowlatency.de synce andreas.bierfert_AT_lowlatency.de synce-gnomevfs andreas.bierfert_AT_lowlatency.de synce-software-manager andreas.bierfert_AT_lowlatency.de synce-trayicon andreas.bierfert_AT_lowlatency.de wine anvil_AT_livna.org aalib anvil_AT_livna.org bin2iso anvil_AT_livna.org imlib2 anvil_AT_livna.org irssi anvil_AT_livna.org libcddb anvil_AT_livna.org libebml anvil_AT_livna.org libmatroska anvil_AT_livna.org libsamplerate anvil_AT_livna.org libsndfile anvil_AT_livna.org libtar anvil_AT_livna.org lzo aportal_AT_univ-montp2.fr gpsim aportal_AT_univ-montp2.fr gputils aportal_AT_univ-montp2.fr gtk+extra aportal_AT_univ-montp2.fr utrac bdpepple_AT_ameritech.net gnomebaker bdpepple_AT_ameritech.net tagtool bojan_AT_rexursive.com libapreq2 bugs.michael_AT_gmx.net abicheck bugs.michael_AT_gmx.net aide bugs.michael_AT_gmx.net bchunk bugs.michael_AT_gmx.net chkrootkit bugs.michael_AT_gmx.net mhash ch.nolte_AT_fh-wolfenbuettel.de kbibtex chris_AT_chrisgrau.com frotz chris_AT_chrisgrau.com ifm chris_AT_chrisgrau.com perl-Time-Piece chrisw_AT_redhat.com git-core colin_AT_fedoraproject.org adns colin_AT_fedoraproject.org gaim-guifications colin_AT_fedoraproject.org MagicPoint colin_AT_fedoraproject.org python-adns danken_AT_cs.technion.ac.il bidiv danken_AT_cs.technion.ac.il hspell danken_AT_cs.technion.ac.il taarich davidhart_AT_tqmcube.com leafnode davidz_AT_redhat.com NetworkManager-vpnc denis_AT_poolshark.org galeon denis_AT_poolshark.org gconfmm26 denis_AT_poolshark.org glibmm24 denis_AT_poolshark.org gnome-vfsmm26 denis_AT_poolshark.org gtkmm24 denis_AT_poolshark.org inkscape denis_AT_poolshark.org libglademm24 denis_AT_poolshark.org libgnomecanvasmm26 denis_AT_poolshark.org libgnomemm26 denis_AT_poolshark.org libgnomeuimm26 denis_AT_poolshark.org libsigc++ denis_AT_poolshark.org libsigc++20 dwmw2_AT_redhat.com exim dwmw2_AT_redhat.com hfsplusutils endur_AT_bennewitz.com streamtuner enrico.scholz_AT_informatik.tu-chemnitz.de dhcp-forwarder enrico.scholz_AT_informatik.tu-chemnitz.de dietlibc enrico.scholz_AT_informatik.tu-chemnitz.de ip-sentinel enrico.scholz_AT_informatik.tu-chemnitz.de libtasn1 enrico.scholz_AT_informatik.tu-chemnitz.de util-vserver extras-orphan_AT_fedoraproject.org abe extras-orphan_AT_fedoraproject.org arc extras-orphan_AT_fedoraproject.org at-poke extras-orphan_AT_fedoraproject.org camstream extras-orphan_AT_fedoraproject.org cgoban extras-orphan_AT_fedoraproject.org cksfv extras-orphan_AT_fedoraproject.org duplicity extras-orphan_AT_fedoraproject.org freedroidrpg extras-orphan_AT_fedoraproject.org gnofract4d extras-orphan_AT_fedoraproject.org gnome-telnet extras-orphan_AT_fedoraproject.org gnugo extras-orphan_AT_fedoraproject.org gurlchecker extras-orphan_AT_fedoraproject.org libzvt extras-orphan_AT_fedoraproject.org lua extras-orphan_AT_fedoraproject.org manedit extras-orphan_AT_fedoraproject.org mknbi extras-orphan_AT_fedoraproject.org netdiag extras-orphan_AT_fedoraproject.org nget extras-orphan_AT_fedoraproject.org ots extras-orphan_AT_fedoraproject.org parchive extras-orphan_AT_fedoraproject.org prozilla extras-orphan_AT_fedoraproject.org putty extras-orphan_AT_fedoraproject.org sirius extras-orphan_AT_fedoraproject.org tdl extras-orphan_AT_fedoraproject.org tetex-lgrind extras-orphan_AT_fedoraproject.org tla extras-orphan_AT_fedoraproject.org wbxml2 extras-orphan_AT_fedoraproject.org xmms-cdread extras-orphan_AT_fedoraproject.org xtide fredrik_AT_dolda2000.com icmpdn gajownik_AT_gmail.com athcool gauret_AT_free.fr amarok gauret_AT_free.fr amaya gauret_AT_free.fr apachetop gauret_AT_free.fr basket gauret_AT_free.fr colorscheme gauret_AT_free.fr elmo gauret_AT_free.fr gmpc gauret_AT_free.fr grisbi gauret_AT_free.fr gwenview gauret_AT_free.fr iftop gauret_AT_free.fr libkexif gauret_AT_free.fr libkipi gauret_AT_free.fr libvisual gauret_AT_free.fr mpc gauret_AT_free.fr pdftohtml gauret_AT_free.fr perl-Jcode gauret_AT_free.fr perl-Unicode-Map gauret_AT_free.fr perl-Unicode-Map8 gauret_AT_free.fr perl-Unicode-String gauret_AT_free.fr psi gauret_AT_free.fr pure-ftpd gauret_AT_free.fr qca gauret_AT_free.fr qca-tls gauret_AT_free.fr showimg gauret_AT_free.fr taglib gauret_AT_free.fr ulogd gauret_AT_free.fr unrtf gauret_AT_free.fr wv gauret_AT_free.fr xbindkeys gauret_AT_free.fr xlhtml gauret_AT_free.fr zope gemi_AT_bluewin.ch audacity gemi_AT_bluewin.ch bigloo gemi_AT_bluewin.ch erlang gemi_AT_bluewin.ch lablgl gemi_AT_bluewin.ch lablgtk gemi_AT_bluewin.ch TeXmacs gemi_AT_bluewin.ch unison ghenry_AT_suretecsystems.com john ghenry_AT_suretecsystems.com librsync ghenry_AT_suretecsystems.com rdiff-backup green_AT_redhat.com itext green_AT_redhat.com jakarta-commons-cli green_AT_redhat.com jogl green_AT_redhat.com kawa green_AT_redhat.com rssowl grenier_AT_cgsecurity.org testdisk hamzy_AT_us.ibm.com sblim-cmpi-base hamzy_AT_us.ibm.com sblim-cmpi-devel hamzy_AT_us.ibm.com sblim-wbemcli i_AT_stingr.net pyflowtools ivazquez_AT_ivazquez.net lock-keys-applet ivazquez_AT_ivazquez.net sqlite2 jamatos_AT_fc.up.pt R-mAr jcarpenter_AT_condell.org ks3switch jcarpenter_AT_condell.org lrmi jcarpenter_AT_condell.org s3switch jcarpenter_AT_condell.org tpb jcarpenter_AT_condell.org xosd jdennis_AT_redhat.com cyrus-imapd jeff_AT_ultimateevil.org up-imapproxy jeff_AT_ultimateevil.org zile jeff.gilchrist_AT_gmail.com pbzip2 jfontain_AT_free.fr blt jfontain_AT_free.fr tktable jnovy_AT_redhat.com allegro jnovy_AT_redhat.com cproto jnovy_AT_redhat.com nedit joost_AT_cnoc.nl fpc jpo_AT_di.uminho.pt libol jpo_AT_di.uminho.pt perl-Array-Compare jpo_AT_di.uminho.pt perl-Cache-Cache jpo_AT_di.uminho.pt perl-Compress-Bzip2 jpo_AT_di.uminho.pt perl-DBD-SQLite jpo_AT_di.uminho.pt perl-File-Tail jpo_AT_di.uminho.pt perl-GDGraph jpo_AT_di.uminho.pt perl-Gtk2 jpo_AT_di.uminho.pt perl-Image-Info jpo_AT_di.uminho.pt perl-IPC-Shareable jpo_AT_di.uminho.pt perl-Net-SSLeay jpo_AT_di.uminho.pt perl-SQL-Statement jpo_AT_di.uminho.pt perl-Test-Manifest jpo_AT_di.uminho.pt perl-Test-Memory-Cycle jpo_AT_di.uminho.pt perl-Text-CSV_XS jpo_AT_di.uminho.pt perl-Text-WikiFormat jspaleta_AT_gmail.com istanbul jylitalo_AT_iki.fi python-imaging jylitalo_AT_iki.fi xplanet lemenkov_AT_newmail.ru chmlib lemenkov_AT_newmail.ru fuse-encfs lemenkov_AT_newmail.ru rlog lemenkov_AT_newmail.ru wavpack llch_AT_redhat.com libtabe llch_AT_redhat.com xcin lmacken_AT_redhat.com valknut luya256_AT_yahoo.com gdesklets matt_AT_truch.net cfitsio matt_AT_truch.net hpic mattdm_AT_mattdm.org wxPythonGTK2 matthias_AT_rpmforge.net advancecomp matthias_AT_rpmforge.net bbkeys matthias_AT_rpmforge.net blackbox matthias_AT_rpmforge.net boa matthias_AT_rpmforge.net camE matthias_AT_rpmforge.net csmash matthias_AT_rpmforge.net d4x matthias_AT_rpmforge.net diradmin matthias_AT_rpmforge.net djvulibre matthias_AT_rpmforge.net easytag matthias_AT_rpmforge.net fillets-ng matthias_AT_rpmforge.net gcombust matthias_AT_rpmforge.net gentoo matthias_AT_rpmforge.net giblib matthias_AT_rpmforge.net gkrellm-aclock matthias_AT_rpmforge.net gkrellm-freq matthias_AT_rpmforge.net Gtk-Perl matthias_AT_rpmforge.net gtktalog matthias_AT_rpmforge.net gtweakui matthias_AT_rpmforge.net hackedbox matthias_AT_rpmforge.net hercules matthias_AT_rpmforge.net i8kutils matthias_AT_rpmforge.net js matthias_AT_rpmforge.net kannel matthias_AT_rpmforge.net libcaca matthias_AT_rpmforge.net liboil matthias_AT_rpmforge.net lighttpd matthias_AT_rpmforge.net linux_logo matthias_AT_rpmforge.net lmarbles matthias_AT_rpmforge.net metakit matthias_AT_rpmforge.net ncftp matthias_AT_rpmforge.net oidentd matthias_AT_rpmforge.net p7zip matthias_AT_rpmforge.net php-eaccelerator matthias_AT_rpmforge.net php-pecl-mailparse matthias_AT_rpmforge.net php-pecl-pdo matthias_AT_rpmforge.net php-pecl-pdo-sqlite matthias_AT_rpmforge.net plib matthias_AT_rpmforge.net plib16 matthias_AT_rpmforge.net portaudio matthias_AT_rpmforge.net powermanga matthias_AT_rpmforge.net proftpd matthias_AT_rpmforge.net rrdtool matthias_AT_rpmforge.net SDL_gfx matthias_AT_rpmforge.net starfighter matthias_AT_rpmforge.net synergy matthias_AT_rpmforge.net thttpd matthias_AT_rpmforge.net torcs matthias_AT_rpmforge.net ucarp matthias_AT_rpmforge.net udftools matthias_AT_rpmforge.net viruskiller matthias_AT_rpmforge.net xvattr matthias_AT_rpmforge.net yasm matthias_AT_rpmforge.net zziplib mccann0011_AT_hotmail.com geos mccann0011_AT_hotmail.com proj meme_AT_daughtersoftiresias.org nethack-vultures mfleming+rpm_AT_enlartenment.com mlmmj mfleming+rpm_AT_enlartenment.com mod_security michel.salim_AT_gmail.com gai michel.salim_AT_gmail.com gai-pal michel.salim_AT_gmail.com grhino michel.salim_AT_gmail.com quarry mihai_AT_xcyb.org htb-util mitr_AT_redhat.com foobillard mitr_AT_redhat.com python-4Suite-XML nhorman_AT_redhat.com iozone nos_AT_utelsystems.com dillo nos_AT_utelsystems.com gktools nos_AT_utelsystems.com gtkterm nos_AT_utelsystems.com neverball nos_AT_utelsystems.com soundtracker nos_AT_utelsystems.com whowatch oliver.andrich_AT_gmail.com ruby-mysql oliver_AT_linux-kernel.at fish oliver_AT_linux-kernel.at libdnet orion_AT_cora.nwra.com gdl orion_AT_cora.nwra.com hdf5 orion_AT_cora.nwra.com kompose orion_AT_cora.nwra.com ncarg orion_AT_cora.nwra.com perl-Cflow orion_AT_cora.nwra.com perl-Net-IP-CMatch orion_AT_cora.nwra.com perl-Net-Patricia orion_AT_cora.nwra.com plplot orion_AT_cora.nwra.com python-basemap orion_AT_cora.nwra.com python-matplotlib otaylor_AT_redhat.com libuninameslist paul_AT_all-the-johnsons.co.uk anjuta paul_AT_all-the-johnsons.co.uk lib765 paul_AT_all-the-johnsons.co.uk libdsk paul_AT_all-the-johnsons.co.uk libspectrum paul_AT_xtdnet.nl fetchlog paul_AT_xtdnet.nl gaim-otr paul_AT_xtdnet.nl l2tpd paul_AT_xtdnet.nl ldns paul_AT_xtdnet.nl libotr paul_AT_xtdnet.nl nsd pawsa_AT_theochem.kth.se balsa pawsa_AT_theochem.kth.se libesmtp pertusus_AT_free.fr BibTool pertusus_AT_free.fr libdap pertusus_AT_free.fr libnc-dap pertusus_AT_free.fr libsx petersen_AT_redhat.com darcs petersen_AT_redhat.com FreeWnn petersen_AT_redhat.com ghc petersen_AT_redhat.com haddock petersen_AT_redhat.com scim-fcitx pvrabec_AT_redhat.com licq rc040203_AT_freenet.de lib3ds rc040203_AT_freenet.de SIMVoleon rdieter_AT_math.unl.edu akode rdieter_AT_math.unl.edu apollon rdieter_AT_math.unl.edu dxpc rdieter_AT_math.unl.edu factory rdieter_AT_math.unl.edu gc rdieter_AT_math.unl.edu geomview rdieter_AT_math.unl.edu gift rdieter_AT_math.unl.edu gift-openft rdieter_AT_math.unl.edu gpa rdieter_AT_math.unl.edu gpgme rdieter_AT_math.unl.edu gsview rdieter_AT_math.unl.edu gtk-qt-engine rdieter_AT_math.unl.edu jasper rdieter_AT_math.unl.edu kasablanca rdieter_AT_math.unl.edu kdocker rdieter_AT_math.unl.edu kickpim rdieter_AT_math.unl.edu kile rdieter_AT_math.unl.edu kimdaba rdieter_AT_math.unl.edu kiosktool rdieter_AT_math.unl.edu kipi-plugins rdieter_AT_math.unl.edu kmymoney2 rdieter_AT_math.unl.edu kxdocker rdieter_AT_math.unl.edu libassuan rdieter_AT_math.unl.edu libfac rdieter_AT_math.unl.edu libksba rdieter_AT_math.unl.edu libsigsegv rdieter_AT_math.unl.edu libtunepimp rdieter_AT_math.unl.edu lyx rdieter_AT_math.unl.edu Macaulay2 rdieter_AT_math.unl.edu maxima rdieter_AT_math.unl.edu openslp rdieter_AT_math.unl.edu pinentry rdieter_AT_math.unl.edu sbcl rdieter_AT_math.unl.edu tidy rdieter_AT_math.unl.edu uw-imap rdieter_AT_math.unl.edu xforms redhat_AT_flyn.org pam_mount redhat-bugzilla_AT_camperquake.de bmp redhat-bugzilla_AT_camperquake.de bmp-flac2 redhat-bugzilla_AT_camperquake.de fwbuilder redhat-bugzilla_AT_camperquake.de libfwbuilder roland_AT_redhat.com monotone rolandd_AT_cisco.com libmthca rvokal_AT_redhat.com nuttcp ryo-dairiki_AT_users.sourceforge.net scim-input-pad ryo-dairiki_AT_users.sourceforge.net scim-skk ryo-dairiki_AT_users.sourceforge.net scim-tomoe ryo-dairiki_AT_users.sourceforge.net tomoe shahms_AT_shahms.com python-psycopg skvidal_AT_phy.duke.edu mock skvidal_AT_phy.duke.edu seahorse steve_AT_silug.org perl-DateTime steve_AT_silug.org tuxpaint tagoh_AT_redhat.com Canna tagoh_AT_redhat.com kakasi tagoh_AT_redhat.com kinput2 tagoh_AT_redhat.com mew tagoh_AT_redhat.com namazu tagoh_AT_redhat.com paps tagoh_AT_redhat.com perl-Text-Kakasi tagoh_AT_redhat.com uim tagoh_AT_redhat.com w3m-el tcallawa_AT_redhat.com alsamixergui tcallawa_AT_redhat.com blacs tcallawa_AT_redhat.com c-ares tcallawa_AT_redhat.com check tcallawa_AT_redhat.com comical tcallawa_AT_redhat.com compat-wxGTK tcallawa_AT_redhat.com gambas tcallawa_AT_redhat.com gxemul tcallawa_AT_redhat.com jam tcallawa_AT_redhat.com lapack tcallawa_AT_redhat.com libgdamm tcallawa_AT_redhat.com libmcrypt tcallawa_AT_redhat.com librx tcallawa_AT_redhat.com lincity-ng tcallawa_AT_redhat.com logjam tcallawa_AT_redhat.com mcrypt tcallawa_AT_redhat.com mfstools tcallawa_AT_redhat.com netgo tcallawa_AT_redhat.com perl-Clone tcallawa_AT_redhat.com perl-DBD-SQLite2 tcallawa_AT_redhat.com perl-Template-Toolkit tcallawa_AT_redhat.com perl-version tcallawa_AT_redhat.com physfs tcallawa_AT_redhat.com QuantLib tcallawa_AT_redhat.com R tcallawa_AT_redhat.com rekall tcallawa_AT_redhat.com R-gnomeGUI tcallawa_AT_redhat.com rocksndiamonds tcallawa_AT_redhat.com rootsh tcallawa_AT_redhat.com scalapack tcallawa_AT_redhat.com udunits tcallawa_AT_redhat.com wlassistant tcallawa_AT_redhat.com xbase tcallawa_AT_redhat.com xbsql tcallawa_AT_redhat.com xkeycaps tcallawa_AT_redhat.com xsupplicant thomas_AT_apestaart.org directfb thomas_AT_apestaart.org flumotion thomas_AT_apestaart.org gstreamer08-python thomas_AT_apestaart.org gstreamer-python thomas_AT_apestaart.org Hermes thomas_AT_apestaart.org ladspa thomas_AT_apestaart.org libannodex thomas_AT_apestaart.org libcmml thomas_AT_apestaart.org liboggz thomas_AT_apestaart.org libshout thomas_AT_apestaart.org mach thomas_AT_apestaart.org mod_annodex thomas_AT_apestaart.org python-twisted toniw_AT_iki.fi silky tripwire-devel_AT_genesis-x.nildram.co.uk tripwire ville.skytta_AT_iki.fi dvb-apps ville.skytta_AT_iki.fi hddtemp ville.skytta_AT_iki.fi xemacs wart_AT_kobold.org tcldom wart_AT_kobold.org tclhttpd wart_AT_kobold.org tclxml wart_AT_kobold.org xpilot-ng wtogami_AT_redhat.com bonnie++ wtogami_AT_redhat.com lvcool wtogami_AT_redhat.com perl-Digest-Nilsimsa wtogami_AT_redhat.com perl-Razor-Agent -- Thorsten Leemhuis From bugzilla at redhat.com Tue Feb 21 17:33:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 12:33:35 -0500 Subject: [Bug 182175] Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) In-Reply-To: Message-ID: <200602211733.k1LHXZoB030729@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182175 Jochen at herr-schmitt.de changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |182173 nThis| | ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-21 12:33 EST ------- Further Bads: - BuildRoot should be %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) - The BuildRoot must be cleaned at the beginning of %install ? Encoding should be UTF-8 - Test of /sbin/ldconfig in %post and %pustun is unnecessary. - Static libs in devel package. - Missing text of the license in %doc. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 21 17:33:57 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 12:33:57 -0500 Subject: [Bug 181997] Review Request: gpc - The GNU Pascal compiler In-Reply-To: Message-ID: <200602211733.k1LHXvFk030856@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gpc - The GNU Pascal compiler https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181997 ------- Additional Comments From tibbs at math.uh.edu 2006-02-21 12:33 EST ------- OK, I've fixed the x86_64 build by disabling multilib. Builds succeed in mock (development, x86_64 and i386). rpmlint output is unchanged. Updated files: spec: http://www.math.uh.edu/~tibbs/rpms/gpc/gpc.spec srpm: http://www.math.uh.edu/~tibbs/rpms/gpc/gpc-3.4.5_20060215-5.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From skvidal at linux.duke.edu Tue Feb 21 18:13:03 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 21 Feb 2006 13:13:03 -0500 Subject: Buildsys needs a kick In-Reply-To: References: Message-ID: <1140545583.31787.17.camel@cutter> On Tue, 2006-02-21 at 18:02 +0100, Aurelien Bompard wrote: > $ make build > /usr/bin/plague-client build apachetop apachetop-0_12_5-3_fc5 devel > Package apachetop enqueued. (However, no Job ID was provided in the time > required) > > Please kick the buildsys. > I kicked it as per Thorsten's request on irc at about 12:58pm (EST) -sv From buildsys at fedoraproject.org Tue Feb 21 18:40:39 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 21 Feb 2006 13:40:39 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060221184039.A72DE8011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 6 dap-netcdf_handler-3.5.2-2.fc3 digikamimageplugins-0.8.1-1.fc3 gtkwave-1.3.84-1.fc3 rbldnsd-0.996-1.fc3 scrub-1.7-1.fc3 wine-0.9.8-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Tue Feb 21 18:35:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 13:35:33 -0500 Subject: [Bug 182305] New: Review Request: pyspi - Python bindings for AT-SPI Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182305 Summary: Review Request: pyspi - Python bindings for AT-SPI Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: zcerza at redhat.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://people.redhat.com/zcerza/dogtail/releases/FE/pyspi.spec SRPM Name or Url: http://people.redhat.com/zcerza/dogtail/releases/FE/pyspi-0.5.4-1.src.rpm Description: Python bindings for AT-SPI. Allows Python programs to act as Assistive Technology Service Providers - i.e. screen readers. pyspi was created for use by dogtail, a GUI test tool and automation framework. This (and dogtail) are my first packages, and I'm seeking a sponsor. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 21 18:35:54 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 13:35:54 -0500 Subject: [Bug 182306] New: Review Request: dogtail - GUI test tool and automation framework Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182306 Summary: Review Request: dogtail - GUI test tool and automation framework Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: zcerza at redhat.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://people.redhat.com/zcerza/dogtail/releases/FE/dogtail.spec SRPM Name or Url: http://people.redhat.com/zcerza/dogtail/releases/FE/dogtail-0.5.0-2.src.rpm Description: GUI test tool and automation framework that uses assistive technologies to communicate with desktop applications. This (and pyspi) are my first packages, and I'm seeking a sponsor. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From buildsys at fedoraproject.org Tue Feb 21 18:41:32 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 21 Feb 2006 13:41:32 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060221184132.CB3598011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 38 SIBsim4-0.10-1.fc5 anjuta-1.2.4-2.fc5 bmp-0.9.7.1-4.fc5 cfv-1.18.1-1.fc5 dap-freeform_handler-3.5.0-1.fc5 dhcp-forwarder-0.7-8.fc5 dietlibc-0.29-6.fc5 foobillard-3.0a-4 gaim-otr-3.0.0-2.fc5 gtkwave-1.3.84-1.fc5 ip-sentinel-0.12-6.fc5 ldns-1.0.1-1.fc5 libotr-3.0.0-1.fc5 mod_geoip-1.1.7-2.fc5 nagios-2.0-1.fc5 ncarg-4.4.1-3.fc5 nsd-2.3.3-7.fc5 perl-Array-Compare-1.13-2.fc5 perl-Cache-Cache-1.04-4.fc5 perl-Compress-Bzip2-2.09-3.fc5 perl-File-Tail-0.99.3-4.fc5 perl-GD-2.31-1.fc5 perl-GDGraph-1.4307-1.fc5 perl-Gtk2-1.104-1.fc5 perl-IPC-Shareable-0.60-2.fc5 perl-Image-Info-1.17-1.fc5 perl-Image-Info-1.17-2.fc5 perl-SQL-Statement-1.14-2.fc5 perl-Test-Manifest-1.14-4.fc5 perl-Test-Memory-Cycle-1.02-2.fc5 perl-Text-WikiFormat-0.77-2.fc5 python-4Suite-XML-1.0-0.4.b3 rbldnsd-0.996-1.fc5 rxvt-unicode-7.7-1.fc5 scrub-1.7-1.fc5 wine-0.9.8-1.fc5 xmlindent-0.2.17-6.fc5 ytalk-3.3.0-3.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From gauret at free.fr Tue Feb 21 18:45:33 2006 From: gauret at free.fr (Aurelien Bompard) Date: Tue, 21 Feb 2006 19:45:33 +0100 Subject: Buildsys needs a kick References: <1140545583.31787.17.camel@cutter> Message-ID: seth vidal wrote: > I kicked it as per Thorsten's request on irc at about 12:58pm (EST) Thanks, working now. Aur?lien -- http://aurelien.bompard.org ~~~~ 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 ville.skytta at iki.fi Tue Feb 21 19:34:53 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 21 Feb 2006 21:34:53 +0200 Subject: Crontab and init scripts In-Reply-To: <1140529297.28732.53.camel@cutter> References: <3237e4410602200046r3d9f871h2d4ba57c4556a80e@mail.gmail.com> <20060220164554.GB17008@devserv.devel.redhat.com> <3237e4410602202348j6fc83e34o62e1dc5ee2c21cfd@mail.gmail.com> <3237e4410602210535o3fc86ea8v510220749ab84b96@mail.gmail.com> <1140529297.28732.53.camel@cutter> Message-ID: <1140550493.3191.7.camel@bobcat.mine.nu> On Tue, 2006-02-21 at 08:41 -0500, seth vidal wrote: > umm - when did anyone say yum put a pid file in /var/run? It sure does, but maybe not in the context you're discussing here. $ sudo yum update Loading "installonlyn" plugin Existing lock /var/run/yum.pid: another copy is running. Aborting. From skvidal at linux.duke.edu Tue Feb 21 19:47:26 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 21 Feb 2006 14:47:26 -0500 Subject: Crontab and init scripts In-Reply-To: <1140550493.3191.7.camel@bobcat.mine.nu> References: <3237e4410602200046r3d9f871h2d4ba57c4556a80e@mail.gmail.com> <20060220164554.GB17008@devserv.devel.redhat.com> <3237e4410602202348j6fc83e34o62e1dc5ee2c21cfd@mail.gmail.com> <3237e4410602210535o3fc86ea8v510220749ab84b96@mail.gmail.com> <1140529297.28732.53.camel@cutter> <1140550493.3191.7.camel@bobcat.mine.nu> Message-ID: <1140551246.31787.40.camel@cutter> On Tue, 2006-02-21 at 21:34 +0200, Ville Skytt? wrote: > On Tue, 2006-02-21 at 08:41 -0500, seth vidal wrote: > > > umm - when did anyone say yum put a pid file in /var/run? > > It sure does, but maybe not in the context you're discussing here. > > $ sudo yum update > Loading "installonlyn" plugin > Existing lock /var/run/yum.pid: another copy is running. Aborting. no - but that's when yum is actually running - not when the cron job is enabled. therefore the use of the yum.pid file in /var/run that you cite is a correct use under the FHS. -sv From paul at all-the-johnsons.co.uk Tue Feb 21 20:00:34 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 21 Feb 2006 20:00:34 +0000 Subject: Abandonned packages - bonobo and gnome-vfs Message-ID: <1140552035.31940.2.camel@T7.Linux> Hi, I'm currently trying to build gnome-build (required for anjuta-2) and it relies on gnome-vfs and bonobo (the spec file generated when I hand compile the tarball has then as BuildRequires). Both of these are abandoned from FC4 and waiting to go into FE. Is the procedure for taking them on the same as any other package or is there a straight replacement I can use which is part of the main distro rather than compiling these up? TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Tue Feb 21 20:05:12 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 21 Feb 2006 15:05:12 -0500 Subject: Abandonned packages - bonobo and gnome-vfs In-Reply-To: <1140552035.31940.2.camel@T7.Linux> References: <1140552035.31940.2.camel@T7.Linux> Message-ID: <20060221200512.GD32666@devserv.devel.redhat.com> Paul (paul at all-the-johnsons.co.uk) said: > I'm currently trying to build gnome-build (required for anjuta-2) and it > relies on gnome-vfs and bonobo (the spec file generated when I hand > compile the tarball has then as BuildRequires). Surely it uses libbonobo and gnome-vfs2? Bill From paul at all-the-johnsons.co.uk Tue Feb 21 20:10:56 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Tue, 21 Feb 2006 20:10:56 +0000 Subject: Abandonned packages - bonobo and gnome-vfs In-Reply-To: <20060221200512.GD32666@devserv.devel.redhat.com> References: <1140552035.31940.2.camel@T7.Linux> <20060221200512.GD32666@devserv.devel.redhat.com> Message-ID: <1140552656.31940.4.camel@T7.Linux> Hi, > > > I'm currently trying to build gnome-build (required for anjuta-2) and it > > relies on gnome-vfs and bonobo (the spec file generated when I hand > > compile the tarball has then as BuildRequires). > > Surely it uses libbonobo and gnome-vfs2? Nope - it specifies bonobo and gnome-vfs. I've removed the requirements and it compiled fine, so I guess it's not an issue. And don't call be Shirley! (sorry, couldn't resist!) TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show From bugs.michael at gmx.net Tue Feb 21 20:13:22 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 21 Feb 2006 21:13:22 +0100 Subject: Build failure for amarok In-Reply-To: References: Message-ID: <20060221211322.653d1d3d.bugs.michael@gmx.net> On Tue, 21 Feb 2006 12:56:51 +0100, Aurelien Bompard wrote: > I have a strange build failure for amarok 1.4beta1 (first one to use > gstreamer 0.10) : > ----- > make[6]: *** No rule to make target > `../../../../amarok/src/engine/gst/config/libgstconfig.la', needed by > `libamarok_gst10engine_plugin.la'. Stop. > ----- > There is nothing before that which could make me think of a missing file or > so. This error only happens in mock, not on a local build. > > I am not very familiar with libtool, could someone help me ? > (I have to read this autotools manual some day) > > http://buildsys.fedoraproject.org/logs/fedora-development-extras/5006-amarok-1.4-0.3.beta1.fc5/x86_64/build.log > Did you run your test-builds with "--define fedora 5"? Anyway, the build log looks like it wants libgstconfig.la from within ./amarok/src/engine/gst/config instead of ./amarok/src/engine/gst10/config which "make" did not enter. It built files in "gst" not "gst10". Hence ../../../../amarok/src/engine/gst/config/libgstconfig.la is not available. From notting at redhat.com Tue Feb 21 20:14:53 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 21 Feb 2006 15:14:53 -0500 Subject: Abandonned packages - bonobo and gnome-vfs In-Reply-To: <1140552656.31940.4.camel@T7.Linux> References: <1140552035.31940.2.camel@T7.Linux> <20060221200512.GD32666@devserv.devel.redhat.com> <1140552656.31940.4.camel@T7.Linux> Message-ID: <20060221201453.GF32666@devserv.devel.redhat.com> Paul F. Johnson (paul at all-the-johnsons.co.uk) said: > > > I'm currently trying to build gnome-build (required for anjuta-2) and it > > > relies on gnome-vfs and bonobo (the spec file generated when I hand > > > compile the tarball has then as BuildRequires). > > > > Surely it uses libbonobo and gnome-vfs2? > > Nope - it specifies bonobo and gnome-vfs. The configure script checks for: checking for gtk+-2.0 >= 2.3.0 libgnome-2.0 >= 2.3.3 libgnomeui-2.0 >= 2.3.3 libbonoboui-2.0 >= 2.3.3 libxml-2.0 >= 2.5.8 gnome-vfs-2.0 >= 2.3.5 gdl-1.0 >= 0.4.0 gnome-vfs-module-2.0 >= 2.3.5... i.e., the gnome2 variants. (gnome-vfs and bonobo are GNOME 1.) Bill From bugzilla at redhat.com Tue Feb 21 20:25:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 15:25:09 -0500 Subject: [Bug 182319] New: Review Request: anjuta-gdl Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182319 Summary: Review Request: anjuta-gdl Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: paul at all-the-johnsons.co.uk QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.smmp.salford.ac.uk/packages/anjuta-gdl.spec SRPM Name or Url: http://www.smmp.salford.ac.uk/packages/anjuta-gdl-0.6.0-2.src.rpm Description: This package contains components and libraries that are intended to be shared between GNOME development tools, including gnome-build and anjuta2. It has been renamed anjuta-gdl (by me) as there is already a package called gdl which is not part of the gnome dev tools -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 21 20:27:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 15:27:16 -0500 Subject: [Bug 182320] New: Review Request: gnome-build Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182320 Summary: Review Request: gnome-build Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: paul at all-the-johnsons.co.uk QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.smmp.salford.ac.uk/packages/gnome-build.spec SRPM Name or Url: http://www.smmp.salford.ac.uk/packages/gnome-build-0.1.2-1.src.rpm Description: This is the GNOME Build Framework (GBF) (required for anjuta2) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From gauret at free.fr Tue Feb 21 22:40:58 2006 From: gauret at free.fr (Aurelien Bompard) Date: Tue, 21 Feb 2006 23:40:58 +0100 Subject: Build failure for amarok References: <20060221211322.653d1d3d.bugs.michael@gmx.net> Message-ID: Michael Schwendt wrote: > Did you run your test-builds with "--define fedora 5"? It failed in the buildsys too, where it is defined > Anyway, the build log looks like it wants libgstconfig.la from within > ./amarok/src/engine/gst/config instead of ./amarok/src/engine/gst10/config > which "make" did not enter. It built files in "gst" not "gst10". Hence > ../../../../amarok/src/engine/gst/config/libgstconfig.la is not available. Ah, yes, it was right under my nose. I already had to patch amarok's configure to make it detect gstreamer 0.10, so I guess support for that version is in its infancy. Thanks for looking at it Michael. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq' | dc From bugzilla at redhat.com Tue Feb 21 22:38:12 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 17:38:12 -0500 Subject: [Bug 181979] Review Request: python-geoip - Python bindings for the GeoIP geographical lookup libraries In-Reply-To: Message-ID: <200602212238.k1LMcClC001451@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: python-geoip - Python bindings for the GeoIP geographical lookup libraries https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181979 mfleming+rpm at enlartenment.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From mfleming+rpm at enlartenment.com 2006-02-21 17:38 EST ------- Imported and a devel branch build requested. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 21 21:59:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 16:59:16 -0500 Subject: [Bug 182175] Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) In-Reply-To: Message-ID: <200602212159.k1LLxGCM024584@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182175 ------- Additional Comments From terjeros at phys.ntnu.no 2006-02-21 16:59 EST ------- OK, thanks for the feedback, fixed most problems, however I am unsure how to deal with - Missing text of the license in %doc. there are no LICENSE file in the tarball, but every .c file has this header (see below). Any hints? /* * Copyright (C) 1997-2004, Michael Jennings * * Permission is hereby granted, free of charge, to any person obtaining a copy * of this software and associated documentation files (the "Software"), to * deal in the Software without restriction, including without limitation the * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or * sell copies of the Software, and to permit persons to whom the Software is * furnished to do so, subject to the following conditions: * * The above copyright notice and this permission notice shall be included in * all copies of the Software, its documentation and marketing & publicity * materials, and acknowledgment shall be given in the documentation, materials * and software packages that this Software was used. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL * THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER * IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */ -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From paul at all-the-johnsons.co.uk Tue Feb 21 21:50:07 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 21 Feb 2006 21:50:07 +0000 Subject: Build problems - any advice Message-ID: <1140558607.31940.11.camel@T7.Linux> Hi, anjuta-2.0.1 requires autogen to build (this is a 4th package required for the build - tsk). I've downloaded the srpm from sourceforge and installed it to my rpmbuild structure. Next, I edited the spec file so that it conforms to the FC policies and then tried to build. It went well until the make install which gave the following + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot ******************************************************************************* * * WARNING: 'check-rpaths' detected a broken RPATH and will cause 'rpmbuild' * to fail. To ignore these errors, you can set the '$QA_RPATHS' * environment variable which is a bitmask allowing the values * below. The current value of QA_RPATHS is 0x0000. * * 0x0001 ... standard RPATHs (e.g. /usr/lib); such RPATHs are a minor * issue but are introducing redundant searchpaths without * providing a benefit. They can also cause errors in multilib * environments. * 0x0002 ... invalid RPATHs; these are RPATHs which are neither absolute * nor relative filenames and can therefore be a SECURITY risk * 0x0004 ... insecure RPATHs; these are relative RPATHs which are a * SECURITY risk * 0x0008 ... the special '$ORIGIN' RPATHs are appearing after other * RPATHs; this is just a minor issue but usually unwanted * 0x0010 ... the RPATH is empty; there is no reason for such RPATHs * and they cause unneeded work while loading libraries * 0x0020 ... an RPATH references '..' of an absolute path; this will break * the functionality when the path before '..' is a symlink * * * Examples: * - to ignore standard and empty RPATHs, execute 'rpmbuild' like * $ QA_RPATHS=$[ 0x0001|0x0010 ] rpmbuild my-package.src.rpm * - to check existing files, set $RPM_BUILD_ROOT and execute check-rpaths like * $ RPM_BUILD_ROOT= /usr/lib/rpm/check-rpaths * * 'check-rpaths' is part of 'fedora-rpmdevtools'. * ******************************************************************************* ERROR 0001: file '/usr/bin/xml2ag' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR 0001: file '/usr/bin/getdefs' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR 0001: file '/usr/bin/columns' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR 0001: file '/usr/bin/autogen' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR 0001: file '/usr/lib64/libguileopts.so.0.0.1' contains a standard rpath '/usr/lib64' in [/usr/lib64] error: Bad exit status from /var/tmp/rpm-tmp.65896 (%install) Bad exit status from /var/tmp/rpm-tmp.65896 (%install) Is this a problem in the source or the spec file and if it's the spec file, how do I fix it? TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From bugzilla at redhat.com Tue Feb 21 21:20:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 16:20:50 -0500 Subject: [Bug 182330] New: Review Request: graphviz Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182330 Summary: Review Request: graphviz Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: paul at all-the-johnsons.co.uk QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.smmp.salford.ac.uk/packages/graphviz.spec SRPM Name or Url: http://www.smmp.salford.ac.uk/packages/graphviz-2.8-2.src.rpm Description: A collection of tools for the manipulation and layout of graphs (as in nodes and edges, not as in barcharts). Required for anjuta2 Source rpm is about 4.2Mb -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 21 23:01:46 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 18:01:46 -0500 Subject: [Bug 182330] Review Request: graphviz In-Reply-To: Message-ID: <200602212301.k1LN1kEC007518@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: graphviz https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182330 ------- Additional Comments From bdpepple at ameritech.net 2006-02-21 18:01 EST ------- This is already a part of FE. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From toshio at tiki-lounge.com Tue Feb 21 23:16:10 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 21 Feb 2006 15:16:10 -0800 Subject: static libs ... again In-Reply-To: <43F9EBBF.7030904@hhs.nl> References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> <1140243907.21764.402.camel@mccallum.corsepiu.local> <43F9BE60.1090705@hhs.nl> <43F9E499.9050109@hhs.nl> <43F9EBBF.7030904@hhs.nl> Message-ID: <1140563771.3361.27.camel@localhost> On Mon, 2006-02-20 at 17:18 +0100, Hans de Goede wrote: > Rex Dieter wrote: > > Hans de Goede wrote: > >> Rex Dieter wrote: > > > >>> Eek. I still think headers and api docs and such still should be > >>> in -devel (especially if there's any likelyhood of a real shared lib > >>> existing some day), and that -static should Requires: %{name}-devel > > > >>>> Also I wonder how hard is it to add -fpic -DPIC to the cflags and > >>>> change the link command to generate an .so. The only added trouble > >>>> would be checking for abi changes on new releases and bumping the > >>>> .so name a release. > > > >>> Exactly. I'm of the opinion (in most cases) that if upstream isn't > >>> able/willing to do something (like generating shared libs), then > >>> neither am I (as packager). > > > >> You say "Exactly" as in I agree with you and then you continue with > >> saying that you're not willing todo this, I'm confused now. > > > > Exactly, as in "The only added trouble..." part. (-: > > > > As I said, if it's really not so hard, let upstream do it, per Fedora's > > mantra "Upstream, upstream, upstream..." > > > > Yes, > > But sometimes upstream doesn't, because they dont care about this for > example, yet it would still be worth the trouble. I believe this needs > more discussion we all seem to agree that static libs should be provided > if possible, since in most cases even if upstream doesn't do it it isn't > all that much work, why don't we do this. > > I'm planning on packaging some software that uses one of these only has > -devel with static libs packages with no .so and I'm actually also > planning on filing an RFE against this package for proper .so files. > > Why shouldn't a packager do this? Upstream is what we want, but > unfortunatly is not always what we get. > Creating shared library infrastructure isn't too hard. But it is hard to maintain it without upstream support. You have to track ABI changes while upstream can feel free to make changes to data structures. You never know if your versioning will interfere with upstream's if they get around to creating the infrastructure themselves. If you're going to do this as a packager, you need to get some sort of blessing from upstream, otherwise you're going to have a lot of work maintaining the shared libraries. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From bugzilla at redhat.com Tue Feb 21 23:12:19 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 18:12:19 -0500 Subject: [Bug 182330] Review Request: graphviz In-Reply-To: Message-ID: <200602212312.k1LNCJmu009230@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: graphviz https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182330 paul at all-the-johnsons.co.uk changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|WONTFIX | ------- Additional Comments From paul at all-the-johnsons.co.uk 2006-02-21 18:12 EST ------- So it is. Mine is a much newer version. I'll file a BZ request -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From chitlesh at fedoraproject.org Tue Feb 21 23:44:22 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 22 Feb 2006 00:44:22 +0100 Subject: Anjuta - change of maintainer In-Reply-To: <1140477835.2971.5.camel@T7.Linux> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602201500w25dcc9dcp3ba8f1db893e7f7a@mail.gmail.com> <1140476701.2971.3.camel@T7.Linux> <13dbfe4f0602201520v21ee0d3br46b04df50eea092b@mail.gmail.com> <1140477835.2971.5.camel@T7.Linux> Message-ID: <13dbfe4f0602211544g643afe6ev3dd6b3419c3e1f6c@mail.gmail.com> > Do you mean 1.2.4 or the vsn 2.0x branch? There is a patch available for > 1.2.4 which I've applied and is currently being committed to extras. A patch ? where can I have it ? -- http://clunixchit.blogspot.com From gijs at gewis.nl Tue Feb 21 23:44:33 2006 From: gijs at gewis.nl (Gijs Hollestelle) Date: Wed, 22 Feb 2006 00:44:33 +0100 Subject: ppc builder problem In-Reply-To: <1140460354.23624.27.camel@cutter> References: <1140459484.25870.11.camel@bobcat.mine.nu> <1140459843.23624.25.camel@cutter> <1140460279.25870.16.camel@bobcat.mine.nu> <1140460354.23624.27.camel@cutter> Message-ID: <95da2d290602211544u2b9db3afpa77b11fea36eb836@mail.gmail.com> On 2/20/06, seth vidal wrote: > > The mailman issue is now https://bugzilla.redhat.com/182131 but I think > > it's not the culprit here. I get similar failures for my build of python-cherrypy today: http://buildsys.fedoraproject.org/logs/fedora-4-extras/5079-python-cherrypy-2.1.1-1.fc4/noarch/root.log It also appears to be pulling boa (and dap-server(?)) in and then fails. Only happens for FC4. FC3 and devel work fine. Anyone got an idea as to why this is happening or how to resolve it? Greets, Gijs From paul at all-the-johnsons.co.uk Tue Feb 21 23:47:05 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Tue, 21 Feb 2006 23:47:05 +0000 Subject: Anjuta - change of maintainer In-Reply-To: <13dbfe4f0602211544g643afe6ev3dd6b3419c3e1f6c@mail.gmail.com> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602201500w25dcc9dcp3ba8f1db893e7f7a@mail.gmail.com> <1140476701.2971.3.camel@T7.Linux> <13dbfe4f0602201520v21ee0d3br46b04df50eea092b@mail.gmail.com> <1140477835.2971.5.camel@T7.Linux> <13dbfe4f0602211544g643afe6ev3dd6b3419c3e1f6c@mail.gmail.com> Message-ID: <1140565626.31940.14.camel@T7.Linux> Hi, > A patch ? where can I have it ? Well, you could always just do a yum -y update and get it that way... Oh well, I'm a nice guy... --- src/anjuta-encodings.c.orig 2005-12-15 18:50:55.000000000 +0100 +++ src/anjuta-encodings.c 2005-12-15 18:51:38.000000000 +0100 @@ -707,15 +707,15 @@ gtk_tree_view_set_search_column (GTK_TREE_VIEW (stock_treeview), COLUMN_ENCODING_NAME); selection = gtk_tree_view_get_selection (GTK_TREE_VIEW (stock_treeview)); g_return_if_fail (selection != NULL); gtk_tree_selection_set_mode (selection, GTK_SELECTION_MULTIPLE); - g_signal_connect (G_OBJECT (selection), "changed", - G_CALLBACK (on_stock_selection_changed), NULL); model = create_encodings_treeview_model (); gtk_tree_view_set_model (GTK_TREE_VIEW (stock_treeview), model); + g_signal_connect (G_OBJECT (selection), "changed", + G_CALLBACK (on_stock_selection_changed), NULL); g_object_unref (model); /* Add the encoding column for supported treeview*/ cell = gtk_cell_renderer_text_new (); column = gtk_tree_view_column_new_with_attributes (_("Supported Encodings"), @@ -726,17 +726,17 @@ gtk_tree_view_set_search_column (GTK_TREE_VIEW (supported_treeview), COLUMN_ENCODING_NAME); selection = gtk_tree_view_get_selection (GTK_TREE_VIEW (supported_treeview)); g_return_if_fail (selection != NULL); gtk_tree_selection_set_mode (selection, GTK_SELECTION_BROWSE); - g_signal_connect (G_OBJECT (selection), "changed", - G_CALLBACK (on_supported_selection_changed), NULL); /* create list store */ model = GTK_TREE_MODEL (gtk_list_store_new (SUPPORTED_ENCODING_NUM_COLS, G_TYPE_STRING, G_TYPE_POINTER)); gtk_tree_view_set_model (GTK_TREE_VIEW (supported_treeview), model); + g_signal_connect (G_OBJECT (selection), "changed", + G_CALLBACK (on_supported_selection_changed), NULL); g_object_unref (model); anjuta_preferences_register_property_custom (pref, supported_treeview, SUPPORTED_ENCODINGS, "ISO-8859-15", TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show From bugzilla at redhat.com Wed Feb 22 00:33:03 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 19:33:03 -0500 Subject: [Bug 175495] Review Request: cgi-util: A C library for creating CGI programs In-Reply-To: Message-ID: <200602220033.k1M0X3Gl022681@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cgi-util: A C library for creating CGI programs https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175495 ------- Additional Comments From redhat at flyn.org 2006-02-21 19:32 EST ------- The following shortens the package descriptions and no longer renames the documentation files: Spec Name or Url: http://flyn.org/SRPMS/cgi-util.spec SRPM Name or Url: http://flyn.org/SRPMS/cgi-util-2.2.1-3.src.rpm Description: A C library for creating Common Gateway Interface ("CGI") programs Ignacio, what causes the package to fail to build on mock FC4/i386? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From pertusus at free.fr Wed Feb 22 00:31:16 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 22 Feb 2006 01:31:16 +0100 Subject: ppc builder problem In-Reply-To: <95da2d290602211544u2b9db3afpa77b11fea36eb836@mail.gmail.com> References: <1140459484.25870.11.camel@bobcat.mine.nu> <1140459843.23624.25.camel@cutter> <1140460279.25870.16.camel@bobcat.mine.nu> <1140460354.23624.27.camel@cutter> <95da2d290602211544u2b9db3afpa77b11fea36eb836@mail.gmail.com> Message-ID: <20060222003116.GD2995@free.fr> > It also appears to be pulling boa (and dap-server(?)) in and then I really can't see why dap-server is pulled! It doesn't provide anything specific??? -- Pat From bugzilla at redhat.com Wed Feb 22 01:31:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 20:31:09 -0500 Subject: [Bug 169717] Review Request: Internode DSL usage applet In-Reply-To: Message-ID: <200602220131.k1M1V9R3031969@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Internode DSL usage applet https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169717 ------- Additional Comments From wart at kobold.org 2006-02-21 20:31 EST ------- More build erros, this time on devel-i386: error: Installed (but unpackaged) file(s) found: /usr/bin/internode-applet.pyc /usr/bin/internode-applet.pyo These should probably be %ghosted. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 22 03:15:51 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 22:15:51 -0500 Subject: [Bug 182330] Review Request: graphviz In-Reply-To: Message-ID: <200602220315.k1M3FpV8017121@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: graphviz https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182330 rdieter at math.unl.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |CLOSED Resolution| |NOTABUG ------- Additional Comments From rdieter at math.unl.edu 2006-02-21 22:15 EST ------- Then do so in another ticket, or re-assign this one. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 03:22:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2006 22:22:28 -0500 Subject: [Bug 181801] Review Request: zeroinstall-injector In-Reply-To: Message-ID: <200602220322.k1M3MSTP018495@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: zeroinstall-injector https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181801 ------- Additional Comments From michel.salim at gmail.com 2006-02-21 22:22 EST ------- I agree on the second point, but about Source0, as I explained, the upstream source is a signed GPG file. Using the upstream source would require a BuildRequires on gnupg .. The source verification can be done by downloading the GPG-ed tarball from here: http://sourceforge.net/project/showfiles.php?group_id=76468&package_id=146899&release_id=390954 So the options are: - point Source0 to the .tar.gz.gpg file, BuildReq on gnupg - Manual verification of the source tarball (take the upstream source, gpg --decrypt ${file} > newfile, compare md5sums or do a diff) The QA checklist does not say anything about including the full Source URL, just that the source matches upstream. Let's come to an agreement on this and then I can submit the final version of the .spec file? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rc040203 at freenet.de Wed Feb 22 04:58:51 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 22 Feb 2006 05:58:51 +0100 Subject: Build problems - any advice In-Reply-To: <1140558607.31940.11.camel@T7.Linux> References: <1140558607.31940.11.camel@T7.Linux> Message-ID: <1140584331.14289.107.camel@mccallum.corsepiu.local> On Tue, 2006-02-21 at 21:50 +0000, Paul wrote: > Hi, > > anjuta-2.0.1 requires autogen to build (this is a 4th package required > for the build - tsk). Are you building from a tarball? If a tarball requires autogen, it is miss-packaged and upstream should solve this. > (this is a 4th package required for the build - tsk). I can't deny having the impression, we should consider a re-review of anjuta. Ralf From buildsys at fedoraproject.org Wed Feb 22 05:18:43 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 22 Feb 2006 00:18:43 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060222051843.0F4AB8011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 2 git-1.2.2-1.fc3 python-cherrypy-2.1.1-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed Feb 22 05:19:44 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 22 Feb 2006 00:19:44 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060222051944.32E9A8011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 41 BibTool-2.48-4.fc5 apachetop-0.12.5-3.fc5 basket-0.5.0-5.fc5 colorscheme-0.3-3.fc5 dvb-apps-1.1.0-2.fc5 freedroid-1.0.2-5.fc5 git-1.2.2-1.fc5 grisbi-0.5.8-2.fc5 gwenview-1.3.1-4.fc5 hdf5-1.6.5-3.fc5 iftop-0.17-1.fc5 lib765-0.3.3-3.fc5 libdsk-1.1.6-1.fc5 libkexif-0.2.2-4.fc5 libspectrum-0.2.2-4.fc5 libsx-2.05-8.fc5 libvisual-0.2.0-8.fc5 mpc-0.11.2-4.fc5 openvpn-2.1-0.7.beta11.fc5 perl-Jcode-2.03-3.fc5 perl-Unicode-Map-0.112-7.fc5 perl-Unicode-String-2.09-1.fc5 plone-2.1.2-1.fc5 psi-0.10-3.fc5 pure-ftpd-1.0.21-1.fc5 python-GeoIP-1.2.1-3.fc5 python-cherrypy-2.1.1-1.fc5 qca-1.0-6.fc5 qca-tls-1.0-9.fc5 showimg-0.9.5-5.fc5 taglib-1.4-2.fc5 tclhttpd-3.5.1-10.fc5 tclxml-3.1-7.fc5 ulogd-1.23-3.fc5 unrtf-0.19.9-1.fc5 wv-1.2.0-3.fc5 wv2-0.2.2-8.fc5 xlhtml-0.5-5.fc5 xlockmore-5.21-1.fc5 xpilot-ng-4.7.2-5.fc5 zope-2.8.5-1.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Wed Feb 22 05:54:37 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 00:54:37 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602220554.k1M5sbWH011435@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From jwb at redhat.com 2006-02-22 00:54 EST ------- Realignment of package: - fold -docs package back into main package. - use -developer tarball from upstream - split out all modules/themes into individual subpackages - realign requires in core package to include at least one graphics module and one theme, graphics modules require the corresponding library packages New files: SPEC: http://www.berningeronline.net/gallery2.spec SRPM: http://www.berningeronline.net/gallery2-2.0.2-6.src.rpm Still needs formal review / sponsor. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rc040203 at freenet.de Wed Feb 22 06:07:29 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 22 Feb 2006 07:07:29 +0100 Subject: Specifying arch in BuildRequires: In-Reply-To: References: <43FA9B74.30606@redhat.com> <1140535185.14289.71.camel@mccallum.corsepiu.local> <1140537283.14289.84.camel@mccallum.corsepiu.local> Message-ID: <1140588449.14289.116.camel@mccallum.corsepiu.local> On Tue, 2006-02-21 at 10:52 -0600, Jason L Tibbitts III wrote: > >>>>> "RC" == Ralf Corsepius writes: > > RC> --with-newlib or --enable-multilib? > > Neither. Honestly, until today I didn't know those flags existed. > > The failed build is at > http://www.math.uh.edu/~tibbs/rpms/gpc/x86_64-failed-build.log This clearly is a side-effect of FC's broken GCC packaging. FC's GCC had been configured w/ --enable-multilib, and the gcc driver (/usr/bin/gcc) knows about it. When building gpc, gcc/configure detects /usr/bin/gcc reporting multilibs to be present, and therefore starts building gcc libs multilib'ed. Unfortunately, FC's GCC has been broken into i386 and x86_64 packages (i.e. /usr/bin/gcc's expectations are inconsistent with the rpm packaging). Anyway, --disable-multlib is the appropriate work-around. > However, the clues I found in the ghdl package (probably just > --disable-multilib) were enough to get things building. My thanks to > Paul. I'll respin the package and update bugzilla. Could you upload the *.x86_64.rpm binary rpms? I am suspecting some paths don't get set up correctly, but I can't check, because I don't have access to x86_64's ... Ralf From bugzilla at redhat.com Wed Feb 22 06:03:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 01:03:13 -0500 Subject: [Bug 177359] Review Request: itk - object oriented extensions for Tk In-Reply-To: Message-ID: <200602220603.k1M63D2o012604@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: itk - object oriented extensions for Tk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177359 wart at kobold.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From wart at kobold.org 2006-02-22 01:03 EST ------- Imported and built on devel. Thanks! -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 22 06:03:37 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 01:03:37 -0500 Subject: [Bug 174268] Review Request: itcl-iwidgets - object oriented megawidgets for Tcl In-Reply-To: Message-ID: <200602220603.k1M63bWY012689@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: itcl-iwidgets - object oriented megawidgets for Tcl https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174268 Bug 174268 depends on bug 177359, which changed state. Bug 177359 Summary: Review Request: itk - object oriented extensions for Tk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177359 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NEXTRELEASE Status|ASSIGNED |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 22 06:57:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 01:57:18 -0500 Subject: [Bug 181801] Review Request: zeroinstall-injector In-Reply-To: Message-ID: <200602220657.k1M6vIEI019956@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: zeroinstall-injector https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181801 ------- Additional Comments From paul at city-fan.org 2006-02-22 01:57 EST ------- (In reply to comment #4) > I agree on the second point, but about Source0, as I explained, the upstream > source is a signed GPG file. Using the upstream source would require a > BuildRequires on gnupg .. > > The source verification can be done by downloading the GPG-ed tarball from here: > http://sourceforge.net/project/showfiles.php?group_id=76468&package_id=146899&release_id=390954 > > So the options are: > - point Source0 to the .tar.gz.gpg file, BuildReq on gnupg > - Manual verification of the source tarball (take the upstream source, gpg > --decrypt ${file} > newfile, compare md5sums or do a diff) I would advocate the first option; it allows people to do: $ spectool --gf zeroinstall-injector.spec to retrieve the sources directly from upstream. Shouldn't the buildreq be python-devel rather than python? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From paul at all-the-johnsons.co.uk Wed Feb 22 07:21:01 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Wed, 22 Feb 2006 07:21:01 +0000 Subject: Build problems - any advice In-Reply-To: <1140584331.14289.107.camel@mccallum.corsepiu.local> References: <1140558607.31940.11.camel@T7.Linux> <1140584331.14289.107.camel@mccallum.corsepiu.local> Message-ID: <1140592861.31940.23.camel@T7.Linux> Hi, > > (this is a 4th package required for the build - tsk). > I can't deny having the impression, we should consider a re-review of > anjuta. This is for version 2.0.1, not 1.2.4 which is relatively easy to build. That said, 2.0.1 fails to build anyway currently! TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show From bugzilla at redhat.com Wed Feb 22 07:20:37 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 02:20:37 -0500 Subject: [Bug 169717] Review Request: Internode DSL usage applet In-Reply-To: Message-ID: <200602220720.k1M7Kb4H022958@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Internode DSL usage applet https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169717 ------- Additional Comments From ville.skytta at iki.fi 2006-02-22 02:20 EST ------- Actually, I think they should be just %exclude'd (can't rm -f because they're generated by rpmbuild after %install). As far as I can tell, there should be no reason for rpmbuild to byte-compile *.py scripts in /usr/bin. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rc040203 at freenet.de Wed Feb 22 07:41:29 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 22 Feb 2006 08:41:29 +0100 Subject: Build problems - any advice In-Reply-To: <1140592861.31940.23.camel@T7.Linux> References: <1140558607.31940.11.camel@T7.Linux> <1140584331.14289.107.camel@mccallum.corsepiu.local> <1140592861.31940.23.camel@T7.Linux> Message-ID: <1140594089.14289.125.camel@mccallum.corsepiu.local> On Wed, 2006-02-22 at 07:21 +0000, Paul F. Johnson wrote: > Hi, > > > > (this is a 4th package required for the build - tsk). > > I can't deny having the impression, we should consider a re-review of > > anjuta. > > This is for version 2.0.1, I am aware about this, but I miss-read your question. It's not that anjuta-2.0.1 uses autogen during building (This would be a bug), it's that anjuta-2.0.1 _unconditionally_ requires autogen, instead of disabling autogen-support if it can't find it. I'd call this a feature-overladden, semi-cooked package ;) Ralf From bugzilla at redhat.com Wed Feb 22 07:46:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 02:46:30 -0500 Subject: [Bug 169717] Review Request: Internode DSL usage applet In-Reply-To: Message-ID: <200602220746.k1M7kUGg026724@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Internode DSL usage applet https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169717 wart at kobold.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|gdk at redhat.com |wart at kobold.org OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From wart at kobold.org 2006-02-22 02:46 EST ------- GOOD ==== * rpmlint output clean * No redundance or not permissible BR: * Source matches upstream * Package name follows guidelines for gnome applets * Builds on FC4-i386 * spec file legible, in Am. English * macro use consistent * code, not content * No shared libraries or -devel package * doc ok * desktop file not needed * Runs without crashing (did not test with a valid Internode account, however) Recommended (but not required) ==== * Use %{SOURCE1} instead of {%_sourcedir}/COPYING * Add %{?dist} to release tag * GPL license ok, text included * Does not build on FC5-i386 or FC4-x86_64. * mock build not tested (my mock env. is hosed right now) MUSTFIX: * %exclude %{_bindir}/*.pyc %{_bindir}/*.pyo (comment #6) * Requires: python-abi not needed for FC-5 (comment #2) * Fix x86_64 build with respect to /usr/lib (comment #3) * Does not own all directories that it creates: - %{python_sitelib}/internode/ - %{datadir}/internode/ - %{_libdir}/bonobo/servers (probably owned by a parent of one of the Requires, but was unable to verify) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 22 07:47:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 02:47:53 -0500 Subject: [Bug 175495] Review Request: cgi-util: A C library for creating CGI programs In-Reply-To: Message-ID: <200602220747.k1M7lrrY026937@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cgi-util: A C library for creating CGI programs https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175495 ivazquez at ivazquez.net changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|gdk at redhat.com |ivazquez at ivazquez.net OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From ivazquez at ivazquez.net 2006-02-22 02:47 EST ------- gcc -DHAVE_CONFIG_H -I. -I. -I. -g -Werror -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables -MT cgi-util.lo -MD -MP -MF .deps/cgi-util.Tpo -c cgi-util.c -fPIC -DPIC -o .libs/cgi-util.o cc1: warnings being treated as errors cgi-util.c: In function 'cgi_init': cgi-util.c:220: warning: ignoring return value of 'fgets', declared with attribute warn_unused_result make[1]: *** [cgi-util.lo] Error 1 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From mmcgrath at fedoraproject.org Wed Feb 22 08:45:27 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 22 Feb 2006 02:45:27 -0600 Subject: THE SKY IS FALLING - FC4 and i386 builds Message-ID: <3237e4410602220045m1cdbf8d8i5c5073fea7070474@mail.gmail.com> FC4 builds are still failing. http://buildsys.fedoraproject.org/logs/fedora-4-extras/5089-ytalk-3.3.0-3.fc4/i386/ I'll keep taking a look but I don't know that much about the buildsys. Anyone else out there more familiar that can take a look? -Mike From andreas.bierfert at lowlatency.de Wed Feb 22 08:46:02 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Wed, 22 Feb 2006 09:46:02 +0100 Subject: FC4 builds are broken - please fix! In-Reply-To: <26585.70.56.38.46.1140534930.squirrel@www.cora.nwra.com> References: <26585.70.56.38.46.1140534930.squirrel@www.cora.nwra.com> Message-ID: <20060222094602.34494bfd@alkaid.a.lan> On Tue, 21 Feb 2006 08:15:30 -0700 (MST) orion at cora.nwra.com wrote: > This is an attempt to get more attention, lest it have fallen through the > cracks due to a strange subject line. Please see the thread "deciphering > a build failure". FC4 build are breaking. All architectures. I cannot > reproduce locally with mock. Same here... - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From paul at all-the-johnsons.co.uk Wed Feb 22 09:10:41 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Wed, 22 Feb 2006 09:10:41 +0000 Subject: Build problems - any advice In-Reply-To: <1140594089.14289.125.camel@mccallum.corsepiu.local> References: <1140558607.31940.11.camel@T7.Linux> <1140584331.14289.107.camel@mccallum.corsepiu.local> <1140592861.31940.23.camel@T7.Linux> <1140594089.14289.125.camel@mccallum.corsepiu.local> Message-ID: <1140599441.31392.7.camel@mrwibble.mrwobble> Hi, > It's not that anjuta-2.0.1 uses autogen during building (This would be a > bug), it's that anjuta-2.0.1 _unconditionally_ requires autogen, instead > of disabling autogen-support if it can't find it. By the looks of it, autogen is required by Anjuta 2.0 to perform part of the users build system, so it isn't viable to remove it. > I'd call this a feature-overladden, semi-cooked package ;) Nah, it looks more like corner cutting. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From paul at city-fan.org Wed Feb 22 09:12:05 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 22 Feb 2006 09:12:05 +0000 Subject: FC4 builds are broken - please fix! In-Reply-To: <20060222094602.34494bfd@alkaid.a.lan> References: <26585.70.56.38.46.1140534930.squirrel@www.cora.nwra.com> <20060222094602.34494bfd@alkaid.a.lan> Message-ID: <1140599525.7246.16.camel@laurel.intra.city-fan.org> On Wed, 2006-02-22 at 09:46 +0100, Andreas Bierfert wrote: > On Tue, 21 Feb 2006 08:15:30 -0700 (MST) > orion at cora.nwra.com wrote: > > > This is an attempt to get more attention, lest it have fallen through the > > cracks due to a strange subject line. Please see the thread "deciphering > > a build failure". FC4 build are breaking. All architectures. I cannot > > reproduce locally with mock. > > Same here... Same everywhere else judging by the complete lack of a Fedora Extras 4 Package Build Report this morning. Paul. From bugzilla at redhat.com Wed Feb 22 09:32:40 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 04:32:40 -0500 Subject: [Bug 182330] Review Request: graphviz In-Reply-To: Message-ID: <200602220932.k1M9WexF018023@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: graphviz https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182330 oliver at linux-kernel.at changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |oliver at linux-kernel.at ------- Additional Comments From oliver at linux-kernel.at 2006-02-22 04:32 EST ------- What exactly do you want? I'm currently the maintainer of graphviz, so if you want it to be newer, why don't you file a bz request for me so I can check it? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From triad at df.lth.se Wed Feb 22 10:35:35 2006 From: triad at df.lth.se (Linus Walleij) Date: Wed, 22 Feb 2006 11:35:35 +0100 (CET) Subject: static libs ... again In-Reply-To: <1140503232.21764.620.camel@mccallum.corsepiu.local> References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> <1140243907.21764.402.camel@mccallum.corsepiu.local> <43F9BE60.1090705@hhs.nl> <1140441846.21764.558.camel@mccallum.corsepiu.local> <43FA1011.9000608@cora.nwra.com> <20060220200441.GH2861@free.fr> <1140503232.21764.620.camel@mccallum.corsepiu.local> Message-ID: > gcc --shared/--static. These are real messy to use, as far as I know it is an all-or-nothing flag to the linker, --static really links all libs statically (if the static versions are available). What one would normally like to do would be: gcc ... -lfoo --static -lbar --shared -lbaz assuming switches progress from left to right to flag that one (and only one) library should be linked in statically. This does not work, atleaste when I tried (could be that I'm unaware of something basic here.) The only approach I ever found was to remove the dynamic libraries (rm -f /usr/lib/libfoo.so*) and link as usual. Since the dynamic libs are missing, the linker will pick up the static ones instead. I wonder of it'll really work to have both static and dynamic libs in the same file tree and try to link the static version, but please enlighten me. Of course as long as you're only using one single library, --static works OK but with more complex programs it's just one big mess. Another reason not to use it IMHO. Linus From bugzilla at redhat.com Wed Feb 22 10:49:29 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 05:49:29 -0500 Subject: [Bug 166255] Review Request: Sprog In-Reply-To: Message-ID: <200602221049.k1MAnTOK006882@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Sprog https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166255 ------- Additional Comments From ghenry at suretecsystems.com 2006-02-22 05:49 EST ------- I don't think so. It's been commited, so not sure what is next. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rdieter at math.unl.edu Wed Feb 22 11:48:51 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 22 Feb 2006 05:48:51 -0600 Subject: static libs ... again In-Reply-To: References: <43F6123D.2060900@ieee.org> <1140230304.31903.54.camel@ernie> <1140243907.21764.402.camel@mccallum.corsepiu.local> <43F9BE60.1090705@hhs.nl> <1140441846.21764.558.camel@mccallum.corsepiu.local> <43FA1011.9000608@cora.nwra.com> <20060220200441.GH2861@free.fr> <1140503232.21764.620.camel@mccallum.corsepiu.local> Message-ID: Linus Walleij wrote: >> gcc --shared/--static. > > These are real messy to use, as far as I know it is an all-or-nothing > flag to the linker, --static really links all libs statically (if the > static versions are available). > > What one would normally like to do would be: > gcc ... -lfoo --static -lbar --shared -lbaz > > assuming switches progress from left to right to flag that one (and only > one) library should be linked in statically. > > This does not work, Try this (or something close to it) instead: gcc ... -lfoo -Wl,--static -lbar -Wl,--shared -lbaz -- Rex From rdieter at math.unl.edu Wed Feb 22 11:50:08 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 22 Feb 2006 05:50:08 -0600 Subject: THE SKY IS FALLING - FC4 and i386 builds In-Reply-To: <3237e4410602220045m1cdbf8d8i5c5073fea7070474@mail.gmail.com> References: <3237e4410602220045m1cdbf8d8i5c5073fea7070474@mail.gmail.com> Message-ID: Mike McGrath wrote: > FC4 builds are still failing. > > http://buildsys.fedoraproject.org/logs/fedora-4-extras/5089-ytalk-3.3.0-3.fc4/i386/ Ditto, it's not just you. -- Rex From bugzilla at redhat.com Wed Feb 22 11:48:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 06:48:10 -0500 Subject: [Bug 166255] Review Request: Sprog In-Reply-To: Message-ID: <200602221148.k1MBmAYD021013@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Sprog https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166255 ------- Additional Comments From ghenry at suretecsystems.com 2006-02-22 06:47 EST ------- Cheers for the kick Ignacio Rebuilt to test everythign is still ok as Sprog-0.14-6.src.rpm. Commited to devel tree. Gavin. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 22 12:01:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 07:01:10 -0500 Subject: [Bug 172140] Review Request: libmal: a convenience library for malsync In-Reply-To: Message-ID: <200602221201.k1MC1AEK023814@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libmal: a convenience library for malsync https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172140 imlinux at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |imlinux at gmail.com ------- Additional Comments From imlinux at gmail.com 2006-02-22 07:00 EST ------- Looks good Do the patches included in this srpm have an upstream url that you could append to them in the spec file? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rc040203 at freenet.de Wed Feb 22 11:22:07 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 22 Feb 2006 12:22:07 +0100 Subject: Build problems - any advice In-Reply-To: <1140599441.31392.7.camel@mrwibble.mrwobble> References: <1140558607.31940.11.camel@T7.Linux> <1140584331.14289.107.camel@mccallum.corsepiu.local> <1140592861.31940.23.camel@T7.Linux> <1140594089.14289.125.camel@mccallum.corsepiu.local> <1140599441.31392.7.camel@mrwibble.mrwobble> Message-ID: <1140607327.14289.131.camel@mccallum.corsepiu.local> On Wed, 2006-02-22 at 09:10 +0000, Paul F. Johnson wrote: > Hi, > > > It's not that anjuta-2.0.1 uses autogen during building (This would be a > > bug), it's that anjuta-2.0.1 _unconditionally_ requires autogen, instead > > of disabling autogen-support if it can't find it. > > By the looks of it, autogen is required by Anjuta 2.0 to perform part of > the users build system, so it isn't viable to remove it. Really? ... anjuta had never worked well and had always done a bad job on using the autotools, but this is worse than I had expected. > > I'd call this a feature-overladden, semi-cooked package ;) > > Nah, it looks more like corner cutting. We'll see how far you can proceed ;) I'd recommend to file a separate Review Request, but I can't say to like what I see in anjuta so far. Ralf From paul at all-the-johnsons.co.uk Wed Feb 22 12:22:09 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Wed, 22 Feb 2006 12:22:09 +0000 Subject: Build problems - any advice In-Reply-To: <1140607327.14289.131.camel@mccallum.corsepiu.local> References: <1140558607.31940.11.camel@T7.Linux> <1140584331.14289.107.camel@mccallum.corsepiu.local> <1140592861.31940.23.camel@T7.Linux> <1140594089.14289.125.camel@mccallum.corsepiu.local> <1140599441.31392.7.camel@mrwibble.mrwobble> <1140607327.14289.131.camel@mccallum.corsepiu.local> Message-ID: <1140610929.31392.22.camel@mrwibble.mrwobble> Hi, > > Nah, it looks more like corner cutting. > We'll see how far you can proceed ;) Getting the damned thing to compile would be a start... TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From bugzilla at redhat.com Wed Feb 22 12:46:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 07:46:09 -0500 Subject: [Bug 172140] Review Request: libmal: a convenience library for malsync In-Reply-To: Message-ID: <200602221246.k1MCk9P2002339@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libmal: a convenience library for malsync https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172140 ------- Additional Comments From rdieter at math.unl.edu 2006-02-22 07:46 EST ------- The patches are from me, so there is no upstream url for them. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 22 13:32:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 08:32:01 -0500 Subject: [Bug 182411] New: Review Request: man-pages-uk Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182411 Summary: Review Request: man-pages-uk Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: andy at smile.org.ua QAContact: fedora-extras-list at redhat.com Spec Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/man-pages-uk.spec SRPM Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/man-pages-uk-0.2-3.src.rpm Description: A large collection of man pages (reference material) from the Linux Documentation Project (LDP), translated to Ukrainian. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 13:34:54 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 08:34:54 -0500 Subject: [Bug 182413] New: Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182413 Summary: Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: andy at smile.org.ua QAContact: fedora-extras-list at redhat.com Spec Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/man-pages-uk.spec SRPM Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/man-pages-uk-0.2-3.src.rpm Description: A large collection of man pages (reference material) from the Linux Documentation Project (LDP), translated to Ukrainian. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 13:44:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 08:44:11 -0500 Subject: [Bug 182415] New: Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182415 Summary: Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: andy at smile.org.ua QAContact: fedora-extras-list at redhat.com Spec Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/man-pages-uk.spec SRPM Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/man-pages-uk-0.2-3.src.rpm Description: Hello. I've finished packaging up man-pages-uk. I should like to send on a review so that I can get it into Fedora Extras. A large collection of man pages (reference material) from the Linux Documentation Project (LDP), translated to Ukrainian. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 13:45:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 08:45:27 -0500 Subject: [Bug 182411] Review Request: man-pages-uk In-Reply-To: Message-ID: <200602221345.k1MDjRsm013053@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: man-pages-uk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182411 andy at smile.org.ua changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |DUPLICATE ------- Additional Comments From andy at smile.org.ua 2006-02-22 08:45 EST ------- *** This bug has been marked as a duplicate of 182415 *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 13:45:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 08:45:34 -0500 Subject: [Bug 182415] Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project In-Reply-To: Message-ID: <200602221345.k1MDjYh7013105@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182415 ------- Additional Comments From andy at smile.org.ua 2006-02-22 08:45 EST ------- *** Bug 182411 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 13:46:06 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 08:46:06 -0500 Subject: [Bug 182413] Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project In-Reply-To: Message-ID: <200602221346.k1MDk6aT013236@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182413 andy at smile.org.ua changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |DUPLICATE ------- Additional Comments From andy at smile.org.ua 2006-02-22 08:46 EST ------- *** This bug has been marked as a duplicate of 182415 *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 13:46:12 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 08:46:12 -0500 Subject: [Bug 182415] Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project In-Reply-To: Message-ID: <200602221346.k1MDkCUg013265@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182415 ------- Additional Comments From andy at smile.org.ua 2006-02-22 08:46 EST ------- *** Bug 182413 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From chitlesh at fedoraproject.org Wed Feb 22 14:04:07 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 22 Feb 2006 15:04:07 +0100 Subject: Anjuta - change of maintainer In-Reply-To: <1140565626.31940.14.camel@T7.Linux> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602201500w25dcc9dcp3ba8f1db893e7f7a@mail.gmail.com> <1140476701.2971.3.camel@T7.Linux> <13dbfe4f0602201520v21ee0d3br46b04df50eea092b@mail.gmail.com> <1140477835.2971.5.camel@T7.Linux> <13dbfe4f0602211544g643afe6ev3dd6b3419c3e1f6c@mail.gmail.com> <1140565626.31940.14.camel@T7.Linux> Message-ID: <13dbfe4f0602220604l1f30f6b6w1511f42ad780fa89@mail.gmail.com> On 2/22/06, Paul F. Johnson wrote: > Hi, > > > A patch ? where can I have it ? > > Well, you could always just do a yum -y update and get it that way... > > Oh well, I'm a nice guy... strange buildsys says this is an update but with yum install anjuta* Im having anjuta i386 1:1.2.3-3.fc5 extras-development 2.6 M by the way, your patch worked :) -- http://clunixchit.blogspot.com From tibbs at math.uh.edu Wed Feb 22 14:30:47 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 22 Feb 2006 08:30:47 -0600 Subject: Specifying arch in BuildRequires: In-Reply-To: <1140588449.14289.116.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Wed, 22 Feb 2006 07:07:29 +0100") References: <43FA9B74.30606@redhat.com> <1140535185.14289.71.camel@mccallum.corsepiu.local> <1140537283.14289.84.camel@mccallum.corsepiu.local> <1140588449.14289.116.camel@mccallum.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> Could you upload the *.x86_64.rpm binary rpms? Sure; they're in http://www.math.uh.edu/~tibbs/rpms/gpc/. Unfortunately I have no FC4 x86_64 boxes running yet, so I have a tough time actually testing the builds. (My x86_64 boxes are still running FC3, but I have a new 8-CPU machine to bring up today so perhaps I'll be able to do proper testing tomorrow.) - J< From bugzilla at redhat.com Wed Feb 22 14:48:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 09:48:11 -0500 Subject: [Bug 182175] Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) In-Reply-To: Message-ID: <200602221448.k1MEmBPn026802@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182175 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-22 09:48 EST ------- I think at first you should ask the upstream author to include a LICENSE file into the tar ball. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 14:55:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 09:55:59 -0500 Subject: [Bug 174268] Review Request: itcl-iwidgets - object oriented megawidgets for Tcl In-Reply-To: Message-ID: <200602221455.k1MEtxaY028754@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: itcl-iwidgets - object oriented megawidgets for Tcl https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174268 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |jpmahowald at gmail.com OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-22 09:55 EST ------- Good: - rpmlint clean - package meets naming guidelines - package meets packaging guidelines - license (BSD) OK, text in %doc, matches source - spec file legible, in am. english - source matches upstream - package compiles on FC4 i386 - no missing BR - no unnecessary BR - no locales - not relocatable - owns all directories that it creates - no duplicate files - permissions ok - %clean ok - macro use consistent - code, not content - no need for -docs - nothing in %doc affects runtime - no need for .desktop file APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 22 14:59:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 09:59:10 -0500 Subject: [Bug 181801] Review Request: zeroinstall-injector In-Reply-To: Message-ID: <200602221459.k1MExAAO029560@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: zeroinstall-injector https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181801 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-22 09:59 EST ------- I agree with Paul that we should use the first option. And I have a look. A python-devel package is existance. Becouse I'm kow on a windows machine, I don't determinate, if setup.py is contains in python-devel. If so, what I believe, python-devel should be a BuildRequire. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 15:04:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 10:04:15 -0500 Subject: [Bug 182175] Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) In-Reply-To: Message-ID: <200602221504.k1MF4FfS030787@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182175 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-22 10:04 EST ------- A fast solution may be to copy the license text from the source file into a LICENSE file, which may be included via the Source1 tag into the SPEC file. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 15:23:26 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 10:23:26 -0500 Subject: [Bug 176021] Review Request: bwidget - extended widget set for Tcl/Tk In-Reply-To: Message-ID: <200602221523.k1MFNQks002568@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: bwidget - extended widget set for Tcl/Tk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176021 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: bwidget - |Review Request: bwidget - |extended widget set for |extended widget set for |Tcl/Tk |Tcl/Tk Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |jpmahowald at gmail.com OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-22 10:23 EST ------- Good: - rpmlint checks clean - package meets naming guidelines - package meets packaging guidelines - license (Distributable, but seems BSDish) OK, text in %doc, matches source - spec file legible, in am. english - source matches upstream - package compiles on FC4 i386 - no missing BR - no unnecessary BR - no locales (none that use %find_lang) - not relocatable - owns all directories that it creates - no duplicate files - permissions ok - %clean ok - macro use consistent - code, not content - no need for -docs - nothing in %doc affects runtime - no need for .desktop file APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From paul at all-the-johnsons.co.uk Wed Feb 22 15:39:26 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Wed, 22 Feb 2006 15:39:26 +0000 Subject: Anjuta - change of maintainer In-Reply-To: <13dbfe4f0602220604l1f30f6b6w1511f42ad780fa89@mail.gmail.com> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602201500w25dcc9dcp3ba8f1db893e7f7a@mail.gmail.com> <1140476701.2971.3.camel@T7.Linux> <13dbfe4f0602201520v21ee0d3br46b04df50eea092b@mail.gmail.com> <1140477835.2971.5.camel@T7.Linux> <13dbfe4f0602211544g643afe6ev3dd6b3419c3e1f6c@mail.gmail.com> <1140565626.31940.14.camel@T7.Linux> <13dbfe4f0602220604l1f30f6b6w1511f42ad780fa89@mail.gmail.com> Message-ID: <1140622767.31392.33.camel@mrwibble.mrwobble> Hi, > strange buildsys says this is an update > but with yum install anjuta* Im having > > anjuta i386 1:1.2.3-3.fc5 extras-development 2.6 M Can't explain that unless the mirror you're using hasn't updated > by the way, your patch worked :) :-) TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From Christian.Iseli at licr.org Wed Feb 22 15:51:53 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 22 Feb 2006 16:51:53 +0100 Subject: FE Package Status of Feb 22, 2006 Message-ID: <200602221551.k1MFprOL025273@ludwig-alpha.unil.ch> FE Package Status of Feb 22, 2006 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 1455 packages - 51 orphans - 49 packages not available in extras devel or release andreas at bawue dot net dd_rescue denis at poolshark dot org gcdmaster dennis at ausil dot us cryptplug djoo at redhat dot com nabi dwmw2 at redhat dot com qemu dwmw2 at redhat dot com apmud gemi at bluewin dot ch inti gemi at bluewin dot ch drscheme ghenry at suretecsystems dot com gnome-applet-netmon ghenry at suretecsystems dot com rsnapshot ghenry at suretecsystems dot com Sprog ivazquez at ivazquez dot net gnome-theme-clearlooks ivazquez at ivazquez dot net gpredict ivazquez at ivazquez dot net TurboGears j dot w dot r dot degoede at hhs dot nl libgsf113 j dot w dot r dot degoede at hhs dot nl Glide3-libGl jcarpenter at condell dot org thinkpad-kmod-common jcarpenter at condell dot org thinkpad-kmod jcarpenter at condell dot org tpctl jcarpenter at condell dot org configure-thinkpad kaboom at oobleck dot net openbox matthias at rpmforge dot net php-pecl-sqlite matthias at rpmforge dot net fillets-ng-data-cs nomis80 at nomis80 dot org juk notting at redhat dot com comps oliver at linux-kernel dot at squidGuard paul at all-the-johnsons dot co dot uk z88dk pertusus at free dot fr dap-hdf4_handler sgrubb at redhat dot com libsafe tcallawa at redhat dot com R-hdf5 tcallawa at redhat dot com stripesnoop tcallawa at redhat dot com compat-wxPythonGTK2 tcallawa at redhat dot com pam_pkcs11 tcallawa at redhat dot com opendap thm at duke dot edu perl-GD-SVG thm at duke dot edu perl-bioperl thm at duke dot edu perl-XML-Writer thm at duke dot edu perl-SVG thm at duke dot edu perl-SOAP-Lite thm at duke dot edu perl-Graph thm at duke dot edu perl-Text-Shellwords thm at duke dot edu perl-Heap toniw at iki dot fi libmatchbox ville dot skytta at iki dot fi lirc-kmod-common ville dot skytta at iki dot fi lirc-kmod wart at kobold dot org itk wtogami at redhat dot com openoffice-extras zipsonic at gmail dot com nx zipsonic at gmail dot com freenx - 10 packages not available in extras devel but present in release andreas dot bierfert at lowlatency dot de wmweather+ dreadyman at gmail dot com yakuake gemi at bluewin dot ch gcl matthias at rpmforge dot net php-mmcache notting at redhat dot com aqhbci-qt-tools pertusus at free dot fr dap-server tcallawa at redhat dot com R-RScaLAPACK tcallawa at redhat dot com ebtables tcallawa at redhat dot com lout wtogami at redhat dot com iiimf-le-simplehangul - 3 packages which have not yet been FE-APPROVE'd... - 5 packages present in the development repo which have no owners entry Glide3-libGL dia git html-xml-utils libresample - 42 orphaned packages, yet available in extras devel abe arc at-poke camstream cgoban cksfv duplicity freedroidrpg gdeskcal gkrellm-themes gnofract4d gnome-password-generator gnome-telnet gnome-themes-extras gnugo gonvert gtkglarea2 gurlchecker libzvt lua manedit mknbi netdiag nget ots parchive perl-Net-SCP perl-Net-SSH prozilla putty rpmproc sirius tdl tetex-arabtex tetex-armtex tetex-font-tipa tetex-lgrind tla wbxml2 wesnoth xmms-cdread xtide - 35 packages that moved to core FE-ACCEPT packages stats: - 523 accepted, closed package reviews - 4 accepted, closed package reviews not in repo - 4 accepted, closed package reviews not in owners - 12 accepted, open package reviews older than 4 weeks; - 8 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 70 open tickets - 15 tickets with no activity in eight weeks - 13 tickets with no activity in four weeks - 3 closed tickets FE-NEW packages stats: - 120 open tickets - 11 tickets with no activity in eight weeks - 23 tickets with no activity in four weeks - 9 closed tickets FE-NEEDSPONSOR packages stats: - 37 open tickets - 11 tickets with no activity in four weeks FE-LEGAL packages stats: - 1 open tickets OPEN-BUGS packages stats: - 292 open tickets - 110 tickets with no activity in eight weeks - 39 tickets with no activity in four weeks CVS stats: - 1433 packages with a devel directory - 6 packages with no owners entry Glide3-libGL dia html-xml-utils kile-i18n perl-Gtk2-Spell perl-Maypole Maintainers stats: - 159 maintainers - 12 inactive maintainers with open bugs - 15 inactive maintainers From Christian.Iseli at licr.org Wed Feb 22 15:58:17 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 22 Feb 2006 16:58:17 +0100 Subject: FE Package Status of Feb 16, 2006 In-Reply-To: Your message of "Sat, 18 Feb 2006 13:00:09 +0100." <1140264009.2904.119.camel@localhost.localdomain> Message-ID: <200602221558.k1MFwH9V025312@ludwig-alpha.unil.ch> Hi folks, I produced a new package status, and tried to fix the reported bugs. Summary is in a separate mail. fedora at leemhuis.info said: > Quite long now. That's a bit problematic afaics. I really would like to have > the important stuff more highlighted. I agree, and welcome any propositions :-) > For example, the stuff that really needs fixing (or at least needs a > explanation why it's broken) should also be sent to the list IMHO. Or maybe > directly to the E-Mail addresses listed. Maybe both. I mean the following > sections: Ok, tried to add those in the email. > There are some other sections like > - "Packages that have not yet completed review", > - "Potential problems: > 'We have X accepted, closed packages where I'm unable to find the > package in the development repo' > and > 'We have 8 accepted, closed packages where I'm unable to find the > package in the owners file'" > - "Some cleanup needed" > - ...and maybe some other sections, too > > Those should be trivial to fix for the owners. They just needed to be > poked by someone -- in an ideal world the script would do that directly. > Christian, would that be possible? I guess anything's possible :-) I didn't see a big discussion about people wanting to be poked by email, so before I go and make a nuisance of myself, I'd like to be reasonably confident that it's a Good Thing(tm) I also added a new section about maintainers, trying to highlight which one might need a hand in fixing a large number of open bug reports, and those that have not touched CVS in a long while, maybe indicating that they have "disappeared" and their packages become orphaned... Cheers, Christian From paul at all-the-johnsons.co.uk Wed Feb 22 15:58:41 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Wed, 22 Feb 2006 15:58:41 +0000 Subject: FE Package Status of Feb 22, 2006 In-Reply-To: <200602221551.k1MFprOL025273@ludwig-alpha.unil.ch> References: <200602221551.k1MFprOL025273@ludwig-alpha.unil.ch> Message-ID: <1140623921.31392.36.camel@mrwibble.mrwobble> Hi, On Wed, 2006-02-22 at 16:51 +0100, Christian.Iseli at licr.org wrote: > FE Package Status of Feb 22, 2006 > paul at all-the-johnsons dot co dot uk z88dk This was rebuilt last night. It should be in the i386 and ppc directories (it won't build under x86_64) TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From rdieter at math.unl.edu Wed Feb 22 16:04:48 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 22 Feb 2006 10:04:48 -0600 Subject: Orphaned kdetoys Message-ID: I see on http://fedoraproject.org/wiki/Extras/OrphanedPackages in section "Packages removed from Fedora Core 4 not yet imported into Extras" that kdetoys is listed. I'd be happy to import/maintain kdetoys. What's policy pertaining to this? Since the dropped version is pretty old, simply importing the version as dropped doesn't make much sense. Is a (formal) Review required a new/current version? -- Rex From rc040203 at freenet.de Wed Feb 22 16:11:17 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 22 Feb 2006 17:11:17 +0100 Subject: Specifying arch in BuildRequires: In-Reply-To: References: <43FA9B74.30606@redhat.com> <1140535185.14289.71.camel@mccallum.corsepiu.local> <1140537283.14289.84.camel@mccallum.corsepiu.local> <1140588449.14289.116.camel@mccallum.corsepiu.local> Message-ID: <1140624677.14289.153.camel@mccallum.corsepiu.local> On Wed, 2006-02-22 at 08:30 -0600, Jason L Tibbitts III wrote: > >>>>> "RC" == Ralf Corsepius writes: > > RC> Could you upload the *.x86_64.rpm binary rpms? > > Sure; they're in http://www.math.uh.edu/~tibbs/rpms/gpc/. > Unfortunately I have no FC4 x86_64 boxes running yet, so I have a > tough time actually testing the builds. My suspicion was right: The rpm contains this: /usr/lib64/gpc/x86_64-redhat-linux/3.4.5/ which should be /usr/lib/gpc/x86_64-redhat-linux/3.4.5/ C.f. gcc package, which contains this: /usr/lib/gcc/x86_64-redhat-linux/4.1.0/ So you probably need to configure with --libdir=%{_lib} or may-be --libdir=%{_prefix}/lib Ralf From dennis at ausil.us Wed Feb 22 16:12:23 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 22 Feb 2006 10:12:23 -0600 Subject: Orphaned kdetoys In-Reply-To: References: Message-ID: <200602221012.23758.dennis@ausil.us> On Wednesday 22 February 2006 10:04, Rex Dieter wrote: > I see on > http://fedoraproject.org/wiki/Extras/OrphanedPackages > in section > "Packages removed from Fedora Core 4 not yet imported into Extras" > that kdetoys is listed. > > I'd be happy to import/maintain kdetoys. > > What's policy pertaining to this? > > Since the dropped version is pretty old, simply importing the version as > dropped doesn't make much sense. Is a (formal) Review required a > new/current version? > > -- Rex the policy changed awhile ago. all new packages must be reviewed, even those coming from core -- Regards Dennis Gilmore, RHCE Proud Australian From paul at all-the-johnsons.co.uk Wed Feb 22 16:16:12 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Wed, 22 Feb 2006 16:16:12 +0000 Subject: Orphaned kdetoys In-Reply-To: References: Message-ID: <1140624972.31392.39.camel@mrwibble.mrwobble> Hi, > What's policy pertaining to this? > > Since the dropped version is pretty old, simply importing the version as > dropped doesn't make much sense. Is a (formal) Review required a > new/current version? You've announced your intent. Wait for any objections (I normally give it 24 hours), if no one moans, go for it. AIUI, if there is a big change (say from anjuta-1.2.4 to anjuta-2 which has many changes internally and for dependencies), it should go through a review. If it's just a bump (say 1.6 to 1.7), you should be good to go. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From tibbs at math.uh.edu Wed Feb 22 16:16:35 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 22 Feb 2006 10:16:35 -0600 Subject: Odd "Fedora Exrras" bugzilla product Message-ID: I noticed a product "Fedora Exrras" is showing up in bugzilla; the only component there is perl-Gmone2-Canvas. I traced this to a typo in the owners.list file which I corrected. Will the component go away automatically? - J< From bugzilla at redhat.com Wed Feb 22 16:31:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 11:31:52 -0500 Subject: [Bug 182440] New: Review Request: fcgi - High-performance Fast CGI engine Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182440 Summary: Review Request: fcgi - High-performance Fast CGI engine Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: icon at fedoraproject.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://blues.mcgill.ca/~icon/fe/fcgi.spec SRPM Name or Url: http://blues.mcgill.ca/~icon/fe/fcgi-2.4.0-1.src.rpm Description: FastCGI is a language independent, scalable, open extension to CGI that provides high performance without the limitations of server specific APIs. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 16:40:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 11:40:30 -0500 Subject: [Bug 165666] Review Request: Graph Visualization Tools In-Reply-To: Message-ID: <200602221640.k1MGeUpr020416@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Graph Visualization Tools https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165666 Bug 165666 depends on bug 163840, which changed state. Bug 163840 Summary: RFE Upgrade to graphviz-2.4, add graphviz-cairo-2.4 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163840 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NOTABUG Status|NEW |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rdieter at math.unl.edu Wed Feb 22 16:47:36 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 22 Feb 2006 10:47:36 -0600 Subject: Orphaned kdetoys In-Reply-To: <200602221012.23758.dennis@ausil.us> References: <200602221012.23758.dennis@ausil.us> Message-ID: Dennis Gilmore wrote: > On Wednesday 22 February 2006 10:04, Rex Dieter wrote: > >>I see on >>http://fedoraproject.org/wiki/Extras/OrphanedPackages >>in section >>"Packages removed from Fedora Core 4 not yet imported into Extras" >>that kdetoys is listed. >> >>I'd be happy to import/maintain kdetoys. >> Is a (formal) Review required a new/current version? > the policy changed awhile ago. all new packages must be reviewed, even those > coming from core WORKSFORME. I'll go whip something up. -- Rex From bugzilla at redhat.com Wed Feb 22 17:00:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 12:00:52 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602221700.k1MH0qpR024540@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 ------- Additional Comments From tibbs at math.uh.edu 2006-02-22 12:00 EST ------- Umm, I was in the process of reviewing this. Why did it get closed? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 17:07:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 12:07:27 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602221707.k1MH7RGg025579@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 ------- Additional Comments From folkert at vanheusden.com 2006-02-22 12:07 EST ------- I have no idea. Should I resubmit it? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 17:13:26 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 12:13:26 -0500 Subject: [Bug 175438] Review Request: smart -- Next generation package handling tool In-Reply-To: Message-ID: <200602221713.k1MHDQAP026696@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: smart -- Next generation package handling tool https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175438 alexl at users.sourceforge.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexl at users.sourceforge.net ------- Additional Comments From alexl at users.sourceforge.net 2006-02-22 12:13 EST ------- Anyone else willing to take up the review now that Ville has resigned (comment #64)? (I'm not an official contributor yet, so I can't). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 22 17:14:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 12:14:56 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602221714.k1MHEu3A026988@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From jvdias at redhat.com 2006-02-22 12:14 EST ------- RE: > Sorry! You were supposed to get help about: > orterun:proc-aborted This was caused by the wrong installation location for the help*.txt files - they now live in /usr/share/openmpi/help/openmpi, and the 'pkgdatadir' configuration option tells the libraries where to find them. Another problem was with the libmpi shared libraries - these used to live in /usr/lib/libmpi* . Having lam and openmpi both install /etc/ld.so.conf.d/*.conf files meant that the LAM libmpi* libraries were always resolved first - ('l' precedes 'o' alphabetically) . Now, both lam-7.1.1-11+ and openmpi own a '%ghost' file /etc/ld.so.conf.d/mpi.conf , which is created as a link to either /usr/share/{lam,openmpi}/ld.conf during the '%post' script of both RPMs only if it does not already exist. openmpi's /usr/sbin/mpi_alternatives now makes /etc/ld.so.conf.d/mpi.conf the primary alternative: $ mpi_alternatives display mpi - status is manual. link currently points to /usr/share/openmpi/ld.conf /usr/share/openmpi/ld.conf - priority 50 slave mpiCC: /usr/bin/om-mpic++ slave mpic++: /usr/bin/om-mpic++ slave mpicc: /usr/bin/om-mpicc slave mpiexec: /usr/bin/om-mpiexec slave mpif77: /usr/bin/om-mpif77 slave mpirun: /usr/bin/om-mpirun /usr/share/lam/ld.conf - priority 50 slave mpiCC: /usr/bin/lam-mpic++ slave mpic++: /usr/bin/lam-mpic++ slave mpicc: /usr/bin/lam-mpicc slave mpiexec: /usr/bin/lam-mpiexec slave mpif77: /usr/bin/lam-mpif77 slave mpirun: /usr/bin/lam-mpirun Current `best version is /usr/share/openmpi/ld.conf. I've uploaded the new openmpi-1.0.1-1.fe5 and lam-7.1.1-11 RPMs to http://people.redhat.com/~jvdias/openmpi . Unless there are any objections, I'll import openmpi-1.0.1-1.fe5 into FC5 Extras tomorrow. Please try out the new RPMs - thanks! -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From gauret at free.fr Wed Feb 22 17:23:03 2006 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 22 Feb 2006 18:23:03 +0100 Subject: Orphaned: elmo Message-ID: Hello all I'm orphaning "elmo", a text-based mail reader, which segfaults in FC4, and is dead upstream. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179239 for more info. Feel free to claim it, but be prepared for heavy patching. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Never test for an error condition you don't know how to handle." -- Steinbach's Guideline for Systems Programming From bugzilla at redhat.com Wed Feb 22 17:23:06 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 12:23:06 -0500 Subject: [Bug 166255] Review Request: Sprog In-Reply-To: Message-ID: <200602221723.k1MHN6TW028789@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Sprog https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166255 alexl at users.sourceforge.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexl at users.sourceforge.net ------- Additional Comments From alexl at users.sourceforge.net 2006-02-22 12:22 EST ------- I tried installing Sprog for FC-4 from here: http://www.perl.me.uk/downloads/modules/Sprog-0.14-4.noarch.rpm just for kicks, just to see if the appropriate requires would be pulled in from FE on FC-4, and I found that perl-Gnome2-Canvas perl-Imager perl-GTK2-GladeXML have not yet been built for FC-4, although they all _do_ have branches for FC-4 in CVS (and hence work in devel). While you are waiting for the sprog FC-4 branch to be created, perhaps these deps can be built for FC-4 just to make sure it will work. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugs.michael at gmx.net Wed Feb 22 17:30:59 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 22 Feb 2006 18:30:59 +0100 Subject: Anjuta - change of maintainer In-Reply-To: <1140622767.31392.33.camel@mrwibble.mrwobble> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602201500w25dcc9dcp3ba8f1db893e7f7a@mail.gmail.com> <1140476701.2971.3.camel@T7.Linux> <13dbfe4f0602201520v21ee0d3br46b04df50eea092b@mail.gmail.com> <1140477835.2971.5.camel@T7.Linux> <13dbfe4f0602211544g643afe6ev3dd6b3419c3e1f6c@mail.gmail.com> <1140565626.31940.14.camel@T7.Linux> <13dbfe4f0602220604l1f30f6b6w1511f42ad780fa89@mail.gmail.com> <1140622767.31392.33.camel@mrwibble.mrwobble> Message-ID: <20060222183059.32178be3.bugs.michael@gmx.net> On Wed, 22 Feb 2006 15:39:26 +0000, Paul F. Johnson wrote: > Hi, > > > strange buildsys says this is an update > > but with yum install anjuta* Im having > > > > anjuta i386 1:1.2.3-3.fc5 extras-development 2.6 M > > Can't explain that unless the mirror you're using hasn't updated I can explain it. You dropped "Epoch: 1", which is a big DO_NOT! Your package now is older than 1:1.2.3-3.fc5 From mmcgrath at fedoraproject.org Wed Feb 22 17:32:14 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 22 Feb 2006 11:32:14 -0600 Subject: Orphaned: elmo In-Reply-To: References: Message-ID: <3237e4410602220932g71785843n9f5df8903a90f60a@mail.gmail.com> On 2/22/06, Aurelien Bompard wrote: > Hello all > > I'm orphaning "elmo", a text-based mail reader, which segfaults in FC4, and > is dead upstream. > See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179239 for more > info. > > Feel free to claim it, but be prepared for heavy patching. > > Aur?lien > -- > http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr > "Never test for an error condition you don't know how to > handle." -- Steinbach's Guideline for Systems Programming > > Poor elmo :-( Just curious, do we have a procedure in place to remove it from extras if no one takes it up after a certain amount of time? -Mike From fedora at leemhuis.info Wed Feb 22 17:40:35 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 22 Feb 2006 18:40:35 +0100 Subject: Orphaned: elmo In-Reply-To: References: Message-ID: <1140630035.4192.14.camel@localhost.localdomain> Am Mittwoch, den 22.02.2006, 18:23 +0100 schrieb Aurelien Bompard: > I'm orphaning "elmo", a text-based mail reader, which segfaults in FC4, and > is dead upstream. > See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179239 for more > info. > > Feel free to claim it, but be prepared for heavy patching. In case no one steps up: Should we remove it from extras/devel before we branch for FE5? Sound like a good idea if it also segfaults in FC5. Somebody probably should look at the other orphans in extras/devel and check if there are other packages that are heavily broken. Removing those is probably better then leaving them around for longer. I'm still for the "remove *all* orphans from the repo before branching FE5 if there is nothing that depends on them" solution... CU thl -- Thorsten Leemhuis From gauret at free.fr Wed Feb 22 17:41:37 2006 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 22 Feb 2006 18:41:37 +0100 Subject: Orphaned: elmo References: <1140630035.4192.14.camel@localhost.localdomain> Message-ID: Thorsten Leemhuis wrote: > In case no one steps up: Should we remove it from extras/devel before we > branch for FE5? Sound like a good idea if it also segfaults in FC5. +1 Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours ; and this we should do freely and generously." -- Benjamin Franklin From dcbw at redhat.com Wed Feb 22 17:44:01 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 22 Feb 2006 12:44:01 -0500 Subject: FC-4 Extras buildsystem breakage details Message-ID: <1140630242.18225.10.camel@localhost.localdomain> Hi, Some of you have noticed and pointed out the fact that the FC-4 Extras target wasn't successfully building any packages and wasn't giving much failure information. So after a bit of detective work this morning we've figured out that: 1) boa, which provides "webserver", is the immediate culprit of the breakage because it does not hardcode its UID for /usr/sbin/useradd. This leads useradd to select its first default of 100 for the UID, which is a direct conflict with mock, which hardcodes 100. It's unclear if mock should use a different UID or not. 2) dap-server, which appeared on 20-Feb-2006 around when the problems started, is the real culprit. dap-server requires webserver, which pulls in 'boa' because it has the shortest package name of those packages which provide 'webserver'. dap-server is getting pulled into all buildroots because it mistakenly provides built-in versions of perl-HTML-Parser modules 3) plague-builder appears to be dropping output from mock that's printed to stderr, causing the real error message not to appear in the logs To correct the problem, dap-server has been temporarily removed from Extras repositories, since it even blocks rebuilds of a fixed dap-server itself. When the buildsystem local repository rsyncs the new repo data down, dap-server will be rebuilt and builds on the fc-4 target should be able to continue as normal. We should also start up a discussion about how to prevent problems of this nature in the future. We would not have noticed the problem had boa not been conflicting with mock, but the real issue of dap-server providing perl-HTML-Parser modules itself would still have been a problem, albeit a silent one. If there are scripts, rules, and/or pre-submit checks which could be performed at various stages, it might go a long way towards prevent this sort of breakage in the future. Dan From bugzilla at redhat.com Wed Feb 22 17:45:24 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 12:45:24 -0500 Subject: [Bug 166255] Review Request: Sprog In-Reply-To: Message-ID: <200602221745.k1MHjOYk002006@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Sprog https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166255 ------- Additional Comments From alexl at users.sourceforge.net 2006-02-22 12:45 EST ------- (In reply to comment #22) > While you are waiting for the sprog FC-4 branch to be created, perhaps > these deps can be built for FC-4 just to make sure it will work. bug #182455, bug #182458, bug #182459 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From gauret at free.fr Wed Feb 22 17:42:33 2006 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 22 Feb 2006 18:42:33 +0100 Subject: Orphaned: elmo References: <3237e4410602220932g71785843n9f5df8903a90f60a@mail.gmail.com> Message-ID: Mike McGrath wrote: > Poor elmo :-( Just curious, do we have a procedure in place to remove > it from extras if no one takes it up after a certain amount of time? There is http://fedoraproject.org/wiki/Extras/FC4Status Aur?lien -- http://aurelien.bompard.org ~~~~ 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 nicolas.mailhot at laposte.net Wed Feb 22 17:55:28 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 22 Feb 2006 18:55:28 +0100 Subject: Orphaned: elmo In-Reply-To: <1140630035.4192.14.camel@localhost.localdomain> References: <1140630035.4192.14.camel@localhost.localdomain> Message-ID: <1140630928.22535.5.camel@rousalka.dyndns.org> Le mercredi 22 f?vrier 2006 ? 18:40 +0100, Thorsten Leemhuis a ?crit : > I'm still for the "remove *all* orphans from the repo before branching > FE5 if there is nothing that depends on them" solution... Some orphans are in pretty good shape though - for example I worked with upstream to fix remaining problems before releasing arc -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From bugzilla at redhat.com Wed Feb 22 17:53:41 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 12:53:41 -0500 Subject: [Bug 175631] Review Request: fedora-package-config-smart - Configuration files for the smart package manager In-Reply-To: Message-ID: <200602221753.k1MHrf5L003410@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: fedora-package-config-smart - Configuration files for the smart package manager https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175631 Jochen at herr-schmitt.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|DUPLICATE | BugsThisDependsOn|175630 |16378 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-22 12:53 EST ------- Good: + rpmlint to srpm ok. + Local build worked fine. Bad: - rpmlint for rpms complaints: rpmlint smart-0.40-23.i686.rpm W: smart conffile-without-noreplace-flag /etc/pam.d/smart-root W: smart conffile-without-noreplace-flag /etc/security/console.apps/smart-root rpmlint smart-gui-0.40-23.i686.rpm W: smart-gui no-documentation rpmlint smart-update-0.40-23.i686.rpm W: smart-update no-documentation - BuildRoot should be %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) ? Encoding should be UTF-8 - New upstream release is available. I have reopen this bug, becouse its was accidently closed. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From skvidal at linux.duke.edu Wed Feb 22 18:01:57 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 22 Feb 2006 13:01:57 -0500 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140630242.18225.10.camel@localhost.localdomain> References: <1140630242.18225.10.camel@localhost.localdomain> Message-ID: <1140631317.3959.21.camel@cutter> > 1) boa, which provides "webserver", is the immediate culprit of the > breakage because it does not hardcode its UID for /usr/sbin/useradd. > This leads useradd to select its first default of 100 for the UID, which > is a direct conflict with mock, which hardcodes 100. It's unclear if > mock should use a different UID or not. I'm open to mock making a different uid in the chroot. iirc - it's just the builder user that's uid 100. changing that to some arbitrarily large number should not negatively impact it. -sv From bugzilla at redhat.com Wed Feb 22 17:57:03 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 12:57:03 -0500 Subject: [Bug 174440] Review Request: bakery - C++ framework for creating GNOME apps In-Reply-To: Message-ID: <200602221757.k1MHv3wf004218@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: bakery - C++ framework for creating GNOME apps https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174440 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-22 12:56 EST ------- God: + rpmlint of srpm ok. + Local build worked fine. Bad: - rpmlint of rpms complaints: rpmlint bakery-2.3.15-2.i686.rpm W: bakery incoherent-version-in-changelog 2.3.15-1 2.3.15-2 rpmlint bakery-devel-2.3.15-2.i686.rpm W: bakery-devel doc-file-dependency /usr/share/doc/bakery-devel-2.3.15/reference/html/installdox /usr/bin/perl - Requires to /sbin/ldconfig are not requires. - Requires to perl missing. - Mock build failed: checking pkg-config is at least version 0.9.0... yes checking for BAKERY_CFLAGS... checking for BAKERY_LIBS... configure: error: Package requirements (gtkmm-2.4 >= 2.6.0 gconfmm-2.6 >= 2.6.0 libglademm-2.4 >= 2.4.0 libxml++-2.6 >= 2.8.0 gnome-vfsmm-2.6 >= 2.6.0) were not met. Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively you may set the BAKERY_CFLAGS and BAKERY_LIBS environment variable s to avoid the need to call pkg-config. See the pkg-config man page for more details. error: Bad exit status from /var/tmp/rpm-tmp.97468 (%build) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From fedora at leemhuis.info Wed Feb 22 18:14:23 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 22 Feb 2006 19:14:23 +0100 Subject: Orphaned: elmo In-Reply-To: <1140630928.22535.5.camel@rousalka.dyndns.org> References: <1140630035.4192.14.camel@localhost.localdomain> <1140630928.22535.5.camel@rousalka.dyndns.org> Message-ID: <1140632063.4192.26.camel@localhost.localdomain> Am Mittwoch, den 22.02.2006, 18:55 +0100 schrieb Nicolas Mailhot: > Le mercredi 22 f?vrier 2006 ? 18:40 +0100, Thorsten Leemhuis a ?crit : > > > I'm still for the "remove *all* orphans from the repo before branching > > FE5 if there is nothing that depends on them" solution... > > Some orphans are in pretty good shape though - for example I worked with > upstream to fix remaining problems before releasing arc Well, I fine if those that are in a relative good shape stay. But somebody probably should check which orphans are in a good shape and which are not. Any volunteers? Shouldn't be to much work afaics. But the biggest problem remains: What happens if a "good shape" orphan needs a security fix during lifetime of FE5? ** CU thl ** Well, a Security SIG is in the works afaics. But they can't maintain all orphans forever. So we probably need to remove them sooner of later from devel (e.g. in this case after branching for FE5) -- maybe this way a new maintainer shows up... -- Thorsten Leemhuis From bugzilla at redhat.com Wed Feb 22 18:10:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 13:10:27 -0500 Subject: [Bug 166255] Review Request: Sprog In-Reply-To: Message-ID: <200602221810.k1MIARbt007221@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Sprog https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166255 ------- Additional Comments From jspaleta at gmail.com 2006-02-22 13:10 EST ------- wtf.. can we PLEASE not overload this initial review bugreport concerning requests to build the fc4 branch. requests for fc4 branch builds should not block initial review request report resolution. as soon as sprog is built in devel.. this bug is going to be closed.. regardless.. of what the blocker status is concerning fc4 branch request. Because as a reviewer who has taken on assignment for this bug this is outside the scope of what the review request bug covers. -jef -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 22 18:20:51 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 13:20:51 -0500 Subject: [Bug 166255] Review Request: Sprog In-Reply-To: Message-ID: <200602221820.k1MIKphS009462@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Sprog https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166255 ------- Additional Comments From alexl at users.sourceforge.net 2006-02-22 13:20 EST ------- (In reply to comment #24) > as soon as sprog is built in devel.. this bug is going to be closed.. > regardless.. of what the blocker status is concerning fc4 branch request. > Because as a reviewer who has taken on assignment for this bug this is outside > the scope of what the review request bug covers. Sprog's been built. Waiting for being signed and pushed. Sorry for the noise, I didn't realise that Sprog bugzilla component had already been created. I've created a bug now: bug #182461. I've opened up bugs on dependent package, but I didn't make them blockers on this one, I'll switch them to above. ;-) That's the last from me. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From chitlesh at fedoraproject.org Wed Feb 22 18:03:49 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 22 Feb 2006 19:03:49 +0100 Subject: Anjuta - change of maintainer In-Reply-To: <20060222183059.32178be3.bugs.michael@gmx.net> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602201500w25dcc9dcp3ba8f1db893e7f7a@mail.gmail.com> <1140476701.2971.3.camel@T7.Linux> <13dbfe4f0602201520v21ee0d3br46b04df50eea092b@mail.gmail.com> <1140477835.2971.5.camel@T7.Linux> <13dbfe4f0602211544g643afe6ev3dd6b3419c3e1f6c@mail.gmail.com> <1140565626.31940.14.camel@T7.Linux> <13dbfe4f0602220604l1f30f6b6w1511f42ad780fa89@mail.gmail.com> <1140622767.31392.33.camel@mrwibble.mrwobble> <20060222183059.32178be3.bugs.michael@gmx.net> Message-ID: <13dbfe4f0602221003l463d483fp99ed352b8f5d189d@mail.gmail.com> > I can explain it. You dropped "Epoch: 1", which is a big DO_NOT! > Your package now is older than 1:1.2.3-3.fc5 what do you mean? -- http://clunixchit.blogspot.com From bugzilla at redhat.com Wed Feb 22 18:29:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 13:29:02 -0500 Subject: [Bug 176021] Review Request: bwidget - extended widget set for Tcl/Tk In-Reply-To: Message-ID: <200602221829.k1MIT2lw012125@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: bwidget - extended widget set for Tcl/Tk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176021 wart at kobold.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From wart at kobold.org 2006-02-22 13:28 EST ------- Imported and built on devel. Thanks! -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 22 18:29:24 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 13:29:24 -0500 Subject: [Bug 174268] Review Request: itcl-iwidgets - object oriented megawidgets for Tcl In-Reply-To: Message-ID: <200602221829.k1MITOXv012265@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: itcl-iwidgets - object oriented megawidgets for Tcl https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174268 ------- Additional Comments From wart at kobold.org 2006-02-22 13:29 EST ------- Imported and built on devel. Thanks! -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 22 18:31:25 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 13:31:25 -0500 Subject: [Bug 176579] Review Request: ipsvd -- Internet protocol service daemons In-Reply-To: Message-ID: <200602221831.k1MIVPCS012989@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ipsvd -- Internet protocol service daemons https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176579 Jochen at herr-schmitt.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |Jochen at herr-schmitt.de OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-22 13:31 EST ------- Good: + rpmlint of srpm fine. + Local build worked fine. + Mock build worked fine. Bad: - rpmlint of binaries rpm complaints: rpmlint ipsvd-0.11.1-0.4.i686.rpm E: ipsvd statically-linked-binary /usr/bin/ipsvd-cdb E: ipsvd statically-linked-binary /usr/bin/tcpsvd E: ipsvd statically-linked-binary /usr/bin/udpsvd question: ? I think a build without the dietlibc will be a better solution. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 22 18:35:41 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 13:35:41 -0500 Subject: [Bug 182440] Review Request: fcgi - High-performance Fast CGI engine In-Reply-To: Message-ID: <200602221835.k1MIZfRP014325@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: fcgi - High-performance Fast CGI engine https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182440 ------- Additional Comments From paul at city-fan.org 2006-02-22 13:35 EST ------- Is this really BSD-ish? Doesn't look very free to me: Open Market permits you to use, copy, modify, distribute, and license this Software and the Documentation solely for the purpose of implementing the FastCGI specification defined by Open Market or derivative specifications publicly endorsed by Open Market and promulgated by an open standards organization and for no other purpose, provided that existing copyright notices are retained in all copies and that this notice is included verbatim in any distributions. No written agreement, license, or royalty fee is required for any of the authorized uses. Modifications to this Software and Documentation may be copyrighted by their authors and need not follow the licensing terms described here, but the modified Software and Documentation must be used for the sole purpose of implementing the FastCGI specification defined by Open Market or derivative specifications publicly endorsed by Open Market and promulgated by an open standards organization and for no other purpose. If modifications to this Software and Documentation have new licensing terms, the new terms must protect Open Market's proprietary rights in the Software and Documentation to the same extent as these licensing terms and must be clearly indicated on the first page of each file where they apply. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 18:37:38 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 13:37:38 -0500 Subject: [Bug 176579] Review Request: ipsvd -- Internet protocol service daemons In-Reply-To: Message-ID: <200602221837.k1MIbcTf014920@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ipsvd -- Internet protocol service daemons https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176579 ------- Additional Comments From enrico.scholz at informatik.tu-chemnitz.de 2006-02-22 13:37 EST ------- No, this kind of packages is designed for dietlibc. Linking with glibc does not make sense there. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From paul at city-fan.org Wed Feb 22 18:45:55 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 22 Feb 2006 18:45:55 +0000 Subject: Anjuta - change of maintainer In-Reply-To: <13dbfe4f0602221003l463d483fp99ed352b8f5d189d@mail.gmail.com> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602201500w25dcc9dcp3ba8f1db893e7f7a@mail.gmail.com> <1140476701.2971.3.camel@T7.Linux> <13dbfe4f0602201520v21ee0d3br46b04df50eea092b@mail.gmail.com> <1140477835.2971.5.camel@T7.Linux> <13dbfe4f0602211544g643afe6ev3dd6b3419c3e1f6c@mail.gmail.com> <1140565626.31940.14.camel@T7.Linux> <13dbfe4f0602220604l1f30f6b6w1511f42ad780fa89@mail.gmail.com> <1140622767.31392.33.camel@mrwibble.mrwobble> <20060222183059.32178be3.bugs.michael@gmx.net> <13dbfe4f0602221003l463d483fp99ed352b8f5d189d@mail.gmail.com> Message-ID: <43FCB163.3070605@city-fan.org> Chitlesh GOORAH wrote: >>I can explain it. You dropped "Epoch: 1", which is a big DO_NOT! >>Your package now is older than 1:1.2.3-3.fc5 > > > what do you mean? Sounds to me like a previous version of the package in the repo had "Epoch: 1" in it, and the current one doesn't (effectively implying "Epoch: 0") and hence being "older" than the previous version as far as RPM and yum are concerned. Paul.. From bugzilla at redhat.com Wed Feb 22 18:49:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 13:49:07 -0500 Subject: [Bug 182463] New: Review Request: cairomm (C++ bindings for cairo) Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182463 Summary: Review Request: cairomm (C++ bindings for cairo) Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: rvinyard at cs.nmsu.edu QAContact: fedora-extras-list at redhat.com This is my first package and I need a sponsor. Spec Name or Url: http://miskatonic.cs.nmsu.edu/pub/cairomm.spec SRPM Name or Url: http://miskatonic.cs.nmsu.edu/pub/fedora/4/srpms/cairomm-0.5.0-3.20060222cvs.src.rpm Description: C++ bindings for cairo; the current spec and srpm are a pre-release from CVS and should comply with the pre-release versioning specs. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 18:58:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 13:58:09 -0500 Subject: [Bug 177211] Review Request: newsx - NNTP news exchange utility In-Reply-To: Message-ID: <200602221858.k1MIw9ik020311@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: newsx - NNTP news exchange utility https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177211 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-22 13:57 EST ------- God: + rpm for srpm worked fine. + Local build worked fine. Bad: - rpmlint binary rpm complaints: rpmlint newsx-1.6-1.i686.rpm E: newsx non-standard-dir-perm /var/spool/news/inhosts 0770 - Please use %{?dist} in Release tag. - Mock build failed. Unfortunately I have not the rights to sponsor you. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 22 19:05:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 14:05:52 -0500 Subject: [Bug 176579] Review Request: ipsvd -- Internet protocol service daemons In-Reply-To: Message-ID: <200602221905.k1MJ5qWQ021978@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ipsvd -- Internet protocol service daemons https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176579 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-22 14:05 EST ------- Another question, is there any hard requirement for staticly linking? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From chitlesh at fedoraproject.org Wed Feb 22 19:13:19 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 22 Feb 2006 20:13:19 +0100 Subject: Anjuta - change of maintainer In-Reply-To: <43FCB163.3070605@city-fan.org> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602201520v21ee0d3br46b04df50eea092b@mail.gmail.com> <1140477835.2971.5.camel@T7.Linux> <13dbfe4f0602211544g643afe6ev3dd6b3419c3e1f6c@mail.gmail.com> <1140565626.31940.14.camel@T7.Linux> <13dbfe4f0602220604l1f30f6b6w1511f42ad780fa89@mail.gmail.com> <1140622767.31392.33.camel@mrwibble.mrwobble> <20060222183059.32178be3.bugs.michael@gmx.net> <13dbfe4f0602221003l463d483fp99ed352b8f5d189d@mail.gmail.com> <43FCB163.3070605@city-fan.org> Message-ID: <13dbfe4f0602221113w119f7a89x415a349fba2ebce6@mail.gmail.com> > Sounds to me like a previous version of the package in the repo had > "Epoch: 1" in it, and the current one doesn't (effectively implying > "Epoch: 0") and hence being "older" than the previous version as far as > RPM and yum are concerned. > > Paul.. so what should I do or what should you do? -- http://clunixchit.blogspot.com From paul at city-fan.org Wed Feb 22 19:15:21 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 22 Feb 2006 19:15:21 +0000 Subject: Anjuta - change of maintainer In-Reply-To: <13dbfe4f0602221113w119f7a89x415a349fba2ebce6@mail.gmail.com> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602201520v21ee0d3br46b04df50eea092b@mail.gmail.com> <1140477835.2971.5.camel@T7.Linux> <13dbfe4f0602211544g643afe6ev3dd6b3419c3e1f6c@mail.gmail.com> <1140565626.31940.14.camel@T7.Linux> <13dbfe4f0602220604l1f30f6b6w1511f42ad780fa89@mail.gmail.com> <1140622767.31392.33.camel@mrwibble.mrwobble> <20060222183059.32178be3.bugs.michael@gmx.net> <13dbfe4f0602221003l463d483fp99ed352b8f5d189d@mail.gmail.com> <43FCB163.3070605@city-fan.org> <13dbfe4f0602221113w119f7a89x415a349fba2ebce6@mail.gmail.com> Message-ID: <43FCB849.2050004@city-fan.org> Chitlesh GOORAH wrote: >>Sounds to me like a previous version of the package in the repo had >>"Epoch: 1" in it, and the current one doesn't (effectively implying >>"Epoch: 0") and hence being "older" than the previous version as far as >>RPM and yum are concerned. >> >>Paul.. > > > so what should I do or what should you do? The anjuta package needs to have "Epoch: 1" or greater forever more. Paul (not the Paul that is maintaining the anjuta package). From chitlesh at fedoraproject.org Wed Feb 22 19:19:08 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 22 Feb 2006 20:19:08 +0100 Subject: Anjuta - change of maintainer In-Reply-To: <43FCB849.2050004@city-fan.org> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602211544g643afe6ev3dd6b3419c3e1f6c@mail.gmail.com> <1140565626.31940.14.camel@T7.Linux> <13dbfe4f0602220604l1f30f6b6w1511f42ad780fa89@mail.gmail.com> <1140622767.31392.33.camel@mrwibble.mrwobble> <20060222183059.32178be3.bugs.michael@gmx.net> <13dbfe4f0602221003l463d483fp99ed352b8f5d189d@mail.gmail.com> <43FCB163.3070605@city-fan.org> <13dbfe4f0602221113w119f7a89x415a349fba2ebce6@mail.gmail.com> <43FCB849.2050004@city-fan.org> Message-ID: <13dbfe4f0602221119h7e190d4dq81dd01c46eb8385d@mail.gmail.com> > The anjuta package needs to have "Epoch: 1" or greater forever more. > > Paul (not the Paul that is maintaining the anjuta package). > Paul, The Maintainer, you know what to do :) -- http://clunixchit.blogspot.com From bugzilla at redhat.com Wed Feb 22 19:15:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 14:15:16 -0500 Subject: [Bug 182440] Review Request: fcgi - High-performance Fast CGI engine In-Reply-To: Message-ID: <200602221915.k1MJFGEv024362@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: fcgi - High-performance Fast CGI engine https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182440 ------- Additional Comments From icon at fedoraproject.org 2006-02-22 14:15 EST ------- Where did you get that? LICENSE.TERMS shipping with the tarball is: --- This FastCGI application library source and object code (the "Software") and its documentation (the "Documentation") are copyrighted by Open Market, Inc ("Open Market"). The following terms apply to all files associated with the Software and Documentation unless explicitly disclaimed in individual files. Open Market permits you to use, copy, modify, distribute, and license this Software and the Documentation for any purpose, provided that existing copyright notices are retained in all copies and that this notice is included verbatim in any distributions. No written agreement, license, or royalty fee is required for any of the authorized uses. Modifications to this Software and Documentation may be copyrighted by their authors and need not follow the licensing terms described here. If modifications to this Software and Documentation have new licensing terms, the new terms must be clearly indicated on the first page of each file where they apply. OPEN MARKET MAKES NO EXPRESS OR IMPLIED WARRANTY WITH RESPECT TO THE SOFTWARE OR THE DOCUMENTATION, INCLUDING WITHOUT LIMITATION ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL OPEN MARKET BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY DAMAGES ARISING FROM OR RELATING TO THIS SOFTWARE OR THE DOCUMENTATION, INCLUDING, WITHOUT LIMITATION, ANY INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES OR SIMILAR DAMAGES, INCLUDING LOST PROFITS OR LOST DATA, EVEN IF OPEN MARKET HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE SOFTWARE AND DOCUMENTATION ARE PROVIDED "AS IS". OPEN MARKET HAS NO LIABILITY IN CONTRACT, TORT, NEGLIGENCE OR OTHERWISE ARISING OUT OF THIS SOFTWARE OR THE DOCUMENTATION. --- This is more or less creative commons "by" clause. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 19:17:17 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 14:17:17 -0500 Subject: [Bug 176579] Review Request: ipsvd -- Internet protocol service daemons In-Reply-To: Message-ID: <200602221917.k1MJHHhQ024749@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ipsvd -- Internet protocol service daemons https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176579 ------- Additional Comments From enrico.scholz at informatik.tu-chemnitz.de 2006-02-22 14:17 EST ------- No; you have only soft benefits: static binaries are smaller, consum lesser memory and will be executed faster. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 22 19:18:17 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 14:18:17 -0500 Subject: [Bug 182440] Review Request: fcgi - High-performance Fast CGI engine In-Reply-To: Message-ID: <200602221918.k1MJIHYJ024913@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: fcgi - High-performance Fast CGI engine https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182440 ------- Additional Comments From paul at city-fan.org 2006-02-22 14:18 EST ------- (In reply to comment #2) > Where did you get that? LICENSE.TERMS shipping with the tarball is: (snip BSD-ish license) Curious. I got it from http://fastcgi.com/mod_fastcgi/docs/LICENSE.TERMS which I believed to be a copy of what was in the tarball. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 19:20:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 14:20:01 -0500 Subject: [Bug 182440] Review Request: fcgi - High-performance Fast CGI engine In-Reply-To: Message-ID: <200602221920.k1MJK1ib025237@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: fcgi - High-performance Fast CGI engine https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182440 ------- Additional Comments From icon at fedoraproject.org 2006-02-22 14:19 EST ------- Note the "mod_fastcgi" in the URL. :) You want: http://www.fastcgi.com/cvs/fcgi2/LICENSE.TERMS -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 19:31:00 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 14:31:00 -0500 Subject: [Bug 175631] Review Request: fedora-package-config-smart - Configuration files for the smart package manager In-Reply-To: Message-ID: <200602221931.k1MJV01r027495@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: fedora-package-config-smart - Configuration files for the smart package manager https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175631 ville.skytta at iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |CLOSED Resolution| |DUPLICATE BugsThisDependsOn|163778 | ------- Additional Comments From ville.skytta at iki.fi 2006-02-22 14:30 EST ------- It was not accidentally closed, this *is* a duplicate of bug 175473. *** This bug has been marked as a duplicate of 175473 *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 22 19:31:06 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 14:31:06 -0500 Subject: [Bug 175473] Review Request: smart-channel -- Specifications for smart channels In-Reply-To: Message-ID: <200602221931.k1MJV6HH027535@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: smart-channel -- Specifications for smart channels https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175473 ------- Additional Comments From ville.skytta at iki.fi 2006-02-22 14:31 EST ------- *** Bug 175631 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 22 19:31:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 14:31:53 -0500 Subject: [Bug 176579] Review Request: ipsvd -- Internet protocol service daemons In-Reply-To: Message-ID: <200602221931.k1MJVr6p027769@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ipsvd -- Internet protocol service daemons https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176579 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-22 14:31 EST ------- Sorry, from my point of view it's make no sense to use the dietlibc and link the binaires staticly. In an embeded environemt this may be okay, but you want inclussion your package into Fedora Extras a distributation which runs on desktops or servers. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 22 19:34:31 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 14:34:31 -0500 Subject: [Bug 176579] Review Request: ipsvd -- Internet protocol service daemons In-Reply-To: Message-ID: <200602221934.k1MJYVnl028448@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ipsvd -- Internet protocol service daemons https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176579 ------- Additional Comments From enrico.scholz at informatik.tu-chemnitz.de 2006-02-22 14:34 EST ------- dietlibc linked programs runs on desktops and servers too. It is not limited to embedded systems only. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 22 19:43:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 14:43:35 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602221943.k1MJhZZJ030969@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 ------- Additional Comments From tibbs at math.uh.edu 2006-02-22 14:43 EST ------- OK, the bug is repoened and back in shape. Now, onto the review: Release: should start at 1 and should include disttag. Don't set Vendor: in extras packages. Buildroot should include user ID. Requires: ncurses is not necessary; rpm will pick up the dependency. Suggest using %setup -q for a quieter build. Suggest fixing up line endings in HTML files to quiet rpmlint. Pass %{optflags} to make. Add the release to the most recent changelog entry. I will attach a patch to fix these and to put the spec more into line with the Extras template. I don't know what it hurts, but as in a previous comment, rpmlint complains about the permissions on the source tarball. I suggest changing the permisions on the tarball in the srpm to 0644. Please consider including the actual text of the license in your tarball. (The package submitter is supposed to bug upstream to do this, but you're the upstream so I guess I'm supposed to bug you.) Good stuff: After building with the patched spec, rpmlint is silent and the package builds in mock (development, i386 and x86_64). Source file matches upstream. License is appropriate and matches source. Fix up the above issues and I'll approve the package, or let me know what you disagree with and we'll figure something out. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From pertusus at free.fr Wed Feb 22 19:51:25 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 22 Feb 2006 20:51:25 +0100 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140630242.18225.10.camel@localhost.localdomain> References: <1140630242.18225.10.camel@localhost.localdomain> Message-ID: <20060222195124.GC2885@free.fr> > 2) dap-server, which appeared on 20-Feb-2006 around when the problems > started, is the real culprit. dap-server requires webserver, which > pulls in 'boa' because it has the shortest package name of those > packages which provide 'webserver'. dap-server is getting pulled into > all buildroots because it mistakenly provides built-in versions of > perl-HTML-Parser modules Oops... My bad :-(. In fact I noticed dap-server bundled an old version of HTML::Parser some time ago, I reported it upstream, and the maintainer agreed to remove it. However it crept in later, because the code doesn't work with the new HTML::Parser. I didn't thought about the issue a single second... > boa not been conflicting with mock, but the real issue of dap-server > providing perl-HTML-Parser modules itself would still have been a > problem, albeit a silent one. If there are scripts, rules, and/or In that case, as it doesn't really install HTML::Parser it may have been noticed at some point. But if the perl module is used in the base system, then it'll have screwed everything anyway. Sorry... It shows once more that providing an old code instead of using the system one is bad. -- Pat From bugs.michael at gmx.net Wed Feb 22 20:04:35 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 22 Feb 2006 21:04:35 +0100 Subject: Anjuta - change of maintainer In-Reply-To: <13dbfe4f0602221003l463d483fp99ed352b8f5d189d@mail.gmail.com> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602201500w25dcc9dcp3ba8f1db893e7f7a@mail.gmail.com> <1140476701.2971.3.camel@T7.Linux> <13dbfe4f0602201520v21ee0d3br46b04df50eea092b@mail.gmail.com> <1140477835.2971.5.camel@T7.Linux> <13dbfe4f0602211544g643afe6ev3dd6b3419c3e1f6c@mail.gmail.com> <1140565626.31940.14.camel@T7.Linux> <13dbfe4f0602220604l1f30f6b6w1511f42ad780fa89@mail.gmail.com> <1140622767.31392.33.camel@mrwibble.mrwobble> <20060222183059.32178be3.bugs.michael@gmx.net> <13dbfe4f0602221003l463d483fp99ed352b8f5d189d@mail.gmail.com> Message-ID: <20060222210435.20f0ea47.bugs.michael@gmx.net> On Wed, 22 Feb 2006 19:03:49 +0100, Chitlesh GOORAH wrote: > > I can explain it. You dropped "Epoch: 1", which is a big DO_NOT! > > Your package now is older than 1:1.2.3-3.fc5 > > what do you mean? A packaging bug. An important change in the package .spec file is not documented in the package %changelog. From ville.skytta at iki.fi Wed Feb 22 20:05:08 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 22 Feb 2006 22:05:08 +0200 Subject: tla (was: Re: FE Package Status of Feb 16, 2006) In-Reply-To: <43F94306.9010107@jdub.homelinux.org> References: <200602161627.k1GGRAOi020957@ludwig-alpha.unil.ch> <1140264009.2904.119.camel@localhost.localdomain> <20060218165448.30fbb45c.bugs.michael@gmx.net> <1140279924.6634.35.camel@localhost.localdomain> <20060218175756.4577d6f2.bugs.michael@gmx.net> <1140282817.6634.47.camel@localhost.localdomain> <20060218202347.2d064fe2.bugs.michael@gmx.net> <1140389692.12129.33.camel@bobcat.mine.nu> <43F94306.9010107@jdub.homelinux.org> Message-ID: <1140638708.8388.9.camel@bobcat.mine.nu> On Sun, 2006-02-19 at 22:18 -0600, Josh Boyer wrote: > Ville Skytt? wrote: > > > > I would like to see tla in Extras in the future as it's every now and > > then needed, but I'd rather stay away from grabbing official > > maintainership. 1.3.4 is out (released in January) and AFAICT the > > upstream project is alive again, with a new maintainer. Anyone? > > There was discussion of having dual maintainers in FE... wanna try it > out with this package? I'm willing to try it out.. Ok, let's do it. Go ahead and set yourself as the initial owner and add me to Cc in owners.list. (And let me know if you intend to push a FE5 rebuild of tla or if you'd like me to take care of it.) From ville.skytta at iki.fi Wed Feb 22 20:07:08 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 22 Feb 2006 22:07:08 +0200 Subject: Orphaned: elmo In-Reply-To: References: <3237e4410602220932g71785843n9f5df8903a90f60a@mail.gmail.com> Message-ID: <1140638828.8388.12.camel@bobcat.mine.nu> On Wed, 2006-02-22 at 18:42 +0100, Aurelien Bompard wrote: > Mike McGrath wrote: > > Poor elmo :-( Just curious, do we have a procedure in place to remove > > it from extras if no one takes it up after a certain amount of time? > > There is http://fedoraproject.org/wiki/Extras/FC4Status ...but pulling packages from repos for released distro versions is Not Good (tm). If it's broken beyond repair, I don't have better suggestions though. From bugzilla at redhat.com Wed Feb 22 20:06:19 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 15:06:19 -0500 Subject: [Bug 182463] Review Request: cairomm (C++ bindings for cairo) In-Reply-To: Message-ID: <200602222006.k1MK6JQL003598@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cairomm (C++ bindings for cairo) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182463 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-22 15:06 EST ------- Bad: - Locak build will not possible on FC-4 - Please give the full URL in the Source tag. - The BuildRoot must be cleaned at the beginning of %install - Please remove Copyright text from spec file. - Please remove Epach tag. - Requires for /sbin/ldconfig are not requires. - I not see any make step in the %build stanza - Please remove static libraries - Mock build (FC5/i686) failed checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for CAIROMM... configure: error: Package requirements (cairo >= 1.0) we re not met: Package x11 was not found in the pkg-config search path. Perhaps you should add the directory containing `x11.pc' to the PKG_CONFIG_PATH environment variable Package 'x11', required by 'Xrender', not found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables CAIROMM_CFLAGS and CAIROMM_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. error: Bad exit status from /var/tmp/rpm-tmp.67558 (%build) Becouse cairo is not part of FC-4 anyone else may overtake the review part. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 20:10:46 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 15:10:46 -0500 Subject: [Bug 182463] Review Request: cairomm (C++ bindings for cairo) In-Reply-To: Message-ID: <200602222010.k1MKAkkc004679@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cairomm (C++ bindings for cairo) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182463 Jochen at herr-schmitt.de changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163776 |177841 nThis| | ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-22 15:10 EST ------- Change to FE_NEEDSPONSOR, becouse submitter wrote, that he needs sponsorship. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From jwboyer at jdub.homelinux.org Wed Feb 22 19:27:04 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 22 Feb 2006 14:27:04 -0500 (EST) Subject: tla (was: Re: FE Package Status of Feb 16, 2006) In-Reply-To: <1140638708.8388.9.camel@bobcat.mine.nu> References: <200602161627.k1GGRAOi020957@ludwig-alpha.unil.ch> <1140264009.2904.119.camel@localhost.localdomain> <20060218165448.30fbb45c.bugs.michael@gmx.net> <1140279924.6634.35.camel@localhost.localdomain> <20060218175756.4577d6f2.bugs.michael@gmx.net> <1140282817.6634.47.camel@localhost.localdomain> <20060218202347.2d064fe2.bugs.michael@gmx.net> <1140389692.12129.33.camel@bobcat.mine.nu> <43F94306.9010107@jdub.homelinux.org> <1140638708.8388.9.camel@bobcat.mine.nu> Message-ID: <28637.129.42.161.36.1140636424.squirrel@jdub.homelinux.org> > On Sun, 2006-02-19 at 22:18 -0600, Josh Boyer wrote: >> Ville Skytt?? wrote: >> > >> > I would like to see tla in Extras in the future as it's every now and >> > then needed, but I'd rather stay away from grabbing official >> > maintainership. 1.3.4 is out (released in January) and AFAICT the >> > upstream project is alive again, with a new maintainer. Anyone? >> >> There was discussion of having dual maintainers in FE... wanna try it >> out with this package? I'm willing to try it out.. > > Ok, let's do it. Go ahead and set yourself as the initial owner and add > me to Cc in owners.list. (And let me know if you intend to push a FE5 > rebuild of tla or if you'd like me to take care of it.) Ok, owners.list updated and rebuild submitted. We can worry about updating tla to 1.3.4 a bit later. josh From jspaleta at gmail.com Wed Feb 22 20:09:58 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 22 Feb 2006 15:09:58 -0500 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <20060222195124.GC2885@free.fr> References: <1140630242.18225.10.camel@localhost.localdomain> <20060222195124.GC2885@free.fr> Message-ID: <604aa7910602221209y35c3fb81g244876fde9976fef@mail.gmail.com> On 2/22/06, Patrice Dumas wrote: > Sorry... It shows once more that providing an old code instead of using > the system one is bad. Without getting into the specifics as to when you should be encouraged to use private codebases in packages. When it's done you have to be a bit careful to make sure you aren't exposing that codebase as a provides. This can involve disabling rpm's normal automatic provides detection and hide the private modules from rpm's automatic perl module detection. The questions I'm most interested in now involve preventing things like this from happening in the future. Would reviewing the provides from a mock build a hard requirement for pre-submission status have helped prevent this? I could see an argument for checking to make sure that a new extras package does not provide duplicate provides as packages in the standard build environment. And if they do, we make sure its not a problem before they get into the tree. Or can this sort of test be scripted in the buildsystem and flag a package build if it disturbs the normal build group? In a sense would it make sense to make the build environment "immutable" and require special action to build packages (new or updates) that would change the list of packages in the build environment being used in the buildsystem? -jef From ville.skytta at iki.fi Wed Feb 22 20:38:48 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 22 Feb 2006 22:38:48 +0200 Subject: rpms/perl-Unicode-Map8/devel perl-Unicode-Map8.spec,1.7,1.8 In-Reply-To: <200602220840.k1M8eWC5015293@cvs-int.fedora.redhat.com> References: <200602220840.k1M8eWC5015293@cvs-int.fedora.redhat.com> Message-ID: <1140640728.8388.24.camel@bobcat.mine.nu> On Wed, 2006-02-22 at 03:40 -0500, Aurelien Bompard wrote: > -%check || : > -make test > +%check > +make test || : [...] > %changelog > +* Wed Feb 22 2006 Aurelien Bompard 0.12-7 > +- disable unit tests (map8.t fails on x86_64) Um, no. You didn't disable the unit test, but just ignored its result. And it's not "just" a unit test failure but a plain crash in t/map8.t's test 2 ($no->recode8(...)), so this package is now pretty certainly shipped broken for x86_64. If it can't be fixed, please ExcludeArch x86_64 instead (and also in all dependent packages), file the appropriate Bugzilla ticket and refer to it in the specfile(s). FYI, the compilation warnings building it on x86_64 are: map8x.c: In function 'map8_recode8': map8x.c:322: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness map8x.c:315: warning: unused variable 'uc' [...] Map8.xs: In function 'to8_cb': Map8.xs:84: warning: pointer targets in return differ in signedness Map8.xs: In function 'XS_Unicode__Map8__empty_block': Map8.xs:201: warning: comparison is always false due to limited range of data type Map8.c: In function 'XS_Unicode__Map8_to16': Map8.c:490: warning: pointer targets in initialization differ in signedness Map8.xs: In function 'XS_Unicode__Map8_recode8': Map8.xs:359: warning: implicit declaration of function 'map8_recode8' Map8.c: At top level: /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/patchlevel.h:122: warning: 'local_patches' defined but not used "implicit declaration of function 'map8_recode8'" looks susceptible. From bugzilla at redhat.com Wed Feb 22 20:36:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 15:36:01 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602222036.k1MKa1Cx010560@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 jpo at di.uminho.pt changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jpo at di.uminho.pt ------- Additional Comments From jpo at di.uminho.pt 2006-02-22 15:35 EST ------- Two more minor suggestions: * We only need to override CFLAGS (no need to override the value of CC). The following line resolves the distro CFLAGS inheritance problem: CFLAGS="%{optflags}" make %{?_smp_mflags} * We can also drop the %doc tag from the man page entry in the %files section. (rpm automatically tags manpages as doc files). Everything else looks good with Jason's patch applied. /jpo PS - And the package can also be updated to version 3.8.7 ;) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 20:51:58 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 15:51:58 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602222051.k1MKpwKA014103@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 ------- Additional Comments From tibbs at math.uh.edu 2006-02-22 15:51 EST ------- Thanks; I had tried a different setting of CFLAGS but that broke the build. Everything works with your method. I also didn't realize that manpages were automatically tagged as %doc. I also notice that 3.8.7 includes the license text in the tarball so I think Folkert is on top of things. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 21:19:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 16:19:02 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602222119.k1MLJ2X4020080@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 folkert at vanheusden.com changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Package Review |orange ------- Additional Comments From folkert at vanheusden.com 2006-02-22 16:18 EST ------- My guess is that that build problem is caused by the 'VERSION' define not being set if omitted from the CFLAGS variable. Suggestions for generic fixes are welcome but I would like to keep it somewhere in the Makefiles-parts as I then only have to set it in one place when I release a new version. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 21:20:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 16:20:27 -0500 Subject: [Bug 182463] Review Request: cairomm (C++ bindings for cairo) In-Reply-To: Message-ID: <200602222120.k1MLKReL020369@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cairomm (C++ bindings for cairo) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182463 ------- Additional Comments From rvinyard at cs.nmsu.edu 2006-02-22 16:20 EST ------- The .spec file is updated in the same place. The new srpm can be found at: http://miskatonic.cs.nmsu.edu/pub/fedora/4/srpms/cairomm-0.5.0-4.20060222cvs.src.rpm - Locak build will not possible on FC-4 Possible, but requires backports of Gtk+ et. al. (available at the same site as the srpm if anyone really wants them for FC4 before FC5 comes out) But, the intent isn't to submit for FC4, just FC5. - Please give the full URL in the Source tag. There are no snapshot releases yet. Only cvs via cairographics.org directly. - The BuildRoot must be cleaned at the beginning of %install The first line is: rm -rf ${RPM_BUILD_ROOT} Is there more to do? In case it was an oversight, I put an extra line in to make it fit the convention that other rpm's seem to use. - Please remove Copyright text from spec file. Removed - Please remove Epach tag. Removed - Requires for /sbin/ldconfig are not requires. Removed - I not see any make step in the %build stanza Added - Please remove static libraries Removed - Mock build (FC5/i686) failed I'm not sure how to handle this one. This looks like mock isn't finding any of the pkgconfig .pc files. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 21:31:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 16:31:53 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602222131.k1MLVrUc023960@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 ------- Additional Comments From jpo at di.uminho.pt 2006-02-22 16:31 EST ------- (In reply to comment #12) > Thanks; I had tried a different setting of CFLAGS but that broke the build. > Everything works with your method. I also didn't realize that manpages were > automatically tagged as %doc. No problem. I have been maintaining my own multitail specfile for several years now ;) /jpo -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From tibbs at math.uh.edu Wed Feb 22 21:41:57 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 22 Feb 2006 15:41:57 -0600 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <604aa7910602221209y35c3fb81g244876fde9976fef@mail.gmail.com> (Jeff Spaleta's message of "Wed, 22 Feb 2006 15:09:58 -0500") References: <1140630242.18225.10.camel@localhost.localdomain> <20060222195124.GC2885@free.fr> <604aa7910602221209y35c3fb81g244876fde9976fef@mail.gmail.com> Message-ID: >>>>> "JS" == Jeff Spaleta writes: JS> Would reviewing the provides from a mock build a hard requirement JS> for pre-submission status have helped prevent this? It's certainly not a terrible idea, but then we're back at the problem of requiring submitters or reviewers to have enough infrastructure to run mock or providing a way to leverage the build system before the package has been checked in. In the absence of build system support, I'll happily do a mock build (on i386 or x86_64) for anyone that asks, especially if it will help prevent this kind of problem. - J< From orion at cora.nwra.com Wed Feb 22 21:44:16 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 22 Feb 2006 14:44:16 -0700 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140630242.18225.10.camel@localhost.localdomain> References: <1140630242.18225.10.camel@localhost.localdomain> Message-ID: <43FCDB30.3010709@cora.nwra.com> Dan Williams wrote: > > We should also start up a discussion about how to prevent problems of > this nature in the future. We would not have noticed the problem had > boa not been conflicting with mock, but the real issue of dap-server > providing perl-HTML-Parser modules itself would still have been a > problem, albeit a silent one. If there are scripts, rules, and/or > pre-submit checks which could be performed at various stages, it might > go a long way towards prevent this sort of breakage in the future. > A crude one might be to have mock check the names of the packages installed by "groupinstall build" against a list of "approved" packages. This list should be static for all releases, and nearly so for rawhide. I've been bitten too by a package providing a file that conflicts with another package. Provides should be checked for conflicts too, although there would have to be a white list of Provides that are allowed to be duplicated - like webserver. Since this info is all in the repo data, shouldn't be too bad to write. :-) -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From ville.skytta at iki.fi Wed Feb 22 21:48:08 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 22 Feb 2006 23:48:08 +0200 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <604aa7910602221209y35c3fb81g244876fde9976fef@mail.gmail.com> References: <1140630242.18225.10.camel@localhost.localdomain> <20060222195124.GC2885@free.fr> <604aa7910602221209y35c3fb81g244876fde9976fef@mail.gmail.com> Message-ID: <1140644888.8388.28.camel@bobcat.mine.nu> On Wed, 2006-02-22 at 15:09 -0500, Jeff Spaleta wrote: > I could see an argument for checking to make > sure that a new extras package does not provide duplicate provides as > packages in the standard build environment. I don't think there's a need for such a special case. Packages simply must not provide things they don't really intend to "export". From buildsys at fedoraproject.org Wed Feb 22 21:53:39 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 22 Feb 2006 16:53:39 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060222215339.B86C28011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 3 cacti-0.8.6h-6.fc3 dap-server-3.5.3-1.fc3.1 kmymoney2-0.8.3-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed Feb 22 21:55:29 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 22 Feb 2006 16:55:29 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060222215529.942A88011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 41 Coin2-2.4.4-10.fc5 Sprog-0.14-6.fc5 amarok-1.4-0.7.beta1.fc5 bmp-flac2-007-2.fc5 bwidget-1.7.0-2.fc5 cacti-0.8.6h-6 enemies-of-carlotta-1.2.1-1.fc5 fwbuilder-2.0.10-3.fc5 gmpc-0.11.2-3.fc5 itk-3.3-0.2.RC1.fc5 iwidgets-4.0.1-3.fc5 jpgraph-2.1.1-1.fc5 kmymoney2-0.8.3-1.fc5 libfwbuilder-2.0.10-2.fc5 libkipi-0.1.2-5.fc5 libtorrent-0.8.2-4.fc5 libtorrent-0.8.5-2.fc5 mhash-0.9.2-4 mhonarc-2.6.15-3.fc5 nuttcp-5.1.11-6 pdftohtml-0.36-7.fc5 perl-Carp-Assert-0.18-3.fc5 perl-GDGraph3d-0.63-5.fc5 perl-Log-Dispatch-2.11-4.fc5 perl-Text-CSV_XS-0.23-4.fc5 perl-Tree-DAG_Node-1.05-3.fc5 perl-Unicode-Map8-0.12-7.fc5 php-adodb-4.72-1.fc5 pure-ftpd-1.0.21-2.fc5 python-dialog-2.7-3.fc5 qps-1.9.12-1.fc5 sblim-cmpi-base-1.5.4-3.fc5 sblim-cmpi-devel-1.0.4-1.fc5 sblim-testsuite-1.2.4-1.fc5 sblim-wbemcli-1.5.1-1.fc5 stow-1.3.3-3.fc5 syck-0.55-7.fc5 tcldom-3.1-4.fc5 tetex-unicode-0-5.20041017.fc5 ulogd-1.24-1.fc5 xbindkeys-1.7.2-4.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From cweyl at alumni.drew.edu Wed Feb 22 22:08:35 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 22 Feb 2006 17:08:35 -0500 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140644888.8388.28.camel@bobcat.mine.nu> References: <1140630242.18225.10.camel@localhost.localdomain> <20060222195124.GC2885@free.fr> <604aa7910602221209y35c3fb81g244876fde9976fef@mail.gmail.com> <1140644888.8388.28.camel@bobcat.mine.nu> Message-ID: <7dd7ab490602221408n242f7450lfd086421d294d512@mail.gmail.com> On 2/22/06, Ville Skytt? wrote: > > I don't think there's a need for such a special case. Packages simply > must not provide things they don't really intend to "export". Along those lines -- I'm pretty sure there is no way to tell rpm to exclude auto-found provides directly, but would capabilities like this help? E.g. a NoProvides: tag that rpm could use to filter the list after the autoprovides scripts run. -Chris From Christian.Iseli at licr.org Wed Feb 22 22:12:36 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 22 Feb 2006 23:12:36 +0100 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Your message of "Wed, 22 Feb 2006 16:19:02 EST." <200602222119.k1MLJ2X4020080@www.beta.redhat.com> Message-ID: <200602222212.k1MMClTA002803@mx1.redhat.com> bugzilla at redhat.com said: > folkert at vanheusden.com changed: > What |Removed |Added > ---------------------------------------------------------------------------- > Component|Package Review |orange Huh ? Could you change that back please ? From bugzilla at redhat.com Wed Feb 22 22:16:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 17:16:59 -0500 Subject: [Bug 175425] Review Request: tile - Modern versions of Tk widget set In-Reply-To: Message-ID: <200602222216.k1MMGxRP003166@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: tile - Modern versions of Tk widget set https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175425 ------- Additional Comments From wart at kobold.org 2006-02-22 17:16 EST ------- (In reply to comment #2) > - Patch filename has no descriptive quality Fixed. I also modified the patch with another minor fix for devel. > - Odd spacing in %changelog You mean the missing spaces between entries? Fixed. > ? Is the static lib in -devel required? Yes. This is the stub library for linking against tile. Tcl stub libraries are a cross-platform cross-compiler way of performing dynamic linking. So even though it's a static library, it's really used for dynamic linking: http://wiki.tcl.tk/285 > - Include demos, doc/converting.txt, and doc/html in %doc Done. > - Install doc/*.n into %{_mandir}/mann Done. New files: http://www.kobold.org/~wart/fedora/tile-0.7.2-3.src.rpm http://www.kobold.org/~wart/fedora/tile.spec -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Feb 22 22:19:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 17:19:27 -0500 Subject: [Bug 182463] Review Request: cairomm (C++ bindings for cairo) In-Reply-To: Message-ID: <200602222219.k1MMJRNc003994@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cairomm (C++ bindings for cairo) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182463 Christian.Iseli at licr.org changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |163776 nThis| | ------- Additional Comments From Christian.Iseli at licr.org 2006-02-22 17:19 EST ------- > Change to FE_NEEDSPONSOR, becouse submitter wrote, that he needs sponsorship. The idea is that FE-NEEDSPONSOR should be added, not used to replace FE-NEW. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From jspaleta at gmail.com Wed Feb 22 22:27:04 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 22 Feb 2006 17:27:04 -0500 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140644888.8388.28.camel@bobcat.mine.nu> References: <1140630242.18225.10.camel@localhost.localdomain> <20060222195124.GC2885@free.fr> <604aa7910602221209y35c3fb81g244876fde9976fef@mail.gmail.com> <1140644888.8388.28.camel@bobcat.mine.nu> Message-ID: <604aa7910602221427k52585f0aocb6964c6743055fd@mail.gmail.com> On 2/22/06, Ville Skytt? wrote: > I don't think there's a need for such a special case. Packages simply > must not provide things they don't really intend to "export". well yes... they shouldn't do that... but I'm asking how do we do a better job of checking for that...especially when rpmbuild's automagical provides calculator notices something and makes it a provides when you did not explicitly ask it to be? If building binary packages and checking its provides list isn't a hard review requirement for pre-submission reviews... how else can we do a better job of catching this sort of thing? And how do we do a better job of making sure that if it happens it doesn't bite us in the buildsystem itself? -jef From notting at redhat.com Wed Feb 22 22:30:24 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 22 Feb 2006 17:30:24 -0500 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140644888.8388.28.camel@bobcat.mine.nu> References: <1140630242.18225.10.camel@localhost.localdomain> <20060222195124.GC2885@free.fr> <604aa7910602221209y35c3fb81g244876fde9976fef@mail.gmail.com> <1140644888.8388.28.camel@bobcat.mine.nu> Message-ID: <20060222223024.GD3543@devserv.devel.redhat.com> Ville Skytt? (ville.skytta at iki.fi) said: > On Wed, 2006-02-22 at 15:09 -0500, Jeff Spaleta wrote: > > > I could see an argument for checking to make > > sure that a new extras package does not provide duplicate provides as > > packages in the standard build environment. > > I don't think there's a need for such a special case. Packages simply > must not provide things they don't really intend to "export". However, attempting to filter provides by turning off RPM's internal generator and using scripts removes multilib tagging and similar features. So it's tricky to solve correctly. Bill From paul at all-the-johnsons.co.uk Wed Feb 22 22:35:55 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Wed, 22 Feb 2006 22:35:55 +0000 Subject: Anjuta - change of maintainer In-Reply-To: <13dbfe4f0602221119h7e190d4dq81dd01c46eb8385d@mail.gmail.com> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602211544g643afe6ev3dd6b3419c3e1f6c@mail.gmail.com> <1140565626.31940.14.camel@T7.Linux> <13dbfe4f0602220604l1f30f6b6w1511f42ad780fa89@mail.gmail.com> <1140622767.31392.33.camel@mrwibble.mrwobble> <20060222183059.32178be3.bugs.michael@gmx.net> <13dbfe4f0602221003l463d483fp99ed352b8f5d189d@mail.gmail.com> <43FCB163.3070605@city-fan.org> <13dbfe4f0602221113w119f7a89x415a349fba2ebce6@mail.gmail.com> <43FCB849.2050004@city-fan.org> <13dbfe4f0602221119h7e190d4dq81dd01c46eb8385d@mail.gmail.com> Message-ID: <1140647755.30541.6.camel@T7.Linux> Hi, > Paul, The Maintainer, you know what to do :) Yes and it was done about an hour back - it should be in the next push. TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show From pertusus at free.fr Wed Feb 22 20:24:35 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 22 Feb 2006 21:24:35 +0100 Subject: webserver, apache user and cgi Message-ID: <20060222202435.GE2885@free.fr> Hello, The buildsys breakage also showed an issue with dap-server. Indeed in a dap-server subpackage, dap-server-cgi, a cgi interface for the dap server is provided. It heavily depends on apache, because it installs a config file in %{_sysconfdir}/httpd/conf.d. The base package also depends on apache because it owns a cache dir, and the cache dir should be owned by the user running the webserver. Maybe the right thing to do would be to Requires httpd for dap-server-cgi. But for the main package what is needed is the uid of the user running the webserver, and a webserver that implements cgi, apache isn't required. What to do in that case? It seems the requiring webserver doesn't do the trick if, for example, boa, which provides webserver uses another uid. Any thought? -- Pat From chitlesh at fedoraproject.org Wed Feb 22 22:56:44 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 22 Feb 2006 23:56:44 +0100 Subject: Anjuta - change of maintainer In-Reply-To: <1140647755.30541.6.camel@T7.Linux> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602220604l1f30f6b6w1511f42ad780fa89@mail.gmail.com> <1140622767.31392.33.camel@mrwibble.mrwobble> <20060222183059.32178be3.bugs.michael@gmx.net> <13dbfe4f0602221003l463d483fp99ed352b8f5d189d@mail.gmail.com> <43FCB163.3070605@city-fan.org> <13dbfe4f0602221113w119f7a89x415a349fba2ebce6@mail.gmail.com> <43FCB849.2050004@city-fan.org> <13dbfe4f0602221119h7e190d4dq81dd01c46eb8385d@mail.gmail.com> <1140647755.30541.6.camel@T7.Linux> Message-ID: <13dbfe4f0602221456j686af01eq63c79a026b38debb@mail.gmail.com> On 2/22/06, Paul F. Johnson wrote: > Hi, > > > Paul, The Maintainer, you know what to do :) > > Yes and it was done about an hour back - it should be in the next push. > > TTFN > > Paul nice :) -- http://clunixchit.blogspot.com From gauret at free.fr Wed Feb 22 23:07:52 2006 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 23 Feb 2006 00:07:52 +0100 Subject: rpms/perl-Unicode-Map8/devel perl-Unicode-Map8.spec,1.7,1.8 References: <200602220840.k1M8eWC5015293@cvs-int.fedora.redhat.com> <1140640728.8388.24.camel@bobcat.mine.nu> Message-ID: Ville Skytt? wrote: > Um, no. You didn't disable the unit test, but just ignored its result. Yes, that's what I meant by "disable" (as in "don't make rpmbuild fail") > And it's not "just" a unit test failure but a plain crash in t/map8.t's > test 2 ($no->recode8(...)), so this package is now pretty certainly > shipped broken for x86_64. If it can't be fixed, please ExcludeArch > x86_64 instead (and also in all dependent packages), file the > appropriate Bugzilla ticket and refer to it in the specfile(s). Done, bug #182514. Thanks for having a look at it. Aur?lien. -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Never test for an error condition you don't know how to handle." -- Steinbach's Guideline for Systems Programming From bugzilla at redhat.com Wed Feb 22 23:19:54 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 18:19:54 -0500 Subject: [Bug 180430] Review Request: Tong - a game of skill In-Reply-To: Message-ID: <200602222319.k1MNJsvT019669@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Tong - a game of skill https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180430 ------- Additional Comments From wart at kobold.org 2006-02-22 18:19 EST ------- (In reply to comment #1) > The source grabbed from http://www.nongnu.org/tong/tong-1.0.tar.gz doesn't match > what's in your SRPM. Did upstream change their tarball recently? That's funny. I just downloaded it again and both diff and md5sum claim that they match: 9f358a012639de1a5a8d3e0b323438de tong-1.0.tar.gz Can you check the md5sum on the file that you downloaded? > rpmlint says: > E: tong-data only-non-binary-in-usr-lib > W: tong-data no-documentation > > The stuff that tong-data installs really should go into /usr/share and the > binary should go into /usr/bin. I know the program is broken in that it > requires the media directory to be in the same place as the binary, but honestly > I think it's simpler to apply a tiny patch to chdir("/usr/share/tong") at the > start of main() than to hack around the deficiency of the program. > > A five-minute hack is at: > http://www.math.uh.edu/~tibbs/rpms/tong/tong.spec > http://www.math.uh.edu/~tibbs/rpms/tong/tong-1.0-3.src.rpm I'll see your patch, and raise you a #define so that %{_datadir} cab be passed in during the compile step: http://www.kobold.org/~wart/fedora/tong-1.0-4.src.rpm http://www.kobold.org/~wart/fedora/tong.spec -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Wed Feb 22 23:31:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 18:31:11 -0500 Subject: [Bug 175495] Review Request: cgi-util: A C library for creating CGI programs In-Reply-To: Message-ID: <200602222331.k1MNVBL1022460@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cgi-util: A C library for creating CGI programs https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175495 ------- Additional Comments From redhat at flyn.org 2006-02-22 18:31 EST ------- The following removes the use of -Werror from the build process: Spec Name or Url: http://flyn.org/SRPMS/cgi-util.spec SRPM Name or Url: http://flyn.org/SRPMS/cgi-util-2.2.1-4.src.rpm Description: A C library for creating Common Gateway Interface ("CGI") programs -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From paul at all-the-johnsons.co.uk Thu Feb 23 00:00:55 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 23 Feb 2006 00:00:55 +0000 Subject: Updating just a spec file to cvs Message-ID: <1140652856.30541.9.camel@T7.Linux> Hi, Is there a way that I can just do a cvs update to a spec file? Currently z88dk won't compile under x86_64 or ia64 and mock refuses to work on my machine. The version in rawhide extras will therefore fail. I've altered the spec file, but now can't build it here and commit. Can just the spec file be updated? TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From wart at kobold.org Thu Feb 23 00:11:17 2006 From: wart at kobold.org (Michael Thomas) Date: Wed, 22 Feb 2006 16:11:17 -0800 Subject: Updating just a spec file to cvs In-Reply-To: <1140652856.30541.9.camel@T7.Linux> References: <1140652856.30541.9.camel@T7.Linux> Message-ID: <43FCFDA5.5040107@kobold.org> Paul wrote: > Hi, > > Is there a way that I can just do a cvs update to a spec file? Currently > z88dk won't compile under x86_64 or ia64 and mock refuses to work on my > machine. > > The version in rawhide extras will therefore fail. I've altered the spec > file, but now can't build it here and commit. Can just the spec file be > updated? Perhaps I'm misunderstanding your problem, but this should work to pull changes from the repository: # cvs update -C foo.spec This will toss away local changes and give you back the latest version from CVS. Or, if you want to push changes to this file only: # cvs commit foo.spec Then request a build: # make tag # make build --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From bugzilla at redhat.com Thu Feb 23 00:33:22 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 19:33:22 -0500 Subject: [Bug 180430] Review Request: Tong - a game of skill In-Reply-To: Message-ID: <200602230033.k1N0XMh5002541@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Tong - a game of skill https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180430 ------- Additional Comments From wart at kobold.org 2006-02-22 19:33 EST ------- Doh. I should try running things before claiming success. I'll get this cleaned up... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugs.michael at gmx.net Thu Feb 23 00:54:45 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 23 Feb 2006 01:54:45 +0100 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <604aa7910602221427k52585f0aocb6964c6743055fd@mail.gmail.com> References: <1140630242.18225.10.camel@localhost.localdomain> <20060222195124.GC2885@free.fr> <604aa7910602221209y35c3fb81g244876fde9976fef@mail.gmail.com> <1140644888.8388.28.camel@bobcat.mine.nu> <604aa7910602221427k52585f0aocb6964c6743055fd@mail.gmail.com> Message-ID: <20060223015445.1f531c04.bugs.michael@gmx.net> On Wed, 22 Feb 2006 17:27:04 -0500, Jeff Spaleta wrote: > On 2/22/06, Ville Skytt? wrote: > > I don't think there's a need for such a special case. Packages simply > > must not provide things they don't really intend to "export". > > well yes... they shouldn't do that... but I'm asking how do we do a > better job of checking for that...especially when rpmbuild's > automagical provides calculator notices something and makes it a > provides when you did not explicitly ask it to be? If building binary > packages and checking its provides list isn't a hard review > requirement for pre-submission reviews... how else can we do a better > job of catching this sort of thing? Examine binary packages ( rpm -qp --provides foo.i386.rpm ) and ask yourself "Do you like what you see? Did you expect the package to provide a Perl module?". It's something the packagers should do anyway before they decide whether any explicit "Provides" are needed. > And how do we do a better job of making sure that if it happens it > doesn't bite us in the buildsystem itself? First let's wait how often it will happen again. ;) From bugzilla at redhat.com Thu Feb 23 01:12:26 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 20:12:26 -0500 Subject: [Bug 180430] Review Request: Tong - a game of skill In-Reply-To: Message-ID: <200602230112.k1N1CQiH008768@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Tong - a game of skill https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180430 ------- Additional Comments From wart at kobold.org 2006-02-22 20:12 EST ------- Ok, all fixed. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rc040203 at freenet.de Thu Feb 23 04:18:31 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 23 Feb 2006 05:18:31 +0100 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140630242.18225.10.camel@localhost.localdomain> References: <1140630242.18225.10.camel@localhost.localdomain> Message-ID: <1140668312.14289.162.camel@mccallum.corsepiu.local> On Wed, 2006-02-22 at 12:44 -0500, Dan Williams wrote: > Hi, > > Some of you have noticed and pointed out the fact that the FC-4 Extras > target wasn't successfully building any packages and wasn't giving much > failure information. So after a bit of detective work this morning > we've figured out that: > 3) plague-builder appears to be dropping output from mock that's printed > to stderr, causing the real error message not to appear in the logs > > To correct the problem, dap-server has been temporarily removed from > Extras repositories, since it even blocks rebuilds of a fixed dap-server > itself. When the buildsystem local repository rsyncs the new repo data > down, dap-server will be rebuilt and builds on the fc-4 target should be > able to continue as normal. Still no-go: ... /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-4-i386-core-72dfa3dc071fedce33db998bb2b4024b3ffa4531/root groupinstall build http://buildsys.fedoraproject.org/plague-results/fedora-4-extras/dap-server/3.5.3-1.fc4/i386/dap-server-3.5.3-1.fc4.i386.rpm: [Errno 4] IOError: HTTP Error 404: Not Found Trying other mirror. Error: failure: dap-server/3.5.3-1.fc4/i386/dap-server-3.5.3-1.fc4.i386.rpm from local: [Errno 256] No more mirrors to try. Cleaning up... Done. ... seems as if now the repo is broked. Ralf From bugzilla at redhat.com Thu Feb 23 04:33:54 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 23:33:54 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602230433.k1N4XsAZ016633@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-22 23:33 EST ------- I'm still getting some files listed twice: warning: File listed twice: /etc/ser/dictionary.ser warning: File listed twice: /etc/ser/ser.cfg warning: File listed twice: /etc/ser/serweb warning: File listed twice: /etc/ser/serweb/config.php warning: File listed twice: /etc/ser/serweb/config_data_layer.php warning: File listed twice: /etc/ser/serweb/config_domain_defaults.php warning: File listed twice: /etc/ser/serweb/config_lang.php warning: File listed twice: /etc/ser/serweb/config_paths.php warning: File listed twice: /etc/ser/serweb/set_domain.php -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 04:56:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 22 Feb 2006 23:56:50 -0500 Subject: [Bug 182175] Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) In-Reply-To: Message-ID: <200602230456.k1N4uoRK020540@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182175 mej at eterm.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mej at eterm.org ------- Additional Comments From mej at eterm.org 2006-02-22 23:56 EST ------- Or you could just get rid of your silly rules which discriminate against packages for no real reason. The license is clearly posted in the spec file and in every .c file in the package. The correct procedure for checking the license of a package on an RPM-based system is "rpm -q --qf '%{LICENSE}\n' ". If that works and returns a standard response ("GPL," "BSD," "MIT," or similar), there should be no problem. Furthermore, the following requirements are just stupid and demonstrate either pointless fascism on the part of your policy makers or flaws in the design of your build system: > - BuildRoot should be %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > - The BuildRoot must be cleaned at the beginning of %install The build system, not the individual RPM's, should ensure that the buildroot path is unique and clean prior to invoking rpmbuild. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 05:11:46 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 00:11:46 -0500 Subject: [Bug 180430] Review Request: Tong - a game of skill In-Reply-To: Message-ID: <200602230511.k1N5BkwU022682@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Tong - a game of skill https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180430 ------- Additional Comments From tibbs at math.uh.edu 2006-02-23 00:11 EST ------- Well, I tried again and the checksums do match what you get. I had tried multiple times before. (I was using spectool, which uses wget, so there shouldn't be a browser caching issue.) Yes, props for the improved hack. Much better. rpmlint now complains only about tong-data having no documentation; no problem there. The only remaining issue is %{optflags} (or $RPM_OPT_FLAGS), which isn't getting passed. The Makefile doesn't support CFLAGS, but you can set CC: make CC="%{__cc} %{optflags}" GAME_DATA_DIR=%{_datadir}/tong %{?_smp_mflags} This produces a build that contains proper debug info (so the debuginfo package actually contains something) and uses recommended flags like FORTIFY_SOURCE. Unfortunately I can't test the package from home so I'll have to wait until tomorrow. Beyond that I don't see any remaining issues; I'll test and run some mock builds tomorrow. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 05:56:19 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 00:56:19 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602230556.k1N5uJaR030231@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From dgregor at redhat.com 2006-02-23 00:56 EST ------- When building the package I noticed that /usr/local/bin/perl got listed as a dependency. Grepping the source, I see a number of references for binaries in /usr/local/bin. These should all be changed to /usr/bin. Also, I run into this problem: $ sudo rpm -ivh gallery2-2.0.2-6.noarch.rpm gallery2-gd-2.0.2-6.noarch.rpm gallery2-classic-2.0.2-6.noarch.rpm error: Failed dependencies: gd <= 2.0 is needed by gallery2-gd-2.0.2-6.noarch $ rpm -q gd gd-2.0.33-2 $ cat /etc/fedora-release Fedora Core release 4 (Stentz) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 06:11:00 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 01:11:00 -0500 Subject: [Bug 182463] Review Request: cairomm (C++ bindings for cairo) In-Reply-To: Message-ID: <200602230611.k1N6B0Pq032387@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cairomm (C++ bindings for cairo) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182463 ------- Additional Comments From rvinyard at cs.nmsu.edu 2006-02-23 01:10 EST ------- Sorry, one more fix; I missed one place when %{epoch} was used. The .spec file above is still good, but the srpm is now: http://miskatonic.cs.nmsu.edu/pub/fedora/4/srpms/cairomm-0.5.0-5.20060222cvs.src.rpm Also, I did try building on a FC5-T3 i686 machine and no problems, so I think the aforementioned problem was in mock. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 06:25:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 01:25:15 -0500 Subject: [Bug 182463] Review Request: cairomm (C++ bindings for cairo) In-Reply-To: Message-ID: <200602230625.k1N6PFZw002384@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cairomm (C++ bindings for cairo) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182463 ------- Additional Comments From rc040203 at freenet.de 2006-02-23 01:25 EST ------- > > - Please give the full URL in the Source tag. > There are no snapshot releases yet. Only cvs via cairographics.org directly. IMO, then we should not ship it. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 06:28:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 01:28:33 -0500 Subject: [Bug 179541] Review Request: tinyfugue: A MU* client In-Reply-To: Message-ID: <200602230628.k1N6SXUJ002759@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: tinyfugue: A MU* client https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179541 ------- Additional Comments From seg at haxxed.com 2006-02-23 01:28 EST ------- New srpm and spec, with epoch removed: http://www.haxxed.com/rpms/tinyfugue.spec http://www.haxxed.com/rpms/tinyfugue-5.0-0.2.b7.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 23 06:34:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 01:34:50 -0500 Subject: [Bug 167147] Review Request: Aqsis In-Reply-To: Message-ID: <200602230634.k1N6YoE9004198@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Aqsis https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167147 rc040203 at freenet.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |WONTFIX OtherBugsDependingO|163776, 177841 | nThis| | ------- Additional Comments From rc040203 at freenet.de 2006-02-23 01:34 EST ------- No feedback from submitter for more than 5 months. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 23 06:36:41 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 01:36:41 -0500 Subject: [Bug 181445] Review Request: php-shout In-Reply-To: Message-ID: <200602230636.k1N6afKt004558@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-shout https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181445 ------- Additional Comments From holbrookbw at users.sourceforge.net 2006-02-23 01:36 EST ------- Spec Name or Url: http://prdownloads.sourceforge.net/phpshout/php-shout-0.1.5-1.fc4.spec?download SRPM Name or Url: http://prdownloads.sourceforge.net/phpshout/php-shout-0.1.5-1.fc4.src.rpm?download Some bugfixes upstream bumped php-shout to 0.1.5, so I rolled some new RPMs. Another review/sponsor would be appreciated! Also, I'm still trying to contact Thomas Vander Stichele with regards to updating libshout to 2.2 for fe5 (bz 181523), but I haven't heard a word. Is there a statute for how long a developer can go without responding before we make decisions for him?... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 06:59:38 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 01:59:38 -0500 Subject: [Bug 176579] Review Request: ipsvd -- Internet protocol service daemons In-Reply-To: Message-ID: <200602230659.k1N6xcvo008003@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ipsvd -- Internet protocol service daemons https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176579 ------- Additional Comments From enrico.scholz at informatik.tu-chemnitz.de 2006-02-23 01:59 EST ------- let it me say in other words: you will gain absolutely nothing when linking the programs dynamically against glibc. This will give only disadvantages. This toolset is designed for bloatless systems and it should be built correspondingly. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From ville.skytta at iki.fi Thu Feb 23 07:05:46 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 23 Feb 2006 09:05:46 +0200 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <20060222223024.GD3543@devserv.devel.redhat.com> References: <1140630242.18225.10.camel@localhost.localdomain> <20060222195124.GC2885@free.fr> <604aa7910602221209y35c3fb81g244876fde9976fef@mail.gmail.com> <1140644888.8388.28.camel@bobcat.mine.nu> <20060222223024.GD3543@devserv.devel.redhat.com> Message-ID: <1140678346.11840.5.camel@bobcat.mine.nu> On Wed, 2006-02-22 at 17:30 -0500, Bill Nottingham wrote: > Ville Skytt? (ville.skytta at iki.fi) said: > > On Wed, 2006-02-22 at 15:09 -0500, Jeff Spaleta wrote: > > > > > I could see an argument for checking to make > > > sure that a new extras package does not provide duplicate provides as > > > packages in the standard build environment. > > > > I don't think there's a need for such a special case. Packages simply > > must not provide things they don't really intend to "export". > > However, attempting to filter provides by turning off RPM's > internal generator and using scripts removes multilib tagging > and similar features. ...which is an example of why a better way to do it, like the NoProvides: tag as suggested by Chris in this thread and others elsewhere (eg. https://bugzilla.redhat.com/126878), is needed. From bugzilla at redhat.com Thu Feb 23 07:08:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 02:08:21 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602230708.k1N78LxE009269@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 ------- Additional Comments From folkert at vanheusden.com 2006-02-23 02:08 EST ------- Ok, my good friend Udo van den Heuvel fixed the suggested changes and I've uploaded the new spec and srpm-file to my site: http://www.vanheusden.com/multitail/multitail-3.8.7-1.src.rpm http://www.vanheusden.com/multitail/multitail.spec -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 07:09:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 02:09:34 -0500 Subject: [Bug 175425] Review Request: tile - Modern versions of Tk widget set In-Reply-To: Message-ID: <200602230709.k1N79Yti009418@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: tile - Modern versions of Tk widget set https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175425 ivazquez at ivazquez.net changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From ivazquez at ivazquez.net 2006-02-23 02:09 EST ------- APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From buildsys at fedoraproject.org Thu Feb 23 07:16:07 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 23 Feb 2006 02:16:07 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060223071607.B92138011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 1 git-1.2.3-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu Feb 23 07:17:12 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 23 Feb 2006 02:17:12 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060223071712.71EAB8011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 8 amaya-9.1-11.fc5 anjuta-1.2.4-3.fc5 git-1.2.3-1.fc5 mhonarc-2.6.15-4.fc5 perl-Unicode-Map8-0.12-8.fc5 perl-Unicode-MapUTF8-1.09-6.fc5 tetex-bytefield-1.2a-2.fc5 tetex-perltex-1.2-3.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Thu Feb 23 07:26:23 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 02:26:23 -0500 Subject: [Bug 180430] Review Request: Tong - a game of skill In-Reply-To: Message-ID: <200602230726.k1N7QNkB012266@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Tong - a game of skill https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180430 ------- Additional Comments From wart at kobold.org 2006-02-23 02:26 EST ------- (In reply to comment #5) > The only remaining issue is %{optflags} (or $RPM_OPT_FLAGS), which isn't getting > passed. The Makefile doesn't support CFLAGS, but you can set CC: > > make CC="%{__cc} %{optflags}" GAME_DATA_DIR=%{_datadir}/tong %{?_smp_mflags} Done. Even though this overrides the "-O3 -Wall" options in the Makefile, these options are added back with optflags. But it needs to be __cxx instead of __cc. I also updated the improved hack to suppress a compiler warning. http://www.kobold.org/~wart/fedora/tong-1.0-5.src.rpm http://www.kobold.org/~wart/fedora/tong.spec I've been able to run it fine on FC4 i386 and x86_64, but it dies on FC5-i386. I suspect that this might be due to my misconfigured vmware box, though. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From ville.skytta at iki.fi Thu Feb 23 07:33:36 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 23 Feb 2006 09:33:36 +0200 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140668312.14289.162.camel@mccallum.corsepiu.local> References: <1140630242.18225.10.camel@localhost.localdomain> <1140668312.14289.162.camel@mccallum.corsepiu.local> Message-ID: <1140680016.11840.11.camel@bobcat.mine.nu> On Thu, 2006-02-23 at 05:18 +0100, Ralf Corsepius wrote: > > To correct the problem, dap-server has been temporarily removed from > > Extras repositories, since it even blocks rebuilds of a fixed dap-server > > itself. When the buildsystem local repository rsyncs the new repo data > > down, dap-server will be rebuilt and builds on the fc-4 target should be > > able to continue as normal. > > Still no-go: > > ... > /usr/sbin/mock-helper yum > --installroot /var/lib/mock/fedora-4-i386-core-72dfa3dc071fedce33db998bb2b4024b3ffa4531/root groupinstall build > http://buildsys.fedoraproject.org/plague-results/fedora-4-extras/dap-server/3.5.3-1.fc4/i386/dap-server-3.5.3-1.fc4.i386.rpm: [Errno 4] IOError: HTTP Error 404: Not Found > Trying other mirror. > Error: failure: > dap-server/3.5.3-1.fc4/i386/dap-server-3.5.3-1.fc4.i386.rpm from local: > [Errno 256] No more mirrors to try. > Cleaning up... > Done. > > ... seems as if now the repo is broked. Yep, maybe the FE4 repodata wasn't regenerated after dap-server removal? My retry last night may have been interrupted by net connectivity glitches. Re-retrying now. From bugzilla at redhat.com Thu Feb 23 07:51:04 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 02:51:04 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602230751.k1N7p4YW016476@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From paul at city-fan.org 2006-02-23 02:51 EST ------- (In reply to comment #22) > I'm still getting some files listed twice: > > warning: File listed twice: /etc/ser/dictionary.ser > warning: File listed twice: /etc/ser/ser.cfg > warning: File listed twice: /etc/ser/serweb > warning: File listed twice: /etc/ser/serweb/config.php > warning: File listed twice: /etc/ser/serweb/config_data_layer.php > warning: File listed twice: /etc/ser/serweb/config_domain_defaults.php > warning: File listed twice: /etc/ser/serweb/config_lang.php > warning: File listed twice: /etc/ser/serweb/config_paths.php > warning: File listed twice: /etc/ser/serweb/set_domain.php I was going to take a look at this but the only spec URL I can see in this ticket seems to be for the initial submission. Where's the latest one? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 07:59:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 02:59:48 -0500 Subject: [Bug 182175] Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) In-Reply-To: Message-ID: <200602230759.k1N7xmQh017709@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182175 ------- Additional Comments From paul at city-fan.org 2006-02-23 02:59 EST ------- (In reply to comment #6) > Or you could just get rid of your silly rules which discriminate against > packages for no real reason. > > The license is clearly posted in the spec file and in every .c file in the > package. The correct procedure for checking the license of a package on an > RPM-based system is "rpm -q --qf '%{LICENSE}\n' ". If that works and > returns a standard response ("GPL," "BSD," "MIT," or similar), there should be > no problem. The point of the rule is to ensure that the license tag in the RPM matches the actual license of the upstream package; that's something the reviewer needs to check. IMHO the presence of the license in the source files itself satisfies the "text included" requirement and there's no need for a separate LICENSE file. > Furthermore, the following requirements are just stupid and demonstrate either > pointless fascism on the part of your policy makers or flaws in the design of > your build system: > > > - BuildRoot should be > %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > > - The BuildRoot must be cleaned at the beginning of %install > > The build system, not the individual RPM's, should ensure that the buildroot > path is unique and clean prior to invoking rpmbuild. Ideally yes, but rpm doesn't do this by default so it has to be done in each package. Even if rpm was changed to do this automatically, packages desiring compatibility with older distributions would still need to clean the buildroot themselves. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 09:05:32 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 04:05:32 -0500 Subject: [Bug 167147] Review Request: Aqsis In-Reply-To: Message-ID: <200602230905.k1N95WRE001554@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Aqsis https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167147 ------- Additional Comments From cgtobi at gmail.com 2006-02-23 04:05 EST ------- I am really sorry about this. I had my practical semester and couldn't take my linux box with me. But I'll soon have access to it again so I can continue my work on the spec/SRPM/RPM. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From chabotc at xs4all.nl Thu Feb 23 09:12:12 2006 From: chabotc at xs4all.nl (Chris Chabot) Date: Thu, 23 Feb 2006 10:12:12 +0100 (CET) Subject: Buildsys / FC4 weirdness Message-ID: <14907.80.95.161.253.1140685932.squirrel@webmail.xs4all.nl> While trying to build a package for FC4 (again, failed a few times yesterday, but was hoping the problems were automagicly fixed) i ran into this error (from the root.log): /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-4-i386-core-454d27f964aff5a45a056e2ee3444e25f8222365/root groupinstall build http://buildsys.fedoraproject.org/plague-results/fedora-4-extras/dap-server/3.5.3-1.fc4/i386/dap-server-3.5.3-1.fc4.i386.rpm: [Errno 4] IOError: HTTP Error 404: Not Found Trying other mirror. Error: failure: dap-server/3.5.3-1.fc4/i386/dap-server-3.5.3-1.fc4.i386.rpm from local: [Errno 256] No more mirrors to try. Full log can be found here: http://buildsys.fedoraproject.org/logs/fedora-4-extras/5171-libtorrent-0.8.5-3.fc4/i386/root.log Can anything be done to fix this, or is there something wrong in my package that could cause this? -- Chris Chabot From mmcgrath at fedoraproject.org Thu Feb 23 09:31:33 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 23 Feb 2006 03:31:33 -0600 Subject: Buildsys / FC4 weirdness In-Reply-To: <14907.80.95.161.253.1140685932.squirrel@webmail.xs4all.nl> References: <14907.80.95.161.253.1140685932.squirrel@webmail.xs4all.nl> Message-ID: <3237e4410602230131x1bcc94bfyce8bf1125060e181@mail.gmail.com> > > Full log can be found here: > http://buildsys.fedoraproject.org/logs/fedora-4-extras/5171-libtorrent-0.8.5-3.fc4/i386/root.log > > Can anything be done to fix this, or is there something wrong in my > package that could cause this? > > -- Chris Chabot > There have been some problems, some have been discussing it in IRC and on the list. The thread created yesterday titled "FC-4 Extras buildsystem breakage details" is probably most relevant. -Mike From bugs.michael at gmx.net Thu Feb 23 10:45:35 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 23 Feb 2006 11:45:35 +0100 Subject: rpms/libtorrent/FC-4 libtorrent.spec,1.3,1.4 In-Reply-To: <200602230901.k1N91GUh009660@cvs-int.fedora.redhat.com> References: <200602230901.k1N91GUh009660@cvs-int.fedora.redhat.com> Message-ID: <20060223114535.617ae1ae.bugs.michael@gmx.net> On Thu, 23 Feb 2006 04:00:44 -0500, Chris Chabot wrote: > Author: chabotc > > Update of /cvs/extras/rpms/libtorrent/FC-4 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv8137 > > Modified Files: > libtorrent.spec > Log Message: > fc4 buildsys bork rebuild > -Release: 2%{?dist} > +Release: 3%{?dist} Just requeue the build job with "plague-client requeue JOBIDHERE". Whenever the buildsys or rawhide breaks and you don't need to modify your package, requeueing works fine. > +* Thu Feb 23 2006 Chris Chabot - 0.8.5-3 > +- Re-tag due to buildsys sillyness > + From bugzilla at redhat.com Thu Feb 23 11:15:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 06:15:56 -0500 Subject: [Bug 182254] Review Request: SS5 In-Reply-To: Message-ID: <200602231115.k1NBFuDF029568@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: SS5 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182254 ------- Additional Comments From matteo.ricchetti at libero.it 2006-02-23 06:15 EST ------- Sorry, I had some trouble during the request process, probably with my internet connection. Tell me if you see any other problems. Thx -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 11:36:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 06:36:53 -0500 Subject: [Bug 180102] Review Request: embryo: A C like scripting language In-Reply-To: Message-ID: <200602231136.k1NBarWH001172@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: embryo: A C like scripting language https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180102 ------- Additional Comments From ivazquez at ivazquez.net 2006-02-23 06:36 EST ------- The BSD license prevents the use of the name of from being used to endorse or promote derived products, whereas this license requires acknowledgement if the source code is not made available. While it isn't MIT per se, it's certainly not BSD. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 12:43:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 07:43:08 -0500 Subject: [Bug 181824] Review Request: gstreamer08 In-Reply-To: Message-ID: <200602231243.k1NCh8WX012761@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gstreamer08 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181824 ------- Additional Comments From ivazquez at ivazquez.net 2006-02-23 07:42 EST ------- - Use --disable-static instead of erasing .a files - Use --disable-rpath - Period at the end of Summary of -devel -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From skvidal at linux.duke.edu Thu Feb 23 14:05:08 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 23 Feb 2006 09:05:08 -0500 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140680016.11840.11.camel@bobcat.mine.nu> References: <1140630242.18225.10.camel@localhost.localdomain> <1140668312.14289.162.camel@mccallum.corsepiu.local> <1140680016.11840.11.camel@bobcat.mine.nu> Message-ID: <1140703508.14667.21.camel@cutter> > Yep, maybe the FE4 repodata wasn't regenerated after dap-server removal? > My retry last night may have been interrupted by net connectivity > glitches. Re-retrying now. I ran the repobuild and repoview before syncing. -sv From bugzilla at redhat.com Thu Feb 23 14:08:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 09:08:16 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602231408.k1NE8GUa030378@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From jeff at ollie.clive.ia.us 2006-02-23 09:08 EST ------- (In reply to comment #23) > (In reply to comment #22) > > I'm still getting some files listed twice: > > > > warning: File listed twice: /etc/ser/dictionary.ser > > warning: File listed twice: /etc/ser/ser.cfg > > warning: File listed twice: /etc/ser/serweb > > warning: File listed twice: /etc/ser/serweb/config.php > > warning: File listed twice: /etc/ser/serweb/config_data_layer.php > > warning: File listed twice: /etc/ser/serweb/config_domain_defaults.php > > warning: File listed twice: /etc/ser/serweb/config_lang.php > > warning: File listed twice: /etc/ser/serweb/config_paths.php > > warning: File listed twice: /etc/ser/serweb/set_domain.php > > I was going to take a look at this but the only spec URL I can see in this > ticket seems to be for the initial submission. Where's the latest one? Andreas has been updating the SPEC/SRPM without bumping the release number. The new package process guideline should be revised to discourage this. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From paul at city-fan.org Thu Feb 23 14:20:55 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 23 Feb 2006 14:20:55 +0000 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140703508.14667.21.camel@cutter> References: <1140630242.18225.10.camel@localhost.localdomain> <1140668312.14289.162.camel@mccallum.corsepiu.local> <1140680016.11840.11.camel@bobcat.mine.nu> <1140703508.14667.21.camel@cutter> Message-ID: <43FDC4C7.9000004@city-fan.org> seth vidal wrote: >>Yep, maybe the FE4 repodata wasn't regenerated after dap-server removal? >>My retry last night may have been interrupted by net connectivity >>glitches. Re-retrying now. > > > I ran the repobuild and repoview before syncing. Strange, because FC4 builds are all failing with: http://buildsys.fedoraproject.org/plague-results/fedora-4-extras/dap-server/3.5.3-1.fc4/i386/dap-server-3.5.3-1.fc4.i386.rpm: [Errno 4] IOError: HTTP Error 404: Not Found Trying other mirror. Error: failure: dap-server/3.5.3-1.fc4/i386/dap-server-3.5.3-1.fc4.i386.rpm from local: [Errno 256] No more mirrors to try. Paul. From bugzilla at redhat.com Thu Feb 23 14:17:38 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 09:17:38 -0500 Subject: [Bug 180345] Review Request: ser - Sip Express Router In-Reply-To: Message-ID: <200602231417.k1NEHcmY032431@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ser - Sip Express Router https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180345 ------- Additional Comments From paul at city-fan.org 2006-02-23 09:17 EST ------- (In reply to comment #24) > (In reply to comment #23) > > (In reply to comment #22) > > > I'm still getting some files listed twice: > > > > > > warning: File listed twice: /etc/ser/dictionary.ser > > > warning: File listed twice: /etc/ser/ser.cfg > > > warning: File listed twice: /etc/ser/serweb > > > warning: File listed twice: /etc/ser/serweb/config.php > > > warning: File listed twice: /etc/ser/serweb/config_data_layer.php > > > warning: File listed twice: /etc/ser/serweb/config_domain_defaults.php > > > warning: File listed twice: /etc/ser/serweb/config_lang.php > > > warning: File listed twice: /etc/ser/serweb/config_paths.php > > > warning: File listed twice: /etc/ser/serweb/set_domain.php > > > > I was going to take a look at this but the only spec URL I can see in this > > ticket seems to be for the initial submission. Where's the latest one? > > Andreas has been updating the SPEC/SRPM without bumping the release number. The > new package process guideline should be revised to discourage this. Agreed. The guidelines should also encourage the addition of changelog information in the spec during the review process. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rc040203 at freenet.de Thu Feb 23 14:25:49 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 23 Feb 2006 15:25:49 +0100 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140703508.14667.21.camel@cutter> References: <1140630242.18225.10.camel@localhost.localdomain> <1140668312.14289.162.camel@mccallum.corsepiu.local> <1140680016.11840.11.camel@bobcat.mine.nu> <1140703508.14667.21.camel@cutter> Message-ID: <1140704749.14289.254.camel@mccallum.corsepiu.local> On Thu, 2006-02-23 at 09:05 -0500, seth vidal wrote: > > Yep, maybe the FE4 repodata wasn't regenerated after dap-server removal? > > My retry last night may have been interrupted by net connectivity > > glitches. Re-retrying now. > > I ran the repobuild and repoview before syncing. No progress so far: http://buildsys.fedoraproject.org/logs/fedora-4-extras/5169-Coin2-2.4.4-3.2.fc4/ Are you using a caching createrepo? Did you verify the cache is in sync with the files? Ralf From bugzilla at redhat.com Thu Feb 23 14:35:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 09:35:56 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602231435.k1NEZuPj004598@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 ------- Additional Comments From jpo at di.uminho.pt 2006-02-23 09:35 EST ------- Folkert, Please do the following: * apply the changes mentioned in comment #11, * drop one of the summary lines (there are two of them), * drop the INSTALL file from the %doc line, * and drop desktop_vendor definition line (not used in the specfile) jpo -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 14:58:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 09:58:53 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602231458.k1NEwrdY009496@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From jwb at redhat.com 2006-02-23 09:58 EST ------- Dependency issue fixed - typo. "<=" should have been ">=" /usr/local/bin/perl references in /lib/tools/ changed to /usr/bin/perl New files: SPEC: http://www.berningeronline.net/gallery2.spec SRPM: http://www.berningeronline.net/gallery2-2.0.2-7.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 15:11:42 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 10:11:42 -0500 Subject: [Bug 182175] Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) In-Reply-To: Message-ID: <200602231511.k1NFBgG1012009@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182175 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-23 10:11 EST ------- (In reply to comment #7) >the point of the rule is to ensure that the license tag in the RPM matches the >actual license of the upstream package; that's something the reviewer needs to >check. >IMHO the presence of the license in the source files itself satisfies >the text. But anyoone whoe only get the binary package doen't recieve a verbatry copy of the license, so you don't aware about you rights given on the license. Event a pointer to a URL is not enough, becouse you don't know, if the URL will be exist in the future and for the other hand, the text publish on the URL may be changend in the funter. But for the reciever of the package only the contest of the license text of the time of packaging may be relevant. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From skvidal at linux.duke.edu Thu Feb 23 15:21:58 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 23 Feb 2006 10:21:58 -0500 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <43FDC4C7.9000004@city-fan.org> References: <1140630242.18225.10.camel@localhost.localdomain> <1140668312.14289.162.camel@mccallum.corsepiu.local> <1140680016.11840.11.camel@bobcat.mine.nu> <1140703508.14667.21.camel@cutter> <43FDC4C7.9000004@city-fan.org> Message-ID: <1140708118.20619.5.camel@cutter> On Thu, 2006-02-23 at 14:20 +0000, Paul Howarth wrote: > seth vidal wrote: > >>Yep, maybe the FE4 repodata wasn't regenerated after dap-server removal? > >>My retry last night may have been interrupted by net connectivity > >>glitches. Re-retrying now. > > > > > > I ran the repobuild and repoview before syncing. > > Strange, because FC4 builds are all failing with: > > http://buildsys.fedoraproject.org/plague-results/fedora-4-extras/dap-server/3.5.3-1.fc4/i386/dap-server-3.5.3-1.fc4.i386.rpm: > [Errno 4] IOError: HTTP Error 404: Not Found > Trying other mirror. > Error: failure: > dap-server/3.5.3-1.fc4/i386/dap-server-3.5.3-1.fc4.i386.rpm from local: > [Errno 256] No more mirrors to try. need more proof: /extras-tree/4/i386/repodata extras64 repodata]$ grep dap-server primary.xml.gz extras64 repodata]$ extras64 is the build master. there is no dap-server for fe4 in the primary.xml.gz please go talk to the people maintaining the internal mirror that is used for the build systems to draw from. I can't help. -sv > Paul. > From Jochen at herr-schmitt.de Thu Feb 23 15:21:17 2006 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 23 Feb 2006 16:21:17 +0100 Subject: Review Rules and staticly linked packages agains dietlibc Message-ID: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, an Bug #176579 I have a review, where soneone will published a package with programs which are staticly linked agains the dietlibc. Becouse I'm unsure about the packaging guidelines I want hear the mind of other contributors on the list. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBQ/3S9k9gByurcX4MEQKYAwCgipWnPBx+As2/ByJdtG6W+KHraWAAoJra kPnS4OaP/5r7Kz8t06IAU2X7 =OESo -----END PGP SIGNATURE----- From skvidal at linux.duke.edu Thu Feb 23 15:22:26 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 23 Feb 2006 10:22:26 -0500 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140704749.14289.254.camel@mccallum.corsepiu.local> References: <1140630242.18225.10.camel@localhost.localdomain> <1140668312.14289.162.camel@mccallum.corsepiu.local> <1140680016.11840.11.camel@bobcat.mine.nu> <1140703508.14667.21.camel@cutter> <1140704749.14289.254.camel@mccallum.corsepiu.local> Message-ID: <1140708146.20619.7.camel@cutter> On Thu, 2006-02-23 at 15:25 +0100, Ralf Corsepius wrote: > On Thu, 2006-02-23 at 09:05 -0500, seth vidal wrote: > > > Yep, maybe the FE4 repodata wasn't regenerated after dap-server removal? > > > My retry last night may have been interrupted by net connectivity > > > glitches. Re-retrying now. > > > > I ran the repobuild and repoview before syncing. > > No progress so far: > http://buildsys.fedoraproject.org/logs/fedora-4-extras/5169-Coin2-2.4.4-3.2.fc4/ > > Are you using a caching createrepo? Did you verify the cache is in sync > with the files? the cache doesn't work like that. See my last message. A mirror is out of sync. -sv From bugzilla at redhat.com Thu Feb 23 15:18:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 10:18:49 -0500 Subject: [Bug 176579] Review Request: ipsvd -- Internet protocol service daemons In-Reply-To: Message-ID: <200602231518.k1NFInvl014461@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ipsvd -- Internet protocol service daemons https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176579 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-23 10:18 EST ------- I have make a post on fedora-extras-list to get an opion from other contribors. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 23 15:21:39 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 10:21:39 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602231521.k1NFLdJA015100@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 ------- Additional Comments From folkert at vanheusden.com 2006-02-23 10:21 EST ------- Done except the man-page thing: the packager told me that if he does that, then rpm complains about found files that are not mentioned in the %files-section. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 15:23:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 10:23:35 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602231523.k1NFNZH7016340@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 ------- Additional Comments From folkert at vanheusden.com 2006-02-23 10:23 EST ------- http://www.vanheusden.com/multitail/multitail-3.8.7-2.src.rpm spec at previous location -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 15:30:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 10:30:47 -0500 Subject: [Bug 175425] Review Request: tile - Modern versions of Tk widget set In-Reply-To: Message-ID: <200602231530.k1NFUlPB018153@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: tile - Modern versions of Tk widget set https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175425 wart at kobold.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From wart at kobold.org 2006-02-23 10:30 EST ------- Imported and built on devel. Thanks! -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Feb 23 15:43:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 10:43:47 -0500 Subject: [Bug 181824] Review Request: gstreamer08 In-Reply-To: Message-ID: <200602231543.k1NFhlSs021439@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gstreamer08 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181824 ------- Additional Comments From bdpepple at ameritech.net 2006-02-23 10:43 EST ------- Spec Url: http://piedmont.homelinux.org/fedora/gstreamer/gstreamer08.spec SRPM Url: http://piedmont.homelinux.org/fedora/gstreamer/gstreamer08-0.8.12-2.src.rpm Description: * Thu Feb 23 2006 Brian Pepple - 0.8.12-2 - Use --disable-rpath & --disable-static. - Drop period in devel summary. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From notting at redhat.com Thu Feb 23 15:50:47 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 23 Feb 2006 10:50:47 -0500 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140678346.11840.5.camel@bobcat.mine.nu> References: <1140630242.18225.10.camel@localhost.localdomain> <20060222195124.GC2885@free.fr> <604aa7910602221209y35c3fb81g244876fde9976fef@mail.gmail.com> <1140644888.8388.28.camel@bobcat.mine.nu> <20060222223024.GD3543@devserv.devel.redhat.com> <1140678346.11840.5.camel@bobcat.mine.nu> Message-ID: <20060223155047.GA1807@devserv.devel.redhat.com> Ville Skytt? (ville.skytta at iki.fi) said: > > > I don't think there's a need for such a special case. Packages simply > > > must not provide things they don't really intend to "export". > > > > However, attempting to filter provides by turning off RPM's > > internal generator and using scripts removes multilib tagging > > and similar features. > > ...which is an example of why a better way to do it, like the > NoProvides: tag as suggested by Chris in this thread and others > elsewhere (eg. https://bugzilla.redhat.com/126878), is needed. Yes, just saying that there's no good way to do it *now*. :/ Bill From bugzilla at redhat.com Thu Feb 23 15:50:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 10:50:10 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602231550.k1NFoAui022819@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 ------- Additional Comments From jpo at di.uminho.pt 2006-02-23 10:50 EST ------- (In reply to comment #17) > Done except the man-page thing: the packager told me that if he does that, then > rpm complains about found files that are not mentioned in the %files-section. Never saw that complain. Which version of rpm/distro is he using? For RedHat/Fedora distros is safe to remove the %doc tag from man pages file entries. You also forgot to add the changelog entry (and the last one is missing the release entry; rpmlint complains about these omissions). It is also custom to mention the bugzilla entry in changelog entries. jpo -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From pertusus at free.fr Thu Feb 23 15:52:52 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 23 Feb 2006 16:52:52 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> Message-ID: <20060223155252.GK2730@free.fr> > an Bug #176579 I have a review, where soneone will published a > package with programs which are staticly linked agains the > dietlibc. > > Becouse I'm unsure about the packaging guidelines I want hear the > mind of other contributors on the list. It seems to be aginst the packaging guidelines. However it is a very specific case where static linking is advocated for speed reasons. If I am not wrong, the reasons to link dynamically because of the implementation of some glibc functions doesn't hold. However the security issue is still there. So, in that precise case, the choice is between security and efficiency. I see 2 possibilities 1) add a benchmark to the review (speed measurement for both cases, and memory footprint) that demonstrates a clear win with static libs. or 2) make two packages or 2 executables in the same package, one with the static and the other with the shared, and give the original name to the shared, and call the other by a name that helps understand that it is statically compiled. In any case if in the end there is something statically linked it should be advertised in the installed files (in a README or anywhere else). -- Pat From bugzilla at redhat.com Thu Feb 23 15:56:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 10:56:11 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602231556.k1NFuBRZ024047@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 ------- Additional Comments From udovdh at xs4all.nl 2006-02-23 10:56 EST ------- I am using FC4. rpm 4.4.1. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 16:07:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 11:07:18 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602231607.k1NG7ISd026516@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 ------- Additional Comments From tibbs at math.uh.edu 2006-02-23 11:07 EST ------- Too many people in this review.... I get clean builds after taking out the %doc tag, but just on the file in %{_mandir}. You will certainly see problems if you remove it from the other line. Jose's being picky about change "make" to a macro, but everything else in the spec is using them so it makes sense for consistency. He's right about the changelogs, they should be kept consistent and the release tag needs to appear for each change. I would like to get this package done and out the door. With Jose's last patch, I'm ready to approve. Let me do a couple of final mock builds first. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From andy at smile.org.ua Thu Feb 23 16:26:08 2006 From: andy at smile.org.ua (Andy Shevchenko) Date: Thu, 23 Feb 2006 18:26:08 +0200 Subject: Anjuta - change of maintainer In-Reply-To: <20060222210435.20f0ea47.bugs.michael@gmx.net> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602201500w25dcc9dcp3ba8f1db893e7f7a@mail.gmail.com> <1140476701.2971.3.camel@T7.Linux> <13dbfe4f0602201520v21ee0d3br46b04df50eea092b@mail.gmail.com> <1140477835.2971.5.camel@T7.Linux> <13dbfe4f0602211544g643afe6ev3dd6b3419c3e1f6c@mail.gmail.com> <1140565626.31940.14.camel@T7.Linux> <13dbfe4f0602220604l1f30f6b6w1511f42ad780fa89@mail.gmail.com> <1140622767.31392.33.camel@mrwibble.mrwobble> <20060222183059.32178be3.bugs.michael@gmx.net> <13dbfe4f0602221003l463d483fp99ed352b8f5d189d@mail.gmail.com> <20060222210435.20f0ea47.bugs.michael@gmx.net> Message-ID: <43FDE220.5090804@smile.org.ua> Michael Schwendt ?????: > A packaging bug. One time FreshRPMS people check and drop Epoch to zero in all shipped files. I think it's like copper. One side is a manual update, another side is a more convenient behaviour (may be). -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From bugzilla at redhat.com Thu Feb 23 16:33:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 11:33:47 -0500 Subject: [Bug 180430] Review Request: Tong - a game of skill In-Reply-To: Message-ID: <200602231633.k1NGXl7u001867@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Tong - a game of skill https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180430 ------- Additional Comments From tibbs at math.uh.edu 2006-02-23 11:33 EST ------- I found build failures in mock as well, but that was when I was mistakenly using %{__cc}. Everything builds fine with the SRPM you sent and tests out OK on an i386 FC4 machine. So, I think the last cleanup is getting rid of tong.sh since you aren't using it any longer. You might also want to either use $RPM_OPT_FLAGS instead of %{optflags} just to be consistent with your last changelog entry. Other than that I think it's ready to go. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From enrico.scholz at informatik.tu-chemnitz.de Thu Feb 23 17:04:25 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 23 Feb 2006 18:04:25 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <20060223155252.GK2730@free.fr> (Patrice Dumas's message of "Thu, 23 Feb 2006 16:52:52 +0100") References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> Message-ID: <87fymavwfa.fsf@kosh.bigo.ensc.de> pertusus at free.fr (Patrice Dumas) writes: >> an Bug #176579 I have a review, where soneone will published a >> package with programs which are staticly linked agains the >> dietlibc. >> >> Becouse I'm unsure about the packaging guidelines I want hear the >> mind of other contributors on the list. > > It seems to be aginst the packaging guidelines. I do not see a violation there. Packaging guidelines are stating | Also applications linking against libraries should as far as possible | link against shared libraries not static versions. There is a "should" but not a "must" so it is possible for a packager to link statically when there are good reasons. Because in this case you have only disadvantages when linking against glibc without having a single gain, the choice is easy: link against dietlibc. > However it is a very specific case where static linking is advocated for > speed reasons. If I am not wrong, the reasons to link dynamically because > of the implementation of some glibc functions doesn't hold. However the > security issue is still there. Which security issues? Tools in 'ipvsd' are doing only some syscalls resp. the (perhaps) exploitable code sits in ipvsd and not in dynamical linkable libraries. The 'ipvsd' code itself is so small that it can be audited completely and you can protect against attacks by reviewing the code instead of trusting into things like non-exec stack and randomized heap which help against some, but not all attacks. > So, in that precise case, the choice is between security and efficiency. No, the choice is between ??? (sorry, I do not have an idea which positive property would be brought in by 'glibc' linking) against efficiency and building 'ipvsvd' with the tools it was designed for. Enrico From adrian at lisas.de Thu Feb 23 17:08:05 2006 From: adrian at lisas.de (Adrian Reber) Date: Thu, 23 Feb 2006 18:08:05 +0100 Subject: Orphaning cvsup Message-ID: <20060223170805.GA2318@lisas.de> I am orphaning cvsup and I will request removal of cvsup from the devel tree. cvsup doesn't build on the development tree and did never build on x86_64. Adrian From bugzilla at redhat.com Thu Feb 23 17:04:23 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 12:04:23 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602231704.k1NH4NMQ011049@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 ------- Additional Comments From folkert at vanheusden.com 2006-02-23 12:04 EST ------- Hopefully this one is the final, fingers crossed! :-) http://www.vanheusden.com/multitail/multitail.spec http://www.vanheusden.com/multitail/multitail-3.8.7-3.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 17:11:40 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 12:11:40 -0500 Subject: [Bug 182415] Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project In-Reply-To: Message-ID: <200602231711.k1NHBe0c012922@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182415 ------- Additional Comments From andy at smile.org.ua 2006-02-23 12:11 EST ------- This is my first package and I need a sponsor. P.S. Sorry for dups. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From fedora at camperquake.de Thu Feb 23 17:20:19 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 23 Feb 2006 18:20:19 +0100 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140708118.20619.5.camel@cutter> References: <1140630242.18225.10.camel@localhost.localdomain> <1140668312.14289.162.camel@mccallum.corsepiu.local> <1140680016.11840.11.camel@bobcat.mine.nu> <1140703508.14667.21.camel@cutter> <43FDC4C7.9000004@city-fan.org> <1140708118.20619.5.camel@cutter> Message-ID: <20060223182019.3bc83d68@dhcp05.addix.net> Hi. On Thu, 23 Feb 2006 10:21:58 -0500, seth vidal wrote: > need more proof: > /extras-tree/4/i386/repodata > extras64 repodata]$ grep dap-server primary.xml.gz > extras64 repodata]$ I am sure this is just a mispasting or such, but you did grep the non-compressed file for sure? From bugzilla at redhat.com Thu Feb 23 17:17:04 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 12:17:04 -0500 Subject: [Bug 180430] Review Request: Tong - a game of skill In-Reply-To: Message-ID: <200602231717.k1NHH4ed014505@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Tong - a game of skill https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180430 ------- Additional Comments From wart at kobold.org 2006-02-23 12:16 EST ------- Only the spec file has changed in this latest package: http://www.kobold.org/~wart/fedora/tong-1.0-6.src.rpm http://www.kobold.org/~wart/fedora/tong.spec I think all issues have finally been addressed. FWIW, I've requested upstream that the game data files be split into a separate tarball, and will forward the GAME_DATA_DIR patch as well. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From skvidal at linux.duke.edu Thu Feb 23 17:23:45 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 23 Feb 2006 12:23:45 -0500 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <20060223182019.3bc83d68@dhcp05.addix.net> References: <1140630242.18225.10.camel@localhost.localdomain> <1140668312.14289.162.camel@mccallum.corsepiu.local> <1140680016.11840.11.camel@bobcat.mine.nu> <1140703508.14667.21.camel@cutter> <43FDC4C7.9000004@city-fan.org> <1140708118.20619.5.camel@cutter> <20060223182019.3bc83d68@dhcp05.addix.net> Message-ID: <1140715426.20619.50.camel@cutter> On Thu, 2006-02-23 at 18:20 +0100, Ralf Ertzinger wrote: > Hi. > > On Thu, 23 Feb 2006 10:21:58 -0500, seth vidal wrote: > > > need more proof: > > /extras-tree/4/i386/repodata > > extras64 repodata]$ grep dap-server primary.xml.gz > > extras64 repodata]$ > > I am sure this is just a mispasting or such, but you > did grep the non-compressed file for sure? yes, sorry - I did type it in wrong. However, I did verify in the file that dap-server does not exist in there. thanks -sv From bugzilla at redhat.com Thu Feb 23 17:23:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 12:23:09 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602231723.k1NHN9GM016574@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 ------- Additional Comments From jpo at di.uminho.pt 2006-02-23 12:23 EST ------- PUBLISH ++ The above line gives my approval (one vote for approval). As there is at least one more reviewer he will also cast his vote. As Jason has taken the lead in the review process he will be the one given the final approval. /jpo Just a picky note in the second changelog entry - the update statement release number doesn't match the the one in the changelog entry header (2 != 3). This can be corrected later. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From Jochen at herr-schmitt.de Thu Feb 23 17:28:10 2006 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 23 Feb 2006 18:28:10 +0100 Subject: Some comment to Extras/Schedule/SecurityPolicy Message-ID: <0ML29c-1FCKGO2sGq-0003FM@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, after reading http://www.fedoraproject.org/wiki/Extras/Schedule/SecurityPolicy I have some comments about this topic. 1.) Secruity SIG members should be norminate by the FESCo. 2) If a contributor listed at vacation (see http://www.fedoraproject.org/wiki/Vacation) securiy SiG should not waiting. Instead he should to try fixing the security issue and make the necessary actions. Ths maintainer of the package should inform about the acrions via email to avoid confusion. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBQ/3wtE9gByurcX4MEQLjIwCgkLI12iaA+ZvcMSCdPCwH81GTs/cAoNoZ AYRJFBePnlrfOQ6mDrq2QoXP =Yb5C -----END PGP SIGNATURE----- From j.w.r.degoede at hhs.nl Thu Feb 23 17:39:06 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 23 Feb 2006 18:39:06 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <87fymavwfa.fsf@kosh.bigo.ensc.de> References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> Message-ID: <43FDF33A.6000503@hhs.nl> Hi all, I believe this is a very clear case, upstream does _not_ advise the use of dietlibc, their default makefile and install instructions don't use it. They do give instructions on howto use it if you want, but they don't _advise_ it. So staying with the Fedora upstream manta I say don't use dietlibc, also there has been much discussion about completly removing all static libs from Fedora, both core and extras have already dropped many static libs. Why? Because static linking is BAD for lots of reasons, many the same reasons why the packaging guidelines state that packages should not compile and (staticly) link against their own version fo system libs, that is exactly what you're doing now linking against an own version of system libs. Please go read: http://fedoraproject.org/wiki/Packaging/Guidelines (again if nescesarry) And pay special attention to especially 1.14 and 1.15 where is written should, one _should_ read must unless there are good reasons why this is the exception that confirms the rule. Also notice: "Static libraries should only be included in exceptional circumstances." This is not an exceptional circumstance a small gain in speed and footprint does not warrant exception. I don't know if this is still possible now that FE has become bigger and more officialy organised but some time ago a rule was that if one packager vetoed a package it couldn't get in. So hereby I veto inclusion / approval of ipvsd when staticly linked against anything, its not nescesarry, has no real gain (modern PC's are _fast_ and have _lots_ of mem), and is not even advised by upstream. Regards, Hans From bugzilla at redhat.com Thu Feb 23 17:42:04 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 12:42:04 -0500 Subject: [Bug 182122] Review Request: multitail In-Reply-To: Message-ID: <200602231742.k1NHg4q4020880@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: multitail https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182122 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From tibbs at math.uh.edu 2006-02-23 12:41 EST ------- Yes, I agree, but do be careful about the changelog entries when you check in. Approved. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 17:43:37 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 12:43:37 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602231743.k1NHhbT0021257@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From dgregor at redhat.com 2006-02-23 12:43 EST ------- I tried a minimal install using the default values from the installer. $ sudo rpm -ivh gallery2-2.0.2-7.noarch.rpm gallery2-gd-2.0.2-7.noarch.rpm gallery2-classic-2.0.2-7.noarch.rpm During Step 2 of the installer, the following files failed the "Integrity Chack" because they were modified: lib/tools/bin/extractClassXml.pl lib/tools/bin/filterManifests.pl lib/tools/bin/getIllegalFunctions.pl lib/tools/bin/makeManifest.pl lib/tools/po/extract.pl lib/tools/uml/make-java-classes.pl Step 4: Can a /srv/gallery2 directory (owned by the apache user/group) be included in the gallery2 RPM and used as the default here? Step 7: A blank /var/www/html/gallery2/config.php could be included in the RPM Step 8: The first time I ran the install I got this error: Error: Failed to load matrix theme, this is the error stack trace; Error (ERROR_BAD_PARAMETER) : /var/www/html/gallery2/modules/core/classes/helpers/../../../../themes/matrix/theme.incin modules/core/classes/helpers/GalleryPluginHelper_simple.class at line 105 (CoreModule::error) I then installed gallery2-matrix and reran the install. This time, at step 8 I got: Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 125 bytes) in /var/www/html/gallery2/lib/adodb/adodb-lib.inc.php on line 926 It had warned me about this in step 2 of the installer. http://codex.gallery2.org/index.php/Gallery1:FAQ#Why_do_I_get_the_error_Allowed_memory_size_of_Xxx_bytes_exhausted.3F We can create a gallery2-specific value for this by adding an entry (e.g. php_value memory_limit 17000000) in /var/www/html/gallery2/.htaccess. This also required creating a /etc/httpd/conf.d/gallery2.conf file with the following contents: AllowOverride Options -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From enrico.scholz at informatik.tu-chemnitz.de Thu Feb 23 17:53:37 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 23 Feb 2006 18:53:37 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <43FDF33A.6000503@hhs.nl> (Hans de Goede's message of "Thu, 23 Feb 2006 18:39:06 +0100") References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <43FDF33A.6000503@hhs.nl> Message-ID: <87bqwyvu5a.fsf@kosh.bigo.ensc.de> j.w.r.degoede at hhs.nl (Hans de Goede) writes: > I believe this is a very clear case, upstream does _not_ advise the > use of dietlibc, their default makefile and install instructions don't > use it. They do give instructions on howto use it if you want, but > they don't _advise_ it. oh, come on. Almost none of the other packages' upstream _advises_ to use the default RPM_OPT_FLAGS, but they are/should be used in all packages nevertheless. Chosing the best flags and compiler is task of the packager. And in this case, 'dietlibc' is the best choice. > Why? Because static linking is BAD for lots of reasons, Please tell me, why static linking is BAD in *this* case. > many the same reasons why the packaging guidelines state that > packages should not compile and (staticly) link against their own > version fo system libs, The "should" in the packaging guidelines was intentionally. It leaves room to link statically when this is the better choice and in this case, dietlibc is the better choice. > that is exactly what you're doing now linking against an own version > of system libs. ??? I do not see where 'ipvsd' links against a "local copy of a library that exists on the system". > is the exception that confirms the rule. Also notice: > "Static libraries should only be included in exceptional circumstances." 'ipvsd' does not provide static libraries. > (modern PC's are _fast_ and have _lots_ of mem), That's a really stupid argument... when there are ways to make things work better, these ways should be gone. Again: linking against 'dietlibc' has only advantages for 'ipvsd'. Enrico From bugzilla at redhat.com Thu Feb 23 17:51:29 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 12:51:29 -0500 Subject: [Bug 180430] Review Request: Tong - a game of skill In-Reply-To: Message-ID: <200602231751.k1NHpTng022805@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Tong - a game of skill https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180430 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From tibbs at math.uh.edu 2006-02-23 12:51 EST ------- Cool. Approved. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 17:53:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 12:53:15 -0500 Subject: [Bug 176579] Review Request: ipsvd -- Internet protocol service daemons In-Reply-To: Message-ID: <200602231753.k1NHrFUu023200@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ipsvd -- Internet protocol service daemons https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176579 ------- Additional Comments From Jochen at herr-schmitt.de 2006-02-23 12:53 EST ------- Hans de Goede wrote in https://www.redhat.com/archives/fedora-extras-list/2006-February/msg01743.html that the upstream author doesn't advice to link staticly agains the dietlibc. So I unfortunately can't approve your package until you will have changed it in according of rules 1.14 and 1.5 at https://www.fedoraproject.org/wiki/Packaging/Guidelines -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From j.w.r.degoede at hhs.nl Thu Feb 23 18:17:34 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 23 Feb 2006 19:17:34 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <87bqwyvu5a.fsf@kosh.bigo.ensc.de> References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <43FDF33A.6000503@hhs.nl> <87bqwyvu5a.fsf@kosh.bigo.ensc.de> Message-ID: <43FDFC3E.7010002@hhs.nl> Enrico Scholz wrote: > j.w.r.degoede at hhs.nl (Hans de Goede) writes: > > >> Why? Because static linking is BAD for lots of reasons, > > Please tell me, why static linking is BAD in *this* case. > I just did a quick grep for your email in owners.list and I'm amazed by the fact that someone who maintains as many security related packages as you needs to ask. Even in glibc which is widely used and audited security holes turn up quite regular, so this will most probably happen for dietlibc atleast as often as for glibc. When this happens we don't want to have to track which packages all are staticly linked against it. With the SSL stuff in ipvsd chances for holes are even bigger, so I would not only like to argue that ipvsd should not staticly link against dietlibc, I would like to add that I believe that the ssl lib used by ipvsd belongs in a seperate package (it has a seperate upstream) and that this seperate package should only contain .so files. >> many the same reasons why the packaging guidelines state that >> packages should not compile and (staticly) link against their own >> version fo system libs, > > The "should" in the packaging guidelines was intentionally. It leaves > room to link statically when this is the better choice and in this case, > dietlibc is the better choice. > Not when this is a better choice, it doesn't say when this is a better choice anywhere, it says "Static libraries should only be included in exceptional circumstances." I guess I can come up with a zillion more small programs which will be smaller and faster with dietlibc, thats not what this is about, the should is there in case its impossible to avoid this without tons of work. Not for this silly it saves a few kB case. > >> that is exactly what you're doing now linking against an own version >> of system libs. > > ??? I do not see where 'ipvsd' links against a "local copy of a library > that exists on the system". > Its staticly linked, this it gets its own private copy hardcoded into the binary. A copy which is functional and api compatible with the system c library, so yes this is linking against a "local copy of a library that exists on the system" > >> is the exception that confirms the rule. Also notice: >> "Static libraries should only be included in exceptional circumstances." > > 'ipvsd' does not provide static libraries. > Nor should it use them, thats the whole point, we don't want to provide them because we don't want apps using them. > >> (modern PC's are _fast_ and have _lots_ of mem), > > That's a really stupid argument... No its not, as my paid fulltime job I write code for computers with 8 kB of "harddisk" and 512 bytes of ram I know when every byte matters and when it doesn't. If you really care about speed and foodprint join a project like: http://live.gnome.org/MemoryReduction That is where the real gain is to be had. > when there are ways to make things > work better, these ways should be gone. Again: linking against 'dietlibc' > has only advantages for 'ipvsd'. > When the tradeof is a small gain in speed and footprint versus maintainability and security then the disadvantages of your choice outway the advantages. So saying that there are only advantages is false as there are clear disadvantages. But this entire discussion is mood anyways. We have clear guidelines and you are in clear (and unnescesarry) violation of the guidelines. If you don't like the guidelines propose to FESco to change them, don't just do as you want under an exception which is for "exceptional circumstances." which isclearly not the case here. Regards, Hans From pertusus at free.fr Thu Feb 23 18:29:42 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 23 Feb 2006 19:29:42 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <87fymavwfa.fsf@kosh.bigo.ensc.de> References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> Message-ID: <20060223182942.GQ2730@free.fr> > Which security issues? Tools in 'ipvsd' are doing only some syscalls > resp. the (perhaps) exploitable code sits in ipvsd and not in dynamical > linkable libraries. The 'ipvsd' code itself is so small that it can be Why couldn't there be an issue with a bug in dietlibc that opens a security hole in ipvsd? I haven't read the code, but I can't see how it is possible. > No, the choice is between ??? (sorry, I do not have an idea which > positive property would be brought in by 'glibc' linking) against > efficiency and building 'ipvsvd' with the tools it was designed for. You cannot rule out security issues in the library easily as long as the library is used, and ipvsd is a networking app, so security matters. I still agree that the increase in efficiency could be worth the risk of security issues. -- Pat From bugzilla at redhat.com Thu Feb 23 18:35:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 13:35:36 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602231835.k1NIZaib031622@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From jwb at redhat.com 2006-02-23 13:35 EST ------- On the first issue, this is due to changing /usr/local/bin/perl to /usr/bin/perl. The MAIFEST file can only be rebuilt against a CVS checked-out tree, as opposed to a versioned tarball. Is using a CVS tree (bundled up into a tarball, of course) acceptable for the source? If so, how do I specify a full URL for that in the Source0 tag? I'm working on the other issues noticed now. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 18:38:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 13:38:44 -0500 Subject: [Bug 173719] Review Request: openmpi - a new MPI implementation In-Reply-To: Message-ID: <200602231838.k1NIciTm032380@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 jvdias at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From jvdias at redhat.com 2006-02-23 13:38 EST ------- OK, openmpi-1.0.1-1.fe5 is now submitted to FC-5 Extras - use with lam-7.1.1-11+ from FC-5 . -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From Christian.Iseli at licr.org Thu Feb 23 18:50:20 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 23 Feb 2006 19:50:20 +0100 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: Your message of "Thu, 23 Feb 2006 12:23:45 EST." <1140715426.20619.50.camel@cutter> Message-ID: <200602231850.k1NIoVqf017922@mx1.redhat.com> Hmm, well *something* is still trying to grab dap-server when building FC-4 packages: ... /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-4-i386-core-f3d8ee5b0fb48da79db7f4813c95303e142357d6/root groupinstall build http://buildsys.fedoraproject.org/plague-results/fedora-4-extras/dap-server/3.5.3-1.fc4/i386/dap-server-3.5.3-1.fc4.i386.rpm: [Errno 4] IOError: HTTP Error 404: Not Found Trying other mirror. Error: failure: dap-server/3.5.3-1.fc4/i386/dap-server-3.5.3-1.fc4.i386.rpm from local: [Errno 256] No more mirrors to try. Cleaning up... Done. From wart at kobold.org Thu Feb 23 19:03:26 2006 From: wart at kobold.org (Michael Thomas) Date: Thu, 23 Feb 2006 11:03:26 -0800 Subject: [Fwd: Build Error (Job 5181): tong-1_0-6_fc5 on fedora-development-extras] Message-ID: <43FE06FE.2000509@kobold.org> Who is the build system administrator that I need to contact about this build failure? The package built fine, and according to the logs, files were created. But the build system still claimed that it couldn't download the result files. --Wart -------- Original Message -------- Subject: Build Error (Job 5181): tong-1_0-6_fc5 on fedora-development-extras Date: Thu, 23 Feb 2006 13:59:55 -0500 (EST) From: buildsys at fedoraproject.org To: wart at kobold.org Job failed on arch i386: couldn't download result files from builder 'https://hammer1.fedora.redhat.com:8888'. Please contact the build system administrator. Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/5181-tong-1.0-6.fc5/ ------------------------------------------------- + export DOCDIR + rm -rf /var/tmp/tong-1.0-6.fc5-root-mockbuild/usr/share/doc/tong-1.0 + /bin/mkdir -p /var/tmp/tong-1.0-6.fc5-root-mockbuild/usr/share/doc/tong-1.0 + cp -pr COPYING CREDITS making-of.txt /var/tmp/tong-1.0-6.fc5-root-mockbuild/usr/share/doc/tong-1.0 + exit 0 Requires(interp): /bin/sh /bin/sh Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires(post): /bin/sh Requires(postun): /bin/sh Requires: libSDL-1.2.so.0 libSDL_image-1.2.so.0 libSDL_mixer-1.2.so.0 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.4) libgcc_s.so.1 libgcc_s.so.1(GCC_3.0) libm.so.6 libm.so.6(GLIBC_2.0) libpthread.so.0 libstdc++.so.6 libstdc++.so.6(CXXABI_1.3) libstdc++.so.6(GLIBCXX_3.4) tong-data Processing files: tong-data-1.0-6.fc5 Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Processing files: tong-debuginfo-1.0-6.fc5 Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/tong-1.0-6.fc5-root-mockbuild warning: Could not canonicalize hostname: hammer1.fedora.redhat.com Wrote: /builddir/build/RPMS/tong-1.0-6.fc5.i386.rpm Wrote: /builddir/build/RPMS/tong-data-1.0-6.fc5.i386.rpm Wrote: /builddir/build/RPMS/tong-debuginfo-1.0-6.fc5.i386.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.88095 + umask 022 + cd /builddir/build/BUILD + cd tong-1.0 + rm -rf /var/tmp/tong-1.0-6.fc5-root-mockbuild + exit 0 Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.88095 + umask 022 + cd /builddir/build/BUILD + rm -rf tong-1.0 + exit 0 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From dcbw at redhat.com Thu Feb 23 19:05:33 2006 From: dcbw at redhat.com (Dan Williams) Date: Thu, 23 Feb 2006 14:05:33 -0500 Subject: [Fwd: Build Error (Job 5181): tong-1_0-6_fc5 on fedora-development-extras] In-Reply-To: <43FE06FE.2000509@kobold.org> References: <43FE06FE.2000509@kobold.org> Message-ID: <1140721534.10877.0.camel@dhcp83-74.boston.redhat.com> On Thu, 2006-02-23 at 11:03 -0800, Michael Thomas wrote: > Who is the build system administrator that I need to contact about this > build failure? The package built fine, and according to the logs, files > were created. But the build system still claimed that it couldn't > download the result files. SSL + timeouts, likely. I've requeued the job, and have increased the # of download attempts for individual files from 5 to 10 one the server. Dan From ville.skytta at iki.fi Thu Feb 23 19:20:43 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 23 Feb 2006 21:20:43 +0200 Subject: Orphaning cvsup In-Reply-To: <20060223170805.GA2318@lisas.de> References: <20060223170805.GA2318@lisas.de> Message-ID: <1140722443.11840.36.camel@bobcat.mine.nu> On Thu, 2006-02-23 at 18:08 +0100, Adrian Reber wrote: > I am orphaning cvsup and I will request removal of cvsup from the devel > tree. cvsup doesn't build on the development tree and did never build on > x86_64. FYI to anyone interested in cvsup, the FreeBSD folks are rewriting it in C, and it is said to already work on 64-bit archs too. http://www.mu.org/~mux/csup.html From enrico.scholz at informatik.tu-chemnitz.de Thu Feb 23 19:36:36 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 23 Feb 2006 20:36:36 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <43FDFC3E.7010002@hhs.nl> (Hans de Goede's message of "Thu, 23 Feb 2006 19:17:34 +0100") References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <43FDF33A.6000503@hhs.nl> <87bqwyvu5a.fsf@kosh.bigo.ensc.de> <43FDFC3E.7010002@hhs.nl> Message-ID: <87vev5hnp7.fsf@kosh.bigo.ensc.de> j.w.r.degoede at hhs.nl (Hans de Goede) writes: >>> Why? Because static linking is BAD for lots of reasons, >> Please tell me, why static linking is BAD in *this* case. > > I just did a quick grep for your email in owners.list and I'm amazed by > the fact that someone who maintains as many security related packages > as you needs to ask. Perhaps because I understand the reasons behind dynamic linking instead of repeating things blindly without knowing why they are there? Ok, let's look at 'ipsvd'; when linking the 'tcpsvd' program dynamically (a '--without dietlibc' rpm switch should do it), we create a binary which imports | __errno_location | __fxstat | __gmon_start__ | __libc_start_main | __xstat | _exit | accept | bind | close | connect | execve | fcntl | fork | free | getgrnam | gethostname | getpeername | getpid | getppid | getpwnam | getservbyname | getsockname | gettimeofday | listen | lseek | malloc | mmap | munmap | open | poll | read | recv | send | setgid | setgroups | setsockopt | setuid | sigaction | sigaddset | sigemptyset | sigprocmask | sigsuspend | socket | time | unlink | unlink | waitpid | write [The static linked dietlibc version will not use more of these functions.] 'malloc' and 'free' are the only higher level functions, all other functions are simple syscall wrappers and ARE implemented unexploitable (the related code are perhaps 20 assembly lines). It is right that the dietlibc 'malloc(3)' implementation suffered the known integer overflow some time ago. But in the meantime, the related 162 lines of code in dietlibc have been reviewed several times so it can be assumed as error-free. So the when-static-library-contains-flaw-we-have-to-rebuild-everything argument does not hold because the "when-static-library-contains-flaw" condition can never occur in *this* case. I admit that there are problems in dietlibc but none of them are interesting in *this* case. > Even in glibc which is widely used and audited security holes turn up > quite regular, so this will most probably happen for dietlibc atleast > as often as for glibc. When this happens we don't want to have to track > which packages all are staticly linked against it. With the SSL stuff > in ipvsd chances for holes are even bigger, so I would not only like to > argue that ipvsd should not staticly link against dietlibc, 1. package can not be shipped with 'matrixssl' due to licensing issues; therefore, 'matrixssl' has nothing todo with the *current* issue. 2. 'ipvsd' supports only static linking of 'matrixssl' >>> many the same reasons why the packaging guidelines state that >>> packages should not compile and (staticly) link against their own >>> version fo system libs, >> The "should" in the packaging guidelines was intentionally. It leaves >> room to link statically when this is the better choice and in this case, >> dietlibc is the better choice. >> > > Not when this is a better choice, it doesn't say when this is a better > choice anywhere, it says "Static libraries should only be included in > exceptional circumstances." This sentence means packaging of %_libdir/*.a files but NOT linking against static libraries. > I guess I can come up with a zillion more small programs which will be > smaller and faster with dietlibc, thats not what this is about, the > should is there in case its impossible to avoid this without tons of > work. It really depends. It's hard to find a reason to link programs like | int main() { write(1, "Hello world\n", 12); } dynamically against glibc instead of using dietlibc. But I would not write a bugreport only because of this inefficiency. >>> that is exactly what you're doing now linking against an own version >>> of system libs. >> ??? I do not see where 'ipvsd' links against a "local copy of a >> library that exists on the system". >> > > Its staticly linked, this it gets its own private copy hardcoded into > the binary. "local copy" in this sentence means a library which is both shipped in the package and exists in the system already. 'matrixssl' might be an example in this case when it would exist in FE already. >>> is the exception that confirms the rule. Also notice: >>> "Static libraries should only be included in exceptional circumstances." >> 'ipvsd' does not provide static libraries. > > Nor should it use them, That is not stated there and was never an intention of this paragraph which covers packages shipping libraries only. 'ipvsd' is not such a package. >> when there are ways to make things work better, these ways should be >> gone. Again: linking against 'dietlibc' has only advantages for >> 'ipvsd'. > > When the tradeof is a small gain in speed and footprint versus > maintainability and security then the disadvantages of your choice > outway the advantages. I do not see how this is related to *this* case and do not know what you mean with "maintainablility". The "security" argument was disproved above. > So saying that there are only advantages is false as there are clear > disadvantages. Please tell me the disadvantages in *this* case. > But this entire discussion is mood anyways. We have clear guidelines and > you are in clear (and unnescesarry) violation of the guidelines. Where does 'ipvsd' violate the guidelines? Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 482 bytes Desc: not available URL: From wart at kobold.org Thu Feb 23 19:42:05 2006 From: wart at kobold.org (Michael Thomas) Date: Thu, 23 Feb 2006 11:42:05 -0800 Subject: [Fwd: Build Error (Job 5181): tong-1_0-6_fc5 on fedora-development-extras] In-Reply-To: <1140721534.10877.0.camel@dhcp83-74.boston.redhat.com> References: <43FE06FE.2000509@kobold.org> <1140721534.10877.0.camel@dhcp83-74.boston.redhat.com> Message-ID: <43FE100D.80204@kobold.org> Dan Williams wrote: > On Thu, 2006-02-23 at 11:03 -0800, Michael Thomas wrote: > >>Who is the build system administrator that I need to contact about this >>build failure? The package built fine, and according to the logs, files >>were created. But the build system still claimed that it couldn't >>download the result files. > > > SSL + timeouts, likely. I've requeued the job, and have increased the # > of download attempts for individual files from 5 to 10 one the server. It happened again: http://buildsys.fedoraproject.org/build-status/job.psp?uid=5181 http://buildsys.fedoraproject.org/logs/fedora-development-extras/5181-tong-1.0-6.fc5/ --Wart -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From bugzilla at redhat.com Thu Feb 23 19:51:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 14:51:01 -0500 Subject: [Bug 176579] Review Request: ipsvd -- Internet protocol service daemons In-Reply-To: Message-ID: <200602231951.k1NJp1Xx018146@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ipsvd -- Internet protocol service daemons https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176579 ------- Additional Comments From enrico.scholz at informatik.tu-chemnitz.de 2006-02-23 14:50 EST ------- Upstream author mentions 'dietlibc' explicitly several times and praises the small memory footprint. So, I think it is adviced by the upstream author. It does not violate against rule 1.14 of the packaging guidelines which are stating | Also applications linking against libraries should as far as possible link | against shared libraries not static versions. The dynamic linking support in dietlibc exists but is very experimental so I would not use. Linking against 'glibc' is not adviced by the upstream author and has only disadvantages. Therefore, I can not link against shared libraries. 'rpmlint' is a great help but is far away from being perfect and gives lot of false positives. This one, is such a false positive and can be ignored therefore. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From enrico.scholz at informatik.tu-chemnitz.de Thu Feb 23 20:00:49 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 23 Feb 2006 21:00:49 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <20060223182942.GQ2730@free.fr> (Patrice Dumas's message of "Thu, 23 Feb 2006 19:29:42 +0100") References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <20060223182942.GQ2730@free.fr> Message-ID: <87r75thmku.fsf@kosh.bigo.ensc.de> pertusus at free.fr (Patrice Dumas) writes: >> Which security issues? Tools in 'ipvsd' are doing only some syscalls >> resp. the (perhaps) exploitable code sits in ipvsd and not in dynamical >> linkable libraries. The 'ipvsd' code itself is so small that it can be > > Why couldn't there be an issue with a bug in dietlibc that opens a > security hole in ipvsd? 'ipvsd' (resp. the shipped programs) are doing | socket() -> bind() -> listen() -> accept() -> [...] -> execve() The [...] part is the only place were an exploit can happen and there will be done: * DNS queries; this is indeed critically but it is done completely by 'ipvsd' without using an external library. So, dynamic linking would not increase security * environ-manipulation; this happens within 'ipvsd' too and sentence above applies too * lookup of the peer in a CDB database managed completely by internal code; ditto So, exploits opened by 'dietlibc' can be excluded for 'ipvsd'. >> No, the choice is between ??? (sorry, I do not have an idea which >> positive property would be brought in by 'glibc' linking) against >> efficiency and building 'ipvsvd' with the tools it was designed for. > > You cannot rule out security issues in the library easily as long as > the library is used, and ipvsd is a networking app, so security > matters. In another posting I gave a complete list of used *libc symbols. These were either simple syscall wrappers or well audited code (e.g. malloc()) so you will the same (or better) security as with glibc (which is much more complicated to audit than dietlibc). Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 482 bytes Desc: not available URL: From chitlesh at fedoraproject.org Thu Feb 23 20:29:48 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 23 Feb 2006 21:29:48 +0100 Subject: Anjuta - change of maintainer In-Reply-To: <43FDE220.5090804@smile.org.ua> References: <1140476355.2971.1.camel@T7.Linux> <1140477835.2971.5.camel@T7.Linux> <13dbfe4f0602211544g643afe6ev3dd6b3419c3e1f6c@mail.gmail.com> <1140565626.31940.14.camel@T7.Linux> <13dbfe4f0602220604l1f30f6b6w1511f42ad780fa89@mail.gmail.com> <1140622767.31392.33.camel@mrwibble.mrwobble> <20060222183059.32178be3.bugs.michael@gmx.net> <13dbfe4f0602221003l463d483fp99ed352b8f5d189d@mail.gmail.com> <20060222210435.20f0ea47.bugs.michael@gmx.net> <43FDE220.5090804@smile.org.ua> Message-ID: <13dbfe4f0602231229l12449a0axbbe7478fa0d3247b@mail.gmail.com> has there been any changes yet? I can't even see the latest anjuta and even amarok-1.4 beta -- http://clunixchit.blogspot.com From buildsys at fedoraproject.org Thu Feb 23 21:16:37 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 23 Feb 2006 16:16:37 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060223211637.72E528011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 10 Coin2-2.4.4-3.2.fc4 SIBsim4-0.10-1.fc4 charis-fonts-4.0.02-1 dap-server-3.5.3-1.fc4.1 doulos-fonts-4.0.14-1 libtorrent-0.8.5-3.fc4 perl-Config-General-2.31-1.fc4 perl-GDGraph-1.4307-1.fc4 rbldnsd-0.996-1.fc4 rdiff-backup-1.0.4-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu Feb 23 21:16:47 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 23 Feb 2006 16:16:47 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060223211647.165D28011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 8 awstats-6.5-2.fc5 libosip2-2.2.2-3.fc5 openmpi-1.0.1-1.fc5 rdiff-backup-1.0.4-1.fc5 seahorse-0.8-2.fc5 tagtool-0.12.2-3.fc5 tile-0.7.2-3.fc5 yum-utils-0.5-1 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From paul at all-the-johnsons.co.uk Thu Feb 23 21:36:05 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Thu, 23 Feb 2006 21:36:05 +0000 Subject: Anjuta - change of maintainer In-Reply-To: <13dbfe4f0602231229l12449a0axbbe7478fa0d3247b@mail.gmail.com> References: <1140476355.2971.1.camel@T7.Linux> <1140477835.2971.5.camel@T7.Linux> <13dbfe4f0602211544g643afe6ev3dd6b3419c3e1f6c@mail.gmail.com> <1140565626.31940.14.camel@T7.Linux> <13dbfe4f0602220604l1f30f6b6w1511f42ad780fa89@mail.gmail.com> <1140622767.31392.33.camel@mrwibble.mrwobble> <20060222183059.32178be3.bugs.michael@gmx.net> <13dbfe4f0602221003l463d483fp99ed352b8f5d189d@mail.gmail.com> <20060222210435.20f0ea47.bugs.michael@gmx.net> <43FDE220.5090804@smile.org.ua> <13dbfe4f0602231229l12449a0axbbe7478fa0d3247b@mail.gmail.com> Message-ID: <1140730565.20488.5.camel@T7.Linux> Hi, > has there been any changes yet? > I can't even see the latest anjuta and even amarok-1.4 beta I can't speak for amarok, but anjuta 1.2.4-3fc5.x86_64 is showing up in the rawhide update I've just started downloading. TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show From pertusus at free.fr Thu Feb 23 21:39:19 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 23 Feb 2006 22:39:19 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <87r75thmku.fsf@kosh.bigo.ensc.de> References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <20060223182942.GQ2730@free.fr> <87r75thmku.fsf@kosh.bigo.ensc.de> Message-ID: <20060223213919.GA3059@free.fr> > > So, exploits opened by 'dietlibc' can be excluded for 'ipvsd'. I am convinced by your audit of the code, I still think that there could be security issues in dietlibc linked with ipsvd (in the places you mentionned), but I personally agree that in that case the possible efficiency gains overpass the possible security issues. But I believe that your explanation was needed too convince the reviewers (I hope that you'll be successfull ;-). -- Pat From bugzilla at redhat.com Thu Feb 23 21:37:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 16:37:20 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602232137.k1NLbKnv016031@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From bugs.michael at gmx.net 2006-02-23 16:37 EST ------- * gallery2-gd must "Requires: php-gd" as else the GD module cannot be installed successfully within Gallery2 modules admin section. * "yum install gallery2" adds gallery2-gd and gallery2-tile, but: file /var/www/html/gallery2/modules is not owned by any package * Further, since "gallery2-matrix" is needed and provides gallery2-display just like gallery2-tile does, the current virtual dependency mechanism "gallery2-display" is questionable. gallery2-tile does not suffice. gallery2-matrix is not optional. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From j.w.r.degoede at hhs.nl Thu Feb 23 22:00:18 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 23 Feb 2006 23:00:18 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <87vev5hnp7.fsf@kosh.bigo.ensc.de> References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <43FDF33A.6000503@hhs.nl> <87bqwyvu5a.fsf@kosh.bigo.ensc.de> <43FDFC3E.7010002@hhs.nl> <87vev5hnp7.fsf@kosh.bigo.ensc.de> Message-ID: <43FE3072.5080402@hhs.nl> Enrico Scholz wrote: > j.w.r.degoede at hhs.nl (Hans de Goede) writes: > >>>> Why? Because static linking is BAD for lots of reasons, >>> Please tell me, why static linking is BAD in *this* case. >> I just did a quick grep for your email in owners.list and I'm amazed by >> the fact that someone who maintains as many security related packages >> as you needs to ask. > > Perhaps because I understand the reasons behind dynamic linking instead > of repeating things blindly without knowing why they are there? > > Ok, let's look at 'ipsvd'; when linking the 'tcpsvd' program dynamically > (a '--without dietlibc' rpm switch should do it), we create a binary > which imports > > > | __errno_location > | __fxstat > | __gmon_start__ > | __libc_start_main > | __xstat > | _exit > | accept > | bind > | close > | connect > | execve > | fcntl > | fork > | free > | getgrnam > | gethostname > | getpeername > | getpid > | getppid > | getpwnam > | getservbyname > | getsockname > | gettimeofday > | listen > | lseek > | malloc > | mmap > | munmap > | open > | poll > | read > | recv > | send > | setgid > | setgroups > | setsockopt > | setuid > | sigaction > | sigaddset > | sigemptyset > | sigprocmask > | sigsuspend > | socket > | time > | unlink > | unlink > | waitpid > | write > > [The static linked dietlibc version will not use more of these functions.] > > 'malloc' and 'free' are the only higher level functions, all other > functions are simple syscall wrappers and ARE implemented unexploitable > (the related code are perhaps 20 assembly lines). It is right that the > dietlibc 'malloc(3)' implementation suffered the known integer overflow > some time ago. But in the meantime, the related 162 lines of code in > dietlibc have been reviewed several times so it can be assumed as > error-free. > Thats one assumption which I would rather not make and that seems to be one of the 2 fundumantel parts of our difference of opinion. > So the when-static-library-contains-flaw-we-have-to-rebuild-everything > argument does not hold because the "when-static-library-contains-flaw" > condition can never occur in *this* case. > never say never :) > > > I admit that there are problems in dietlibc but none of them are > interesting in *this* case. > Again jumping to conclusions rather quickly, you've clearly given this many thought and done your "homework" but there just is no such thing as bug free code, thats where we disagree. > >> Even in glibc which is widely used and audited security holes turn up >> quite regular, so this will most probably happen for dietlibc atleast >> as often as for glibc. When this happens we don't want to have to track >> which packages all are staticly linked against it. With the SSL stuff >> in ipvsd chances for holes are even bigger, so I would not only like to >> argue that ipvsd should not staticly link against dietlibc, > > 1. package can not be shipped with 'matrixssl' due to licensing issues; > therefore, 'matrixssl' has nothing todo with the *current* issue. > Yes I saw that after my mail, sorry thats because the flag is called with-iossl instead of with-matrixssl. So I thought these were 2 different things. > 2. 'ipvsd' supports only static linking of 'matrixssl' > Which would be unacceptable for something as security sensitive as an ssl lib. > > >>>> many the same reasons why the packaging guidelines state that >>>> packages should not compile and (staticly) link against their own >>>> version fo system libs, >>> The "should" in the packaging guidelines was intentionally. It leaves >>> room to link statically when this is the better choice and in this case, >>> dietlibc is the better choice. >>> >> Not when this is a better choice, it doesn't say when this is a better >> choice anywhere, it says "Static libraries should only be included in >> exceptional circumstances." > > This sentence means packaging of %_libdir/*.a files but NOT linking > against static libraries. > If you want to take things literaty the dietlibc package does fall under thus rule and thus should be changed to only provide .so or removed since I see no reason for allowing an exeption for it. Don't you see that either way it is the same we don't want static libs because we don't want static linking learn to read between the lines. > >> I guess I can come up with a zillion more small programs which will be >> smaller and faster with dietlibc, thats not what this is about, the >> should is there in case its impossible to avoid this without tons of >> work. > > It really depends. It's hard to find a reason to link programs like > > | int main() { write(1, "Hello world\n", 12); } > > dynamically against glibc instead of using dietlibc. But I would not > write a bugreport only because of this inefficiency. > So you agree the gain isn't big enough to warrent doing this for other packages, then it also isn't big enough for this package. And more in general the gain of dietlibc (for soem programs) isn't big enough to warrant it an exception to the no .a files rules, so dietlibc should be changed or removed. Now if we're talking about moving the entire distro over to dietlibc, that would be interesting! But for a few packages its ridiculous. > >>>> that is exactly what you're doing now linking against an own version >>>> of system libs. >>> ??? I do not see where 'ipvsd' links against a "local copy of a >>> library that exists on the system". >>> >> Its staticly linked, this it gets its own private copy hardcoded into >> the binary. > > "local copy" in this sentence means a library which is both shipped in > the package and exists in the system already. 'matrixssl' might be an > example in this case when it would exist in FE already. > See above, the intention of this rule is imho clear and it extends to what you're doing. > >>>> is the exception that confirms the rule. Also notice: >>>> "Static libraries should only be included in exceptional circumstances." >>> 'ipvsd' does not provide static libraries. >> Nor should it use them, > > That is not stated there and was never an intention of this paragraph > which covers packages shipping libraries only. 'ipvsd' is not such a > package. > Dietlibc is, so remove/fix that please. > >>> when there are ways to make things work better, these ways should be >>> gone. Again: linking against 'dietlibc' has only advantages for >>> 'ipvsd'. >> When the tradeof is a small gain in speed and footprint versus >> maintainability and security then the disadvantages of your choice >> outway the advantages. > > I do not see how this is related to *this* case and do not know what you > mean with "maintainablility". The "security" argument was disproved > above. > maintainability means that if we allow this and a few other packages will get linked against dietlibc too and a bug in dietlibc is found then all those packages will need a rebuild, since some maintainers are not all that responsive to bugreports, this will be a pain, who is going to coordinate this and make sure all affected packages get rebuild. This is exactly why we don't want static libs and if we don't have them we can't use them because we don;t want static linking either (it _really_ is the same) > >> So saying that there are only advantages is false as there are clear >> disadvantages. > > Please tell me the disadvantages in *this* case. > See above. > >> But this entire discussion is mood anyways. We have clear guidelines and >> you are in clear (and unnescesarry) violation of the guidelines. > > Where does 'ipvsd' violate the guidelines? > See above, and dietlibc clear violates them too. Regards, Hans From j.w.r.degoede at hhs.nl Thu Feb 23 22:01:44 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 23 Feb 2006 23:01:44 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <20060223213919.GA3059@free.fr> References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <20060223182942.GQ2730@free.fr> <87r75thmku.fsf@kosh.bigo.ensc.de> <20060223213919.GA3059@free.fr> Message-ID: <43FE30C8.1070200@hhs.nl> Patrice Dumas wrote: >> So, exploits opened by 'dietlibc' can be excluded for 'ipvsd'. > > I am convinced by your audit of the code, I still think that there could > be security issues in dietlibc linked with ipsvd (in the places you > mentionned), but I personally agree that in that case the possible > efficiency gains overpass the possible security issues. But I believe > that your explanation was needed too convince the reviewers (I hope that > you'll be successfull ;-). > I for one am still far from convinced what exactly are those effiecency gains, numbers please. We've seen the data on the symbol list now lets see the data on the efficiency gain. Regards, Hans From wart at kobold.org Thu Feb 23 22:01:20 2006 From: wart at kobold.org (Michael Thomas) Date: Thu, 23 Feb 2006 14:01:20 -0800 Subject: [Fwd: Build Error (Job 5181): tong-1_0-6_fc5 on fedora-development-extras] In-Reply-To: <43FE100D.80204@kobold.org> References: <43FE06FE.2000509@kobold.org> <1140721534.10877.0.camel@dhcp83-74.boston.redhat.com> <43FE100D.80204@kobold.org> Message-ID: <43FE30B0.9080800@kobold.org> Michael Thomas wrote: > Dan Williams wrote: > >>On Thu, 2006-02-23 at 11:03 -0800, Michael Thomas wrote: >> >> >>>Who is the build system administrator that I need to contact about this >>>build failure? The package built fine, and according to the logs, files >>>were created. But the build system still claimed that it couldn't >>>download the result files. >> >> >>SSL + timeouts, likely. I've requeued the job, and have increased the # >>of download attempts for individual files from 5 to 10 one the server. > > > It happened again: > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=5181 > http://buildsys.fedoraproject.org/logs/fedora-development-extras/5181-tong-1.0-6.fc5/ I requeued the job after a short while, and this time it succeeded. Issue closed. --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From bugs.michael at gmx.net Thu Feb 23 22:31:18 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 23 Feb 2006 23:31:18 +0100 Subject: Anjuta - change of maintainer In-Reply-To: <43FDE220.5090804@smile.org.ua> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602201500w25dcc9dcp3ba8f1db893e7f7a@mail.gmail.com> <1140476701.2971.3.camel@T7.Linux> <13dbfe4f0602201520v21ee0d3br46b04df50eea092b@mail.gmail.com> <1140477835.2971.5.camel@T7.Linux> <13dbfe4f0602211544g643afe6ev3dd6b3419c3e1f6c@mail.gmail.com> <1140565626.31940.14.camel@T7.Linux> <13dbfe4f0602220604l1f30f6b6w1511f42ad780fa89@mail.gmail.com> <1140622767.31392.33.camel@mrwibble.mrwobble> <20060222183059.32178be3.bugs.michael@gmx.net> <13dbfe4f0602221003l463d483fp99ed352b8f5d189d@mail.gmail.com> <20060222210435.20f0ea47.bugs.michael@gmx.net> <43FDE220.5090804@smile.org.ua> Message-ID: <20060223233118.422ac37c.bugs.michael@gmx.net> On Thu, 23 Feb 2006 18:26:08 +0200, Andy Shevchenko wrote: > Michael Schwendt ?????: > > A packaging bug. > > One time FreshRPMS people check and drop Epoch to zero in all shipped files. > I think it's like copper. One side is a manual update, another side is a > more convenient behaviour (may be). No. This is not an option. Removing explicit "Epoch: 0" is different from removing an Epoch higher than zero. The former only breaks "rpm -F", the latter would break "everything". ;) Btw, explicit "Epoch: 0" has been removed from Fedora Extras long ago by the same person, who maintains freshrpms.net. From paul at all-the-johnsons.co.uk Thu Feb 23 22:49:25 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 23 Feb 2006 22:49:25 +0000 Subject: More on anjuta2 Message-ID: <1140734965.20488.17.camel@T7.Linux> Hi, So far, anjuta-2 relies on 4 external packages (graphviz, autogen, gnome-build and gdl [renamed to anjuta-gdl for now]). autogen relies on libopts. That's 4 new additional packages for one new package. It seems quite a lot for another IDE. I'm happy to carry on building though... TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From bugzilla at redhat.com Thu Feb 23 22:49:57 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 17:49:57 -0500 Subject: [Bug 182678] New: Review Request: libopts Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182678 Summary: Review Request: libopts Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: paul at all-the-johnsons.co.uk QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.smmp.salford.ac.uk/packages/libopts.spec SRPM Name or Url: http://www.smmp.salford.ac.uk/packages/libopts-27.1-1.src.rpm Description: libopts is part of the autogen project builder required as part of anjuta 2 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From chitlesh at fedoraproject.org Thu Feb 23 23:47:50 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Fri, 24 Feb 2006 00:47:50 +0100 Subject: More on anjuta2 In-Reply-To: <1140734965.20488.17.camel@T7.Linux> References: <1140734965.20488.17.camel@T7.Linux> Message-ID: <13dbfe4f0602231547rebd4e5fsed5e72c97536ba47@mail.gmail.com> On 2/23/06, Paul wrote: > Hi, > > So far, anjuta-2 relies on 4 external packages (graphviz, autogen, > gnome-build and gdl [renamed to anjuta-gdl for now]). > > autogen relies on libopts. > > That's 4 new additional packages for one new package. It seems quite a > lot for another IDE. > > I'm happy to carry on building though... > > TTFN > > Paul good on ya mate :) -- http://clunixchit.blogspot.com From paul at all-the-johnsons.co.uk Thu Feb 23 23:49:22 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 23 Feb 2006 23:49:22 +0000 Subject: Rebuilding during make install process Message-ID: <1140738562.20488.22.camel@T7.Linux> Hi, Part of the autogen make install has the following in it and I'm wondering how to do what it's doing within the make install part /bin/sh ../libtool --mode=install /usr/bin/install -c 'libguileopts.la' '/usr/lib64/libguileopts.la' (cd /home/paul/rpmbuild/BUILD/autogen-5.8.3/autoopts; /bin/sh ../libtool --tag=CC --mode=relink gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o libguileopts.la -rpath /usr/lib64 -version-info 0:1:0 libguileopts_la-guileopt.lo libopts.la -lm -ldl ) gcc -shared .libs/libguileopts_la-guileopt.o -Wl,--rpath -Wl,/usr/lib64 -L/usr/lib64 -lopts -lm -ldl -m64 -mtune=generic -Wl,-soname -Wl,libguileopts.so.0 -o .libs/libguileopts.so.0.0.1 /usr/bin/install -c .libs/libguileopts.so.0.0.1T /usr/lib64/libguileopts.so.0.0.1 It's basically relinking libguile for it's own purposes. TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From paul at all-the-johnsons.co.uk Thu Feb 23 23:50:12 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Thu, 23 Feb 2006 23:50:12 +0000 Subject: More on anjuta2 In-Reply-To: <13dbfe4f0602231547rebd4e5fsed5e72c97536ba47@mail.gmail.com> References: <1140734965.20488.17.camel@T7.Linux> <13dbfe4f0602231547rebd4e5fsed5e72c97536ba47@mail.gmail.com> Message-ID: <1140738612.20488.24.camel@T7.Linux> Hi, > > autogen relies on libopts. > good on ya mate :) autogen is evil. autogen is evil. autogen is evil. TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show From bugzilla at redhat.com Thu Feb 23 23:49:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 18:49:28 -0500 Subject: [Bug 180743] Review Request: pdsh In-Reply-To: Message-ID: <200602232349.k1NNnSOP016306@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: pdsh https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180743 ------- Additional Comments From woodard at redhat.com 2006-02-23 18:49 EST ------- OK fixed a bunch more things. Now all packages not just the src.rpm have almost all their warnings resolved: $ sudo rm -f /usr/src/redhat/RPMS/i386/pdsh-*;sudo cp /tmp/pdsh.spec .;sudo rpmbuild -ba pdsh.spec; rpmlint /usr/src/redhat/RPMS/i386/pdsh-* | grep -v invalid-vendor | grep -v invalid-distribution | grep -v no-packager-tag| grep -v invalid-buildhost | grep -v no-signature W: pdsh-debuginfo non-standard-group Development/Debug W: pdsh-rcmd-rsh no-documentation W: pdsh-rcmd-ssh no-documentation The debuginfo package warning I think will be resolved by building in a different environment. rcmd-rsh and rcmp-ssh in fact do not have any documentation associated with them. Fixing that warning is an exercise for upstream. http://osdn.dl.sourceforge.net/sourceforge/pdsh/pdsh-2.8.1-4.src.rpm http://osdn.dl.sourceforge.net/sourceforge/pdsh/pdsh.spec -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Thu Feb 23 23:57:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 18:57:15 -0500 Subject: [Bug 175495] Review Request: cgi-util: A C library for creating CGI programs In-Reply-To: Message-ID: <200602232357.k1NNvFch017619@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cgi-util: A C library for creating CGI programs https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175495 ------- Additional Comments From redhat at flyn.org 2006-02-23 18:57 EST ------- The following removes the use of -Werror from Makefile.in: Spec Name or Url: http://flyn.org/SRPMS/cgi-util.spec SRPM Name or Url: http://flyn.org/SRPMS/cgi-util-2.2.1-5.src.rpm Description: A C library for creating Common Gateway Interface ("CGI") programs -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From pertusus at free.fr Fri Feb 24 00:36:09 2006 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 24 Feb 2006 01:36:09 +0100 Subject: Rebuilding during make install process In-Reply-To: <1140738562.20488.22.camel@T7.Linux> References: <1140738562.20488.22.camel@T7.Linux> Message-ID: <20060224003609.GG3059@free.fr> > It's basically relinking libguile for it's own purposes. My understanding is that the linking done during lake is against libraries within the package. So libguileopts is linked against a local libopts. It allows, for example to run tests. Therefore, while installing, libtool relinks the libguileopts library against the installed libopts. -- Pat From paul at all-the-johnsons.co.uk Fri Feb 24 00:58:38 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Fri, 24 Feb 2006 00:58:38 +0000 Subject: Rebuilding during make install process In-Reply-To: <20060224003609.GG3059@free.fr> References: <1140738562.20488.22.camel@T7.Linux> <20060224003609.GG3059@free.fr> Message-ID: <1140742718.20488.28.camel@T7.Linux> Hi, > > It's basically relinking libguile for it's own purposes. > > My understanding is that the linking done during lake is against libraries > within the package. So libguileopts is linked against a local libopts. > It allows, for example to run tests. Therefore, while installing, libtool > relinks the libguileopts library against the installed libopts. I should be able to just omit it then :-) TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show From bugzilla at redhat.com Fri Feb 24 03:30:00 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 23 Feb 2006 22:30:00 -0500 Subject: [Bug 180430] Review Request: Tong - a game of skill In-Reply-To: Message-ID: <200602240330.k1O3U0i7023724@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Tong - a game of skill https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180430 wart at kobold.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From wart at kobold.org 2006-02-23 22:29 EST ------- Imported and built. Thanks! -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rc040203 at freenet.de Fri Feb 24 04:24:33 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 24 Feb 2006 05:24:33 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <87r75thmku.fsf@kosh.bigo.ensc.de> References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <20060223182942.GQ2730@free.fr> <87r75thmku.fsf@kosh.bigo.ensc.de> Message-ID: <1140755074.14289.270.camel@mccallum.corsepiu.local> On Thu, 2006-02-23 at 21:00 +0100, Enrico Scholz wrote: > pertusus at free.fr (Patrice Dumas) writes: > > >> No, the choice is between ??? (sorry, I do not have an idea which > >> positive property would be brought in by 'glibc' linking) against > >> efficiency and building 'ipvsvd' with the tools it was designed for. > > > > You cannot rule out security issues in the library easily as long as > > the library is used, and ipvsd is a networking app, so security > > matters. > > In another posting I gave a complete list of used *libc symbols. These > were either simple syscall wrappers or well audited code (e.g. malloc()) > so you will the same (or better) security as with glibc Which is part of the OS and is being used and monitored by the whole linux community. So, if ipvsd should suffer from problems it will be much more but ipvsd package to be in trouble. > (which is much > more complicated to audit than dietlibc). ... which adds additional code to monitor. IMO, dietlibc should be banned from Fedora. Its only purpose is to circumvent the OS's libc for highly questionable reasons. As a compromise, I could be persuaded to agree to dynamical linkage against dietlibc, but statical linkage against dietlibc is non-acceptable to me. Ralf From bugzilla at redhat.com Fri Feb 24 06:25:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 01:25:09 -0500 Subject: [Bug 181801] Review Request: zeroinstall-injector In-Reply-To: Message-ID: <200602240625.k1O6P9OL030981@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: zeroinstall-injector https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181801 ------- Additional Comments From michel.salim at gmail.com 2006-02-24 01:25 EST ------- Most Python packages actually BuildRequire on python, not python-devel : the setup.py file is included with the source tarball, and it imports distutils.core which is part of python, not python-devel. Haven't used spectool --gf before, that's handy. OK, first option it is, we need a BuildRequire on gnupg, but no BuildReq on python-devel. Will upload a new package tomorrow (actually, later today) after some testing. Thanks for all your help, - Michel -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From ville.skytta at iki.fi Fri Feb 24 07:00:03 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 24 Feb 2006 09:00:03 +0200 Subject: More on anjuta2 In-Reply-To: <1140734965.20488.17.camel@T7.Linux> References: <1140734965.20488.17.camel@T7.Linux> Message-ID: <1140764403.13705.5.camel@bobcat.mine.nu> On Thu, 2006-02-23 at 22:49 +0000, Paul wrote: > So far, anjuta-2 relies on 4 external packages (graphviz, autogen, > gnome-build and gdl [renamed to anjuta-gdl for now]). > > autogen relies on libopts. > > That's 4 new additional packages for one new package. graphviz has been in Extras for a long time. From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 24 07:17:19 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 24 Feb 2006 08:17:19 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <43FE3072.5080402@hhs.nl> (Hans de Goede's message of "Thu, 23 Feb 2006 23:00:18 +0100") References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <43FDF33A.6000503@hhs.nl> <87bqwyvu5a.fsf@kosh.bigo.ensc.de> <43FDFC3E.7010002@hhs.nl> <87vev5hnp7.fsf@kosh.bigo.ensc.de> <43FE3072.5080402@hhs.nl> Message-ID: <877j7l1b0g.fsf@kosh.bigo.ensc.de> j.w.r.degoede at hhs.nl (Hans de Goede) writes: >> 'malloc' and 'free' are the only higher level functions, all other >> functions are simple syscall wrappers and ARE implemented unexploitable >> (the related code are perhaps 20 assembly lines). It is right that the >> dietlibc 'malloc(3)' implementation suffered the known integer overflow >> some time ago. But in the meantime, the related 162 lines of code in >> dietlibc have been reviewed several times so it can be assumed as >> error-free. >> > > Thats one assumption which I would rather not make Please, look at the code before doing such unreasoned statements. The malloc() code is | static void* REGPARM(1) __small_malloc(size_t _size) { | __alloc_t *ptr; | size_t size=_size; | size_t idx; | | idx=get_index(size); | ptr=__small_mem[idx]; | | if (ptr==0) { /* no free blocks ? */ | register int i,nr; | ptr=do_mmap(MEM_BLOCK_SIZE); | if (ptr==MAP_FAILED) return MAP_FAILED; | | __small_mem[idx]=ptr; | | nr=__SMALL_NR(size)-1; | for (i=0;inext=(((void*)ptr)+size); | ptr=ptr->next; | } | ptr->next=0; | | ptr=__small_mem[idx]; | } | | /* get a free block */ | __small_mem[idx]=ptr->next; | ptr->next=0; | | return ptr; | } | | static void* _alloc_libc_malloc(size_t size) { | __alloc_t* ptr; | size_t need; | #ifdef WANT_MALLOC_ZERO | if (!size) return BLOCK_RET(zeromem); | #else | if (!size) goto err_out; | #endif | size+=sizeof(__alloc_t); | if (sizesize=need; | return BLOCK_RET(ptr); | err_out: | (*__errno_location())=ENOMEM; | return 0; | } | | static void REGPARM(2) __small_free(void*_ptr,size_t _size) { | __alloc_t* ptr=BLOCK_START(_ptr); | size_t size=_size; | size_t idx=get_index(size); | | memset(ptr,0,size); /* allways zero out small mem */ | | ptr->next=__small_mem[idx]; | __small_mem[idx]=ptr; | } | | static void _alloc_libc_free(void *ptr) { | register size_t size; | if (ptr) { | size=((__alloc_t*)BLOCK_START(ptr))->size; | if (size) { | if (size<=__MAX_SMALL_SIZE) | __small_free(ptr,size); | else | munmap(BLOCK_START(ptr),size); | } | } | } It is definitively not exploitable. >> So the when-static-library-contains-flaw-we-have-to-rebuild-everything >> argument does not hold because the "when-static-library-contains-flaw" >> condition can never occur in *this* case. > > never say never :) Correctness of a program can be proved mathematically. So I can say that exploits in ipsvd are NEVER caused by dietlibc. >> I admit that there are problems in dietlibc but none of them are >> interesting in *this* case. > > Again jumping to conclusions rather quickly, you've clearly given this > many thought and done your "homework" but there just is no such thing > as bug free code, thats where we disagree. bug-free code exists. The malloc() implementation and the named syscall wrappers in dietlibc are examples. >>>>> many the same reasons why the packaging guidelines state that >>>>> packages should not compile and (staticly) link against their own >>>>> version fo system libs, >>>> The "should" in the packaging guidelines was intentionally. It leaves >>>> room to link statically when this is the better choice and in this case, >>>> dietlibc is the better choice. >>>> >>> Not when this is a better choice, it doesn't say when this is a better >>> choice anywhere, it says "Static libraries should only be included in >>> exceptional circumstances." >> This sentence means packaging of %_libdir/*.a files but NOT linking >> against static libraries. >> > > If you want to take things literaty the dietlibc package does fall > under thus rule I do not see where. dietlibc makes sense with static libraries only. The dynamic linking support is experimental and does not exist for all platforms. So, there exist "exceptional circumstances" and there is still the "should" which allows the packager to do the best thing (and static dietlibc libraries are the best thing). > and thus should be changed to only provide .so or removed since I see > no reason for allowing an exeption for it. Don't you see that either > way it is the same we don't want static libs because we don't want > static linking learn to read between the lines. These static-linking rules were not written to ban static libraries completely but to avoid things like the static-zlib desaster. Therefore, it is a "should" but not "must" rule. >>> I guess I can come up with a zillion more small programs which will >>> be smaller and faster with dietlibc, thats not what this is about, >>> the should is there in case its impossible to avoid this without >>> tons of work. >> It really depends. It's hard to find a reason to link programs like >> | int main() { write(1, "Hello world\n", 12); } >> dynamically against glibc instead of using dietlibc. But I would not >> write a bugreport only because of this inefficiency. > > So you agree the gain isn't big enough No, Fedora Extras rules do neither forbid nor encourage usage of dietlibc so it is finally the decision of the packager to do the best thing. When he does not want to add dietlibc deps to his package, I have to accept it. Arguing with effiency would result into endless discussions without a result as this thread is showing. > to warrent doing this for other packages, then it also isn't big > enough for this package. And more in general the gain of dietlibc > (for soem programs) isn't big enough to warrant it an exception to > the no .a files rules, so dietlibc should be changed or removed. Now > if we're talking about moving the entire distro over to dietlibc, > that would be interesting! I never wanted to move the entire distro to dietlibc, only few programs benefit from this library. It is obviously that complex libraries whose bugfreeness can not be proven mathematically should be linked dynamically. > But for a few packages its ridiculous. I prefer to chose things in case-per-case decision instead of making generalisations which hold for most but not all packages. "Static linking is insecure" is such a generalisation which does not apply to the 'ipsvd' case. >>>>> that is exactly what you're doing now linking against an own >>>>> version of system libs. >>>> ??? I do not see where 'ipvsd' links against a "local copy of a >>>> library that exists on the system". > ... > See above, the intention of this rule is imho clear and it extends to > what you're doing. This rule means only that packages should not use local copies of libraries (e.g. 'zlib', 'db4') but use the existing ones from the system. There are no deaper intentions or extends of this rule. >>>>> is the exception that confirms the rule. Also notice: "Static >>>>> libraries should only be included in exceptional circumstances." >>>> 'ipvsd' does not provide static libraries. >>> Nor should it use them, >> That is not stated there and was never an intention of this paragraph >> which covers packages shipping libraries only. 'ipvsd' is not such a >> package. > > Dietlibc is, so remove/fix that please. NOTABUG. This rule is a "should" only and there exist "exceptional circumstances". >>>> when there are ways to make things work better, these ways should >>>> be gone. Again: linking against 'dietlibc' has only advantages for >>>> 'ipvsd'. >>> When the tradeof is a small gain in speed and footprint versus >>> maintainability and security then the disadvantages of your choice >>> outway the advantages. >> I do not see how this is related to *this* case and do not know >> what you mean with "maintainablility". The "security" argument was >> disproved above. > > maintainability means that if we allow this and a few other packages > will get linked against dietlibc too and a bug in dietlibc is found > then all those packages will need a rebuild, You mean that you want to add a rule to the guidelines like | A package MUST NOT be usable as an example for other unrelated packages | which might do bad things -1 from me... I speak only about 'ipvsd' currently but not about potential other packages maintained by other people. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 482 bytes Desc: not available URL: From paul at city-fan.org Fri Feb 24 07:52:11 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 24 Feb 2006 07:52:11 +0000 Subject: More on anjuta2 In-Reply-To: <1140734965.20488.17.camel@T7.Linux> References: <1140734965.20488.17.camel@T7.Linux> Message-ID: <1140767531.23360.4.camel@laurel.intra.city-fan.org> On Thu, 2006-02-23 at 22:49 +0000, Paul wrote: > Hi, > > So far, anjuta-2 relies on 4 external packages (graphviz, autogen, > gnome-build and gdl [renamed to anjuta-gdl for now]). > > autogen relies on libopts. > > That's 4 new additional packages for one new package. It seems quite a > lot for another IDE. > > I'm happy to carry on building though... If you think that's a lot of packages, try installing perl-Maypole or rt3 and see how many dependencies they pull in from Extras... Paul. From paul at city-fan.org Fri Feb 24 07:55:10 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 24 Feb 2006 07:55:10 +0000 Subject: Rebuilding during make install process In-Reply-To: <1140738562.20488.22.camel@T7.Linux> References: <1140738562.20488.22.camel@T7.Linux> Message-ID: <1140767710.23360.6.camel@laurel.intra.city-fan.org> On Thu, 2006-02-23 at 23:49 +0000, Paul wrote: > Hi, > > Part of the autogen make install has the following in it and I'm > wondering how to do what it's doing within the make install part > > /bin/sh ../libtool --mode=install /usr/bin/install -c > 'libguileopts.la' '/usr/lib64/libguileopts.la' > (cd /home/paul/rpmbuild/BUILD/autogen-5.8.3/autoopts; /bin/sh ../libtool > --tag=CC --mode=relink gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 > -mtune=generic -o libguileopts.la -rpath /usr/lib64 -version-info 0:1:0 > libguileopts_la-guileopt.lo libopts.la -lm -ldl ) > gcc -shared .libs/libguileopts_la-guileopt.o -Wl,--rpath > -Wl,/usr/lib64 -L/usr/lib64 -lopts -lm -ldl -m64 -mtune=generic > -Wl,-soname -Wl,libguileopts.so.0 -o .libs/libguileopts.so.0.0.1 > /usr/bin/install > -c .libs/libguileopts.so.0.0.1T /usr/lib64/libguileopts.so.0.0.1 I think that -rpath /usr/lib64 may result in a blocker at review time... Paul. From bugzilla at redhat.com Fri Feb 24 08:01:43 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 03:01:43 -0500 Subject: [Bug 180743] Review Request: pdsh In-Reply-To: Message-ID: <200602240801.k1O81hYj014099@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: pdsh https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180743 ------- Additional Comments From paul at city-fan.org 2006-02-24 03:01 EST ------- (In reply to comment #7) > OK fixed a bunch more things. Now all packages not just the src.rpm have almost > all their warnings resolved: > > $ sudo rm -f /usr/src/redhat/RPMS/i386/pdsh-*;sudo cp /tmp/pdsh.spec .;sudo > rpmbuild -ba pdsh.spec Why are you building packages as root? This is potentially a security issue and it can also hide some issues that may crop up when the package is rebuilt as a regular user (some upstream packages have $(DESTDIR) missing in some Makefile entries for instance). ; rpmlint /usr/src/redhat/RPMS/i386/pdsh-* | grep -v > invalid-vendor | grep -v invalid-distribution | grep -v no-packager-tag| grep -v > invalid-buildhost | grep -v no-signature > > W: pdsh-debuginfo non-standard-group Development/Debug > W: pdsh-rcmd-rsh no-documentation > W: pdsh-rcmd-ssh no-documentation > > The debuginfo package warning I think will be resolved by building in a > different environment. Which rpmlint are you using? I've never seen the Extras version complain about the group used in automatically-generated debuginfo packages, nor about missing packager tags. I'd change the Source0 URL to: http://dl.sourceforge.net/sourceforge/pdsh/pdsh-%{version}-1.tar.gz so as not to use a specific mirror and to use the %{version} macro to save you having to change it when upstream releases a new version. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From dan at danny.cz Fri Feb 24 08:50:42 2006 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Fri, 24 Feb 2006 09:50:42 +0100 Subject: requires for lcov Message-ID: <1140771042.3400.8.camel@eagle.danny.cz> Hello, I am doing a review for lcov, which is an extension of gcov (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181444). In the spec file there is "Requires: /usr/bin/gcov", gcov is a part of gcc package. I would like to know whether is this correct or there should be a dependency on the whole gcc package. I do not see any relevant information in the Packaging Guidelines. Thank you Dan From paul at city-fan.org Fri Feb 24 09:04:41 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 24 Feb 2006 09:04:41 +0000 Subject: requires for lcov In-Reply-To: <1140771042.3400.8.camel@eagle.danny.cz> References: <1140771042.3400.8.camel@eagle.danny.cz> Message-ID: <1140771881.23360.15.camel@laurel.intra.city-fan.org> On Fri, 2006-02-24 at 09:50 +0100, Dan Hor?k wrote: > Hello, > > I am doing a review for lcov, which is an extension of gcov > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181444). In the > spec file there is "Requires: /usr/bin/gcov", gcov is a part of gcc > package. I would like to know whether is this correct or there should be > a dependency on the whole gcc package. I do not see any relevant > information in the Packaging Guidelines. Looks fine to me. A file-based dependency like this will continue to work even if gcov was split off into a separate package like gcc-gcov or just plain gcov at some point in the future. Paul. From rc040203 at freenet.de Fri Feb 24 09:05:25 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 24 Feb 2006 10:05:25 +0100 Subject: requires for lcov In-Reply-To: <1140771042.3400.8.camel@eagle.danny.cz> References: <1140771042.3400.8.camel@eagle.danny.cz> Message-ID: <1140771926.14289.277.camel@mccallum.corsepiu.local> On Fri, 2006-02-24 at 09:50 +0100, Dan Hor?k wrote: > Hello, > > I am doing a review for lcov, which is an extension of gcov > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181444). In the > spec file there is "Requires: /usr/bin/gcov", gcov is a part of gcc > package. I would like to know whether is this correct If lcov calls /usr/bin/gcov, esp. if it contains a hard-coded reference to this file, is absolutely perfect. If lconv calls "gcov" on $PATH, then there'd be some room for argumentation. > or there should be > a dependency on the whole gcc package. "R: gcc" would break if gcov once should be moved out of the gcc package. A "R: /usr/bin/gcov" would remain valid. > I do not see any relevant > information in the Packaging Guidelines. As usual in such cases, there is no "black or white". It depends on a package's details. Ralf From bugzilla at redhat.com Fri Feb 24 09:01:25 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 04:01:25 -0500 Subject: [Bug 182678] Review Request: libopts In-Reply-To: Message-ID: <200602240901.k1O91PaR029433@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libopts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182678 rc040203 at freenet.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bugzilla-sink at leemhuis.info |rc040203 at freenet.de OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From rc040203 at freenet.de 2006-02-24 04:01 EST ------- NEEDSWORK: This spec is rather immature and needs quite some work - For the moment, I presume you are new to rpm packaging ;) For the moment, let me only mention a few major issues: 1. Replace the mkdir/install stuff with make DESTDIR=${RPM_BUILD_ROOT} install 2. Use %{_infodir} instead of %{_datadir}/info in %files 3. Missing %{_includedir}/autoopts in %files 4. Split the package into *-devel and nondevel. 5. Package ships infos but no calls to install-info 6. Wrong license ... [libopts is LGPL or BSD cf. http://autogen.sourceforge.net/doc/autogen_185.html#SEC185 ... and many further details ... I'll try to provide a patch addressing the most severe issues ... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 24 08:56:06 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 24 Feb 2006 09:56:06 +0100 Subject: rpms/scorched3d/FC-4 scorched3d-apoc-3.1-bins.tgz, NONE, 1.1 scorched3d-apoc-3.1.patch, NONE, 1.1 scorched3d.spec, 1.6, 1.7 In-Reply-To: <200602240000.k1O00DCN012182@cvs-int.fedora.redhat.com> (Hans de Goede's message of "Thu, 23 Feb 2006 18:59:40 -0500") References: <200602240000.k1O00DCN012182@cvs-int.fedora.redhat.com> Message-ID: <87slq9i195.fsf@kosh.bigo.ensc.de> fedora-extras-commits at redhat.com ("Hans de Goede" (jwrdegoede)) writes: > Author: jwrdegoede > > --- NEW FILE scorched3d-apoc-3.1-bins.tgz --- Wouldn't it be a better idea to upload the binary files instead of submitting them into CVS? [The CVS sync mailer should not send binary diffs overall; especially not with 'charset=utf-8'] Enrico From roland at redhat.com Fri Feb 24 09:28:45 2006 From: roland at redhat.com (Roland McGrath) Date: Fri, 24 Feb 2006 01:28:45 -0800 (PST) Subject: requires for lcov In-Reply-To: Ralf Corsepius's message of Friday, 24 February 2006 10:05:25 +0100 <1140771926.14289.277.camel@mccallum.corsepiu.local> Message-ID: <20060224092845.27205180A66@magilla.sf.frob.com> > If lcov calls /usr/bin/gcov, esp. if it contains a hard-coded reference > to this file, is absolutely perfect. > > If lconv calls "gcov" on $PATH, then there'd be some room for > argumentation. In fact it runs "gcov" using the path. What to run can be set in a configuration file. Should I make the default /usr/bin/gcov instead? That would annoy someone who installed their own gcc build, but they could edit the config file. I'm inclined to leave it as it is, and wish for an rpm pseudo-dependency meaning "there is a foobar command in the local standard path for users". My thinking in using the file dependency was as mentioned, that gcov might conceivably move to a different package in the future. (There is no special reason to expect that to happen.) Thanks, Roland From j.w.r.degoede at hhs.nl Fri Feb 24 09:46:37 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 24 Feb 2006 10:46:37 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <877j7l1b0g.fsf@kosh.bigo.ensc.de> References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <43FDF33A.6000503@hhs.nl> <87bqwyvu5a.fsf@kosh.bigo.ensc.de> <43FDFC3E.7010002@hhs.nl> <87vev5hnp7.fsf@kosh.bigo.ensc.de> <43FE3072.5080402@hhs.nl> <877j7l1b0g.fsf@kosh.bigo.ensc.de> Message-ID: <43FED5FD.6010003@hhs.nl> It seems we can't get to an agreement, also see Ralf Corsepius reaction, which I support. An alternative c-lib implementation does not belong in extras. I suggest we ask FESco to take a decision on this. Regards, Hans From bugzilla at redhat.com Fri Feb 24 10:02:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 05:02:50 -0500 Subject: [Bug 182678] Review Request: libopts In-Reply-To: Message-ID: <200602241002.k1OA2oSN012025@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libopts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182678 ------- Additional Comments From paul at all-the-johnsons.co.uk 2006-02-24 05:02 EST ------- Not that new to packaging - just somewhat tired when I did the spec file! I originally had the make DESTDIR=${RPM_BUILD_ROOT} install in the spec file, but the compilation continually failed. I swapped it over and all was well. This could be down to my buildsys at home (x86_64 box). Does %{_infodir} automagically point to /usr/share/info? I've not come across that one and it will affect the autogen package which should be ready tonight (it also has the same make DESTDIR problem as libopts :-( ) Thanks for the patch - I'll review and apply it tonight. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 24 10:17:38 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 24 Feb 2006 11:17:38 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <1140755074.14289.270.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Fri, 24 Feb 2006 05:24:33 +0100") References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <20060223182942.GQ2730@free.fr> <87r75thmku.fsf@kosh.bigo.ensc.de> <1140755074.14289.270.camel@mccallum.corsepiu.local> Message-ID: <87d5hdf4cd.fsf@kosh.bigo.ensc.de> rc040203 at freenet.de (Ralf Corsepius) writes: >> In another posting I gave a complete list of used *libc symbols. These >> were either simple syscall wrappers or well audited code (e.g. malloc()) >> so you will the same (or better) security as with glibc > Which is part of the OS and is being used and monitored by the whole > linux community. Do you have numbers, how many people read (and understood) the glibc and the dietlibc code? Speaking about a "whole linux community" does not tell something. > So, if ipvsd should suffer from problems it will be much more but > ipvsd package to be in trouble. ??? Why should 'ipvsd' affect other packages? > IMO, dietlibc should be banned from Fedora. Its only purpose is to > circumvent the OS's libc for highly questionable reasons. Efficiency is a "highy questionable reason"? > As a compromise, I could be persuaded to agree to dynamical linkage against > dietlibc, but statical linkage against dietlibc is non-acceptable to me. Dynamical linkage in dietlibc is highly experimental, is not supported on all archs and you gain absolutely nothing in the current 'ipsvd' case. Enrico From bugzilla at redhat.com Fri Feb 24 10:38:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 05:38:47 -0500 Subject: [Bug 182463] Review Request: cairomm (C++ bindings for cairo) In-Reply-To: Message-ID: <200602241038.k1OAclLo019795@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cairomm (C++ bindings for cairo) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182463 ------- Additional Comments From murrayc at murrayc.com 2006-02-24 05:38 EST ------- I dont' understand. There are definitely cairomm tarball releases. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 24 11:03:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 06:03:21 -0500 Subject: [Bug 182678] Review Request: libopts In-Reply-To: Message-ID: <200602241103.k1OB3LZS024568@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libopts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182678 ------- Additional Comments From rc040203 at freenet.de 2006-02-24 06:03 EST ------- (In reply to comment #3) > Not that new to packaging - just somewhat tired when I did the spec file! :) > I originally had the make DESTDIR=${RPM_BUILD_ROOT} install in the spec file, > but the compilation continually failed. I swapped it over and all was well. This > could be down to my buildsys at home (x86_64 box). Pretty unlikely. This package is automake based and applies a pretty clean and modern build infrastructure. > Does %{_infodir} automagically point to /usr/share/info? Yes. It's analogous to %{_mandir} and implicitly being used inside of %configure. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 24 12:19:32 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 07:19:32 -0500 Subject: [Bug 179707] Review Request: dap-server - Basic request handling for DAP servers In-Reply-To: Message-ID: <200602241219.k1OCJWdX006547@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: dap-server - Basic request handling for DAP servers https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179707 Bug 179707 depends on bug 179708, which changed state. Bug 179708 Summary: Review Request: freeform_handler - FreeForm data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179708 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NEXTRELEASE Status|ASSIGNED |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 24 12:21:12 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 07:21:12 -0500 Subject: [Bug 175433] Review Request: tor - Anonymizing overlay network for TCP (The onion router) In-Reply-To: Message-ID: <200602241221.k1OCLCTW006989@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: tor - Anonymizing overlay network for TCP (The onion router) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175433 ------- Additional Comments From gnomeuser at gmail.com 2006-02-24 07:21 EST ------- I'll agree with #23, untill we actually support multiple init systems there's no special reason to branch it out in seperate packages. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 24 13:07:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 08:07:47 -0500 Subject: [Bug 182737] New: Review Request: kdetoys Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182737 Summary: Review Request: kdetoys Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: rdieter at math.unl.edu QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://apt.kde-redhat.org/apt/kde-redhat/SPECS/kdetoys-3.5.1-2.spec SRPM Name or Url: http://apt.kde-redhat.org/apt/kde-redhat/all/SRPMS.stable/kdetoys-3.5.1-2.src.rpm Description: Includes: * amor: Amusing Misuse Of Resources put's comic figures above your windows * eyesapplet: a kicker applet similar to XEyes * fifteenapplet: kicker applet, order 15 pieces in a 4x4 square by moving them * kaphorism: displays aphorisms * kmoon: system tray applet showing the moon phase * kodo: mouse movement meter * kscore: kicker applet with a sports ticker * kteatime: system tray applet that makes sure your tea doesn't get too strong * ktux: Tux-in-a-Spaceship screen saver * kweather: kicker applet that will display the current weather outside * kworldwatch: application and kicker applet showing daylight area on the world globe -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 24 13:19:32 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 08:19:32 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602241319.k1ODJWc8019441@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From rdieter at math.unl.edu 2006-02-24 08:19 EST ------- %changelog * Fri Feb 24 2006 Rex Dieter 6:3.5.1-3 - -extras: --add-category "X-Fedora" Spec Name or Url: http://apt.kde-redhat.org/apt/kde-redhat/SPECS/kdemultimedia-extras.spec SRPM Name or Url: http://apt.kde-redhat.org/apt/kde-redhat/all/SRPMS.stable/kdemultimedia-extras-3.5.1-3.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From mitr at volny.cz Fri Feb 24 13:38:02 2006 From: mitr at volny.cz (Miloslav Trmac) Date: Fri, 24 Feb 2006 14:38:02 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <87vev5hnp7.fsf@kosh.bigo.ensc.de> References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <43FDF33A.6000503@hhs.nl> <87bqwyvu5a.fsf@kosh.bigo.ensc.de> <43FDFC3E.7010002@hhs.nl> <87vev5hnp7.fsf@kosh.bigo.ensc.de> Message-ID: <43FF0C3A.4060606@volny.cz> Hello, Enrico Scholz napsal(a): > 'malloc' and 'free' are the only higher level functions, all other > functions are simple syscall wrappers and ARE implemented unexploitable > (the related code are perhaps 20 assembly lines). It is right that the > dietlibc 'malloc(3)' implementation suffered the known integer overflow > some time ago. But in the meantime, the related 162 lines of code in > dietlibc have been reviewed several times so it can be assumed as > error-free. Even assuming that it is correct in the current version, there is no reason to assume there won't be introducted any new bugs. Will you be reviewing every new release of dietlibc to verify that there were no bugs in malloc introduced or fixed? If ipsvd dynamically links to glibc, the ipsvd maintainer doesn't have to watch for dietlibc changes; the presence, absence, appearance or fixing of libc bugs is determined purely by the version of glibc installed and not by the version of dietlibc in the repository when ipsvd was rebuilt for some random reason. Mirek From bugzilla at redhat.com Fri Feb 24 13:49:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 08:49:47 -0500 Subject: [Bug 182743] New: Review Request: nessus-libraries Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182743 Summary: Review Request: nessus-libraries Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: andreas.bierfert at lowlatency.de QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://fedora.lowlatency.de/review/nessus-libraries.spec SRPM Name or Url: http://fedora.lowlatency.de/review/nessus-libraries-2.2.6-1.src.rpm Description: Support libraries for nessus -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 24 13:53:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 08:53:53 -0500 Subject: [Bug 182744] New: Review Request: libnasl - Nessus Attack Scripting Language Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182744 Summary: Review Request: libnasl - Nessus Attack Scripting Language Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: andreas.bierfert at lowlatency.de QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://fedora.lowlatency.de/review/libnasl.spec SRPM Name or Url: http://fedora.lowlatency.de/review/libnasl-2.2.6-1.src.rpm Description: The Nessus Security Scanner includes NASL, (Nessus Attack Scripting Language) a language designed to write security test easily and quickly. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 24 14:07:38 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 24 Feb 2006 15:07:38 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <43FF0C3A.4060606@volny.cz> (Miloslav Trmac's message of "Fri, 24 Feb 2006 14:38:02 +0100") References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <43FDF33A.6000503@hhs.nl> <87bqwyvu5a.fsf@kosh.bigo.ensc.de> <43FDFC3E.7010002@hhs.nl> <87vev5hnp7.fsf@kosh.bigo.ensc.de> <43FF0C3A.4060606@volny.cz> Message-ID: <878xs0g89h.fsf@kosh.bigo.ensc.de> mitr at volny.cz (Miloslav Trmac) writes: >> 'malloc' and 'free' are the only higher level functions, all other >> functions are simple syscall wrappers and ARE implemented unexploitable >> (the related code are perhaps 20 assembly lines). It is right that the >> dietlibc 'malloc(3)' implementation suffered the known integer overflow >> some time ago. But in the meantime, the related 162 lines of code in >> dietlibc have been reviewed several times so it can be assumed as >> error-free. > Even assuming that it is correct in the current version, there is no > reason to assume there won't be introducted any new bugs. Will you be > reviewing every new release of dietlibc to verify that there were no > bugs in malloc introduced or fixed? Yes, I will (which is not very difficultly due to the minimal code size). > If ipsvd dynamically links to glibc, the ipsvd maintainer doesn't > have to watch for dietlibc changes; ipvsd is designed for 'dietlibc' (malloc() and friends are the only higher level functions, the other imported functions are pure syscall wrappers). So would not need to take care about dietlibc changes neither. Enrico From rc040203 at freenet.de Fri Feb 24 14:36:24 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 24 Feb 2006 15:36:24 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <87d5hdf4cd.fsf@kosh.bigo.ensc.de> References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <20060223182942.GQ2730@free.fr> <87r75thmku.fsf@kosh.bigo.ensc.de> <1140755074.14289.270.camel@mccallum.corsepiu.local> <87d5hdf4cd.fsf@kosh.bigo.ensc.de> Message-ID: <1140791784.14289.337.camel@mccallum.corsepiu.local> On Fri, 2006-02-24 at 11:17 +0100, Enrico Scholz wrote: > rc040203 at freenet.de (Ralf Corsepius) writes: > > >> In another posting I gave a complete list of used *libc symbols. These > >> were either simple syscall wrappers or well audited code (e.g. malloc()) > >> so you will the same (or better) security as with glibc > > Which is part of the OS and is being used and monitored by the whole > > linux community. > > Do you have numbers, how many people read (and understood) the glibc and > the dietlibc code? It doesn't matter, it's widestly used, and therefore if an exploit or bug should be exposed it'll be very soon be known in public. Also, if behavioral change should be introduced into glibc, these will be available for all applications which are dynamically linked to glibc. All this doesn't apply to dietlibc. > > IMO, dietlibc should be banned from Fedora. Its only purpose is to > > circumvent the OS's libc for highly questionable reasons. > > Efficiency is a "highy questionable reason"? What you call efficiency, I call lack of understanding on software engineering and software integration. A libc is an integral core part of the OS. It provides the essential interface to an OS's kernel and resources, and therefore should not be circumvented. Doing so (like dietlibc) is crappy design. > > As a compromise, I could be persuaded to agree to dynamical linkage against > > dietlibc, but statical linkage against dietlibc is non-acceptable to me. > > Dynamical linkage in dietlibc is highly experimental, is not supported > on all archs and you gain absolutely nothing in the current 'ipsvd' > case. You still don't seem to have understood: I say, there should not be any room for dietlibc in any LINUX distribution - I'd consider to file a request for removal, but unless dietlibc starts to infect my systems, it's not worth the hassle of fighting. Ralf From bugs.michael at gmx.net Fri Feb 24 14:50:22 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 24 Feb 2006 15:50:22 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <87d5hdf4cd.fsf@kosh.bigo.ensc.de> References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <20060223182942.GQ2730@free.fr> <87r75thmku.fsf@kosh.bigo.ensc.de> <1140755074.14289.270.camel@mccallum.corsepiu.local> <87d5hdf4cd.fsf@kosh.bigo.ensc.de> Message-ID: <20060224155022.4f347b0c.bugs.michael@gmx.net> On Fri, 24 Feb 2006 11:17:38 +0100, Enrico Scholz wrote: > > IMO, dietlibc should be banned from Fedora. Its only purpose is to > > circumvent the OS's libc for highly questionable reasons. > > Efficiency is a "highy questionable reason"? To be accurate with regard to the packaging guidelines on linking against shared libraries they say: "should as far as possible". Linking shared against glibc _is_ possible. So, this raises the question why another libc implementation -- let's call it a competing implementation -- shall be preferred in this case? Efficiency? That's one thing that worries me during this discussion: What will be next? Somebody wrote that packagers may decide on their own "what's best". Does this bring us back to a point where packagers may decide for themselves whether to use default RPM optflags or whether to get back to -O3 -funroll-loops and other forms of "optimisation hell"? On the contrary, this thread has not discussed any numbers that prove the efficiency gain. Instead, it has gone as far as discussing the secureness of low-level C functions. So, once more, what is the overwhelming reason for preferring a competing C library over the core OS's C library? From j.w.r.degoede at hhs.nl Fri Feb 24 15:07:41 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 24 Feb 2006 16:07:41 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <878xs0g89h.fsf@kosh.bigo.ensc.de> References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <43FDF33A.6000503@hhs.nl> <87bqwyvu5a.fsf@kosh.bigo.ensc.de> <43FDFC3E.7010002@hhs.nl> <87vev5hnp7.fsf@kosh.bigo.ensc.de> <43FF0C3A.4060606@volny.cz> <878xs0g89h.fsf@kosh.bigo.ensc.de> Message-ID: <43FF213D.60504@hhs.nl> Enrico Scholz wrote: > mitr at volny.cz (Miloslav Trmac) writes: >> If ipsvd dynamically links to glibc, the ipsvd maintainer doesn't >> have to watch for dietlibc changes; > > ipvsd is designed for 'dietlibc' (malloc() and friends are the only > higher level functions, the other imported functions are pure syscall > wrappers). So would not need to take care about dietlibc changes > neither. > Please stop claiming this, using dietlibc is your idea, ipvsd upstream does not advice let alone propagandizes this. Regards, Hans From j.w.r.degoede at hhs.nl Fri Feb 24 15:09:39 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 24 Feb 2006 16:09:39 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <20060224155022.4f347b0c.bugs.michael@gmx.net> References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <20060223182942.GQ2730@free.fr> <87r75thmku.fsf@kosh.bigo.ensc.de> <1140755074.14289.270.camel@mccallum.corsepiu.local> <87d5hdf4cd.fsf@kosh.bigo.ensc.de> <20060224155022.4f347b0c.bugs.michael@gmx.net> Message-ID: <43FF21B3.4010302@hhs.nl> Michael Schwendt wrote: > On Fri, 24 Feb 2006 11:17:38 +0100, Enrico Scholz wrote: > >>> IMO, dietlibc should be banned from Fedora. Its only purpose is to >>> circumvent the OS's libc for highly questionable reasons. >> Efficiency is a "highy questionable reason"? > > To be accurate with regard to the packaging guidelines on linking against > shared libraries they say: "should as far as possible". Linking shared > against glibc _is_ possible. So, this raises the question why another libc > implementation -- let's call it a competing implementation -- shall be > preferred in this case? Efficiency? That's one thing that worries me > during this discussion: What will be next? Somebody wrote that packagers > may decide on their own "what's best". Does this bring us back to a point > where packagers may decide for themselves whether to use default RPM > optflags or whether to get back to -O3 -funroll-loops and other forms of > "optimisation hell"? On the contrary, this thread has not discussed any > numbers that prove the efficiency gain. Instead, it has gone as far as > discussing the secureness of low-level C functions. So, once more, what is > the overwhelming reason for preferring a competing C library over the core > OS's C library? > Exactly, I agree 100% and I especially agree with the no numbers shown argument, I've asked for numbers on the efficiency increase before, where are those numbers? Regards, Hans From j.w.r.degoede at hhs.nl Fri Feb 24 15:11:14 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 24 Feb 2006 16:11:14 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <1140791784.14289.337.camel@mccallum.corsepiu.local> References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <20060223182942.GQ2730@free.fr> <87r75thmku.fsf@kosh.bigo.ensc.de> <1140755074.14289.270.camel@mccallum.corsepiu.local> <87d5hdf4cd.fsf@kosh.bigo.ensc.de> <1140791784.14289.337.camel@mccallum.corsepiu.local> Message-ID: <43FF2212.1040802@hhs.nl> Ralf Corsepius wrote: > On Fri, 2006-02-24 at 11:17 +0100, Enrico Scholz wrote: >> rc040203 at freenet.de (Ralf Corsepius) writes: >> >>> As a compromise, I could be persuaded to agree to dynamical linkage against >>> dietlibc, but statical linkage against dietlibc is non-acceptable to me. >> Dynamical linkage in dietlibc is highly experimental, is not supported >> on all archs and you gain absolutely nothing in the current 'ipsvd' >> case. > You still don't seem to have understood: I say, there should not be any > room for dietlibc in any LINUX distribution - I'd consider to file a > request for removal, but unless dietlibc starts to infect my systems, > it's not worth the hassle of fighting. > Considering this discussion and the fact that this will create a precedence I say that it is worth fighting, what is the procedure for requesting removal? Regards, Hans From bugzilla at redhat.com Fri Feb 24 14:57:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 09:57:11 -0500 Subject: [Bug 182743] Review Request: nessus-libraries In-Reply-To: Message-ID: <200602241457.k1OEvBdA009304@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: nessus-libraries https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182743 gajownik at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gajownik at gmail.com ------- Additional Comments From gajownik at gmail.com 2006-02-24 09:57 EST ------- I've been playing with nessus some time ago. You may want to take a look at my patches and spec files ? http://fedora.pl/~gajownik/nessus/ IIRC nessus-plugins was not finished -- after one week of patching I was fed up ;-) https://www.redhat.com/archives/fedora-extras-list/2005-July/msg00380.html -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rc040203 at freenet.de Fri Feb 24 15:13:03 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 24 Feb 2006 16:13:03 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <20060224155022.4f347b0c.bugs.michael@gmx.net> References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <20060223182942.GQ2730@free.fr> <87r75thmku.fsf@kosh.bigo.ensc.de> <1140755074.14289.270.camel@mccallum.corsepiu.local> <87d5hdf4cd.fsf@kosh.bigo.ensc.de> <20060224155022.4f347b0c.bugs.michael@gmx.net> Message-ID: <1140793983.14289.361.camel@mccallum.corsepiu.local> On Fri, 2006-02-24 at 15:50 +0100, Michael Schwendt wrote: > On Fri, 24 Feb 2006 11:17:38 +0100, Enrico Scholz wrote: > > > > IMO, dietlibc should be banned from Fedora. Its only purpose is to > > > circumvent the OS's libc for highly questionable reasons. > > > > Efficiency is a "highy questionable reason"? > > To be accurate with regard to the packaging guidelines on linking against > shared libraries they say: "should as far as possible". Linking shared > against glibc _is_ possible. IMO, wrt. glibc this should be changed into "static linkage against glibc is strongly discouraged and must be explained for exceptional cases". > So, this raises the question why another libc > implementation -- let's call it a competing implementation -- shall be > preferred in this case? I guess you are aware there exist circular dependencies between the kernel, glibc and gcc? I.e. strictly speaking, an alternative libc must not even use a GCC which had been compiled against glibc, but should be accompanied by a corresponding, alternative GCC. Similar considerations apply when linking libraries having been compiled against an alternative libc with libraries which had been compiled against glibc - There is no guarantee whatsoever this will work (Think about inlined functions being used inside of libaries). Ralf From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 24 15:13:20 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 24 Feb 2006 16:13:20 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <43FF213D.60504@hhs.nl> (Hans de Goede's message of "Fri, 24 Feb 2006 16:07:41 +0100") References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <43FDF33A.6000503@hhs.nl> <87bqwyvu5a.fsf@kosh.bigo.ensc.de> <43FDFC3E.7010002@hhs.nl> <87vev5hnp7.fsf@kosh.bigo.ensc.de> <43FF0C3A.4060606@volny.cz> <878xs0g89h.fsf@kosh.bigo.ensc.de> <43FF213D.60504@hhs.nl> Message-ID: <878xs0g57z.fsf@kosh.bigo.ensc.de> j.w.r.degoede at hhs.nl (Hans de Goede) writes: >>> If ipsvd dynamically links to glibc, the ipsvd maintainer doesn't >>> have to watch for dietlibc changes; >> ipvsd is designed for 'dietlibc' (malloc() and friends are the only >> higher level functions, the other imported functions are pure syscall >> wrappers). So would not need to take care about dietlibc changes >> neither. > > Please stop claiming this, using dietlibc is your idea, ipvsd upstream > does not advice upstream mentions 'dietlibc' several times and praises low memory consumption. I would interpret this as 'advice'... Enrico PS: numbers will follow soon... From bugzilla at redhat.com Fri Feb 24 15:20:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 10:20:50 -0500 Subject: [Bug 177107] Review Request: libgeda - library for gEDA circuit design software In-Reply-To: Message-ID: <200602241520.k1OFKoHU016591@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libgeda - library for gEDA circuit design software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177107 ------- Additional Comments From wk at ire.pw.edu.pl 2006-02-24 10:20 EST ------- I have applied some corrections to gEDA specfiles in response to the above comments. Specfiles are at: http://www.sp5pbe.waw.pl/~sp5smk/fedora-extras/specs2/ Source RPM is at: http://www.sp5pbe.waw.pl/~sp5smk/fedora-extras/srpms/ Please check/review -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 24 15:21:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 10:21:50 -0500 Subject: [Bug 177108] Review Request: geda-gschem - schematic editor for gEDA circuit design software In-Reply-To: Message-ID: <200602241521.k1OFLoSh016908@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: geda-gschem - schematic editor for gEDA circuit design software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177108 ------- Additional Comments From wk at ire.pw.edu.pl 2006-02-24 10:21 EST ------- I have applied some corrections to gEDA specfiles in response to the above comments. Specfiles are at: http://www.sp5pbe.waw.pl/~sp5smk/fedora-extras/specs2/ Source RPM is at: http://www.sp5pbe.waw.pl/~sp5smk/fedora-extras/srpms/ Please check/review -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From buildsys at fedoraproject.org Fri Feb 24 15:45:54 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 24 Feb 2006 10:45:54 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060224154554.557EF8011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 3 dap-freeform_handler-3.5.0-1.fc3 gtk-gnutella-0.96.1-1.fc3 scim-1.4.4-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri Feb 24 15:46:56 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 24 Feb 2006 10:46:56 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060224154656.BC8DC8011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 25 TurboGears-0.8a5-1.fc4 bwidget-1.7.0-2.fc4 cpan2rpm-2.028-1.fc4 dap-freeform_handler-3.5.0-1.fc4 dap-netcdf_handler-3.5.2-2.fc4 fftw-3.1-3.fc4 freedroid-1.0.2-5.fc4 git-1.2.2-1.fc4 git-1.2.3-1.fc4 gtk-gnutella-0.96.1-1.fc4 gtkwave-1.3.84-1.fc4 itk-3.3-0.2.RC1.fc4 iwidgets-4.0.1-3.fc4 libosip2-2.2.2-2.fc4 mod_geoip-1.1.7-2.fc4 perl-GD-2.31-1.fc4 perl-SQL-Statement-1.15-1.fc4 perl-UNIVERSAL-isa-0.06-1.fc4 python-GeoIP-1.2.1-3.fc4 qps-1.9.12-1.fc4 rtorrent-0.4.5-1.fc4 scim-1.4.4-1.fc4 scorched3d-39.1-5.fc4 tile-0.7.2-3.fc4 tong-1.0-6.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri Feb 24 15:47:47 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 24 Feb 2006 10:47:47 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060224154747.AC7E08011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 14 cpan2rpm-2.028-1.fc5 deskbar-applet-2.13.91-3.fc5 fftw-3.1-4.fc5 gtk-gnutella-0.96.1-1.fc5 perl-Cache-Simple-TimedExpiry-0.23-3.fc5 perl-PAR-Dist-0.08-1.fc5 perl-SQL-Statement-1.15-1.fc5 perl-Sub-Uplevel-0.09-4.fc5 perl-UNIVERSAL-isa-0.06-1.fc5 rtorrent-0.4.5-1.fc5 scorched3d-39.1-5.fc5 seahorse-0.8-3.fc5 tla-1.3.3-6.fc5 tong-1.0-6.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Fri Feb 24 15:47:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 10:47:21 -0500 Subject: [Bug 182743] Review Request: nessus-libraries In-Reply-To: Message-ID: <200602241547.k1OFlLlX024843@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: nessus-libraries https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182743 ------- Additional Comments From andreas.bierfert at lowlatency.de 2006-02-24 10:47 EST ------- Thanks for posting... I will take a look and see what I can use/integrate if you don't mind :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 24 15:47:43 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 10:47:43 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602241547.k1OFlhFG025019@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From jwb at redhat.com 2006-02-24 10:47 EST ------- Updated packages. I've had to switch to using a CVS tarball in order to rebuild the MANIFEST properly, which is reflected in the specfile changelog. CVS also gave me a bunch more modules, those are separated as the standard ones are. This build seems to install and configure properly, with the caveat that the database has to be created independently. New package locations: SPEC: http://www.berningeronline.net/gallery2.spec SRPM: http://www.berningeronline.net/gallery2-2.0.2-0.7cvs20060223.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 24 15:49:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 10:49:53 -0500 Subject: [Bug 172140] Review Request: libmal: a convenience library for malsync In-Reply-To: Message-ID: <200602241549.k1OFnrEQ025501@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libmal: a convenience library for malsync https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172140 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |jpmahowald at gmail.com OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-24 10:49 EST ------- Looks good overall, a few nitpicks: Needs work: * rpmlint of libmal: Remove empty files and capitalize summary. * The package should contain the text of the license (wiki: PackageReviewGuidelines) Just a couple spec tweaks, and query the author to package the license with the tarball. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 24 16:06:32 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 11:06:32 -0500 Subject: [Bug 182743] Review Request: nessus-libraries In-Reply-To: Message-ID: <200602241606.k1OG6WED030283@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: nessus-libraries https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182743 ------- Additional Comments From gajownik at gmail.com 2006-02-24 11:06 EST ------- (In reply to comment #2) > I will take a look and see what I can use/integrate if you don't mind :) Shure. That's the reason why I gave you link to these patches :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 24 16:11:19 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 11:11:19 -0500 Subject: [Bug 174021] Review Request: aplus-fsf - Advanced APL Interpreter In-Reply-To: Message-ID: <200602241611.k1OGBJE0031386@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: aplus-fsf - Advanced APL Interpreter https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174021 ------- Additional Comments From jpmahowald at gmail.com 2006-02-24 11:11 EST ------- For some reason I get a bad MD5 digest. What should the md5sum/sha1sum of the src rpm be? Also, note that with modular X your X defines and BuildRequires need another look. http://mharris.ca/xorg/xorg-modularization-status.html -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 24 16:20:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 11:20:47 -0500 Subject: [Bug 182744] Review Request: libnasl - Nessus Attack Scripting Language In-Reply-To: Message-ID: <200602241620.k1OGKl2a001049@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libnasl - Nessus Attack Scripting Language https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182744 ------- Additional Comments From andreas.bierfert at lowlatency.de 2006-02-24 11:20 EST ------- Some tuneups (see #182743 for details) :) http://fedora.lowlatency.de/review/libnasl-2.2.6-2.src.rpm http://fedora.lowlatency.de/review/libnasl.spec -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 24 16:22:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 11:22:49 -0500 Subject: [Bug 182743] Review Request: nessus-libraries In-Reply-To: Message-ID: <200602241622.k1OGMnWD001996@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: nessus-libraries https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182743 ------- Additional Comments From andreas.bierfert at lowlatency.de 2006-02-24 11:22 EST ------- Ok here are the first tuneups :) Thanks again =) http://fedora.lowlatency.de/review/nessus-libraries.spec http://fedora.lowlatency.de/review/nessus-libraries-2.2.6-2.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 24 16:29:34 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 24 Feb 2006 17:29:34 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <43FE30C8.1070200@hhs.nl> (Hans de Goede's message of "Thu, 23 Feb 2006 23:01:44 +0100") References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <20060223182942.GQ2730@free.fr> <87r75thmku.fsf@kosh.bigo.ensc.de> <20060223213919.GA3059@free.fr> <43FE30C8.1070200@hhs.nl> Message-ID: <874q2og1ox.fsf@kosh.bigo.ensc.de> j.w.r.degoede at hhs.nl (Hans de Goede) writes: > I for one am still far from convinced what exactly are those effiecency > gains, numbers please. ok, I executed the following sequence: for i in `seq 0 10`; do for F in ds glibc diet; do echo "$F/$i" ; { time /tmp/tcpsvd.$F 127.0.0.1 1024 ~/tmp/r & } &>/tmp/res.$F.$i ; ~/tmp/s 10000 50 127.0.0.1 1024; killall tcpsvd.$F; wait; done; done which * executes a static dietlibc linked 'tcpsvd.ds' (F=='ds'), a dynlinked dietlibc 'tcpsvd.diet' (F=='diet') and a glibc linked 'tcpsvd.glibc' (F=='glibc') * tcpsvd listens on localhost, port 1024 and executes program ~/tmp/r * ~/tmp/s makes 10000 requests as fast as possible but not more than 50 at the same time * all this will be done 11 times for each $F * results will be stored into /tmp/res.{diet,ds,glibc}.$RUN This gives the following numbers (values of static linked dietlibc are assumed as 100%): user-time: res.ds.* res.diet.* res.glibc.* 0m0.000s(#) 0m0.260s 0m0.356s 0m0.180s 0m0.308s 0m0.344s 0m0.220s 0m0.300s 0m0.348s 0m0.160s 0m0.328s 0m0.364s 0m0.212s 0m0.288s 0m0.404s 0m0.208s 0m0.296s 0m0.332s 0m0.148s 0m0.348s 0m0.280s 0m0.172s 0m0.308s 0m0.304s 0m0.224s 0m0.324s 0m0.292s 0m0.212s 0m0.312s 0m0.368s 0m0.212s 0m0.280s 0m0.352s -------------------------------------- 0m0.195s 0m0.305s 0m0.340s 100% 156% 175% sys-time res.ds.* res.diet.* res.glibc.* 0m0.000s(#) 0m1.516s 0m2.248s 0m1.212s 0m1.748s 0m2.124s 0m1.512s 0m1.412s 0m2.160s 0m1.296s 0m1.672s 0m2.204s 0m1.240s 0m1.764s 0m2.192s 0m1.340s 0m1.748s 0m2.132s 0m1.444s 0m1.716s 0m1.944s 0m1.612s 0m1.720s 0m1.980s 0m1.428s 0m1.808s 0m1.924s 0m1.492s 0m1.804s 0m1.968s 0m1.480s 0m1.640s 0m2.120s -------------------------------------- 0m1.406s 0m1.686s 0m2.090s 100% 119% 149% (#) ... socket was blocked by older process; ignored The 'real' times were omitted because they are having a very high variance; see http://ensc.de/diet/ for the values Comparing static sizes: $ ls -l tcpsvd.{ds,diet,glibc} -rwxr-xr-x 1 ensc ensc 38788 23. Feb 23:28 tcpsvd.diet 100% -rwxr-xr-x 1 ensc ensc 33308 24. Feb 00:26 tcpsvd.ds 86% -rwxr-xr-x 1 ensc ensc 47352 23. Feb 23:29 tcpsvd.glibc 122% $ ps u VSZ RSS VSZ% RSS% ... 132 44 pts/20 S+ 17:05 0:00 /tmp/tcpsvd.ds ... 100% 100% ... 324 160 pts/20 S+ 17:06 0:00 /tmp/tcpsvd.diet ... 245% 364% ... 1636 500 pts/20 S+ 17:14 0:00 /tmp/tcpsvd.glibc ... 1239% 1136% As you can see, the static dietlibc linked application outperforms both the dynamic linked and especially the glibc linked version significantly. Environment: FC4, P4 2.8GHz HT, 1GB RAM The 'r' and 's' programs were built with 'diet -Os gcc ...' and are available at http://ensc.de/diet/r.c and http://ensc.de/diet/s.c Enrico From bugzilla at redhat.com Fri Feb 24 16:34:38 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 11:34:38 -0500 Subject: [Bug 180422] Review Request: gnome-mud In-Reply-To: Message-ID: <200602241634.k1OGYcpu006095@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-mud https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180422 sysadmin at tacticalbusinesspartners.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |CANTFIX ------- Additional Comments From sysadmin at tacticalbusinesspartners.com 2006-02-24 11:34 EST ------- Development stopped for two reasons: 1. Found project more worthwhile for insertion into Extras 2. Found better coded MUD editor. Kmuddy, already included in Extras. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 24 16:34:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 11:34:36 -0500 Subject: [Bug 175500] Review Request: compat-wxGTK & compat-wxPythonGTK2 In-Reply-To: Message-ID: <200602241634.k1OGYagD006078@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: compat-wxGTK & compat-wxPythonGTK2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175500 matthias at rpmforge.net changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: compat- |Review Request: compat-wxGTK |wxGTK2 & compat-wxPythonGTK2|& compat-wxPythonGTK2 ------- Additional Comments From matthias at rpmforge.net 2006-02-24 11:34 EST ------- I see these have been imported, but only compat-wxGTK bas been built in FC5, is that wanted? What about FC4? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 24 16:34:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 11:34:49 -0500 Subject: [Bug 177841] Tracker: New Extras packages that need a sponsor In-Reply-To: Message-ID: <200602241634.k1OGYndU006210@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Tracker: New Extras packages that need a sponsor Alias: FE-NEEDSPONSOR https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177841 Bug 177841 depends on bug 180422, which changed state. Bug 180422 Summary: Review Request: gnome-mud https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180422 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |CANTFIX Status|NEW |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From somlo at cmu.edu Fri Feb 24 16:40:33 2006 From: somlo at cmu.edu (Gabriel L. Somlo) Date: Fri, 24 Feb 2006 11:40:33 -0500 Subject: please help: %doc causing extra dependencies ? Message-ID: <20060224164033.GA9696@hedwig.net.cmu.edu> There's a package I'm working on, and it has a contrib directory, which I'd like to add to /usr/share/doc// Trouble is, there are a couple of perl scripts in contrib, and my package suddenly ends up requiring perl. There's no perl anywhere else, except in the scripts that get added because of %doc in the %files section. How can I still add these things as *documentation*, without them causing my package to require PERL ? I've already tried removing the executable attribute on the files, but the package still ends up requiring perl... Thanks, Gabriel From bugzilla at redhat.com Fri Feb 24 16:49:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 11:49:15 -0500 Subject: [Bug 174866] Review Request: polypaudio: Improved Linux sound server In-Reply-To: Message-ID: <200602241649.k1OGnFOx011818@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: polypaudio: Improved Linux sound server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174866 ------- Additional Comments From drzeus-bugzilla at drzeus.cx 2006-02-24 11:49 EST ------- What's the status of this? The links in the initial comment are dead. I'd really like to see this included in Fedora. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 24 16:56:35 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 24 Feb 2006 17:56:35 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <874q2og1ox.fsf@kosh.bigo.ensc.de> (Enrico Scholz's message of "Fri, 24 Feb 2006 17:29:34 +0100") References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <20060223182942.GQ2730@free.fr> <87r75thmku.fsf@kosh.bigo.ensc.de> <20060223213919.GA3059@free.fr> <43FE30C8.1070200@hhs.nl> <874q2og1ox.fsf@kosh.bigo.ensc.de> Message-ID: <87wtfkelvg.fsf@kosh.bigo.ensc.de> ok, completing the numbers and assuming a dietlibc less world, we will have to compile 'r' dynamically which results into the following datasets: user-time: res.ds.* res.diet.* res.glibc.* resD.glibc.* 0m0.000s(#) 0m0.260s 0m0.356s 0m1.088s 0m0.180s 0m0.308s 0m0.344s 0m1.124s 0m0.220s 0m0.300s 0m0.348s 0m1.140s 0m0.160s 0m0.328s 0m0.364s 0m1.172s 0m0.212s 0m0.288s 0m0.404s 0m1.060s 0m0.208s 0m0.296s 0m0.332s 0m1.072s 0m0.148s 0m0.348s 0m0.280s 0m1.108s 0m0.172s 0m0.308s 0m0.304s 0m1.080s 0m0.224s 0m0.324s 0m0.292s 0m0.972s 0m0.212s 0m0.312s 0m0.368s 0m1.092s 0m0.212s 0m0.280s 0m0.352s 0m1.000s ------------------------------------------------------ 0m0.195s 0m0.305s 0m0.340s 0m1.083s 100% 156% 175% 555% sys-time res.ds.* res.diet.* res.glibc.* resD.glibc.* 0m0.000s(#) 0m1.516s 0m2.248s 0m4.100s 0m1.212s 0m1.748s 0m2.124s 0m4.084s 0m1.512s 0m1.412s 0m2.160s 0m3.988s 0m1.296s 0m1.672s 0m2.204s 0m4.060s 0m1.240s 0m1.764s 0m2.192s 0m3.444s 0m1.340s 0m1.748s 0m2.132s 0m3.804s 0m1.444s 0m1.716s 0m1.944s 0m4.040s 0m1.612s 0m1.720s 0m1.980s 0m4.044s 0m1.428s 0m1.808s 0m1.924s 0m3.688s 0m1.492s 0m1.804s 0m1.968s 0m3.864s 0m1.480s 0m1.640s 0m2.120s 0m4.152s ------------------------------------------------------ 0m1.406s 0m1.686s 0m2.090s 0m3.933s 100% 119% 149% 279% > $ ls -l tcpsvd.{ds,diet,glibc} > -rwxr-xr-x 1 ensc ensc 38788 23. Feb 23:28 tcpsvd.diet 100% > -rwxr-xr-x 1 ensc ensc 33308 24. Feb 00:26 tcpsvd.ds 86% > -rwxr-xr-x 1 ensc ensc 47352 23. Feb 23:29 tcpsvd.glibc 122% This is obviously a wrong order; the static linked dietlibc version wins here too: -rwxr-xr-x 1 ensc ensc 33308 24. Feb 00:26 tcpsvd.ds 100% -rwxr-xr-x 1 ensc ensc 38788 23. Feb 23:28 tcpsvd.diet 116% -rwxr-xr-x 1 ensc ensc 47352 23. Feb 23:29 tcpsvd.glibc 142% Enrico From bugzilla at redhat.com Fri Feb 24 16:51:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 11:51:52 -0500 Subject: [Bug 182415] Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project In-Reply-To: Message-ID: <200602241651.k1OGpqTf012663@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182415 ------- Additional Comments From andy at smile.org.ua 2006-02-24 11:51 EST ------- While I am looking for license of previous files I found new page with newest tarballs. The tarball includes license now and project not dead. Spec Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/man-pages- uk.spec SRPM Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/man-pages- uk-0.1-0.1.20051210wiki.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From andy at smile.org.ua Fri Feb 24 17:01:03 2006 From: andy at smile.org.ua (Andy Shevchenko) Date: Fri, 24 Feb 2006 19:01:03 +0200 Subject: reviewing (was: Anjuta - change of maintainer) In-Reply-To: <20060223233118.422ac37c.bugs.michael@gmx.net> References: <1140476355.2971.1.camel@T7.Linux> <13dbfe4f0602201500w25dcc9dcp3ba8f1db893e7f7a@mail.gmail.com> <1140476701.2971.3.camel@T7.Linux> <13dbfe4f0602201520v21ee0d3br46b04df50eea092b@mail.gmail.com> <1140477835.2971.5.camel@T7.Linux> <13dbfe4f0602211544g643afe6ev3dd6b3419c3e1f6c@mail.gmail.com> <1140565626.31940.14.camel@T7.Linux> <13dbfe4f0602220604l1f30f6b6w1511f42ad780fa89@mail.gmail.com> <1140622767.31392.33.camel@mrwibble.mrwobble> <20060222183059.32178be3.bugs.michael@gmx.net> <13dbfe4f0602221003l463d483fp99ed352b8f5d189d@mail.gmail.com> <20060222210435.20f0ea47.bugs.michael@gmx.net> <43FDE220.5090804@smile.org.ua> <20060223233118.422ac37c.bugs.michael@gmx.net> Message-ID: <43FF3BCF.2020801@smile.org.ua> Hi, Michael! As I see you are a sponsor for FE contributors. Could you helps me and review the next request? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182415 Thank you. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From dan at danny.cz Fri Feb 24 17:14:31 2006 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Fri, 24 Feb 2006 18:14:31 +0100 Subject: requires for lcov In-Reply-To: <20060224092845.27205180A66@magilla.sf.frob.com> References: <20060224092845.27205180A66@magilla.sf.frob.com> Message-ID: <1140801271.7586.7.camel@eagle.danny.cz> Roland McGrath p??e v P? 24. 02. 2006 v 01:28 -0800: > > If lcov calls /usr/bin/gcov, esp. if it contains a hard-coded reference > > to this file, is absolutely perfect. > > > > If lconv calls "gcov" on $PATH, then there'd be some room for > > argumentation. > > In fact it runs "gcov" using the path. What to run can be set in a > configuration file. Should I make the default /usr/bin/gcov instead? That > would annoy someone who installed their own gcc build, but they could edit > the config file. I'm inclined to leave it as it is, and wish for an rpm > pseudo-dependency meaning "there is a foobar command in the local standard > path for users". > I would make it specified in the config file to be consistent with the spec file and add a note for the experienced users to point it to the gcov from their gcc instalation. Something like "change this for non-Fedora GCC instalations". --- lcovrc.orig 2006-02-24 18:12:01.000000000 +0100 +++ lcovrc 2006-02-24 18:12:35.000000000 +0100 @@ -51,7 +51,8 @@ genhtml_highlight = 0 # Location of the gcov tool (used by geninfo) -#geninfo_gcov_tool = gcov +# Change this for non-Fedora GCC instalations +geninfo_gcov_tool = /usr/bin/gcov # Adjust test names to include operating system information if non-zero #geninfo_adjust_testname = 0 > My thinking in using the file dependency was as mentioned, that gcov might > conceivably move to a different package in the future. (There is no > special reason to expect that to happen.) That is reasonable. Dan From bugzilla at redhat.com Fri Feb 24 17:09:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 12:09:50 -0500 Subject: [Bug 182941] New: Review Request: nessus-core Network vulnerability scanner Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182941 Summary: Review Request: nessus-core Network vulnerability scanner Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: andreas.bierfert at lowlatency.de QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://fedora.lowlatency.de/review/nessus-core.spec SRPM Name or Url: http://fedora.lowlatency.de/review/nessus-core-2.2.6-1.src.rpm Description: Nessus is the world's most popular vulnerability scanner used in over 75,000 organizations world-wide. Many of the world's largest organizations are realizing significant cost savings by using Nessus to audit business-critical enterprise devices and applications. The "Nessus" Project was started by Renaud Deraison in 1998 to provide to the internet community a free, powerful, up-to-date and easy to use remote security scanner. Nessus is currently rated among the top products of its type throughout the security industry and is endorsed by professional information security organizations such as the SANS Institute. It is estimated that the Nessus scanner is used by 75,000 organizations world-wide. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From ville.skytta at iki.fi Fri Feb 24 17:17:55 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 24 Feb 2006 19:17:55 +0200 Subject: please help: %doc causing extra dependencies ? In-Reply-To: <20060224164033.GA9696@hedwig.net.cmu.edu> References: <20060224164033.GA9696@hedwig.net.cmu.edu> Message-ID: <1140801475.14325.14.camel@bobcat.mine.nu> On Fri, 2006-02-24 at 11:40 -0500, Gabriel L. Somlo wrote: > How can I still add these things as *documentation*, without them > causing my package to require PERL ? I've already tried removing > the executable attribute on the files, but the package still ends up > requiring perl... Could you upload the specfile/SRPM somewhere for examination? My crystal ball is a bit dim at the moment ;) From j.w.r.degoede at hhs.nl Fri Feb 24 18:05:59 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 24 Feb 2006 19:05:59 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <87wtfkelvg.fsf@kosh.bigo.ensc.de> References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <20060223182942.GQ2730@free.fr> <87r75thmku.fsf@kosh.bigo.ensc.de> <20060223213919.GA3059@free.fr> <43FE30C8.1070200@hhs.nl> <874q2og1ox.fsf@kosh.bigo.ensc.de> <87wtfkelvg.fsf@kosh.bigo.ensc.de> Message-ID: <43FF4B07.4070103@hhs.nl> Enrico Scholz wrote: > ok, completing the numbers and assuming a dietlibc less world, we will > have to compile 'r' dynamically which results into the following > datasets: > > user-time: > res.ds.* res.diet.* res.glibc.* resD.glibc.* > 0m0.000s(#) 0m0.260s 0m0.356s 0m1.088s > 0m0.180s 0m0.308s 0m0.344s 0m1.124s > 0m0.220s 0m0.300s 0m0.348s 0m1.140s > 0m0.160s 0m0.328s 0m0.364s 0m1.172s > 0m0.212s 0m0.288s 0m0.404s 0m1.060s > 0m0.208s 0m0.296s 0m0.332s 0m1.072s > 0m0.148s 0m0.348s 0m0.280s 0m1.108s > 0m0.172s 0m0.308s 0m0.304s 0m1.080s > 0m0.224s 0m0.324s 0m0.292s 0m0.972s > 0m0.212s 0m0.312s 0m0.368s 0m1.092s > 0m0.212s 0m0.280s 0m0.352s 0m1.000s > ------------------------------------------------------ > 0m0.195s 0m0.305s 0m0.340s 0m1.083s > 100% 156% 175% 555% > > > sys-time > res.ds.* res.diet.* res.glibc.* resD.glibc.* > 0m0.000s(#) 0m1.516s 0m2.248s 0m4.100s > 0m1.212s 0m1.748s 0m2.124s 0m4.084s > 0m1.512s 0m1.412s 0m2.160s 0m3.988s > 0m1.296s 0m1.672s 0m2.204s 0m4.060s > 0m1.240s 0m1.764s 0m2.192s 0m3.444s > 0m1.340s 0m1.748s 0m2.132s 0m3.804s > 0m1.444s 0m1.716s 0m1.944s 0m4.040s > 0m1.612s 0m1.720s 0m1.980s 0m4.044s > 0m1.428s 0m1.808s 0m1.924s 0m3.688s > 0m1.492s 0m1.804s 0m1.968s 0m3.864s > 0m1.480s 0m1.640s 0m2.120s 0m4.152s > ------------------------------------------------------ > 0m1.406s 0m1.686s 0m2.090s 0m3.933s > 100% 119% 149% 279% > > Yes, all very interesting but you're using a static inetd like in.xxx program for these tests, unless you want to argue that all programs executed by invsd are going to be static linked too, in which case you can start to vastly expand you're auditing of dietlibc to all functionality such a in.xxx program could use, so basicly to all functionality I would like to see results for resD.diet and resD.ds and compare those to resD.glibc About your resident sizes results this doesn't take the shared part of this into the picture. Please substract the shared part (minus the stripped binary size) from these figures since the few basic glibc functions used will be resident already in any realistic Fedora test scenario. Regards, Hans From bugzilla at redhat.com Fri Feb 24 18:11:41 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 13:11:41 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602241811.k1OIBfcr031862@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From orion at cora.nwra.com 2006-02-24 13:11 EST ------- (In reply to comment #23) > > I am not sure I understand what you mean by this. I think you want me to change > this line: > USEROPT="-g haclient -u 17 -d /var/lib/heartbeat/cores/hacluster" > to: > USEROPT="-g haclient -u $[ $(cat /etc/fedora/usermgmt/baseuid) + 17 ] -d > /var/lib/heartbeat/cores/hacluster" > Correct? > Well, if you can live without a fixed user id, drop the '-u 17'. If you need a fixed one, register with http://fedoraproject.org/wiki/Packaging/UserRegistry and use that offset rather than 17. I think I would drop the redirection to /dev/null as well. > > - rpmlint: > > > > # rpmlint heartbeat-pils > > W: heartbeat-pils devel-file-in-non-devel-package /usr/lib/libpils.so > > ^ this should be in heartbeat-devel (or heartbeat-pils-devel) > > > I am unsure what to do here: > * Do *.so files always go in a seperate -devel package or just in this case? > What to do with /usr/lib/pils/plugins/InterfaceMgr/generic.so file? > * You know that /usr/lib/libpils.so symlinks to > /usr/lib/libpils.so.1.0.0; should this also go in -devel package? > .so files always go in -devel (and just the .so links, not the actual libraries). > > E: heartbeat-pils library-without-ldconfig-postin /usr/lib/libpils.so.1.0.0 > > E: heartbeat-pils library-without-ldconfig-postun /usr/lib/libpils.so.1.0.0 > > ^ needs: > > %post pils -p /sbin/ldconfig > > %postun pils -p /sbin/ldconfig > > If these files go to -devel package They don't. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 24 18:13:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 13:13:47 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602241813.k1OIDlkK032253@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From orion at cora.nwra.com 2006-02-24 13:13 EST ------- (In reply to comment #24) > Regarding helper.sh > > It is *never* supposed to be executed on its own and should not have #!/bin/sh added to to it. If this is the case, then you can safely ignore the rpmlint warning here Joost. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 24 18:21:58 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 24 Feb 2006 19:21:58 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <43FF4B07.4070103@hhs.nl> (Hans de Goede's message of "Fri, 24 Feb 2006 19:05:59 +0100") References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <20060223182942.GQ2730@free.fr> <87r75thmku.fsf@kosh.bigo.ensc.de> <20060223213919.GA3059@free.fr> <43FE30C8.1070200@hhs.nl> <874q2og1ox.fsf@kosh.bigo.ensc.de> <87wtfkelvg.fsf@kosh.bigo.ensc.de> <43FF4B07.4070103@hhs.nl> Message-ID: <87d5hcfwhl.fsf@kosh.bigo.ensc.de> j.w.r.degoede at hhs.nl (Hans de Goede) writes: >> user-time: >> res.ds.* res.diet.* res.glibc.* ... >> 0m0.195s 0m0.305s 0m0.340s ... >> 100% 156% 175% ... >> >> sys-time >> res.ds.* res.diet.* res.glibc.* ... >> 0m1.406s 0m1.686s 0m2.090s ... >> 100% 119% 149% ... > > Yes, all very interesting but you're using a static inetd like in.xxx > program for these tests, fwiw, 'ipvsd' was submitted by me because 'fnord'[1] requires a daemontools like inetd. And 'fnord' is heavily (and probably explicitly) advised to be linked against dietlibc. > unless you want to argue that all programs executed by invsd are going > to be static linked too, in which case you can start to vastly expand > you're auditing of dietlibc to all functionality such a in.xxx program > could use, so basicly to all functionality I would like to see results > for resD.diet and resD.ds and compare those to resD.glibc No; this subthread exists to decide whether dietlibc increases performance of 'ipvsd' significantly. Therefore, only the code executed within 'tcpsvd' should be measured. It is obviously that a slow program would increase absolute numbers and reduce the relative ones. Dynamic linking against glibc would make small programs significantly slower so I used the fastest possible 'r'. Ok, telling the 'resD.glibc.*' results at this place was wrong and related to other statements in this thread. So, please ignore them... > About your resident sizes results this doesn't take the shared part of > this into the picture. Please substract the shared part (minus the > stripped binary size) from these figures since the few basic glibc > functions used will be resident already in any realistic Fedora test > scenario. I am not sure whether this it what you want but /proc/*/status tells: Name: tcpsvd.ds tcpsvd.diet tcpsvd.glibc VmPeak: 156 kB 340 kB 1768 kB VmSize: 136 kB 320 kB 1636 kB VmLck: 0 kB 0 kB 0 kB VmHWM: 60 kB 176 kB 504 kB VmRSS: 44 kB 156 kB 504 kB VmData: 12 kB 36 kB 160 kB VmStk: 88 kB 84 kB 88 kB VmExe: 32 kB 36 kB 48 kB VmLib: 0 kB 152 kB 1304 kB VmPTE: 8 kB 12 kB 20 kB Enrico Footnotes: [1] http://www.fefe.de/fnord/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 482 bytes Desc: not available URL: From tibbs at math.uh.edu Fri Feb 24 18:22:42 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 24 Feb 2006 12:22:42 -0600 Subject: please help: %doc causing extra dependencies ? In-Reply-To: <20060224164033.GA9696@hedwig.net.cmu.edu> (Gabriel L. Somlo's message of "Fri, 24 Feb 2006 11:40:33 -0500") References: <20060224164033.GA9696@hedwig.net.cmu.edu> Message-ID: >>>>> "GLS" == Gabriel L Somlo writes: GLS> Trouble is, there are a couple of perl scripts in contrib, and my GLS> package suddenly ends up requiring perl. The scripts probably start with #!/usr/bin/perl, which RPM sees as a perl dependency. You probably just need to chmod -x the scripts in %prep. - J< From tibbs at math.uh.edu Fri Feb 24 18:24:20 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 24 Feb 2006 12:24:20 -0600 Subject: please help: %doc causing extra dependencies ? In-Reply-To: <20060224164033.GA9696@hedwig.net.cmu.edu> (Gabriel L. Somlo's message of "Fri, 24 Feb 2006 11:40:33 -0500") References: <20060224164033.GA9696@hedwig.net.cmu.edu> Message-ID: Sorry for not reading clearly. When are you turning off execute permission on the files? I don't think you can do it in the %files section with %attr. - J< From bugzilla at redhat.com Fri Feb 24 18:46:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 13:46:09 -0500 Subject: [Bug 177818] Review Request: adplug In-Reply-To: Message-ID: <200602241846.k1OIk9Ve007861@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: adplug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177818 ------- Additional Comments From bugs.michael at gmx.net 2006-02-24 13:46 EST ------- It's a matter of design. As /usr/share may be read-only, nobody could create or modify the database file. Only the superuser of the master server could. If the goal is to make it possible to distribute a shared database file master copy to multiple machines in a network, /usr/share would be right. Which solution to choose depends on where the global database file comes from and how it is accessed at run-time. If it will turn out to be something which is downloaded or updated at run-time, /usr/share won't work on the individual machines. If it is something which can be wrapped up in the RPM package as a default database, too, /usr/share would work. Particularly, since users can override the db contents from within their home dir. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 24 18:53:51 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 13:53:51 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602241853.k1OIrpO2009605@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From bugs.michael at gmx.net 2006-02-24 13:53 EST ------- > USEROPT="-g haclient -u $[ $(cat /etc/fedora/usermgmt/baseuid) + 17 ] -d > /var/lib/heartbeat/cores/hacluster" > Correct? No. The baseuid is not for immediate use. Use /usr/sbin/fedora-useradd -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 24 19:27:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 14:27:01 -0500 Subject: [Bug 181824] Review Request: gstreamer08 In-Reply-To: Message-ID: <200602241927.k1OJR10x017846@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gstreamer08 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181824 ------- Additional Comments From bdpepple at ameritech.net 2006-02-24 14:26 EST ------- Hmmm, probably something messed up in it's configure script. Unfortunately, I'm going to be fairly busy the next couple of weeks, and probably won't have time to track down the problem. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 24 19:56:45 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 14:56:45 -0500 Subject: [Bug 182966] New: Review Request: argus-2.0.6.fixes.1-1.src.rpm Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182966 Summary: Review Request: argus-2.0.6.fixes.1-1.src.rpm Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: somlo at cmu.edu QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.contrib.andrew.cmu.edu/~somlo/argus.spec SRPM Name or Url: http://www.contrib.andrew.cmu.edu/~somlo/argus-2.0.6.fixes.1-1.src.rpm Description: Argus (Audit Record Generation and Utilization System) is an IP network transaction audit tool. The data generated by argus can be used for a wide range of tasks such as network operations, security and performance management. Second package -- still need a sponsor :) Also, see FIXME line in spec file: currently commenting out some %doc files because they pull in an unwanted dependency on perl -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From somlo at cmu.edu Fri Feb 24 20:11:14 2006 From: somlo at cmu.edu (Gabriel L. Somlo) Date: Fri, 24 Feb 2006 15:11:14 -0500 Subject: please help: %doc causing extra dependencies ? Message-ID: <20060224201114.GB9696@hedwig.net.cmu.edu> Thanks for replying. I'm turning off execute permissions as part of %install. BTW, I've submitted the package (with the offending %doc entries commented out) for review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182966 Gabriel From bugzilla at redhat.com Fri Feb 24 20:07:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 15:07:48 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602242007.k1OK7mBB027821@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From fedora at soeterbroek.com 2006-02-24 15:07 EST ------- Spec Name or Url: http://www.soeterbroek.com/linux/fedora/extras/heartbeat/heartbeat.spec SRPM Name or Url: http://www.soeterbroek.com/linux/fedora/extras/heartbeat/heartbeat-2.0.3-5.src.rpm * Fri Feb 24 2006 Joost Soeterbroek - 2.0.3-5 - added heartbeat to fedoraproject.org/wiki/Packaging/UserRegistry with uid 24 - group/useradd with fedora-usermgmt - added *.so file to -devel sub-package -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From fedora at camperquake.de Fri Feb 24 20:17:55 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 24 Feb 2006 21:17:55 +0100 Subject: please help: %doc causing extra dependencies ? In-Reply-To: <20060224164033.GA9696@hedwig.net.cmu.edu> References: <20060224164033.GA9696@hedwig.net.cmu.edu> Message-ID: <20060224211755.5daafb6a@nausicaa.camperquake.de> Hi. "Gabriel L. Somlo" wrote: > How can I still add these things as *documentation*, without them > causing my package to require PERL ? I've already tried removing > the executable attribute on the files, but the package still ends up > requiring perl... I remember that half a year ago or so the ppp package in Core ended up requiring /usr/local/bin/perl because of a file in %doc. I do not remember if there was a general solution to this or just a change of the hashbang path in the file. -- Duct tape is like "The Force": it has a light side and a dark side, and it holds the universe together. From tibbs at math.uh.edu Fri Feb 24 20:32:47 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 24 Feb 2006 14:32:47 -0600 Subject: please help: %doc causing extra dependencies ? In-Reply-To: <20060224201114.GB9696@hedwig.net.cmu.edu> (Gabriel L. Somlo's message of "Fri, 24 Feb 2006 15:11:14 -0500") References: <20060224201114.GB9696@hedwig.net.cmu.edu> Message-ID: Interesting; there's a whole Perl module in there that you're including as %doc and the dependency generator is finding every perl-related requirement (and some provides as well). My suggestion would be to just spit out the module as a separate package. - J< From bugzilla at redhat.com Fri Feb 24 20:51:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 15:51:07 -0500 Subject: [Bug 181534] Review Request: kst - plots scientific data In-Reply-To: Message-ID: <200602242051.k1OKp7OF007016@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kst - plots scientific data https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181534 orion at cora.nwra.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From orion at cora.nwra.com 2006-02-24 15:51 EST ------- Looks good. APPROVED. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 24 21:19:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 16:19:21 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602242119.k1OLJLRb013084@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From bugs.michael at gmx.net 2006-02-24 16:19 EST ------- > %postun -p /sbin/ldconfig > test "$1" != 0 || /usr/sbin/fedora-userdel hacluster &>/dev/null || : > test "$1" != 0 || /usr/sbin/fedora-groupdel haclient &>/dev/null || : This is broken. What "-p /sbin/ldconfig" does is making /sbin/ldconfig the interpreter for the following lines up to the beginning of the next section in the .spec file. Here you try to execute the two lines of shell code with /sbin/ldconfig instead of the default /bin/sh used for RPM scriptlets. Try "rpm --erase heartbeat" which gives fatal errors. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 24 21:39:29 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 16:39:29 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602242139.k1OLdTsd018523@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From orion at cora.nwra.com 2006-02-24 16:39 EST ------- Need: Requires(post): /sbin/chkconfig Requires(preun): /sbin/chkconfig Change: %{_libdir}/pils/plugins to %{_libdir}/pils/ so that it owns the directory and everything below. You might want the devel files section to look like: %{_includedir}/heartbeat/ %{_includedir}/clplumbing/ %{_includedir}/saf/ %{_includedir}/ocf/ %{_includedir}/stonith/ %{_includedir}/pils/ To be clear that they are directories. Similar with %{_libdir}/stonith/ - Your *.so are duplicated in heartbeat and heartbeat-devel. Change file lines in heartbeat to: %{_libdir}/libapphb.so.* - Various programs are checked for a config time and not found: checking for lynx... no checking for ssh... no checking for scp... no checking for mail... no checking for raidstart... no checking for raidstop... no checking for mdadm... no checking for iptables... no checking for md5... no checking for drbdadm... no checking for drbdsetup... no I have no idea if this affects functionality or not... - Is this important? checking for owcimomd... no configure: WARNING: Cimom not found, MOF will not be installed! - Looks like the user ID might get hardcoded? HA user user id = "17" - Do you want to add snmp support? Probably just needs BuildRequires: net-snmp-devel. Build snmp subagent = "no" SNMP libraries = "" Probably also need an enable flag and another subpackage. - I think you need a BR: libtool-ltdl-devel , perhaps instead of BR: libtool (as it seems to use $(top_builddir)/libtool in either case), to get: Use system LTDL = "yes" -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 24 21:47:43 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 16:47:43 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602242147.k1OLlhDQ020355@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From orion at cora.nwra.com 2006-02-24 16:47 EST ------- rpmlint -i heartbeat (edited) W: heartbeat non-conffile-in-etc /etc/ha.d/README.config A non-executable file in your package is being installed in /etc, but is not a configuration file. All non-executable files in /etc should be configuration files. Mark the file as %config in the spec file. W: heartbeat dangling-symlink /etc/ha.d/resource.d/ldirectord /usr/sbin/ldirectord The symbolic link points nowhere. ^ I think this might be duplicate ownership: # rpm -qf /etc/ha.d/resource.d/ldirectord heartbeat-2.0.3-5.fc5 heartbeat-ldirectord-2.0.3-5.fc5 perhaps only in heartbeat-ldirectord W: heartbeat non-conffile-in-etc /etc/ha.d/shellfuncs A non-executable file in your package is being installed in /etc, but is not a configuration file. All non-executable files in /etc should be configuration files. Mark the file as %config in the spec file. W: heartbeat non-conffile-in-etc /etc/pam.d/hbmgmtd A non-executable file in your package is being installed in /etc, but is not a configuration file. All non-executable files in /etc should be configuration files. Mark the file as %config in the spec file. W: heartbeat service-default-enabled /etc/init.d/heartbeat The service is enabled by default after "chkconfig --add"; for security reasons, most services should not be. Use "-" as the default runlevel in the init script's chkconfig line to fix this if appropriate for this service. E: heartbeat subsys-not-used /etc/init.d/heartbeat While your daemon is running, you have to put a lock file in /var/lock/subsys/. To see an example, look at this directory on your machine and examine the corresponding init scripts. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 24 21:55:43 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 16:55:43 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602242155.k1OLthK6022207@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From orion at cora.nwra.com 2006-02-24 16:55 EST ------- # rpmlint -i heartbeat-devel W: heartbeat-devel no-dependency-on heartbeat Should have a Requires: heartbeat = %{version}-%{release} in the devel package section. # rpmlint -i heartbeat-ldirectord W: heartbeat-ldirectord devel-file-in-non-devel-package /usr/sbin/supervise-ldirectord-config A development file (usually source code) is located in a non-devel package. If you want to include source code in your package, be sure to create a development package. E: heartbeat-ldirectord incoherent-logrotate-file /etc/logrotate.d/ldirectord Your logrotate file should be named /etc/logrotate.d/. W: heartbeat-ldirectord non-conffile-in-etc /etc/logrotate.d/ldirectord A non-executable file in your package is being installed in /etc, but is not a configuration file. All non-executable files in /etc should be configuration files. Mark the file as %config in the spec file. E: heartbeat-ldirectord init-script-without-chkconfig-postin /etc/init.d/ldirectord The package contains an init script but doesn't contain a %post with a call to chkconfig. E: heartbeat-ldirectord init-script-without-chkconfig-preun /etc/init.d/ldirectord The package contains an init script but doesn't contain a %preun with a call to chkconfig. W: heartbeat-ldirectord service-default-enabled /etc/init.d/ldirectord The service is enabled by default after "chkconfig --add"; for security reasons, most services should not be. Use "-" as the default runlevel in the init script's chkconfig line to fix this if appropriate for this service. E: heartbeat-ldirectord subsys-not-used /etc/init.d/ldirectord While your daemon is running, you have to put a lock file in /var/lock/subsys/. To see an example, look at this directory on your machine and examine the corresponding init scripts. W: heartbeat-ldirectord incoherent-init-script-name ldirectord The init script name should be the same as the package name in lower case. # rpmlint -i heartbeat-stonith E: heartbeat-stonith library-without-ldconfig-postin /usr/lib/libapphb.so.0.0.0 This package contains a library and provides no %post scriptlet containing a call to ldconfig. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From orion at cora.nwra.com Fri Feb 24 22:14:45 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 24 Feb 2006 15:14:45 -0700 Subject: Help with python-matplotlib packaging Message-ID: <43FF8555.6070301@cora.nwra.com> I'm the maintainer for python-matplotlib. I'm getting ready to build 0.87 and am looking for suggestions about what numeric engine to make standard. I'm building against numpy, Numeric, and numarry, but I don't want to have it Require: all three at run time. Is numpy the way of the future and should I just list that? Currently (0.86) I have python-numeric. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From bugzilla at redhat.com Fri Feb 24 22:22:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 17:22:01 -0500 Subject: [Bug 180743] Review Request: pdsh In-Reply-To: Message-ID: <200602242222.k1OMM1m4028324@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: pdsh https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180743 ------- Additional Comments From woodard at redhat.com 2006-02-24 17:21 EST ------- OK http://osdn.dl.sourceforge.net/sourceforge/pdsh/pdsh-2.8.1-5.src.rpm http://osdn.dl.sourceforge.net/sourceforge/pdsh/pdsh.spec Not built as root. No problems when I didn't once I fixed perms on some dirs on my system. Upstream is my friend and cycling buddy so I wasn't too worried about security. upgraded rpmlint. It got rid of some bogus errors. Other items tweaked as requested. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From j.w.r.degoede at hhs.nl Fri Feb 24 23:45:08 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 25 Feb 2006 00:45:08 +0100 Subject: PPC (game) testing help needed Message-ID: <43FF9A84.3010500@hhs.nl> Hi, I've been working on the Linux port of a cool opensource dos game, Worminator (3) . The port is complete and I'm planning on packaging this for fedora soon (right after creating a webpage for it). The problem is that the dos version used a couple of binary formats which are just c-structs dumped to disk, since I wanted to keep compatibility with this because I did not want to have to recreate all the data / contents stored in this format I've kept these files as is. I've written code which reads this structures one byte at a time and then does the right thing with them this works on i386 and x86_64 and should work on PPC too since this should be endian independent. So now I wonder if someone could give this a try on PPC, I'm especially interested in playing the included demo files and in saving / restoring games and recording demos of you're self and playing these back. Source is at: http://home.zonnet.nl/jwrdegoede/worminator/worminator-3.0R2.1.tar.gz The data is at: http://home.zonnet.nl/jwrdegoede/worminator/worminator-data-3.0R2.1.tar.gz-split00 http://home.zonnet.nl/jwrdegoede/worminator/worminator-data-3.0R2.1.tar.gz-split01 Sorry I had to split the file because of size restrictions of my sucky isp. Just concat them together: cat worminator-data-3.0R2.1.tar.gz-split00 \ worminator-data-3.0R2.1.tar.gz-split01 \ > worminator-data-3.0R2.1.tar.gz And you get a regular tar.gz file again. Instructions for compiling and install are in ReadMe.txt Thanks for testing & Regards, Hans From bugzilla at redhat.com Fri Feb 24 23:44:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 18:44:27 -0500 Subject: [Bug 182415] Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project In-Reply-To: Message-ID: <200602242344.k1ONiRts013977@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182415 ------- Additional Comments From paul at all-the-johnsons.co.uk 2006-02-24 18:44 EST ------- Just a couple of quick comments 1. Why the need to change the name to remove the -utf8? I can't recall seeing anything in the FE rules over that 2. {buildroot} should really be ${RPM_BUILD_ROOT} 3. INSTALLPATH - should that not be DESTDIR? 4. Do you need to include the epoch? It can be more of a pain than anything (well, from what I've seen of it). Other than that, it looks okay. I'm not happy with the naming scheme - Release: 0.1%{?date:.%{date}wiki}%{?dist} seems somewhat long (to me). Can you not just have Release:0.1%{?dist}. I would normally reserve the longer release if the source was dragged from cvs/svn -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Fri Feb 24 23:49:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 24 Feb 2006 18:49:59 -0500 Subject: [Bug 182415] Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project In-Reply-To: Message-ID: <200602242349.k1ONnxkv015019@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182415 ------- Additional Comments From wart at kobold.org 2006-02-24 18:49 EST ------- > 2. {buildroot} should really be ${RPM_BUILD_ROOT} According to the packaging guidelines, either is fine as long as it is used consistently throughout the spec file (which appears to be the case here). The use of %{buildroot} is fine here. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From jamatos at fc.up.pt Fri Feb 24 23:57:48 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Fri, 24 Feb 2006 23:57:48 +0000 Subject: Help with python-matplotlib packaging In-Reply-To: <43FF8555.6070301@cora.nwra.com> References: <43FF8555.6070301@cora.nwra.com> Message-ID: <200602242357.48936.jamatos@fc.up.pt> On Friday 24 February 2006 22:14, Orion Poplawski wrote: > I'm the maintainer for python-matplotlib. I'm getting ready to build > 0.87 and am looking for suggestions about what numeric engine to make > standard. I'm building against numpy, Numeric, and numarry, but I don't > want to have it Require: all three at run time. Is numpy the way of the > future and should I just list that? Currently (0.86) I have > python-numeric. numpy it is certainly the future, what I am not sure is if it is the present. ;-) John Hunter showed interest in maintaining only numpy instead of the general support for Numerix. The question is if numpy is ready to replace the other toolkits. We could play cautiously an only replace it at 1.0 Why don't you put your question in the matplotlib list? It is a friendly environment. :-) > -- > Orion Poplawski > System Administrator 303-415-9701 x222 > Colorado Research Associates/NWRA FAX: 303-415-9702 > 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com -- Jos? Ab?lio From bugzilla at redhat.com Sat Feb 25 05:35:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 00:35:59 -0500 Subject: [Bug 182463] Review Request: cairomm (C++ bindings for cairo) In-Reply-To: Message-ID: <200602250535.k1P5ZxXi009005@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cairomm (C++ bindings for cairo) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182463 ------- Additional Comments From rvinyard at cs.nmsu.edu 2006-02-25 00:35 EST ------- My mistake on the cairomm tarballs. I didn't realize they were there. The URL is now corrected, and I think everything is ready to go. Spec Name or Url: http://miskatonic.cs.nmsu.edu/pub/cairomm.spec SRPM Name or Url: http://miskatonic.cs.nmsu.edu/pub/fedora/4/srpms/cairomm-0.5.0-6.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 05:59:00 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 00:59:00 -0500 Subject: [Bug 182463] Review Request: cairomm (C++ bindings for cairo) In-Reply-To: Message-ID: <200602250559.k1P5x0gn012369@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cairomm (C++ bindings for cairo) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182463 ------- Additional Comments From rc040203 at freenet.de 2006-02-25 00:58 EST ------- NEEDSWORK Not a review, just a some remarks on the spec file: 1) It contains this: URL: http://www.cairographics.org/releases//cairomm-0.5.0.tar.gz Source: cairomm-0.5.0.tar.gz "Source:" should contain an URL pointing to the tarball, "URL" should point to the projects homepage. I.e. you probably want something similar to this: URL: http://www.cairographics.org Source: http://www.cairographics.org/releases/cairomm-0.5.0.tar.gz 2) The spec contains this: %files devel ... %{_includedir}/cairomm-1.0/* The last line should be %{_includedir}/cairomm-1.0 (without the asterisk - The directory and all files underneath should be included into the *-devel package) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From buildsys at fedoraproject.org Sat Feb 25 06:05:33 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 25 Feb 2006 01:05:33 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060225060533.022CB8011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 4 dap-hdf4_handler-3.5.0-1.fc3 hdf-4.2r1-6.fc3.2 munin-1.2.4-7.fc3 perl-Crypt-CBC-2.17-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat Feb 25 06:05:44 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 25 Feb 2006 01:05:44 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060225060544.7773C8011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 9 dap-hdf4_handler-3.5.0-1.fc4 digikamimageplugins-0.8.1-1.fc4 gdl-0.8.11-2.fc4 hdf-4.2r1-6.fc4 kmymoney2-0.8.3-1.fc4 munin-1.2.4-7.fc4 perl-Crypt-CBC-2.17-1.fc4 smb4k-0.6.8-1.fc4 translate-toolkit-0.8-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat Feb 25 06:05:54 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 25 Feb 2006 01:05:54 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060225060554.61EE88011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 15 athcool-0.3.11-4.fc5 gdl-0.8.11-4.fc5 munin-1.2.4-7.fc5 perl-Cflow-1.053-4.fc5 perl-Crypt-CBC-2.17-1.fc5 perl-DBD-CSV-0.22-3.fc5 perl-HTTP-Server-Simple-0.18-2.fc5 perl-Regexp-Common-2.120-4.fc5 perl-Test-Exception-0.21-2.fc5 perl-Test-Warn-0.08-3.fc5 plplot-5.5.3-12.fc5 python-kid-0.8-1.fc5 smb4k-0.6.8-1.fc5 xchat-gnome-0.10-1.fc5 xchat-gnome-0.10-2.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Sat Feb 25 07:12:38 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 02:12:38 -0500 Subject: [Bug 182463] Review Request: cairomm (C++ bindings for cairo) In-Reply-To: Message-ID: <200602250712.k1P7CcSp024026@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: cairomm (C++ bindings for cairo) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182463 ------- Additional Comments From rvinyard at cs.nmsu.edu 2006-02-25 02:12 EST ------- I think we're there... Spec Name or Url: http://miskatonic.cs.nmsu.edu/pub/cairomm.spec SRPM Name or Url: http://miskatonic.cs.nmsu.edu/pub/fedora/4/srpms/cairomm-0.5.0-7.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 08:59:55 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 03:59:55 -0500 Subject: [Bug 175438] Review Request: smart -- Next generation package handling tool In-Reply-To: Message-ID: <200602250859.k1P8xtNQ013132@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: smart -- Next generation package handling tool https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175438 ------- Additional Comments From ville.skytta at iki.fi 2006-02-25 03:59 EST ------- smart-update requires sudo >= 1.6.8 due to use of "sudo -i". Can't the -i be just dropped? That would make things work with RHEL4. ksmarttray invokes "smart --gui" for installing the available updates; even though that would bring in the gtk dependencies to kde systems, I think a dependency on smart-gui should be added, perhaps using Requires(missingok). (In reply to comment #69) > 1. smart > 2. gtk2 > installation sequence (which would be possible without the Requires(post)). Please demonstrate how that sequence would be possible without it. I'm assuming you mean smart-gui-gtk, not smart in the sequence though. See also https://www.redhat.com/archives/fedora-extras-list/2006-February/msg00322.html -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From frank at scirocco-5v-turbo.de Sat Feb 25 09:40:26 2006 From: frank at scirocco-5v-turbo.de (Frank Arnold) Date: Sat, 25 Feb 2006 10:40:26 +0100 Subject: PPC (game) testing help needed In-Reply-To: <43FF9A84.3010500@hhs.nl> References: <43FF9A84.3010500@hhs.nl> Message-ID: <1140860426.25906.18.camel@localhost> Am Samstag, den 25.02.2006, 00:45 +0100 schrieb Hans de Goede: > So now I wonder if someone could give this a try on PPC, I'm especially > interested in playing the included demo files and in saving / restoring > games and recording demos of you're self and playing these back. Allegro segfaults: #0 blit (src=0x0, dest=0x10b6e6a0, s_x=-172, s_y=-32, d_x=0, d_y=0, w=344, h=64) at ./src/blit.c:706 #1 0x0feb11d8 in popup_dialog (dialog=0xff9033c, focus_obj=4) at ./src/gui.c:844 #2 0x0feb1650 in alert3 (s1=Variable "s1" is not available. ) at ./src/gui.c:2394 #3 0x0feb17f8 in alert (s1=Variable "s1" is not available. ) at ./src/gui.c:2416 #4 0x10040e4c in reset_sound () #5 0x10040e4c in reset_sound () #6 0x10040e4c in reset_sound () #7 0x10040e4c in reset_sound () #8 0x10040e4c in reset_sound () #9 0x10040e4c in reset_sound () Previous frame inner to this frame (corrupt stack?) And another one, running through ssh from another machine. Doesn't make sense, but should not crash: #0 0x0febc5c8 in install_keyboard () at ./src/keyboard.c:658 #1 0x1004f0f8 in initialize () #2 0x10055cb4 in main () Powerbook G4 1,67GHz, allegro from extras. Regards, Frank From sdl.web at gmail.com Sat Feb 25 10:50:13 2006 From: sdl.web at gmail.com (leon) Date: Sat, 25 Feb 2006 10:50:13 +0000 Subject: maxima bug? Message-ID: Hi all, Can anyone confirm this bug? Thank you. Maxima failed with: ----BEGIN HERE---------------------------------------------------------- fatal error encountered in SBCL pid 14139(tid 3086939824): can't load .core for different runtime, sorry The system is too badly corrupted or confused to continue at the Lisp level. If the system had been compiled with the SB-LDB feature, we'd drop into the LDB low-level debugger now. But there's no LDB in this build, so we can't really do anything but just exit, sorry. ----END HERE------------------------------------------------------------ -- Leon From bugzilla at redhat.com Sat Feb 25 12:00:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 07:00:33 -0500 Subject: [Bug 175438] Review Request: smart -- Next generation package handling tool In-Reply-To: Message-ID: <200602251200.k1PC0Xj1014080@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: smart -- Next generation package handling tool https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175438 ------- Additional Comments From enrico.scholz at informatik.tu-chemnitz.de 2006-02-25 07:00 EST ------- > smart-update requires sudo >= 1.6.8 due to use of "sudo -i". Can't > the -i be just dropped? That would make things work with RHEL4. Does this sudo support the '-H' flag? >> 1. smart >> 2. gtk2 >> installation sequence (which would be possible without the Requires(post)). > >Please demonstrate how that sequence would be possible without it. E.g. a new package like | Name: ncgl | Summary: A new, cool, libGL.so implementation | # We need smart to download the firmware, and users want a GUI | Requires: smart-gui-gtk will create a circular dep like xorg-x11-libs -> libGL.so -> smart-gui-gtk -> gtk2 ^ (ncgl wins) | `-------------------------------------------' It is not specified whether smart-gui-gtk or gtk2 will be installed first. Such an 'ncgl' package does not exist in Fedora Extras currently, but: * could be added in the future; I do not have the time to investigate all possible circular deps when a new package gets added * could be added by a third party repository. E.g. a well known one provides 'ati-fglrx' which wins against the default xorg-x11-Mesa-libGL That's why, I prefer to prevent such undetermined situations with tagged Requires(...). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 25 13:20:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 08:20:35 -0500 Subject: [Bug 175438] Review Request: smart -- Next generation package handling tool In-Reply-To: Message-ID: <200602251320.k1PDKZBu026487@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: smart -- Next generation package handling tool https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175438 ------- Additional Comments From ville.skytta at iki.fi 2006-02-25 08:20 EST ------- Yes, sudo 1.6.7p5 understands -H. The circular dep example is too far fetched for me to consider it relevant, and I guess it's just as easy to craft artificial situations where use of the Requires(post) would cause problems as it was to come up with that example. (No, I'm not willing to spend time trying to demonstrate one though.) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From fedora at leemhuis.info Sat Feb 25 14:55:59 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 25 Feb 2006 15:55:59 +0100 Subject: Summary from last FESCo meeting Message-ID: <1140879360.2314.14.camel@localhost.localdomain> == Summary == Present from FESCo: thl, jpo, warren, jeremy, scop, Sopwith Important topics: * Kernel module standardization * thl will try to convert GFS-packages from Core to the new kernel-module scheme * adding kmodtool to redhat-rpm-macros? scop: '...and I think it wouldn't hurt to actually ship some module packages and watch it a bit before including in something "official" like that' * status of yum wrt kmod-* packages? plugin in the works; no one knows the exact status * Mass rebuild of Extras for FC5 * noarch packages don't need to be rebuild * jpo mentions that if would be good for perl packages as it reduces the module loading time; warren replied later "I personally don't consider that a reason for mandatory rebuild, but the owners have the option of doing anything they want." * there were also some other perl problems (maybe ABI related, maybe not); see https://www.redhat.com/archives/fedora-perl-devel-list/2006-February/msg00037.html for details * EOL Policy for FE * Some discussions; we probably soon have a security SIG and will try to get them involved. No details yet. * Weekly sponsorship nomination * John Mahowald / jpmahowald is a sponsor now * separate extras-ml-list for bugzilla spam * We'll probably open fedora-extras-bugzilla-list and fedora-extras-review-list. All contributors should subscribe to -reviews. * Free discussion; Topics: Review days, better education and documentation to increase reviews, close old reviews-bugs where nothing is happening, scratch builds. Highlights below: {{{ 19:03 < thl> | nirik, any plans for another "review day" 19:04 < nirik> | I could try another one... was out of town last weekend and have been trying to catch up since then... ;) 19:04 < nirik> | perhaps not this coming weekend, but the one after, and I could start advertising soon. --- 19:51 < warren> | Regarding the review problem, I don't see any viable options here other than what I suggested last week. Focus on education and documentation, because nothing else is effective in the long term. --- 19:38 < nirik> | I have something to throw out for free discussion... should there be a time limit after which a new review request is closed for lack of interest? or should they just stay? 19:52 < warren> | I don't think we should close review requests or bugs just because they are old. 19:54 < BobJensen> | People I have talked to abotu submitting packages are frustrated by the reviw process 19:54 < thl> | nirik, if you don't get answers in old review bugs it's probably okay to close them 19:54 < warren> | He was being hand-holded through package reviews, he himself didn't know how to do anything, and he didn't learn any skills in the process. That is unsustainable, and it cannot be our responsibilty to get such people through the process. 19:54 < BobJensen> | Most say they never hear anything 19:55 < BobJensen> | I know nothing about packaging or the Extras Process at this time, but this is a community concern in general 19:55 < warren> | BobJensen, ultimately volunteers cannot be forced to do anything. volunteers will only review things that interest them. 19:58 < ignacio> | Better to have someone incapable get frustrated and leave then to let them in. 19:58 < warren> | ignacio, I agree with that. 19:59 < Sopwith> | ignacio: I could agree a lot more with that if Fedora Extras had a great setup for teaching people about packaging 19:59 < Sopwith> | ignacio: I could agree a lot more with that if Fedora Extras had a great setup for teaching people about packaging 19:59 < ignacio> | I'm working on it... --- 20:13 < jwb> | anything from RH on the "scratch builds"? 20:14 < jwb> | thl, i think dcbw outlined what is needed for plague pretty well. i'm talking about just "should we do it" 20:15 < thl> | "buildroot = core + extras + needsign + scratch" sound like the best solution afaics 20:15 < jwb> | +1 20:16 < jwb> | packages hang out for two days and are gone? 20:16 < thl> | jwb, +1 }}} == Full Log == {{{ 18:57 --> | jpo (Unknown) has joined #fedora-extras 19:00 * | thl looks at the watch 19:00 --- | thl has changed the topic to: FESCo Meeting in progress 19:00 < thl> | okay, who's around? 19:01 < nman64> | I am, but that's irrelevant. 19:01 * | Anvil is, unusualy. 19:02 < thl> | hmmm, that not much 19:02 * | nirik is much of the time too. 19:02 < thl> | well, let's start slowly 19:02 --- | thl has changed the topic to: FESCo Meeting in progress -- Free discussion 19:02 < thl> | is there anything you guys want to talk about before we start looking at the schedule? 19:03 < thl> | nirik, any plans for another "review day" 19:04 < nirik> | I could try another one... was out of town last weekend and have been trying to catch up since then... ;) 19:04 --- | Users 60 nicks 19:04 < nirik> | perhaps not this coming weekend, but the one after, and I could start advertising soon. 19:04 --> | scop (Ville Skytta) has joined #fedora-extras 19:04 < thl> | ping warren, jeremy , skvidal , ensc|w, Sopwith: "FESCo meeting!" 19:05 < warren> | I'm here, just waiting 19:05 < warren> | (and doing 3 other things) 19:05 < thl> | ahh, okay :) 19:05 < thl> | nirik, okay, sounds like a plan 19:06 < thl> | okay, then let's go trough the schedule 19:06 --- | thl has changed the topic to: FESCo Meeting in progress -- Kernel module standardization 19:06 < Sopwith> | oh 19:06 < thl> | Well, we poked dcbw and he answered 19:06 < thl> | but now we're stuck again afaics 19:07 < thl> | warren, or is dcbw working on it already? 19:08 < warren> | sorry... I don't know any new information about his 19:08 < warren> | this 19:08 < warren> | I suggested to jeremy that we should redo the GFS kernel modules in FC5 in order to lead by example, but no response. People are very busy. 19:08 < thl> | warren, I wanted to talk about GFS in core, too 19:08 < thl> | warren, shall I convert it? 19:09 < jeremy> | warren: cfeist had said he'd look at converting gfs, but hasn't 19:09 < jeremy> | if someone wants to take a pass at it, that wouldn't be a bad thing 19:09 < warren> | thl, that would be interesting and helpful, kick them 19:09 < warren> | jeremy, do you agree with "single package" for GFS modules? 19:09 < thl> | k, I'll try to find time for it 19:09 < jeremy> | warren: I'm not against the idea 19:10 < thl> | warren, just out of curiosity: "single package" ? 19:10 < thl> | all the modules in one packages? 19:10 < warren> | thl, currently GFS modules are multiple packages, which is rather stupid 19:10 < thl> | warren, okay 19:10 < thl> | yeah, sounds like a good idea 19:10 < warren> | anyhow, I think this would be useful to lead by example in this way. 19:10 < thl> | yeah 19:11 < thl> | and we need to get kmodtool into redhat-rpm-macros 19:11 < thl> | that was the plan iirc? 19:12 < thl> | Think it was 19:12 < thl> | moving on 19:12 < warren> | Hmm.. I need to get my ass involved 19:12 --- | thl has changed the topic to: FESCo Meeting in progress -- Mass rebuild of Extras for FC5 19:12 < warren> | thl, let us talk afterward about stuff 19:12 < thl> | warren, okay 19:12 < thl> | well, rebuilding SRPMS is still undecided 19:13 < warren> | What specifically about it? 19:13 < warren> | or do you mean noarch? 19:13 < thl> | stupid me 19:13 < thl> | I meant rebuilding noarch rpms 19:13 < warren> | I personally think it isn't necessary 19:13 < warren> | and we have bigger problems to worry about 19:14 < thl> | jpo, what's the status regarding perl? 19:14 < thl> | jpo, you rebuild a lot of perl packages 19:14 < jpo> | For perl it would be good as it reduces the module loading time 19:14 < thl> | jpo, should they all be rebuild? 19:14 < warren> | jpo, last week there was concern about perl-5.8.8 breaking ABI or something, any more details found? 19:14 <-- | puzzled has quit ("Leaving") 19:15 < jpo> | Warren: sent a email for the fedora-perl-list a few hours ago 19:15 < jpo> | regarding the problem with perl-Sub-Uplevel 19:16 < scop> | that doesn't look like anything ABI related though 19:16 < warren> | any responses from upstream? 19:17 < jpo> | Not yet. There at least two tickets in CPAN RT. 19:17 < thl> | so, what do we do? 19:18 < scop> | jpo, regarding module loading time, you mean perl not having to search that much @INC? 19:18 < thl> | ignoring the problem for another week? 19:18 < jpo> | scop: yes. 19:18 < warren> | were compat dirs removed in 5.8.8? 19:18 < scop> | no 19:19 < jpo> | thl: No. I already have a patch but I would like a second opinion 19:19 < scop> | why should they be removed? 19:19 < jpo> | before commiting it 19:20 < warren> | Just wondering how the @INC list became smaller 19:20 < scop> | did it? 19:20 < jpo> | I am also planning in sending an email to the perl5-porters mailing list if I don't hear from the module author 19:20 < warren> | How is the attitude on the lits? Probably best to ask for clarification sooner than later? 19:20 < jpo> | warren: not smaller. The perl 5.8.8 dir is searched before the 5.8.7 ones and so on 19:21 < warren> | ahh 19:21 < scop> | It's actually larger in FC5 than FC4, as expected 19:22 < jpo> | Yes: 5.8.8 and 5.8.7 19:22 --> | ensc (Enrico Scholz) has joined #fedora-extras 19:23 < warren> | I personally don't consider that a reason for mandatory rebuild, but the owners have the option of doing anything they want. 19:23 < warren> | We have bigger problems elsewhere... (kmod) 19:24 < thl> | okay, then let's ignore the noarch packages in the rebuild 19:24 < thl> | anything else on this topic? 19:24 --- | thl has changed the topic to: FESCo Meeting in progress -- EOL Policy for FE 19:24 < thl> | still on the list 19:25 < thl> | we'll probably soon have a security SIG 19:25 < thl> | maybe that can be involved in this discussion 19:25 < thl> | so let's wait for that first 19:25 < thl> | oaky? 19:25 < warren> | what does SIG mean? 19:25 < thl> | Special Interest Group iirc 19:25 < warren> | good that it isn't called Legacy 19:26 < warren> | How do people here feel about my idea... that this 'team' by any name should focus on tracking the problem rather than doing? (they can optionally do) 19:26 < thl> | well, the plan is that is also watches FE-current and FE-devel 19:27 < warren> | 1) security SIG tracks security issues and makes sure there are open bugs for each, tracked in some sort. 19:27 < warren> | 2) existing maintainers can fix stuff, and probably will in many cases 19:27 < warren> | 3) we can then easily see where we have gaps, and people can query easily for stuff to work on 19:27 < thl> | warren, the current private discussion lead in a different direction 19:27 < thl> | more a 19:27 < warren> | My thought is, we can work on merging this methodology with Core and Legacy eventually. 19:28 < Sopwith> | It's a nice suggestion, but I think at this point the problem really requires a motivated leader, rather than more planning. 19:28 < thl> | team a from Securiy SiG tracks issues 19:28 < thl> | team b from Security SIG fixes things if maintainers vanished or don#t do anything 19:29 < warren> | Sopwith, right, it is a problem of leadership really 19:29 < warren> | thl, I don't think team b needs to be defined officially. the important thing is 'team a' providing the plainly easy to see data of what work needs to be done. 19:29 < Sopwith> | If there's someone here who wants to (and has the time & commitment to) focus on security issues, that's cool. Otherwise, it's probably something that should go on the HelpWanted page. 19:30 < warren> | thl, Red Hat operates in this way, our security team identifies issues and puts them in the database, and maintainers deal with it. 19:30 < thl> | Sopwith, there are people who are working on it 19:30 < warren> | thl, sometimes security people help 19:30 < thl> | warren, yeah, you have a point 19:30 < thl> | warren, I'll forward you opinion to the private discussions 19:30 <-- | Foolish has quit (Read error: 110 (Connection timed out)) 19:31 < thl> | let's wait what the guys think about it 19:31 < thl> | warren, that okay for now? 19:31 < warren> | can I join the private discussion? 19:31 < warren> | I happen to know a lot about how similar models work 19:31 < warren> | plus the volunteer motivation 19:31 < warren> | which is unique in our situation 19:31 < thl> | well, I'm only watching the discussions 19:31 < thl> | mostly 19:31 < thl> | But I'll forward your request 19:31 < warren> | ok, I'll see where this goes. 19:31 < thl> | k 19:32 < thl> | moving on 19:32 < scop> | my experience in the past is that most maintainers deal with security issues pretty quickly, and others completely ignore 19:32 < warren> | I just want to warn against the idea of forming defined groups and expectations 19:32 < thl> | scop, exactly... 19:32 < warren> | groups of volunteers too often become about the people and their egos rather than results. 19:32 < warren> | scop, right, that is why tracking is the most important part. 19:33 < thl> | okay, let's move on 19:34 --- | thl has changed the topic to: FESCo Meeting in progress -- Broken deps report 19:34 < thl> | mschwendt not there, skipping 19:34 --- | thl has changed the topic to: FESCo Meeting in progress -- Weekly sponsorship nomination 19:35 < thl> | John Mahowald / jpmahowald ? 19:35 < thl> | we didn't get to a real and last week 19:35 < thl> | scop, warren ? 19:35 < scop> | oh, my +1 is still in effect 19:35 < warren> | I'm not against it, no strong feeling here. 19:36 < thl> | that lets do it; 19:36 < warren> | ok 19:36 < thl> | Can anybody ask him if he wants to be a sponsor? 19:36 < scop> | I'll take care of it 19:36 < warren> | scop, thanks 19:36 < thl> | scop, k, thx 19:37 < thl> | scop, if it's okay for him drop be a mail and I'll upgrade him 19:37 < scop> | thl, ack 19:37 --- | thl has changed the topic to: FESCo Meeting in progress -- Free discussion 19:37 < thl> | scop, something else: 19:37 < thl> | scop, can you also take care of adding kmodtool to redhat-rpm-macros? 19:38 < nirik> | I have something to throw out for free discussion... should there be a time limit after which a new review request is closed for lack of interest? or should they just stay? 19:38 < scop> | well, I obviously don't have that kind of access... 19:38 < thl> | scop, sure; but a patch would probably be helpfull for warren and jeremy 19:38 < scop> | ...and I think it wouldn't hurt to actually ship some module packages and watch it a bit before including in something "official" like that 19:39 < Sopwith> | nirik: The real problem is that not enough package reviews are getting done. 19:39 < Sopwith> | nirik: That's what I wanted to bring up :) 19:39 < scop> | kmodtool is the smallest of our kmod problems :) 19:39 < thl> | scop, okay 19:39 < scop> | ...but sure, I can put together a patch 19:39 < nirik> | yeah, many of the pending ones are pretty old... how do we interest people in reviewing them? they are often things that are not of general interest too... 19:40 < thl> | jeremy, what about the xen problematic regarding package/kenrel names? 19:40 < thl> | jeremy, should we file a bug? 19:40 < warren> | Red Hat engineering needs to make a good faith effort of ratifying the standard. This involves 1) leading by example in GFS 2) helping the implemetation of buildsys hooks 3) ??? 19:40 < Sopwith> | buildsys hooks meaning what? 19:41 < thl> | Sopwith, passing options like "--define kvariants foo bar" to rpmbuild 19:41 < warren> | thl, is the buildsys stuff as simple as looping through archs, or we have variants too? 19:41 < thl> | warren, archs and variants 19:41 < thl> | warren, and maybe kernel-versions if they differ between archs 19:41 < warren> | thl, hmm I don't think GFS has direct support for this in core (beehive) currently. 19:42 < Sopwith> | thl: My guess is that's unlikely. The .spec file needs to have this coded in so that builds are reproducible. 19:42 < thl> | warren, the kversions and variants can be hardcoded in the spec 19:42 < thl> | warren, but it should be done in the buildsys 19:42 < Sopwith> | We can possibly come up with some preinstalled macros to make this easier (e.g. in redhat-rpm-config) 19:42 < thl> | Sopwith, well, we discussed this in the past with jeremy 19:42 < thl> | Sopwith, the result was a "okay, I can live with it" 19:43 < warren> | Sopwith, I understand your feelings about this, but it was really our responsibilty to take seriously the kmod discussions earlier 19:43 < scop> | what's the status of yum wrt kmod-* packages? 19:43 < warren> | fortunately hard coding is possible 19:43 < thl> | scop, don't know 19:43 < warren> | scop, probably best handled as a plugin, we make sure it works, and include it in yum by default when it is ready. there is another plugin that handles groupinstall conditionals that is going in soon. 19:44 < scop> | warren, ok 19:44 < Sopwith> | thl: I guess for the context of this discussion, my main point would be "Don't assume any specific features in the build system, such as passing macros on the cmdline" 19:44 < thl> | warren, a plugin is in the works, but I don't know the status 19:44 < thl> | Sopwith, okay, noted; hardcoding is possible, so it should work in beehive, too 19:45 < thl> | warren, search yum-devel for details 19:45 < warren> | k 19:45 < thl> | I suppose we'll have to deal with the yum problems during FE5 19:45 < thl> | there will be some rough edges in the beginning 19:45 < thl> | but in genereal it should work afaics 19:46 < scop> | so who's got the ball now? do we want this in gfs and friends first? 19:46 < thl> | scop, I can try to convert GFS over 19:46 < scop> | okay 19:46 < thl> | scop, but if you want to do it feel free 19:47 < scop> | no thanks :) 19:47 < thl> | ;-) 19:47 < scop> | but I _could_ hardcode everything into lirc and thinkpad kmod and just request builds... 19:47 < warren> | GFS needs to lead by example, and I don't think cfeist has the rpm skills to do it. 19:47 < warren> | also lacks motivation 19:47 < thl> | jeremy, we really need to solve the xen naming issues regarding the kernel-packages/the kernel names! 19:48 * | thl hopes jeremy shows up again 19:48 < warren> | thl, is that a different issue than other variants? 19:48 < scop> | yes, there's a mismatch in uname and kernel-$foo 19:48 < scop> | (naming) 19:48 < warren> | thl, I think we need a separate small meeting between me, you, jeremy and anybody else to focus on this stuff. 19:48 < warren> | ah 19:49 < thl> | warren, not sure if a meeting helps 19:49 < thl> | warren, but yeah, why not 19:49 < warren> | at least to get some focused time from jeremy so he can make decisions 19:49 < warren> | I'll figure it out 19:49 < thl> | warren, k, thx 19:50 < thl> | getting back to what nirik suggested 19:50 < warren> | scop, any existing thread describing the xen mismatch? 19:50 < thl> | warren, was in a private mail 19:50 < scop> | I don't think there's a public one; thl did send some private mails last week(ish) 19:50 < thl> | jeremy wanted to talk to the xen guys about it 19:50 < thl> | warren, I can forward that mail to you 19:50 < warren> | thl, that would be useful 19:51 < warren> | I need context 19:51 < thl> | yeah, that's often usefull :) 19:51 < thl> | okay, now nirik again :) 19:51 < thl> | < nirik> | I have something to throw out for free discussion... should there be a time limit after which a new review request is closed for lack of 19:51 < thl> | interest? or should they just stay? 19:51 < thl> | interest? or should they just stay? 19:51 < thl> | interest? or should they just stay? 19:51 < warren> | Regarding the review problem, I don't see any viable options here other than what I suggested last week. Focus on education and documentation, because nothing else is effective in the long term. 19:51 < thl> | interest? or should they just stay? 19:52 < thl> | uhhps, sorry 19:52 < warren> | I don't think we should close review requests or bugs just because they are old. 19:52 < nirik> | warren: yeah... 19:52 < thl> | warren, agreed 19:52 < warren> | Rahul went through closing a bunch of bugs across the board this week and got many people angry. 19:53 < nirik> | I added comments to some of the older reviews and got some response, and some no answers... 19:53 < BobJensen> | Can I give some Feedback? 19:53 < Sopwith> | nirik: Thanks for taking the time to do that. 19:53 < warren> | In the review problem, there are cases like Finalzone where I don't know what to do... 19:53 < thl> | BobJensen, sure 19:54 < BobJensen> | People I have talked to abotu submitting packages are frustrated by the reviw process 19:54 < thl> | nirik, if you don#t get answers in old review bugs it's probably okay to close them 19:54 < warren> | He was being hand-holded through package reviews, he himself didn't know how to do anything, and he didn't learn any skills in the process. That is unsustainable, and it cannot be our responsibilty to get such people through the process. 19:54 < BobJensen> | Most say they never hear anything 19:54 < thl> | BobJensen, yeah, that's a problem 19:55 < BobJensen> | I know nothing about packaging or the Extras Process at this time, but this is a community concern in general 19:55 < thl> | BobJensen, but we need solutions 19:55 < warren> | BobJensen, ultimately volunteers cannot be forced to do anything. volunteers will only review things that interest them. 19:55 < jwb> | and at a pace that suits them 19:55 < BobJensen> | How can the community in general get involved? 19:55 < jwb> | anyone can do reviews 19:55 < jwb> | _anyone_) 19:55 < Sopwith> | That needs to be communicated 19:56 < jwb> | right 19:56 < warren> | If you cannot get even a single volunteer other than yourself to look at your package, then there is a big question about the level of interest in your software. 19:56 < warren> | it only takes 2 people to get a package into Fedora 19:56 < jwb> | warren, that's not true 19:56 < BobJensen> | Who can I contact to help with promoting that part of the process? 19:56 < warren> | 2 people, and a sponsor 19:56 < jwb> | yes 19:56 < Sopwith> | bobjensen: You can do it yourself if you like. Just write up a post to fedora-announce-list asking for volunteers to help with package reviews, and pointing out that /anyone/ can do a review. 19:57 < warren> | while I wanted to trust more, I got burned sponsoring Finalzone. 19:57 < warren> | I don't know how to think about this anymore. 19:57 < Sopwith> | What's with Finalzone? 19:57 < ignacio> | You really do have to take a hard line when sponsoring someone. 19:57 < jwb> | warren, but until submitters get cvsextras access there is burden on the sponsor to actually work with the package 19:57 < ignacio> | Mollycoddling just degrades the project as a whole. 19:57 < jwb> | ignacio, right 19:58 < warren> | Sopwith, a case where somebody lacked even basic skills in using Linux, submitted a RPM made by someone else that he downloaded from the internet, everyone else gave him dozens of sugestions to fix the package, he himself dind't learn anything. 19:58 < ignacio> | Better to have someone incapable get frustrated and leave then to let them in. 19:58 < warren> | We can't be hand holding 19:58 < BobJensen> | Sopwith: I will start with some added content ont he subjet on our Fedora Unity/Solved sites and see how we can work that in to an article for RHMag and mailing lists 19:58 < warren> | ignacio, I agree with that. 19:58 < Sopwith> | bobjensen: Cool stuff! 19:58 < Sopwith> | bobjensen: BTW, you get paid for RHMag articles, which is a nice bonus :) 19:59 < Sopwith> | ignacio: I could agree a lot more with that if Fedora Extras had a great setup for teaching people about packaging 19:59 < ignacio> | I'm working on it... 19:59 < Sopwith> | cool :) 20:00 < thl> | okay, something else: warren, what's the status of the separate extras-ml-list for bugzilla spam? 20:00 < warren> | I can create the lists, I only need decisions 20:00 < warren> | what do we actually want? 20:00 < jwb> | a -bug and a -review list 20:00 < thl> | fedora-extras-bugzilla-list and fedora-extras-review-list ? 20:00 < ignacio> | +1 20:01 < jwb> | are sponsors required to subscribe to both? 20:01 < warren> | no, anybody can subscribe 20:01 < warren> | nobody can post to those lists though 20:01 < jwb> | that wasn't my question 20:01 < warren> | absolutely nobody 20:01 < thl> | warren, okay for me 20:01 < ignacio> | All contributors should subscribe to -reviews. 20:01 < jwb> | people with cvsextras access are required to subscribe to -commits 20:01 < thl> | ignacio, +1 20:01 < jwb> | right 20:02 < jwb> | +1 20:02 < warren> | jwb, they are? 20:02 < jwb> | they were at one time, yes 20:02 < thl> | not anymore iirc 20:02 * | jwb goes to look 20:02 < warren> | that isn't bein enforced 20:02 < warren> | really no problem in allowing subscriptions 20:02 < warren> | open project 20:02 --> | JL0gik (JerzeyLogic) has joined #fedora-extras 20:03 < Sopwith> | warren: I think you're missing jwb's point. Requiring some people to subscribe doesn't exclude other people from subscribing. 20:03 < jwb> | right :) 20:03 < warren> | ah 20:03 < warren> | OK yes, some people are required to subscribe, everyone else has the option. 20:03 < jwb> | basically i'm just looking to make sure that these shiny new lists aren't just bit buckets because nobody is subscribed 20:04 < thl> | warren, maybe we should subscribe everyone from fedora-extras-list to fedora-extras-reviews-list? 20:04 < warren> | thl, initially yes 20:04 < thl> | warren, sure 20:04 < warren> | and anybody that is sponsored 20:04 < thl> | warren, sounds fine 20:05 < warren> | I'll take this ball 20:05 < warren> | creation of lists, announcements, etc. 20:05 < thl> | okay, does anyone don't like this whole concept? 20:05 < warren> | subscriptoins 20:05 < thl> | then speak now 20:05 < thl> | warren, thx 20:05 < Sopwith> | I think enforcement needs to be figured out. 20:05 < warren> | this makes it easier to find conversation on fedora-extras-list 20:05 <-- | nman64 has quit ("BRB") 20:05 < Sopwith> | Not a reason not to do it, just a detail to take care of. 20:05 * | jwb agrees with Sopwith 20:05 < warren> | reviews can be more easily filtered into their own folder 20:05 < warren> | We need to promote the canned queries page more, what is the URL? 20:06 < Sopwith> | Otherwise this is just as bad as a law saying you can't have a pet whale in your house on Tuesdays. 20:06 < warren> | Sopwith, but only in California 20:06 < Sopwith> | True dat. 20:06 < warren> | how about enforcement ideas, next meeting? 20:06 <-- | JL0gik has left #fedora-extras ( ) 20:07 < thl> | warren, +1 20:07 < warren> | I'll go ahead with these first steps 20:08 < warren> | Sopwith, can our bugzilla component auto-create script add to the hidden auto-CC field automatically? 20:08 < warren> | Sopwith, that will be necessary to add stuff like 1) perl team list to perl* 2) fedora-extras-bugs-list to auto-CC of all fedora extras components. 20:09 < Sopwith> | warren: Hmm, I think it's doable. 20:09 --> | nman64 (Patrick Barnes) has joined #fedora-extras 20:09 < Sopwith> | Need a way to store & retrieve that information in a generic way. 20:09 < Sopwith> | If you come up with the syntax you want used in owners.list, I can implement it. 20:10 < warren> | Sopwith, it need not be in owners.list at all, these are global things 20:10 < Sopwith> | They are not global to the multiple Fedora projects that use owners.list 20:10 < warren> | hmm 20:11 < warren> | Sopwith, should we have an Extras specific owners.list? 20:11 < Sopwith> | We already do. 20:11 < warren> | then it is global for that owners.list 20:11 < Sopwith> | Yup 20:11 < warren> | if perl*, then perl team list 20:11 < warren> | if *, then fedora-extras-bugs-list 20:11 < warren> | being careful not to blow away other auto-CC things we already have there 20:11 < warren> | (probably entered manually by me) 20:11 < Sopwith> | Sure. What I'd like you to do is come up with the desired syntax for lines in owners.list that will communicate this special info. 20:12 < Sopwith> | And make sure it will work for all the use cases you can imagine. 20:12 < warren> | no no, I'm saying it shouldn't be in owners.list at all 20:12 < warren> | this should be hidden from owners.list 20:12 < warren> | it is needless complication 20:12 < Sopwith> | Why hide it? 20:12 < thl> | warren, Sopwith can you work out the details later? 20:12 < warren> | because it is a blanket policy 20:12 < warren> | yes 20:12 < warren> | I'll talk with sopwith privately 20:12 < thl> | thx 20:12 < thl> | anything else left? 20:13 < warren> | I think we have enough to work on 20:13 < thl> | yeah 20:13 < jwb> | anything from RH on the "scratch builds"? 20:13 < jwb> | as in, can we do it? 20:13 < thl> | jwb, that depends on the new plague iirc 20:13 < warren> | good question.. 20:13 < jwb> | thl, yeah i know. i meant outside of the technical things 20:13 < warren> | oh, somewhat related buildsys question, anybody remember the URL to the needsign yum repo? 20:14 < thl> | warren, http://buildsys.fedoraproject.org/plague-results/ 20:14 < jwb> | thl, i think dcbw outlined what is needed for plague pretty well. i'm talking about just "should we do it" 20:14 < warren> | question 20:14 < thl> | jwb, good question 20:14 < warren> | should scratch populate the scratch buildroot with itself 20:15 < warren> | or only Extras + needsign is the buildroot? 20:15 < warren> | scratch buildroot = core + extras + needsign? 20:15 < warren> | scratch buildroot = core + extras + needsign + scratch? 20:15 < jwb> | warren, that was some of the dep solving things that dcbw was talking about 20:15 --> | Foolish (Sindre Pedersen Bjordal) has joined #fedora-extras 20:15 < warren> | It is a simple matter of creating another mock definition and plague target 20:15 < thl> | "buildroot = core + extras + needsign + scratch" sound like the best solution afaics 20:15 < jwb> | +1 20:16 < warren> | What policy governs scratch? 20:16 < jwb> | packages hang out for two days and are gone? 20:16 < thl> | jwb, +1 20:16 < warren> | If we use existing infrastructure, stuff needs to go in CVS before built in scratch 20:16 < warren> | but CVS conflicts with the contents of extras 20:16 < jwb> | yes 20:16 < thl> | warren, yes 20:16 < jwb> | conflicts? 20:17 < warren> | you aren't sure if packagename/FC-5 means Extras or scratch 20:17 < thl> | warren, people want to use it to test there builds before they are build for real 20:17 < warren> | hmm 20:17 < jwb> | which brings up a better question: should scratch only exist for devel? 20:17 * | jwb sorta see's warrens point 20:18 < warren> | Red Hat has a scratch target 20:18 < warren> | it doesn't build from CVS 20:18 < warren> | and requires manual pruning 20:18 < warren> | it also doesn't populate a buildroot, which is both good and bad in some ways. 20:18 < jwb> | plague can build from uploaded SRPMs, but i dont think we want to do that 20:19 < warren> | "2 days" automatic pruning sounds like a good idea, but is that problematic? 20:19 < thl> | no, we don't want that afaics 20:19 < jwb> | warren, only if you allow scratch builds to be ongoing during the prune 20:19 < warren> | we need pruning of some sort 20:20 < warren> | scratch in RH regularly takes up LOTS of storage 20:20 < warren> | Too many implementation details here, and I don't think this is as importnat as other tasks 20:20 < warren> | lets get these tasks done, and revisit the details of this in nex tmeeting 20:20 < thl> | agreed 20:20 * | thl will close this meeting in 30 20:21 * | thl will close this meeting in 15 20:21 --> | dcbw (dcbw) has joined #fedora-extras 20:21 < roozbeh> | while all the big fish are here, 20:21 * | thl will close this meeting in 10 20:21 < dcbw> | skvidal: ping 20:21 < roozbeh> | would someone fix the FC4 build thing? 20:21 < thl> | MARK: Meeting end }}} -- Thorsten Leemhuis From bugzilla at redhat.com Sat Feb 25 15:22:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 10:22:10 -0500 Subject: [Bug 174866] Review Request: polypaudio: Improved Linux sound server In-Reply-To: Message-ID: <200602251522.k1PFMAH5013416@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: polypaudio: Improved Linux sound server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174866 ------- Additional Comments From tcallawa at redhat.com 2006-02-25 10:22 EST ------- Spec Name or Url: http://auroralinux.org/people/spot/review/polypaudio.spec SRPM Name or Url: http://auroralinux.org/people/spot/review/polypaudio-0.7-2.src.rpm Fixed packages resolve the unstripped binary. The rpath issues on x86_64 are much harder to resolve, as removing the rpath calls causes it to explode on that architecture, and an rpath of /usr/lib64 is not fatal, just a bit redundant. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 25 15:28:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 10:28:18 -0500 Subject: [Bug 174866] Review Request: polypaudio: Improved Linux sound server In-Reply-To: Message-ID: <200602251528.k1PFSI6S014489@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: polypaudio: Improved Linux sound server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174866 ------- Additional Comments From drzeus-bugzilla at drzeus.cx 2006-02-25 10:28 EST ------- This multiple architecture business is a bit new to me, so I'm unclear to what the problem is. Does library paths get stored inside the resulting binaries? If you can point me in the right direction I can try to remedy the situation. :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 25 15:30:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 10:30:48 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602251530.k1PFUmeI014903@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From jwb at redhat.com 2006-02-25 10:30 EST ------- Updated %post to set SELinux security context on /srv/gallery2 when /usr/bin/chcon is detected as executable. SPEC: http://www.berningeronline.net/gallery2.spec SRPM: http://www.berningeronline.net/gallery2-2.0.2-0.8cvs20060223.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 15:35:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 10:35:34 -0500 Subject: [Bug 174866] Review Request: polypaudio: Improved Linux sound server In-Reply-To: Message-ID: <200602251535.k1PFZY2l016204@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: polypaudio: Improved Linux sound server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174866 ------- Additional Comments From tcallawa at redhat.com 2006-02-25 10:35 EST ------- Yep, that's exactly what it is. Google for rpath, and grep through the polypaudio source tree to see it in action. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 25 15:42:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 10:42:07 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602251542.k1PFg7v8017240@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From ville.skytta at iki.fi 2006-02-25 10:42 EST ------- As far as I know, SELinux contexts are something that should be done in the selinux-policy package (until drop-in policy modules from packages are possible), not chcon'ing in packages. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 15:52:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 10:52:08 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602251552.k1PFq8L2019349@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From dennis at ausil.us 2006-02-25 10:51 EST ------- %if "%{?juk:1}" == "1" desktop-file-install --vendor=fedora \ --dir $RPM_BUILD_ROOT%{_datadir}/applications/kde \ --add-category="X-Fedora" \ --delete-original \ $RPM_BUILD_ROOT%{_datadir}/applications/kde/juk.desktop %endif the desktop-file-install was wrong. there was a done that did not belong there and you have to add --vendor=fedora not --vendor="" and you need to delete the original otherwise you end up with 2 .desktop files. Fix this and the package is approved -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From tibbs at math.uh.edu Sat Feb 25 16:29:38 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 25 Feb 2006 10:29:38 -0600 Subject: maxima bug? In-Reply-To: (leon's message of "Sat, 25 Feb 2006 10:50:13 +0000") References: Message-ID: >>>>> "l" == leon writes: l> Hi all, Can anyone confirm this bug? Thank you. You don't really provide much information. I installed maxima and its maxima-runtime-gcl dependency on FC4 i386 and ran it; it starts fine. But you gave no instructions for reproducing your problem, so I don't know what I should do now. - J< From bugzilla at redhat.com Sat Feb 25 16:38:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 11:38:01 -0500 Subject: [Bug 183028] New: Review Request: perl-Spiffy Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 Summary: Review Request: perl-Spiffy Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: steve at silug.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Spiffy/perl-Spiffy.spec SRPM Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Spiffy-0.24-1.src.rpm Description: "Spiffy" is a framework and methodology for doing object oriented (OO) programming in Perl. Spiffy combines the best parts of Exporter.pm, base.pm, mixin.pm and SUPER.pm into one magic foundation class. It attempts to fix all the nits and warts of traditional Perl OO, in a clean, straightforward and (perhaps someday) standard way. Spiffy is required by Spoon and IO::All, which are both required by Kwiki. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 16:46:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 11:46:30 -0500 Subject: [Bug 182941] Review Request: nessus-core Network vulnerability scanner In-Reply-To: Message-ID: <200602251646.k1PGkUZJ028655@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: nessus-core Network vulnerability scanner https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182941 ------- Additional Comments From imlinux at gmail.com 2006-02-25 11:46 EST ------- -Please provide a full URL to any sources/patches that have an upstream (Source0 is a must) -Inconsistant use of buildroot ($RPM_BUILD_ROOT, %buildroot %{buildroot}) pick one -Consolidate sbindir entries in nessus-server (non-blocker) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugs.michael at gmx.net Sat Feb 25 18:10:18 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 25 Feb 2006 19:10:18 +0100 Subject: Frustrated package submitters? (was: Re: Summary from last FESCo meeting) In-Reply-To: <1140879360.2314.14.camel@localhost.localdomain> References: <1140879360.2314.14.camel@localhost.localdomain> Message-ID: <20060225191018.33e9a3a7.bugs.michael@gmx.net> On Sat, 25 Feb 2006 15:55:59 +0100, Thorsten Leemhuis wrote: > 19:54 < BobJensen> | People I have talked to abotu submitting packages are frustrated by the reviw process > I would prefer if those unnamed people contacted FESCO or fedora-extras-list directly. In case you picked yourself as the spokesman of that group, provide some details, please. From my perspective (and I admit I've been doing a *lot* less reviews myself compared with fedora.us era), many reviews are still quite difficult and time-consuming. The usual packaging mistakes range from "simply fails to build" to "does not work at run-time" and "does not erase without errors". There are packages which NEEDSWORK, not seldomly due to severe packaging mistakes. There are packages, where the reviewers becomes an instructor (same thing applies to some upstream projects). And there are packages, where the packagers seem to spend less time on packaging and testing than the reviewer(s) do. The recent repo breakage caused by invalid "Provides" plus some bugs in new packages and updates are reason enough not to "lower the hurdle" by altering the review process for new packages. In general, reviews and approvals can be sped up by bringing packages in shape, doing test-builds and reviews and run-time tests and only then declaring a package as "ready". Better check your own package more carefully instead of relying on reviewers. Everybody can help with that in bugzilla. New packagers can demonstrate good packaging practice and that they are aware of things discussed in the packaging guidelines/policies. From bugzilla at redhat.com Sat Feb 25 18:32:03 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 13:32:03 -0500 Subject: [Bug 183038] New: Review Request: perl-IO-All Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183038 Summary: Review Request: perl-IO-All Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: steve at silug.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-IO-All/perl-IO-All.spec SRPM Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-IO-All-0.33-1.src.rpm Description: The IO::All object is a proxy for IO::File, IO::Dir, IO::Socket, IO::String, Tie::File, File::Spec, File::Path and File::ReadBackwards; as well as all the DBM and MLDBM modules. You can use most of the methods found in these classes and in IO::Handle (which they inherit from). IO::All adds dozens of other helpful idiomatic methods including file stat and manipulation functions. IO::All is required by Spiffy, which is required by Kwiki. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 18:36:17 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 13:36:17 -0500 Subject: [Bug 183039] New: Review Request: perl-Spoon Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183039 Summary: Review Request: perl-Spoon Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: steve at silug.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Spoon/perl-Spoon.spec SRPM Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Spoon-0.23-1.src.rpm Description: Spoon is an Application Framework that is designed primarily for building Social Software web applications. The Kwiki wiki software is built on top of Spoon. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 18:40:45 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 13:40:45 -0500 Subject: [Bug 183040] New: Review Request: perl-Kwiki Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183040 Summary: Review Request: perl-Kwiki Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: steve at silug.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki/perl-Kwiki.spec SRPM Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-0.38-1.src.rpm Description: A Wiki is a website that allows its users to add pages, and edit any existing pages. It is one of the most popular forms of web collaboration. If you are new to wiki, visit http://c2.com/cgi/wiki?WelcomeVisitors which is possibly the oldest wiki, and has lots of information about how wikis work. Kwiki is a Perl wiki implementation based on the Spoon application architecture and using the Spiffy object orientation model. The major goals of Kwiki are that it be easy to install, maintain and extend. All the features of a Kwiki wiki come from plugin modules. The base installation comes with the bare minimum plugins to make a working Kwiki. To make a really nice Kwiki installation you need to install additional plugins. Which plugins you pick is entirely up to you. Another goal of Kwiki is that every installation will be unique. When there are hundreds of plugins available, this will hopefully be the case. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 18:56:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 13:56:07 -0500 Subject: [Bug 183041] New: Review Request: perl-Kwiki-ModPerl Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183041 Summary: Review Request: perl-Kwiki-ModPerl Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: steve at silug.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-ModPerl/perl-Kwiki-ModPerl.spec SRPM Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-ModPerl-0.09-1.src.rpm Description: Kwiki mod_perl plugin. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 18:59:04 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 13:59:04 -0500 Subject: [Bug 183042] New: Review Request: perl-Kwiki-Archive-Rcs Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183042 Summary: Review Request: perl-Kwiki-Archive-Rcs Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: steve at silug.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-Archive-Rcs/perl-Kwiki-Archive-Rcs.spec SRPM Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-Archive-Rcs-0.15-1.src.rpm Description: Kwiki Page Archival Using RCS. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 19:03:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 14:03:16 -0500 Subject: [Bug 183043] New: Review Request: perl-Kwiki-Revisions Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183043 Summary: Review Request: perl-Kwiki-Revisions Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: steve at silug.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-Revisions/perl-Kwiki-Revisions.spec SRPM Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-Revisions-0.15-1.src.rpm Description: Kwiki Revisions plugin. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 19:08:39 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 14:08:39 -0500 Subject: [Bug 183044] New: Review Request: perl-Kwiki-NewPage Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183044 Summary: Review Request: perl-Kwiki-NewPage Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: steve at silug.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-NewPage/perl-Kwiki-NewPage.spec SRPM Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-NewPage-0.12-1.src.rpm Description: Kwiki New Page plugin. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 19:11:05 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 14:11:05 -0500 Subject: [Bug 183045] New: Review Request: perl-Kwiki-RecentChanges Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183045 Summary: Review Request: perl-Kwiki-RecentChanges Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: steve at silug.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-RecentChanges/perl-Kwiki-RecentChanges.spec SRPM Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-RecentChanges-0.13-1.src.rpm Description: Kwiki Recent Changes plugin. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 19:14:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 14:14:13 -0500 Subject: [Bug 183047] New: Review Request: perl-Kwiki-Search Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183047 Summary: Review Request: perl-Kwiki-Search Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: steve at silug.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-Search/perl-Kwiki-Search.spec SRPM Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-Search-0.12-1.src.rpm Description: Kwiki Search plugin. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 19:36:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 14:36:53 -0500 Subject: [Bug 183050] New: Review Request: perl-Kwiki-UserPreferences Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183050 Summary: Review Request: perl-Kwiki-UserPreferences Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: steve at silug.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-UserPreferences/perl-Kwiki-UserPreferences.spec SRPM Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-UserPreferences-0.13-1.src.rpm Description: Kwiki User Preferences plugin. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 19:38:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 14:38:50 -0500 Subject: [Bug 183052] New: Review Request: perl-Kwiki-UserName Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183052 Summary: Review Request: perl-Kwiki-UserName Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: steve at silug.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-UserName/perl-Kwiki-UserName.spec SRPM Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-UserName-0.14-1.src.rpm Description: Kwiki User Name plugin. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 19:40:04 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 14:40:04 -0500 Subject: [Bug 176452] Review Request: oddjob - a D-BUS service which runs odd jobs on behalf of client applications In-Reply-To: Message-ID: <200602251940.k1PJe4J1024057@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: oddjob - a D-BUS service which runs odd jobs on behalf of client applications https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176452 jspaleta at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From jspaleta at gmail.com 2006-02-25 14:39 EST ------- Okay sorry it took so long. Marking this as APPROVED for FE devel I just built local binaries of 0.23 under mock against the development trees. No important changes in the spec file since 0.22 that need review and the md5sums in the 0.23 src.rpm match the upstream source md5sum df4a8c74dc972ede3c829b42da388f1b oddjob-0.23-1.tar.gz Once i move the example configs over to the system locations the example command in comment #11 appears to work as i expect. As an aside, this looks like a very good tool for sysadmins, but I think there will need to be a little more polish associated with the documentation and perhaps another example or two to help people walk through getting more familiar with scripting dbus actions through oddjob Back to the provided example as user: oddjob_request -s com.redhat.oddjob.sample -o /com/redhat/oddjob/sample -i com.redhat.oddjob.sample sample com.redhat.oddjob.Error.ACL: ACL does not allow access as root oddjob_request -s com.redhat.oddjob.sample -o /com/redhat/oddjob/sample -i com.redhat.oddjob.sample sample Error org.freedesktop.DBus.Error.SELinuxSecurityContextUnknown: Could not determine security context for ':1.3'. [env] ODDJOB_OBJECT_PATH=/com/redhat/oddjob/sample ODDJOB_INTERFACE_NAME=com.redhat.oddjob.sample ODDJOB_METHOD_NAME=sample ODDJOB_SERVICE_NAME=com.redhat.oddjob.sample [id] uid=0(root) gid=0(root) groups=0(root) [vmstat] procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 136 7588 34068 205392 0 0 160 67 169 401 10 3 84 3 -jef -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From ed at eh3.com Sat Feb 25 19:50:33 2006 From: ed at eh3.com (Ed Hill) Date: Sat, 25 Feb 2006 14:50:33 -0500 Subject: Frustrated package submitters? (was: Re: Summary from last FESCo meeting) In-Reply-To: <20060225191018.33e9a3a7.bugs.michael@gmx.net> References: <1140879360.2314.14.camel@localhost.localdomain> <20060225191018.33e9a3a7.bugs.michael@gmx.net> Message-ID: <1140897033.31903.729.camel@ernie> On Sat, 2006-02-25 at 19:10 +0100, Michael Schwendt wrote: > The recent repo > breakage caused by invalid "Provides" plus some bugs in new packages and > updates are reason enough not to "lower the hurdle" by altering the review > process for new packages. As one of the guilty parties from the recent dap-server problem, I'd like to submit my humble apologies along with two ideas for addition to the wiki at: http://fedoraproject.org/wiki/Packaging/ReviewGuidelines and they are: - '''MUST''': Source must not use (and preferably not even contain) a local copy of something that is packaged elsewhere in Fedora Core or Extras. - '''MUST''': For each binary and noarch RPM generated, reviewers must verify that the list of provides ("rpm -q --provides ...") are acceptable for this package. Or, are there better ways to avoid this situation in the future? If so, would someone please describe? 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 bugzilla at redhat.com Sat Feb 25 19:47:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 14:47:02 -0500 Subject: [Bug 183054] New: Review Request: perl-Kwiki-Diff Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183054 Summary: Review Request: perl-Kwiki-Diff Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: steve at silug.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-Diff/perl-Kwiki-Diff.spec SRPM Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-Diff-0.03-2.src.rpm Description: Kwiki Diff plugin. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 20:21:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 15:21:30 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602252021.k1PKLUCf030138@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From jwb at redhat.com 2006-02-25 15:21 EST ------- Without the chcon or modification of the selinux-policy package, the web server will be unable to do anything in the default gallery directory (/srv/gallery2) if SELinux is in enforcing mode. Since I don't have ability or access to change the policy package, I simply chcon'ed as a workaround until the policy is changed. As the gallery2 package creates the /srv/gallery2 directory, I'm not sure changing the policy would have any effect - it may have to be either a "chcon" in %post or wait until drop-in policy modules are possible/accepted. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 20:42:05 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 15:42:05 -0500 Subject: [Bug 174866] Review Request: polypaudio: Improved Linux sound server In-Reply-To: Message-ID: <200602252042.k1PKg5gS001385@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: polypaudio: Improved Linux sound server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174866 ------- Additional Comments From drzeus-bugzilla at drzeus.cx 2006-02-25 15:41 EST ------- This seems to be a libtool issue since only x86_64 gets the rpath set. I also examined the command sent to libtool and it contained no rpath. The resulting gcc command does though. I tried googling the issue but didn't see anything to help me solve it. Do you have any pointers? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 25 21:15:32 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 16:15:32 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602252115.k1PLFWSA006958@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From ville.skytta at iki.fi 2006-02-25 16:15 EST ------- Just file a bug/RFE against the selinux-policy package with details on what's needed. According to my experience, those requests tend to get fulfilled very quickly especially in simple cases such as this one. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 21:28:26 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 16:28:26 -0500 Subject: [Bug 176582] Review Request: freedt -- Reimplementation of Dan Bernstein's daemontools under the GNU GPL In-Reply-To: Message-ID: <200602252128.k1PLSQwH009100@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: freedt -- Reimplementation of Dan Bernstein's daemontools under the GNU GPL https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176582 ------- Additional Comments From jpmahowald at gmail.com 2006-02-25 16:28 EST ------- The binaries appear to be statically linked. This needs to be fixed unless there's a real reason to do so. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From michel.salim at gmail.com Sat Feb 25 21:34:36 2006 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 25 Feb 2006 16:34:36 -0500 Subject: RPM %setup query Message-ID: <883cfe6d0602251334q4a8e9609y53f2d6b394507dae@mail.gmail.com> I'm packaging zeroinstall-injector for Extras, and the upstream tarball comes signed with GPG (the signature is not detached). The discussion for the review seems to have reached the consensus that I should use this as the source tarball, which leads to the following problem: How can I tell %setup that it needs to do gpg --decrypt on the source (*and* ignore the error return status due to the public key not being in the keychain), and then pipe the result to gzip and tar? Right now I'm calling gpg manually before %setup, moved the signed tarball out of the way, rename the unsigned tarball to the original name, run %setup and then restore the original signed tarball to its original name. rpmlint does not like me using %{_sourcedir} in the spec file, though. Should I ignore this rpmlint error? Or Would this be a special case in which the packaged source tarball does not have to match upstream? Any help from spec macro experts appreciated. Thanks, -- Michel Salim http://www.cs.indiana.edu/~msalim http://the-dubois-papers.blogspot.com/ From ville.skytta at iki.fi Sat Feb 25 21:53:56 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 25 Feb 2006 23:53:56 +0200 Subject: RPM %setup query In-Reply-To: <883cfe6d0602251334q4a8e9609y53f2d6b394507dae@mail.gmail.com> References: <883cfe6d0602251334q4a8e9609y53f2d6b394507dae@mail.gmail.com> Message-ID: <1140904436.15616.62.camel@bobcat.mine.nu> On Sat, 2006-02-25 at 16:34 -0500, Michel Salim wrote: > I'm packaging zeroinstall-injector for Extras, and the upstream > tarball comes signed with GPG [...] > How can I tell %setup that it needs to do gpg --decrypt on the source Hm, I'm confused, the tarball is signed but you're running --decrypt? > Right now I'm calling gpg manually before %setup, moved the signed > tarball out of the way, rename the unsigned tarball to the original > name, run %setup and then restore the original signed tarball to its > original name. How about just: %prep %setup -c -T # do whatever is needed $stuff to %{SOURCEx} From bugzilla at redhat.com Sat Feb 25 21:49:17 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 16:49:17 -0500 Subject: [Bug 181801] Review Request: zeroinstall-injector In-Reply-To: Message-ID: <200602252149.k1PLnHZi012629@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: zeroinstall-injector https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181801 ------- Additional Comments From michel.salim at gmail.com 2006-02-25 16:49 EST ------- So, as I posted on the mailing list, there is no clean way of using the signed tarball that upstream provided. This is the hackery I have so far; it works, has no side effect, but rpmlint is deeply unhappy by the use of %{sourcedir}. Unless there is a cleaner solution I'd suggest that either the curious user find the upstream and verify it himself. %prep # Decrypt upstream source, ignore error message due to unknown key gpg --decrypt %{_sourcedir}/%{name}-%{version}.tar.gz.gpg > %{_sourcedir}/%{name}-%{version}.tar.gz || true # Point source to the decrypted tarball mv %{_sourcedir}/%{name}-%{version}.tar.gz.gpg %{_sourcedir}/%{name}-%{version}.tar.gz.gpgbak mv %{_sourcedir}/%{name}-%{version}.tar.gz %{_sourcedir}/%{name}-%{version}.tar.gz.gpg %setup -q # Restore upstream tarball mv %{_sourcedir}/%{name}-%{version}.tar.gz.gpgbak %{_sourcedir}/%{name}-%{version}.tar.gz -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 21:50:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 16:50:13 -0500 Subject: [Bug 181068] Review Request: html401-dtds - HTML 4.01 document type definitions In-Reply-To: Message-ID: <200602252150.k1PLoDoE012781@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: html401-dtds - HTML 4.01 document type definitions https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181068 ------- Additional Comments From ville.skytta at iki.fi 2006-02-25 16:50 EST ------- http://cachalot.mine.nu/5/SRPMS/html401-dtds-4.01-0.3.src.rpm * Sat Feb 25 2006 Ville Skytt? - 4.01-0.3 - Improve description (#181068). - Fold specification into main package as %doc (#181068). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From tibbs at math.uh.edu Sat Feb 25 22:06:47 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 25 Feb 2006 16:06:47 -0600 Subject: Frustrated package submitters? In-Reply-To: <20060225191018.33e9a3a7.bugs.michael@gmx.net> (Michael Schwendt's message of "Sat, 25 Feb 2006 19:10:18 +0100") References: <1140879360.2314.14.camel@localhost.localdomain> <20060225191018.33e9a3a7.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> I would prefer if those unnamed people contacted FESCO or MS> fedora-extras-list directly. In case you picked yourself as the MS> spokesman of that group, provide some details, please. Well, I've been on both ends of the process and I think it generally works pretty well, but it could work a little better. Here are a few observations after having submitted a few packages and having reviewed several others. First, the sponsor process hurts a bit; I think we could relax the requirement that the initial sponsor and reviewer be the same person. I just went through a big review for multitail but I think that there was no notation that a sponsor was needed. Under the current rules I shouldn't have done the review, but what does it hurt? And in any case we probably could use more sponsors. One thing that's bothered me is the nonspecificity of the guidelines. Someone noted a blocker on one of my packages, but when asked where the prohibition was in the guidelines the commenter didn't respond. Some people say that my reviews haven't been picky enough, and some have said they're too picky. There's not a lot of consistency. In my own reviews I'm trying to strike a balance. Doing good reviews takes a lot of time and besides lowering standards the only thing we that can be done to help is to provide better and more complete templates and then require adherence to them. - J< MS> perspective (and I admit I've been doing a *lot* less reviews MS> myself compared with fedora.us era), many reviews are still quite MS> difficult and time-consuming. The usual packaging mistakes range MS> from "simply fails to build" to "does not work at run-time" and MS> "does not erase without errors". There are packages which MS> NEEDSWORK, not seldomly due to severe packaging mistakes. There MS> are packages, where the reviewers becomes an instructor (same MS> thing applies to some upstream projects). And there are packages, MS> where the packagers seem to spend less time on packaging and MS> testing than the reviewer(s) do. The recent repo breakage caused MS> by invalid "Provides" plus some bugs in new packages and updates MS> are reason enough not to "lower the hurdle" by altering the review MS> process for new packages. MS> In general, reviews and approvals can be sped up by bringing MS> packages in shape, doing test-builds and reviews and run-time MS> tests and only then declaring a package as "ready". Better check MS> your own package more carefully instead of relying on MS> reviewers. Everybody can help with that in bugzilla. New packagers MS> can demonstrate good packaging practice and that they are aware of MS> things discussed in the packaging guidelines/policies. MS> -- fedora-extras-list mailing list fedora-extras-list at redhat.com MS> https://www.redhat.com/mailman/listinfo/fedora-extras-list -- Jason L Tibbitts III - tibbs at math.uh.edu - 713/743-3486 - 660PGH - 94 PC800 System Manager: University of Houston Department of Mathematics And with death The knowledge comes It was the life all along We'd been afraid of From bugzilla at redhat.com Sat Feb 25 22:07:17 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 17:07:17 -0500 Subject: [Bug 181801] Review Request: zeroinstall-injector In-Reply-To: Message-ID: <200602252207.k1PM7H3O015331@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: zeroinstall-injector https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181801 ------- Additional Comments From tibbs at math.uh.edu 2006-02-25 17:07 EST ------- Why not use %setup -c -T to make a directory and cd into it. Decrypt %{SOURCE0} into the current directory, untar it manually, and go on with the installation as normal? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 22:08:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 17:08:53 -0500 Subject: [Bug 177818] Review Request: adplug In-Reply-To: Message-ID: <200602252208.k1PM8rIL015537@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: adplug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177818 ------- Additional Comments From triad at df.lth.se 2006-02-25 17:08 EST ------- Updtream have agreed to change the path, but has this strange phenomenon with autoconf, any ideas to help them understand what autoconf seem to want to do? ---------------------------------- Date: 2006-02-18 00:29 Sender: dynamiteProject Admin Logged In: YES user_id=31101 I agree with you and like to correct it, although the following is strange: Autoconf has a set of variables to refer to default installation directories, which i've been using. In order to correct this bug, i changed the default lookup path for the adplug.db file from $(datadir)/adplug, which resolves to /usr/local/share/adplug, to $(sharedstatedir)/adplug, of which the Autoconf docs say for $(sharedstatedir) that it is "The directory for installing modifiable architecture-independent data", so exactly what i'm looking for. This variable resolves to /usr/local/com, which is a path i never heard of and didn't exist in my system before. Question is now if i should just set it to $(sharedstatedir) and let the distribution maintainers (i.e. you) re-configure the right path for their installation at build time. According to the Autoconf docs, this is the right way to go. I really wonder though what this /com directory is. I don't see anything useful on google. Do you have any idea? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From michel.salim at gmail.com Sat Feb 25 22:12:21 2006 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 25 Feb 2006 17:12:21 -0500 Subject: RPM %setup query In-Reply-To: <1140904436.15616.62.camel@bobcat.mine.nu> References: <883cfe6d0602251334q4a8e9609y53f2d6b394507dae@mail.gmail.com> <1140904436.15616.62.camel@bobcat.mine.nu> Message-ID: <883cfe6d0602251412n27d44f0cic1ef8dee34e53ef6@mail.gmail.com> On 2/25/06, Ville Skytt? wrote: > On Sat, 2006-02-25 at 16:34 -0500, Michel Salim wrote: > > > I'm packaging zeroinstall-injector for Extras, and the upstream > > tarball comes signed with GPG > [...] > > How can I tell %setup that it needs to do gpg --decrypt on the source > > Hm, I'm confused, the tarball is signed but you're running --decrypt? > Sure. if GnuPG is not told to create a detached signature, a .gpg file is generated, and the file that was signed can be retrieved using --decrypt. > > Right now I'm calling gpg manually before %setup, moved the signed > > tarball out of the way, rename the unsigned tarball to the original > > name, run %setup and then restore the original signed tarball to its > > original name. > > How about just: > > %prep > %setup -c -T > # do whatever is needed $stuff to %{SOURCEx} > Ah, OK. I'm changing it to %prep # do stuff with %{SOURCEx} %setup -D -T To make use of %setup's sanitization of the extracted files. Thanks! -- Michel Salim http://www.cs.indiana.edu/~msalim http://the-dubois-papers.blogspot.com/ From bugzilla at redhat.com Sat Feb 25 22:16:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 17:16:53 -0500 Subject: [Bug 176784] Review Request: gnome-schedule: A GTK+ based user interface for cron and at In-Reply-To: Message-ID: <200602252216.k1PMGrZL017076@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-schedule: A GTK+ based user interface for cron and at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176784 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |jpmahowald at gmail.com OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-25 17:16 EST ------- Good: rpmlint of gnome-schedule-1.0.0-1.noarch.rpm:E: gnome-schedule only-non-binary-in-usr-lib bonobo, can be ignored. - package meets naming guidelines - package meets packaging guidelines - license ( GPL) OK, text in %doc, matches source - spec file legible, in am. english - source matches upstream - package compiles on devel (x86_64) - no missing BR - no unnecessary BR - locales handled by %find_lang - not relocatable - owns all directories that it creates - no duplicate files - permissions ok - %clean ok - macro use consistent - code, not content - no need for -docs - nothing in %doc affects runtime - .desktop file in order - works Looks good. Send me your account details and I'll sponsor you. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 25 22:35:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 17:35:47 -0500 Subject: [Bug 177818] Review Request: adplug In-Reply-To: Message-ID: <200602252235.k1PMZlvb022554@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: adplug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177818 ------- Additional Comments From triad at df.lth.se 2006-02-25 17:35 EST ------- This was one weird thing, but looking into the M4 sources for autoconf you see it is defined like this: AC_SUBST([sharedstatedir], ['${prefix}/com']) When it installs for real it will go into /com actually, and that is NOT in the Filesystem Hierarchy Standard, nor on any system I have ever seen (logged into a Solaris and a ULTRIX system to verify this) it might be in the Modified Directory Structure http://markhobley.yi.org/standards/mdirs/index.html but I cannot access that right now. I think this comes from the fact that some sysadmins like to mount /usr/local on a network share, so when you just compile and install a program it will install in a location where all computers (running same OS/distro) have access to the locally compiled programs. Then a shared database across all computers mounting /usr/local (or even NFS-mounting /com) will make sense. (This is just an educated guess.) /var however, is guaranteed to be on the actual local computer only. That is why there exist such sick things as proprietary software actually installing itself into /var. Even if /com is probably used by some people in this world, I hardly believe it will be very many. What you probably rather want to use is $(localstatedir) definied as: AC_SUBST([localstatedir], ['${prefix}/var']) which will expand to "/usr/local/var" on local build but when built for installation into root (--prefix=/) will expand to /var of course. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 25 22:51:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 17:51:36 -0500 Subject: [Bug 181801] Review Request: zeroinstall-injector In-Reply-To: Message-ID: <200602252251.k1PMpaoM026647@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: zeroinstall-injector https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181801 ------- Additional Comments From michel.salim at gmail.com 2006-02-25 17:51 EST ------- This is what Ville Skytt? suggested as well. I decided to do something similar, but the other way around: after %prep, back up one directory, manually untar, then call %setup with -D (do not delete) and -T (do not untar). This way, %setup gets to sanitize file ownership and permissions. Thanks for the suggestion! Changes from the previous -2 release: - Now use gpg-signed upstream tarball, BuildReq on gnupg to handle this The other BuildReq is still on Python, as explained before. Spec Name or Url: http://hircus.org/fedora/zeroinstall-injector/zeroinstall-injector.spec SRPM Name or Url: http://hircus.org/fedora/zeroinstall-injector/zeroinstall-injector-0.18-3.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 22:58:31 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 17:58:31 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602252258.k1PMwVXl028544@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From tibbs at math.uh.edu 2006-02-25 17:58 EST ------- Man, there's a whole pile of these, but so far the ones I've looked at look great. What autogenerated these specs? I'll try to get through them all tonight. Anyway, one problem and one question: BuildRequires: perl >= 1:5.6.1 should go; it will always be satisfied for Extras packages thus is prohibited by the packaging guidelines. Why the Provides: perl(mixin)? I note that RPM does not find that provide, but I'm wondering why not. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 23:00:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 18:00:10 -0500 Subject: [Bug 175623] Review Request: yaz - Z39.50/SRW/SRU programs In-Reply-To: Message-ID: <200602252300.k1PN0A88028897@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: yaz - Z39.50/SRW/SRU programs https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175623 ------- Additional Comments From jpmahowald at gmail.com 2006-02-25 18:00 EST ------- Build failed, devel x86_64 checking for working tcpd.h... no configure: error: tcpd development libraries missing -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 25 23:07:24 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 18:07:24 -0500 Subject: [Bug 183067] New: Review Request: par2 - PAR2 recovery set command line utility Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183067 Summary: Review Request: par2 - PAR2 recovery set command line utility Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: a.kurtz at hardsun.net QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://hardsun.net/fedora/par2.spec SRPM Name or Url: http://hardsun.net/fedora/par2-0.4-1.src.rpm Description: This application provides support for PAR2 files. Parity archives provide RAID-like data recovery for files, allowing the recovery of any 'X' real data-blocks for 'X' parity data-blocks present. Version 2 extends this to virtual slices of files, reducing the required redundant data and making it easier to include non-like sized files in the recovery set. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 23:10:14 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 18:10:14 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602252310.k1PNAEFo030643@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From jwb at redhat.com 2006-02-25 18:10 EST ------- Assuming the RFE is accepted, which based on above comments I think is a safe assumption, how does the policy get applied when the gallery2 package is installed? Do I need to run 'restorecon' in %post, or is there magic I'm unaware of the apply the correct contexts automatically when the directory is created? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 23:23:09 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 18:23:09 -0500 Subject: [Bug 182254] Review Request: SS5 In-Reply-To: Message-ID: <200602252323.k1PNN9rA032645@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: SS5 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182254 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|bugzilla-sink at leemhuis.info |jpmahowald at gmail.com OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-25 18:23 EST ------- See the packaging guidelines for most of these: http://fedoraproject.org/wiki/Packaging/Guidelines A few things need to be worked on: * rpm chokes on your Copyright tag. This should be changed to License, and changed to the accepted acronym, GPL. * I don't understand the mr1 part of the Release tag. Read the naming guidlines to see examples when this can be used. http://fedoraproject.org/wiki/Packaging/NamingGuidelines * Define the recommended Buildroot * Your %files directive lists a binary in /opt. Move it out of there, it's not even on the path. * Many directives are after the %changelog. This may work, but it's against convvention, nearly every other package does %changelog last. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 23:27:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 18:27:02 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602252327.k1PNR2NX000855@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From ville.skytta at iki.fi 2006-02-25 18:26 EST ------- No need to run anything, that magic exists and is how other files in the filesystem get their contexts too. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sat Feb 25 23:47:54 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 18:47:54 -0500 Subject: [Bug 166254] Review Request: perl-Imager In-Reply-To: Message-ID: <200602252347.k1PNlsxT004501@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Imager https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166254 alexl at users.sourceforge.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexl at users.sourceforge.net ------- Additional Comments From alexl at users.sourceforge.net 2006-02-25 18:47 EST ------- Since this has been built in development, this bug should be CLOSED as NEXTRELEASE. (However I had troubles rebuilding this in development similar to what happens in bug #182459 for FC-4). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 25 23:50:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 18:50:20 -0500 Subject: [Bug 166253] Review Request: perl-Gtk2-GladeXML In-Reply-To: Message-ID: <200602252350.k1PNoKYr004998@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Gtk2-GladeXML https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166253 alexl at users.sourceforge.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexl at users.sourceforge.net ------- Additional Comments From alexl at users.sourceforge.net 2006-02-25 18:50 EST ------- Built and available in development since September 2005, please CLOSE as NEXTRELEASE. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 25 23:51:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 18:51:47 -0500 Subject: [Bug 166252] Review Request: perl-Gnome2-Canvas In-Reply-To: Message-ID: <200602252351.k1PNplt2005288@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Gnome2-Canvas https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166252 alexl at users.sourceforge.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexl at users.sourceforge.net ------- Additional Comments From alexl at users.sourceforge.net 2006-02-25 18:51 EST ------- Built and available in development since September 2005, please CLOSE as NEXTRELEASE. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 25 23:54:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 18:54:13 -0500 Subject: [Bug 166252] Review Request: perl-Gnome2-Canvas In-Reply-To: Message-ID: <200602252354.k1PNsDwh005650@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Gnome2-Canvas https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166252 sundaram at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From sundaram at redhat.com 2006-02-25 18:53 EST ------- done. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Feb 25 23:55:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 18:55:34 -0500 Subject: [Bug 179541] Review Request: tinyfugue: A MU* client In-Reply-To: Message-ID: <200602252355.k1PNtYCn005894@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: tinyfugue: A MU* client https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179541 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |jpmahowald at gmail.com OtherBugsDependingO|163776, 177841 |163779 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-25 18:55 EST ------- You may have seen older fedora.us guidlines. Good: - rpmlint checks clean - package meets naming guidelines - package meets packaging guidelines - license (GPL) OK, text in %doc, matches source - spec file legible, in am. english - source matches upstream - package compiles on devel (x86_64) - no missing BR - no unnecessary BR - no locales - not relocatable - owns all directories that it creates - no duplicate files - permissions ok - %clean ok - macro use consistent - code, not content - no need for -docs - nothing in %doc affects runtime - no need for .desktop file APPROVED. I have since become a sponsor, so send me your Fedora account info. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 26 00:07:19 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 19:07:19 -0500 Subject: [Bug 183067] Review Request: par2 - PAR2 recovery set command line utility In-Reply-To: Message-ID: <200602260007.k1Q07J22007583@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: par2 - PAR2 recovery set command line utility https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183067 ------- Additional Comments From icon at fedoraproject.org 2006-02-25 19:07 EST ------- There is "parchive" already in Extras. Same thing? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 00:55:45 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 19:55:45 -0500 Subject: [Bug 183067] Review Request: par2 - PAR2 recovery set command line utility In-Reply-To: Message-ID: <200602260055.k1Q0tjEp014890@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: par2 - PAR2 recovery set command line utility https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183067 ------- Additional Comments From a.kurtz at hardsun.net 2006-02-25 19:55 EST ------- No, parchive deals with PAR or PAR1 files, while par2 is the utility for the next generation spec, PAR2. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 00:57:19 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 19:57:19 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602260057.k1Q0vJCw015197@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From steve at silug.org 2006-02-25 19:57 EST ------- > What autogenerated these specs? cpanspec (http://cpanspec.sf.net/ or install it from Extras). While I didn't (and probably should) mention it in the changelog, I had to do a little minor cleanup to most of the specs it generated, but it's usually just a matter of verifying the license and fixing the description. > I'll try to get through them all tonight. Thank you. :-) > Anyway, one problem and one question: > > BuildRequires: perl >= 1:5.6.1 should go; it will always be satisfied for > Extras packages thus is prohibited by the packaging guidelines. True. That's probably something picked up by cpanspec. I'll change that. > Why the Provides: perl(mixin)? I note that RPM does not find that provide, > but I'm wondering why not. ISTR that rpm picked up a Requires, but not the Provides, so I added the Provides. The Requires seems to get picked up in this whole stack, so I don't think filtering it out would work. # rpm -q --whatrequires 'perl(mixin)' perl-IO-All-0.33-1.fc4 perl-Kwiki-0.38-1.fc4 perl-Kwiki-UserPreferences-0.13-1.fc4 perl-Kwiki-Search-0.12-1.fc4 perl-Kwiki-Revisions-0.15-1.fc4 perl-Kwiki-RecentChanges-0.13-1.fc4 perl-Kwiki-NewPage-0.12-1.fc4 perl-Kwiki-UserName-0.14-1.fc4 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 01:04:32 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 20:04:32 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602260104.k1Q14WsI016231@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From steve at silug.org 2006-02-25 20:04 EST ------- It turns out there's a newer version. http://ftp.kspei.com/pub/steve/rpms/perl-Spiffy-0.30-1.src.rpm * Sat Feb 25 2006 Steven Pritchard 0.30-1 - Update to 0.30. - Drop explicit perl BR. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 02:03:51 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 21:03:51 -0500 Subject: [Bug 179709] Review Request: hdf4_handler - HDF4 data handler for the OPeNDAP Data server In-Reply-To: Message-ID: <200602260203.k1Q23pUD027773@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: hdf4_handler - HDF4 data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179709 pertusus at free.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From pertusus at free.fr 2006-02-25 21:03 EST ------- Ed, thanks for all the reviews, and sorry for the dap-server mess... Everything builds in FC3 and FC4, and I reported upstream the issues (including the HTML::Parser issue) and they're working on it. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 26 02:04:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 21:04:11 -0500 Subject: [Bug 179707] Review Request: dap-server - Basic request handling for DAP servers In-Reply-To: Message-ID: <200602260204.k1Q24BlW027902@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: dap-server - Basic request handling for DAP servers https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179707 Bug 179707 depends on bug 179709, which changed state. Bug 179709 Summary: Review Request: hdf4_handler - HDF4 data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179709 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NEXTRELEASE Status|ASSIGNED |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From pertusus at free.fr Sun Feb 26 02:08:16 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 26 Feb 2006 03:08:16 +0100 Subject: Frustrated package submitters? (was: Re: Summary from last FESCo meeting) In-Reply-To: <1140897033.31903.729.camel@ernie> References: <1140879360.2314.14.camel@localhost.localdomain> <20060225191018.33e9a3a7.bugs.michael@gmx.net> <1140897033.31903.729.camel@ernie> Message-ID: <20060226020816.GA12155@free.fr> > - '''MUST''': Source must not use (and preferably not even contain) > a local copy of something that is packaged elsewhere in Fedora > Core or Extras. In the case of dap-server I guess this wouldn't have helped, as I allready had tried to get rid of it, upstream was convinced, but using the fedora core version wasn't implemented allready. I think that that case really deserved an exception. > - '''MUST''': For each binary and noarch RPM generated, reviewers > must verify that the list of provides ("rpm -q --provides ...") > are acceptable for this package. That would have avoided the issue, I believe. And it is good practice, so let's enforce it. It raises the cost of doing a review, but I believe it is worth it. -- Pat From bugzilla at redhat.com Sun Feb 26 02:07:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 21:07:50 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602260207.k1Q27ohF028679@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From rdieter at math.unl.edu 2006-02-25 21:07 EST ------- OK... I purposely didn't want to change vendor, because that changes the name of the desktop file (juk.desktop -> fedora-juk.desktop) and folks you'd previously used menu editors would have their mods broken because of the name change... but I guess it's not that big of deal... I'll conform. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 26 02:09:46 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 21:09:46 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602260209.k1Q29kS3029212@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From rdieter at math.unl.edu 2006-02-25 21:09 EST ------- %changelog * Sat Feb 25 2006 Rex Dieter 6:3.5.1-4 - -extras: --vendor="fedora" Spec Name or Url: http://apt.kde-redhat.org/apt/kde-redhat/SPECS/kdemultimedia-extras.spec SRPM Name or Url: http://apt.kde-redhat.org/apt/kde-redhat/all/SRPMS.stable/kdemultimedia-extras-3.5.1-4.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From buildsys at fedoraproject.org Sun Feb 26 03:16:08 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 25 Feb 2006 22:16:08 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060226031608.655638011@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 7 cacti-0.8.6h-6.fc4 gajim-0.9.1-2.fc4 gossip-0.10.1-1.fc4 nagios-2.0-0.6.rc2.fc4 perl-Gnome2-Canvas-1.002-4.fc4 perl-Gtk2-GladeXML-1.005-4.fc4 python-cherrypy-2.1.1-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun Feb 26 03:16:14 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 25 Feb 2006 22:16:14 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060226031614.2ECF38011@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 7 Sprog-0.14-7.fc5 TurboGears-0.8a5-1.fc5 bchunk-1.2.0-3 chkrootkit-0.46a-2.fc5 gossip-0.10.1-2.fc5 liferea-1.0.6-2.fc5 xchat-gnome-0.10-3.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Sun Feb 26 04:27:42 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 23:27:42 -0500 Subject: [Bug 183089] New: Review Request: ularn - a text-based roguelike game Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183089 Summary: Review Request: ularn - a text-based roguelike game Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: wart at kobold.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.kobold.org/~wart/fedora/ularn.spec SRPM Name or Url: http://www.kobold.org/~wart/fedora/ularn-1.5p4-1.src.rpm Description: A text-based roguelike game based on the original Larn. Travel through dungeons collecting weapons, killing monsters, in order to find and sell the Eye of Larn to save your sick daughter. ularn is setgid 'games' so that everyone has write access to the high score file. rpmlint complains about this, but I'm inclined to ignore it: E: ularn non-standard-executable-perm /usr/bin/Ularn 02755 E: ularn non-standard-dir-perm /var/games/ularn 0775 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 04:58:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 25 Feb 2006 23:58:34 -0500 Subject: [Bug 182941] Review Request: nessus-core Network vulnerability scanner In-Reply-To: Message-ID: <200602260458.k1Q4wYKZ012853@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: nessus-core Network vulnerability scanner https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182941 ------- Additional Comments From imlinux at gmail.com 2006-02-25 23:58 EST ------- Are you planning on packaging libICE? nessus-core requires it and its not in FC nor FE at this time. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 05:36:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 00:36:27 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602260536.k1Q5aRdm024628@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From tibbs at math.uh.edu 2006-02-26 00:36 EST ------- OK, the package looks great. I've thought about the Provides: perl(mixin) a bit; just to explain it for posterity: Various modules using this one will make use of the syntax: use mixin 'package'; which will cause Perl's dependency generator to decide that the package requires perl(mixin). Since this package (perl-Spiffy) is the package that enables that syntax even though RPM's automatic Provides: generation doesn't detect it, it makes sense to add Provides: perl(mixin) here. The bad: Source matches upstream. However, I can't fetch the source from the provided URL. I needed to use http://search.cpan.org/CPAN/authors/id/I/IN/INGY/Spiffy-0.30.tar.gz instead. The Summary: is problematic. How about "A framework for doing object orinted programming in Perl" instead? The good: Package builds and passes tests in mock (development, i386 and x86_64). rpmlint is silent. The specfile is clean and well written. The license is appropriate, matches upstream and is included as %doc. I'll approve if you fix the Source0: URL and the Summary:. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 05:38:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 00:38:18 -0500 Subject: [Bug 177818] Review Request: adplug In-Reply-To: Message-ID: <200602260538.k1Q5cIxK025236@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: adplug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177818 ------- Additional Comments From rc040203 at freenet.de 2006-02-26 00:38 EST ------- sharedstatedir=$prefix/com is GNU standard cf. http://www.gnu.org/prep/standards/html_node/Directory-Variables.html -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 26 05:39:26 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 00:39:26 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602260539.k1Q5dQLi025431@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From tibbs at math.uh.edu 2006-02-26 00:39 EST ------- I meant to add "and you comment the necessity for the Provides: perl(mixin)." -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 05:45:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 00:45:08 -0500 Subject: [Bug 183097] New: Review Request: rogue - text-based adventure game Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183097 Summary: Review Request: rogue - text-based adventure game Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: wart at kobold.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.kobold.org/~wart/fedora/rogue.spec SRPM Name or Url: http://www.kobold.org/~wart/fedora/rogue-5.4.2-1.src.rpm Description: Before DOOM, there were the Dungeons of DOOM. This is the game that started an entire genre. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 05:49:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 00:49:36 -0500 Subject: [Bug 183097] Review Request: rogue - text-based adventure game In-Reply-To: Message-ID: <200602260549.k1Q5naaS028330@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: rogue - text-based adventure game https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183097 ------- Additional Comments From wart at kobold.org 2006-02-26 00:49 EST ------- rogue is setgid 'games' so that everyone who runs the game can write to the high score file. This causes rpmlint to complain: E: rogue non-standard-dir-perm /var/games/roguelike 0775 E: rogue non-standard-executable-perm /usr/bin/rogue 02755 I am inclined to ignore this. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From wart at kobold.org Sun Feb 26 06:12:08 2006 From: wart at kobold.org (Wart) Date: Sat, 25 Feb 2006 22:12:08 -0800 Subject: angband license Message-ID: <440146B8.60209@kobold.org> While I was packaging angband, I came across this questionable license text. Before I spend too much time with this, I wanted to verify that the first paragraph is valid. In particular, it says that the software can be copied and distributed for non-for-profit purposes, that is, not for commercial purposes. Does this disqualify it as an OSI-compatible license? Note that the current maintainers are actively trying to relicense it under the GPL, but have not yet gotten permission from all of the earlier authors. The web page at the end of the license also claims that it can't be legally distributed with Linux distributions due to GPL incompatibilities, but I question that claim. Does anyone has some insight as to the acceptibility of this license? --Wart Copyright (c) 1997 Ben Harrison, James E. Wilson, Robert A. Koeneke This software may be copied and distributed for educational, research, and not for profit purposes provided that this copyright and statement are included in all such copies. Other copyrights may also apply. All changes made by Ben Harrison, Robert Ruehlmann, and many other Angband developers are also available under the GNU GENERAL PUBLIC LICENSE. Note that this doesn't influence the current distribution, since parts of the source are still only available under the old Moria/Angband license. Until all parts of Angband are distributed under the GPL the only valid license remains the original Moria/Angband license. More informations about Angband and the GPL can be found at: http://www.thangorodrim.net/development/opensource.html From sundaram at fedoraproject.org Sun Feb 26 06:20:23 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 26 Feb 2006 11:50:23 +0530 Subject: angband license In-Reply-To: <440146B8.60209@kobold.org> References: <440146B8.60209@kobold.org> Message-ID: <440148A7.2010807@fedoraproject.org> Wart wrote: >While I was packaging angband, I came across this questionable license >text. Before I spend too much time with this, I wanted to verify that >the first paragraph is valid. In particular, it says that the software >can be copied and distributed for non-for-profit purposes, that is, not >for commercial purposes. Does this disqualify it as an OSI-compatible >license? > > > Yes it does. It is not a OSI compatible since the OSI definition, claus 6 disallows a OSI license to discriminate against fields of endeavor. Refer to http://opensource.org/docs/definition.php for more details. -- Rahul From bugzilla at redhat.com Sun Feb 26 06:19:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 01:19:28 -0500 Subject: [Bug 183067] Review Request: par2 - PAR2 recovery set command line utility In-Reply-To: Message-ID: <200602260619.k1Q6JSts002911@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: par2 - PAR2 recovery set command line utility https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183067 ------- Additional Comments From rc040203 at freenet.de 2006-02-26 01:19 EST ------- NEEDSWORK: - package doesn't depend on libsigc++ at all. Please remove "BR: libsigc++-devel" - I don't see any need for 001_hardlinks.patch The original authors want these programs hardlinks, so be it. - Compilation triggers dozens of warnings of this kind: ... par2fileformat.h:67: warning: ignoring packed attribute on unpacked non-POD field 'MD5Hash PACKET_HEADER::hash' par2fileformat.h:68: warning: ignoring packed attribute on unpacked non-POD field 'MD5Hash PACKET_HEADER::setid' par2fileformat.h:79: warning: ignoring packed attribute on unpacked non-POD field 'MD5Hash FILEVERIFICATIONENTRY::hash' par2fileformat.h:86: warning: ignoring packed attribute on unpacked non-POD field 'MD5Hash FILEVERIFICATIONPACKET::fileid' ... In many cases, these warnings can not be ignored. Please check. - The toplevel Makefile.am contains this: LDADD = -lstdc++ This is a BUG. Remove this line. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 06:35:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 01:35:21 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602260635.k1Q6ZL4V006902@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From rc040203 at freenet.de 2006-02-26 01:35 EST ------- I disagree on your rationale on "Provides: mixin". IMO, this package should NOT provide it, instead packages applying "use mixin 'package'" should be adapted to this kind of usage. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From j.w.r.degoede at hhs.nl Sun Feb 26 08:25:55 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 26 Feb 2006 09:25:55 +0100 Subject: Frustrated package submitters? In-Reply-To: <20060226020816.GA12155@free.fr> References: <1140879360.2314.14.camel@localhost.localdomain> <20060225191018.33e9a3a7.bugs.michael@gmx.net> <1140897033.31903.729.camel@ernie> <20060226020816.GA12155@free.fr> Message-ID: <44016613.6030805@hhs.nl> Patrice Dumas wrote: >> - '''MUST''': For each binary and noarch RPM generated, reviewers >> must verify that the list of provides ("rpm -q --provides ...") >> are acceptable for this package. > > That would have avoided the issue, I believe. And it is good practice, so > let's enforce it. It raises the cost of doing a review, but I believe it > is worth it. > I'm not so sure, the longer the MUST list, the less thorough each step will be done. We need to strike a balance here. This would make a fine should though. Regards, Hans From j.w.r.degoede at hhs.nl Sun Feb 26 08:36:43 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 26 Feb 2006 09:36:43 +0100 Subject: Not for commercial use licenses / seperate repo? (was Re: angband license) In-Reply-To: <440148A7.2010807@fedoraproject.org> References: <440146B8.60209@kobold.org> <440148A7.2010807@fedoraproject.org> Message-ID: <4401689B.6060708@hhs.nl> Rahul Sundaram wrote: > Wart wrote: > >> While I was packaging angband, I came across this questionable license >> text. Before I spend too much time with this, I wanted to verify that >> the first paragraph is valid. In particular, it says that the software >> can be copied and distributed for non-for-profit purposes, that is, not >> for commercial purposes. Does this disqualify it as an OSI-compatible >> license? >> >> >> > Yes it does. It is not a OSI compatible since the OSI definition, claus > 6 disallows a OSI license to discriminate against fields of endeavor. > Refer to http://opensource.org/docs/definition.php for more details. > Indeed it does. This subject actually comes up quite frequent and it seems relevant in the non-free FE repo discussion we had on the -devel list. Now I'm no fan of non-free software, but IMHO opinion I think it is fair if people give something away for free including source et all that they disallow commercial use. So I would like to propose creating a not for commercial use repo under the fedora umbrella. I know some people are afraid that this will cause pollution of the really free parts, so this repo would have to follow the following rules: -not enabled in default FC repo config -may not be used by FE packages to depend on, IOW any package depending on a package in non-commercial automaticly must itself be in non-commercial. -for the allowed non-commercial use it should be 100% free, so derative works, redistributing (modfied) versions and (modified) source should all be allowed. And maybe: -the license should explicitly state, that a license for commercial use can be had by contacting (and paying) the copyright holder. Regards, Hans From sundaram at fedoraproject.org Sun Feb 26 08:26:16 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 26 Feb 2006 13:56:16 +0530 Subject: Not for commercial use licenses / seperate repo? (was Re: angband license) In-Reply-To: <4401689B.6060708@hhs.nl> References: <440146B8.60209@kobold.org> <440148A7.2010807@fedoraproject.org> <4401689B.6060708@hhs.nl> Message-ID: <44016628.3070404@fedoraproject.org> Hi > > Now I'm no fan of non-free software, but IMHO opinion I think it is > fair if people give something away for free including source et all > that they disallow commercial use. > > So I would like to propose creating a not for commercial use repo > under the fedora umbrella. Currently Fedora is 100% Free and open source. Such repositories IMO would dilute that. If it needs to be done, coordinate and do it but not within the Fedora umbrella. My 2 cents. -- Rahul From bugzilla at redhat.com Sun Feb 26 08:37:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 03:37:59 -0500 Subject: [Bug 182941] Review Request: nessus-core Network vulnerability scanner In-Reply-To: Message-ID: <200602260837.k1Q8bxJp029861@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: nessus-core Network vulnerability scanner https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182941 ------- Additional Comments From andreas.bierfert at lowlatency.de 2006-02-26 03:37 EST ------- libICE is part of xorg and part of Fedora Core (this spec is for rawhide and thus BR libICE-devel only because of modular X) For the rest: http://fedora.lowlatency.de/review/nessus-core.spec http://fedora.lowlatency.de/review/nessus-core-2.2.6-2.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 11:07:39 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 06:07:39 -0500 Subject: [Bug 182415] Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project In-Reply-To: Message-ID: <200602261107.k1QB7dhO002753@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182415 ------- Additional Comments From andy at smile.org.ua 2006-02-26 06:07 EST ------- 1. Naming for this package derived from man-pages-$LANG. I think the more convenient to use man-pages-uk instead of smth. else. I see also "Addon packages" from package naming guidelines. And I consider proposed name building similar to "Addon package (locales)". I should like to hear RH people about this. 3. Do I need to patch original Makefile? INSTALLPATH here is a author's variable. 4. Sure, epoch is my local requirement (I'll droped it in spec). Some words about release. This project does not have svn/cvs, but wiki page with last changes. Author of package builds tarball with %date. As package guidelines describes I need to put this date in release. May be I am wrong. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From dragoran at feuerpokemon.de Sun Feb 26 11:47:26 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 26 Feb 2006 12:47:26 +0100 Subject: fc4/5 wine-0.9.8 Message-ID: <4401954E.1000502@feuerpokemon.de> wine 0.9.8 was build for fc3 but not for fc4/fc5 (maybe because buildsys was broken) but now it works and it is still at 0.9.7 From bugzilla at redhat.com Sun Feb 26 12:47:00 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 07:47:00 -0500 Subject: [Bug 181068] Review Request: html401-dtds - HTML 4.01 document type definitions In-Reply-To: Message-ID: <200602261247.k1QCl0Td018772@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: html401-dtds - HTML 4.01 document type definitions https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181068 ------- Additional Comments From link at pobox.com 2006-02-26 07:46 EST ------- Hmmm. * html401-dtds-4.01 seems odd. W3C specs have a Version (4.01) and each edition of that version get tagged with the Date of publication (19991224). "html-dtd-4.01-19991224" or "dtd-html-4.01-19991224" seem like saner naming and versioning conventions. Dunno what that'd be in RPM spec terms though. * In any case, the rec version (4.01) should in either he package name xor the package version; a directory named "html401-dtds-4.01" just seems odd. Other than that this looks good; I'd say push it as is if there isn't an easy way to fix the versioning scheme nits. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From j.w.r.degoede at hhs.nl Sun Feb 26 13:13:48 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 26 Feb 2006 14:13:48 +0100 Subject: Not for commercial use licenses / seperate repo? (was Re: angband license) In-Reply-To: <44016628.3070404@fedoraproject.org> References: <440146B8.60209@kobold.org> <440148A7.2010807@fedoraproject.org> <4401689B.6060708@hhs.nl> <44016628.3070404@fedoraproject.org> Message-ID: <4401A98C.9070701@hhs.nl> Rahul Sundaram wrote: > Hi > >> >> Now I'm no fan of non-free software, but IMHO opinion I think it is >> fair if people give something away for free including source et all >> that they disallow commercial use. >> >> So I would like to propose creating a not for commercial use repo >> under the fedora umbrella. > > Currently Fedora is 100% Free and open source. Such repositories IMO > would dilute that. If it needs to be done, coordinate and do it but not > within the Fedora umbrella. My 2 cents. > Setting up a proper repo takes lots of effort, if it can legally be done within Fedora then all that effort could be put somewhere better. We've even had discussions about allowing this kinda software into extras afaik we're still waiting for a response from legal. Greg you were talking to legal about this back then, did they give an answer if not why not? Don't get me wrong I'm not advocating putting this into extras, but I think it should be doable under the Fedora umbrella. Regards, Hans From nman64 at n-man.com Sun Feb 26 13:11:19 2006 From: nman64 at n-man.com (Patrick Barnes) Date: Sun, 26 Feb 2006 07:11:19 -0600 Subject: Not for commercial use licenses / seperate repo? (was Re: angband license) In-Reply-To: <4401A98C.9070701@hhs.nl> References: <440146B8.60209@kobold.org> <44016628.3070404@fedoraproject.org> <4401A98C.9070701@hhs.nl> Message-ID: <200602260711.22503.nman64@n-man.com> On Sunday 26 February 2006 07:13, Hans de Goede wrote: > Rahul Sundaram wrote: > > Hi > > > >> Now I'm no fan of non-free software, but IMHO opinion I think it is > >> fair if people give something away for free including source et all > >> that they disallow commercial use. > >> > >> So I would like to propose creating a not for commercial use repo > >> under the fedora umbrella. > > > > Currently Fedora is 100% Free and open source. Such repositories IMO > > would dilute that. If it needs to be done, coordinate and do it but not > > within the Fedora umbrella. My 2 cents. > > Setting up a proper repo takes lots of effort, if it can legally be done > within Fedora then all that effort could be put somewhere better. > > We've even had discussions about allowing this kinda software into > extras afaik we're still waiting for a response from legal. Greg you > were talking to legal about this back then, did they give an answer if > not why not? > > Don't get me wrong I'm not advocating putting this into extras, but I > think it should be doable under the Fedora umbrella. > > Regards, > > Hans Personally, I don't care if it *can* be done. AFAIK, there's no legal reason we couldn't, but I don't think we *should* do it. It goes against the stated goals of the project, and it does so without good reason. A repository of such software would fail many of the requirements we currently place on Core and Extras - requirements that we place for good reason. That aside, it would take a great deal of effort to do this under the Fedora umbrella, even if it were possible and allowed. We already have our hands full with the Core and Extras repositories, and there's no reason to add to the workload with a repository of questionable merit. I say we continue as we are, following the goals that we have already set, and leave non-free or otherwise limited software to third-parties with a vested interest. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From bugzilla at redhat.com Sun Feb 26 13:45:26 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 08:45:26 -0500 Subject: [Bug 181068] Review Request: html401-dtds - HTML 4.01 document type definitions In-Reply-To: Message-ID: <200602261345.k1QDjQTx027687@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: html401-dtds - HTML 4.01 document type definitions https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181068 ------- Additional Comments From ville.skytta at iki.fi 2006-02-26 08:45 EST ------- 401 needs to be in the package's name in order to make rpm and friends not consider eg. the 4.01 DTDs an upgrade over let's say 3.2 DTDs, but to keep them cleanly parallel installable. The package's version number is intentionally "duplicated" so that it'll be kept unchanged between package (and possibly spec) revisions so that the documentation dir stays the same between possible package revisions for /usr/share/doc/html401-dtds-$version/index.html bookmarkability; I don't want to invent another version number. This also follows the practice of the existing xhtml1-dtds package. Including the date stamp to the package's release field should be no problem, will do before requesting the first build unless there are other things that require changing. -dtds vs -dtd: there are already xhtml1-dtds and docbook-dtds, I don't see a reason to deviate from that. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 14:09:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 09:09:13 -0500 Subject: [Bug 182941] Review Request: nessus-core Network vulnerability scanner In-Reply-To: Message-ID: <200602261409.k1QE9Dxk031268@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: nessus-core Network vulnerability scanner https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182941 ------- Additional Comments From imlinux at gmail.com 2006-02-26 09:09 EST ------- -changelog version number is wrapped on next line, put it on the same line as the date -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 14:40:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 09:40:50 -0500 Subject: [Bug 182941] Review Request: nessus-core Network vulnerability scanner In-Reply-To: Message-ID: <200602261440.k1QEeo1G004191@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: nessus-core Network vulnerability scanner https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182941 ------- Additional Comments From bugs.michael at gmx.net 2006-02-26 09:40 EST ------- Mike, that is not a MUST. Andreas' full name and e-mail is so long, he prefers wrapping the line to reduce its width. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 15:11:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 10:11:44 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602261511.k1QFBiRD008794@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From tibbs at math.uh.edu 2006-02-26 10:11 EST ------- Why am I not surprised that you would second guess another of my reviews. Frankly, I understand your trepidation but unless you're willing to provide a reasonable workaround I will still approve this package. I don't think that overriding dependency generation for a dozen dependent packages is reasonable. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 15:18:39 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 10:18:39 -0500 Subject: [Bug 176855] Review Request: python-cpio: A Python module for accessing cpio archives In-Reply-To: Message-ID: <200602261518.k1QFIdiK009887@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: python-cpio: A Python module for accessing cpio archives https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176855 imlinux at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |imlinux at gmail.com ------- Additional Comments From imlinux at gmail.com 2006-02-26 10:18 EST ------- -RPM name is OK -Source python-cpio-0.1.tar.bz2 is the same as upstream (which I see is you) -rpmlint of python-cpio looks fine, no output -File list of python-cpio looks OK -License matches -Builds fine in mock and FC-4 - Encoding should be UTF-8 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 26 15:21:39 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 10:21:39 -0500 Subject: [Bug 182941] Review Request: nessus-core Network vulnerability scanner In-Reply-To: Message-ID: <200602261521.k1QFLdMj010513@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: nessus-core Network vulnerability scanner https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182941 ------- Additional Comments From imlinux at gmail.com 2006-02-26 10:21 EST ------- Even with the version and name its still less than 80 characters long, I'll move that to should. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 16:44:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 11:44:49 -0500 Subject: [Bug 177580] Review Request: lat (LDAP Administration Tool) In-Reply-To: Message-ID: <200602261644.k1QGin5K024074@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: lat (LDAP Administration Tool) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177580 ------- Additional Comments From jpmahowald at gmail.com 2006-02-26 11:44 EST ------- Didn't build on rawhide. checking for GTKSHARP... configure: error: Package requirements (gtk-sharp-2.0 >= 2.4 gnome-sharp-2.0 >= 2.4 gconf-sharp-2.0 >= 2.4 glade-sharp-2.0 >= 2.4) were not met: No package 'gtk-sharp-2.0' found No package 'gnome-sharp-2.0' found No package 'gconf-sharp-2.0' found No package 'glade-sharp-2.0' found Seems like you really mean gtk-sharp2 for the (Build)Requires. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From fedora at leemhuis.info Sun Feb 26 17:12:20 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 26 Feb 2006 18:12:20 +0100 Subject: dia orphaned Message-ID: <1140973941.18127.51.camel@localhost.localdomain> Hi all, just FYI, dia in Fedora Extras is now officially orphaned -- is was dropped from Core and later imported to Extras by its old maintainer Caolan McNamara, but never had a official maintainer in Extras. CU thl -- Thorsten Leemhuis From buc at odusz.so-cdu.ru Sun Feb 26 17:21:02 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Sun, 26 Feb 2006 20:21:02 +0300 Subject: php-extras: Can anyone finish the review? Message-ID: <4401E37E.5040709@odu.neva.ru> There is "php-extras" package, too long time pending in the review stage. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170131 At least 3 persons tried to make the review, but then have disappeared without any essential remarks. The package itself seems to be useful, as it adds, for example, such FE-based modules as php-mcrypt and php-tidy. This package is downloaded often enough from its current location, that can vote for its demand. Perhaps I can't understand some simple things?.. Can anyone help? Thanks in advance, Dmitry Butskoy From bugzilla at redhat.com Sun Feb 26 17:33:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 12:33:20 -0500 Subject: [Bug 177881] Review Request: lucidlife In-Reply-To: Message-ID: <200602261733.k1QHXKQJ030987@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: lucidlife https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177881 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gdk at redhat.com |jpmahowald at gmail.com OtherBugsDependingO|163776, 177841 |163779 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-26 12:33 EST ------- I concur with Brian in comment 5. The only other thing I could see was that there were both a lucidlife and a lucidlife-0.9 dir in the docs dir. If that's too confusing a symlink might fix it up. Not a blocker though. APPROVED. I'll sponsor when you apply for cvsextras. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From buildsys at fedoraproject.org Sun Feb 26 17:46:09 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 26 Feb 2006 12:46:09 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060226174609.82D8F7FD0@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 1 openal-0.0.9-0.3.20060226cvs.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun Feb 26 17:46:17 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 26 Feb 2006 12:46:17 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060226174617.EF00D7FD0@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 4 fedora-rpmdevtools-1.5-1.fc4 hddtemp-0.3-0.8.beta14.fc4 lablgl-1.02-4.fc4 openal-0.0.9-0.3.20060226cvs.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun Feb 26 17:46:45 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 26 Feb 2006 12:46:45 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060226174645.E8CE37FD0@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 6 fedora-rpmdevtools-1.5-1.fc5 hddtemp-0.3-0.8.beta14.fc5 koffice-1.4.90-4.fc5 lablgl-1.02-6.fc5 openal-0.0.9-0.4.20060226cvs.fc5 t1lib-5.1.0-6.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugzilla at redhat.com Sun Feb 26 17:43:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 12:43:52 -0500 Subject: [Bug 180066] Request: Inclusion of a ruby template file In-Reply-To: Message-ID: <200602261743.k1QHhqTo032760@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Request: Inclusion of a ruby template file https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180066 ville.skytta at iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |ERRATA Fixed In Version| |1.5-1 ------- Additional Comments From ville.skytta at iki.fi 2006-02-26 12:43 EST ------- Included in 1.5-1. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 26 17:58:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 12:58:59 -0500 Subject: [Bug 177881] Review Request: lucidlife In-Reply-To: Message-ID: <200602261758.k1QHwxn5002531@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: lucidlife https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177881 ------- Additional Comments From admin at ramshacklestudios.com 2006-02-26 12:58 EST ------- Thanks, John. :) I've just submitted my CLA and have applied for membership to cvsextras. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 26 18:00:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 13:00:21 -0500 Subject: [Bug 176582] Review Request: freedt -- Reimplementation of Dan Bernstein's daemontools under the GNU GPL In-Reply-To: Message-ID: <200602261800.k1QI0LJF002759@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: freedt -- Reimplementation of Dan Bernstein's daemontools under the GNU GPL https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176582 ------- Additional Comments From enrico.scholz at informatik.tu-chemnitz.de 2006-02-26 13:00 EST ------- 1. linking dynamically creates significantly larger binaries (>50%); e.g. building with default settings and with '--without dietlibc' creates binaries with the following sizes (bytes): diet glibc glibc/diet anonidentd 6732 11572 171% argv0 6580 10304 156% dumblog 8636 11784 136% envdir 7448 11288 151% envuidgid 8624 10752 124% mkservice 1286 1286 100% ratelimit 8400 13288 158% recordio 34 34 100% setlock 7112 11372 159% setuidgid 8852 11160 126% softlimit 7440 11696 157% supervise 8628 14436 167% svc 6828 11572 169% svok 5964 10432 174% svscan 8632 13200 152% svstat 6356 11248 176% -------------------------------------------- 107552 165424 153% 2. linking dynamically slows down some programs significantly. To measure the time, I used http://ensc.de/freedt/rep.c http://ensc.de/freedt/nop.S and executed sequences like | for i in `seq 0 4`; do | for F in diet glibc; do | echo $F/$i; | ( time ~/tmp/rep 100000 @@@CMD@@@ ) &>res.argv0.$F.$i; | done; | done which starts '@@@CMD@@@' 100000 times. This resulted into the following times: argv0 (@@@CMD@@@ = 'argv0.$F /tmp/nop foo') diet glibc glibc/diet real: 15.964s 52.879s 331% user: 0.136s 3.557s 2615% sys: 5.396s 14.604s 270% envuid (@@@CMD@@@ = 'envuid.$F bin /tmp/nop') diet glibc glibc/diet real: 25.500s 83.016s 325% user: 1.722s 6.920s 401% sys: 6.965s 20.451s 293% 3. the security aspects of dynamic linking are not interesting for the freedt programs: * argv0, envdir, envuidgid, setuidgid, softlimit are pure command wrappers; they are not suid and you can not gain additional rights with an exploit * anonidentd: this server imports the following symbols from the libc: - getpid, write, setgroups, setgid, chdir, fcntl, exit, setuid, read, chroot these are pure syscall wrappers which are implemented correctly and can not be exploited - sleep simple wrapper around nanosleep(2); can not be exploited - strchr, strncmp, strcat, strcpy, memcpy, memchr, memmove trivial memory operations which are implemented correctly by dietlibc and can not be exploited - getenv * lib/getenv.c implementation is correct * optimized i386/getenv.S implementation is correct * read environment will be set by calling process and can not be influenced by client-input - malloc, free, realloc * code (incl. comments) is 202 lines and reviewable; it takes care about integer-overflows, and the handling of internal hunk lists is correct. Underlying algorithms are simple, possible inputs are limited so based upon my review these functions are unexploitable - getopt * complicated, unreviewed code. But input can not be influenced by client-input so its usage within anonidentd is unexploitable * dumplog: input reading is the only, potential exploitable code; there only the following functions will be used from libc - read, malloc, free, realloc, memcpy: see above; these functions are implemented correctly * ratelimit: ditto to 'dumplog' * setlock: just an 'fcntl' wrapper; not suid and you could not gain additionals rights with an exploit * supervise: only user input is coming from a fifo which reads a single char. This is evaluated in a 'switch {}' statement without using a libc function * svc, svok, svstat: not suid, you can not gain additional rights with it * svscan: - uses opendir, readdir, closedir: <20 lines of code; could not detect something suspicious while reviewing them; only assumption is that MAP_ANON zeros the mmap'ed memory which is true on linux platforms 4. this statement is not proved with numbers for this case, but memory consumption of dietlibc programs is significantly lower than with traditional glibc SUMMARY: linking 'freedt' against dietlibc generates significantly smaller and faster binaries without lowering security. Therefore, it would be an error to use glibc in this case. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 26 18:01:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 13:01:34 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602261801.k1QI1Yq5003025@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From fedora at soeterbroek.com 2006-02-26 13:01 EST ------- Spec Name or Url: http://www.soeterbroek.com/linux/fedora/extras/heartbeat/heartbeat.spec SRPM Name or Url: http://www.soeterbroek.com/linux/fedora/extras/heartbeat/heartbeat-2.0.3-6.src.rpm * Sat Feb 25 2006 Joost Soeterbroek - 2.0.3-6 - fixed number of rpmlint warnings and errors - generate 'predictable' uid and gid with fedora-usermgmt to use with configure flag -with-ccmuser-id and groupadd, useradd - added Buildreq's: libtool-ltdl-devel, fedora-usermgmt-setup net-snmp-devel, bzip2-devel - removed *.so duplication in heartbeat and heartbeat-devel - changed file sections Builds in mock. There are still some libtool and rpmlint errors and warnings that I am not sure about what do do with.. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 18:02:01 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 13:02:01 -0500 Subject: [Bug 179439] Review Request: linux-libertine-fonts - TrueType serif fonts In-Reply-To: Message-ID: <200602261802.k1QI21jh003152@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: linux-libertine-fonts - TrueType serif fonts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179439 kevin at tummy.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778, 177841 |163779 nThis| | ------- Additional Comments From kevin at tummy.com 2006-02-26 13:01 EST ------- Sorry for the delay in getting back to you on this... It seems that no-one has a strong opinion on the naming of font packages. (At least according to this thread on the list: https://www.redhat.com/archives/fedora-extras-list/2006-February/msg00986.html ) The name seems fine to me. I ran a mock build and some testing on the package from comment #11, and it all looks good. So, this package is APPROVED. I see you were just sponsored, but if you have any questions or problems, feel free to drop me an email. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From fedora at leemhuis.info Sun Feb 26 18:22:26 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 26 Feb 2006 19:22:26 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1140541669.2144.30.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> Message-ID: <1140978146.18127.112.camel@localhost.localdomain> Hi all! Replies to fedora-extras-list please to avoid confusion. Small update: 366 arch packages still need a rebuild. The following 43 maintainers didn't rebuild a single package since the rebuild was announced: aaron.bennett_AT_olin.edu ad+rh-bugzilla_AT_uni-x.org aportal_AT_univ-montp2.fr bojan_AT_rexursive.com ch.nolte_AT_fh-wolfenbuettel.de chris_AT_chrisgrau.com chrisw_AT_redhat.com colin_AT_fedoraproject.org danken_AT_cs.technion.ac.il davidhart_AT_tqmcube.com davidz_AT_redhat.com denis_AT_poolshark.org dwmw2_AT_redhat.com endur_AT_bennewitz.com fredrik_AT_dolda2000.com grenier_AT_cgsecurity.org jcarpenter_AT_condell.org jdennis_AT_redhat.com jeff_AT_ultimateevil.org jeff.gilchrist_AT_gmail.com jnovy_AT_redhat.com joost_AT_cnoc.nl jylitalo_AT_iki.fi llch_AT_redhat.com luya256_AT_yahoo.com matt_AT_truch.net mccann0011_AT_hotmail.com meme_AT_daughtersoftiresias.org michel.salim_AT_gmail.com mihai_AT_xcyb.org nhorman_AT_redhat.com nos_AT_utelsystems.com oliver.andrich_AT_gmail.com otaylor_AT_redhat.com pawsa_AT_theochem.kth.se petersen_AT_redhat.com pvrabec_AT_redhat.com roland_AT_redhat.com ryo-dairiki_AT_users.sourceforge.net tagoh_AT_redhat.com thomas_AT_apestaart.org toniw_AT_iki.fi tripwire-devel_AT_genesis-x.nildram.co.uk Site note: - 12 of those 43 maintainers have a redhat.com address ;-) - 2 of those 43 are FESCo members. - those 43 own 110 packages in total Okay, let's be fair. Let's say 8 of them are on holiday and didn't read about the rebuild yet. But what about the other 35? Vanished? Lost interest in fedora-extras? Or do they route mail from fedora-maintainers to /dev/null? Or did they unsubscribe from the list (iirc it is mandatory to be subscribed to fedora-maintainers if you maintain a package in extras. Or am I wrong here?). Okay, let's look at the whole situation from a different perspective. The following list shows maintainers that still have to rebuild more than 5 packages: 54 matthias_AT_rpmforge.net 36 tcallawa_AT_redhat.com 35 rdieter_AT_math.unl.edu 28 extras-orphan_AT_fedoraproject.org 13 thomas_AT_apestaart.org 12 denis_AT_poolshark.org 11 anvil_AT_livna.org 11 adrian_AT_lisas.de 9 tagoh_AT_redhat.com 7 gemi_AT_bluewin.ch 7 andreas.bierfert_AT_lowlatency.de 6 ghenry_AT_suretecsystems.com 6 andreas_AT_bawue.net 5 petersen_AT_redhat.com 5 orion_AT_cora.nwra.com 5 nos_AT_utelsystems.com 5 jcarpenter_AT_condell.org 5 green_AT_redhat.com Site notes: - there might be good reasons to be in the list if you have a lot of packages that don't build yet with gcc 4.1. Okay, then let's look at the whole situation from a different perspective again. Any packages in the repo that still have fc4 in the name? That would be really confusing for everybody IMHO. Ohh, yeah, we have: anvil_AT_livna.org libsamplerate 0.1.2-3.fc4 anvil_AT_livna.org libsndfile 1.0.11-3.fc4 gijs_AT_gewis.nl python-cherrytemplate 1.0.0-2.fc4 ivazquez_AT_ivazquez.net python-HTMLgen 2.2.2-7.fc4 jdennis_AT_redhat.com cyrus-imapd 2.2.12-6.fc4 jpo_AT_di.uminho.pt pdfjam 1.20-3.fc4 jpo_AT_di.uminho.pt perl-Test-Builder-Tester 1.01-4.fc4 matthias_AT_rpmforge.net rrdtool 1.0.49-5.fc4 rdieter_AT_math.unl.edu Macaulay2 0.9.2-17.fc4 tcallawa_AT_redhat.com scalapack 1.7-7.fc4 wtogami_AT_redhat.com pyzor 0.4.0-9.fc4 /me is really disappointed by all these results. Disclaimer: Maybe I or the scripts I wrote did an error here and there. If that's the case I'm very sorry and must apologize. Okay, let's face it. The "rebuild by maintainer solution" that was agreed upon in FESCo did not work very well up to this point. Actually I suspected that in the beginning, but I had hoped that it would work at least a bit better. But the result is quite interesting. But that's a different story. So, how to proceed? Bug the maintainers with a E-Mail directly? Probably a good idea. I'll try to write a script that does this. But we have not much time until FC5 is shipped. Do we simply want to ignore that a lot of packages were not rebuild until then? Or do we want to let a script rebuild the rest of the packages? More important: How do we find out if these 43 people are still Fedora Extras maintainers? I'm sure a majority of them will show up in time. But I suspect that at least some of them are vanished and their packages are orphaned in fact -- we need to know that sooner or later, otherwise Fedora Extras results in a mess over time (site note: there are probably also some noarch packages where the maintainer is vanished, But we don't request a rebuild of those, so we don't). And I suspect that some others from those 43 maintainers probably should face that they have a lot of other, more important work to do and should probably orphan their packages so that other interested people can take them over. Suggestions how to solve this whole mess in the short and in the long term welcome. Anyway, here a complete list of packages that still need a rebuild. It is also in the wiki now at http://www.fedoraproject.org/wiki/Extras/FC5Status If there is a good reason why the package is not yet rebuild please add a short note to the page. tia aaron.bennett_AT_olin.edu ifplugd 0.24-6 ad+rh-bugzilla_AT_uni-x.org pam_abl 0.2.2-2.fc5 adrian_AT_lisas.de kover 2.9.6-4 adrian_AT_lisas.de libcdio 0.76-1.fc5 adrian_AT_lisas.de most 4.10.2-2.fc5 adrian_AT_lisas.de nexuiz 1.2.1-3.fc5 adrian_AT_lisas.de ninja 1.5.8.1-2 adrian_AT_lisas.de sopwith 1.7.1-2 adrian_AT_lisas.de source-highlight 2.2-1.fc5 adrian_AT_lisas.de tin 1.6.2-4 adrian_AT_lisas.de uudeview 0.5.20-4 adrian_AT_lisas.de vnstat 1.4-5 adrian_AT_lisas.de xdesktopwaves 1.3-4 a.kurtz_AT_hardsun.net libdaemon 0.6-6 andreas_AT_bawue.net barcode 0.98-8.fc5 andreas_AT_bawue.net commoncpp2 1.3.23-1.fc5 andreas_AT_bawue.net ddrescue 1.10-2 andreas_AT_bawue.net mod_suphp 0.6.1-1.fc5 andreas_AT_bawue.net perl-Crypt-Blowfish 2.09-2.fc5 andreas_AT_bawue.net scmxx 0.8.2-1.fc5 andreas.bierfert_AT_lowlatency.de fbdesk 1.2.1-2 andreas.bierfert_AT_lowlatency.de fluxbox 0.9.14-1.fc5 andreas.bierfert_AT_lowlatency.de orange 0.3-0.cvs20051118.fc5.1 andreas.bierfert_AT_lowlatency.de synce 0.9.1-6.fc5 andreas.bierfert_AT_lowlatency.de synce-gnomevfs 0.9.0-2.fc5 andreas.bierfert_AT_lowlatency.de synce-software-manager 0.9.0-4.fc5 andreas.bierfert_AT_lowlatency.de synce-trayicon 0.9.0-5.fc5 anvil_AT_livna.org aalib 1.4.0-0.rc5.7 anvil_AT_livna.org bin2iso 1.9-2.b anvil_AT_livna.org imlib2 1.2.1-5.fc5 anvil_AT_livna.org irssi 0.8.10-3.fc5 anvil_AT_livna.org libcddb 1.2.1-1.fc5 anvil_AT_livna.org libebml 0.7.6-1.fc5 anvil_AT_livna.org libmatroska 0.8.0-1.fc5 anvil_AT_livna.org libsamplerate 0.1.2-3.fc4 anvil_AT_livna.org libsndfile 1.0.11-3.fc4 anvil_AT_livna.org libtar 1.2.11-5 anvil_AT_livna.org lzo 1.08-5.fc5 aportal_AT_univ-montp2.fr gpsim 0.21.11-1.fc5 aportal_AT_univ-montp2.fr gputils 0.13.3-1.fc5 aportal_AT_univ-montp2.fr gtk+extra 2.1.1-1.fc5 bdpepple_AT_ameritech.net gnomebaker 0.5.1-2.fc5 bdpepple_AT_ameritech.net tagtool 0.12.2-4.fc5 bojan_AT_rexursive.com libapreq2 2.07-1.fc5 bugs.michael_AT_gmx.net abicheck 1.2-9 bugs.michael_AT_gmx.net aide 0.10-2 ch.nolte_AT_fh-wolfenbuettel.de kbibtex 0.1.3-3.fc5 chris_AT_chrisgrau.com frotz 2.43-3.fc5 chris_AT_chrisgrau.com ifm 5.1-2.fc5 chris_AT_chrisgrau.com perl-Time-Piece 1.08-2.fc5 chrisw_AT_redhat.com git-core 0.99.9a-2.fc5 colin_AT_fedoraproject.org adns 1.1-5 colin_AT_fedoraproject.org gaim-guifications 2.12-2.fc5 colin_AT_fedoraproject.org MagicPoint 1.11b-2.fc5 colin_AT_fedoraproject.org python-adns 1.1.0-1 danken_AT_cs.technion.ac.il bidiv 1.5-2.fc5 danken_AT_cs.technion.ac.il hspell 0.9-6 danken_AT_cs.technion.ac.il taarich 1.20051120-3.fc5 davidhart_AT_tqmcube.com leafnode 1.9.53-3 davidz_AT_redhat.com NetworkManager-vpnc 0.5.0-1 denis_AT_poolshark.org galeon 2.0.0-2.fc5 denis_AT_poolshark.org gconfmm26 2.12.0-2 denis_AT_poolshark.org glibmm24 2.8.3-1 denis_AT_poolshark.org gnome-vfsmm26 2.12.0-1 denis_AT_poolshark.org gtkmm24 2.8.1-1 denis_AT_poolshark.org inkscape 0.43-1.fc5 denis_AT_poolshark.org libglademm24 2.6.1-2 denis_AT_poolshark.org libgnomecanvasmm26 2.12.0-2 denis_AT_poolshark.org libgnomemm26 2.12.1-1 denis_AT_poolshark.org libgnomeuimm26 2.12.0-2 denis_AT_poolshark.org libsigc++ 1.2.5-8 denis_AT_poolshark.org libsigc++20 2.0.16-2 dwmw2_AT_redhat.com exim 4.60-2.fc5 dwmw2_AT_redhat.com hfsplusutils 1.0.4-5 endur_AT_bennewitz.com streamtuner 0.99.99-11.fc5 enrico.scholz_AT_informatik.tu-chemnitz.de libtasn1 0.2.6-3 enrico.scholz_AT_informatik.tu-chemnitz.de util-vserver 0.30.210-1.fc5 extras-orphan_AT_fedoraproject.org abe 1.0-5 extras-orphan_AT_fedoraproject.org arc 5.21o-1.fc5 extras-orphan_AT_fedoraproject.org at-poke 0.2.2-2 extras-orphan_AT_fedoraproject.org camstream 0.26.3-8 extras-orphan_AT_fedoraproject.org cgoban 1.9.14-4 extras-orphan_AT_fedoraproject.org cksfv 1.3-4 extras-orphan_AT_fedoraproject.org duplicity 0.4.1-4 extras-orphan_AT_fedoraproject.org freedroidrpg 0.9.13-1.fc5 extras-orphan_AT_fedoraproject.org gnofract4d 2.6-3 extras-orphan_AT_fedoraproject.org gnome-telnet 2.5-5 extras-orphan_AT_fedoraproject.org gnugo 3.6-3 extras-orphan_AT_fedoraproject.org gurlchecker 0.6.3-5 extras-orphan_AT_fedoraproject.org libzvt 2.0.1-7 extras-orphan_AT_fedoraproject.org lua 5.0.2-5.fc5 extras-orphan_AT_fedoraproject.org manedit 0.5.11-5 extras-orphan_AT_fedoraproject.org mknbi 1.4.4-2 extras-orphan_AT_fedoraproject.org netdiag 2.4-7 extras-orphan_AT_fedoraproject.org nget 0.27.1-4 extras-orphan_AT_fedoraproject.org ots 0.4.2-7 extras-orphan_AT_fedoraproject.org parchive 1.1-4 extras-orphan_AT_fedoraproject.org prozilla 1.3.7.4-2.fc5 extras-orphan_AT_fedoraproject.org putty 0.58-1 extras-orphan_AT_fedoraproject.org sirius 0.8.0-5 extras-orphan_AT_fedoraproject.org tdl 1.5.2-3 extras-orphan_AT_fedoraproject.org tetex-lgrind 3.67-9.fc5 extras-orphan_AT_fedoraproject.org wbxml2 0.9.0-4 extras-orphan_AT_fedoraproject.org xmms-cdread 0.14-6.a extras-orphan_AT_fedoraproject.org xtide 2.8-4 fredrik_AT_dolda2000.com icmpdn 0.3-2 gemi_AT_bluewin.ch audacity 1.2.3-5 gemi_AT_bluewin.ch bigloo 2.7a-2.fc5 gemi_AT_bluewin.ch erlang R10B-8.3.fc5 gemi_AT_bluewin.ch lablgl 1.02-2.fc5 gemi_AT_bluewin.ch lablgtk 2.6.0-2.fc5 gemi_AT_bluewin.ch TeXmacs 1.0.5.12-2.fc5 gemi_AT_bluewin.ch unison 2.13.16-1.fc5 ghenry_AT_suretecsystems.com html-xml-utils 3.7-3.fc5 ghenry_AT_suretecsystems.com john 1.6-4 ghenry_AT_suretecsystems.com librsync 0.9.7-4 ghenry_AT_suretecsystems.com perl-Gnome2-Canvas 1.002-4.fc5 ghenry_AT_suretecsystems.com perl-Gtk2-GladeXML 1.005-4.fc5 ghenry_AT_suretecsystems.com perl-Imager 0.45-2.fc5 green_AT_redhat.com itext 1.3-1jpp_6.fc5 green_AT_redhat.com jakarta-commons-cli 1.0-6jpp_5.fc5 green_AT_redhat.com jogl 1.1.1-13.fc5 green_AT_redhat.com kawa 1.8-3.fc5 green_AT_redhat.com rssowl 1.2-10.fc5 grenier_AT_cgsecurity.org testdisk 6.2-3.fc5 i_AT_stingr.net pyflowtools 0.3-5.fc5 ivazquez_AT_ivazquez.net lock-keys-applet 1.0-9 ivazquez_AT_ivazquez.net sqlite2 2.8.16-2.fc5 jamatos_AT_fc.up.pt R-mAr 1.1-3.fc5 jcarpenter_AT_condell.org ks3switch 0.1-1.fc5 jcarpenter_AT_condell.org lrmi 0.9-2.fc5 jcarpenter_AT_condell.org s3switch 0.0-6.20020912 jcarpenter_AT_condell.org tpb 0.6.4-2.fc5 jcarpenter_AT_condell.org xosd 2.2.14-4.fc5 jdennis_AT_redhat.com cyrus-imapd 2.2.12-6.fc4 jeff_AT_ultimateevil.org up-imapproxy 1.2.4-4.fc5 jeff_AT_ultimateevil.org zile 2.2.4-2.fc5 jeff.gilchrist_AT_gmail.com pbzip2 0.9.5-1.fc5 jfontain_AT_free.fr blt 2.4-11.z jfontain_AT_free.fr tktable 2.9-2 jnovy_AT_redhat.com allegro 4.2.0-7 jnovy_AT_redhat.com cproto 4.7d-2 jnovy_AT_redhat.com nedit 5.5-6 joost_AT_cnoc.nl fpc 2.0.2-3.fc5 jpo_AT_di.uminho.pt libol 0.3.16-2.fc5 jpo_AT_di.uminho.pt perl-DBD-SQLite 1.11-1.fc5 jpo_AT_di.uminho.pt perl-Net-SSLeay 1.30-2.fc5 jspaleta_AT_gmail.com istanbul 0.1.1-5 jylitalo_AT_iki.fi python-imaging 1.1.4-9 jylitalo_AT_iki.fi xplanet 1.0.1-7 lemenkov_AT_newmail.ru chmlib 0.37.4-4.fc5 lemenkov_AT_newmail.ru fuse-encfs 1.2.5-1.fc5 lemenkov_AT_newmail.ru rlog 1.3.7-1.fc5 lemenkov_AT_newmail.ru wavpack 4.31-1.fc5 llch_AT_redhat.com libtabe 0.2.6-14 llch_AT_redhat.com xcin 2.5.3.pre3-27 lmacken_AT_redhat.com valknut 0.3.7-5.fc5 luya256_AT_yahoo.com gdesklets 0.35.3-2.fc5 matt_AT_truch.net cfitsio 3.005-0.1.beta.fc5 matt_AT_truch.net hpic 0.52-5.fc5 mattdm_AT_mattdm.org wxPythonGTK2 2.4.2.4-7 matthias_AT_rpmforge.net advancecomp 1.15-3.fc5 matthias_AT_rpmforge.net bbkeys 0.9.0-3.fc5 matthias_AT_rpmforge.net blackbox 0.70.1-3.fc5 matthias_AT_rpmforge.net boa 0.94.14-0.3.rc21.fc5 matthias_AT_rpmforge.net camE 1.9-5.fc5 matthias_AT_rpmforge.net csmash 0.6.6-11.fc5 matthias_AT_rpmforge.net d4x 2.5.6-1.fc5 matthias_AT_rpmforge.net diradmin 1.7.1-3.fc5 matthias_AT_rpmforge.net djvulibre 3.5.15-2.fc5 matthias_AT_rpmforge.net easytag 1.1-2.fc5 matthias_AT_rpmforge.net fillets-ng 0.7.3-2.fc5 matthias_AT_rpmforge.net gcombust 0.1.55-7 matthias_AT_rpmforge.net gentoo 0.11.55-2.fc5 matthias_AT_rpmforge.net giblib 1.2.4-5.fc5 matthias_AT_rpmforge.net gkrellm-aclock 0.3.3-3.fc5 matthias_AT_rpmforge.net gkrellm-freq 1.0-1.fc5 matthias_AT_rpmforge.net Gtk-Perl 0.7008-39.fc5 matthias_AT_rpmforge.net gtktalog 1.0.4-6.fc5 matthias_AT_rpmforge.net gtweakui 0.4.0-1.fc5 matthias_AT_rpmforge.net hackedbox 0.8.4-5.fc5 matthias_AT_rpmforge.net hercules 3.02-3 matthias_AT_rpmforge.net i8kutils 1.25-5.fc5 matthias_AT_rpmforge.net js 1.5-3.fc5 matthias_AT_rpmforge.net kannel 1.4.0-7.fc5 matthias_AT_rpmforge.net libcaca 0.9-9.fc5 matthias_AT_rpmforge.net liboil 0.3.6-1.fc5 matthias_AT_rpmforge.net lighttpd 1.4.10-1.fc5 matthias_AT_rpmforge.net linux_logo 4.13-1.fc5 matthias_AT_rpmforge.net lmarbles 1.0.7-4 matthias_AT_rpmforge.net metakit 2.4.9.5-1.fc5 matthias_AT_rpmforge.net ncftp 3.1.9-2.fc5 matthias_AT_rpmforge.net oidentd 2.0.7-8.fc5 matthias_AT_rpmforge.net p7zip 4.30-2.fc5 matthias_AT_rpmforge.net php-eaccelerator 5.0.4_0.9.3-3.fc5 matthias_AT_rpmforge.net php-pecl-mailparse 2.1.1-2.fc5 matthias_AT_rpmforge.net php-pecl-pdo 1.0.2-1.fc5 matthias_AT_rpmforge.net php-pecl-pdo-sqlite 0.3-3.fc5 matthias_AT_rpmforge.net plib16 1.6.0-4.fc5 matthias_AT_rpmforge.net plib 1.8.4-2.fc5 matthias_AT_rpmforge.net portaudio 18.1-6.fc5 matthias_AT_rpmforge.net powermanga 0.79-7.fc5 matthias_AT_rpmforge.net proftpd 1.3.0-0.1.rc3.fc5 matthias_AT_rpmforge.net rrdtool 1.0.49-5.fc4 matthias_AT_rpmforge.net SDL_gfx 2.0.13-3.fc5 matthias_AT_rpmforge.net starfighter 1.1-6.fc5 matthias_AT_rpmforge.net synergy 1.2.7-1.fc5 matthias_AT_rpmforge.net thttpd 2.25b-9.fc5 matthias_AT_rpmforge.net torcs 1.2.4-1.fc5 matthias_AT_rpmforge.net ucarp 1.1-4.fc5 matthias_AT_rpmforge.net udftools 1.0.0b3-4.fc5 matthias_AT_rpmforge.net viruskiller 0.9-6.fc5 matthias_AT_rpmforge.net xvattr 1.3-8.fc5 matthias_AT_rpmforge.net yasm 0.4.0-5.fc5 matthias_AT_rpmforge.net zziplib 0.13.45-1.fc5 mccann0011_AT_hotmail.com geos 2.2.1-3.fc5 mccann0011_AT_hotmail.com proj 4.4.9-1.fc5 meme_AT_daughtersoftiresias.org nethack-vultures 1.11.2-4.fc5 mfleming+rpm_AT_enlartenment.com mlmmj 1.2.11-2.fc5 mfleming+rpm_AT_enlartenment.com mod_security 1.9.2-2.fc5 michel.salim_AT_gmail.com gai 0.5.10-5.fc5 michel.salim_AT_gmail.com gai-pal 0.7-7 michel.salim_AT_gmail.com grhino 0.15.0-3.fc5 michel.salim_AT_gmail.com quarry 0.1.16-1.fc5 mihai_AT_xcyb.org htb-util 0.2.4-0.4.pre1 nhorman_AT_redhat.com iozone 3-1 nos_AT_utelsystems.com dillo 0.8.4-3 nos_AT_utelsystems.com gktools 0.9.1-3 nos_AT_utelsystems.com gtkterm 0.99.4-4 nos_AT_utelsystems.com neverball 1.4.0-4 nos_AT_utelsystems.com whowatch 1.6.0-1 oliver.andrich_AT_gmail.com ruby-mysql 2.7-6.fc5 oliver_AT_linux-kernel.at fish 1.12.0-1.fc5 oliver_AT_linux-kernel.at libdnet 1.10-2.fc5 orion_AT_cora.nwra.com kompose 0.5.3-4.fc5 orion_AT_cora.nwra.com perl-Net-IP-CMatch 0.02-2.fc5 orion_AT_cora.nwra.com perl-Net-Patricia 1.014-1.fc5 orion_AT_cora.nwra.com python-basemap 0.7.2.1-1.fc5 orion_AT_cora.nwra.com python-matplotlib 0.86-1.fc5 otaylor_AT_redhat.com libuninameslist 0.0-4.040707 paul_AT_xtdnet.nl fetchlog 1.0-2.fc5 paul_AT_xtdnet.nl l2tpd 0.69-0.2.20051030.fc5 pawsa_AT_theochem.kth.se balsa 2.3.10-1.fc5 pawsa_AT_theochem.kth.se libesmtp 1.0.3r1-7.fc5 pertusus_AT_free.fr libdap 3.5.3-2.fc5 pertusus_AT_free.fr libnc-dap 3.5.2-5.fc5 petersen_AT_redhat.com darcs 1.0.5-1.fc5 petersen_AT_redhat.com FreeWnn 1.10pl020-6.fc5 petersen_AT_redhat.com ghc 6.4.1-2.fc5 petersen_AT_redhat.com haddock 0.7-1.fc5 petersen_AT_redhat.com scim-fcitx 3.1.1-3.fc5 pvrabec_AT_redhat.com licq 1.3.2-4 rc040203_AT_freenet.de lib3ds 1.2.0-6.fc5 rc040203_AT_freenet.de SIMVoleon 2.0.1-2.fc5 rdieter_AT_math.unl.edu akode 2.0-1.fc5 rdieter_AT_math.unl.edu apollon 1.0.1-4.fc5.1 rdieter_AT_math.unl.edu dxpc 3.8.2-3.fc5.1 rdieter_AT_math.unl.edu factory 2.0.5-6 rdieter_AT_math.unl.edu gc 6.6-5.fc5 rdieter_AT_math.unl.edu geomview 1.8.2-0.2.cvs20040221.fc5.2 rdieter_AT_math.unl.edu gift 0.11.8.1-4.fc5.1 rdieter_AT_math.unl.edu gift-openft 0.2.1.6-2.fc5.1 rdieter_AT_math.unl.edu gpa 0.7.0-4 rdieter_AT_math.unl.edu gpgme 1.1.0-3.fc5.1 rdieter_AT_math.unl.edu gsview 4.7-5.fc5.1 rdieter_AT_math.unl.edu gtk-qt-engine 0.60-7.fc5.1 rdieter_AT_math.unl.edu jasper 1.701.0-9.fc5.1 rdieter_AT_math.unl.edu kasablanca 0.4.0.2-7.fc5.2 rdieter_AT_math.unl.edu kdocker 1.3-4.fc5.3 rdieter_AT_math.unl.edu kickpim 0.5.3-9.fc5.2 rdieter_AT_math.unl.edu kile 1.8.1-7.fc5.1 rdieter_AT_math.unl.edu kimdaba 2.1-6.fc5.1 rdieter_AT_math.unl.edu kiosktool 1.0-5.fc5.1 rdieter_AT_math.unl.edu kipi-plugins 0.1.0-0.2.rc1.fc5 rdieter_AT_math.unl.edu kxdocker 0.39-3.fc5.1 rdieter_AT_math.unl.edu libassuan 0.6.10-2.fc5.1 rdieter_AT_math.unl.edu libfac 2.0.5-3 rdieter_AT_math.unl.edu libksba 0.9.13-2.fc5.1 rdieter_AT_math.unl.edu libsigsegv 2.2-1.fc5.1 rdieter_AT_math.unl.edu libtunepimp 0.4.0-5.fc5.1 rdieter_AT_math.unl.edu lyx 1.3.6-3.fc5 rdieter_AT_math.unl.edu Macaulay2 0.9.2-17.fc4 rdieter_AT_math.unl.edu maxima 5.9.2-9.fc5 rdieter_AT_math.unl.edu openslp 1.2.1-4.fc5.1 rdieter_AT_math.unl.edu pinentry 0.7.2-1.fc5.1 rdieter_AT_math.unl.edu sbcl 0.9.9-1.fc5.2 rdieter_AT_math.unl.edu tidy 0.99.0-9.20051025.fc5.1 rdieter_AT_math.unl.edu uw-imap 2004g-4.fc5.1 rdieter_AT_math.unl.edu xforms 1.0.90-6.fc5.1 redhat_AT_flyn.org pam_mount 0.9.25-4 roland_AT_redhat.com monotone 0.25-2.fc5 rolandd_AT_cisco.com libmthca 1.0-0.3.rc5.fc5 ryo-dairiki_AT_users.sourceforge.net scim-input-pad 0.1.1-3.fc5 ryo-dairiki_AT_users.sourceforge.net scim-skk 0.5.2-3.fc5 ryo-dairiki_AT_users.sourceforge.net scim-tomoe 0.1.0-3.fc5 ryo-dairiki_AT_users.sourceforge.net tomoe 0.2.1-3.fc5 shahms_AT_shahms.com python-psycopg 1.1.21-1.fc5 skvidal_AT_phy.duke.edu mock 0.4-5.fc5 steve_AT_silug.org perl-DateTime 0.2901-2.fc5 steve_AT_silug.org tuxpaint 0.9.13-3 tagoh_AT_redhat.com Canna 3.7p3-14.fc5 tagoh_AT_redhat.com kakasi 2.3.4-20 tagoh_AT_redhat.com kinput2 v3.1-26.fc5 tagoh_AT_redhat.com mew 4.2-1 tagoh_AT_redhat.com namazu 2.0.14-3 tagoh_AT_redhat.com paps 0.6.3-1.fc5 tagoh_AT_redhat.com perl-Text-Kakasi 2.04-1 tagoh_AT_redhat.com uim 1.0.1-1.fc5 tagoh_AT_redhat.com w3m-el 1.4.4-1 tcallawa_AT_redhat.com alsamixergui 0.9.0-0.2.rc1.fc5 tcallawa_AT_redhat.com blacs 1.1-18.fc5 tcallawa_AT_redhat.com c-ares 1.3.0-1.fc5 tcallawa_AT_redhat.com check 0.9.3-3.fc5 tcallawa_AT_redhat.com comical 0.7-1.fc5 tcallawa_AT_redhat.com compat-wxGTK 2.4.2-16.fc5 tcallawa_AT_redhat.com gambas 1.0.13-2.fc5 tcallawa_AT_redhat.com gxemul 0.3.7-1.fc5 tcallawa_AT_redhat.com jam 2.5-2.fc5 tcallawa_AT_redhat.com lapack 3.0-36.fc5 tcallawa_AT_redhat.com libgdamm 1.3.7-2.fc5 tcallawa_AT_redhat.com libmcrypt 2.5.7-2.fc5 tcallawa_AT_redhat.com librx 1.5-5 tcallawa_AT_redhat.com lincity-ng 1.0.2-2.fc5 tcallawa_AT_redhat.com logjam 4.5.1-5.fc5 tcallawa_AT_redhat.com mcrypt 2.6.4-1.fc5 tcallawa_AT_redhat.com mfstools 2.0-8.snapshot050221.fc5 tcallawa_AT_redhat.com netgo 0.5-3.fc5 tcallawa_AT_redhat.com perl-Clone 0.18-2.fc5 tcallawa_AT_redhat.com perl-DBD-SQLite2 0.33-4.fc5 tcallawa_AT_redhat.com perl-Template-Toolkit 2.14-5.fc5 tcallawa_AT_redhat.com perl-version 0.51-3.fc5 tcallawa_AT_redhat.com physfs 1.0.1-2.fc5 tcallawa_AT_redhat.com QuantLib 0.3.11-3.fc5 tcallawa_AT_redhat.com R 2.2.1-3.fc5 tcallawa_AT_redhat.com rekall 2.2.4-8.fc5 tcallawa_AT_redhat.com R-gnomeGUI 2.1.0-4 tcallawa_AT_redhat.com rocksndiamonds 3.1.1-2.fc5 tcallawa_AT_redhat.com rootsh 1.5.2-2.fc5 tcallawa_AT_redhat.com scalapack 1.7-7.fc4 tcallawa_AT_redhat.com udunits 1.12.4-9.fc5 tcallawa_AT_redhat.com wlassistant 0.5.4a-3.fc5 tcallawa_AT_redhat.com xbase 2.0.0-3.fc5 tcallawa_AT_redhat.com xbsql 0.11-5.fc5 tcallawa_AT_redhat.com xkeycaps 2.46-3.fc5 tcallawa_AT_redhat.com xsupplicant 1.2.2-7.fc5 thomas_AT_apestaart.org directfb 0.9.24-4.fc5 thomas_AT_apestaart.org flumotion 0.1.8-1 thomas_AT_apestaart.org gstreamer08-python 0.8.3-1.fc5 thomas_AT_apestaart.org gstreamer-python 0.10.2-1.fc5 thomas_AT_apestaart.org Hermes 1.3.3-7 thomas_AT_apestaart.org ladspa 1.12-5 thomas_AT_apestaart.org libannodex 0.7.2-1.fc5 thomas_AT_apestaart.org libcmml 0.9.0-2.fc5 thomas_AT_apestaart.org liboggz 0.9.3-2.fc5 thomas_AT_apestaart.org libshout 1.0.9-4 thomas_AT_apestaart.org mach 0.4.8-1.fc5 thomas_AT_apestaart.org mod_annodex 0.2.2-2.fc5 thomas_AT_apestaart.org python-twisted 1.3.0-4 toniw_AT_iki.fi silky 0.5.4-1 tripwire-devel_AT_genesis-x.nildram.co.uk tripwire 2.3.1-22 ville.skytta_AT_iki.fi hddtemp 0.3-0.7.beta14.fc5 ville.skytta_AT_iki.fi xemacs 21.4.18-2.fc5 wtogami_AT_redhat.com bonnie++ 1.03a-4 wtogami_AT_redhat.com lvcool 1.0.0-3 wtogami_AT_redhat.com perl-Digest-Nilsimsa 0.06-5 wtogami_AT_redhat.com perl-Razor-Agent 2.77-2.fc5 -- Thorsten Leemhuis From bugzilla at redhat.com Sun Feb 26 18:21:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 13:21:15 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602261821.k1QILFjJ005846@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From tibbs at math.uh.edu 2006-02-26 13:21 EST ------- I will add that it looks to me as if the base Fedora Perl package does the same thing. And it makes sense: a package does "use mixin 'something'", so it needs the package that supplies perl(mixin), which happens to be Spiffy. Only RPM's automatic dependency generation doesn't understand that Spiffy provides perl(mixin), so we have to instruct it. I suppose the dependency generator doesn't understand because the Spiffy module doesn't have a file named "mixin.pm", nor does it have a "package mixin" statement. It's pretty esoteric code that looks like it inserts things into the symbol table. So I think it's perfectly reasonable to have this package provide perl(mixin), because in reality it does provide perl(mixin). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 18:26:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 13:26:53 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602261826.k1QIQr9P006844@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From dennis at ausil.us 2006-02-26 13:26 EST ------- build fails as you left the done in there i said you needed to remove previously. build failed on x86_64 also couldnt find qt. you need to add export QTLIB=${QTDIR}/lib QTINC=${QTDIR}/include to the build section. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From jwboyer at jdub.homelinux.org Sun Feb 26 17:35:57 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 26 Feb 2006 12:35:57 -0500 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1140978146.18127.112.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> Message-ID: <1140975357.32357.20.camel@yoda.jdub.homelinux.org> On Sun, 2006-02-26 at 19:22 +0100, Thorsten Leemhuis wrote: > Hi all! > > Replies to fedora-extras-list please to avoid confusion. > > Small update: > > Anyway, here a complete list of packages that still need a rebuild. It > is also in the wiki now at > http://www.fedoraproject.org/wiki/Extras/FC5Status > > > If there is a good reason why the package is not yet rebuild please add > a short note to the page. tia > chrisw_AT_redhat.com git-core 0.99.9a-2.fc5 Erm.. I think your script is slightly broken. git-core has been rebuilt quite a bit because upstream releases a new version about once a week :) [jwboyer at yoda ~]$ rpm -q git-core git-core-1.2.2-1.fc5 [jwboyer at yoda ~]$ On a side note, I've been debugging a build error for tla on PPC. It looks like it might be a glibc problem at the moment related to the recent ABI change. If it is, it may required another respin of core. I'm not quite sure about that yet, since Jakub hasn't had a chance to look at the bug. Just an FYI. josh From bugzilla at redhat.com Sun Feb 26 18:34:03 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 13:34:03 -0500 Subject: [Bug 182175] Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) In-Reply-To: Message-ID: <200602261834.k1QIY3dr008115@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182175 ------- Additional Comments From terjeros at phys.ntnu.no 2006-02-26 13:34 EST ------- New updated files available: Spec: http://web.phys.ntnu.no/~terjeros/eterm/libast.spec SRPM: http://web.phys.ntnu.no/~terjeros/eterm/libast-0.7-3.src.rpm Most problems should be fixed. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 18:34:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 13:34:47 -0500 Subject: [Bug 173368] Review Request: planetplanet In-Reply-To: Message-ID: <200602261834.k1QIYkre008328@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: planetplanet https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173368 ------- Additional Comments From kevin at tummy.com 2006-02-26 13:34 EST ------- 1. ok. 2. ok. I have checked the md5sum's and they match up fine. I see 1.0 still isn't out yet. They did push out a test 1.0 tar/zip file, but that was only a test release, not something you would want to base a package on. I ran a mockbuild and some testing on the packages in comment #8 and everything looks good, so this package is APPROVED. I will be happy to sponsor you. You should move forward from the "Get a Fedora Account" section of the http://fedoraproject.org/wiki/Extras/Contributors page. If you have any questions at all, feel free to drop me an email. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 26 18:48:41 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 13:48:41 -0500 Subject: [Bug 177818] Review Request: adplug In-Reply-To: Message-ID: <200602261848.k1QImfnX010372@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: adplug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177818 ------- Additional Comments From triad at df.lth.se 2006-02-26 13:48 EST ------- Aha! So when something is in the GNU standard but not the FHS, which one should win in the Fedora world...? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From fedora at leemhuis.info Sun Feb 26 18:54:08 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 26 Feb 2006 19:54:08 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1140975357.32357.20.camel@yoda.jdub.homelinux.org> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <1140975357.32357.20.camel@yoda.jdub.homelinux.org> Message-ID: <1140980049.18825.1.camel@localhost.localdomain> Am Sonntag, den 26.02.2006, 12:35 -0500 schrieb Josh Boyer: > On Sun, 2006-02-26 at 19:22 +0100, Thorsten Leemhuis wrote: > > Hi all! > > > > Replies to fedora-extras-list please to avoid confusion. > > > > Small update: > > > > Anyway, here a complete list of packages that still need a rebuild. It > > is also in the wiki now at > > http://www.fedoraproject.org/wiki/Extras/FC5Status > > > > > > If there is a good reason why the package is not yet rebuild please add > > a short note to the page. tia > > > chrisw_AT_redhat.com git-core 0.99.9a-2.fc5 > > Erm.. I think your script is slightly broken. git-core has been rebuilt > quite a bit because upstream releases a new version about once a week :) > > [jwboyer at yoda ~]$ rpm -q git-core > git-core-1.2.2-1.fc5 > [jwboyer at yoda ~]$ Yep, it didn't catch this one because it was renamed -- git-core is still at http://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/git-core-0.99.9a-2.fc5.src.rpm and the script does not check that it is obsoleted by http://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/git-1.2.3-1.fc5.src.rpm git-core-*.fc5.src.rpm probably should be removed. It not only confuses my script, it is also useless afaics -- correct me if I'm wrong. BTW, the latest version of the script attached. -- Thorsten Leemhuis -------------- next part -------------- A non-text attachment was scrubbed... Name: buildcheck Type: application/x-shellscript Size: 1906 bytes Desc: not available URL: From paul at all-the-johnsons.co.uk Sun Feb 26 18:54:23 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Sun, 26 Feb 2006 18:54:23 +0000 Subject: dia orphaned In-Reply-To: <1140973941.18127.51.camel@localhost.localdomain> References: <1140973941.18127.51.camel@localhost.localdomain> Message-ID: <1140980064.12922.54.camel@T7.Linux> Hi, > just FYI, dia in Fedora Extras is now officially orphaned -- is was > dropped from Core and later imported to Extras by its old maintainer > Caolan McNamara, but never had a official maintainer in Extras. I quite like dia - if no one has any problems, I'll take a look at it tonight and see about giving it a new home. TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show From pertusus at free.fr Sun Feb 26 19:10:10 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 26 Feb 2006 20:10:10 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1140978146.18127.112.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> Message-ID: <20060226191010.GA2961@free.fr> > interest in fedora-extras? Or do they route mail from fedora-maintainers > to /dev/null? Or did they unsubscribe from the list (iirc it is > mandatory to be subscribed to fedora-maintainers if you maintain a > package in extras. Or am I wrong here?). I haven't seen such a thing. It isn't even advertised in the wiki (if my search in the wiki isn't wrong). I personaly think that fedora-extras-list and fedora-maintainers should be merged (and bugzilla reviews should go to another list to keep traffic on fedora-extras-list low). But I guess this has allready been talked about previously... (and I'm gonna subscribe to fedora-maintainers). -- Pat From gauret at free.fr Sun Feb 26 19:21:17 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 26 Feb 2006 20:21:17 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> Message-ID: Hi Thorsten. Thanks for those status reports. > So, how to proceed? Bug the maintainers with a E-Mail directly? Probably > a good idea. I'll try to write a script that does this. This is the best idea at the moment IMHO. Those people may read the lists through an NNTP gateway, and have reasons not to fire up their news client (not the habit, too much work, etc...). But then, you might say, will they have time to rebuild their packages ? Anyway, a direct mail reminder will probably help a lot. > But we have not much time until FC5 is shipped. Do we simply want to > ignore that a lot of packages were not rebuild until then? Or do we want > to let a script rebuild the rest of the packages? About 3/4 of my packages rebuilt correctly on FC5 IIRC, so that still leaves a lot of work to have packages build with gcc4.1, updated libs, etc... Maybe have the script rebuild a maintainer's packages if he hasn't answered the direct mail by Wednesday ? > More important: How do we find out if these 43 people are still Fedora > Extras maintainers? The direct mail will help there too. > And I suspect that some others from those 43 maintainers probably should > face that they have a lot of other, more important work to do and should > probably orphan their packages so that other interested people can take > them over. Maybe automatically orphan the packages if they are not rebuilt for the 6th of Mars ? (date of "Absolute devel freeze") ? That leaves 9 days to rebuild them and fix the problems. Maybe it's too short, it depends on how many packages fail to rebuild automatically. We'll see. Ah, and they need to find new maintainers quickly :( If no one steps up I can help rebuilding them for FC5, so we'll be able to wait after FC5 is released to find new maintainers. > Suggestions how to solve this whole mess in the short and in the long > term welcome. Having not-rebuilt packages being automatically orphaned on test3 of each FC release seems like a decent long-term solution to me. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Never trust a computer you can't throw out a window." -- Steve Wozniak From gemi at bluewin.ch Sun Feb 26 19:24:50 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Sun, 26 Feb 2006 20:24:50 +0100 Subject: OpenAL 0.0.9 problems Message-ID: <1140981890.23109.4.camel@scriabin.tannenrauch.ch> The OpenAL 0.0.9-0.2.20060204cvs.fc4 update causes several problems: 1. Dependents such as blender and scorched3d require libopenal.so.0 Of course these have to be rebuilt by their maintainers, but how can one avoid deinstalling them to do a clean yum update? 2. There are other non-RPMed programs like X-Plane that use libopenal.so.0. In addition these suffer from the separation of libalut, i.e., I had to set LD_PRELOAD to start it. I suggest creating an openal0 package for an older version (that also include alut). So other programs will continue to work, and dependents don't need to be installed before an update is available. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From bugs.michael at gmx.net Sun Feb 26 19:46:55 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 26 Feb 2006 14:46:55 -0500 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-02-26 Message-ID: <200602261946.k1QJktXa020728@mx1.redhat.com> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- dap-server-cgi 3.5.3-1.fc3.1.i386 Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- dap-server-cgi 3.5.3-1.fc3.1.x86_64 ---------------------------------------------------------------------- New report for: pertusus AT free.fr package: dap-server-cgi - 3.5.3-1.fc3.1.i386 from fedora-extras-3-i386 unresolved deps: dap-hdf_handler From bugs.michael at gmx.net Sun Feb 26 19:47:08 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 26 Feb 2006 14:47:08 -0500 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-02-26 Message-ID: <200602261947.k1QJl8Xo020783@mx1.redhat.com> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- dap-server 3.5.3-1.fc4.1.i386 dap-server-cgi 3.5.3-1.fc4.1.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- dap-server 3.5.3-1.fc4.1.ppc dap-server-cgi 3.5.3-1.fc4.1.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- dap-server 3.5.3-1.fc4.1.x86_64 dap-server-cgi 3.5.3-1.fc4.1.x86_64 ---------------------------------------------------------------------- New report for: pertusus AT free.fr package: dap-server-cgi - 3.5.3-1.fc4.1.i386 from fedora-extras-4-i386 unresolved deps: perl(DODS_Dispatch) perl(DODS_Cache) dap-hdf_handler From bugs.michael at gmx.net Sun Feb 26 19:47:26 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 26 Feb 2006 14:47:26 -0500 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-02-26 Message-ID: <200602261947.k1QJlQfK020872@mx1.redhat.com> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- at-poke 0.2.2-2.i386 cyrus-imapd 2.2.12-6.fc4.i386 cyrus-imapd-murder 2.2.12-6.fc4.i386 cyrus-imapd-nntp 2.2.12-6.fc4.i386 cyrus-imapd-utils 2.2.12-6.fc4.i386 gnomebaker 0.5.1-2.fc5.i386 gstreamer08-python 0.8.3-1.fc5.i386 istanbul 0.1.1-5.i386 libgdamm 1.3.7-2.fc5.i386 pam_mount 0.9.25-4.i386 perl-Cyrus 2.2.12-6.fc4.i386 sabayon-admin 2.12.1-2.i386 scalapack 1.7-7.fc4.i386 soundconverter 0.8.3-1.fc5.noarch tidy-devel 0.99.0-8.20051025.fc5.i386 tripwire 2.3.1-22.i386 up-imapproxy 1.2.4-4.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- at-poke 0.2.2-2.ppc cyrus-imapd 2.2.12-6.fc4.ppc cyrus-imapd-murder 2.2.12-6.fc4.ppc cyrus-imapd-nntp 2.2.12-6.fc4.ppc cyrus-imapd-utils 2.2.12-6.fc4.ppc gnomebaker 0.5.1-2.fc5.ppc gstreamer08-python 0.8.3-1.fc5.ppc istanbul 0.1.1-5.ppc libgdamm 1.3.7-2.fc5.ppc pam_mount 0.9.25-4.ppc perl-Cyrus 2.2.12-6.fc4.ppc sabayon-admin 2.12.1-2.ppc scalapack 1.7-7.fc4.ppc soundconverter 0.8.3-1.fc5.noarch tidy-devel 0.99.0-8.20051025.fc5.ppc up-imapproxy 1.2.4-4.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- at-poke 0.2.2-2.x86_64 cernlib 2005-7.fc5.x86_64 cernlib-packlib 2005-7.fc5.x86_64 cyrus-imapd 2.2.12-6.fc4.x86_64 cyrus-imapd-murder 2.2.12-6.fc4.x86_64 cyrus-imapd-nntp 2.2.12-6.fc4.x86_64 cyrus-imapd-utils 2.2.12-6.fc4.x86_64 gnomebaker 0.5.1-2.fc5.x86_64 gstreamer08-python 0.8.3-1.fc5.x86_64 istanbul 0.1.1-5.x86_64 libgdamm 1.3.7-2.fc5.x86_64 pam_mount 0.9.25-4.x86_64 paw 2005-7.fc5.x86_64 perl-Cyrus 2.2.12-6.fc4.x86_64 sabayon-admin 2.12.1-2.x86_64 scalapack 1.7-7.fc4.x86_64 soundconverter 0.8.3-1.fc5.noarch tidy-devel 0.99.0-8.20051025.fc5.x86_64 up-imapproxy 1.2.4-4.fc5.x86_64 ---------------------------------------------------------------------- New report for: thomas AT apestaart.org package: gstreamer08-python - 0.8.3-1.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgstinterfaces-0.8.so.0 libgstreamer-0.8.so.1 libgstcontrol-0.8.so.1 libgstplay-0.8.so.0 gstreamer08-plugins >= 0:0.8.5 gstreamer08 >= 0:0.8.7 ---------------------------------------------------------------------- New report for: rdieter AT math.unl.edu package: tidy-devel - 0.99.0-8.20051025.fc5.i386 from fedora-extras-development-i386 unresolved deps: tidy = 0:0.99.0-8.20051025.fc5 ---------------------------------------------------------------------- New report for: bdpepple AT ameritech.net package: gnomebaker - 0.5.1-2.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgstreamer-0.8.so.1 From jwboyer at jdub.homelinux.org Sun Feb 26 18:53:30 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 26 Feb 2006 13:53:30 -0500 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1140980049.18825.1.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <1140975357.32357.20.camel@yoda.jdub.homelinux.org> <1140980049.18825.1.camel@localhost.localdomain> Message-ID: <1140980010.32357.23.camel@yoda.jdub.homelinux.org> On Sun, 2006-02-26 at 19:54 +0100, Thorsten Leemhuis wrote: > Am Sonntag, den 26.02.2006, 12:35 -0500 schrieb Josh Boyer: > > > > > > > > > If there is a good reason why the package is not yet rebuild please add > > > a short note to the page. tia > > > > > chrisw_AT_redhat.com git-core 0.99.9a-2.fc5 > > > > Erm.. I think your script is slightly broken. git-core has been rebuilt > > quite a bit because upstream releases a new version about once a week :) > > > > [jwboyer at yoda ~]$ rpm -q git-core > > git-core-1.2.2-1.fc5 > > [jwboyer at yoda ~]$ > > Yep, it didn't catch this one because it was renamed -- git-core is > still at > http://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/git-core-0.99.9a-2.fc5.src.rpm > and the script does not check that it is obsoleted by > http://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/git-1.2.3-1.fc5.src.rpm > > git-core-*.fc5.src.rpm probably should be removed. It not only confuses > my script, it is also useless afaics -- correct me if I'm wrong. You're correct. I forgot that the package was renamed. The SRPM for the old package should indeed be removed. josh From bugzilla at redhat.com Sun Feb 26 20:01:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 15:01:36 -0500 Subject: [Bug 179439] Review Request: linux-libertine-fonts - TrueType serif fonts In-Reply-To: Message-ID: <200602262001.k1QK1aNh023064@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: linux-libertine-fonts - TrueType serif fonts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179439 ------- Additional Comments From frank at scirocco-5v-turbo.de 2006-02-26 15:01 EST ------- Would you strongly protest, if the name were changed back to linux-libertine-fonts? There's currently an 8:1 of packages named fontname-fonts against fonts-fontname inside Extras. So it may be more consistent at least for Extras. Anyway, thanks for your review, and sorry for not being your first sponsoree...;) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From ivazquez at ivazquez.net Sun Feb 26 20:12:14 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 26 Feb 2006 15:12:14 -0500 Subject: rpms/dap-server/devel dap-server.spec,1.5,1.6 In-Reply-To: <200602262004.k1QK4rr4005382@cvs-int.fedora.redhat.com> References: <200602262004.k1QK4rr4005382@cvs-int.fedora.redhat.com> Message-ID: <1140984734.26628.2.camel@ignacio.lan> On Sun, 2006-02-26 at 15:04 -0500, Patrice Dumas wrote: > Author: pertusus > > Update of /cvs/extras/rpms/dap-server/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv5331/devel > > Modified Files: > dap-server.spec > Log Message: > Provides perl(DODS_Dispatch) perl(DODS_Cache) now that nothing is detected > anymore. Does it *actually* provide these for the system, or do you just need to disable Perl autoreqs? -- 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 bugzilla at redhat.com Sun Feb 26 20:12:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 15:12:59 -0500 Subject: [Bug 177818] Review Request: adplug In-Reply-To: Message-ID: <200602262012.k1QKCxlh024585@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: adplug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177818 ------- Additional Comments From triad at df.lth.se 2006-02-26 15:12 EST ------- Thinking about it, if upstream goes for the GNU standard, what would we do? This package certainly cannot own /com, it's in the freaking root dir! The only reasonable package to own /com would be "filesystem" and the question is if filesystem would include it or only implement FHS stuff. Has anyone ever, ever seen a package use $prefix/com?? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From pertusus at free.fr Sun Feb 26 20:16:46 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 26 Feb 2006 21:16:46 +0100 Subject: rpms/dap-server/devel dap-server.spec,1.5,1.6 In-Reply-To: <1140984734.26628.2.camel@ignacio.lan> References: <200602262004.k1QK4rr4005382@cvs-int.fedora.redhat.com> <1140984734.26628.2.camel@ignacio.lan> Message-ID: <20060226201645.GA2995@free.fr> > Does it *actually* provide these for the system, or do you just need to > disable Perl autoreqs? You're right it doesn't provide this to the system. It should be better to disable Perl autoreqs. -- Pat From bugs.michael at gmx.net Sun Feb 26 20:22:24 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 26 Feb 2006 21:22:24 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1140978146.18127.112.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> Message-ID: <20060226212224.00e5b6fd.bugs.michael@gmx.net> On Sun, 26 Feb 2006 19:22:26 +0100, Thorsten Leemhuis wrote: > Okay, let's look at the whole situation from a different perspective. > The following list shows maintainers that still have to rebuild more > than 5 packages: > 5 nos_AT_utelsystems.com Nils has not signed up since the transition from fedora.us to Fedora Extras. > bugs.michael_AT_gmx.net abicheck 1.2-9 This is a noarch package in disguise, a Perl script. Its build-time tests have given mixed results on different archs several times before. Hence I prefer building it platform-dependent. > bugs.michael_AT_gmx.net aide 0.10-2 > Due to upstream changes in libmhash I've delayed updates here as long as possible. Trouble with flex on x86_64 (bug #183098) still needs further investigation. From ville.skytta at iki.fi Sun Feb 26 20:25:59 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 26 Feb 2006 22:25:59 +0200 Subject: OpenAL 0.0.9 problems In-Reply-To: <1140981890.23109.4.camel@scriabin.tannenrauch.ch> References: <1140981890.23109.4.camel@scriabin.tannenrauch.ch> Message-ID: <1140985559.2990.11.camel@bobcat.mine.nu> On Sun, 2006-02-26 at 20:24 +0100, G?rard Milmeister wrote: > The OpenAL 0.0.9-0.2.20060204cvs.fc4 update causes several problems: > 1. Dependents such as blender and scorched3d require libopenal.so.0 [...] Sigh. https://bugzilla.redhat.com/181989 From j.w.r.degoede at hhs.nl Sun Feb 26 20:43:13 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 26 Feb 2006 21:43:13 +0100 Subject: OpenAL 0.0.9 problems In-Reply-To: <1140981890.23109.4.camel@scriabin.tannenrauch.ch> References: <1140981890.23109.4.camel@scriabin.tannenrauch.ch> Message-ID: <440212E1.5030505@hhs.nl> G?rard Milmeister wrote: > The OpenAL 0.0.9-0.2.20060204cvs.fc4 update causes several problems: > 1. Dependents such as blender and scorched3d require libopenal.so.0 > Of course these have to be rebuilt by their maintainers, but how > can one avoid deinstalling them to do a clean yum update? > 2. There are other non-RPMed programs like X-Plane that use > libopenal.so.0. In addition these suffer from the separation > of libalut, i.e., I had to set LD_PRELOAD to start it. > > I suggest creating an openal0 package for an older version (that > also include alut). So other programs will continue to work, and > dependents don't need to be installed before an update is available. Everyone involved please read: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181989 This is _not_ intended to put shame to Andreas who I know as a great Extras contributer, but to watch and learn! Short story Andreas is using upstream CVS (at upstream's advice) and upstream bumped the .so probably because the plan on changing the abi, thus sticking with CVS is probably a bad idea right now. I'm waiting for a response from Andreas. I just wish to warn everybody this way to not start rebuilding everything against the new openal because in my book, we should revert to the .so.0 version instead of going with an unstable abi .so.1 version Regards, Hans From bugzilla at redhat.com Sun Feb 26 20:40:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 15:40:33 -0500 Subject: [Bug 181013] Review Request: qgit - a GUI browser for local git repositories In-Reply-To: Message-ID: <200602262040.k1QKeXb5029086@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: qgit - a GUI browser for local git repositories https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181013 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-26 15:40 EST ------- Good: - rpmlint clean - package meets naming guidelines - package meets packaging guidelines - license (GPL) OK, text in %doc, matches source - spec file legible, in am. english - source matches upstream - package compiles on devel (x86_64) - no missing BR - no unnecessary BR - no locales - not relocatable - owns all directories that it creates - no duplicate files - permissions ok - %clean ok - macro use consistent - code, not content - no need for -docs - nothing in %doc affects runtime - proper .desktop file - works with a kernel tree The only thing I can think of is that it could use an icon. Something to bug upstream about I suppose. APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From matt at truch.net Sun Feb 26 21:04:58 2006 From: matt at truch.net (Matthew D Truch) Date: Sun, 26 Feb 2006 16:04:58 -0500 Subject: buildsystem on devel unable to run kde-config Message-ID: <20060226210458.GB4879@truch.net> Greetings, I'm having a little trouble building kst (a KDE app) on the devel buildsystem, which builds fine on FC-4 systems. Configure fails with the following error: checking for kde-config... /usr/bin/kde-config /usr/bin/kde-config: error while loading shared libraries: libqt-mt.so.3: cannot open shared object file: No such file or directory configure: error: /usr/bin/kde-config --prefix outputed the non existant prefix '' for kdelibs. This means it has been moved since you installed it. This won't work. Please recompile kdelibs for the new prefix. The full logs are available at: http://buildsys.fedoraproject.org/logs/fedora-development-extras/5288-kst-1.2.0-9.fc5/i386/build.log The shared library kde-config complains about, libqt-mt.so.3, is included in the qt rpm, which mock does claim to have installed. Any help would be greatly appreciated. Thanks. -- "It is now later than it was before." -------------------------- Matthew Truch Department of Physics Brown University matt at truch.net http://matt.truch.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Sun Feb 26 21:20:23 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 26 Feb 2006 22:20:23 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <20060226191010.GA2961@free.fr> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <20060226191010.GA2961@free.fr> Message-ID: <44021B97.7040806@hhs.nl> Patrice Dumas wrote: >> interest in fedora-extras? Or do they route mail from fedora-maintainers >> to /dev/null? Or did they unsubscribe from the list (iirc it is >> mandatory to be subscribed to fedora-maintainers if you maintain a >> package in extras. Or am I wrong here?). > > I haven't seen such a thing. It isn't even advertised in the wiki (if my > search in the wiki isn't wrong). I personaly think that fedora-extras-list > and fedora-maintainers should be merged (and bugzilla reviews should go to > another list to keep traffic on fedora-extras-list low). But I guess this > has allready been talked about previously... (and I'm gonna subscribe to > fedora-maintainers). > + a zillion I almost never (never say never) read the bugzilla generated mails, and I get confused about what to send to maintainers and what to send to extras-list. Regards, Hans From bugzilla at redhat.com Sun Feb 26 21:32:03 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 16:32:03 -0500 Subject: [Bug 182320] Review Request: gnome-build In-Reply-To: Message-ID: <200602262132.k1QLW3c3004405@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-build https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182320 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|bugzilla-sink at leemhuis.info |jpmahowald at gmail.com OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-26 16:32 EST ------- Build failed on devel: No Package Found for anjuta-gdl Upstream source download URL is 404'd. fedora-qa script found: * Missing SMP flags. If it doesn't build with it, please add a comment (wiki: PackagingGuidelines#parallelmake) Minor: * Duplicate BuildRequires: gtk+-devel (by gnome-libs-devel), gnome-libs-devel (by libglade-devel), libxml-devel (by libglade-devel), libglade-devel (by gal-devel), gal-devel (by gtkhtml-devel) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 21:33:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 16:33:20 -0500 Subject: [Bug 182320] Review Request: gnome-build In-Reply-To: Message-ID: <200602262133.k1QLXKml004755@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-build https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182320 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |182319 ------- Additional Comments From jpmahowald at gmail.com 2006-02-26 16:33 EST ------- Should've done bug 182319 first. Making this depend on it. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Sun Feb 26 21:35:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 16:35:08 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602262135.k1QLZ8Im005151@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From rdieter at math.unl.edu 2006-02-26 16:35 EST ------- %changelog * Sun Feb 26 2006 Rex Dieter 6:3.5.1-5 - remove stray 'done' - set QTLIB/QTINC (at least until #169132 is backported to fc4) Spec Name or Url: http://apt.kde-redhat.org/apt/kde-redhat/SPECS/kdemultimedia-extras.spec SRPM Name or Url: http://apt.kde-redhat.org/apt/kde-redhat/all/SRPMS.stable/kdemultimedia-extras-3.5.1-5.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 26 21:47:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 16:47:18 -0500 Subject: [Bug 182319] Review Request: anjuta-gdl In-Reply-To: Message-ID: <200602262147.k1QLlIw0006938@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: anjuta-gdl https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182319 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|bugzilla-sink at leemhuis.info |jpmahowald at gmail.com OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-26 16:47 EST ------- Build failed on rawhide. checking for libxml-2.0 >= 2.2.8... Package libxml-2.0 was not found in the pkg-config search path. Also, the spec has many Requires and no BuildRequires. Really it should be the other way around, with *-devel packages in BuildRequires rpm will figure out the Requires. * Missing SMP flags. If it doesn't build with it, please add a comment (wiki: PackagingGuidelines#parallelmake) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From ivazquez at ivazquez.net Sun Feb 26 21:55:36 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 26 Feb 2006 16:55:36 -0500 Subject: rpms/dap-server/devel dap-server.spec,1.5,1.6 In-Reply-To: <20060226201645.GA2995@free.fr> References: <200602262004.k1QK4rr4005382@cvs-int.fedora.redhat.com> <1140984734.26628.2.camel@ignacio.lan> <20060226201645.GA2995@free.fr> Message-ID: <1140990936.26628.3.camel@ignacio.lan> On Sun, 2006-02-26 at 21:16 +0100, Patrice Dumas wrote: > > Does it *actually* provide these for the system, or do you just need to > > disable Perl autoreqs? > > You're right it doesn't provide this to the system. It should be better > to disable Perl autoreqs. %define __perl_requires %{nil} And don't forget to manually add any that it really does require. -- 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 pertusus at free.fr Sun Feb 26 21:55:35 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 26 Feb 2006 22:55:35 +0100 Subject: rpms/dap-server/devel dap-server.spec,1.5,1.6 In-Reply-To: <20060226201645.GA2995@free.fr> References: <200602262004.k1QK4rr4005382@cvs-int.fedora.redhat.com> <1140984734.26628.2.camel@ignacio.lan> <20060226201645.GA2995@free.fr> Message-ID: <20060226215535.GB2995@free.fr> On Sun, Feb 26, 2006 at 09:16:46PM +0100, Patrice Dumas wrote: > > Does it *actually* provide these for the system, or do you just need to > > disable Perl autoreqs? > > You're right it doesn't provide this to the system. It should be better > to disable Perl autoreqs. Perl autoreqs are perl >= 0:5.004 perl(Carp) perl(DODS_Cache) perl(DODS_Dispatch) perl(Env) perl(Exporter) perl(FilterDirHTML) perl(HTML::Entities) perl(HTML::Filter) perl(HTML::Parser) perl(POSIX) perl(Time::Local) perl(dods_logging) perl(lib) perl(read_config) perl(strict) perl(vars) All the HTML:: should be ignored as it is the old HTML::Parser module, perl(DODS_Cache) perl(DODS_Dispatch) perl(dods_logging) perl(read_config) perl(FilterDirHTML) are 'internal' packages that are provided by the same package, so should be ignored. So should the remaining be explicitely required, like Requires: perl perl(Carp) perl(Env) perl(Exporter) perl(lib) perl(strict) perl(vars) Or should only be perl required, given that all those are part of any recent perl? -- Pat From bugzilla at redhat.com Sun Feb 26 22:44:03 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 17:44:03 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602262244.k1QMi381018181@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 dennis at ausil.us changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |181824 ------- Additional Comments From dennis at ausil.us 2006-02-26 17:43 EST ------- also forgot that we need to either wait to gstreamer08 is approved for extras or everything is ported over to gstreamer 0.10 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 26 22:48:54 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 17:48:54 -0500 Subject: [Bug 176288] Review Request: kdemulimedia-extras In-Reply-To: Message-ID: <200602262248.k1QMmsZY019324@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemulimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 ------- Additional Comments From rdieter at math.unl.edu 2006-02-26 17:48 EST ------- Re: comment #33, that's only relavent for the devel/fc5 branch (And we'll, of course, keep an eye on that). Until gst08 is approved, we can disable gst support. fc4 need not wait. (-: -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 26 23:04:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 18:04:13 -0500 Subject: [Bug 181599] Review Request: gallery: web based photo album software In-Reply-To: Message-ID: <200602262304.k1QN4Djn022650@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gallery: web based photo album software https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 ------- Additional Comments From jwb at redhat.com 2006-02-26 18:04 EST ------- Updated packages to remove chcon in %post, filed RFE for policy change. New packages: SPEC: http://www.berningeronline.net/gallery2.spec SRPM: http://www.berningeronline.net/gallery2-2.0.2-0.9cvs20060223.src.rpm selinux-policy RFE: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183140 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From admin at ramshacklestudios.com Mon Feb 27 01:00:02 2006 From: admin at ramshacklestudios.com (Peter Gordon) Date: Sun, 26 Feb 2006 17:00:02 -0800 Subject: Cannot Enqueue Build Message-ID: <1141002002.3324.30.camel@tuxhugger> Hi, all. I'm working on submitting lucidlife to FE, and I've stumbled on a small problem. After getting APPROVED and sponsored, I've created and checked out a lucidlife CVS and, after fixing a typo, have tagged both a devel and FC-4 release. However, when I run `make build` in either the devel/ or FC-4/ directories of this tree, it returns the following error: make: Entering directory `/home/peter/rpmbuild/cvs/lucidlife/devel' /usr/bin/plague-client build lucidlife lucidlife-0_9-3_fc5 devel Server returned an error: Insufficient privileges. At first glance, I thought that it was due to my not configuring plague-client correctly, but I made sure that I had followed the Extras/BuildSystemClientSetup wiki page, and I still get the same results. I've even redownloaded all three certificate files and placed them in $HOME, accordingly. I've waited a few hours, thinking maybe that my account info needed to propagate or similar, but with the same results. Any advice would be appreciated. Thanks. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xDA3634D7 Fingerprint: 0629 F604 3C14 937E F088 E5E9 B3CB 48EC DA36 34D7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From bugzilla at redhat.com Mon Feb 27 01:45:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 26 Feb 2006 20:45:48 -0500 Subject: [Bug 179439] Review Request: linux-libertine-fonts - TrueType serif fonts In-Reply-To: Message-ID: <200602270145.k1R1jmso017212@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: linux-libertine-fonts - TrueType serif fonts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179439 ------- Additional Comments From kevin at tummy.com 2006-02-26 20:45 EST ------- I think whichever name you prefer is ok in the absence of a hard rule in the naming guidelines. :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From dcbw at redhat.com Mon Feb 27 03:33:08 2006 From: dcbw at redhat.com (Dan Williams) Date: Sun, 26 Feb 2006 22:33:08 -0500 Subject: Cannot Enqueue Build In-Reply-To: <1141002002.3324.30.camel@tuxhugger> References: <1141002002.3324.30.camel@tuxhugger> Message-ID: <1141011189.23695.1.camel@localhost.localdomain> On Sun, 2006-02-26 at 17:00 -0800, Peter Gordon wrote: > Hi, all. > > I'm working on submitting lucidlife to FE, and I've stumbled on a small > problem. After getting APPROVED and sponsored, I've created and checked > out a lucidlife CVS and, after fixing a typo, have tagged both a devel > and FC-4 release. However, when I run `make build` in either the devel/ > or FC-4/ directories of this tree, it returns the following error: > > make: Entering directory `/home/peter/rpmbuild/cvs/lucidlife/devel' > /usr/bin/plague-client build lucidlife lucidlife-0_9-3_fc5 devel > Server returned an error: Insufficient privileges. > > At first glance, I thought that it was due to my not configuring > plague-client correctly, but I made sure that I had followed the > Extras/BuildSystemClientSetup wiki page, and I still get the same > results. I've even redownloaded all three certificate files and placed > them in $HOME, accordingly. > > I've waited a few hours, thinking maybe that my account info needed to > propagate or similar, but with the same results. You do not appear to be in the build server's user database. I'm not exactly sure what the process is to add you (if someone has to do it manually or if there are scripts set up to do so), so I'll have to leave it to others to answer that. Dan From rc040203 at freenet.de Mon Feb 27 04:06:52 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 27 Feb 2006 05:06:52 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <20060226212224.00e5b6fd.bugs.michael@gmx.net> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <20060226212224.00e5b6fd.bugs.michael@gmx.net> Message-ID: <1141013213.14289.399.camel@mccallum.corsepiu.local> On Sun, 2006-02-26 at 21:22 +0100, Michael Schwendt wrote: > On Sun, 26 Feb 2006 19:22:26 +0100, Thorsten Leemhuis wrote: > > > Okay, let's look at the whole situation from a different perspective. > > The following list shows maintainers that still have to rebuild more > > than 5 packages: > > > 5 nos_AT_utelsystems.com > > Nils has not signed up since the transition from fedora.us to Fedora > Extras. => orphan packages? Ralf From fedora at leemhuis.info Mon Feb 27 05:52:23 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 27 Feb 2006 06:52:23 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <44021B97.7040806@hhs.nl> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <20060226191010.GA2961@free.fr> <44021B97.7040806@hhs.nl> Message-ID: <1141019544.808.5.camel@thl.ct.heise.de> Am Sonntag, den 26.02.2006, 22:20 +0100 schrieb Hans de Goede: > > Patrice Dumas wrote: > >> interest in fedora-extras? Or do they route mail from fedora-maintainers > >> to /dev/null? Or did they unsubscribe from the list (iirc it is > >> mandatory to be subscribed to fedora-maintainers if you maintain a > >> package in extras. Or am I wrong here?). > > > > I haven't seen such a thing. It isn't even advertised in the wiki (if my > > search in the wiki isn't wrong). I personaly think that fedora-extras-list > > and fedora-maintainers should be merged (and bugzilla reviews should go to > > another list to keep traffic on fedora-extras-list low). But I guess this > > has allready been talked about previously... (and I'm gonna subscribe to > > fedora-maintainers). > + a zillion I disagree ;-) > I almost never (never say never) read the bugzilla generated mails, and > I get confused about what to send to maintainers and what to send to > extras-list. Read the FESCo-Meeting summary from the last meeting: ---- * separate extras-ml-list for bugzilla spam * We'll probably open fedora-extras-bugzilla-list and fedora-extras-review-list. All contributors should subscribe to -reviews. ---- fedora-extras-review-list -> review bugs fedora-extras-bugzilla-list -> everything else related to Extras fedora-extras-list should remain for general discussions about Fedora Extras. fedora-maintainers should stay for all maintainers (redhat and community) that only want to maintain stuff, but don't what to be involved with all the flamewars ^w discussions on fedora-extras-list. Patrice, Hans, that okay for you? CU thl From fedora at leemhuis.info Mon Feb 27 05:59:05 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 27 Feb 2006 06:59:05 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <20060226212224.00e5b6fd.bugs.michael@gmx.net> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <20060226212224.00e5b6fd.bugs.michael@gmx.net> Message-ID: <1141019945.808.11.camel@thl.ct.heise.de> Am Sonntag, den 26.02.2006, 21:22 +0100 schrieb Michael Schwendt: > On Sun, 26 Feb 2006 19:22:26 +0100, Thorsten Leemhuis wrote: > > > Okay, let's look at the whole situation from a different perspective. > > The following list shows maintainers that still have to rebuild more > > than 5 packages: > > 5 nos_AT_utelsystems.com > Nils has not signed up since the transition from fedora.us to Fedora > Extras. Okay, so they are practically orphaned for at least a year? Wow. So let's orphan them for real. Anyone interested in on of the following packages? dillo, gktools, gtkterm, neverball, whowatch > > bugs.michael_AT_gmx.net abicheck 1.2-9 > This is a noarch package in disguise, a Perl script. Its build-time tests > have given mixed results on different archs several times before. Hence I > prefer building it platform-dependent. > > bugs.michael_AT_gmx.net aide 0.10-2 > Due to upstream changes in libmhash I've delayed updates here as long as > possible. Trouble with flex on x86_64 (bug #183098) still needs further > investigation. Added this informations to where we track it now: http://www.fedoraproject.org/wiki/Extras/FC5Status CU thl From holbrookbw at users.sourceforge.net Mon Feb 27 06:04:15 2006 From: holbrookbw at users.sourceforge.net (Brandon Holbrook) Date: Mon, 27 Feb 2006 00:04:15 -0600 Subject: frustrated newcomers AND orphaned packages (Was: Rebuild status of FE5) In-Reply-To: References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> Message-ID: <4402965F.2070707@users.sourceforge.net> As a very newcomer to the Fedora Extras scene, I feel it's important to put in my .02 as an outsider's perspective on this issue AND the "frustrated by the review process" thread that passed through a few days ago. I have been a RedHat / Fedora SysAdmin for going on 4 years now, have rolled my own RPMs to customize the systems for our environment, and even created my own yum repository as a middle man testing ground before deploying updates-released packages. In my free time I love streaming radio, and have written a few Icecast-compatible applications that turned out to work so well I am trying to make the packages public (instead of hardcoded to my machines) and offer them to the community. Anyway, I feel very confident in my ability to create RPMs, love Fedora and its community, and am passionate about getting my packages as publicly available as I can, so I came to Extras, read through the .spec requirements to submit a package for review, and did just that for php-shout (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181445) almost 2 weeks ago. Unique to my request, however, is that my package requires an upgrade of libshout to at least version 2.0 which was released mid-2003, so doesn't seem like an unreasonable request. libshout, it turns out, is already a package in Extras, owned by Thomas Vander Stichele (thomas at apestaart.org). After a suggestion by Jochen, I submitted a RFE in bugzilla to update libshout to 2.x, or at least create a libshout2 package that I would be more than happy to maintain (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181523). Thomas, however, has yet to comment on the RFE, and apparently according to the Wiki's FC5Status, he has yet to rebuild ANY of his packages for FC5, making his MIA a burden on us all, not just me. This is very frustrating for me, because for the past two weeks I've been ready every day to finally get a project approved and actually be able to contribute to Extras. I would love to be able to adopt libshout from Thomas, or as stated create a libshout2 package if an upgrade would break dependencies. AND we're getting closer and closer to devel freeze for FC5, and I want my package to make it into FE5! I've also been watching the broken packages list, and watch cyrus-imapd go by every time, which is a package I use daily and want to see make it into FE5 because cyrus-imapd is a must before I can upgrade my mail server to FC5. Again, a package I would love to adopt and IMHO feel like I could be a good package maintainer, if only I could get off the ground floor. My point out of all this is that first, I would like to see Extras adopt a "forced adoption" policy (maybe "kidnapping" is a more appropriate term ;) ). SourceForge's policy is that if you feel a project has been abandoned, you can submit a "Project Takeover Request", at which time the SF.net staff sends an email to the package owner telling them of the request, and gives them 2 weeks to respond. If the owner does not respond in those two weeks, your request is approved and you become the project's new owner, supplanting the old owner, and the code is yours to steer wherever you want. Second, I am obviously a +1 for the "auto orphan" policy Aurelien proposed below, but I'd also take it a step further and auto-orphan packages that have RFEs unanswered for x days. I understand that this is next-to-impossible to automate, but if a written policy is at least put in place, then a developer like myself who puts in an RFE that goes unanswered can point back to the policy after x days have expired and request an adoption. I'd love to be able to get started contributing back to the Fedora that has treated me so well over the years... but all my hands are tied! -Brandon Aurelien Bompard wrote: > Hi Thorsten. > > Thanks for those status reports. > > >> So, how to proceed? Bug the maintainers with a E-Mail directly? Probably >> a good idea. I'll try to write a script that does this. >> > > This is the best idea at the moment IMHO. Those people may read the lists > through an NNTP gateway, and have reasons not to fire up their news client > (not the habit, too much work, etc...). > But then, you might say, will they have time to rebuild their packages ? > Anyway, a direct mail reminder will probably help a lot. > > >> But we have not much time until FC5 is shipped. Do we simply want to >> ignore that a lot of packages were not rebuild until then? Or do we want >> to let a script rebuild the rest of the packages? >> > > About 3/4 of my packages rebuilt correctly on FC5 IIRC, so that still leaves > a lot of work to have packages build with gcc4.1, updated libs, etc... > Maybe have the script rebuild a maintainer's packages if he hasn't answered > the direct mail by Wednesday ? > > >> More important: How do we find out if these 43 people are still Fedora >> Extras maintainers? >> > > The direct mail will help there too. > > >> And I suspect that some others from those 43 maintainers probably should >> face that they have a lot of other, more important work to do and should >> probably orphan their packages so that other interested people can take >> them over. >> > > Maybe automatically orphan the packages if they are not rebuilt for the 6th > of Mars ? (date of "Absolute devel freeze") ? That leaves 9 days to rebuild > them and fix the problems. Maybe it's too short, it depends on how many > packages fail to rebuild automatically. We'll see. > Ah, and they need to find new maintainers quickly :( > If no one steps up I can help rebuilding them for FC5, so we'll be able to > wait after FC5 is released to find new maintainers. > > >> Suggestions how to solve this whole mess in the short and in the long >> term welcome. >> > > Having not-rebuilt packages being automatically orphaned on test3 of each FC > release seems like a decent long-term solution to me. > > Aur?lien > From florin at andrei.myip.org Mon Feb 27 06:09:01 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Sun, 26 Feb 2006 22:09:01 -0800 Subject: frustrated newcomers AND orphaned packages (Was: Rebuild status of FE5) In-Reply-To: <4402965F.2070707@users.sourceforge.net> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <4402965F.2070707@users.sourceforge.net> Message-ID: <1141020541.16413.18.camel@rivendell.home.local> On Mon, 2006-02-27 at 00:04 -0600, Brandon Holbrook wrote: > Unique to my request, however, is that my package requires an upgrade of > libshout to at least version 2.0 which was released mid-2003, so doesn't > seem like an unreasonable request. libshout, it turns out, is already a > package in Extras, owned by Thomas Vander Stichele > (thomas at apestaart.org). After a suggestion by Jochen, I submitted a RFE > in bugzilla to update libshout to 2.x, or at least create a libshout2 > package that I would be more than happy to maintain > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181523). Thomas, > however, has yet to comment on the RFE, and apparently according to the > Wiki's FC5Status, he has yet to rebuild ANY of his packages for FC5, > making his MIA a burden on us all, not just me. Deadbeat maintainers should be automatically disowned. No sign of life in X amount of time ==> package becomes orphan automatically. Make it a policy and put an end to debates. Easy. -- Florin Andrei http://florin.myip.org/ From wart at kobold.org Mon Feb 27 06:24:02 2006 From: wart at kobold.org (Wart) Date: Sun, 26 Feb 2006 22:24:02 -0800 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1141019945.808.11.camel@thl.ct.heise.de> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <20060226212224.00e5b6fd.bugs.michael@gmx.net> <1141019945.808.11.camel@thl.ct.heise.de> Message-ID: <44029B02.6080702@kobold.org> Thorsten Leemhuis wrote: > Am Sonntag, den 26.02.2006, 21:22 +0100 schrieb Michael Schwendt: > >>On Sun, 26 Feb 2006 19:22:26 +0100, Thorsten Leemhuis wrote: >> >> >>>Okay, let's look at the whole situation from a different perspective. >>>The following list shows maintainers that still have to rebuild more >>>than 5 packages: >>>5 nos_AT_utelsystems.com >> >>Nils has not signed up since the transition from fedora.us to Fedora >>Extras. > > > Okay, so they are practically orphaned for at least a year? Wow. > > So let's orphan them for real. Anyone interested in on of the following > packages? > > dillo, gktools, gtkterm, neverball, whowatch I can pick up neverball if there are no objections. --Wart From bugzilla at redhat.com Mon Feb 27 06:39:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 01:39:10 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602270639.k1R6dAsX031717@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From rc040203 at freenet.de 2006-02-27 01:39 EST ------- (In reply to comment #8) > I will add that it looks to me as if the base Fedora Perl package does the same > thing. And it makes sense: a package does "use mixin 'something'", so it needs > the package that supplies perl(mixin), perl(mixin) would correspond to mixin.pm. perl-Spiffy doesn't provide this, as can be easily demonstrated: perl -e 'use mixin' => Letting the rpm "Provide: perl(mixin)" is a bug. > So I think it's perfectly reasonable to have this package provide perl(mixin), > because in reality it does provide perl(mixin). Cf. above. it doesn't. It's packages using perl(Spiffy) which apply magic to access the Spiffy::mixin method as "mixin" => It's those applications which have to "Requires: perl(Spiffy)" to get this working. If rpm generates bogus "Requires: perl(mixin)" for those applications, these have to filter them out. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From enrico.scholz at informatik.tu-chemnitz.de Mon Feb 27 06:58:45 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 27 Feb 2006 07:58:45 +0100 Subject: Rebuild status of FE5 In-Reply-To: <1140978146.18127.112.camel@localhost.localdomain> (Thorsten Leemhuis's message of "Sun, 26 Feb 2006 19:22:26 +0100") References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> Message-ID: <873bi5fftm.fsf@kosh.bigo.ensc.de> fedora at leemhuis.info (Thorsten Leemhuis) writes: > enrico.scholz_AT_informatik.tu-chemnitz.de util-vserver 0.30.210-1.fc5 fails with | ... | Error: Missing Dependency: libc.so.6(GLIBC_2.0) is needed by package vconfig | Error: Missing Dependency: libc.so.6 is needed by package vconfig | Cleaning up... | Done. in the x86_64 root for over a week. This broken dep is listed for other archs in the rawhide report but not for x86_64. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 482 bytes Desc: not available URL: From fedora at leemhuis.info Mon Feb 27 07:26:41 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 27 Feb 2006 08:26:41 +0100 Subject: Rebuild status of FE5 In-Reply-To: <873bi5fftm.fsf@kosh.bigo.ensc.de> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <873bi5fftm.fsf@kosh.bigo.ensc.de> Message-ID: <1141025202.808.22.camel@thl.ct.heise.de> Am Montag, den 27.02.2006, 07:58 +0100 schrieb Enrico Scholz: > fedora at leemhuis.info (Thorsten Leemhuis) writes: > > > enrico.scholz_AT_informatik.tu-chemnitz.de util-vserver 0.30.210-1.fc5 > > fails with > > | ... > | Error: Missing Dependency: libc.so.6(GLIBC_2.0) is needed by package vconfig > | Error: Missing Dependency: libc.so.6 is needed by package vconfig > | Cleaning up... > | Done. > > in the x86_64 root for over a week. This broken dep is listed for other > archs in the rawhide report but not for x86_64. Because there is a glibc.i386 in the x86_64 tree so this dep can be satisfied. But *.i386 packages are excluded in the buildsys. Anyway, should be fixed soon -- if not, poke Phil here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182633 CU thl From j.w.r.degoede at hhs.nl Mon Feb 27 08:19:11 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 27 Feb 2006 09:19:11 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1141019544.808.5.camel@thl.ct.heise.de> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <20060226191010.GA2961@free.fr> <44021B97.7040806@hhs.nl> <1141019544.808.5.camel@thl.ct.heise.de> Message-ID: <4402B5FF.7030800@hhs.nl> Thorsten Leemhuis wrote: > Am Sonntag, den 26.02.2006, 22:20 +0100 schrieb Hans de Goede: >> + a zillion > > I disagree ;-) > I know you would :) >> I almost never (never say never) read the bugzilla generated mails, and >> I get confused about what to send to maintainers and what to send to >> extras-list. > > Read the FESCo-Meeting summary from the last meeting: > ---- > * separate extras-ml-list for bugzilla spam > > * We'll probably open fedora-extras-bugzilla-list and > fedora-extras-review-list. All contributors should subscribe to > -reviews. I think 2 bugzilla lists is a great idea, I see you say should subscribe to review-list so its not a must? I'm all for doing my share of reviews, but I just go to the FE-NEW page and click on the oldest ones, as said 99.9% of the time I just delete all bugzilla mail without reading. Now the non review bugzilla mail could be actually interesting for me, and should be (much) lower volume (I hope). > ---- > fedora-extras-review-list -> review bugs > fedora-extras-bugzilla-list -> everything else related to Extras > > fedora-extras-list should remain for general discussions about Fedora > Extras. > > fedora-maintainers should stay for all maintainers (redhat and > community) that only want to maintain stuff, but don't what to be > involved with all the flamewars ^w discussions on fedora-extras-list. > I can see the logic in things, but in practice everything extras related that gets posted to maintainer also gets crossposed to maintainer, now if you stop doing that, assuming that all maintainers are (must be) subscribed to maintainers then thats fine. Regards, Hans From j.w.r.degoede at hhs.nl Mon Feb 27 08:23:20 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 27 Feb 2006 09:23:20 +0100 Subject: frustrated newcomers AND orphaned packages (Was: Rebuild status of FE5) In-Reply-To: <1141020541.16413.18.camel@rivendell.home.local> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <4402965F.2070707@users.sourceforge.net> <1141020541.16413.18.camel@rivendell.home.local> Message-ID: <4402B6F8.8050604@hhs.nl> Florin Andrei wrote: > On Mon, 2006-02-27 at 00:04 -0600, Brandon Holbrook wrote: > >> Unique to my request, however, is that my package requires an upgrade of >> libshout to at least version 2.0 which was released mid-2003, so doesn't >> seem like an unreasonable request. libshout, it turns out, is already a >> package in Extras, owned by Thomas Vander Stichele >> (thomas at apestaart.org). After a suggestion by Jochen, I submitted a RFE >> in bugzilla to update libshout to 2.x, or at least create a libshout2 >> package that I would be more than happy to maintain >> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181523). Thomas, >> however, has yet to comment on the RFE, and apparently according to the >> Wiki's FC5Status, he has yet to rebuild ANY of his packages for FC5, >> making his MIA a burden on us all, not just me. > > Deadbeat maintainers should be automatically disowned. > No sign of life in X amount of time ==> package becomes orphan > automatically. Make it a policy and put an end to debates. > I've had something similar with a bug in a package which was owned by Thomas, I ended up fixing it myself (in a very bad way) and then Thomas surfaced, he is also probably reading this, this should get him awake, if not then .... ? And it seems currently nothing is using libshout so an upgrade could be done real painless atleast in devel, and should be done for FC5 release IMHO, much better then having 2 versions around: [root at shalem ~]# rpm -q --provides libshout libshout-1.0.9-4.x86_64 libshout.so.2()(64bit) libshout = 1.0.9-4 [root at shalem ~]# repoquery -q --whatrequires libshout.so.2 [root at shalem ~]# repoquery -q --whatrequires libshout.so.2()(64bit) -bash: syntax error near unexpected token `(' [root at shalem ~]# repoquery -q --whatrequires 'libshout.so.2()(64bit)' [root at shalem ~]# Regards, Hans From fedora at leemhuis.info Mon Feb 27 09:46:11 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 27 Feb 2006 10:46:11 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <4402B5FF.7030800@hhs.nl> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <20060226191010.GA2961@free.fr> <44021B97.7040806@hhs.nl> <1141019544.808.5.camel@thl.ct.heise.de> <4402B5FF.7030800@hhs.nl> Message-ID: <1141033571.808.36.camel@thl.ct.heise.de> Am Montag, den 27.02.2006, 09:19 +0100 schrieb Hans de Goede: > > Thorsten Leemhuis wrote: > > Am Sonntag, den 26.02.2006, 22:20 +0100 schrieb Hans de Goede: > >> + a zillion > > I disagree ;-) > I know you would :) :-) > >> I almost never (never say never) read the bugzilla generated mails, and > >> I get confused about what to send to maintainers and what to send to > >> extras-list. > > Read the FESCo-Meeting summary from the last meeting: > > ---- > > * separate extras-ml-list for bugzilla spam > > * We'll probably open fedora-extras-bugzilla-list and > > fedora-extras-review-list. All contributors should subscribe to > > -reviews. > I think 2 bugzilla lists is a great idea, I see you say should subscribe > to review-list so its not a must? Undecided yet. I'm not sure where I stand. Maybe it should be a "must", but we can't control people. So they maybe won't read it or send it directly to /dev/null with procmail... >[...] > > ---- > > fedora-extras-review-list -> review bugs > > fedora-extras-bugzilla-list -> everything else related to Extras > > > > fedora-extras-list should remain for general discussions about Fedora > > Extras. > > > > fedora-maintainers should stay for all maintainers (redhat and > > community) that only want to maintain stuff, but don't what to be > > involved with all the flamewars ^w discussions on fedora-extras-list. > I can see the logic in things, but in practice everything extras related > that gets posted to maintainer also gets crossposed to maintainer s/maintainer/extras/ here? > , now > if you stop doing that, assuming that all maintainers are (must be) > subscribed to maintainers then thats fine. Well, IMHO maintainers is a bit like an announce-list. Important things for maintainers should be announced there, but discussions should happen elsewhere (e.g. on extras-list in this case). Otherwise people will stop reading that list and/or unsubscribe. But maybe that's just my opinion. That wouldn't be a big problem if the Reply-To would work. See '"Reply-To" Munging Considered Harmful' on http://www.unicom.com/pw/reply-to-harmful.html CU thl From j.w.r.degoede at hhs.nl Mon Feb 27 10:08:23 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 27 Feb 2006 11:08:23 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1141033571.808.36.camel@thl.ct.heise.de> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <20060226191010.GA2961@free.fr> <44021B97.7040806@hhs.nl> <1141019544.808.5.camel@thl.ct.heise.de> <4402B5FF.7030800@hhs.nl> <1141033571.808.36.camel@thl.ct.heise.de> Message-ID: <4402CF97.7020405@hhs.nl> Thorsten Leemhuis wrote: > Am Montag, den 27.02.2006, 09:19 +0100 schrieb Hans de Goede: >> Thorsten Leemhuis wrote: >>> Am Sonntag, den 26.02.2006, 22:20 +0100 schrieb Hans de Goede: >>>> + a zillion >>> I disagree ;-) >> I know you would :) > > :-) > >>>> I almost never (never say never) read the bugzilla generated mails, and >>>> I get confused about what to send to maintainers and what to send to >>>> extras-list. >>> Read the FESCo-Meeting summary from the last meeting: >>> ---- >>> * separate extras-ml-list for bugzilla spam >>> * We'll probably open fedora-extras-bugzilla-list and >>> fedora-extras-review-list. All contributors should subscribe to >>> -reviews. >> I think 2 bugzilla lists is a great idea, I see you say should subscribe >> to review-list so its not a must? > > Undecided yet. I'm not sure where I stand. Maybe it should be a "must", > but we can't control people. So they maybe won't read it or send it > directly to /dev/null with procmail... >> [...] >>> ---- >>> fedora-extras-review-list -> review bugs >>> fedora-extras-bugzilla-list -> everything else related to Extras >>> >>> fedora-extras-list should remain for general discussions about Fedora >>> Extras. >>> >>> fedora-maintainers should stay for all maintainers (redhat and >>> community) that only want to maintain stuff, but don't what to be >>> involved with all the flamewars ^w discussions on fedora-extras-list. > >> I can see the logic in things, but in practice everything extras related >> that gets posted to maintainer also gets crossposed to maintainer > > s/maintainer/extras/ here? > Erm yes. >> , now >> if you stop doing that, assuming that all maintainers are (must be) >> subscribed to maintainers then thats fine. > > Well, IMHO maintainers is a bit like an announce-list. Important things > for maintainers should be announced there, but discussions should happen > elsewhere (e.g. on extras-list in this case). Otherwise people will stop > reading that list and/or unsubscribe. But maybe that's just my opinion. > Well if extras-list becomes low volume then this setup is fine. Offtopic: anyone now how to teach thunderbird to nuke crossposts (all except one) ? Regards, Hans From bugzilla at redhat.com Mon Feb 27 09:54:42 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 04:54:42 -0500 Subject: [Bug 182254] Review Request: SS5 In-Reply-To: Message-ID: <200602270954.k1R9sgEe010775@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: SS5 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182254 ------- Additional Comments From matteo.ricchetti at libero.it 2006-02-27 04:54 EST ------- I'm going to fix all your requests, but about /opt I followed RH guidelines even if it is not in path, such as /etc/opt/"name prog"? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 10:12:45 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 05:12:45 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602271012.k1RACjLa014471@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From paul at city-fan.org 2006-02-27 05:12 EST ------- (In reply to comment #9) > => It's those applications which have to "Requires: perl(Spiffy)" to get this > working. If rpm generates bogus "Requires: perl(mixin)" for those applications, > these have to filter them out. I agree with Ralf, and have a suggestion for how to do this: Have the perl-Spiffy package (which is presumably a buildreq of the problematic packages) provide a custom perl "requires" script (perhaps as simple as an expansion of "%{__perl_requires} "$@" | sed -e 's/^perl(mixin)/perl(Spiffy)/'") and ship it with the perl-Spiffy package as /usr/lib/rpm/perl-Spiffy.req. Then, in each dependent package, simply add the line: %define __perl_requires /usr/lib/rpm/perl-Spiffy.req That's not too hard, is it? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From pertusus at free.fr Mon Feb 27 10:43:30 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 27 Feb 2006 11:43:30 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <4402B5FF.7030800@hhs.nl> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <20060226191010.GA2961@free.fr> <44021B97.7040806@hhs.nl> <1141019544.808.5.camel@thl.ct.heise.de> <4402B5FF.7030800@hhs.nl> Message-ID: <20060227104330.GC2995@free.fr> > I think 2 bugzilla lists is a great idea, I see you say should subscribe > to review-list so its not a must? I'm all for doing my share of reviews, I think that it should be a must. It doesn't mean that everybody will do it we're all volunteer after all, but it shows that reviews are importante. > >fedora-maintainers should stay for all maintainers (redhat and > >community) that only want to maintain stuff, but don't what to be > >involved with all the flamewars ^w discussions on fedora-extras-list. > > > > I can see the logic in things, but in practice everything extras related > that gets posted to maintainer also gets crossposed to maintainer, now > if you stop doing that, assuming that all maintainers are (must be) > subscribed to maintainers then thats fine. It seems to me that these lists are double, because everybody subscribed to maintainers should also be subscribed to fedora-extras-list. Anyway, now that I'm subscribed to maintainers list I could see what happens there, maybe it is not of interest to people subscribed to fedora-extras-list, but I doubt it. -- Pat From andreas at bawue.net Mon Feb 27 10:52:13 2006 From: andreas at bawue.net (Andreas Thienemann) Date: Mon, 27 Feb 2006 11:52:13 +0100 (CET) Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <20060227104330.GC2995@free.fr> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <20060226191010.GA2961@free.fr> <44021B97.7040806@hhs.nl> <1141019544.808.5.camel@thl.ct.heise.de> <4402B5FF.7030800@hhs.nl> <20060227104330.GC2995@free.fr> Message-ID: On Mon, 27 Feb 2006, Patrice Dumas wrote: [Forced subscription to extras-reviews] > I think that it should be a must. It doesn't mean that everybody will > do it we're all volunteer after all, but it shows that reviews are > importante. Bad idea. As soon as you force unwilling people to review packages, you will get hasty or bad reviews. So why go this way and force people to subscribe to the review list? If people want to do reviews, great. They will put work into it and the reviews will be thorough. > It seems to me that these lists are double, because everybody subscribed > to maintainers should also be subscribed to fedora-extras-list. Anyway, now > that I'm subscribed to maintainers list I could see what happens there, > maybe it is not of interest to people subscribed to fedora-extras-list, > but I doubt it. maintainers is basically silent. The list could be used however for announcements to maintainers. Right now -extras is high volume and I for one don't have the time to really follow the list. bye, andreas -- "Being drunk beyond the thin line of good taste" -- weEKAy on #ebone From pertusus at free.fr Mon Feb 27 11:33:11 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 27 Feb 2006 12:33:11 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <20060226191010.GA2961@free.fr> <44021B97.7040806@hhs.nl> <1141019544.808.5.camel@thl.ct.heise.de> <4402B5FF.7030800@hhs.nl> <20060227104330.GC2995@free.fr> Message-ID: <20060227113310.GD2995@free.fr> > Bad idea. As soon as you force unwilling people to review packages, you > will get hasty or bad reviews. > So why go this way and force people to subscribe to the review list? > If people want to do reviews, great. They will put work into it and the > reviews will be thorough. The reviews aren't only usefull for those who do reviews, but also for those who learn to review. If everybody is subscribed to the review list it helps learning to review. > maintainers is basically silent. Oh, I hadn't understood something. fedora-maintainers is for extras and core packagers. And some core packagers may be uninterested in extras. Ok, so there is some overlap between fedora-extras-list, fedora-maintainers and fedora-devel, but maybe it is unavoidable. fedora-extras-list is for those interested in extras, fedora-devel for those interested in core and fedora-maintainers for those interested in both, but then it isn't a surprise that it is mostly silent. It is even strange that there is more than annoucements. Anyway if every extra contributor should be subscribed to that list, it should be said there: http://fedoraproject.org/wiki/Extras/Contributors#head-53aea28748f7f8172082faefbad5b3f9788c4236 and the mailing list should appear here: http://fedoraproject.org/wiki/Communicate#head-e515a6e891efe6e2f1c8faa0434f8b5422510668 > The list could be used however for announcements to maintainers. > Right now -extras is high volume and I for one don't have the time to > really follow the list. Still we are volunteer, so it is not a problem if it isn't possible to read everything. But it is a community project, so there are discussions about policy, and disagreements. My personal opinion is that things are kept constructive most of the time, but I may be biased, as I participate to the noise... -- Pat From sundaram at fedoraproject.org Mon Feb 27 11:58:19 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 27 Feb 2006 17:28:19 +0530 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <20060227113310.GD2995@free.fr> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <20060226191010.GA2961@free.fr> <44021B97.7040806@hhs.nl> <1141019544.808.5.camel@thl.ct.heise.de> <4402B5FF.7030800@hhs.nl> <20060227104330.GC2995@free.fr> <20060227113310.GD2995@free.fr> Message-ID: <4402E95B.3000405@fedoraproject.org> HI >Anyway if every extra contributor should be subscribed to that list, >it should be said there: > >http://fedoraproject.org/wiki/Extras/Contributors#head-53aea28748f7f8172082faefbad5b3f9788c4236 > >and the mailing list should appear here: > >http://fedoraproject.org/wiki/Communicate#head-e515a6e891efe6e2f1c8faa0434f8b5422510668 > > Added to both. Thanks. -- Rahul From bugs.michael at gmx.net Mon Feb 27 12:05:38 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 27 Feb 2006 13:05:38 +0100 Subject: owners owners.list,1.681,1.682 In-Reply-To: <200602271003.k1RA3BMF004088@cvs-int.fedora.redhat.com> References: <200602271003.k1RA3BMF004088@cvs-int.fedora.redhat.com> Message-ID: <20060227130538.0fd5a8b0.bugs.michael@gmx.net> On Mon, 27 Feb 2006 05:02:38 -0500, Hans de Goede wrote: > Author: jwrdegoede > > Update of /cvs/extras/owners > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv4070/owners > > Modified Files: > owners.list > Log Message: > Add myself as co-owner of allegro You broke it. The file format doesn't work like that. > -Fedora Extras|allegro|A game programming library|jnovy at redhat.com|extras-qa at fedoraproject.org| > +Fedora Extras|allegro|A game programming library|jnovy at redhat.com|j.w.r.degoede at hhs.nl|extras-qa at fedoraproject.org| You want: Fedora Extras|allegro|A game programming library|jnovy at redhat.com|extras-qa at fedoraproject.org|j.w.r.degoede at hhs.nl From andreas.bierfert at lowlatency.de Mon Feb 27 12:15:35 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Mon, 27 Feb 2006 13:15:35 +0100 Subject: OpenAL 0.0.9 problems In-Reply-To: <440212E1.5030505@hhs.nl> References: <1140981890.23109.4.camel@scriabin.tannenrauch.ch> <440212E1.5030505@hhs.nl> Message-ID: <20060227131535.1ad894bc@alkaid.a.lan> On Sun, 26 Feb 2006 21:43:13 +0100 Hans de Goede wrote: > Everyone involved please read: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181989 > > This is _not_ intended to put shame to Andreas who I know as a great > Extras contributer, but to watch and learn! Well thats ok... it is my fault after all. So shame on me. So for everybody involved: I just pushed a new version which: - Does not change the soname (based on the old cvs snapshot) and should not have sound issues - has #181989 fixed properly (as I believe) After the daily extras push yum should run smooth again. I am sorry for the delay and that this fell trough my testing stuff but after switching to x86_64 rawhide I forgot to install some of the packages which have one of my packages as a dep thus not seeing this error on test install. For other non-RPMed stuff please open a bug and we will talk about what the best action for that would be. Sorry for the inconvenience. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From skvidal at linux.duke.edu Mon Feb 27 12:33:21 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 27 Feb 2006 07:33:21 -0500 Subject: frustrated newcomers AND orphaned packages (Was: Rebuild status of FE5) In-Reply-To: <1141020541.16413.18.camel@rivendell.home.local> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <4402965F.2070707@users.sourceforge.net> <1141020541.16413.18.camel@rivendell.home.local> Message-ID: <1141043601.1723.30.camel@cutter> > Deadbeat maintainers should be automatically disowned. > No sign of life in X amount of time ==> package becomes orphan > automatically. Make it a policy and put an end to debates. > > Easy. Automatically? You mean w/o trying to contact the maintainer off-list? Occasionally people respond well to a poke. It might be worth making the rule 'after N attempts to contact over N months' -sv From andreas.bierfert at lowlatency.de Mon Feb 27 12:56:23 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Mon, 27 Feb 2006 13:56:23 +0100 Subject: fc4/5 wine-0.9.8 In-Reply-To: <4401954E.1000502@feuerpokemon.de> References: <4401954E.1000502@feuerpokemon.de> Message-ID: <20060227135623.05d515d3@alkaid.a.lan> On Sun, 26 Feb 2006 12:47:26 +0100 dragoran wrote: > wine 0.9.8 > was build for fc3 but not for fc4/fc5 (maybe because buildsys was broken) > but now it works and it is still at 0.9.7 Did you mean fc3/fc5 and not fc4? Anyway... just restarted the fc4 build. Thanks. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From fedora at leemhuis.info Mon Feb 27 12:58:53 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 27 Feb 2006 13:58:53 +0100 Subject: frustrated newcomers AND orphaned packages (Was: Rebuild status of FE5) In-Reply-To: <1141043601.1723.30.camel@cutter> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <4402965F.2070707@users.sourceforge.net> <1141020541.16413.18.camel@rivendell.home.local> <1141043601.1723.30.camel@cutter> Message-ID: <1141045133.808.66.camel@thl.ct.heise.de> Am Montag, den 27.02.2006, 07:33 -0500 schrieb seth vidal: > > Deadbeat maintainers should be automatically disowned. > > No sign of life in X amount of time ==> package becomes orphan > > automatically. Make it a policy and put an end to debates. > > > > Easy. > > Automatically? You mean w/o trying to contact the maintainer off-list? > Occasionally people respond well to a poke. It might be worth making the > rule 'after N attempts to contact over N months' Well, I would prefer a solution somewhere between those two ideas. For example something like this: - you open a bugzilla-ticket with a fix/enhancement. Maintainer does not react after N days (N=14, shorter timeframe if it's something more important, e.g. security or something is totally broken) -> you go ask on fedora-extras-list for comments and wait for another 24 hours -> apply patch and build - if 'after N (N=something between 3 and 5) failed attempts to contact maintainer over N (N=something between 10 and 18) weeks' a package officially is orphaned. Opinions? CU thl From jwboyer at jdub.homelinux.org Mon Feb 27 12:14:35 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 27 Feb 2006 06:14:35 -0600 (CST) Subject: owners owners.list,1.681,1.682 In-Reply-To: <20060227130538.0fd5a8b0.bugs.michael@gmx.net> References: <200602271003.k1RA3BMF004088@cvs-int.fedora.redhat.com> <20060227130538.0fd5a8b0.bugs.michael@gmx.net> Message-ID: <14126.129.42.161.36.1141042475.squirrel@jdub.homelinux.org> > On Mon, 27 Feb 2006 05:02:38 -0500, Hans de Goede wrote: > >> Author: jwrdegoede >> >> Update of /cvs/extras/owners >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv4070/owners >> >> Modified Files: >> owners.list >> Log Message: >> Add myself as co-owner of allegro > > You broke it. The file format doesn't work like that. > >> -Fedora Extras|allegro|A game programming >> library|jnovy at redhat.com|extras-qa at fedoraproject.org| >> +Fedora Extras|allegro|A game programming >> library|jnovy at redhat.com|j.w.r.degoede at hhs.nl|extras-qa at fedoraproject.org| > > You want: > > Fedora Extras|allegro|A game programming > library|jnovy at redhat.com|extras-qa at fedoraproject.org|j.w.r.degoede at hhs.nl FYI, I did that for the tla package the other day and it didn't work. I've been meaning to ping Elliot to see if something has gone wacky with the auto-CCing parts. josh From bugzilla at redhat.com Mon Feb 27 13:41:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 08:41:44 -0500 Subject: [Bug 170131] Review Request: php-extras - Additional PHP modules from the standard PHP distribution In-Reply-To: Message-ID: <200602271341.k1RDfiCH028209@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-extras - Additional PHP modules from the standard PHP distribution https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170131 ------- Additional Comments From bugs.michael at gmx.net 2006-02-27 08:41 EST ------- The "Requires: php = %{version}" in every module package is not good. It causes upgrade problems between FC's "php" and every module package. Querying the rpms, all contain just DSOs, no versioned paths, and nothing obvious which would justify a dependency on a specific minor version of PHP. In case you meant to use "Requires: php >= %{version}" instead, then prefer that. Alternatively, drop the version completely, since you know PHP in the FC repo is big enough. RPATHs will need a close look to make sure they really never end up in the binaries. With Rawhide they don't currently, but in the build log they are still present, e.g.: -rpath /home/qa/tmp/rpm/BUILD/php-5.1.1/ext/dbase/modules -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 27 13:49:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 08:49:28 -0500 Subject: [Bug 182254] Review Request: SS5 In-Reply-To: Message-ID: <200602271349.k1RDnSdL029594@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: SS5 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182254 ------- Additional Comments From matteo.ricchetti at libero.it 2006-02-27 08:49 EST ------- New package available: Spec Name or Url: http://prdownloads.sourceforge.net/ss5/ss5.spec.3.4.3? download SRPM Name or Url: http://prdownloads.sourceforge.net/ss5/ss5-3.4.3-1.src.rpm? download Tell me if it's ok. Thx -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 14:13:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 09:13:30 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602271413.k1REDTjs002977@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From tibbs at math.uh.edu 2006-02-27 09:13 EST ------- I still disagree, because it is quite possible for a package to provide functionality different from its name. But fortunately Paul is actually constructive in his objections, though I feel that adding that hack to every downstream package is far worse then actually specifying what Spiffy provides. If Steve is willing to add hacks to all of the downstream packages then I won't object. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 14:20:31 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 09:20:31 -0500 Subject: [Bug 176784] Review Request: gnome-schedule: A GTK+ based user interface for cron and at In-Reply-To: Message-ID: <200602271420.k1REKV5E004401@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gnome-schedule: A GTK+ based user interface for cron and at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176784 frank at scirocco-5v-turbo.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From frank at scirocco-5v-turbo.de 2006-02-27 09:20 EST ------- Thanks for the review and your sponsoring. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 27 14:22:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 09:22:59 -0500 Subject: [Bug 182254] Review Request: SS5 In-Reply-To: Message-ID: <200602271422.k1REMxEZ005111@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: SS5 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182254 ------- Additional Comments From matteo.ricchetti at libero.it 2006-02-27 09:22 EST ------- New package available (fix startup file): Spec Name or Url: http://prdownloads.sourceforge.net/ss5/ss5.spec.3.4.3-2? download SRPM Name or Url: http://prdownloads.sourceforge.net/ss5/ss5-3.4.3-2.src.rpm? download Tell me if it's ok. Thx -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 14:25:46 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 09:25:46 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602271425.k1REPkFG005643@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From rc040203 at freenet.de 2006-02-27 09:25 EST ------- (In reply to comment #11) > I still disagree, because it is quite possible for a package to provide > functionality different from its name. Consider the case of adding annother package implementing "perl(mixin)"? > If Steve is willing to add hacks to all of the downstream packages then > I won't object. You guys are putting the cart before the horse. I can't avoid VETO'ing against this package if the Provides: mixin won't be removed. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 14:29:12 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 09:29:12 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602271429.k1RETC96006406@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From paul at city-fan.org 2006-02-27 09:29 EST ------- (In reply to comment #11) > I still disagree, because it is quite possible for a package to provide > functionality different from its name. But fortunately Paul is actually > constructive in his objections, though I feel that adding that hack to every > downstream package is far worse then actually specifying what Spiffy provides. Whilst it's fine for a package to provide functionality different from its name, the problem here is that the package is saying it provides something that it doesn't, namely a perl module called "mixin". Pretending that it provides this package means that it's not possible for, at some future date, a new perl module of that name to be packaged properly without clashing with this one. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From jspaleta at gmail.com Mon Feb 27 14:36:37 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 27 Feb 2006 09:36:37 -0500 Subject: frustrated newcomers AND orphaned packages (Was: Rebuild status of FE5) In-Reply-To: <4402965F.2070707@users.sourceforge.net> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <4402965F.2070707@users.sourceforge.net> Message-ID: <604aa7910602270636r1dad0f48j5e105c9f4175c8b6@mail.gmail.com> On 2/27/06, Brandon Holbrook wrote: > owned by Thomas Vander Stichele > (thomas at apestaart.org). After a suggestion by Jochen, I submitted a > RFE in bugzilla to update libshout to 2.x, or at least create a libshout2 > package that I would be more than happy to maintain > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181523). > Thomas,however, has yet to comment on the RFE, and apparently > according to the Wiki's FC5Status, he has yet to rebuild ANY of his > packages for FC5, > making his MIA a burden on us all, not just me. >From reading between the lines in his blog entries, I believe he's on vacation for a couple of weeks. > This is very frustrating for me, because for the past two weeks I've > been ready every day to finally get a project approved and actually be > able to contribute to Extras. > My point out of all this is that first, I would like to see Extras adopt > a "forced adoption" policy (maybe "kidnapping" is a more appropriate > term ;) ). Any policy of forced adoption would require at least a month waiting period if its going to be a policy at all. I don't think 2 weeks is enough considering this isn't a source code repository but there are packaging depchains which must be accounted for. This isn't sourceforge, were you can archive older releases for use. And I certaintly don't think "new" contributors, who don't have a track record inside the project, should be allowed to walk in and forcible take a package under any circumstances. The better solution the problem is breaking the model of one owner per package and having as many packages as possible under the maintainership of teams of people who agree as to roadmap for that subset of packages. > Second, I am obviously a +1 for the "auto > orphan" policy Aurelien proposed below, but I'd also take it a step > further and auto-orphan packages that have RFEs unanswered for x > days. Mental note to self, create that script to auto-answer all new tickets to components that I own so I don't have to take time out answering crackrock RFEs in x number of days just to keep my ownership status. Mental note #2, give the script to thomas. -jef From rdieter at math.unl.edu Mon Feb 27 14:53:59 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 27 Feb 2006 08:53:59 -0600 Subject: maxima bug? In-Reply-To: References: Message-ID: leon wrote: > Can anyone confirm this bug? Thank you. > > Maxima failed with: > ----BEGIN HERE---------------------------------------------------------- > fatal error encountered in SBCL pid 14139(tid 3086939824): > can't load .core for different runtime, sorry > > The system is too badly corrupted or confused to continue at the Lisp > level. If the system had been compiled with the SB-LDB feature, we'd drop > into the LDB low-level debugger now. But there's no LDB in this build, so > we can't really do anything but just exit, sorry. > ----END HERE------------------------------------------------------------ Probably a bug with maxima-runtime-sbcl. Can you bugzilla it to track the issue? (Hopefully, all that is required is a maxima rebuild against the latest sbcl). -- Rex From bugzilla at redhat.com Mon Feb 27 14:51:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 09:51:48 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602271451.k1REpmek011952@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From tibbs at math.uh.edu 2006-02-27 09:51 EST ------- Mid-air collission - I'm replying to Ralf here. Consider the case of adding another package implementing "webserver". So we have two packages providing the same thing. The "mixin" functionality you get depends on which package you 'use'. You could never use that package and this one in the same Perl program because they would conflict at the language level. What perl packages provide and which conflict with each other doesn't simply map onto RPM dependencies. Anyway, the issue is whether Steve is willing to add the Requires: filtering kindly provided by Paul to the packages that require this one, so that the Provides: here can be removed. It's simpler to ask here than in all of the downstream bugzilla tickets. If he's not, then we try to work out another solution. BTW, please quote the place in the review policy where the process of vetoing reviews is laid out. I would like to know how it works, but I can't find it. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 14:59:06 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 09:59:06 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602271459.k1REx6aQ013517@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From rc040203 at freenet.de 2006-02-27 09:59 EST ------- (In reply to comment #14) > Mid-air collission - I'm replying to Ralf here. > > Consider the case of adding another package implementing "webserver". Yes, ... RH's responsibility, bad design on their part. However, there is a substantial difference between "webserver" and "perl(mixin)" "webserver" is a virtual package/property, perl(mixin) is a 1:1 correspondence to mixin.pm. > So we > have two packages providing the same thing. The "mixin" functionality you get > depends on which package you 'use'. Exactly. > You could never use that package and this > one in the same Perl program because they would conflict at the language level. > What perl packages provide and which conflict with each other doesn't simply > map onto RPM dependencies. It does. perl(xxx) is the file dependency on xxx.pm with the %vendor*/%perl* cruft removed. > BTW, please quote the place in the review policy where the process of vetoing > reviews is laid out. I would like to know how it works, but I can't find it. FE doesn't have a policy of vetoing. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From rdieter at math.unl.edu Mon Feb 27 15:09:01 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 27 Feb 2006 09:09:01 -0600 Subject: buildsystem on devel unable to run kde-config In-Reply-To: <20060226210458.GB4879@truch.net> References: <20060226210458.GB4879@truch.net> Message-ID: Matthew D Truch wrote: > I'm having a little trouble building kst (a KDE app) on the devel > buildsystem, which builds fine on FC-4 systems. > > Configure fails with the following error: > checking for kde-config... /usr/bin/kde-config > /usr/bin/kde-config: error while loading shared libraries: > libqt-mt.so.3: cannot open shared object file: No such file or directory > configure: error: /usr/bin/kde-config --prefix outputed the non existant > prefix '' for kdelibs. > This means it has been moved since you installed it. > This won't work. Please recompile kdelibs for the new prefix. Try requeue'ing the failed job to see if you can reproduce the problem. I've built several KDE apps not too long ago without any problems (at least not related to this anyway). -- Rex From bugzilla at redhat.com Mon Feb 27 15:25:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 10:25:52 -0500 Subject: [Bug 177818] Review Request: adplug In-Reply-To: Message-ID: <200602271525.k1RFPqJt020240@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: adplug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177818 ------- Additional Comments From bugs.michael at gmx.net 2006-02-27 10:25 EST ------- $prefix expands to /usr/local (or /usr) by default in our environment and most distributions, so $prefix/com won't be in the root directory. However, %{_sharedstatedir} in RPM macros expands to %{_prefix}/com (and RPM %{_localstatedir} expands to just /var not %{_prefix}/var). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From jspaleta at gmail.com Mon Feb 27 15:35:36 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 27 Feb 2006 10:35:36 -0500 Subject: frustrated newcomers AND orphaned packages (Was: Rebuild status of FE5) In-Reply-To: <1141045133.808.66.camel@thl.ct.heise.de> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <4402965F.2070707@users.sourceforge.net> <1141020541.16413.18.camel@rivendell.home.local> <1141043601.1723.30.camel@cutter> <1141045133.808.66.camel@thl.ct.heise.de> Message-ID: <604aa7910602270735p31e9a433y6591538d6f5a9217@mail.gmail.com> On 2/27/06, Thorsten Leemhuis wrote: > - you open a bugzilla-ticket with a fix/enhancement. Maintainer does not > react after N days (N=14, shorter timeframe if it's something more > important, e.g. security or something is totally broken) -> you go ask > on fedora-extras-list for comments and wait for another 24 hours -> > apply patch and build no for enhancements 2 weeks is too damn short for rfe's.. people have real lives that get in the way... and I think policy needs to be aware of that. This is the wrong solution. The solution is pro-active team building no re-active patching. Are you really going to demand that contributors respond to all enhancement requests regardless of crackrock status? Sounds to me like a great way to forcibly get a change into a package that the current maintainer(s) doesn't support. Duplicate enhancement request for the same thing over and over again until the maintainer decides not to respond because its a waste of time to mark the dupes. I will not personally support any policy which puts mandatory constraints on an Extras contributor reply to bugzilla tickets for non-security feature requests in X amount of time. And I don't think letting people willy-nilly patch and build packages is a good idea. If you want to set a time limit to strip maintainership status of a package from someone and hand over ownership status of the package to someone else.. fine. But encouraging other contributors to blast through patch and build updates for RFE's when they don't take over full responsibility is asking for problems associated with updates. Who's job is it to fix problems associated with the new patched build? The original maintainer? Or the person who put in the patch? The default policy on patching and building should be, if you patch/build it..you own it, unless you have the blessing of the current owner(s). And this should go for the security team as well. If we get a security team and they have the authority to step in and patch/build something if the maintainer is unavailable.. then the package should clearly change ownership to the security team so its clear who is taking responsibility for problems associated with that updated package... until such time that the original maintainer is back in touch with the project or the package. > > - if 'after N (N=something between 3 and 5) failed attempts to contact > maintainer over N (N=something between 10 and 18) weeks' a package > officially is orphaned. No... i do not think allowing contributors to patch and build packages they are not taking personal responsibility for is a good idea. All this does is muddy the waters as to which group of people are going to respond to problems resulting for that extraordinary patch/build and whether or not the package is actually "orphaned". Encouraging people to hot patch something that is potentially orphaned makes it more difficult to determine if its actually orphaned or not. I do not think you can rely solely on open bugzilla ticket status as a reliable measure as to orphan status because you are not going to get consistent bugzilla usage across contributors. If you patch it in CVS without the current owner's permission then you should be responsible for it and that package should not be considered orphaned. Instead of relying completely on ways to guess if a package is orphaned.. I would prefer specific scheduled points in time when all packagers/teams re-affirm their maintainership over packages and which branches they are actively maintaining. The goal should be to establish as much multi-contributor coverage over packages as possible, before multi-contributor coverage is actually needed. A scheduled, reliable, re-affirm process will help us identify..proactively..what packages are under multi-contributor team oversight and which aren't and can help us tell the difference between a packager that has left the ranch completely and someone who is afk for a 2 week vacation. -jef From bugzilla at redhat.com Mon Feb 27 15:38:54 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 10:38:54 -0500 Subject: [Bug 169704] Review Request: mosml - Moscow ML In-Reply-To: Message-ID: <200602271538.k1RFcsLC023768@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mosml - Moscow ML https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169704 ------- Additional Comments From jpmahowald at gmail.com 2006-02-27 10:38 EST ------- The CAML light part of the license says "The user undertakes not to carry out any paying distribution of the software." while allowing for cost of reproduction. Don't know if this non commercial clause is too restrictive. The .sos do not seem to have any versioning, mosml does this a different wa? rpmlint complains about several shlib-with-non-pic-code and linking problems like the following example: E: mosml-pg shlib-with-non-pic-code /usr/lib/mosml/lib/libmpq.so The listed shared libraries contain object code that was compiled without -fPIC. All object code in shared libraries should be recompiled separately from the static libraries with the -fPIC option. Another common mistake that causes this problem is linking with ``gcc -Wl,-shared'' instead of ``gcc -shared''. E: mosml-pg library-not-linked-against-libc /usr/lib/mosml/lib/libmpq.so -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 27 15:45:45 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 10:45:45 -0500 Subject: [Bug 170131] Review Request: php-extras - Additional PHP modules from the standard PHP distribution In-Reply-To: Message-ID: <200602271545.k1RFjjcU025036@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-extras - Additional PHP modules from the standard PHP distribution https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170131 ------- Additional Comments From rpm at timj.co.uk 2006-02-27 10:45 EST ------- About the Requires, this thread I raised on pecl-dev may be of relevance: http://marc.theaimsgroup.com/?t=113745441400005 I *think* what needs to happen is for the core PHP package to have a: Provides: php(API) = XXXXXXXX (or similar) and for PECL modules, php-extras etc to have: Requires: php(API) = XXXXXXXX This will need jorton at redhat to help by adding the Provide to the Core php package. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 27 15:55:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 10:55:49 -0500 Subject: [Bug 172343] Review Request: libtomoe-gtk In-Reply-To: Message-ID: <200602271555.k1RFtniN027057@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libtomoe-gtk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172343 ------- Additional Comments From jpmahowald at gmail.com 2006-02-27 10:55 EST ------- New site downloads much better. One thing still blocking: the devel subpackage needs it's own call to ldconfig. See the ReviewGuidelines on the wiki. Good: - rpmlint checks return: W: libtomoe-gtk-debuginfo objdump-failed Not critical. - package meets naming guidelines - package meets packaging guidelines - license (GPL) OK, text in %doc, matches source - spec file legible, in am. english - source matches upstream - package compiles on devel (x86) - no missing BR - no unnecessary BR - locales handled by %find_lang - not relocatable - owns all directories that it creates - no duplicate files - permissions ok - %clean ok - macro use consistent - code, not content - no need for -docs - nothing in %doc affects runtime - no need for .desktop file - devel package ok - no .la files - devel requires base package n-v-r -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 27 16:01:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 11:01:50 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602271601.k1RG1oOY028248@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From tibbs at math.uh.edu 2006-02-27 11:01 EST ------- > It does. perl(xxx) is the file dependency on xxx.pm with the %vendor*/%perl* > cruft removed. Now that's a clean, well defined statement that I can live with. But is it actually written down as policy anywhere? Judging from things like "webserver", I have always taken Requires:/Provides: to be based on functionality except when specifying paths or library names. If perl(blah) is different then things are certainly simpler, but this really has to be written down somewhere that someone like me can find. Otherwise I'm just seeing policy being made up on the spot and frankly it looks rather capricious. (See also the veto thing.) In any case, this is just banter until we hear from Steve. So, Steve: I think the Provides: perl(mixin) is the only issue of contention, so if you drop that and fixe the Source0: URL and the summary then I'll approve this and move on to the rest of your submissions. If you don't want to drop the Provides: and filter out the dependency downstream, then say so and we'll try to figure something else out. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 16:04:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 11:04:56 -0500 Subject: [Bug 182064] Review Request: facter In-Reply-To: Message-ID: <200602271604.k1RG4u0w028963@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: facter https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182064 ------- Additional Comments From bugs.michael at gmx.net 2006-02-27 11:04 EST ------- $ rpmls facter -rwxr-xr-x /usr/bin/facter -rwxr-xr-x /usr/lib/site_ruby/1.8/facter.rb drwxr-xr-x /usr/share/doc/facter-1.1.1 -rw-r--r-- /usr/share/doc/facter-1.1.1/CHANGELOG -rw-r--r-- /usr/share/doc/facter-1.1.1/COPYING -rw-r--r-- /usr/share/doc/facter-1.1.1/INSTALL -rw-r--r-- /usr/share/doc/facter-1.1.1/LICENSE -rw-r--r-- /usr/share/doc/facter-1.1.1/README It has a direct dependency on "ruby-libs", which owns the /usr/lib/*ruby/1.8 directory tree. That "ruby" requires "ruby-libs" already, well, ugh. * The facter.rb script should not be executable. Gives ugly errors without a ruby shebang. * The install location of the script (/usr/lib/site_ruby/1.8/) looks wrong. IMHO, it should be $ ruby -rrbconfig -e 'puts Config::CONFIG["rubylibdir"]' /usr/lib/ruby/1.8 instead, just like we install Perl modules into vendor locations, as site locations take precendence in search path list. * "Source0" tag should include full URL of tarball: http://reductivelabs.com/downloads/facter/facter-1.1.3.tgz * Repeating the program name in the "Summary" is commonly considered bad taste/style, since what counts and is most interesting is what the stuff in the package does, not its name. Summary: Ruby module for collecting simple facts about a host operating system The package description can expand on that, and at least the %description hould explain that this is a module written in "Ruby". * facter 1.1.3 has been released. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 16:18:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 11:18:13 -0500 Subject: [Bug 170131] Review Request: php-extras - Additional PHP modules from the standard PHP distribution In-Reply-To: Message-ID: <200602271618.k1RGIDuJ032036@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-extras - Additional PHP modules from the standard PHP distribution https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170131 ------- Additional Comments From bugs.michael at gmx.net 2006-02-27 11:18 EST ------- That thread confirms that the current dependency is too strict. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 27 16:28:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 11:28:56 -0500 Subject: [Bug 174588] Review Request: libopensync-plugin-gpe In-Reply-To: Message-ID: <200602271628.k1RGSu2c002769@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libopensync-plugin-gpe https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174588 ------- Additional Comments From jpmahowald at gmail.com 2006-02-27 11:28 EST ------- Fixed version also builds on x86_64 rawhide. APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 27 16:29:25 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 11:29:25 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602271629.k1RGTPn9002873@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From steve at silug.org 2006-02-27 11:29 EST ------- What if I just add a mixin.pm that does nothing but "use Spiffy;" (or maybe "die 'use Spiffy; first';")? I could document the entire packaging problem there, and I think if I do it right, it wouldn't affect proper use of Spiffy at all. I *really* don't want to force some hack on every package that uses Spiffy, which would probably mean every Kwiki package (potentially 130 of them at the moment). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 16:35:00 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 11:35:00 -0500 Subject: [Bug 177818] Review Request: adplug In-Reply-To: Message-ID: <200602271635.k1RGZ03M004810@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: adplug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177818 ------- Additional Comments From rc040203 at freenet.de 2006-02-27 11:34 EST ------- (In reply to comment #10) > Aha! So when something is in the GNU standard but not the FHS, > which one should win in the Fedora world...? None. Both standards cover different aspects. The GNU standards aim at configuration portability, the FHS is the smallest common denominator that many *nix vendors (almost) agree to. So, in this case it's a matter of "switching on brains" and "taking the plunge" of drawing responsible decisions. As far as, sharedstatedir is concerned, this is rarely used, because it's beyond the scope of most packages, and beyond the reponsibility of vendors ("shared statedir", architecture independent data, it is supposed to be shared between different architectures and OSes). Implementing it definitely is a very tough task, and therefore probably not covered by the FHS. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 27 16:51:11 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 11:51:11 -0500 Subject: [Bug 170131] Review Request: php-extras - Additional PHP modules from the standard PHP distribution In-Reply-To: Message-ID: <200602271651.k1RGpBYq009710@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-extras - Additional PHP modules from the standard PHP distribution https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170131 ------- Additional Comments From rpm at timj.co.uk 2006-02-27 11:50 EST ------- I have filed a request for the API Provide as bug #183227 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 27 16:54:40 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 11:54:40 -0500 Subject: [Bug 174952] Review Request: lightning - GNU Lightning In-Reply-To: Message-ID: <200602271654.k1RGsecN010641@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: lightning - GNU Lightning https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174952 ------- Additional Comments From jpmahowald at gmail.com 2006-02-27 11:54 EST ------- error: Architecture is not included: x86_64 Does lightning support x86_64? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 27 17:14:03 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 12:14:03 -0500 Subject: [Bug 179040] Review Request: socat In-Reply-To: Message-ID: <200602271714.k1RHE3pI015675@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: socat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179040 ------- Additional Comments From jpmahowald at gmail.com 2006-02-27 12:13 EST ------- 1.4.3.0 got Archived, update to latest 1.4.3.1. Doesn't build on x86_64: In file included from socat.c:14: compat.h:114:4: error: #error "HAVE_BASIC_SIZE_T is out of range:" HAVE_BASIC_SIZE_T -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 27 17:14:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 12:14:15 -0500 Subject: [Bug 170131] Review Request: php-extras - Additional PHP modules from the standard PHP distribution In-Reply-To: Message-ID: <200602271714.k1RHEFxb015773@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-extras - Additional PHP modules from the standard PHP distribution https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170131 ------- Additional Comments From rdieter at math.unl.edu 2006-02-27 12:14 EST ------- IMO, until Provides: php(API) = XXXXXXXX is adopted by the core php package/maintainer, I think it not unreasonable to be more safe (to guarantee modules' use against the same php version it was built) by using the more restrictive Requires: php = %{version} than to be (potentially) sorry and discover breakage when/if php(core) is upgraded. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 27 17:28:37 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 12:28:37 -0500 Subject: [Bug 170131] Review Request: php-extras - Additional PHP modules from the standard PHP distribution In-Reply-To: Message-ID: <200602271728.k1RHSb3m019790@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-extras - Additional PHP modules from the standard PHP distribution https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170131 ------- Additional Comments From dmitry at butskoy.name 2006-02-27 12:28 EST ------- About "Requires: php = %{version}" : There is also one big reason for this. These are modules which have THE SAME source as the Core php package (i.e., common tarball). It would be strange if the Core php package will be upgraded, but php-extras still use another, obsoleted source... Initially, I even wanted to make "Requires: php = %{version}-%{release}", but as different "php Core" releases do not reflect the "php-extras" source part (patches change nothing in that area), I've considered that "php = %{version}" seems to be enough... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 27 17:31:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 12:31:27 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602271731.k1RHVRSv020713@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From tibbs at math.uh.edu 2006-02-27 12:31 EST ------- To go down that road, you could just use: package mixin; 1; (You need the package line for RPM to pick up the Provides.) I built a quick package using this and it does work. It probably satisfies the letter of the requirement, but I'm sure there will be objections as it's far nastier than just a single Provides: line and is obvious trickery which purists will hate. On the plus side, is prevents conflicts with any hypothetical mixin.pm that may appear in the future. Barring that, perhaps we could get the dependency filter into the Perl template? 130 packages needing it certainly argues for general accessibility. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From wtogami at redhat.com Mon Feb 27 18:07:04 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 27 Feb 2006 13:07:04 -0500 Subject: Extras Lists Transition Plan Message-ID: <44033FC8.9030700@redhat.com> Hey folks, During the last FESCO meeting we decided to split fedora-extras-list in order to better modularize discussion and communication within the Extras project. fedora-extras-list alone cannot support further growth in this quickly growing project. fedora-extras-list will be split into multiple lists, some of which will be mandatory for contributors to subscribe, and others will be optional but recommended. fedora-extras-list ================== CHANGE: No more bugmail goes here. fedora-extras-list will become only a discussion list. This should hopefully make it easier to follow discussion here. REQUIRED subscription for all Extras contributors. fedora-extras-review-list ========================= NEW: Extras review mail goes here. "review" the singular verb sounds better than "reviews" the plural noun here to me. Maybe the verb implies action? =) REQUIRED subscription for all Extras contributors. When the split happens, all existing fedora-extras-list subscribers will be auto-subscribed to this list. fedora-extras-bugs-list ======================= NEW: Extras bugs go here. SUGGESTED subscription for all Extras contributors. Anybody see any huge problems here? I'm going ahead with this plan sometime in the next day or two. Warren Togami wtogami at redhat.com From buildsys at fedoraproject.org Mon Feb 27 18:12:36 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 27 Feb 2006 13:12:36 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060227181236.319127FD0@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 6 dap-server-3.5.3-1.fc3.2 gtkwave-1.3.85-1.fc3 maxima-5.9.2-10.fc3 openal-0.0.9-0.4.20060204cvs.fc3 sbcl-0.9.10-1.fc3 zoo-2.10-6.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon Feb 27 18:13:05 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 27 Feb 2006 13:13:05 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060227181305.B89287FD0@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 10 dap-server-3.5.3-1.fc4.2 gtkwave-1.3.85-1.fc4 kst-1.2.0-8.fc4 lablgtk-2.6.0-2.fc4 maxima-5.9.2-10.fc4 nagios-2.0-1.fc4 openal-0.0.9-0.4.20060204cvs.fc4 sbcl-0.9.10-1.fc4 wine-0.9.8-1.fc4 zoo-2.10-6.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon Feb 27 18:13:43 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 27 Feb 2006 13:13:43 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060227181343.020487FD0@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 27 Sprog-0.14-10.fc5 Sprog-0.14-8.fc5 Sprog-0.14-9.fc5 allegro-4.2.0-8 barcode-0.98-8.fc5 commoncpp2-1.3.23-1.fc5 ddrescue-1.10-2 gnome-schedule-1.0.0-1 gtkwave-1.3.85-1.fc5 lablgtk-2.6.0-3.fc5 licq-1.3.2-5 maxima-5.9.2-10.fc5 mod_suphp-0.6.1-1.fc5 openal-0.0.9-0.5.20060204cvs.fc5 perl-Carp-Assert-More-1.12-2.fc5 perl-Crypt-Blowfish-2.09-2.fc5 perl-DateTime-0.30-3.fc5 perl-Log-Log4perl-1.03-3.fc5 perl-Net-IP-CMatch-0.02-3.fc5 perl-Net-Patricia-1.014-2.fc5 pyflowtools-0.3-6.fc5 python-HTMLgen-2.2.2-7.fc5 sbcl-0.9.10-1.fc5 scmxx-0.8.2-1.fc5 tagtool-0.12.2-5.fc5 tla-1.3.4-2.fc5 zoo-2.10-6.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From rc040203 at freenet.de Mon Feb 27 18:21:19 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 27 Feb 2006 19:21:19 +0100 Subject: Extras Lists Transition Plan In-Reply-To: <44033FC8.9030700@redhat.com> References: <44033FC8.9030700@redhat.com> Message-ID: <1141064480.8565.23.camel@mccallum.corsepiu.local> On Mon, 2006-02-27 at 13:07 -0500, Warren Togami wrote: > Hey folks, > Anybody see any huge problems here? Not huge, except that I find this proposal counterproductive to FE, because * All on FE is about to getting competent people involved, and not to hide maintainers away and give people the impression of "These dumb nuts are so stupid to do the work for you". * FE and FC should be treated as one entity, therefore the split you are proposing renders fedora-extras list superfluous, because the topics to be discussed on your future fedora-extras-list are already covered by fedora-list. * A significant amount of discussions on current fedora-extras is about packaging - People wanting to get involved into Fedora should learn about the issues on packaging as early as possible, before they try to submit anything. * As an FE maintainer, the number of mailing list I am subscribed to has reached an extend I find non-acceptable. With your split, I fear we will soon see the fedora-list trolls popping up on fedora-extras and a further decrease in quality of packages, because first-time SUBMITTERS had not been confronted with packaging issues in advance. Ralf From bugzilla at redhat.com Mon Feb 27 18:16:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 13:16:07 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602271816.k1RIG7Lp000930@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From steve at silug.org 2006-02-27 13:16 EST ------- http://ftp.kspei.com/pub/steve/rpms/perl-Spiffy-0.30-2.src.rpm * Mon Feb 27 2006 Steven Pritchard 0.30-2 - Drop explicit Provides: mixin. - Add dummy mixin.pm. - Improve Summary. - Fix Source0. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From dragoran at feuerpokemon.de Mon Feb 27 18:22:43 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 27 Feb 2006 19:22:43 +0100 Subject: fc4/5 wine-0.9.8 In-Reply-To: <20060227135623.05d515d3@alkaid.a.lan> References: <4401954E.1000502@feuerpokemon.de> <20060227135623.05d515d3@alkaid.a.lan> Message-ID: <44034373.7000808@feuerpokemon.de> Andreas Bierfert wrote: >On Sun, 26 Feb 2006 12:47:26 +0100 >dragoran wrote: > > > >>wine 0.9.8 >>was build for fc3 but not for fc4/fc5 (maybe because buildsys was broken) >>but now it works and it is still at 0.9.7 >> >> > >Did you mean fc3/fc5 and not fc4? >Anyway... just restarted the fc4 build. Thanks. > >- Andreas > > > yes sorry missed the one devel report. From bugzilla at redhat.com Mon Feb 27 18:21:54 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 13:21:54 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602271821.k1RILsMg002452@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 rc040203 at freenet.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fedora-perl-devel- | |list at redhat.com ------- Additional Comments From rc040203 at freenet.de 2006-02-27 13:21 EST ------- (In reply to comment #19) > http://ftp.kspei.com/pub/steve/rpms/perl-Spiffy-0.30-2.src.rpm > > * Mon Feb 27 2006 Steven Pritchard 0.30-2 > - Drop explicit Provides: mixin. > - Add dummy mixin.pm. With all due respect, what have you been drinking? One crazyness replacing the next? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From wtogami at redhat.com Mon Feb 27 18:32:55 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 27 Feb 2006 13:32:55 -0500 Subject: Extras Lists Transition Plan In-Reply-To: <1141064480.8565.23.camel@mccallum.corsepiu.local> References: <44033FC8.9030700@redhat.com> <1141064480.8565.23.camel@mccallum.corsepiu.local> Message-ID: <440345D7.9000204@redhat.com> Ralf Corsepius wrote: > On Mon, 2006-02-27 at 13:07 -0500, Warren Togami wrote: >> Hey folks, > >> Anybody see any huge problems here? > Not huge, except that I find this proposal counterproductive to FE, > because > > * All on FE is about to getting competent people involved, and not to > hide maintainers away and give people the impression of "These dumb nuts > are so stupid to do the work for you". How is this promoting this idea? > > * FE and FC should be treated as one entity, therefore the split you are > proposing renders fedora-extras list superfluous, because the topics to > be discussed on your future fedora-extras-list are already covered by > fedora-list. While there is agreement that FE and FC need to be moving closer together, we will not reach that goal overnight. In the meantime this is a slight improvement meant to better handle the rapid growth and traffic within Extras project. fedora-extras-list is supposed to be a devel discussion list, anything else is off-topic. With less noise on the list, it will be easier to enforce this. fedora-list and other places are supposed to be for users. > > * A significant amount of discussions on current fedora-extras is about > packaging - People wanting to get involved into Fedora should learn > about the issues on packaging as early as possible, before they try to > submit anything. > > * As an FE maintainer, the number of mailing list I am subscribed to has > reached an extend I find non-acceptable. > > > With your split, I fear we will soon see the fedora-list trolls popping > up on fedora-extras and a further decrease in quality of packages, > because first-time SUBMITTERS had not been confronted with packaging > issues in advance. > > Ralf I see no real difference in splitting the current traffic of fedora-extras-list into two lists. You have the option of filtering both lists into a single folder so you personally see no change. Warren Togami wtogami at redhat.com From dragoran at feuerpokemon.de Mon Feb 27 18:39:40 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 27 Feb 2006 19:39:40 +0100 Subject: Fedora Extras 4 Package Build Report (broken dep) In-Reply-To: <20060227181305.B89287FD0@extras64.linux.duke.edu> References: <20060227181305.B89287FD0@extras64.linux.duke.edu> Message-ID: <4403476C.9060803@feuerpokemon.de> buildsys at fedoraproject.org wrote: >Packages built and released for Fedora Extras 4: 10 > >dap-server-3.5.3-1.fc4.2 >gtkwave-1.3.85-1.fc4 >kst-1.2.0-8.fc4 >lablgtk-2.6.0-2.fc4 >maxima-5.9.2-10.fc4 >nagios-2.0-1.fc4 >openal-0.0.9-0.4.20060204cvs.fc4 >sbcl-0.9.10-1.fc4 >wine-0.9.8-1.fc4 >zoo-2.10-6.fc4 > > >For more information about the built packages please see the repository >or the fedora Info Feed: http://fedoraproject.org/infofeed/ > > > running yum update I get this: Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for hddtemp to pack into transaction set. hddtemp-0.3-0.8.beta14.fc 100% |=========================| 8.6 kB 00:00 ---> Package hddtemp.x86_64 0:0.3-0.8.beta14.fc4 set to be updated ---> Downloading header for openal to pack into transaction set. openal-0.0.9-0.3.20060226 100% |=========================| 8.1 kB 00:00 ---> Package openal.x86_64 0:0.0.9-0.3.20060226cvs.fc4 set to be updated --> Running transaction check --> Processing Dependency: libopenal.so.0()(64bit) for package: blender --> Finished Dependency Resolution Error: Missing Dependency: libopenal.so.0()(64bit) is needed by package blender seems like blender needs a rebuild.. should I fill a bug? From ed at eh3.com Mon Feb 27 18:38:50 2006 From: ed at eh3.com (Ed Hill) Date: Mon, 27 Feb 2006 13:38:50 -0500 Subject: Extras Lists Transition Plan In-Reply-To: <44033FC8.9030700@redhat.com> References: <44033FC8.9030700@redhat.com> Message-ID: <1141065530.10077.24.camel@ernie> On Mon, 2006-02-27 at 13:07 -0500, Warren Togami wrote: > > During the last FESCO meeting we decided to split fedora-extras-list in > order to better modularize discussion and communication within the > Extras project. fedora-extras-list alone cannot support further growth > in this quickly growing project. fedora-extras-list will be split into > multiple lists, some of which will be mandatory for contributors to > subscribe, and others will be optional but recommended. [snip: list of more new lists] > Anybody see any huge problems here? I'm going ahead with this plan > sometime in the next day or two. Hi folks, I'd like to see fewer lists, not more. As a part-time volunteer its already an effort to keep track of the new things going on. Or am I somehow missing out on the benefits of a MUA with perhaps more folders and better message filtering or something...? How you folks handle the daily onslaught of email? Do more lists make it easier for you? And, if so, how? Anyway, thats just my $0.02 and I may certainly be in the minority on this issue! Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From rc040203 at freenet.de Mon Feb 27 18:43:04 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 27 Feb 2006 19:43:04 +0100 Subject: Extras Lists Transition Plan In-Reply-To: <440345D7.9000204@redhat.com> References: <44033FC8.9030700@redhat.com> <1141064480.8565.23.camel@mccallum.corsepiu.local> <440345D7.9000204@redhat.com> Message-ID: <1141065784.8565.32.camel@mccallum.corsepiu.local> On Mon, 2006-02-27 at 13:32 -0500, Warren Togami wrote: > Ralf Corsepius wrote: > > On Mon, 2006-02-27 at 13:07 -0500, Warren Togami wrote: > >> Hey folks, > > > >> Anybody see any huge problems here? > > Not huge, except that I find this proposal counterproductive to FE, > > because > > > > * All on FE is about to getting competent people involved, and not to > > hide maintainers away and give people the impression of "These dumb nuts > > are so stupid to do the work for you". > > How is this promoting this idea? Quite simple: People reading fedora-extras-list won't see anything about packaging issues, however 90% of FE is about packaging. > fedora-extras-list is supposed to be a devel discussion list, So far, except of some guys abusing FE package submission/review as their testbed, there is not much of actual fedora-extra development, nor do I see substantial future FE-development. Most of fedora extra development is packaging. > > With your split, I fear we will soon see the fedora-list trolls popping > > up on fedora-extras and a further decrease in quality of packages, > > because first-time SUBMITTERS had not been confronted with packaging > > issues in advance. > > > > Ralf > > I see no real difference in splitting the current traffic of > fedora-extras-list into two lists. You have the option of filtering > both lists into a single folder so you personally see no change. You've got it: It doesn't matter if we have several lists or one. Users can filter, ... so why do you want to change the status-quo? To nag current fedora-list subscriber's with having to re-implement/duplicate/fix their list filters and having to deal with more mail duplicates? Ralf From rc040203 at freenet.de Mon Feb 27 18:44:15 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 27 Feb 2006 19:44:15 +0100 Subject: Extras Lists Transition Plan In-Reply-To: <1141065530.10077.24.camel@ernie> References: <44033FC8.9030700@redhat.com> <1141065530.10077.24.camel@ernie> Message-ID: <1141065855.8565.34.camel@mccallum.corsepiu.local> On Mon, 2006-02-27 at 13:38 -0500, Ed Hill wrote: > On Mon, 2006-02-27 at 13:07 -0500, Warren Togami wrote: > > > > During the last FESCO meeting we decided to split fedora-extras-list in > > order to better modularize discussion and communication within the > > Extras project. fedora-extras-list alone cannot support further growth > > in this quickly growing project. fedora-extras-list will be split into > > multiple lists, some of which will be mandatory for contributors to > > subscribe, and others will be optional but recommended. > > [snip: list of more new lists] > > > Anybody see any huge problems here? I'm going ahead with this plan > > sometime in the next day or two. > > Hi folks, > > I'd like to see fewer lists, not more. As a part-time volunteer its > already an effort to keep track of the new things going on. Full ACK. Ralf From ville.skytta at iki.fi Mon Feb 27 18:47:22 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 27 Feb 2006 20:47:22 +0200 Subject: owners owners.list,1.681,1.682 In-Reply-To: <14126.129.42.161.36.1141042475.squirrel@jdub.homelinux.org> References: <200602271003.k1RA3BMF004088@cvs-int.fedora.redhat.com> <20060227130538.0fd5a8b0.bugs.michael@gmx.net> <14126.129.42.161.36.1141042475.squirrel@jdub.homelinux.org> Message-ID: <1141066042.25729.9.camel@bobcat.mine.nu> On Mon, 2006-02-27 at 06:14 -0600, Josh Boyer wrote: > > On Mon, 27 Feb 2006 05:02:38 -0500, Hans de Goede wrote: > > > >> Author: jwrdegoede > >> > >> Update of /cvs/extras/owners > >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv4070/owners > >> > >> Modified Files: > >> owners.list > >> Log Message: > >> Add myself as co-owner of allegro > > > > You broke it. The file format doesn't work like that. > > > >> -Fedora Extras|allegro|A game programming > >> library|jnovy at redhat.com|extras-qa at fedoraproject.org| > >> +Fedora Extras|allegro|A game programming > >> library|jnovy at redhat.com|j.w.r.degoede at hhs.nl|extras-qa at fedoraproject.org| > > > > You want: > > > > Fedora Extras|allegro|A game programming > > library|jnovy at redhat.com|extras-qa at fedoraproject.org|j.w.r.degoede at hhs.nl > > FYI, I did that for the tla package the other day and it didn't work. Actually, you made the same mistake[0] as Hans above, and I fixed it afterwards changing it to the latter form :). Looks like the changes don't propagate to Bugzilla though. [0] Assuming the format described at top of owners.list is correct. From wart at kobold.org Mon Feb 27 18:49:59 2006 From: wart at kobold.org (Michael Thomas) Date: Mon, 27 Feb 2006 10:49:59 -0800 Subject: angband license In-Reply-To: <440148A7.2010807@fedoraproject.org> References: <440146B8.60209@kobold.org> <440148A7.2010807@fedoraproject.org> Message-ID: <440349D7.9020902@kobold.org> Rahul Sundaram wrote: > Wart wrote: > >> While I was packaging angband, I came across this questionable license >> text. Before I spend too much time with this, I wanted to verify that >> the first paragraph is valid. In particular, it says that the software >> can be copied and distributed for non-for-profit purposes, that is, not >> for commercial purposes. Does this disqualify it as an OSI-compatible >> license? >> >> >> > Yes it does. It is not a OSI compatible since the OSI definition, claus > 6 disallows a OSI license to discriminate against fields of endeavor. > Refer to http://opensource.org/docs/definition.php for more details. Thanks for the clarification. I'll try to get it into livna instead. --Wart -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From ville.skytta at iki.fi Mon Feb 27 18:50:54 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 27 Feb 2006 20:50:54 +0200 Subject: frustrated newcomers AND orphaned packages (Was: Rebuild status of FE5) In-Reply-To: <4402B6F8.8050604@hhs.nl> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <4402965F.2070707@users.sourceforge.net> <1141020541.16413.18.camel@rivendell.home.local> <4402B6F8.8050604@hhs.nl> Message-ID: <1141066254.25729.12.camel@bobcat.mine.nu> On Mon, 2006-02-27 at 09:23 +0100, Hans de Goede wrote: > [root at shalem ~]# repoquery -q --whatrequires libshout.so.2 > [root at shalem ~]# repoquery -q --whatrequires libshout.so.2()(64bit) > -bash: syntax error near unexpected token `(' > [root at shalem ~]# repoquery -q --whatrequires 'libshout.so.2()(64bit)' > [root at shalem ~]# Somewhat OT: "repoquery --whatrequires --alldeps libshout" is an easier alternative to that. From orion at cora.nwra.com Mon Feb 27 18:54:26 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 27 Feb 2006 11:54:26 -0700 Subject: buildsystem on devel unable to run kde-config In-Reply-To: <20060226210458.GB4879@truch.net> References: <20060226210458.GB4879@truch.net> Message-ID: <44034AE2.4010202@cora.nwra.com> Matthew D Truch wrote: > Greetings, > > I'm having a little trouble building kst (a KDE app) on the devel > buildsystem, which builds fine on FC-4 systems. > > Configure fails with the following error: > checking for kde-config... /usr/bin/kde-config > /usr/bin/kde-config: error while loading shared libraries: > libqt-mt.so.3: cannot open shared object file: No such file or directory > configure: error: /usr/bin/kde-config --prefix outputed the non existant > prefix '' for kdelibs. > This means it has been moved since you installed it. > This won't work. Please recompile kdelibs for the new prefix. I'm seeing the same. Can't reproduce locally in mock on my FC4-based build machine. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From ville.skytta at iki.fi Mon Feb 27 18:59:41 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 27 Feb 2006 20:59:41 +0200 Subject: Fedora Extras 4 Package Build Report (broken dep) In-Reply-To: <4403476C.9060803@feuerpokemon.de> References: <20060227181305.B89287FD0@extras64.linux.duke.edu> <4403476C.9060803@feuerpokemon.de> Message-ID: <1141066781.25729.17.camel@bobcat.mine.nu> On Mon, 2006-02-27 at 19:39 +0100, dragoran wrote: > openal-0.0.9-0.3.20060226 100% |=========================| 8.1 kB 00:00 > ---> Package openal.x86_64 0:0.0.9-0.3.20060226cvs.fc4 set to be updated > --> Running transaction check > --> Processing Dependency: libopenal.so.0()(64bit) for package: blender > --> Finished Dependency Resolution > Error: Missing Dependency: libopenal.so.0()(64bit) is needed by package > blender > seems like blender needs a rebuild.. Nope, openal will revert to the previous soname in 0.0.9-0.4.* > should I fill a bug? Already reported and also discussed on this list. https://bugzilla.redhat.com/181989 From florin at andrei.myip.org Mon Feb 27 19:02:45 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Mon, 27 Feb 2006 11:02:45 -0800 Subject: Extras Lists Transition Plan In-Reply-To: <44033FC8.9030700@redhat.com> References: <44033FC8.9030700@redhat.com> Message-ID: <1141066965.17644.9.camel@rivendell.home.local> On Mon, 2006-02-27 at 13:07 -0500, Warren Togami wrote: > fedora-extras-list > fedora-extras-review-list > fedora-extras-bugs-list My prayers have been answered. :-) Thank you! -- Florin Andrei http://florin.myip.org/ From dennis at ausil.us Mon Feb 27 19:05:21 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 27 Feb 2006 13:05:21 -0600 Subject: Extras Lists Transition Plan In-Reply-To: <1141064480.8565.23.camel@mccallum.corsepiu.local> References: <44033FC8.9030700@redhat.com> <1141064480.8565.23.camel@mccallum.corsepiu.local> Message-ID: <200602271305.21373.dennis@ausil.us> On Monday 27 February 2006 12:21, Ralf Corsepius wrote: > * FE and FC should be treated as one entity, therefore the split you are > proposing renders fedora-extras list superfluous, because the topics to > be discussed on your future fedora-extras-list are already covered by > fedora-list. I for one have not been subscribed to fedora-list for at least a couple of years. when the move from redhat to fedora happened i quickly dropped off of fedora-list because of to much noise. so I personally am not aware of what happens there. I do think the proposed split is good. I would ask that a welcome letter come out so that i can set up my procmail filters before to much mail comes in. -- Regards Dennis Gilmore, RHCE Proud Australian From jwboyer at jdub.homelinux.org Mon Feb 27 18:14:02 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 27 Feb 2006 12:14:02 -0600 (CST) Subject: owners owners.list,1.681,1.682 In-Reply-To: <1141066042.25729.9.camel@bobcat.mine.nu> References: <200602271003.k1RA3BMF004088@cvs-int.fedora.redhat.com> <20060227130538.0fd5a8b0.bugs.michael@gmx.net> <14126.129.42.161.36.1141042475.squirrel@jdub.homelinux.org> <1141066042.25729.9.camel@bobcat.mine.nu> Message-ID: <34695.129.42.161.36.1141064042.squirrel@jdub.homelinux.org> > On Mon, 2006-02-27 at 06:14 -0600, Josh Boyer wrote: >> > On Mon, 27 Feb 2006 05:02:38 -0500, Hans de Goede wrote: >> > >> >> Author: jwrdegoede >> >> >> >> Update of /cvs/extras/owners >> >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv4070/owners >> >> >> >> Modified Files: >> >> owners.list >> >> Log Message: >> >> Add myself as co-owner of allegro >> > >> > You broke it. The file format doesn't work like that. >> > >> >> -Fedora Extras|allegro|A game programming >> >> library|jnovy at redhat.com|extras-qa at fedoraproject.org| >> >> +Fedora Extras|allegro|A game programming >> >> library|jnovy at redhat.com|j.w.r.degoede at hhs.nl|extras-qa at fedoraproject.org| >> > >> > You want: >> > >> > Fedora Extras|allegro|A game programming >> > library|jnovy at redhat.com|extras-qa at fedoraproject.org|j.w.r.degoede at hhs.nl >> >> FYI, I did that for the tla package the other day and it didn't work. > > Actually, you made the same mistake[0] as Hans above, and I fixed it > afterwards changing it to the latter form :). Looks like the changes > don't propagate to Bugzilla though. Gah, you're right. I blame a brief moment of dyslexia. josh From jwboyer at jdub.homelinux.org Mon Feb 27 18:16:55 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 27 Feb 2006 12:16:55 -0600 (CST) Subject: Extras Lists Transition Plan In-Reply-To: <200602271305.21373.dennis@ausil.us> References: <44033FC8.9030700@redhat.com> <1141064480.8565.23.camel@mccallum.corsepiu.local> <200602271305.21373.dennis@ausil.us> Message-ID: <58153.129.42.161.36.1141064215.squirrel@jdub.homelinux.org> > On Monday 27 February 2006 12:21, Ralf Corsepius wrote: > >> * FE and FC should be treated as one entity, therefore the split you are >> proposing renders fedora-extras list superfluous, because the topics to >> be discussed on your future fedora-extras-list are already covered by >> fedora-list. > > I for one have not been subscribed to fedora-list for at least a couple > of > years. when the move from redhat to fedora happened i quickly dropped > off > of fedora-list because of to much noise. so I personally am not aware of > what happens there. > > I do think the proposed split is good. +1 > > I would ask that a welcome letter come out so that i can set up my > procmail > filters before to much mail comes in. +2 josh From bugzilla at redhat.com Mon Feb 27 19:12:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 14:12:20 -0500 Subject: [Bug 170131] Review Request: php-extras - Additional PHP modules from the standard PHP distribution In-Reply-To: Message-ID: <200602271912.k1RJCKIP014633@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-extras - Additional PHP modules from the standard PHP distribution https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170131 ------- Additional Comments From bugs.michael at gmx.net 2006-02-27 14:12 EST ------- > These are modules which have THE SAME source as the Core php package > (i.e., common tarball). It would be strange if the Core php package > will be upgraded, but php-extras still use another, obsoleted source... Unconvincing. Surely you would follow with a minor update in Extras, too, wouldn't you? IMO, the version in this dependency introduces breakage at the depsolver level, whereas no API/ABI breakage is found in the php module implementation itself. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugs.michael at gmx.net Mon Feb 27 19:24:57 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 27 Feb 2006 20:24:57 +0100 Subject: buildsystem on devel unable to run kde-config In-Reply-To: <20060226210458.GB4879@truch.net> References: <20060226210458.GB4879@truch.net> Message-ID: <20060227202457.29624a00.bugs.michael@gmx.net> On Sun, 26 Feb 2006 16:04:58 -0500, Matthew D Truch wrote: > Greetings, > > I'm having a little trouble building kst (a KDE app) on the devel > buildsystem, which builds fine on FC-4 systems. > > Configure fails with the following error: > checking for kde-config... /usr/bin/kde-config > /usr/bin/kde-config: error while loading shared libraries: > libqt-mt.so.3: cannot open shared object file: No such file or directory > configure: error: /usr/bin/kde-config --prefix outputed the non existant > prefix '' for kdelibs. > This means it has been moved since you installed it. > This won't work. Please recompile kdelibs for the new prefix. > > The full logs are available at: > http://buildsys.fedoraproject.org/logs/fedora-development-extras/5288-kst-1.2.0-9.fc5/i386/build.log > > The shared library kde-config complains about, libqt-mt.so.3, is > included in the qt rpm, which mock does claim to have installed. > > Any help would be greatly appreciated. Thanks. Have you noticed all the other errors in the build log? [...] Install: libXrandr-devel.i386 0:1.1.0.2-2.2 - cerror: rpmtsOrder failed, 9 elements remain /var/tmp/rpm-tmp.64943: line 1: update-desktop-database: command not found error: %post(redhat-menus-6.6.5-1.noarch) scriptlet failed, exit status 127 update-desktop-database: error while loading shared libraries: libglib-2.0.so.0: cannot open shared object file: No such file or directory /var/tmp/rpm-tmp.38050: line 4: /usr/bin/gtk-update-icon-cache: No such file or directory /var/tmp/rpm-tmp.38050: line 4: /usr/bin/gtk-update-icon-cache: No such file or directory /var/tmp/rpm-tmp.38050: line 4: /usr/bin/gtk-update-icon-cache: No such file or directory error: %post(redhat-artwork-0.240-1.i386) scriptlet failed, exit status 127 /usr/bin/gdk-pixbuf-query-loaders-32: error while loading shared libraries: libgmodule-2.0.so.0: cannot open shared object file: No such file or directory /usr/bin/gtk-query-immodules-2.0-32: error while loading shared libraries: libpangocairo-1.0.so.0: cannot open shared object file: No such file or directory error: %post(gtk2-2.8.12-8.i386) scriptlet failed, exit status 127 /usr/bin/gtk-update-icon-cache: error while loading shared libraries: libpangocairo-1.0.so.0: cannot open shared object file: No such file or directory /usr/bin/pango-querymodules-32: error while loading shared libraries: libXft.so.2: cannot open shared object file: No such file or directory error: %post(pango-1.11.5-2.i386) scriptlet failed, exit status 127 /usr/bin/gtk-update-icon-cache: error while loading shared libraries: libXi.so.6: cannot open shared object file: No such file or directory ore Install: libXrender.i386 0:0.9.0.2-3.2 - core [...] From j.w.r.degoede at hhs.nl Mon Feb 27 19:51:08 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 27 Feb 2006 20:51:08 +0100 Subject: new wiki page: Contacting fellow packagers from other distros Message-ID: <4403582C.7030200@hhs.nl> Hi all, After spending a lot of time patching up (already public) scorched3d security holes I thought it was a good idea to share the results not only with upstream but also with other distros. As a result of this I've been building a list of other distro packager address lists, which is now in the wiki: http://fedoraproject.org/wiki/ContactingOtherDistroPackagers Questions: 1) currently there is no link to this on the main page, where should I put one / what is a good place for this? 2) Anyone no similar links for other distros? Regards, Hans From j.w.r.degoede at hhs.nl Mon Feb 27 19:52:17 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 27 Feb 2006 20:52:17 +0100 Subject: new wiki page: Contacting fellow packagers from other distros In-Reply-To: <4403582C.7030200@hhs.nl> References: <4403582C.7030200@hhs.nl> Message-ID: <44035871.8060505@hhs.nl> Hans de Goede wrote: > Hi all, > > After spending a lot of time patching up (already public) scorched3d > security holes I thought it was a good idea to share the results not > only with upstream but also with other distros. > > As a result of this I've been building a list of other distro packager > address lists, which is now in the wiki: > http://fedoraproject.org/wiki/ContactingOtherDistroPackagers > > Questions: > > 1) currently there is no link to this on the main page, where should I > put one / what is a good place for this? > 2) Anyone no similar links for other distros? > > > Regards, > > Hans > p.s. Maybe we should create such a page too? From matt at truch.net Mon Feb 27 19:44:37 2006 From: matt at truch.net (Matthew D Truch) Date: Mon, 27 Feb 2006 14:44:37 -0500 Subject: buildsystem on devel unable to run kde-config In-Reply-To: <20060227202457.29624a00.bugs.michael@gmx.net> References: <20060226210458.GB4879@truch.net> <20060227202457.29624a00.bugs.michael@gmx.net> Message-ID: <20060227194437.GA14151@truch.net> On Mon, Feb 27, 2006 at 08:24:57PM +0100, Michael Schwendt wrote: > Have you noticed all the other errors in the build log? > > [...] > Install: libXrandr-devel.i386 0:1.1.0.2-2.2 - cerror: rpmtsOrder failed, 9 elements remain > /var/tmp/rpm-tmp.64943: line 1: update-desktop-database: command not found > error: %post(redhat-menus-6.6.5-1.noarch) scriptlet failed, exit status 127 > update-desktop-database: error while loading shared libraries: libglib-2.0.so.0: cannot open shared object file: No such file or directory > /var/tmp/rpm-tmp.38050: line 4: /usr/bin/gtk-update-icon-cache: No such file or directory > /var/tmp/rpm-tmp.38050: line 4: /usr/bin/gtk-update-icon-cache: No such file or directory > /var/tmp/rpm-tmp.38050: line 4: /usr/bin/gtk-update-icon-cache: No such file or directory > error: %post(redhat-artwork-0.240-1.i386) scriptlet failed, exit status 127 > /usr/bin/gdk-pixbuf-query-loaders-32: error while loading shared libraries: libgmodule-2.0.so.0: cannot open shared object file: No such file or directory > /usr/bin/gtk-query-immodules-2.0-32: error while loading shared libraries: libpangocairo-1.0.so.0: cannot open shared object file: No such file or directory > error: %post(gtk2-2.8.12-8.i386) scriptlet failed, exit status 127 > /usr/bin/gtk-update-icon-cache: error while loading shared libraries: libpangocairo-1.0.so.0: cannot open shared object file: No such file or directory > /usr/bin/pango-querymodules-32: error while loading shared libraries: libXft.so.2: cannot open shared object file: No such file or directory > error: %post(pango-1.11.5-2.i386) scriptlet failed, exit status 127 > /usr/bin/gtk-update-icon-cache: error while loading shared libraries: libXi.so.6: cannot open shared object file: No such file or directory > ore > Install: libXrender.i386 0:0.9.0.2-3.2 - core > [...] I missed that. Thanks. Interesting. I take it either the build system or the devel core rpms (libXrandr-devel) are fubar. -- "Only two things are infinite, the universe, and human stupidity, and I'm not sure about the former -- Einstein." -------------------------- Matthew Truch Department of Physics Brown University matt at truch.net http://matt.truch.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From matt at truch.net Mon Feb 27 19:45:39 2006 From: matt at truch.net (Matthew D Truch) Date: Mon, 27 Feb 2006 14:45:39 -0500 Subject: buildsystem on devel unable to run kde-config In-Reply-To: References: <20060226210458.GB4879@truch.net> Message-ID: <20060227194539.GB14151@truch.net> On Mon, Feb 27, 2006 at 09:09:01AM -0600, Rex Dieter wrote: > > Try requeue'ing the failed job to see if you can reproduce the problem. > > I've built several KDE apps not too long ago without any problems (at > least not related to this anyway). Requeueing did not help. -- "Things are more like they are today than they ever have been before." -------------------------- Matthew Truch Department of Physics Brown University matt at truch.net http://matt.truch.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugzilla at redhat.com Mon Feb 27 19:46:58 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 14:46:58 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602271946.k1RJkwNH024780@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From orion at cora.nwra.com 2006-02-27 14:46 EST ------- (In reply to comment #33) > Builds in mock. There are still some libtool and rpmlint errors and warnings > that I am not sure about what do do with.. Please read the "rpmlint -i" messages and the packaging guidelines on the wiki for guidance. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 19:52:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 14:52:20 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602271952.k1RJqK0j026379@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From tibbs at math.uh.edu 2006-02-27 14:52 EST ------- Look, he's trying to come up with a solution that doesn't involve hacking 130 downstream packages. If you don't want to be constructive then please just don't post. Steve, I'm working on filtering the requires and it's really simple; you just need six lines in %prep. Looking through what other packages in Core and Extras do, I see that this is really very common: cat << EOF > %{name}-req #!/bin/sh %{__perl_requires} $* | sed -e '/perl(mixin)/d' EOF %define __perl_requires %{_builddir}/%{name}-%{version}/%{name}-req chmod +x %{__perl_requires} (You can also reference an external script as %{SOURCE99} if you find emitting it from the spec distasteful.) Finally, I was hacking on the packages and noticed that Spiffy also provides perl(DB), which I think is broken. (It overrides the super() method in the DB package, and so it has a "package DB" statement which RPM turns into Provides: perl(DB).) This has the capacity to break other things, so Spiffy is definitely going to need a __perl_provides override as well: cat < %{name}-prov #!/bin/sh %{__perl_provides} $* | sed -e '/perl(DB)/d' XXX %define __perl_provides %{_builddir}/Spiffy-%{version}/%{name}-prov chmod +x %{__perl_provides} With this, things are working cleanly. I know it's a pain to have to do this in all of the modules, but I think this is going to be the only way to move forward. I will try to get these overrides into the Perl template and I suggest that they get into cpanspec as well. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From ville.skytta at iki.fi Mon Feb 27 20:03:14 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 27 Feb 2006 22:03:14 +0200 Subject: new wiki page: Contacting fellow packagers from other distros In-Reply-To: <44035871.8060505@hhs.nl> References: <4403582C.7030200@hhs.nl> <44035871.8060505@hhs.nl> Message-ID: <1141070594.25729.25.camel@bobcat.mine.nu> On Mon, 2006-02-27 at 20:52 +0100, Hans de Goede wrote: > Hans de Goede wrote: > > 2) Anyone no similar links for other distros? FreeBSD added. > Maybe we should create such a page too? https://bugzilla.redhat.com/bugzilla/describecomponents.cgi?product=Fedora%20Core https://bugzilla.redhat.com/bugzilla/describecomponents.cgi?product=Fedora%20Extras (email addresses only visible when logged into Bugzilla) http://cvs.fedora.redhat.com/viewcvs/*checkout*/owners/owners.list?root=extras Maybe add those to the new Wiki page? From tibbs at math.uh.edu Mon Feb 27 20:06:18 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 27 Feb 2006 14:06:18 -0600 Subject: angband license In-Reply-To: <440349D7.9020902@kobold.org> (Michael Thomas's message of "Mon, 27 Feb 2006 10:49:59 -0800") References: <440146B8.60209@kobold.org> <440148A7.2010807@fedoraproject.org> <440349D7.9020902@kobold.org> Message-ID: >>>>> "MT" == Michael Thomas writes: MT> Thanks for the clarification. I'll try to get it into livna MT> instead. Hopefully they'll manage to get everything relicensed so it can move to Extras in the future. - J< From bugzilla at redhat.com Mon Feb 27 20:07:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 15:07:33 -0500 Subject: [Bug 183255] New: Review Request: xscreensaver Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183255 Summary: Review Request: xscreensaver Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: rstrode at redhat.com QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://people.freedesktop.org/~halfline/xscreensaver.spec SRPM Name or Url: http://people.freedesktop.org/~halfline/xscreensaver-4.24-2.src.rpm Description: This is the xscreensaver package being moved from core. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 20:16:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 15:16:48 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602272016.k1RKGm1q031430@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From steve at silug.org 2006-02-27 15:16 EST ------- I missed the perl(DB) thing. That's fixed in -3. http://ftp.kspei.com/pub/steve/rpms/perl-Spiffy-0.30-3.src.rpm I still *really* don't like the idea of modifying (potentially) nearly every Kwiki package to filter out the perl(mixin) thing, especially since there's no easy way to tell if the dependency will get picked up ahead of time. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 20:19:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 15:19:07 -0500 Subject: [Bug 183255] Review Request: xscreensaver In-Reply-To: Message-ID: <200602272019.k1RKJ7uJ032089@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xscreensaver https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183255 wtogami at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wtogami at redhat.com ------- Additional Comments From wtogami at redhat.com 2006-02-27 15:19 EST ------- (not a complete review, just a comment) %define default_text %{_datadir}/doc/fedora-release-4/RELEASE-NOTES This will change of course change in FC5. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From j.w.r.degoede at hhs.nl Mon Feb 27 20:39:38 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 27 Feb 2006 21:39:38 +0100 Subject: new wiki page: Contacting fellow packagers from other distros In-Reply-To: <1141070594.25729.25.camel@bobcat.mine.nu> References: <4403582C.7030200@hhs.nl> <44035871.8060505@hhs.nl> <1141070594.25729.25.camel@bobcat.mine.nu> Message-ID: <4403638A.7060204@hhs.nl> Ville Skytt? wrote: > On Mon, 2006-02-27 at 20:52 +0100, Hans de Goede wrote: >> Hans de Goede wrote: > >>> 2) Anyone no similar links for other distros? > > FreeBSD added. > >> Maybe we should create such a page too? > > https://bugzilla.redhat.com/bugzilla/describecomponents.cgi?product=Fedora%20Core > https://bugzilla.redhat.com/bugzilla/describecomponents.cgi?product=Fedora%20Extras > (email addresses only visible when logged into Bugzilla) > > http://cvs.fedora.redhat.com/viewcvs/*checkout*/owners/owners.list?root=extras > > Maybe add those to the new Wiki page? > Yes, that sounds like a plan. No answer to question 1 (where to put a link to this page?) Regards, Hans From bugzilla at redhat.com Mon Feb 27 20:24:22 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 15:24:22 -0500 Subject: [Bug 183255] Review Request: xscreensaver In-Reply-To: Message-ID: <200602272024.k1RKOMEl001183@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xscreensaver https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183255 ------- Additional Comments From wtogami at redhat.com 2006-02-27 15:24 EST ------- I guess I read through the entire spec anyway, and the rest of it looks fine. Just fix the above problem and it is APPROVED. Proceed to edit the owners list, cvs-import your package, make tag and make build. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 20:31:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 15:31:35 -0500 Subject: [Bug 183255] Review Request: xscreensaver In-Reply-To: Message-ID: <200602272031.k1RKVZK5003290@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xscreensaver https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183255 rstrode at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |WONTFIX ------- Additional Comments From rstrode at redhat.com 2006-02-27 15:31 EST ------- So we decided to keep this in Core until FC6. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From orion at cora.nwra.com Mon Feb 27 20:39:49 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 27 Feb 2006 13:39:49 -0700 Subject: buildsystem on devel unable to run kde-config In-Reply-To: <20060227202457.29624a00.bugs.michael@gmx.net> References: <20060226210458.GB4879@truch.net> <20060227202457.29624a00.bugs.michael@gmx.net> Message-ID: <44036395.5020000@cora.nwra.com> Michael Schwendt wrote: > On Sun, 26 Feb 2006 16:04:58 -0500, Matthew D Truch wrote: > > Have you noticed all the other errors in the root log? > > [...] > error: rpmtsOrder failed, 9 elements remain Well, this is from librpm.so. So perhaps a yum or rpm bug? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From bugzilla at redhat.com Mon Feb 27 20:38:58 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 15:38:58 -0500 Subject: [Bug 183255] Review Request: xscreensaver In-Reply-To: Message-ID: <200602272038.k1RKcw3L005735@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xscreensaver https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183255 wtogami at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From wtogami at redhat.com 2006-02-27 15:38 EST ------- NEEDSWORK actually, there are a few more things that should be cleared up [warren at caprica tmp]$ rpmlint xscreensaver-4.24-2.src.rpm W: xscreensaver buildprereq-use bc, pam-devel E: xscreensaver broken-syntax-in-scriptlet-requires BuildPrereq: bc, pam-devel W: xscreensaver buildprereq-use libX11-devel, libXScrnSaver-devel, libXext-devel E: xscreensaver broken-syntax-in-scriptlet-requires BuildPrereq: libX11-devel, libXScrnSaver-devel, libXext-devel W: xscreensaver buildprereq-use libXinerama-devel E: xscreensaver broken-syntax-in-scriptlet-requires BuildPrereq: libXinerama-devel W: xscreensaver buildprereq-use xorg-x11-proto-devel E: xscreensaver broken-syntax-in-scriptlet-requires BuildPrereq: xorg-x11-proto-devel W: xscreensaver buildprereq-use gtk2-devel libglade2-devel E: xscreensaver broken-syntax-in-scriptlet-requires BuildPrereq: gtk2-devel libglade2-devel All of the above makes little sense to me and might not be actual problems. Anybody else know what this means? W: xscreensaver patch-not-applied Patch2: xscreensaver-4.21-dont-ping-if-not-root.patch W: xscreensaver patch-not-applied Patch4: xscreensaver-4.22-fix-man-pages.patch If patches are not applied, usually this indicates it should be cleaned from the spec? (There are some weird exceptions to this like within gaim.) Then there's some build failure, it could be more missing BuildReq's. This will fail in Extras buildsys where it might not fail in Core beehive. gcc -pedantic -Wall -Wstrict-prototypes -Wnested-externs -std=c89 -U__STRICT_ANSI__ -c -I. -I../../driver -I../../driver/../utils -I.. -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/libglade-2.0 -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include -DHACK_CONFIGURATION_PATH='"/usr/share/xscreensaver/config"' -DHAVE_CONFIG_H -DDEFAULT_ICONDIR='"/usr/share/xscreensaver/glade"' -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables \ ../../driver/demo-Gtk-conf.c In file included from /usr/include/gtk-2.0/gtk/gtkactiongroup.h:34, from /usr/include/gtk-2.0/gtk/gtk.h:38, from ../../driver/demo-Gtk-conf.c:63: /usr/include/gtk-2.0/gtk/gtkitemfactory.h:50: warning: function declaration isn't a prototype gcc -pedantic -Wall -Wstrict-prototypes -Wnested-externs -std=c89 -U__STRICT_ANSI__ -L/usr/lib -o xscreensaver-demo-Gtk prefs.o dpms.o remote.o exec.o ../utils/resources.o ../utils/usleep.o ../utils/visual.o demo-Gtk.o demo-Gtk-conf.o \ -Wl,--export-dynamic -lglade-2.0 -lgtk-x11-2.0 -lxml2 -lz -lgdk-x11-2.0 -latk-1.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgdk_pixbuf_xlib-2.0 -lgdk_pixbuf-2.0 -lm -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lgdk_pixbuf_xlib-2.0 -lgdk_pixbuf-2.0 -lm -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lSM -lICE \ -lXt -lX11 -lXinerama -lXext demo-Gtk.o: In function `demo_ehandler':../../driver/demo-Gtk.c:4330: undefined reference to `XmuPrintDefaultErrorMessage' collect2: ld returned 1 exit status make[1]: *** [xscreensaver-demo-Gtk] Error 1 make[1]: Leaving directory `/home/builder6/rpmbuild/BUILD/xscreensaver-4.24/i686-redhat-linux-gnu/driver' make: *** [default] Error 5 error: Bad exit status from /var/tmp/rpm-tmp.53103 (%build) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 20:41:06 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 15:41:06 -0500 Subject: [Bug 183256] Add requires and provides filtering to the Perl template In-Reply-To: Message-ID: <200602272041.k1RKf6V2006463@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Add requires and provides filtering to the Perl template https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183256 ville.skytta at iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO CC| |fedora-extras- | |list at redhat.com ------- Additional Comments From ville.skytta at iki.fi 2006-02-27 15:41 EST ------- (In reply to comment #0) > If you think that's too much to clutter the template with then I understand; > I'll try to get it added to the wiki in any case. Personally I do think it's too much as this stuff is relatively rarely needed anyway, but let's see if folks on fedora-extras-list have differing opinions. There's also the same stuff for filtering spurious perl(...) autodependencies, but luckily that's even more rare. Some nitpickery about the suggested boilerplate: > cat < %{name}-prov This should be "... << \XXX ..." (note the backslash) to prevent too early shell variable expansion (such as with "$*" below). And EOF sounds better than XXX to me. > #!/bin/sh > %{__perl_provides} $* | sed -e '/perl(unwanted_provide)/d' No sed in perl packages, for god's sake! :) I'd personally use grep -v. > XXX > %define __perl_provides %{_builddir}/%{name}-%{version}/%{name}-prov %{name}-%{version} practically never works for perl module packages in this context, but needs to be Foo-Bar-%{version}. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From dcbw at redhat.com Mon Feb 27 20:58:51 2006 From: dcbw at redhat.com (Dan Williams) Date: Mon, 27 Feb 2006 15:58:51 -0500 Subject: buildsystem on devel unable to run kde-config In-Reply-To: <20060226210458.GB4879@truch.net> References: <20060226210458.GB4879@truch.net> Message-ID: <1141073931.4859.11.camel@localhost.localdomain> On Sun, 2006-02-26 at 16:04 -0500, Matthew D Truch wrote: > Greetings, > > I'm having a little trouble building kst (a KDE app) on the devel > buildsystem, which builds fine on FC-4 systems. > > Configure fails with the following error: > checking for kde-config... /usr/bin/kde-config > /usr/bin/kde-config: error while loading shared libraries: > libqt-mt.so.3: cannot open shared object file: No such file or directory > configure: error: /usr/bin/kde-config --prefix outputed the non existant > prefix '' for kdelibs. > This means it has been moved since you installed it. > This won't work. Please recompile kdelibs for the new prefix. > > The full logs are available at: > http://buildsys.fedoraproject.org/logs/fedora-development-extras/5288-kst-1.2.0-9.fc5/i386/build.log > > The shared library kde-config complains about, libqt-mt.so.3, is > included in the qt rpm, which mock does claim to have installed. > > Any help would be greatly appreciated. Thanks. There's currently a circular dependency between gtk2 and hicolor-icon-theme, it turns out. That's screwing up the RPM transaction and likely causing stuff to fail here. After the buildroot is set up, the kde-config is failing because it can't find libqt-mt.so.3, of course. This seems to be because the information for ld isn't up to date, likely because stuff in the RPM transaction failed. Running an ldconfig in the buildroot fixed the kde-config issue. I'd say wait until the issues with gtk2 + hicolor-icon-theme are sorted out, then retry the build and we'll see where it fails next. Dan From bugzilla at redhat.com Mon Feb 27 21:01:43 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 16:01:43 -0500 Subject: [Bug 183256] Add requires and provides filtering to the Perl template In-Reply-To: Message-ID: <200602272101.k1RL1hoB013791@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Add requires and provides filtering to the Perl template https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183256 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Status|NEEDINFO |ASSIGNED ------- Additional Comments From tibbs at math.uh.edu 2006-02-27 16:01 EST ------- You illustrate precisely why this needs to be standardized. Much of it is lifted directly from the examples I found in Core and Extras CVS, although I admit to flubbing the \EOF thing. Every example I found in what I currently had checked out of CVS (perl, subversion, rt3) uses sed. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 27 21:01:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 16:01:49 -0500 Subject: [Bug 183255] Review Request: xscreensaver In-Reply-To: Message-ID: <200602272101.k1RL1nuV013826@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xscreensaver https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183255 ------- Additional Comments From wtogami at redhat.com 2006-02-27 16:01 EST ------- BuildRequires: libXmu-devel -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 21:03:32 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 16:03:32 -0500 Subject: [Bug 181068] Review Request: html401-dtds - HTML 4.01 document type definitions In-Reply-To: Message-ID: <200602272103.k1RL3WKY014371@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: html401-dtds - HTML 4.01 document type definitions https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181068 ------- Additional Comments From veillard at redhat.com 2006-02-27 16:03 EST ------- w.r.t. 401, I don't think the W3C will ever release an updated version of the SGML HTML DTDs. All new developments have been around XML anyway. "Cast in stone" Daniel -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 21:10:03 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 16:10:03 -0500 Subject: [Bug 183255] Review Request: xscreensaver In-Reply-To: Message-ID: <200602272110.k1RLA32a016895@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: xscreensaver https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183255 ------- Additional Comments From ville.skytta at iki.fi 2006-02-27 16:09 EST ------- Warren, you noticed comment 3 and CLOSED WONTFIX, right? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 21:12:19 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 16:12:19 -0500 Subject: [Bug 183256] Add requires and provides filtering to the Perl template In-Reply-To: Message-ID: <200602272112.k1RLCJ1C017572@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Add requires and provides filtering to the Perl template https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183256 ------- Additional Comments From ville.skytta at iki.fi 2006-02-27 16:12 EST ------- Standardized: sure, but in the spec template: still IMHO no. sed vs grep: note the smiley... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Feb 27 21:17:06 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 16:17:06 -0500 Subject: [Bug 181068] Review Request: html401-dtds - HTML 4.01 document type definitions In-Reply-To: Message-ID: <200602272117.k1RLH6e8018669@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: html401-dtds - HTML 4.01 document type definitions https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181068 ville.skytta at iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |veillard at redhat.com ------- Additional Comments From ville.skytta at iki.fi 2006-02-27 16:17 EST ------- Fully agreed, but I'm afraid there might be some confusion here. Daniel, could you clarify if/what you imply in practical packaging terms with "w.r.t. 401"? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From dcbw at redhat.com Mon Feb 27 21:19:25 2006 From: dcbw at redhat.com (Dan Williams) Date: Mon, 27 Feb 2006 16:19:25 -0500 Subject: buildsystem on devel unable to run kde-config In-Reply-To: <44036395.5020000@cora.nwra.com> References: <20060226210458.GB4879@truch.net> <20060227202457.29624a00.bugs.michael@gmx.net> <44036395.5020000@cora.nwra.com> Message-ID: <1141075165.4859.13.camel@localhost.localdomain> On Mon, 2006-02-27 at 13:39 -0700, Orion Poplawski wrote: > Michael Schwendt wrote: > > On Sun, 26 Feb 2006 16:04:58 -0500, Matthew D Truch wrote: > > > > Have you noticed all the other errors in the root log? > > > > [...] > > error: rpmtsOrder failed, 9 elements remain > > Well, this is from librpm.so. So perhaps a yum or rpm bug? Circular dep in Core. Dan From bugzilla at redhat.com Mon Feb 27 22:10:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 17:10:08 -0500 Subject: [Bug 181404] Review Request: emacs-muse In-Reply-To: Message-ID: <200602272210.k1RMA8YG002679@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 ------- Additional Comments From jonathan.underwood at gmail.com 2006-02-27 17:10 EST ------- Updated spec file and src rpm which builds Muse for both emacs and Xemacs can be found at: http://physics.open.ac.uk/~ju83/muse.spec http://physics.open.ac.uk/~ju83/muse-3.02.6a-2.src.rpm This source file generates several packages: The common rpm that is generated is called muse, which contains documentation files. emacs-muse and xemacs-muse contain the lisp files for emacs and xemacs, and emacs-muse-el and xemacs-muse-el install the source lisp files. Building for both emacs and xemacs AND complying with the naming guidelines for fedora extras is really proving difficult, but I think this is the best compromise. I would really appreciate a review and a sponsor, as I have other packages to contribute, but this is my first package. Thanks for looking :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 22:10:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 17:10:18 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602272210.k1RMAIsV002712@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From steve at silug.org 2006-02-27 17:10 EST ------- Given that there is a real mixin.pm, I'm checking now to see if Spiffy is a drop-in replacement for it. If it is, we *should* be able to include a fake mixin.pm that just does "use Spiffy". Otherwise, I guess I have to filter the perl(mixin) dependency. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From jspaleta at gmail.com Mon Feb 27 22:23:08 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 27 Feb 2006 17:23:08 -0500 Subject: OpenAL 0.0.9 problems In-Reply-To: <440212E1.5030505@hhs.nl> References: <1140981890.23109.4.camel@scriabin.tannenrauch.ch> <440212E1.5030505@hhs.nl> Message-ID: <604aa7910602271423n74bdadccke872f01a0214fdbe@mail.gmail.com> On 2/26/06, Hans de Goede wrote: > This is _not_ intended to put shame to Andreas who I know as a great > Extras contributer, but to watch and learn! Would this situation have been helped by having a per-branch testing or scratch area made available to put the new cvs based binaries in? -jef From bugzilla at redhat.com Mon Feb 27 22:54:46 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 17:54:46 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602272254.k1RMskLP018443@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From steve at silug.org 2006-02-27 17:54 EST ------- OK, I've dropped the bogus mixin.pm. http://ftp.kspei.com/pub/steve/rpms/perl-Spiffy-0.30-4.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 22:57:04 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 17:57:04 -0500 Subject: [Bug 183038] Review Request: perl-IO-All In-Reply-To: Message-ID: <200602272257.k1RMv4XG019147@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-IO-All https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183038 ------- Additional Comments From steve at silug.org 2006-02-27 17:57 EST ------- http://ftp.kspei.com/pub/steve/rpms/perl-IO-All-0.33-2.src.rpm * Mon Feb 27 2006 Steven Pritchard 0.33-2 - Filter Requires: perl(mixin). - Turn off "make test" for now. - Drop explict BR: perl. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 22:57:57 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 17:57:57 -0500 Subject: [Bug 183039] Review Request: perl-Spoon In-Reply-To: Message-ID: <200602272257.k1RMvvKJ019498@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spoon https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183039 ------- Additional Comments From steve at silug.org 2006-02-27 17:57 EST ------- http://ftp.kspei.com/pub/steve/rpms/perl-Spoon-0.23-2.src.rpm * Mon Feb 27 2006 Steven Pritchard 0.23-2 - Drop explicit BR: perl. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 22:58:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 17:58:48 -0500 Subject: [Bug 183040] Review Request: perl-Kwiki In-Reply-To: Message-ID: <200602272258.k1RMwm07019792@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Kwiki https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183040 ------- Additional Comments From steve at silug.org 2006-02-27 17:58 EST ------- http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-0.38-2.src.rpm * Mon Feb 27 2006 Steven Pritchard 0.32-2 - Drop explicit BR: perl. - Filter perl(mixin) dependency. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 22:59:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 17:59:34 -0500 Subject: [Bug 183041] Review Request: perl-Kwiki-ModPerl In-Reply-To: Message-ID: <200602272259.k1RMxY3F019990@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Kwiki-ModPerl https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183041 ------- Additional Comments From steve at silug.org 2006-02-27 17:59 EST ------- http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-ModPerl-0.09-2.src.rpm * Mon Feb 27 2006 Steven Pritchard 0.09-2 - Drop explicit BR: perl. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 23:00:14 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 18:00:14 -0500 Subject: [Bug 183042] Review Request: perl-Kwiki-Archive-Rcs In-Reply-To: Message-ID: <200602272300.k1RN0E7X020144@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Kwiki-Archive-Rcs https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183042 ------- Additional Comments From steve at silug.org 2006-02-27 18:00 EST ------- http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-Archive-Rcs-0.15-2.src.rpm * Mon Feb 27 2006 Steven Pritchard 0.15-2 - Drop explicit BR: perl. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 23:00:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 18:00:44 -0500 Subject: [Bug 183043] Review Request: perl-Kwiki-Revisions In-Reply-To: Message-ID: <200602272300.k1RN0ikN020379@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Kwiki-Revisions https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183043 ------- Additional Comments From steve at silug.org 2006-02-27 18:00 EST ------- http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-Revisions-0.15-2.src.rpm * Mon Feb 27 2006 Steven Pritchard 0.15-2 - Drop explicit BR: perl. - Filter perl(mixin) dependency. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 23:01:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 18:01:53 -0500 Subject: [Bug 183044] Review Request: perl-Kwiki-NewPage In-Reply-To: Message-ID: <200602272301.k1RN1rNM020734@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Kwiki-NewPage https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183044 ------- Additional Comments From steve at silug.org 2006-02-27 18:01 EST ------- http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-NewPage-0.12-2.src.rpm * Mon Feb 27 2006 Steven Pritchard 0.12-2 - Drop explicit BR: perl. - Filter perl(mixin) dependency. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 23:02:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 18:02:35 -0500 Subject: [Bug 183045] Review Request: perl-Kwiki-RecentChanges In-Reply-To: Message-ID: <200602272302.k1RN2ZpJ021005@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Kwiki-RecentChanges https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183045 ------- Additional Comments From steve at silug.org 2006-02-27 18:02 EST ------- http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-RecentChanges-0.13-2.src.rpm * Mon Feb 27 2006 Steven Pritchard 0.13-2 - Drop explicit BR: perl. - Filter perl(mixin) dependency. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 23:03:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 18:03:02 -0500 Subject: [Bug 183047] Review Request: perl-Kwiki-Search In-Reply-To: Message-ID: <200602272303.k1RN32wc021117@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Kwiki-Search https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183047 ------- Additional Comments From steve at silug.org 2006-02-27 18:02 EST ------- http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-Search-0.12-2.src.rpm * Mon Feb 27 2006 Steven Pritchard 0.12-2 - Drop explicit BR: perl. - Filter perl(mixin) dependency. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 23:03:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 18:03:33 -0500 Subject: [Bug 183050] Review Request: perl-Kwiki-UserPreferences In-Reply-To: Message-ID: <200602272303.k1RN3XAt021241@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Kwiki-UserPreferences https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183050 ------- Additional Comments From steve at silug.org 2006-02-27 18:03 EST ------- http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-UserPreferences-0.13-2.src.rpm * Mon Feb 27 2006 Steven Pritchard 0.13-2 - Drop explicit BR: perl. - Filter perl(mixin) dependency. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 23:03:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 18:03:50 -0500 Subject: [Bug 183290] New: Review Request: libipoddevice Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183290 Summary: Review Request: libipoddevice Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: caillon at redhat.com QAContact: fedora-extras-list at redhat.com Spec and SRPM from: http://people.redhat.com/caillon/RPMS/rawhide/banshee/ Description: libipoddevice provides device-level support for Apple's iPods. libipoddevice is written in GObject/C. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 23:03:55 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 18:03:55 -0500 Subject: [Bug 183291] New: Review Request: ipod-sharp Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183291 Summary: Review Request: ipod-sharp Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: caillon at redhat.com QAContact: fedora-extras-list at redhat.com Spec and SRPM from: http://people.redhat.com/caillon/RPMS/rawhide/banshee/ Description: ipod-sharp provides high-level feature support for Apple's iPod and binds libipoddevice. ipod-sharp is written in C# under Mono. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 23:04:06 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 18:04:06 -0500 Subject: [Bug 183052] Review Request: perl-Kwiki-UserName In-Reply-To: Message-ID: <200602272304.k1RN46gm021432@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Kwiki-UserName https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183052 ------- Additional Comments From steve at silug.org 2006-02-27 18:04 EST ------- http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-UserName-0.14-2.src.rpm * Mon Feb 27 2006 Steven Pritchard 0.14-2 - Drop explicit BR: perl. - Filter perl(mixin) dependency. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Mon Feb 27 23:04:17 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 18:04:17 -0500 Subject: [Bug 183292] New: Review Request:
Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183292 Summary: Review Request:
Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: caillon at redhat.com QAContact: fedora-extras-list at redhat.com Spec and SRPM from: http://people.redhat.com/caillon/RPMS/rawhide/banshee/ Description: With Banshee you can easily import, manage, and play selections from your music collection. Banshee allows you to import CDs, sync your music collection to an iPod, play music directly from an iPod, create playlists with songs from your library, and create audio and MP3 CDs from subsets of your library. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From matt at truch.net Mon Feb 27 23:20:42 2006 From: matt at truch.net (Matthew D Truch) Date: Mon, 27 Feb 2006 18:20:42 -0500 Subject: buildsystem on devel unable to run kde-config In-Reply-To: <1141073931.4859.11.camel@localhost.localdomain> References: <20060226210458.GB4879@truch.net> <1141073931.4859.11.camel@localhost.localdomain> Message-ID: <20060227232042.GC14713@truch.net> On Mon, Feb 27, 2006 at 03:58:51PM -0500, Dan Williams wrote: > There's currently a circular dependency between gtk2 and > hicolor-icon-theme, it turns out. That's screwing up the RPM > transaction and likely causing stuff to fail here. > > After the buildroot is set up, the kde-config is failing because it > can't find libqt-mt.so.3, of course. This seems to be because the > information for ld isn't up to date, likely because stuff in the RPM > transaction failed. Running an ldconfig in the buildroot fixed the > kde-config issue. > > I'd say wait until the issues with gtk2 + hicolor-icon-theme are sorted > out, then retry the build and we'll see where it fails next. [Warning: This may be a stupid question.] Is there someone/somehow I should ping people about this problem, or should I assume it'll get resolved on its own? -- "Only two things are infinite, the universe, and human stupidity, and I'm not sure about the former -- Einstein." -------------------------- Matthew Truch Department of Physics Brown University matt at truch.net http://matt.truch.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugzilla at redhat.com Mon Feb 27 23:19:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 18:19:02 -0500 Subject: [Bug 183292] Review Request: banshee In-Reply-To: Message-ID: <200602272319.k1RNJ2rr024879@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: banshee https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183292 ------- Additional Comments From caillon at redhat.com 2006-02-27 18:18 EST ------- Note: my package currently doesn't support devices other than ipods. njb-sharp is required for that, but as I don't have one of those devices, it is probably best I don't maintain that. If someone wants to maintain that (perhaps the maintainer of libnjb in extras-development?) I'll package banshee with that support, but I'd like not to have to wait on that for the banshee packages. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From dcbw at redhat.com Mon Feb 27 23:26:17 2006 From: dcbw at redhat.com (Dan Williams) Date: Mon, 27 Feb 2006 18:26:17 -0500 Subject: buildsystem on devel unable to run kde-config In-Reply-To: <20060227232042.GC14713@truch.net> References: <20060226210458.GB4879@truch.net> <1141073931.4859.11.camel@localhost.localdomain> <20060227232042.GC14713@truch.net> Message-ID: <1141082778.11658.1.camel@localhost.localdomain> On Mon, 2006-02-27 at 18:20 -0500, Matthew D Truch wrote: > On Mon, Feb 27, 2006 at 03:58:51PM -0500, Dan Williams wrote: > > There's currently a circular dependency between gtk2 and > > hicolor-icon-theme, it turns out. That's screwing up the RPM > > transaction and likely causing stuff to fail here. > > > > After the buildroot is set up, the kde-config is failing because it > > can't find libqt-mt.so.3, of course. This seems to be because the > > information for ld isn't up to date, likely because stuff in the RPM > > transaction failed. Running an ldconfig in the buildroot fixed the > > kde-config issue. > > > > I'd say wait until the issues with gtk2 + hicolor-icon-theme are sorted > > out, then retry the build and we'll see where it fails next. > > [Warning: This may be a stupid question.] > > Is there someone/somehow I should ping people about this problem, or > should I assume it'll get resolved on its own? If you feel inclined, file bugs in RH bugzilla, or just wait it out. Consistency of the distro is checked quite often and you should expect that it would get fixed up in a day or two unless there is something like a mass-rebuild going on. Dan From andreas.bierfert at lowlatency.de Mon Feb 27 23:48:55 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Tue, 28 Feb 2006 00:48:55 +0100 Subject: OpenAL 0.0.9 problems In-Reply-To: <604aa7910602271423n74bdadccke872f01a0214fdbe@mail.gmail.com> References: <1140981890.23109.4.camel@scriabin.tannenrauch.ch> <440212E1.5030505@hhs.nl> <604aa7910602271423n74bdadccke872f01a0214fdbe@mail.gmail.com> Message-ID: <20060228004855.5cf94af3@alkaid.a.lan> On Mon, 27 Feb 2006 17:23:08 -0500 "Jeff Spaleta" wrote: > Would this situation have been helped by having a per-branch testing > or scratch area made available to put the new cvs based binaries in? Well that sort of is what I normally do but due to lot of exams and things going on at university and switching to x86_64 and rawhide my setup was and is not complete yet... So yes... - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From bugzilla at redhat.com Mon Feb 27 23:51:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 18:51:20 -0500 Subject: [Bug 174588] Review Request: libopensync-plugin-gpe In-Reply-To: Message-ID: <200602272351.k1RNpKnt031923@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libopensync-plugin-gpe https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174588 andreas.bierfert at lowlatency.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From andreas.bierfert at lowlatency.de 2006-02-27 18:51 EST ------- Thanks. Imported and pushed :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From wart at kobold.org Tue Feb 28 00:09:38 2006 From: wart at kobold.org (Michael Thomas) Date: Mon, 27 Feb 2006 16:09:38 -0800 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <44029B02.6080702@kobold.org> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <20060226212224.00e5b6fd.bugs.michael@gmx.net> <1141019945.808.11.camel@thl.ct.heise.de> <44029B02.6080702@kobold.org> Message-ID: <440394C2.4060306@kobold.org> Wart wrote: > Thorsten Leemhuis wrote: > >>Am Sonntag, den 26.02.2006, 21:22 +0100 schrieb Michael Schwendt: >> >> >>>On Sun, 26 Feb 2006 19:22:26 +0100, Thorsten Leemhuis wrote: >>> >>> >>> >>>>Okay, let's look at the whole situation from a different perspective. >>>>The following list shows maintainers that still have to rebuild more >>>>than 5 packages: >>>>5 nos_AT_utelsystems.com >>> >>>Nils has not signed up since the transition from fedora.us to Fedora >>>Extras. >> >> >>Okay, so they are practically orphaned for at least a year? Wow. >> >>So let's orphan them for real. Anyone interested in on of the following >>packages? >> >>dillo, gktools, gtkterm, neverball, whowatch > > > I can pick up neverball if there are no objections. No objections? None? Whee! :) I emailed Nils to see if he was still interested in maintaining these, but I haven't gotten a reply yet. So is this the right time to add these to OrphanedPackages on the wiki so that others can make claim to them, and claim neverball myself by updating owners.list? --Wart -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From bugzilla at redhat.com Tue Feb 28 00:37:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 19:37:18 -0500 Subject: [Bug 172343] Review Request: libtomoe-gtk In-Reply-To: Message-ID: <200602280037.k1S0bIiM008917@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libtomoe-gtk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172343 ------- Additional Comments From ryo-dairiki at users.sourceforge.net 2006-02-27 19:37 EST ------- SPEC: http://homepage2.nifty.com/shibatama/garage/libtomoe-gtk.spec SRPM: http://homepage2.nifty.com/shibatama/garage/libtomoe-gtk-0.5. I've added ldconfig for the devel package. But I still get some errors and warnings, do you have any idea? rpmlint libtomot-gtk-devel: E: libtomoe-gtk-devel only-non-binary-in-usr-lib (Yeah, there is only "libtomoe-gtk.so" in that directory) rpmlint libtomoe-gtk-debuginfo: W: libtomoe-gtk-debuginfo objdump-failed (What is it?) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 28 00:38:49 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 19:38:49 -0500 Subject: [Bug 172343] Review Request: libtomoe-gtk In-Reply-To: Message-ID: <200602280038.k1S0cnwe009278@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libtomoe-gtk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172343 ------- Additional Comments From ryo-dairiki at users.sourceforge.net 2006-02-27 19:38 EST ------- Typo. SRPM: http://homepage2.nifty.com/shibatama/garage/libtomoe-gtk-0.1.0-5.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 28 00:58:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 19:58:07 -0500 Subject: [Bug 172343] Review Request: libtomoe-gtk In-Reply-To: Message-ID: <200602280058.k1S0w7F8012993@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libtomoe-gtk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172343 ------- Additional Comments From petersen at redhat.com 2006-02-27 19:57 EST ------- Sorry, why does the -devel package need ldconfig? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 28 01:19:39 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 20:19:39 -0500 Subject: [Bug 183042] Review Request: perl-Kwiki-Archive-Rcs In-Reply-To: Message-ID: <200602280119.k1S1Jdia016881@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Kwiki-Archive-Rcs https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183042 ------- Additional Comments From steve at silug.org 2006-02-27 20:19 EST ------- Apparently I was missing an explicit Requires: rcs. http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-Archive-Rcs-0.15-3.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 28 01:55:14 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 20:55:14 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602280155.k1S1tEAY023384@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From tibbs at math.uh.edu 2006-02-27 20:54 EST ------- I think we're set. Approved. BTW, while talking with Ville I found that for correctness you need to backwhack the first XXX. My screwup. I don't know if it breaks anything, but you might wnat to hit it before checking in. The current version of this stuff is at http://fedoraproject.org/wiki/Packaging/Perl -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From admin at ramshacklestudios.com Tue Feb 28 02:22:58 2006 From: admin at ramshacklestudios.com (Peter Gordon) Date: Mon, 27 Feb 2006 18:22:58 -0800 Subject: [SOLVED] Re: Cannot Enqueue Build In-Reply-To: <1141002002.3324.30.camel@tuxhugger> References: <1141002002.3324.30.camel@tuxhugger> Message-ID: <1141093378.3433.17.camel@tuxhugger> On Sun, 2006-02-26 at 17:00 -0800, Peter Gordon wrote: > I've waited a few hours, thinking maybe that my account info needed to > propagate or similar, but with the same results. Maybe that was the issue. I was able to enqueue FC-4 and devel builds a few moments ago. :) Dan: Thanks for the input. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xDA3634D7 Fingerprint: 0629 F604 3C14 937E F088 E5E9 B3CB 48EC DA36 34D7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From bugzilla at redhat.com Tue Feb 28 02:19:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 21:19:02 -0500 Subject: [Bug 183303] New: Review Request: perl-Kwiki-Users-Remote Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183303 Summary: Review Request: perl-Kwiki-Users-Remote Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: steve at silug.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-Users-Remote/perl-Kwiki-Users-Remote.spec SRPM Name or Url: http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-Users-Remote-0.04-1.src.rpm Description: Automatically set Kwiki user name from HTTP authentication. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From skvidal at linux.duke.edu Tue Feb 28 02:35:43 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 27 Feb 2006 21:35:43 -0500 Subject: [SOLVED] Re: Cannot Enqueue Build In-Reply-To: <1141093378.3433.17.camel@tuxhugger> References: <1141002002.3324.30.camel@tuxhugger> <1141093378.3433.17.camel@tuxhugger> Message-ID: <1141094144.17414.16.camel@cutter> On Mon, 2006-02-27 at 18:22 -0800, Peter Gordon wrote: > On Sun, 2006-02-26 at 17:00 -0800, Peter Gordon wrote: > > I've waited a few hours, thinking maybe that my account info needed to > > propagate or similar, but with the same results. > > Maybe that was the issue. I was able to enqueue FC-4 and devel builds a > few moments ago. :) > > Dan: Thanks for the input. I saw your account propagate in the cron reports from last night. -sv From bugzilla at redhat.com Tue Feb 28 02:32:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 21:32:48 -0500 Subject: [Bug 177881] Review Request: lucidlife In-Reply-To: Message-ID: <200602280232.k1S2WmvP029627@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: lucidlife https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177881 admin at ramshacklestudios.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From admin at ramshacklestudios.com 2006-02-27 21:32 EST ------- Builds completed. Closing as NEXTRELEASE. Thanks! -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 28 03:09:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 22:09:02 -0500 Subject: [Bug 172343] Review Request: libtomoe-gtk In-Reply-To: Message-ID: <200602280309.k1S3921V004034@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libtomoe-gtk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172343 jpmahowald at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| | ------- Additional Comments From jpmahowald at gmail.com 2006-02-27 22:08 EST ------- Initially I saw this guideline: - MUST: If the package contains shared library files located in the dynamic linker's default paths, that package must call ldconfig in %post and %postun. If the package has multiple subpackages with libraries, each subpackage should also have a %post/%postun section that calls /sbin/ldconfig. http://fedoraproject.org/wiki/Packaging/ReviewGuidelines and thought that there was a devel subpackage that has an object in the linker's path. However, on second thought, this is merely a symlink to the library in the main libtomoe-gtk package and so doesn't need it. What rpmlint has to say about objdump-failed: Executing objdump on this file failed, all checks could not be run. Which just means rpmlint couldn't examine the object files further. This is not serious. APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 28 03:10:52 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 22:10:52 -0500 Subject: [Bug 183038] Review Request: perl-IO-All In-Reply-To: Message-ID: <200602280310.k1S3Aqa5004538@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-IO-All https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183038 ------- Additional Comments From tibbs at math.uh.edu 2006-02-27 22:10 EST ------- OK, onto this one. It's looks good: The source file matches upstream. Package builds in FC4 i386. rpmlint is silent. The package meets the naming and packaging guidelines. The specfile is properly named and follows the suggested template. The license is appropriate and included as %doc. BuildRequires: and Requires: are good. Provides: of built package are fine. The only thing I can't do is run the mock builds because perl-Spiffy isn't in development yet. When it hits the mirrors I'll finish this up. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 28 03:39:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 22:39:28 -0500 Subject: [Bug 175127] Review Request: wavbreaker - Tool for splitting .wav files In-Reply-To: Message-ID: <200602280339.k1S3dSMj011843@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: wavbreaker - Tool for splitting .wav files https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175127 ------- Additional Comments From dmaley at redhat.com 2006-02-27 22:39 EST ------- Updated for release of wavbreaker 0.7: SPEC: http://homer.homelinux.net/RPMS/wavbreaker.spec SRPM: http://homer.homelinux.net/RPMS/wavbreaker-0.7-1.src.rpm New in 0.7 release: + Added ./configure checking for alsa and oss + Added a dialog to ask if you "really" want to quit + Added checks for existing files and dialogs to say yes or no to overwrite the existing files -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 28 04:20:41 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 27 Feb 2006 23:20:41 -0500 Subject: [Bug 172343] Review Request: libtomoe-gtk In-Reply-To: Message-ID: <200602280420.k1S4KfGC021265@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libtomoe-gtk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172343 ------- Additional Comments From ryo-dairiki at users.sourceforge.net 2006-02-27 23:20 EST ------- Okay, thanks. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From admin at ramshacklestudios.com Tue Feb 28 05:42:17 2006 From: admin at ramshacklestudios.com (Peter Gordon) Date: Mon, 27 Feb 2006 21:42:17 -0800 Subject: [SOLVED] Re: Cannot Enqueue Build In-Reply-To: <1141094144.17414.16.camel@cutter> References: <1141002002.3324.30.camel@tuxhugger> <1141093378.3433.17.camel@tuxhugger> <1141094144.17414.16.camel@cutter> Message-ID: <1141105337.3433.21.camel@tuxhugger> On Mon, 2006-02-27 at 21:35 -0500, seth vidal wrote: > I saw your account propagate in the cron reports from last night. That would do it, then! Thanks, Seth. :-] -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xDA3634D7 Fingerprint: 0629 F604 3C14 937E F088 E5E9 B3CB 48EC DA36 34D7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Tue Feb 28 06:48:54 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 28 Feb 2006 07:48:54 +0100 Subject: Extras Lists Transition Plan In-Reply-To: <58153.129.42.161.36.1141064215.squirrel@jdub.homelinux.org> References: <44033FC8.9030700@redhat.com> <1141064480.8565.23.camel@mccallum.corsepiu.local> <200602271305.21373.dennis@ausil.us> <58153.129.42.161.36.1141064215.squirrel@jdub.homelinux.org> Message-ID: <1141109335.8565.41.camel@mccallum.corsepiu.local> On Mon, 2006-02-27 at 12:16 -0600, Josh Boyer wrote: > > On Monday 27 February 2006 12:21, Ralf Corsepius wrote: > > > >> * FE and FC should be treated as one entity, therefore the split you are > >> proposing renders fedora-extras list superfluous, because the topics to > >> be discussed on your future fedora-extras-list are already covered by > >> fedora-list. > > > > I for one have not been subscribed to fedora-list for at least a couple > > of > > years. when the move from redhat to fedora happened i quickly dropped > > off > > of fedora-list because of to much noise. so I personally am not aware of > > what happens there. > > > > I do think the proposed split is good. > > +1 Not address Josh in particular, just picking up his email: Why? I'd presume you want * to avoid having to read review requests? * to avoid to see developers being involved into reviews? * to shield packager's from user's and developer's opinions? As I've said many times before, one effect of establishing more and more mailing lists is "establishing gangs/closed circles" instead of widening the audience - I can't find anything helpful in this. Ralf From rc040203 at freenet.de Tue Feb 28 06:51:21 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 28 Feb 2006 07:51:21 +0100 Subject: new wiki page: Contacting fellow packagers from other distros In-Reply-To: <4403582C.7030200@hhs.nl> References: <4403582C.7030200@hhs.nl> Message-ID: <1141109481.8565.43.camel@mccallum.corsepiu.local> On Mon, 2006-02-27 at 20:51 +0100, Hans de Goede wrote: > Hi all, > > After spending a lot of time patching up (already public) scorched3d > security holes I thought it was a good idea to share the results not > only with upstream but also with other distros. > > As a result of this I've been building a list of other distro packager > address lists, which is now in the wiki: > http://fedoraproject.org/wiki/ContactingOtherDistroPackagers > > Questions: > > 1) currently there is no link to this on the main page, where should I > put one / what is a good place for this? > 2) Anyone no similar links for other distros? 3) Is there a Fedora counterpart to these pages? At least I couldn't find any ;) Ralf From bugzilla at redhat.com Tue Feb 28 07:12:32 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 02:12:32 -0500 Subject: [Bug 183322] New: Review Request: conexus (network and serial I/O library with Gtkmm widgets) Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183322 Summary: Review Request: conexus (network and serial I/O library with Gtkmm widgets) Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: rvinyard at cs.nmsu.edu QAContact: fedora-extras-list at redhat.com Note: This is sort of my first package. I have another package (cairomm) pending review. I don't have any of the same mistakes in conexus.spec that I had in cairomm.spec, and hopefully I didn't make any new ones. So, I still don't have a sponsor, but I'm not sure if you want to mark this one as NEED_SPONSOR also. Spec Name or Url: http://miskatonic.cs.nmsu.edu/pub/conexus.spec SRPM Name or Url: http://miskatonic.cs.nmsu.edu/pub/fedora/4/srpms/conexus-0.1.15-1.src.rpm Description: Conexus is a generalized C++ I/O library that includes support for BSD sockets, serial/tty, packet capture (via pcap), et. al. conexus utilizes sigc++ for object communication. A companion library, conexusgtk, provides a set of gtkmm widgets. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From fedora at leemhuis.info Tue Feb 28 07:36:40 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 28 Feb 2006 08:36:40 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <440394C2.4060306@kobold.org> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <20060226212224.00e5b6fd.bugs.michael@gmx.net> <1141019945.808.11.camel@thl.ct.heise.de> <44029B02.6080702@kobold.org> <440394C2.4060306@kobold.org> Message-ID: <1141112200.14792.34.camel@thl.ct.heise.de> Am Montag, den 27.02.2006, 16:09 -0800 schrieb Michael Thomas: > Wart wrote: > > Thorsten Leemhuis wrote: > >>Am Sonntag, den 26.02.2006, 21:22 +0100 schrieb Michael Schwendt: > >>>On Sun, 26 Feb 2006 19:22:26 +0100, Thorsten Leemhuis wrote: > >>>>Okay, let's look at the whole situation from a different perspective. > >>>>The following list shows maintainers that still have to rebuild more > >>>>than 5 packages: > >>>>5 nos_AT_utelsystems.com > >>>Nils has not signed up since the transition from fedora.us to Fedora > >>>Extras. > >>Okay, so they are practically orphaned for at least a year? Wow. > >>So let's orphan them for real. Anyone interested in on of the following > >>packages? > >>dillo, gktools, gtkterm, neverball, whowatch > > I can pick up neverball if there are no objections. > > No objections? None? Whee! :) > > I emailed Nils to see if he was still interested in maintaining these, > but I haven't gotten a reply yet. > > So is this the right time to add these to OrphanedPackages on the wiki Yes, go ahead. > so that others can make claim to them, and claim neverball myself by > updating owners.list? Well, according to the docs in the wiki we normally wait 10 days. But we're running out of time for FE5. Wait another days or two and if no one steps up go ahead. That okay for everybody? CU thl From bugzilla at redhat.com Tue Feb 28 07:33:31 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 02:33:31 -0500 Subject: [Bug 183290] Review Request: libipoddevice In-Reply-To: Message-ID: <200602280733.k1S7XVDB032550@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libipoddevice https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183290 ------- Additional Comments From rc040203 at freenet.de 2006-02-28 02:33 EST ------- One minor nit, which gets exposed when trying to build this package on FC4: ... error: Package requirements (gobject-2.0 glib-2.0 dbus-1 dbus-glib-1 hal >= 0.5.2 libgtop-2.0 >= 2.12.0) were not met: Requested 'libgtop-2.0 >= 2.12.0' but version of libgtop is 2.10.1 => Missing "BuildRequires: libgtop-devel >= 2.12.0" -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 28 08:00:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 03:00:21 -0500 Subject: [Bug 183256] Add requires and provides filtering to the Perl template In-Reply-To: Message-ID: <200602280800.k1S80LjX004893@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Add requires and provides filtering to the Perl template https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183256 ------- Additional Comments From rc040203 at freenet.de 2006-02-28 03:00 EST ------- (In reply to comment #2) > You illustrate precisely why this needs to be standardized. Much of it is > lifted directly from the examples I found in Core and Extras CVS, although I > admit to flubbing the \EOF thing. POSIX. All POSIX shells support it and it's widestly used (eg. autoconf generated configure scripts internally use it) ... > Every example I found in what I currently had > checked out of CVS (perl, subversion, rt3) uses sed. POSIX. sed is required to be available by POSIX, so it's safe to use it and very portable. Using perl (or awk or ...) instead of sed for string substitutions are options, but making it mandatory is nothing but overengineering and basically sense-free. Choose the tool you're familiar with, for most perl packagers this will be perl, but I prefer to use sed ;) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From fedora at leemhuis.info Tue Feb 28 08:44:44 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 28 Feb 2006 09:44:44 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1140251657.2904.24.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <43F632B9.40904@hhs.nl> <1140251657.2904.24.camel@localhost.localdomain> Message-ID: <1141116284.14792.52.camel@thl.ct.heise.de> /me is getting really tired and a bit frustrated. Am Samstag, den 18.02.2006, 09:34 +0100 schrieb Thorsten Leemhuis: > Am Freitag, den 17.02.2006, 22:32 +0100 schrieb Zoltan Kota: > > On Fri, 17 Feb 2006, Hans de Goede wrote: > > > It seems to check the wrong time/date though, its listing a few of my > > > packages which have all been rebuild, take Glide3 as an example from the > > > changelog: > > > * Mon Feb 13 2006 Hans de Goede 20050815-3 > > > - Bump release and rebuild for new gcc4.1 and glibc. > > > - add %%{?dist} for consistency with my other packages > > Same for me (Feb 13). Packages: recode, python-bibtex, pybliographer. > > Well, I had to define a point in time *somewhere*. I took the obvious > one: The time when I announced the mass rebuild. >[...] > Okay. We can revisit that point in time and can set i back some hours -- We did -- we set it to the exact time when the rawhide was pushed on 13. February. > [...]And wherever we put it, there will probably always be > someone who'll say "My package was rebuild just between 1 and 1440> minutes earlier then , why does > it need a rebuild?" This could soon lead to and endless discussion that > might take a lot of more time then it takes to just rebuild the packages > in question... Okay, it happened as predicted. See attached mails. How to proceed? Ignore the whole rebuild? Get the time from a random number generator (sounds like the best solution so far)? Set it back to the second mass rebuild in Core and not the third? BTW, do we want to discuss this endlessly? Solution please. *Fast*, FC5 is near. And no please discussion that takes longer then just fire off a rebuild of those packages. CU thl -------------- next part -------------- An embedded message was scrubbed... From: fedorawiki-noreply at fedoraproject.org Subject: [Fedora Project Wiki] Update of "Extras/FC5Status" by RexDieter Date: Mon, 27 Feb 2006 20:38:29 -0000 Size: 3910 URL: -------------- next part -------------- An embedded message was scrubbed... From: fedorawiki-noreply at fedoraproject.org Subject: [Fedora Project Wiki] Update of "Extras/FC5Status" by ShahmsKing Date: Mon, 27 Feb 2006 16:20:45 -0000 Size: 2487 URL: From bugzilla at redhat.com Tue Feb 28 08:42:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 03:42:59 -0500 Subject: [Bug 180319] Review Request: svnmailer - Tool to post subversion repository commit information In-Reply-To: Message-ID: <200602280842.k1S8gxBt015750@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: svnmailer - Tool to post subversion repository commit information https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180319 ------- Additional Comments From mfleming+rpm at enlartenment.com 2006-02-28 03:42 EST ------- Spec Name or Url: http://www.enlartenment.com/extras/svnmailer.spec SRPM Name or Url: http://www.enlartenment.com/extras/svnmailer-1.0.7-1.src.rpm Upgrade to new upstream version (may as well keep it current eh? :-)) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 28 08:49:57 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 03:49:57 -0500 Subject: [Bug 179439] Review Request: linux-libertine-fonts - TrueType serif fonts In-Reply-To: Message-ID: <200602280849.k1S8nvmq017798@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: linux-libertine-fonts - TrueType serif fonts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179439 ------- Additional Comments From frank at scirocco-5v-turbo.de 2006-02-28 03:49 EST ------- Just to be sure, and to follow the guidelines here is the hopefully last version inside bugzilla. Spec: http://www.scirocco-5v-turbo.de/fedora/linux-libertine-fonts.spec SRPM: http://www.scirocco-5v-turbo.de/fedora/linux-libertine-fonts-2.0.4-2.src.rpm Changes: * Changed %(name) to linux-libertine-fonts * Renamed spec file to linux-libertine-fonts.spec * Bumped version and added a changelog entry Everything else stayed the same. Builds with mock devel, rpmlint doesn't complain on results. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From j.w.r.degoede at hhs.nl Tue Feb 28 10:10:00 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 28 Feb 2006 11:10:00 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1141116284.14792.52.camel@thl.ct.heise.de> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <43F632B9.40904@hhs.nl> <1140251657.2904.24.camel@localhost.localdomain> <1141116284.14792.52.camel@thl.ct.heise.de> Message-ID: <44042178.8030700@hhs.nl> Thorsten Leemhuis wrote: > /me is getting really tired and a bit frustrated. > > Am Samstag, den 18.02.2006, 09:34 +0100 schrieb Thorsten Leemhuis: >> Am Freitag, den 17.02.2006, 22:32 +0100 schrieb Zoltan Kota: >>> On Fri, 17 Feb 2006, Hans de Goede wrote: >>>> It seems to check the wrong time/date though, its listing a few of my >>>> packages which have all been rebuild, take Glide3 as an example from the >>>> changelog: >>>> * Mon Feb 13 2006 Hans de Goede 20050815-3 >>>> - Bump release and rebuild for new gcc4.1 and glibc. >>>> - add %%{?dist} for consistency with my other packages >>> Same for me (Feb 13). Packages: recode, python-bibtex, pybliographer. >> Well, I had to define a point in time *somewhere*. I took the obvious >> one: The time when I announced the mass rebuild. >> [...] >> Okay. We can revisit that point in time and can set i back some hours -- > > We did -- we set it to the exact time when the rawhide was pushed on 13. > February. > >> [...]And wherever we put it, there will probably always be >> someone who'll say "My package was rebuild just > between 1 and 1440> minutes earlier then , why does >> it need a rebuild?" This could soon lead to and endless discussion that >> might take a lot of more time then it takes to just rebuild the packages >> in question... > > Okay, it happened as predicted. See attached mails. How to proceed? > Ignore the whole rebuild? Get the time from a random number generator > (sounds like the best solution so far)? Set it back to the second mass > rebuild in Core and not the third? > I say leave it as is, the rawhide mail is the time the new packages of the third rebuild where available and thus is a good time. > BTW, do we want to discuss this endlessly? Solution please. *Fast*, FC5 > is near. And no please discussion that takes longer then just fire off a > rebuild of those packages. > No, as said leave it as is. Regards, Hans From bugzilla at redhat.com Tue Feb 28 10:54:56 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 05:54:56 -0500 Subject: [Bug 178310] Review Request: w3c-libwww - An HTTP library of common code In-Reply-To: Message-ID: <200602281054.k1SAsu1e018310@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: w3c-libwww - An HTTP library of common code https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178310 andreas.bierfert at lowlatency.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From andreas.bierfert at lowlatency.de 2006-02-28 05:54 EST ------- Ok, I resolved that by readding the wwwconfig.h file. Imported and pushed :) Thanks again for the review. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 28 10:55:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 05:55:13 -0500 Subject: [Bug 178169] Review Request: jigdo In-Reply-To: Message-ID: <200602281055.k1SAtD8N018419@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: jigdo https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178169 Bug 178169 depends on bug 178310, which changed state. Bug 178310 Summary: Review Request: w3c-libwww - An HTTP library of common code https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178310 What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Resolution| |NEXTRELEASE Status|ASSIGNED |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 28 11:22:45 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 06:22:45 -0500 Subject: [Bug 177832] Review Request: wmweather+ In-Reply-To: Message-ID: <200602281122.k1SBMjDb023967@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: wmweather+ https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177832 andreas.bierfert at lowlatency.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From andreas.bierfert at lowlatency.de 2006-02-28 06:22 EST ------- Build. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From jwboyer at jdub.homelinux.org Tue Feb 28 10:59:30 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 28 Feb 2006 05:59:30 -0500 Subject: Extras Lists Transition Plan In-Reply-To: <1141109335.8565.41.camel@mccallum.corsepiu.local> References: <44033FC8.9030700@redhat.com> <1141064480.8565.23.camel@mccallum.corsepiu.local> <200602271305.21373.dennis@ausil.us> <58153.129.42.161.36.1141064215.squirrel@jdub.homelinux.org> <1141109335.8565.41.camel@mccallum.corsepiu.local> Message-ID: <1141124370.9100.11.camel@yoda.jdub.homelinux.org> On Tue, 2006-02-28 at 07:48 +0100, Ralf Corsepius wrote: > On Mon, 2006-02-27 at 12:16 -0600, Josh Boyer wrote: > > > On Monday 27 February 2006 12:21, Ralf Corsepius wrote: > > > > > >> * FE and FC should be treated as one entity, therefore the split you are > > >> proposing renders fedora-extras list superfluous, because the topics to > > >> be discussed on your future fedora-extras-list are already covered by > > >> fedora-list. > > > > > > I for one have not been subscribed to fedora-list for at least a couple > > > of > > > years. when the move from redhat to fedora happened i quickly dropped > > > off > > > of fedora-list because of to much noise. so I personally am not aware of > > > what happens there. > > > > > > I do think the proposed split is good. > > > > +1 > > Not address Josh in particular, just picking up his email: Fair enough. But I'll respond anyway :) > > Why? I'd presume you want > * to avoid having to read review requests? No, I just want them in a separate list. Right now, I would say that the review requests make up the majority of mail on -extras and I personally find it harder to read some of the non-review content. Just a personal preference, that's all. > * to avoid to see developers being involved into reviews? Hm, no definitely not. > * to shield packager's from user's and developer's opinions? I don't see how that will happen because of this. > As I've said many times before, one effect of establishing more and more > mailing lists is "establishing gangs/closed circles" instead of widening > the audience - I can't find anything helpful in this. I don't think so. The way I would see it working is that review email goes to the -review list. Normally, the content of such bugs is the same. "Fix this to be like it says in the packaging guidelines", etc. We have a defined set of packaging and review guidelines that are pretty easy to follow, IMHO. So for new packagers, we point them there. Whenever something comes up that _isn't_ a typical situation, then the packager/reviewer brings it up on -extras. That list should be for discussing changes to Extras as a whole, whether it be packaging policy or the recent kmod discussions, or even scratch builds. Even this particular discussion (see it's working already ;). The -extras list should also be where end users get to voice their opinions. Nothing prevents them from doing so today, so that doesn't really change. It also allows FESCO and the maintainers to communicate with the end users. Take Thorsten's FESCO summary emails. Those are awesome. Stuff like that is what -extras should be. I don't think this is a case of closing circles. All of the lists can be subscribed to by anyone, so it's all still open. Just my $0.02. josh -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From bugzilla at redhat.com Tue Feb 28 12:39:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 07:39:28 -0500 Subject: [Bug 181068] Review Request: html401-dtds - HTML 4.01 document type definitions In-Reply-To: Message-ID: <200602281239.k1SCdSuN006644@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: html401-dtds - HTML 4.01 document type definitions https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181068 ------- Additional Comments From veillard at redhat.com 2006-02-28 07:39 EST ------- To me it reinforced the fact that it's fine to not put it as a version, we don't expect any more versions. I also put the number in the name for xhtml1-dtds for the reasons exposed in #11 Daniel -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 28 12:46:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 07:46:16 -0500 Subject: [Bug 170131] Review Request: php-extras - Additional PHP modules from the standard PHP distribution In-Reply-To: Message-ID: <200602281246.k1SCkG3u007939@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-extras - Additional PHP modules from the standard PHP distribution https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170131 ------- Additional Comments From dmitry at butskoy.name 2006-02-28 07:46 EST ------- > Unconvincing. Surely you would follow with a minor update in Extras, > too, wouldn't you? Sure! It is not too often, and it is not too difficult... But you are right -- it is possible that there is a new Core package version, but Extras yet not, and Extras package's dependencies prevent the updating of the Core package... Perhaps: "Requires: php >= 5.1.1, php < 5.2" is a good solution (at least while there is no "php(ABI)" feature)? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 28 14:19:24 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 09:19:24 -0500 Subject: [Bug 179043] Review Request: perl-HTTP-Proxy - A pure Perl HTTP proxy In-Reply-To: Message-ID: <200602281419.k1SEJOvV026936@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-HTTP-Proxy - A pure Perl HTTP proxy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179043 rc040203 at freenet.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|gdk at redhat.com |rc040203 at freenet.de OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From rc040203 at freenet.de 2006-02-28 09:19 EST ------- Minor nit: # rpmlint perl-HTTP-Proxy-0.17-1.noarch.rpm W: perl-HTTP-Proxy file-not-utf8 /usr/share/man/man3/HTTP::Proxy::BodyFilter::save.3pm.gz The cause is lib/HTTP/Proxy/BodyFilter/save.pm containing an author's name latin1 encoded. APPROVED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From tibbs at math.uh.edu Tue Feb 28 15:19:46 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 28 Feb 2006 09:19:46 -0600 Subject: Recoding non-UTF-8 documentation? Message-ID: Is there ever a case where it's worth it to recode documentation to satisfy a "file-not-utf8" warning from rpmlint? Some packages fix up line endings to quiet rpmlint but I'm not sure about altering the character encoding. If not, then would it be reasonable to remove this warning from rpmlint? - J< From paul at city-fan.org Tue Feb 28 15:27:16 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 28 Feb 2006 15:27:16 +0000 Subject: Recoding non-UTF-8 documentation? In-Reply-To: References: Message-ID: <44046BD4.80805@city-fan.org> Jason L Tibbitts III wrote: > Is there ever a case where it's worth it to recode documentation to > satisfy a "file-not-utf8" warning from rpmlint? Some packages fix up > line endings to quiet rpmlint but I'm not sure about altering the > character encoding. > > If not, then would it be reasonable to remove this warning from > rpmlint? Having the wrong encoding results in strange results when trying to read the documentation. It's quite common to recode files. Take perl-IO-Socket-SSL for example: for f in README SSL.pm ; do iconv -f iso-8859-1 -t utf-8 -o $f{.utf8,} ; mv $f{.utf8,} done My vote would be for the warning to stay. Paul. From wart at kobold.org Tue Feb 28 15:36:50 2006 From: wart at kobold.org (Wart) Date: Tue, 28 Feb 2006 07:36:50 -0800 Subject: Recoding non-UTF-8 documentation? In-Reply-To: References: Message-ID: <44046E12.7010107@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jason L Tibbitts III wrote: > Is there ever a case where it's worth it to recode documentation to > satisfy a "file-not-utf8" warning from rpmlint? Some packages fix up > line endings to quiet rpmlint but I'm not sure about altering the > character encoding. > > If not, then would it be reasonable to remove this warning from > rpmlint? I had this problem with xpilot-ng: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179818#c2 iconv fixed it up quite nice. The less output that you get from rpmlint, the smoother the review. Since the fix is simple then I would just go ahead and do the conversion. - --Wart -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEBG4MDeYlPfs40g8RAkOWAJ9uJhaPOei9sM1wx8t5iQF1dho8VQCdFJeM i4iwTkKqceatxjWaKIQ8fWg= =E+j2 -----END PGP SIGNATURE----- From fedora at camperquake.de Tue Feb 28 15:40:00 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 28 Feb 2006 16:40:00 +0100 Subject: Recoding non-UTF-8 documentation? In-Reply-To: <44046E12.7010107@kobold.org> References: <44046E12.7010107@kobold.org> Message-ID: <20060228164000.7c2fcbbb@dhcp05.addix.net> Hi. On Tue, 28 Feb 2006 07:36:50 -0800, Wart wrote: > iconv fixed it up quite nice. The less output that you get from > rpmlint, the smoother the review. Since the fix is simple then I > would just go ahead and do the conversion. The problem I see with it is that once the automatic conversion is in place, it may be forgotten. What if upstream goes to UTF-8 itself? iconv will not catch that (every UTF-8 file is valid ISO-8859-x) From rc040203 at freenet.de Tue Feb 28 15:44:46 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 28 Feb 2006 16:44:46 +0100 Subject: Recoding non-UTF-8 documentation? In-Reply-To: <20060228164000.7c2fcbbb@dhcp05.addix.net> References: <44046E12.7010107@kobold.org> <20060228164000.7c2fcbbb@dhcp05.addix.net> Message-ID: <1141141486.8565.59.camel@mccallum.corsepiu.local> On Tue, 2006-02-28 at 16:40 +0100, Ralf Ertzinger wrote: > Hi. > > On Tue, 28 Feb 2006 07:36:50 -0800, Wart wrote: > > > iconv fixed it up quite nice. The less output that you get from > > rpmlint, the smoother the review. Since the fix is simple then I > > would just go ahead and do the conversion. > > The problem I see with it is that once the automatic conversion is > in place, it may be forgotten. What if upstream goes to UTF-8 itself? > iconv will not catch that (every UTF-8 file is valid ISO-8859-x) Why would this be a problem? Ralf From tibbs at math.uh.edu Tue Feb 28 15:44:46 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 28 Feb 2006 09:44:46 -0600 Subject: Recoding non-UTF-8 documentation? In-Reply-To: <44046BD4.80805@city-fan.org> (Paul Howarth's message of "Tue, 28 Feb 2006 15:27:16 +0000") References: <44046BD4.80805@city-fan.org> Message-ID: >>>>> "PH" == Paul Howarth writes: PH> Having the wrong encoding results in strange results when trying PH> to read the documentation. So should packagers be expected to fix this? And does this apply to info documentation, or does it have special rules regarding encoding? - J< From fedora at camperquake.de Tue Feb 28 15:51:17 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 28 Feb 2006 16:51:17 +0100 Subject: Recoding non-UTF-8 documentation? In-Reply-To: <1141141486.8565.59.camel@mccallum.corsepiu.local> References: <44046E12.7010107@kobold.org> <20060228164000.7c2fcbbb@dhcp05.addix.net> <1141141486.8565.59.camel@mccallum.corsepiu.local> Message-ID: <20060228165117.13c7c58a@dhcp05.addix.net> Hi. On Tue, 28 Feb 2006 16:44:46 +0100, Ralf Corsepius wrote: > > The problem I see with it is that once the automatic conversion is > > in place, it may be forgotten. What if upstream goes to UTF-8 > > itself? iconv will not catch that (every UTF-8 file is valid > > ISO-8859-x) > > Why would this be a problem? Because iconv would convert already valid UTF-8 (thinking it was ISO-8859-x) into UTF-8 again, destroying all characters with a codepoint > 127. From wart at kobold.org Tue Feb 28 15:52:49 2006 From: wart at kobold.org (Wart) Date: Tue, 28 Feb 2006 07:52:49 -0800 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1141112200.14792.34.camel@thl.ct.heise.de> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <20060226212224.00e5b6fd.bugs.michael@gmx.net> <1141019945.808.11.camel@thl.ct.heise.de> <44029B02.6080702@kobold.org> <440394C2.4060306@kobold.org> <1141112200.14792.34.camel@thl.ct.heise.de> Message-ID: <440471D1.4050305@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thorsten Leemhuis wrote: > Am Montag, den 27.02.2006, 16:09 -0800 schrieb Michael Thomas: > >>Wart wrote: >> >>>Thorsten Leemhuis wrote: >>> >>>>Am Sonntag, den 26.02.2006, 21:22 +0100 schrieb Michael Schwendt: >>>> >>>>>On Sun, 26 Feb 2006 19:22:26 +0100, Thorsten Leemhuis wrote: >>>>> >>>>>>Okay, let's look at the whole situation from a different perspective. >>>>>>The following list shows maintainers that still have to rebuild more >>>>>>than 5 packages: >>>>>>5 nos_AT_utelsystems.com >>>>> >>>>>Nils has not signed up since the transition from fedora.us to Fedora >>>>>Extras. >>>> >>>>Okay, so they are practically orphaned for at least a year? Wow. >>>>So let's orphan them for real. Anyone interested in on of the following >>>>packages? >>>>dillo, gktools, gtkterm, neverball, whowatch >>> >>>I can pick up neverball if there are no objections. >> >>No objections? None? Whee! :) >> >>I emailed Nils to see if he was still interested in maintaining these, >>but I haven't gotten a reply yet. >> >>So is this the right time to add these to OrphanedPackages on the wiki > > > Yes, go ahead. I finally got confirmation from Nils that he is no longer maintaining these packages. I've added them to the wiki. >>so that others can make claim to them, and claim neverball myself by >>updating owners.list? > > > Well, according to the docs in the wiki we normally wait 10 days. But > we're running out of time for FE5. Wait another days or two and if no > one steps up go ahead. That okay for everybody? Fair enough. - --Wart -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEBHHNDeYlPfs40g8RAupnAJ4i+p89fzM1n6YHMk+lAqR9RZTGcACdEDjN EMt+BShyLeYV1sibu4zCWuQ= =d2n1 -----END PGP SIGNATURE----- From bugzilla at redhat.com Tue Feb 28 15:52:26 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 10:52:26 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602281552.k1SFqQKa019120@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From steve at silug.org 2006-02-28 10:52 EST ------- > BTW, while talking with Ville I found that for correctness you need to > backwhack the first XXX. My screwup. I don't know if it breaks anything, > but you might wnat to hit it before checking in. I wonder what the reason is for that. It seems to build fine as-is. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 28 16:12:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 11:12:53 -0500 Subject: [Bug 183038] Review Request: perl-IO-All In-Reply-To: Message-ID: <200602281612.k1SGCrU9024538@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-IO-All https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183038 ------- Additional Comments From steve at silug.org 2006-02-28 11:12 EST ------- Keep an eye on this: http://buildsys.fedoraproject.org/build-status/job.psp?uid=5365 As soon as it finishes, you should be able to build in mock. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 28 16:15:42 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 11:15:42 -0500 Subject: [Bug 170131] Review Request: php-extras - Additional PHP modules from the standard PHP distribution In-Reply-To: Message-ID: <200602281615.k1SGFgEe025126@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-extras - Additional PHP modules from the standard PHP distribution https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170131 ------- Additional Comments From dmitry at butskoy.name 2006-02-28 11:15 EST ------- - apply "libtool-rpath-workaround" to avoid passing -rpath option to the linker. It is well-known hack, easyly found anywhere in Inet. Actually, I never see any rpathes in the binaries generated by me, but comment #14 says that it seems to be needed. - remove old and add new readline patch for newest php 5.1.2 (avoid building with libedit instead of libreadline). - "Requires: php = %{version}" -- not any changes yet, IMO it can be saved "as is" until some php(ABI) feature appears in the future... New SPECS/SRPMS: FC3 (I know that it was EOL'ed :)) : http://dmitry.butskoy.name/php-extras/php-extras.spec.fc3 http://dmitry.butskoy.name/php-extras/php-extras-4.3.11-3.src.rpm FC4: http://dmitry.butskoy.name/php-extras/php-extras.spec.fc4 http://dmitry.butskoy.name/php-extras/php-extras-5.0.4-3.src.rpm FC5: http://dmitry.butskoy.name/php-extras/php-extras.spec.fc5 http://dmitry.butskoy.name/php-extras/php-extras-5.1.1-1.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 28 16:17:38 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 11:17:38 -0500 Subject: [Bug 170131] Review Request: php-extras - Additional PHP modules from the standard PHP distribution In-Reply-To: Message-ID: <200602281617.k1SGHcIw025620@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-extras - Additional PHP modules from the standard PHP distribution https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170131 ------- Additional Comments From dmitry at butskoy.name 2006-02-28 11:17 EST ------- Sorry for the typo: FC5: http://dmitry.butskoy.name/php-extras/php-extras.spec.fc5 http://dmitry.butskoy.name/php-extras/php-extras-5.1.2-1.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rc040203 at freenet.de Tue Feb 28 16:23:52 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 28 Feb 2006 17:23:52 +0100 Subject: Recoding non-UTF-8 documentation? In-Reply-To: <20060228165117.13c7c58a@dhcp05.addix.net> References: <44046E12.7010107@kobold.org> <20060228164000.7c2fcbbb@dhcp05.addix.net> <1141141486.8565.59.camel@mccallum.corsepiu.local> <20060228165117.13c7c58a@dhcp05.addix.net> Message-ID: <1141143832.8565.61.camel@mccallum.corsepiu.local> On Tue, 2006-02-28 at 16:51 +0100, Ralf Ertzinger wrote: > Hi. > > On Tue, 28 Feb 2006 16:44:46 +0100, Ralf Corsepius wrote: > > > > The problem I see with it is that once the automatic conversion is > > > in place, it may be forgotten. What if upstream goes to UTF-8 > > > itself? iconv will not catch that (every UTF-8 file is valid > > > ISO-8859-x) > > > > Why would this be a problem? > > Because iconv would convert already valid UTF-8 (thinking it was > ISO-8859-x) into UTF-8 again, destroying all characters with a > codepoint > 127. That's what maintainers are for and what users are supposed to bugzilla ;) Ralf From rc040203 at freenet.de Tue Feb 28 16:26:39 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 28 Feb 2006 17:26:39 +0100 Subject: Recoding non-UTF-8 documentation? In-Reply-To: References: <44046BD4.80805@city-fan.org> Message-ID: <1141143999.8565.65.camel@mccallum.corsepiu.local> On Tue, 2006-02-28 at 09:44 -0600, Jason L Tibbitts III wrote: > >>>>> "PH" == Paul Howarth writes: > > PH> Having the wrong encoding results in strange results when trying > PH> to read the documentation. > > So should packagers be expected to fix this? Ask yourself: Do you expect readable man pages? > And does this apply to > info documentation, Do you mean "info files" or do you mean informational files in general? > or does it have special rules regarding encoding? Originally, info were ASCII only. I am not sure if this still applies. Ralf From bugzilla at redhat.com Tue Feb 28 16:24:30 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 11:24:30 -0500 Subject: [Bug 183038] Review Request: perl-IO-All In-Reply-To: Message-ID: <200602281624.k1SGOU07027679@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-IO-All https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183038 ------- Additional Comments From tibbs at math.uh.edu 2006-02-28 11:24 EST ------- Unfortunately it still needs to be signed and pushed to the mirrors. It doesn't look like any packages have been pushed since noon on Sunday, so hopefully that will happen soon. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 28 16:47:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 11:47:15 -0500 Subject: [Bug 180747] Review Request: powerman In-Reply-To: Message-ID: <200602281647.k1SGlFaq001392@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: powerman https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180747 ------- Additional Comments From woodard at redhat.com 2006-02-28 11:47 EST ------- Here is a new version of powerman rpm and spec file. This fixes all the problems that rpmlint turned up in all the rpms. Previously I had only done this for the src rpm. http://osdn.dl.sourceforge.net/sourceforge/powerman/powerman.spec http://osdn.dl.sourceforge.net/sourceforge/powerman/powerman-1.0.23-3.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 28 16:53:25 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 11:53:25 -0500 Subject: [Bug 179940] Review Request: ruby-http-access2 In-Reply-To: Message-ID: <200602281653.k1SGrPLO003210@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ruby-http-access2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179940 tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|bugzilla-sink at leemhuis.info |tibbs at math.uh.edu OtherBugsDependingO|163776 |163778 nThis| | ------- Additional Comments From tibbs at math.uh.edu 2006-02-28 11:53 EST ------- We have a specfile template for Ruby now; it would be best to follow it especially as it fixes things like %{ruby_sitelib}. Ruby packaging isn't as far along as Perl or Python so I think it's important that everything is consistent. Onto the review: package is properly named (although there aren't naming guidelines for Ruby yet, the name matches the tarball and the necessary 'require' line). 2.0.6 is the current version. The summary is a bit awkward; suggest changing "Accessing" to "Access" or "A library for accessing". I believe the licensing is more complex than just GPL since the package allows distribution under Ruby's dual license, but I don't know what the common name of the other license is. The URL given seems to be throwing an internal server error for me. The specfile template prefers: BuildRequires: ruby ruby-devel Requires: %{ruby_sitelib} where %{ruby_sitelib} is defined earlier in the template. The package should be BuildArch: noarch as it doesn't produce any binaries. Suggest deleting the last line for the description. Suggest running the provided tests in a %check section if this is reasonable. (It probably isn't if this requires network access.) Please use %{ruby_sitelib} instead hardcoding the Ruby version in %files. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 28 17:19:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 12:19:27 -0500 Subject: [Bug 170131] Review Request: php-extras - Additional PHP modules from the standard PHP distribution In-Reply-To: Message-ID: <200602281719.k1SHJR8a010712@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-extras - Additional PHP modules from the standard PHP distribution https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170131 ------- Additional Comments From rpm at timj.co.uk 2006-02-28 12:19 EST ------- Hey, Joe Orton's done the php-api Provide upstream in the Core php package. See bug #183227. Awesome. Assuming that makes it into FC5 final, hopefully that ends the discussion about versioning :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From tibbs at math.uh.edu Tue Feb 28 17:28:53 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 28 Feb 2006 11:28:53 -0600 Subject: The Ruby license Message-ID: I couldn't find any of the valid licenses in rpmlint which matches the Ruby license. These days everything in Ruby is dual Ruby/GPL; it it acceptable to use just GPL or should "Ruby license" be added to rpmlint's list? (If so, I'll file a bug.) Note that the OSI doesn't list Ruby's license, but Debian accepts it as free: http://www.debian.org/legal/licenses/ The license text is at http://www.ruby-lang.org/en/LICENSE.txt - J< From gdk at redhat.com Tue Feb 28 17:35:48 2006 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Tue, 28 Feb 2006 12:35:48 -0500 (EST) Subject: The Ruby license In-Reply-To: References: Message-ID: Looks to me like the sensible thing to do is to modify rpmlint. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- On Tue, 28 Feb 2006, Jason L Tibbitts III wrote: > I couldn't find any of the valid licenses in rpmlint which matches the > Ruby license. These days everything in Ruby is dual Ruby/GPL; it it > acceptable to use just GPL or should "Ruby license" be added to > rpmlint's list? (If so, I'll file a bug.) > > Note that the OSI doesn't list Ruby's license, but Debian accepts it > as free: http://www.debian.org/legal/licenses/ > > The license text is at http://www.ruby-lang.org/en/LICENSE.txt > > - J< > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From bugzilla at redhat.com Tue Feb 28 17:31:35 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 12:31:35 -0500 Subject: [Bug 182415] Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project In-Reply-To: Message-ID: <200602281731.k1SHVZ88014163@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: man-pages-uk - Ukrainian man pages from Linux Documentation Project https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182415 andy at smile.org.ua changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Package Review |aalib ------- Additional Comments From andy at smile.org.ua 2006-02-28 12:31 EST ------- I found addon info about this package in its Makefile. Also, Gentoo people package it as real tarball name. I've fixed name, release, version in specfile. ftp://andriy.asplinux.com.ua/pub/people/andy/extras/manpages-uk-utf8-0.0.0.2-0. 1.20060228.src.rpm ftp://andriy.asplinux.com.ua/pub/people/andy/extras/manpages-uk-utf8.spec Please, review it again. Thank you. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 28 17:40:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 12:40:59 -0500 Subject: [Bug 177818] Review Request: adplug In-Reply-To: Message-ID: <200602281740.k1SHexxH016780@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: adplug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177818 ------- Additional Comments From triad at df.lth.se 2006-02-28 12:40 EST ------- OK upstream has opted for $(sharedstatedir) i.e. /usr/local/com so I have opened bug 183370 to address this in filesystem. Until filesystem fix/rejects this I will leave /usr/local/com unowned in the package. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From fedora at leemhuis.info Tue Feb 28 17:47:02 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 28 Feb 2006 18:47:02 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> Message-ID: <1141148822.2278.34.camel@localhost.localdomain> Am Sonntag, den 26.02.2006, 20:21 +0100 schrieb Aurelien Bompard: >[...] > > So, how to proceed? Bug the maintainers with a E-Mail directly? Probably > > a good idea. I'll try to write a script that does this. > This is the best idea at the moment IMHO.[...] > Anyway, a direct mail reminder will probably help a lot. Done some minutes ago (sorry, I didn't find time for it earlier); Initial results: Keith G. Robertson-Turner: "This account is protected against spam, using the SpamArrest service, which is a 'C/R' or 'Challenge/Response' service. [...]" /me wonders if Keith was wise enough to whitelist the E-Mail address used by bugzilla.redhat.com. Keith? aaron.bennett_AT_olin.edu -- "Delivery failed." colin_AT_fedoraproject.org -- "User unknown" lemenkov at newmail.ru -- "User unknown" :-(( :-(( /me wonders how many of the other mail addresses from owners.list don't work but chooses to simply ignore that for now. >[...] > > And I suspect that some others from those 43 maintainers probably should > > face that they have a lot of other, more important work to do and should > > probably orphan their packages so that other interested people can take > > them over. > Maybe automatically orphan the packages if they are not rebuilt for the 6th > of Mars ? (date of "Absolute devel freeze")? Opinions on that? > > Suggestions how to solve this whole mess in the short and in the long > > term welcome. > Having not-rebuilt packages being automatically orphaned on test3 of each FC > release seems like a decent long-term solution to me. And opinions on this one? We would also need to force a rebuild of all noarch packages to to make this work efficient. And I suspect that a lot of people don't like that or a "rebuild everything in Extras for each Core release". CU thl -- Thorsten Leemhuis From bugzilla at redhat.com Tue Feb 28 17:43:32 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 12:43:32 -0500 Subject: [Bug 170131] Review Request: php-extras - Additional PHP modules from the standard PHP distribution In-Reply-To: Message-ID: <200602281743.k1SHhWPK017447@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-extras - Additional PHP modules from the standard PHP distribution https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170131 ------- Additional Comments From dmitry at butskoy.name 2006-02-28 12:43 EST ------- Well, FC4: php = %{version} FC5 and later: php-api = Is it OK? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 28 18:10:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 13:10:02 -0500 Subject: [Bug 183374] New: Review Request: perl-Crypt-Random Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183374 Summary: Review Request: perl-Crypt-Random Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink at leemhuis.info ReportedBy: paul at city-fan.org QAContact: fedora-extras-list at redhat.com Spec Name or Url: http://www.city-fan.org/~paul/extras/perl-Crypt-Random/perl-Crypt-Random.spec SRPM Name or Url: http://www.city-fan.org/~paul/extras/perl-Crypt-Random/perl-Crypt-Random-1.25-1.src.rpm Description: Crypt::Random is an interface module to the /dev/random device found on most modern unix systems. It also interfaces with egd, a user space entropy gathering daemon, available for systems where /dev/random (or similar) devices are not available. When Math::Pari is installed, Crypt::Random can generate random integers of arbitrary size of a given bitsize or in a specified interval. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From j.w.r.degoede at hhs.nl Tue Feb 28 18:30:57 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 28 Feb 2006 19:30:57 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1141148822.2278.34.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <1141148822.2278.34.camel@localhost.localdomain> Message-ID: <440496E1.9080603@hhs.nl> Thorsten Leemhuis wrote: > Am Sonntag, den 26.02.2006, 20:21 +0100 schrieb Aurelien Bompard: >> [...] >>> So, how to proceed? Bug the maintainers with a E-Mail directly? Probably >>> a good idea. I'll try to write a script that does this. >> This is the best idea at the moment IMHO.[...] >> Anyway, a direct mail reminder will probably help a lot. > > Done some minutes ago (sorry, I didn't find time for it earlier); > Initial results: > > Keith G. Robertson-Turner: "This account is protected against spam, > using the SpamArrest service, which is a 'C/R' or 'Challenge/Response' > service. [...]" > > /me wonders if Keith was wise enough to whitelist the E-Mail address > used by bugzilla.redhat.com. Keith? > > aaron.bennett_AT_olin.edu -- "Delivery failed." > colin_AT_fedoraproject.org -- "User unknown" > lemenkov at newmail.ru -- "User unknown" > I say if they didn't bother to keep a working email in owners.list orphan the bunch _right_ _now_, then we still have a small window for people to pick up the broken pieces. > :-(( > > :-(( > Agreed. > /me wonders how many of the other mail addresses from owners.list don't > work but chooses to simply ignore that for now. > Someone could write a ping scripts which sends messages on be halve of say you? And then send mails to all listed addresses, with a content telling the maintainers to ignore it. Then you would get all failures and would know. >> [...] >>> And I suspect that some others from those 43 maintainers probably should >>> face that they have a lot of other, more important work to do and should >>> probably orphan their packages so that other interested people can take >>> them over. >> Maybe automatically orphan the packages if they are not rebuilt for the 6th >> of Mars ? (date of "Absolute devel freeze")? > > Opinions on that? > auto orphan is a bit harsh, but maybe a bit harsh is just what we need? I would not want to auto orphan packages where people have given a reason why they aren't rebuilded yet. >>> Suggestions how to solve this whole mess in the short and in the long >>> term welcome. >> Having not-rebuilt packages being automatically orphaned on test3 of each FC >> release seems like a decent long-term solution to me. > > And opinions on this one? We would also need to force a rebuild of all > noarch packages to to make this work efficient. And I suspect that a lot > of people don't like that or a "rebuild everything in Extras for each > Core release". > I agree, including non-arch packages. We really want a rebuild each FC release, because of newer compilers, maybe api but not abi compatible deps etc. And this would nicely shake out all not activly maintained packages. The real question however is not when to orphan that we'll figure out. but what todo with packages that stay orphaned for a long period? Regards, Hans From bugzilla at redhat.com Tue Feb 28 18:25:27 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 13:25:27 -0500 Subject: [Bug 179940] Review Request: ruby-http-access2 In-Reply-To: Message-ID: <200602281825.k1SIPRqc028626@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ruby-http-access2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179940 ------- Additional Comments From oliver.andrich at gmail.com 2006-02-28 13:25 EST ------- (In reply to comment #1) > We have a specfile template for Ruby now; it would be best to follow it > especially as it fixes things like %{ruby_sitelib}. Ruby packaging isn't as far > along as Perl or Python so I think it's important that everything is consistent. Well, I supplied the template myself, but havn't applied it yet on this package. Shame on me. :) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180066 I also suggested adding a paragraph concerning ruby to the package naming guidelines the closely follows the python and perl paragraphs. I hope it will be merged into the document soon. > The summary is a bit awkward; suggest changing "Accessing" to "Access" or "A > library for accessing". Okay, understood. I am not a native english speaker, which is the cause of such issues. > I believe the licensing is more complex than just GPL since the package allows > distribution under Ruby's dual license, but I don't know what the common name of > the other license is. Well, I talked about that with the maintainer of the ruby package itself. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179933 If I look at the packaging guidelines and what is stated about licensing information, it is obvious to me, that I have to mark to be licensed under the GPL, cause it is the OSI approved licence. Akira Tagoh (tagoh at redhat.com) suggested to use Distributable, as you can see in Ticket 179933. This is the way I want to go. > The specfile template prefers: > > BuildRequires: ruby ruby-devel > Requires: %{ruby_sitelib} > > where %{ruby_sitelib} is defined earlier in the template. This is done as soon as I update to the template. okay. > The package should be BuildArch: noarch as it doesn't produce any binaries. > > Suggest deleting the last line for the description. > > Suggest running the provided tests in a %check section if this is reasonable. > (It probably isn't if this requires network access.) > > Please use %{ruby_sitelib} instead hardcoding the Ruby version in %files. I agree with you and will release a new package tonight. Thanks for checking. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From jspaleta at gmail.com Tue Feb 28 18:34:17 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 28 Feb 2006 13:34:17 -0500 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1141148822.2278.34.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <1141148822.2278.34.camel@localhost.localdomain> Message-ID: <604aa7910602281034m6e631569rbab3d2feaa33fec@mail.gmail.com> On 2/28/06, Thorsten Leemhuis wrote: > Maybe automatically orphan the packages if they are not rebuilt for the 6th > of Mars ? (date of "Absolute devel freeze")? > Opinions on that? I'm going to pretend to be wicked pissed if you automatically orphan istanbul if it won't build because of dep issues. I've said repeatedly that the transition from gst0.8 to gst0.10 has caused an untimely shift in dependancies and I will be moving the istanbul in the devel tree to using gst 0.10 building it in fc5 as soon as its feasible to do so which will require an update to gst in Core. I do not believe the dependancies for istanbul will be ready to be pushed into an fe5 branch..but it is not orphaned and it will see a build as soon as the dependancy chain allows it to work again. In truth I'll be deeply grateful if you automatically orphan it that gives me a great excuse to just walk away from the issue completely playing the victim to your uncaring and viciously inhumane automated computer logic that I can point to as the harbinger of computer subjugation of human freedom in the theme of the terminator movies...and let someone else with far less patience jump in 6 mmonths from now and rant and rave about the dependancy problems which I don't have the ability to solve on my own. How do I get the currently depedancy broken istanbul package out of the binary devel tree? I'm more than happy to not have the broken binary package sitting in the tree while the dependancy issues to be worked out one way or the other, especially if removal of the binary package from the tree keeps automated orphaning scripts from triggering on istanbul. -jef"or i could just script an hourly rebuild attempt of istanbul that I know will fail, wasting buildhost resources, just to make everyone happy with the rebuild is being attempted"spaleta From dragoran at feuerpokemon.de Tue Feb 28 19:03:27 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 28 Feb 2006 20:03:27 +0100 Subject: fc4/5 wine-0.9.8 In-Reply-To: <44034373.7000808@feuerpokemon.de> References: <4401954E.1000502@feuerpokemon.de> <20060227135623.05d515d3@alkaid.a.lan> <44034373.7000808@feuerpokemon.de> Message-ID: <44049E7F.5050702@feuerpokemon.de> dragoran wrote: > Andreas Bierfert wrote: > >> On Sun, 26 Feb 2006 12:47:26 +0100 >> dragoran wrote: >> >> >> >>> wine 0.9.8 >>> was build for fc3 but not for fc4/fc5 (maybe because buildsys was >>> broken) >>> but now it works and it is still at 0.9.7 >>> >> >> >> Did you mean fc3/fc5 and not fc4? >> Anyway... just restarted the fc4 build. Thanks. >> >> - Andreas >> >> >> > yes sorry missed the one devel report. > now its in the build report but I can't find it (no mirror has it) .... From bugs.michael at gmx.net Tue Feb 28 19:06:24 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 28 Feb 2006 20:06:24 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1141148822.2278.34.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <1141148822.2278.34.camel@localhost.localdomain> Message-ID: <20060228200624.4a6ed73c.bugs.michael@gmx.net> On Tue, 28 Feb 2006 18:47:02 +0100, Thorsten Leemhuis wrote: > Am Sonntag, den 26.02.2006, 20:21 +0100 schrieb Aurelien Bompard: > >[...] > > > So, how to proceed? Bug the maintainers with a E-Mail directly? Probably > > > a good idea. I'll try to write a script that does this. > > This is the best idea at the moment IMHO.[...] > > Anyway, a direct mail reminder will probably help a lot. > > Done some minutes ago (sorry, I didn't find time for it earlier); > Initial results: > > Keith G. Robertson-Turner: "This account is protected against spam, > using the SpamArrest service, which is a 'C/R' or 'Challenge/Response' > service. [...]" > > /me wonders if Keith was wise enough to whitelist the E-Mail address > used by bugzilla.redhat.com. Keith? I believe he has been active in one of his tripwire bug reports in bugzilla recently. > aaron.bennett_AT_olin.edu -- "Delivery failed." > colin_AT_fedoraproject.org -- "User unknown" > lemenkov at newmail.ru -- "User unknown" > > :-(( > > :-(( > > /me wonders how many of the other mail addresses from owners.list don't > work but chooses to simply ignore that for now. Well, this time around you do some of the things I did for FE3/4. Discovering old packages and orphans, invalid mail addresses, invalid addresses in bugzilla, sending packagers reminders, helping out with fixes for GCC, and so on. It is also something which decreases the fun in "sponsoring contributors". Theoretically, the time which is necessary to "get to know" other people should be longer before somebody would feel good about "sponsoring" somebody else from the other end of the world. All you get from some people in return for reviews, guidance, approval, sponsorship, is that they drop off silently or complain on IRC. It's really sad. I agree. But hey, the single last thing that protects the repository from daily breakage is the review and sponsorship process. If we removed that last hurdle (and everyone, remember, updates and upgrades don't need any reviews as with old fedora.us QA procedures), we could put up the wooden sign which reads "playground". I do like the idea of "hostile takeover" of potentially orphaned packages where current official packager doesn't respond to bug reports and private mail. It is in the community's best interest to have actively maintained packages within Fedora Extras. It ought not result in anarchy, however. Hence it should happen in accordance with well-defined policies, tracking and perhaps explicit approval. Because there's a tendency among some packagers to treat package upgrades lightly. From bugzilla at redhat.com Tue Feb 28 19:01:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 14:01:18 -0500 Subject: [Bug 179940] Review Request: ruby-http-access2 In-Reply-To: Message-ID: <200602281901.k1SJ1IOg006587@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ruby-http-access2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179940 ------- Additional Comments From tibbs at math.uh.edu 2006-02-28 14:01 EST ------- Sorry, I had no idea you had supplied the ruby spec template. I just noticed that it had popped up with the latest fedora-rpmdevtools release. I would suggest using "Ruby license" and ignoring warnings from rpmlint until that license can be added, unless the discussion on fedora-extras-list turns in another direction. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From seg at haxxed.com Tue Feb 28 19:18:33 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 28 Feb 2006 13:18:33 -0600 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <20060224155022.4f347b0c.bugs.michael@gmx.net> References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <20060223182942.GQ2730@free.fr> <87r75thmku.fsf@kosh.bigo.ensc.de> <1140755074.14289.270.camel@mccallum.corsepiu.local> <87d5hdf4cd.fsf@kosh.bigo.ensc.de> <20060224155022.4f347b0c.bugs.michael@gmx.net> Message-ID: <1141154313.4052.5.camel@localhost> On Fri, 2006-02-24 at 15:50 +0100, Michael Schwendt wrote: > So, once more, what is > the overwhelming reason for preferring a competing C library over the > core > OS's C library? End users may want to build small static binaries to put on rescue disks and whatnot. dietlibc is useful to end users. But just because its packaged in extras, doesn't mean other packages should be using it. dietlibc should stay in IMHO, but perhaps an explicit policy should be made that such packages are there for end user use only, and MUST not be used by other FE packages. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From oliver.andrich at gmail.com Tue Feb 28 19:24:46 2006 From: oliver.andrich at gmail.com (Oliver Andrich) Date: Tue, 28 Feb 2006 20:24:46 +0100 Subject: The Ruby license In-Reply-To: References: Message-ID: <20060228192446.GA3980@fitheach> On Tue, Feb 28, 2006 at 11:28:53AM -0600, Jason L Tibbitts III wrote: > I couldn't find any of the valid licenses in rpmlint which matches the > Ruby license. These days everything in Ruby is dual Ruby/GPL; it it > acceptable to use just GPL or should "Ruby license" be added to > rpmlint's list? (If so, I'll file a bug.) > > Note that the OSI doesn't list Ruby's license, but Debian accepts it > as free: http://www.debian.org/legal/licenses/ And it is even GPL compatible, so I also think it would be a good thing to update rpmlint. http://www.gnu.org/licenses/license-list.html Best regards, Oliver -- Oliver Andrich --- oliver.andrich at gmail.com --- http://roughbook.de/ From kevin-fedora-extras at scrye.com Tue Feb 28 19:32:50 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Tue, 28 Feb 2006 12:32:50 -0700 (MST) Subject: 2nd Fedora Extras Review Day - 2006-03-05 (sunday) Message-ID: <20060228.123250.647505333.kevin@scrye.com> Come one, Come all... it's the 2nd Fedora Extras Review day. More information at: http://fedoraproject.org/wiki/Extras/ReviewDay The last review day was pretty slow and poorly attended, so this might be the last one if there isn't more interest. What better way to spend a sunday afternoon that reviewing some packages? Come join us on #fedora-extras on irc.freenode.net. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From bugzilla at redhat.com Tue Feb 28 19:35:08 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 14:35:08 -0500 Subject: [Bug 179940] Review Request: ruby-http-access2 In-Reply-To: Message-ID: <200602281935.k1SJZ8J2015914@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ruby-http-access2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179940 ------- Additional Comments From oliver.andrich at gmail.com 2006-02-28 14:35 EST ------- Spec Name or Url: http://roughbook.de/fedora/ruby-http-access2.spec SRPM Name or Url: http://roughbook.de/fedora/ruby-http-access2-2.0.6-2.src.rpm I fixed everything except: - I stick with license Distributable cause it the "redhat" way to handle it. - I skipped the tests so far, cause I have to figure out how to check the results in a spec file. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From tibbs at math.uh.edu Tue Feb 28 19:41:13 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 28 Feb 2006 13:41:13 -0600 Subject: The Ruby license In-Reply-To: (Greg DeKoenigsberg's message of "Tue, 28 Feb 2006 12:35:48 -0500 (EST)") References: Message-ID: I've filed https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183384 - J< From bugzilla at redhat.com Tue Feb 28 19:40:45 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 14:40:45 -0500 Subject: [Bug 179940] Review Request: ruby-http-access2 In-Reply-To: Message-ID: <200602281940.k1SJejHP017864@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ruby-http-access2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179940 ------- Additional Comments From tibbs at math.uh.edu 2006-02-28 14:40 EST ------- "Distributable" is clearly an inferior solution. The Ruby License is free (or so says Debian and the FSF), so the License: tag should read "GPL/Ruby License" and hopefully rpmlint will catch up. Until then, we'll just have to ignore the warning. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 28 19:42:20 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 14:42:20 -0500 Subject: [Bug 179439] Review Request: linux-libertine-fonts - TrueType serif fonts In-Reply-To: Message-ID: <200602281942.k1SJgK0X018337@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: linux-libertine-fonts - TrueType serif fonts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179439 ------- Additional Comments From kevin at tummy.com 2006-02-28 14:42 EST ------- Looks good to me. Works fine here. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From michael at knox.net.nz Tue Feb 28 19:49:04 2006 From: michael at knox.net.nz (Michael J Knox) Date: Wed, 01 Mar 2006 08:49:04 +1300 Subject: 2nd Fedora Extras Review Day - 2006-03-05 (sunday) In-Reply-To: <20060228.123250.647505333.kevin@scrye.com> References: <20060228.123250.647505333.kevin@scrye.com> Message-ID: <1141156144.3526.18.camel@cosima.et.endace.com> On Tue, 2006-02-28 at 12:32 -0700, Kevin Fenzi wrote: > Come one, Come all... it's the 2nd Fedora Extras Review day. > > More information at: > > http://fedoraproject.org/wiki/Extras/ReviewDay > > The last review day was pretty slow and poorly attended, so this might > be the last one if there isn't more interest. > > What better way to spend a sunday afternoon that reviewing some > packages? Come join us on #fedora-extras on irc.freenode.net. > > kevin I think these are a great idea. I was not able to attend the last one and will make a good effort to take part in this one. Even if turn out is low, I think they should still be organized. Not everyone can commit to it at times, but the following review day might more suitable to them etc Michael From bugzilla at redhat.com Tue Feb 28 19:49:25 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 14:49:25 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602281949.k1SJnPwP020404@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From ville.skytta at iki.fi 2006-02-28 14:49 EST ------- Yes, because the perl.prov and perl.req and friends scriptles don't currently take any arguments but just read the filelist from stdin. Backslash protects the $* so it won't be expanded too early when emitting the script. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From buildsys at fedoraproject.org Tue Feb 28 20:02:37 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 28 Feb 2006 15:02:37 -0500 (EST) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060228200237.E94577FD0@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 3 cogito-0.17-1.fc3 denyhosts-2.1-2.1.fc3 polyxmass-bin-0.9.2-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue Feb 28 20:02:47 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 28 Feb 2006 15:02:47 -0500 (EST) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060228200247.53FEE7FD0@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 10 cogito-0.17-1.fc4 denyhosts-2.1-2.1.fc4 gcfilms-6.1-2.fc4 gpa-0.7.0-5.fc4 libopensync-plugin-gpe-0.18-2.fc4 lucidlife-0.9-3.fc4 perl-Imager-0.47-1.fc4 polyxmass-bin-0.9.2-1.fc4 python-kid-0.9-1.fc4 ruby-mysql-2.7-8.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue Feb 28 20:03:24 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 28 Feb 2006 15:03:24 -0500 (EST) Subject: Fedora Extras development Package Build Report Message-ID: <20060228200324.DCBBD7FD0@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 43 SIMVoleon-2.0.1-3.fc5 akode-2.0-1.fc5.1 asciidoc-7.0.2-2.fc5 bidiv-1.5-3.fc5 cogito-0.17-1.fc5 cyrus-imapd-2.2.12-1.fc5 denyhosts-2.1-2.fc5 gcfilms-6.1-2.fc5 gpa-0.7.0-5.fc5 gramps-2.0.10-2.fc5 hspell-0.9-7.fc5 html-xml-utils-3.7-3.fc5 itext-1.3-1jpp_8.fc5 jakarta-commons-cli-1.0-6jpp_6.fc5 lablgtk-2.6.0-3.fc5 lib3ds-1.2.0-7.fc5 libapreq2-2.07-1.1.fc5 libmthca-1.0-0.5.rc7.fc5 libopensync-plugin-gpe-0.18-2.fc5 librsync-0.9.7-4 lucidlife-0.9-3.fc5 orange-0.3-0.cvs20051118.fc5.2 pbzip2-0.9.6-2.fc5 perl-Gnome2-Canvas-1.002-4.fc5 perl-Gtk2-GladeXML-1.005-4.fc5 perl-Imager-0.47-1.fc5 perl-Net-SSLeay-1.30-3.fc5 perl-Spiffy-0.30-4.fc5 perl-Test-MockObject-1.02-1.fc5 perl-WWW-Mechanize-1.18-2.fc5 polyxmass-bin-0.9.2-1.fc5 python-kid-0.9-1.fc5 ruby-mysql-2.7-8.fc5 synce-0.9.1-7.fc5 synce-gnomevfs-0.9.0-3.fc5 synce-software-manager-0.9.0-5.fc5 synce-trayicon-0.9.0-6.fc5 taarich-1.20051120-5.fc5 testdisk-6.2-4.fc5 tinyfugue-5.0-0.2.b7 valknut-0.3.7-7.fc5 w3c-libwww-5.4.1-0.2.20060206cvs.fc5 wmweather+-2.9-3.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugs.michael at gmx.net Tue Feb 28 20:29:58 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 28 Feb 2006 21:29:58 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <604aa7910602281034m6e631569rbab3d2feaa33fec@mail.gmail.com> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <1141148822.2278.34.camel@localhost.localdomain> <604aa7910602281034m6e631569rbab3d2feaa33fec@mail.gmail.com> Message-ID: <20060228212958.0cd4046a.bugs.michael@gmx.net> On Tue, 28 Feb 2006 13:34:17 -0500, Jeff Spaleta wrote: > How do I get the currently depedancy broken istanbul package out of > the binary devel tree? Via remove request on FC5Status page in the Wiki. From bugs.michael at gmx.net Tue Feb 28 20:33:14 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 28 Feb 2006 21:33:14 +0100 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <1141154313.4052.5.camel@localhost> References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <20060223182942.GQ2730@free.fr> <87r75thmku.fsf@kosh.bigo.ensc.de> <1140755074.14289.270.camel@mccallum.corsepiu.local> <87d5hdf4cd.fsf@kosh.bigo.ensc.de> <20060224155022.4f347b0c.bugs.michael@gmx.net> <1141154313.4052.5.camel@localhost> Message-ID: <20060228213314.5ea4b913.bugs.michael@gmx.net> On Tue, 28 Feb 2006 13:18:33 -0600, Callum Lerwick wrote: > On Fri, 2006-02-24 at 15:50 +0100, Michael Schwendt wrote: > > So, once more, what is > > the overwhelming reason for preferring a competing C library over the > > core > > OS's C library? > > End users may want to [...] Your reply is out of context, unfortunately. I didn't ask why dietlibc exists. From bugs.michael at gmx.net Tue Feb 28 20:40:02 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 28 Feb 2006 21:40:02 +0100 Subject: Hula Message-ID: <20060228214002.4c39d2d4.bugs.michael@gmx.net> What the heck is up with Hula? $ grep hula owners.list Fedora Extras|hula|A calendar and mail server|extras-orphan at fedoraproject.org|extras-qa at fedoraproject.org| ---------------------------- revision 1.27 date: 2005/07/23 00:39:39; author: wtogami; state: Exp; lines: +1 -1 hula-kevin at iprone.com doesn't exist From bugzilla at redhat.com Tue Feb 28 20:34:00 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 15:34:00 -0500 Subject: [Bug 179940] Review Request: ruby-http-access2 In-Reply-To: Message-ID: <200602282034.k1SKY07S001054@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ruby-http-access2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179940 ------- Additional Comments From oliver.andrich at gmail.com 2006-02-28 15:33 EST ------- Spec Name or Url: http://roughbook.de/fedora/ruby-http-access2.spec SRPM Name or Url: http://roughbook.de/fedora/ruby-http-access2-2.0.6-3.src.rpm Changed license to Ruby License after reading the implicit acceptance of https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183384 Any further show stoppers before accepting the package? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 28 20:42:25 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 15:42:25 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602282042.k1SKgPVB003447@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From steve at silug.org 2006-02-28 15:42 EST ------- Ah, so to be more obvious to a perl person, would this be acceptable? cat <<'END' > %{name}-prov #!/bin/sh %{__perl_provides} "$@" | sed -e '/^perl(DB)$/d' END %define __perl_provides %{_builddir}/Spiffy-%{version}/%{name}-prov chmod +x %{__perl_provides} -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 28 20:53:14 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 15:53:14 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602282053.k1SKrEK1005789@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From steve at silug.org 2006-02-28 15:53 EST ------- Actually, since anything using Module::Signature doesn't like for anything to be in the build directory that isn't in MANIFEST, I'm going with this (unless there are any objections): cat <<'END' > %{_sourcedir}/%{name}-prov #!/bin/sh %{__perl_provides} "$@" | sed -e '/^perl(DB)$/d' END %define __perl_provides %{_sourcedir}/%{name}-prov chmod +x %{__perl_provides} -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 28 21:00:54 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 16:00:54 -0500 Subject: [Bug 183028] Review Request: perl-Spiffy In-Reply-To: Message-ID: <200602282100.k1SL0sXc008012@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From ville.skytta at iki.fi 2006-02-28 16:00 EST ------- That will leave trash behind in sourcedir. And for a number of reasons, all Module::Signature checks should be disabled anyway (the exact way how to do that varies between packages). More info: http://koti.welho.com/vskytta/packagers-handbook/packagers-handbook.html#guidelines-perl-cpansign -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From lostson at lostsonsvault.org Tue Feb 28 21:09:47 2006 From: lostson at lostsonsvault.org (lostson) Date: Tue, 28 Feb 2006 15:09:47 -0600 Subject: 2nd Fedora Extras Review Day - 2006-03-05 (sunday) In-Reply-To: <20060228.123250.647505333.kevin@scrye.com> References: <20060228.123250.647505333.kevin@scrye.com> Message-ID: <1141160987.14869.0.camel@localhost.localdomain> On Tue, 2006-02-28 at 12:32 -0700, Kevin Fenzi wrote: > Come one, Come all... it's the 2nd Fedora Extras Review day. > > More information at: > > http://fedoraproject.org/wiki/Extras/ReviewDay > > The last review day was pretty slow and poorly attended, so this might > be the last one if there isn't more interest. > > What better way to spend a sunday afternoon that reviewing some > packages? Come join us on #fedora-extras on irc.freenode.net. > > kevin Do you have to be a dev to attend ? I can make it and am very interested in helping out if i can. -- LostSon http://www.lostsonsvault.org /\ \ \ \__/ \__/ \ \ (oo) (oo) \_\/~~\_/~~\_ _.-~===========~-._ (___________________) \_______/ I Want To Believe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Tue Feb 28 21:25:57 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 28 Feb 2006 22:25:57 +0100 Subject: 2nd Fedora Extras Review Day - 2006-03-05 (sunday) In-Reply-To: <20060228.123250.647505333.kevin@scrye.com> References: <20060228.123250.647505333.kevin@scrye.com> Message-ID: <20060228212557.GB3003@free.fr> > The last review day was pretty slow and poorly attended, so this might > be the last one if there isn't more interest. Some people that weren't on irc that day were reminded about reviews to finish by the announce of a review day, however... -- Pat From bugzilla at redhat.com Tue Feb 28 21:25:29 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 16:25:29 -0500 Subject: [Bug 179940] Review Request: ruby-http-access2 In-Reply-To: Message-ID: <200602282125.k1SLPTCo014955@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ruby-http-access2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179940 ------- Additional Comments From tibbs at math.uh.edu 2006-02-28 16:25 EST ------- It should be either "GPL/Ruby License" or "GPL or Ruby License" since the package is dual-licensed. You can remove any reference to %{ruby_sitearch} as this is a noarch package. rpmlint says: W: ruby-http-access2 invalid-license Ruby License E: ruby-http-access2 only-non-binary-in-usr-lib W: ruby-http-access2 no-documentation We can discount the first warning. I think we must discount the second warning; rpmlint has checks to prevent this for /usr/lib/ruby but not for /usr/lib/site_ruby. I would argue that site_ruby should be in /usr/lib/ruby (as Perl does things) but the current organization is the way Red Hat set things up. The second warning is valid; you seem to have dropped the documentation. At minimum you should package README.txt and the sample directory. The package doesn't build in mock for some reason. It looks like ruby isn't installed in the build environment at the time the first two lines of the specfile are executed. I need to spend some more time debugging this. More in about 90 minutes. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From seg at haxxed.com Tue Feb 28 21:42:57 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 28 Feb 2006 15:42:57 -0600 Subject: Review Rules and staticly linked packages agains dietlibc In-Reply-To: <20060228213314.5ea4b913.bugs.michael@gmx.net> References: <0ML21M-1FCIHb0sIF-0002D3@mrelayeu.kundenserver.de> <20060223155252.GK2730@free.fr> <87fymavwfa.fsf@kosh.bigo.ensc.de> <20060223182942.GQ2730@free.fr> <87r75thmku.fsf@kosh.bigo.ensc.de> <1140755074.14289.270.camel@mccallum.corsepiu.local> <87d5hdf4cd.fsf@kosh.bigo.ensc.de> <20060224155022.4f347b0c.bugs.michael@gmx.net> <1141154313.4052.5.camel@localhost> <20060228213314.5ea4b913.bugs.michael@gmx.net> Message-ID: <1141162977.4052.9.camel@localhost> > Your reply is out of context, unfortunately. I didn't ask why dietlibc > exists. This thread is such a giant mess I wasn't sure where to put it. ;P -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From bugzilla at redhat.com Tue Feb 28 21:35:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 16:35:44 -0500 Subject: [Bug 179940] Review Request: ruby-http-access2 In-Reply-To: Message-ID: <200602282135.k1SLZiKn018161@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ruby-http-access2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179940 ------- Additional Comments From ville.skytta at iki.fi 2006-02-28 16:35 EST ------- Doesn't the Ruby License imply GPL? At least /usr/share/doc/ruby-*/COPYING seems to say so, and that's what I thought when I said I'd accept the patch adding "Ruby License" to rpmlint's valid licenses list. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 28 21:44:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 16:44:02 -0500 Subject: [Bug 179940] Review Request: ruby-http-access2 In-Reply-To: Message-ID: <200602282144.k1SLi2wX020451@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ruby-http-access2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179940 ------- Additional Comments From oliver.andrich at gmail.com 2006-02-28 16:44 EST ------- Well, I would suggest to stick with Ruby License. Cause all the ruby packages can be distributed under the Ruby License _or_ the GPL. The Ruby License is a valid OSS license, its is compatible with the GPL and it is lighter. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at redhat.com Tue Feb 28 21:45:28 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 16:45:28 -0500 Subject: [Bug 181068] Review Request: html401-dtds - HTML 4.01 document type definitions In-Reply-To: Message-ID: <200602282145.k1SLjSJp020899@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: html401-dtds - HTML 4.01 document type definitions https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181068 ------- Additional Comments From ville.skytta at iki.fi 2006-02-28 16:45 EST ------- Ok, so... how about a formal acceptance or an explicit list of blockers so we could proceed here? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From mmcgrath at fedoraproject.org Tue Feb 28 21:47:12 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 28 Feb 2006 15:47:12 -0600 Subject: 2nd Fedora Extras Review Day - 2006-03-05 (sunday) In-Reply-To: <20060228212557.GB3003@free.fr> References: <20060228.123250.647505333.kevin@scrye.com> <20060228212557.GB3003@free.fr> Message-ID: <4404C4E0.4020901@fedoraproject.org> Patrice Dumas wrote: >>The last review day was pretty slow and poorly attended, so this might >>be the last one if there isn't more interest. >> >> > >Some people that weren't on irc that day were reminded about reviews to >finish by the announce of a review day, however... > >-- >Pat > > > On this very special day I'd encourage anyone who's interested to take a look at OTRS. We're really wanting to us it in Fedora-Admin but can't use it yet because its not in extras :-D -Mike From bugzilla at redhat.com Tue Feb 28 21:49:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 16:49:13 -0500 Subject: [Bug 179940] Review Request: ruby-http-access2 In-Reply-To: Message-ID: <200602282149.k1SLnDcN021998@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ruby-http-access2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179940 ------- Additional Comments From oliver.andrich at gmail.com 2006-02-28 16:49 EST ------- Spec Name or Url: http://roughbook.de/fedora/ruby-http-access2.spec SRPM Name or Url: http://roughbook.de/fedora/ruby-http-access2-2.0.6-4.src.rpm Fixed: - missing README.txt - removed reference of %{ruby_sitearch} in the requirements The rpmlint error about the binary lib is missing when I call rpmlint. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From jfontain at free.fr Tue Feb 28 21:59:52 2006 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Tue, 28 Feb 2006 22:59:52 +0100 Subject: strange rebuild configure error on FC5 (tktable) Message-ID: <4404C7D8.1010501@free.fr> When trying to rebuild tktable for FE5, I got the following error (from http://buildsys.fedoraproject.org/logs/fedora-development-extras/5422-tktable-2.9-8.fc5/i386/build.log): ./configure: line 9966: syntax error near unexpected token `(' ./configure: line 9966: ` case `(ac_space=' '; set | grep ac_space) 2>&1` in' According to the above, it would seems the following script would fail on FC5: case `(ac_space=' '; set | grep ac_space) 2>&1` in *ac_space=\ *) echo 0 ;; *) echo 1 ;; esac; I doubt it (works on FC4, must be something else in configure), but I do not have an FC5 box to check it... If you have a little time to spare to help, here are the files: http://jfontain.free.fr/tmp/Tktable2.9.tar.gz http://jfontain.free.fr/tmp/tktable.spec Thanks! I'll keep looking on my side... -- Jean-Luc Fontaine http://jfontain.free.fr/ From bugzilla at redhat.com Tue Feb 28 22:02:43 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 17:02:43 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602282202.k1SM2hgB026448@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From fedora at soeterbroek.com 2006-02-28 17:02 EST ------- Spec Name or Url: http://www.soeterbroek.com/linux/fedora/extras/heartbeat/heartbeat.spec SRPM Name or Url: http://www.soeterbroek.com/linux/fedora/extras/heartbeat/heartbeat-2.0.3-7.src.rpm * Tue Feb 28 2006 Joost Soeterbroek - 2.0.3-7 - fixed more rpmlint errors and warnings remaining rpmlint issues: W: heartbeat unstripped-binary-or-object /usr/bin/cl_status - I do not know how to fix. Is this warning safe to ignore? W: heartbeat dangling-symlink /etc/ha.d/resource.d/ldirectord /usr/sbin/ldirectord The symbolic link points nowhere. - I do not know how to fix. Is this warning safe to ignore? W: heartbeat dangerous-command-in-%postun userdel - I do not know how to fix. Is this warning safe to ignore? W: heartbeat-ldirectord devel-file-in-non-devel-package /usr/sbin/supervise-ldirectord-config A development file (usually source code) is located in a non-devel package. If you want to include source code in your package, be sure to create a development package. - I think this is an error on the part of rpmlint. I can not see any reason this file would be flagged as a 'development file', while it isn't. E: heartbeat-ldirectord incoherent-logrotate-file /etc/logrotate.d/ldirectord Your logrotate file should be named /etc/logrotate.d/. - Agree with the error, but changing /etc/logrotate.d/ldirectord to /etc/logrotate.d/heartbeat-ldirectord would mean changing a lot of non-trivial things in source package. Can we safely ignore this? W: heartbeat-ldirectord incoherent-init-script-name ldirectord The init script name should be the same as the package name in lower case. - same as above. Can we safely ignore this? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugs.michael at gmx.net Tue Feb 28 22:16:18 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 28 Feb 2006 17:16:18 -0500 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-02-28 Message-ID: <200602282216.k1SMGIkH007385@mx1.redhat.com> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- at-poke 0.2.2-2.i386 cyrus-imapd 2.2.12-6.fc4.i386 cyrus-imapd-murder 2.2.12-6.fc4.i386 cyrus-imapd-nntp 2.2.12-6.fc4.i386 cyrus-imapd-utils 2.2.12-6.fc4.i386 gnomebaker 0.5.1-2.fc5.i386 gstreamer08-python 0.8.3-1.fc5.i386 istanbul 0.1.1-5.i386 libgdamm 1.3.7-2.fc5.i386 libopensync-plugin-irmc 0.18-5.fc5.i386 pam_mount 0.9.25-4.i386 perl-Cyrus 2.2.12-6.fc4.i386 sabayon-admin 2.12.1-2.i386 scalapack 1.7-7.fc4.i386 tidy-devel 0.99.0-8.20051025.fc5.i386 tripwire 2.3.1-22.i386 up-imapproxy 1.2.4-4.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- at-poke 0.2.2-2.ppc cyrus-imapd 2.2.12-6.fc4.ppc cyrus-imapd-murder 2.2.12-6.fc4.ppc cyrus-imapd-nntp 2.2.12-6.fc4.ppc cyrus-imapd-utils 2.2.12-6.fc4.ppc gnomebaker 0.5.1-2.fc5.ppc gstreamer08-python 0.8.3-1.fc5.ppc istanbul 0.1.1-5.ppc libgdamm 1.3.7-2.fc5.ppc libopensync-plugin-irmc 0.18-5.fc5.ppc pam_mount 0.9.25-4.ppc perl-Cyrus 2.2.12-6.fc4.ppc sabayon-admin 2.12.1-2.ppc scalapack 1.7-7.fc4.ppc tidy-devel 0.99.0-8.20051025.fc5.ppc up-imapproxy 1.2.4-4.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- at-poke 0.2.2-2.x86_64 cernlib 2005-7.fc5.x86_64 cernlib-packlib 2005-7.fc5.x86_64 cyrus-imapd 2.2.12-6.fc4.x86_64 cyrus-imapd-murder 2.2.12-6.fc4.x86_64 cyrus-imapd-nntp 2.2.12-6.fc4.x86_64 cyrus-imapd-utils 2.2.12-6.fc4.x86_64 gnomebaker 0.5.1-2.fc5.x86_64 gstreamer08-python 0.8.3-1.fc5.x86_64 istanbul 0.1.1-5.x86_64 libgdamm 1.3.7-2.fc5.x86_64 libopensync-plugin-irmc 0.18-5.fc5.x86_64 pam_mount 0.9.25-4.x86_64 paw 2005-7.fc5.x86_64 perl-Cyrus 2.2.12-6.fc4.x86_64 sabayon-admin 2.12.1-2.x86_64 scalapack 1.7-7.fc4.x86_64 tidy-devel 0.99.0-8.20051025.fc5.x86_64 up-imapproxy 1.2.4-4.fc5.x86_64 ---------------------------------------------------------------------- New report for: andreas.bierfert AT lowlatency.de package: libopensync-plugin-irmc - 0.18-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libopenobex-1.0.so.1 From bugzilla at redhat.com Tue Feb 28 22:31:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 17:31:44 -0500 Subject: [Bug 177818] Review Request: adplug In-Reply-To: Message-ID: <200602282231.k1SMVi1O003754@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: adplug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177818 ------- Additional Comments From triad at df.lth.se 2006-02-28 17:31 EST ------- Here: Spec Name or Url: http://www.df.lth.se/~triad/krad/fc/adplug.spec SRPM Name or Url: http://www.df.lth.se/~triad/krad/fc/adplug-1.5.1-4.20060228cvs.src.rpm This incorporates the move of adplugdb into $(sharedstatedir)/adplug on my local build it resolves into /usr/com/adplug which rpmlint naturally complains about but otherwise it's clean I think. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Feb 28 22:37:36 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 17:37:36 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602282237.k1SMbaeW005971@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From paul at city-fan.org 2006-02-28 17:37 EST ------- (In reply to comment #35) > remaining rpmlint issues: > > W: heartbeat unstripped-binary-or-object /usr/bin/cl_status > - I do not know how to fix. Is this warning safe to ignore? Why isn't it stripped? What permissions does it get installed with? > W: heartbeat dangling-symlink /etc/ha.d/resource.d/ldirectord /usr/sbin/ldirectord > The symbolic link points nowhere. > - I do not know how to fix. Is this warning safe to ignore? This symlink is explicitly created in the spec file: ( cd $RPM_BUILD_ROOT/etc/ha.d/resource.d ln -s /usr/sbin/ldirectord ldirectord ) Is it pointing from the right place to the right place? > W: heartbeat dangerous-command-in-%postun userdel > - I do not know how to fix. Is this warning safe to ignore? Don't delete user or group accounts on package deletion, leave them there. > W: heartbeat-ldirectord devel-file-in-non-devel-package > /usr/sbin/supervise-ldirectord-config > A development file (usually source code) is located in a non-devel > package. If you want to include source code in your package, be sure to > create a development package. > - I think this is an error on the part of rpmlint. I can not > see any reason this file would be flagged as a > 'development file', while it isn't. It's probably the "-config" suffix of the name (without looking at the rpmlint code). Looks bogus to me too. > E: heartbeat-ldirectord incoherent-logrotate-file /etc/logrotate.d/ldirectord > Your logrotate file should be named /etc/logrotate.d/. > - Agree with the error, but changing /etc/logrotate.d/ldirectord > to /etc/logrotate.d/heartbeat-ldirectord would mean changing a > lot of non-trivial things in source package. Can we safely ignore > this? Why wouldn't it just be a "mv"? Having said that, heartbeat-ldirectord is a bit of a mouthful. > W: heartbeat-ldirectord incoherent-init-script-name ldirectord > The init script name should be the same as the package name in lower case. > - same as above. Can we safely ignore this? I'd say so, yes. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From ville.skytta at iki.fi Tue Feb 28 22:48:47 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 01 Mar 2006 00:48:47 +0200 Subject: Going to push kernel module test builds in devel Message-ID: <1141166927.32428.57.camel@bobcat.mine.nu> FYI: I'm going to push some thinkpad-kmod and lirc-kmod test builds through the devel buildsys tomorrowish. This will be done in order to verify the state of the infrastructure and to see if we could resort to hardcoding stuff until better ways to do things exist. The results of these particular builds are not really intended to stay in the devel repo permanently but just for approximately two Rawhide kernel respins, so as far as I'm concerned, they'll disappear well before FC5 and the real thing will follow later on. From rc040203 at freenet.de Tue Feb 28 23:02:00 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 01 Mar 2006 00:02:00 +0100 Subject: no Job ID was provided in the time required (Was: Please rebuild your packages in Fedora Extras development) In-Reply-To: <20060228171419.01D7F8DA9@truhe.thl.home> References: <20060228171419.01D7F8DA9@truhe.thl.home> Message-ID: <1141167720.8565.99.camel@mccallum.corsepiu.local> On Tue, 2006-02-28 at 18:14 +0100, Thorsten Leemhuis wrote: > Hi! > > This is a script-generated mail to remind you that some of your arch- > specific Fedora Extras packages were not yet rebuild for FC5. All arch- > specific packages in "extras/development/" that were build before > '2006-02-13 02:48:00 -0500' > > should be rebuild as soon as possible. We're running out of time, FC5 > is near! I'd do, but ATM, I am facing sporadic ... Package ... enqueued. (However, no Job ID was provided in the time required) ... again (2 out of ca. 9 requests failed) IMO, such mass rebuild requests are not of much use before we have more reliable buildsystem. Ralf From andreas.bierfert at lowlatency.de Tue Feb 28 23:16:45 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Wed, 1 Mar 2006 00:16:45 +0100 Subject: fc4/5 wine-0.9.8 In-Reply-To: <44049E7F.5050702@feuerpokemon.de> References: <4401954E.1000502@feuerpokemon.de> <20060227135623.05d515d3@alkaid.a.lan> <44034373.7000808@feuerpokemon.de> <44049E7F.5050702@feuerpokemon.de> Message-ID: <20060301001645.2eda63e6@alkaid.a.lan> On Tue, 28 Feb 2006 20:03:27 +0100 dragoran wrote: > now its in the build report but I can't find it (no mirror has it) .... Happened to all packages from 27th I believe don't know whats up there... - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From bugzilla at redhat.com Tue Feb 28 23:22:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 18:22:48 -0500 Subject: [Bug 179940] Review Request: ruby-http-access2 In-Reply-To: Message-ID: <200602282322.k1SNMmEc016049@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ruby-http-access2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179940 ------- Additional Comments From tibbs at math.uh.edu 2006-02-28 18:22 EST ------- Here is the beginning of Ruby's COPYING file: ---- Ruby is copyrighted free software by Yukihiro Matsumoto . You can redistribute it and/or modify it under either the terms of the GPL (see the file GPL), or the conditions below: ---- I'll drop my objection and leave it to the experts to decide whether that means the license should be "GPL/Ruby Licence" or just "Ruby License". I've been basing my comments on Perl, where everything is GPL/Artistic. In any case, the real problems I'm seeing is that it won't build in mock. Here is the tail of the build log: /sbin/runuser -c 'rpm -Uvh --nodeps /builddir/build/originals/ruby-http-access2-2.0.6-4.src.rpm' mockbuild ruby-http-access2 warning: user tibbs does not exist - using root ##############################################warning: user tibbs does not exist - using root #warning: user tibbs does not exist - using root ### sh: ruby: command not found sh: ruby: command not found sh: ruby: command not found error: line 21: Empty tag: Requires: Building target platforms: i386 Building for target i386 Cleaning up... Done. This happens directly after the "groupinstall build" phase completes; ruby was not installed at that time. This happens on two separate systems, one x86_64 and the other i386; both are building on both FC4 and the development branch. Even though it's not a problem, I do wonder why you don't see the rpmlint complaint: E: ruby-http-access2 only-non-binary-in-usr-lib I'm running rpmlint-0.75-1.fc4. The mock build is a killer, though; if my setup isn't busted then it implies that you won't be able to get through the build system. Have you tried it yourself? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From wart at kobold.org Tue Feb 28 23:32:21 2006 From: wart at kobold.org (Michael Thomas) Date: Tue, 28 Feb 2006 15:32:21 -0800 Subject: strange rebuild configure error on FC5 (tktable) In-Reply-To: <4404C7D8.1010501@free.fr> References: <4404C7D8.1010501@free.fr> Message-ID: <4404DD85.1050504@kobold.org> Jean-Luc Fontaine wrote: > When trying to rebuild tktable for FE5, I got the following error (from > http://buildsys.fedoraproject.org/logs/fedora-development-extras/5422-tktable-2.9-8.fc5/i386/build.log): > > ./configure: line 9966: syntax error near unexpected token `(' > ./configure: line 9966: ` case `(ac_space=' '; set | grep ac_space) 2>&1` in' > > According to the above, it would seems the following script would fail > on FC5: > > case `(ac_space=' '; set | grep ac_space) 2>&1` in > *ac_space=\ *) > echo 0 > ;; > *) > echo 1 > ;; > esac; > > I doubt it (works on FC4, must be something else in configure), but I do > not have an FC5 box to check it... This is a problem with the tcl.m4 file that came with earlier versions of Tcl. There is a quoting bug in the file that was not exposed until bash 3.1 was packaged with FC5. Many tcl extensions were bitten by this bug. Grab the latest tcl.m4 from sourceforge and re-run autoconf to fix the problem. Or take a look at the patch that I made for tclxml in FE (which fixes some missing lib problems as well). FWIW, the offending line in tcl.m4 is: system=MP-RAS=`awk '{print }' /etc/.relid'` (note the unmatched single quote near the end) --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From tibbs at math.uh.edu Tue Feb 28 23:35:46 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 28 Feb 2006 17:35:46 -0600 Subject: 2nd Fedora Extras Review Day - 2006-03-05 (sunday) In-Reply-To: <4404C4E0.4020901@fedoraproject.org> (Mike McGrath's message of "Tue, 28 Feb 2006 15:47:12 -0600") References: <20060228.123250.647505333.kevin@scrye.com> <20060228212557.GB3003@free.fr> <4404C4E0.4020901@fedoraproject.org> Message-ID: >>>>> "MM" == Mike McGrath writes: MM> On this very special day I'd encourage anyone who's interested to MM> take a look at OTRS. I made a comment regarding the only problem I saw on a quick reading of the spec file a couple of weeks ago. Maybe my comment was misguided, but I received no response. If I get through my current pile of reviews and nobody else has stepped in then I'll be happy to take a closer look. - J< From tibbs at math.uh.edu Tue Feb 28 23:47:38 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 28 Feb 2006 17:47:38 -0600 Subject: Odd mock build problem Message-ID: I'm trying to build the submitted ruby-http-access2 package in mock: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179940 http://roughbook.de/fedora/ruby-http-access2-2.0.6-4.src.rpm http://roughbook.de/fedora/ruby-http-access2.spec Unfortunately I can't build on i386 or x86_64, FC4 or development. A build outside of mock works fine. The failed builds don't get as far as completely setting up the root; the end of root.log is: /sbin/runuser -c 'rpm -Uvh --nodeps /builddir/build/originals/ruby-http-access2-2.0.6-4.src.rpm' mockbuild ruby-http-access2 warning: user tibbs does not exist - using root ##############################################warning: user tibbs does ##############################################not exist - using root #warning: user tibbs does not exist - using root ### sh: ruby: command not found sh: ruby: command not found sh: ruby: command not found error: line 21: Empty tag: Requires: Building target platforms: x86_64 Building for target x86_64 Cleaning up... Done. The full log is at http://www.math.uh.edu/~tibbs/rpms/ruby-http-access2/root.log My guess is that mock is trying to determine the BuildRequires:, but it can't generate the srpm because of these statements at the top of the spec: %{!?ruby_sitelib: %define ruby_sitelib %(ruby -rrbconfig -e "puts %Config::CONFIG['sitedir']")} %{!?ruby_sitearch: %define ruby_sitearch %(ruby -rrbconfig -e "puts %Config::CONFIG['sitearchdir']")} ruby isn't installed as part of the base environment. I wonder if my mock setup isn't messed up somehow. Could someone else try a quick mock build? - J< From ellson at research.att.com Tue Feb 28 23:56:56 2006 From: ellson at research.att.com (John Ellson) Date: Tue, 28 Feb 2006 18:56:56 -0500 Subject: strange rebuild configure error on FC5 (tktable) In-Reply-To: <4404C7D8.1010501@free.fr> References: <4404C7D8.1010501@free.fr> Message-ID: <4404E348.8000101@research.att.com> Jean-Luc Fontaine wrote: > When trying to rebuild tktable for FE5, I got the following error (from > http://buildsys.fedoraproject.org/logs/fedora-development-extras/5422-tktable-2.9-8.fc5/i386/build.log): > > ./configure: line 9966: syntax error near unexpected token `(' > ./configure: line 9966: ` case `(ac_space=' '; set | grep ac_space) 2>&1` in' > > According to the above, it would seems the following script would fail > on FC5: > > case `(ac_space=' '; set | grep ac_space) 2>&1` in > *ac_space=\ *) > echo 0 > ;; > *) > echo 1 > ;; > esac; > > I doubt it (works on FC4, must be something else in configure), but I do > not have an FC5 box to check it... > > If you have a little time to spare to help, here are the files: > http://jfontain.free.fr/tmp/Tktable2.9.tar.gz > http://jfontain.free.fr/tmp/tktable.spec > > Thanks! I'll keep looking on my side... > > The problem is bash-3.1-6.2, but I don't know exactly what. Downgrading to bash-3.0-31 from FC4 on an otherwise current Rawhide fixes the problem. Changing the first line of configure to "#!/bin/ksh" also fixes the problem. Commenting out TEA_CONFIG_CFLAGS _and_ TEA_ENABLE_SYMBOLS avoids the problem, but I think TEA_ENABLE_SYMBOLS invokes TEA_CONFIG_CFLAGS so I think the problem is triggered by something in TEA_CONFIG_CFLAGS. Thats all the clues I have so far... John From bugzilla at redhat.com Tue Feb 28 23:58:25 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 28 Feb 2006 18:58:25 -0500 Subject: [Bug 180897] Review Request: heartbeat In-Reply-To: Message-ID: <200602282358.k1SNwPq0021968@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: heartbeat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 ------- Additional Comments From orion at cora.nwra.com 2006-02-28 18:58 EST ------- (In reply to comment #35) > W: heartbeat unstripped-binary-or-object /usr/bin/cl_status > - I do not know how to fix. Is this warning safe to ignore? I can't reproduce, might be a local build issue. > W: heartbeat dangling-symlink /etc/ha.d/resource.d/ldirectord /usr/sbin/ldirectord > The symbolic link points nowhere. > - I do not know how to fix. Is this warning safe to ignore? > The link is in both heartbeat and heartbeat-ldirectord. Remove from heartbeat: --- heartbeat.spec.orig 2006-02-28 15:38:00.000000000 -0700 +++ heartbeat.spec 2006-02-28 16:50:52.000000000 -0700 @@ -200,6 +200,7 @@ %{_libdir}/libstonithd.so.* %{_prefix}/lib/ocf %{_sysconfdir}/ha.d/resource.d/ +%exclude %{_sysconfdir}/ha.d/resource.d/ldirectord %{_sysconfdir}/init.d/heartbeat %config(noreplace) %{_sysconfdir}/logrotate.d/heartbeat %dir %{_var}/lib/heartbeat > W: heartbeat dangerous-command-in-%postun userdel > - I do not know how to fix. Is this warning safe to ignore? As above, don't delete the user. > W: heartbeat-ldirectord devel-file-in-non-devel-package > /usr/sbin/supervise-ldirectord-config > A development file (usually source code) is located in a non-devel > package. If you want to include source code in your package, be sure to > create a development package. > - I think this is an error on the part of rpmlint. I can not > see any reason this file would be flagged as a > 'development file', while it isn't. Agreed. > E: heartbeat-ldirectord incoherent-logrotate-file /etc/logrotate.d/ldirectord > Your logrotate file should be named /etc/logrotate.d/. > - Agree with the error, but changing /etc/logrotate.d/ldirectord > to /etc/logrotate.d/heartbeat-ldirectord would mean changing a > lot of non-trivial things in source package. Can we safely ignore > this? > > W: heartbeat-ldirectord incoherent-init-script-name ldirectord > The init script name should be the same as the package name in lower case. > - same as above. Can we safely ignore this? > Yes, or alternative is to name the subpackage "ldirectord" instead of "heartbeat-ldirectord". %package -n ldirectord does this (and same for %files, %post, etc). Might be a good idea if it seems likely that this will be split off (the description indicates that it is "standalone"). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.