From mricon at gmail.com Sun May 1 04:04:52 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Sun, 1 May 2005 00:04:52 -0400 Subject: I'm looking for someone to sponsor me. In-Reply-To: <4273124C.3040306@mbm.nifty.com> References: <4273124C.3040306@mbm.nifty.com> Message-ID: On 4/30/05, ??? wrote: > Hi, > > I'm Ryo Dairiki, a packager of SCIM projects. > (If you don't know SCIM, please visit http://www.scim-im.org/) > Now I'm thinking of adding the packages to Fedora Extras. > > I've already finished "Fedora Individual Contributor Lisence Agreement" > and made a request for membership in the cvsextras. > Now I'm looking for a person who sponsor me. I can sponsor you. My on-file email address is icon-at-linux-dot-duke-dot-edu. Regards and welcome, -- Konstantin Ryabitsev Zlotniks, INC From enrico.scholz at informatik.tu-chemnitz.de Sun May 1 13:13:48 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 01 May 2005 15:13:48 +0200 Subject: [PATCH] let Makefile.common respect $RPM_BUILD_DIR Message-ID: <87ll6zccmr.fsf@kosh.bigo.ensc.de> Hello, please apply the attached patch. It makes the 'patch' and 'rediff' targets work when $(RPM_BUILD_DIR) was set to another directory. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: common-builddir.patch Type: text/x-patch Size: 1710 bytes Desc: Make 'patch' and 'rediff' work when RPM_BUILD_DIR is set URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From Jochen at herr-schmitt.de Sun May 1 18:42:11 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Sun, 01 May 2005 20:42:11 +0200 Subject: Review Request: inadyn In-Reply-To: <1114729727.5061.34.camel@ignacio.ignacio.lan> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <0ML21M-1DQRXN2I2w-0004zr@mrelayeu.kundenserver.de> <0MKxQS-1DQo9k40Yz-00056x@mrelayeu.kundenserver.de> <1114614916.5061.12.camel@ignacio.ignacio.lan> <1114642372.5061.18.camel@ignacio.ignacio.lan> <1114699593.5061.27.camel@ignacio.ignacio.lan> <0ML2Dk-1DRDb81Qoz-0002e8@mrelayeu.kundenserver.de> <1114729727.5061.34.camel@ignacio.ignacio.lan> Message-ID: <0ML25U-1DSJOO3PY8-0008Qk@mrelayeu.kundenserver.de> On Thu, 28 Apr 2005 19:08:47 -0400, you wrote: >Nope, still didn't work. I went to DynDNS's website, created the host >entry as 127.0.0.1, and still got the same output from inadyn. Sorry, it deficuilt to find out your prbleme without knewing your environment. For my tests, I have done the following. 1.) Start up the PPPoE connection. 2.) Start up inadyn. 3.) make a ping to the registered dynDNS hostname. I think, it's very important, to start inadyn after the interface to the official internet is up. If not, the time between to update times will not be reached, so your dynDNS address will be shown to a old IP address. Best Regards: Jochen Schmitt From bdpepple at ameritech.net Sun May 1 19:47:07 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Sun, 01 May 2005 19:47:07 +0000 Subject: New Package Sponser Request: Gossip & Loudmouth Message-ID: <1114976827.25152.4.camel@localhost.localdomain> Gossip: Gnome Jabber client. http://piedmont.homelinux.org/fedora/gossip/gossip.spec http://piedmont.homelinux.org/fedora/gossip/gossip-0.8-1.src.rpm Loudmouth: C library for programming with the Jabber protocol. http://piedmont.homelinux.org/fedora/gossip/loudmouth.spec http://piedmont.homelinux.org/fedora/gossip/loudmouth-0.17.2-1.src.rpm Thanks, /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 gauret at free.fr Mon May 2 08:26:44 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 02 May 2005 10:26:44 +0200 Subject: Deprecated packages Message-ID: Hi all, What should we do with packages of closed projects ? For example, elmo (a text-based mail client) fails to build on PPC today, and the project is closed since January (http://elmo.sf.net). Maybe this build failure can be fixed this time, but how should we depreciate packages in general ? Is there some flag to add, some list where it should be appended, or should we just remove the directory from CVS ? Thanks for your input Aur?lien -- http://gauret.free.fr ~~~~ Jabber : abompard at jabber.fr "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." -- Rich Cook From lemenkov at newmail.ru Mon May 2 10:30:47 2005 From: lemenkov at newmail.ru (lemenkov at newmail.ru) Date: 02 May 2005 14:30:47 +0400 Subject: Request for addition: GRASS, Quantum GIS Message-ID: Hello, All! I decided to add little help for whose, who uses FC at GIS-workstations, and created spec-files for two GIS-applications: * GRASS Geographic Resources Analysis Support System. spec: http://paula.comtv.ru/grass.spec source: http://grass.itc.it/grass60/source/grass-6.0.0.tar.gz * Quantum GIS. spec: http://paula.comtv.ru/qgis.spec source: http://prdownloads.sourceforge.net/qgis/qgis-0.6.0.tar.gz?download (n.b.: Qantum GIS depends on GEOS, which stillnot in FE-repository, but exists at newrpms). Please tell me, what should I do next for the sake of inclusion of these two applications to the FC/FE-package tree? And maybe someone will be so patient what he'll review my spec-files? -- With best regards, Peter Lemenkov. From bugs.michael at gmx.net Mon May 2 11:18:48 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 2 May 2005 13:18:48 +0200 Subject: Request for addition: GRASS, Quantum GIS In-Reply-To: References: Message-ID: <20050502131848.37475c43.bugs.michael@gmx.net> On 02 May 2005 14:30:47 +0400, lemenkov at newmail.ru wrote: > Hello, All! > > I decided to add little help for whose, who > uses FC at GIS-workstations, and created spec-files for two > GIS-applications: > > * GRASS Geographic Resources Analysis Support System. > > spec: http://paula.comtv.ru/grass.spec > source: http://grass.itc.it/grass60/source/grass-6.0.0.tar.gz > > * Quantum GIS. > > spec: http://paula.comtv.ru/qgis.spec > source: http://prdownloads.sourceforge.net/qgis/qgis-0.6.0.tar.gz?download > > (n.b.: Qantum GIS depends on GEOS, which stillnot in FE-repository, > but exists at newrpms). > > > Please tell me, what should I do next for the sake of inclusion of > these two applications to the FC/FE-package tree? > > And maybe someone will be so patient what he'll review my spec-files? Please see list archives around April 18th (yeah, would be easier if everyone used a clear subject line like you did): https://www.redhat.com/archives/fedora-extras-list/2005-April/msg00474.html https://www.redhat.com/archives/fedora-extras-list/2005-April/msg00476.html We now have several people who want to work on GIS related packages and their inter-dependencies, which is the opportunity to team up. I can help with reviewing spec files, but the more important thing would be to produce packages, which work and e.g. fix the issues linked in above message. From rc040203 at freenet.de Mon May 2 11:18:23 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 02 May 2005 13:18:23 +0200 Subject: Request for addition: GRASS, Quantum GIS In-Reply-To: References: Message-ID: <1115032703.24385.372.camel@mccallum.corsepiu.local> On Mon, 2005-05-02 at 14:30 +0400, lemenkov at newmail.ru wrote: > Hello, All! > > I decided to add little help for whose, who > uses FC at GIS-workstations, and created spec-files for two > GIS-applications: > > * GRASS Geographic Resources Analysis Support System. > > spec: http://paula.comtv.ru/grass.spec Well, I know, I won't make friends with what I am going to say now, but sometimes it's inevitable. This spec is not even close to be in shape for inclusion in FE. Just to mention a few issues: * %define _prefix /usr/lib Non-acceptable, if the grass sources want --prefix=/usr/lib, pass --prefix=%{_libdir}, but ... if this is required, it's strongly justified to have doubts on grass source code. * make \ ... install-strip Don't use install-strip, this will break the debug-packages rpm is supposed to produce. * Provides: *.so .... This rarely can be correct. You also want to have a look into http://bugzilla.fedora.us/show_bug.cgi?id=1965 Ralf From qspencer at ieee.org Mon May 2 14:12:07 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Mon, 02 May 2005 09:12:07 -0500 Subject: Review Request: fftw3, cln, GiNaC, octave-forge In-Reply-To: <426D5140.6010408@ieee.org> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D01D5.6080605@ieee.org> <426D5140.6010408@ieee.org> Message-ID: <42763537.6090804@ieee.org> Updates of all of these packages were checked into CVS a week ago. I requested a review then, but due to lack of response, I'm sending out the request again. Note that octave-forge requires GiNaC, which requires cln. regards, Quentin From bugs.michael at gmx.net Mon May 2 14:37:50 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 2 May 2005 16:37:50 +0200 Subject: Review Request: fftw3, cln, GiNaC, octave-forge In-Reply-To: <42763537.6090804@ieee.org> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D01D5.6080605@ieee.org> <426D5140.6010408@ieee.org> <42763537.6090804@ieee.org> Message-ID: <20050502163750.1e907694.bugs.michael@gmx.net> On Mon, 02 May 2005 09:12:07 -0500, Quentin Spencer wrote: > Updates of all of these packages were checked into CVS a week ago. I > requested a review then, but due to lack of response, I'm sending out > the request again. Note that octave-forge requires GiNaC, which requires > cln. Who was the one who volunteered to review and approve your packages? Also, where are "octave" and "octave-devel"? They have been removed from Fedora Core. From qspencer at ieee.org Mon May 2 14:48:33 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Mon, 02 May 2005 09:48:33 -0500 Subject: Review Request: fftw3, cln, GiNaC, octave-forge In-Reply-To: <20050502163750.1e907694.bugs.michael@gmx.net> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D01D5.6080605@ieee.org> <426D5140.6010408@ieee.org> <42763537.6090804@ieee.org> <20050502163750.1e907694.bugs.michael@gmx.net> Message-ID: <42763DC1.1030200@ieee.org> Michael Schwendt wrote: >On Mon, 02 May 2005 09:12:07 -0500, Quentin Spencer wrote: > > > >>Updates of all of these packages were checked into CVS a week ago. I >>requested a review then, but due to lack of response, I'm sending out >>the request again. Note that octave-forge requires GiNaC, which requires >>cln. >> >> > >Who was the one who volunteered to review and approve your packages? >Also, where are "octave" and "octave-devel"? They have been removed from >Fedora Core. > > Spot was my original sponsor, who did look at my packages before I checked them into CVS. Several people responded to my initial CVS checkins, and I have corrected all of the problems that came up. Does that constitute approval or does there need to be a final review? I haven't started working on packaging octave yet because I'm still working on an FC3 system at the moment. My original plan was to get these packages added, approved, and built on FC3, and then begin working on building octave for FC4. From the octave mailing lists I understand this could be a bit of an undertaking with the move from g77 to gfortran. Anyway, this was a perfectly reasonable plan back in February when I first asked for sponsorship, but obviously the process has taken much longer than planned. Should I work on building octave for FC4 before I get any of these approved? -Quentin From bugs.michael at gmx.net Mon May 2 15:32:40 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 2 May 2005 17:32:40 +0200 Subject: Review Request: fftw3, cln, GiNaC, octave-forge In-Reply-To: <42763DC1.1030200@ieee.org> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D01D5.6080605@ieee.org> <426D5140.6010408@ieee.org> <42763537.6090804@ieee.org> <20050502163750.1e907694.bugs.michael@gmx.net> <42763DC1.1030200@ieee.org> Message-ID: <20050502173240.6c49a19c.bugs.michael@gmx.net> On Mon, 02 May 2005 09:48:33 -0500, Quentin Spencer wrote: > >Who was the one who volunteered to review and approve your packages? > >Also, where are "octave" and "octave-devel"? They have been removed from > >Fedora Core. > > > > > Spot was my original sponsor, who did look at my packages before I > checked them into CVS. Several people responded to my initial CVS > checkins, and I have corrected all of the problems that came up. Does > that constitute approval or does there need to be a final review? "Approval" is when somebody sends an "APPROVED: packagename(s)" message to fedora-extras-commits list. > I haven't started working on packaging octave yet because I'm still > working on an FC3 system at the moment. My original plan was to get > these packages added, approved, and built on FC3, and then begin working > on building octave for FC4. Then you should request an FC-3 branch for your packages first. This is done here http://fedoraproject.org/wiki/Extras/CVSSyncNeeded and is explained in the Fedora Extras CVS FAQ, too. > From the octave mailing lists I understand > this could be a bit of an undertaking with the move from g77 to > gfortran. Anyway, this was a perfectly reasonable plan back in February > when I first asked for sponsorship, but obviously the process has taken > much longer than planned. Should I work on building octave for FC4 > before I get any of these approved? IMHO, I would really make sure there is an upgrade path to FC4 for your packages. If you released packages only for FC3 and [late in the FC4 development cycle] ran into problems with getting them to build/work on FC4, that would not be a good situation. FC4 should take precedence. From qspencer at ieee.org Mon May 2 15:56:28 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Mon, 02 May 2005 10:56:28 -0500 Subject: Review Request: fftw3, cln, GiNaC, octave-forge In-Reply-To: <20050502173240.6c49a19c.bugs.michael@gmx.net> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D01D5.6080605@ieee.org> <426D5140.6010408@ieee.org> <42763537.6090804@ieee.org> <20050502163750.1e907694.bugs.michael@gmx.net> <42763DC1.1030200@ieee.org> <20050502173240.6c49a19c.bugs.michael@gmx.net> Message-ID: <42764DAC.9010808@ieee.org> Michael Schwendt wrote: >On Mon, 02 May 2005 09:48:33 -0500, Quentin Spencer wrote: > > >>>Who was the one who volunteered to review and approve your packages? >>>Also, where are "octave" and "octave-devel"? They have been removed from >>>Fedora Core. >>> >>> >>Spot was my original sponsor, who did look at my packages before I >>checked them into CVS. Several people responded to my initial CVS >>checkins, and I have corrected all of the problems that came up. Does >>that constitute approval or does there need to be a final review? >> >> >"Approval" is when somebody sends an "APPROVED: packagename(s)" message >to fedora-extras-commits list. > > I was aware of that, but who has authority to do this? Can I do it, based on having corrected all outstanding issues? Or must my sponsor or somebody else? I have followed the discussions about this on the list, but I never felt like it was completely clarified. >>I haven't started working on packaging octave yet because I'm still >>working on an FC3 system at the moment. My original plan was to get >>these packages added, approved, and built on FC3, and then begin working >>on building octave for FC4. >> >> > >Then you should request an FC-3 branch for your packages first. >This is done here http://fedoraproject.org/wiki/Extras/CVSSyncNeeded >and is explained in the Fedora Extras CVS FAQ, too. > > I was under the impression that I had to get the package approved first (this question is not address in either of those places). If that's not the case, I'll go ahead and request a branch. >>From the octave mailing lists I understand >>this could be a bit of an undertaking with the move from g77 to >>gfortran. Anyway, this was a perfectly reasonable plan back in February >>when I first asked for sponsorship, but obviously the process has taken >>much longer than planned. Should I work on building octave for FC4 >>before I get any of these approved? >> >> > >IMHO, I would really make sure there is an upgrade path to FC4 for your >packages. If you released packages only for FC3 and [late in the FC4 >development cycle] ran into problems with getting them to build/work on >FC4, that would not be a good situation. FC4 should take precedence. > > Of course. Like I said, the original intention was for this to be done long before "late in the FC4 development cycle". Hopefully I'll get to work on packaging octave soon. -Quentin From bugs.michael at gmx.net Mon May 2 16:13:38 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 2 May 2005 18:13:38 +0200 Subject: Review Request: fftw3, cln, GiNaC, octave-forge In-Reply-To: <42764DAC.9010808@ieee.org> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D01D5.6080605@ieee.org> <426D5140.6010408@ieee.org> <42763537.6090804@ieee.org> <20050502163750.1e907694.bugs.michael@gmx.net> <42763DC1.1030200@ieee.org> <20050502173240.6c49a19c.bugs.michael@gmx.net> <42764DAC.9010808@ieee.org> Message-ID: <20050502181338.32193a99.bugs.michael@gmx.net> On Mon, 02 May 2005 10:56:28 -0500, Quentin Spencer wrote: > >>Spot was my original sponsor, who did look at my packages before I > >>checked them into CVS. Several people responded to my initial CVS > >>checkins, and I have corrected all of the problems that came up. Does > >>that constitute approval or does there need to be a final review? > >> > >> > >"Approval" is when somebody sends an "APPROVED: packagename(s)" message > >to fedora-extras-commits list. > > > > > I was aware of that, but who has authority to do this? The current NewPackageProcess page in the Wiki uses the term "package sponsor", which is the person who volunteers to review and approve your packages with the notification message mentioned above. > Can I do it, > based on having corrected all outstanding issues? Or must my sponsor or > somebody else? I have followed the discussions about this on the list, > but I never felt like it was completely clarified. Just following discussions silently may not be enough. Voice your opinion in case something in the documentation is not clear. I've volunteered to update the NewPackageProcess [in a few hours probably], because almost everyone agreed that the used terminology ("package sponsor") is confusing, and some steps are ambigous, too. But I still have the feeling that there is strong disagreement about the overall process, the reviewing, the approvals. > >>I haven't started working on packaging octave yet because I'm still > >>working on an FC3 system at the moment. My original plan was to get > >>these packages added, approved, and built on FC3, and then begin working > >>on building octave for FC4. > >> > >> > > > >Then you should request an FC-3 branch for your packages first. > >This is done here http://fedoraproject.org/wiki/Extras/CVSSyncNeeded > >and is explained in the Fedora Extras CVS FAQ, too. > > > > > I was under the impression that I had to get the package approved first > (this question is not address in either of those places). If that's not > the case, I'll go ahead and request a branch. Explicit approval is necessary prior to building packages. From qspencer at ieee.org Mon May 2 16:13:20 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Mon, 02 May 2005 11:13:20 -0500 Subject: Need Wiki Edit privileges In-Reply-To: <42764DAC.9010808@ieee.org> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D01D5.6080605@ieee.org> <426D5140.6010408@ieee.org> <42763537.6090804@ieee.org> <20050502163750.1e907694.bugs.michael@gmx.net> <42763DC1.1030200@ieee.org> <20050502173240.6c49a19c.bugs.michael@gmx.net> <42764DAC.9010808@ieee.org> Message-ID: <427651A0.802@ieee.org> My username is QuentinSpencer, and I need edit permission for the following Wiki pages: Extras/CVSSyncNeeded Extras/FC3Status Extras/FC4Status Extras/BugzillaAdmin -Quentin From Jochen at herr-schmitt.de Mon May 2 17:21:10 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 02 May 2005 19:21:10 +0200 Subject: Review Request: inadyn In-Reply-To: <1114731248.5061.40.camel@ignacio.ignacio.lan> References: <0MKxQS-1DQo9k40Yz-00056x@mrelayeu.kundenserver.de> <1114614916.5061.12.camel@ignacio.ignacio.lan> <1114642372.5061.18.camel@ignacio.ignacio.lan> <1114699593.5061.27.camel@ignacio.ignacio.lan> <0ML2Dk-1DRDb81Qoz-0002e8@mrelayeu.kundenserver.de> <1114729727.5061.34.camel@ignacio.ignacio.lan> <1114730272.4620.33.camel@localhost.localdomain> <1114731248.5061.40.camel@ignacio.ignacio.lan> Message-ID: <0ML25U-1DSebW2Z0e-0007BZ@mrelayeu.kundenserver.de> On Thu, 28 Apr 2005 19:34:08 -0400, you wrote: >What really bugs me about this problem is that I don't get any useful >diagnostics from the program whatsoever, even at maximum verbosity. it will be nice, if you can insert the line verbose 5 into /etc/inadyn.conf ent send me the produced log entries after you have finished your test drive. Best Regards: Jochen Schmitt From bugs.michael at gmx.net Mon May 2 18:02:41 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 2 May 2005 20:02:41 +0200 Subject: Need Wiki Edit privileges In-Reply-To: <427651A0.802@ieee.org> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D01D5.6080605@ieee.org> <426D5140.6010408@ieee.org> <42763537.6090804@ieee.org> <20050502163750.1e907694.bugs.michael@gmx.net> <42763DC1.1030200@ieee.org> <20050502173240.6c49a19c.bugs.michael@gmx.net> <42764DAC.9010808@ieee.org> <427651A0.802@ieee.org> Message-ID: <20050502200241.06abcdce.bugs.michael@gmx.net> On Mon, 02 May 2005 11:13:20 -0500, Quentin Spencer wrote: > My username is QuentinSpencer, and I need edit permission for the > following Wiki pages: > > Extras/CVSSyncNeeded > Extras/FC3Status > Extras/FC4Status > Extras/BugzillaAdmin Done. Note that you can edit other pages, too. From tian at c-sait.net Mon May 2 21:00:40 2005 From: tian at c-sait.net (Tian) Date: Mon, 2 May 2005 23:00:40 +0200 Subject: Review Request: GCfilms (new package) Message-ID: <20050502230040.4c3ab365@tianbox> Hello, This package is still not included. I am doing the CVS access operations (looking for a sponsor) at the same time. But I'd like to have some reviews about the .spec file I used to create an RPM for GCfilms application ( https://gna.org/projects/gcfilms/ ). The .spec file can be found here: http://cvs.gna.org/viewcvs/gcfilms/gcfilms/packages/fedora/gcfilms.spec?rev=HEAD&content-type=text/vnd.viewcvs-markup An RPM generated with it is here: http://download.gna.org/gcfilms/fedora/3/gcfilms-5.0-1.noarch.rpm Thanks to let me know about any problem there could be or if something is not compliant with Fedora Extras rules. Best regards, Tian. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 3 00:05:41 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 3 May 2005 02:05:41 +0200 Subject: Imported to CVS, review requested: Glide3 In-Reply-To: <42735CC8.60208@hhs.nl> References: <42712EA1.2050401@hhs.nl> <20050429120923.0fd0a318@python2> <42735CC8.60208@hhs.nl> Message-ID: <20050503020541.5046d453@python2> Hans de Goede wrote : > This and a bunch of other stuff should be fixed in CVS now, please try > the current CVS version. Still fails for me on FC 3 x86_64 :-/ (my Devel root is trashed ATM) I'm really impressed nevertheless by the amount of hacking you achieve, though... pretty much like for xmame :-) [...] gcc -DX11 -fomit-frame-pointer -funroll-loops -fexpensive-optimizations - ffast-math -DBIG_OPT -Wall -DGLIDE_LIB -DGLIDE3 -DGLIDE3_ALPHA -DH3 - DGLIDE_PACKET3_TRI_SETUP=1 -DUSE_PACKET_FIFO=1 -DGLIDE_HW_TRI_SETUP=1 - DFX_GLIDE_NAPALM=1 -DFX_GLIDE_H5_CSIM=1 -DGLIDE_PLUG -DGLIDE_SPLASH - DFX_STATIC_BUILD -DGLIDE_INIT_HWC -DGLIDE_USE_C_TRISETUP -I../../../../h5/ glide3/src -I../../../h5/incsrc -I../../../../h5/incsrc -I../../../../h5/ minihwc -I. -I../../../../swlibs/fxmemmap -I../../../../swlibs/fxmisc - I../../../../swlibs/newpci/pcilib -I../../../../swlibs/texus2/lib -O2 -g - pipe -m64 -O6 -Wno-unknown-pragmas -Wno-unused-value -Wno-unused -Wp,- MD,.deps/fifo.pp -c ../../../../h5/glide3/src/fifo.c -o fifo.o >/dev/null 2>&1 /lib/cpp -I. -DUSE_PACKET_FIFO=1 ../../../../h5/glide3/src/cpudtect.s > cpudtect.tmp.s libtool --mode=compile gcc -I. -c -o cpudtect.lo cpudtect.tmp.s gcc -I. -c cpudtect.tmp.s -fPIC -DPIC -o .libs/cpudtect.o ../../../../h5/glide3/src/cpudtect.s: Assembler messages: ../../../../h5/glide3/src/cpudtect.s:118: Error: suffix or operands invalid for `push' ../../../../h5/glide3/src/cpudtect.s:119: Error: suffix or operands invalid for `push' ../../../../h5/glide3/src/cpudtect.s:120: Error: suffix or operands invalid for `push' ../../../../h5/glide3/src/cpudtect.s:121: Error: suffix or operands invalid for `push' ../../../../h5/glide3/src/cpudtect.s:126: Error: suffix or operands invalid for `pop' ../../../../h5/glide3/src/cpudtect.s:129: Error: suffix or operands invalid for `push' ../../../../h5/glide3/src/cpudtect.s:132: Error: suffix or operands invalid for `pop' ../../../../h5/glide3/src/cpudtect.s:190: Error: suffix or operands invalid for `pop' ../../../../h5/glide3/src/cpudtect.s:191: Error: suffix or operands invalid for `pop' ../../../../h5/glide3/src/ cpudtect.s:192: Error: suffix or operands invalid for `pop' ../../../../h5/ glide3/src/cpudtect.s:193: Error: suffix or operands invalid for `pop' ../../../../h5/glide3/src/cpudtect.s:328: Error: suffix or operands invalid for `push' ../../../../h5/glide3/src/cpudtect.s:335: Error: suffix or operands invalid for `pop' ../../../../h5/glide3/src/cpudtect.s:347: Error: suffix or operands invalid for `push' ../../../../h5/glide3/src/ cpudtect.s:355: Error: suffix or operands invalid for `pop' make[3]: *** [cpudtect.lo] Error 1 make[3]: Leaving directory `/usr/src/rpm/BUILD/ Glide3/build-5/h5/glide3/src' Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.20_FC3 Load : 0.47 0.97 1.17 From adrian at lisas.de Tue May 3 06:48:42 2005 From: adrian at lisas.de (Adrian Reber) Date: Tue, 3 May 2005 08:48:42 +0200 Subject: packages for review: openbox and friends In-Reply-To: References: <20050420052915.GA11961@lisas.de> <20050423155830.GB9919@lisas.de> Message-ID: <20050503064842.GA8791@lisas.de> On Mon, Apr 25, 2005 at 04:21:50PM -0400, Chris Ricker wrote: > The pkconfig files in openbox-devel require at least libxml2-devel, glib2-devel and xorg-x11-devel so that these Requires should be added to openbox-devel. It would be really nice if the default menu openbox shows would include some other applications. Instead of mozilla I would prefer that firefox is there. I also think that it doesn't make much sense to have quark in the Applications menu as well as any of the games which may not be there. Maybe you could replace the entries in the game menu with games that are available from FE. Adrian From ryo-dairiki at mbm.nifty.com Tue May 3 07:27:56 2005 From: ryo-dairiki at mbm.nifty.com (Ryo Dairiki) Date: Tue, 03 May 2005 16:27:56 +0900 Subject: New package: SCIM Message-ID: <427727FC.8040001@mbm.nifty.com> Hi, I'm thinking of add the package of SCIM to fedora extras. Could you review them and report me problems? You can get my packages from here: http://sourceforge.net/projects/scim Notes: Scim-qtimm installs xinput-qtimm into /etc/X11/xinit/xinitrc.d/, which exports "QT_IM_MODULE" entry in /etc/X11/xinit/xinput.d/scim. It seems it will be of no use soon. See: http://sourceforge.net/projects/scim Regards, Ryo Dairiki From bugs.michael at gmx.net Tue May 3 12:26:43 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 3 May 2005 14:26:43 +0200 Subject: sponsors still needed for new packages, extras not advertised on fedorawebsite? In-Reply-To: <20050429181738.7cb32fdc.bugs.michael@gmx.net> References: <427137B3.9080009@hhs.nl> <20050429150649.7960a12c.bugs.michael@gmx.net> <42725126.9080708@hhs.nl> <20050429181738.7cb32fdc.bugs.michael@gmx.net> Message-ID: <20050503142643.2cd978b1.bugs.michael@gmx.net> An overhaul of the interim new package process is in the Wiki now. I've also removed instructions, which are covered by other Wiki pages already, e.g. "UsingCvsFaq", "BugzillaAdmin" and "CVSSyncNeeded". If those pages need a better explanation, the particular page that is unclear should be improved instead of trying to squeeze everything onto the NewPackageProcess page. From paul at dwerryhouse.com.au Tue May 3 13:30:42 2005 From: paul at dwerryhouse.com.au (Paul Dwerryhouse) Date: Tue, 3 May 2005 23:30:42 +1000 Subject: New Package Sponsor Request: radiusclient and portslave Message-ID: <20050503133042.GA22829@dwerryhouse.com.au> I'd like to package radiusclient & portslave. Would someone care to have a look at them and tell me of any problems? Radiusclient: A library for writing radius clients http://leapster.org/linux/fedora/radiusclient/radiusclient.spec http://leapster.org/linux/fedora/radiusclient/radiusclient-0.3.2-2.src.rpm Portslave: Radius & PPP enabled terminal server http://leapster.org/linux/fedora/portslave/portslave.spec http://leapster.org/linux/fedora/portslave/portslave-2002.10.21-2.src.rpm Cheers, Paul -- Paul Dwerryhouse | PGP Key ID: 0x6B91B584 Melbourne, Australia | paul at dwerryhouse.com.au From ivazquez at ivazquez.net Tue May 3 15:55:42 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 03 May 2005 11:55:42 -0400 Subject: Review Request: inadyn In-Reply-To: <0ML25U-1DSJOO3PY8-0008Qk@mrelayeu.kundenserver.de> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <0ML21M-1DQRXN2I2w-0004zr@mrelayeu.kundenserver.de> <0MKxQS-1DQo9k40Yz-00056x@mrelayeu.kundenserver.de> <1114614916.5061.12.camel@ignacio.ignacio.lan> <1114642372.5061.18.camel@ignacio.ignacio.lan> <1114699593.5061.27.camel@ignacio.ignacio.lan> <0ML2Dk-1DRDb81Qoz-0002e8@mrelayeu.kundenserver.de> <1114729727.5061.34.camel@ignacio.ignacio.lan> <0ML25U-1DSJOO3PY8-0008Qk@mrelayeu.kundenserver.de> Message-ID: <1115135743.5462.3.camel@ignacio.ignacio.lan> On Sun, 2005-05-01 at 20:42 +0200, Jochen Schmitt wrote: > On Thu, 28 Apr 2005 19:08:47 -0400, you wrote: > > >Nope, still didn't work. I went to DynDNS's website, created the host > >entry as 127.0.0.1, and still got the same output from inadyn. > > Sorry, it deficuilt to find out your prbleme without knewing your > environment. > > For my tests, I have done the following. > > 1.) Start up the PPPoE connection. > > 2.) Start up inadyn. > > 3.) make a ping to the registered dynDNS hostname. > > I think, it's very important, to start inadyn after the interface > to the official internet is up. Yes, this is pretty much exactly what I was doing. I'd love to be able to give you more diagnostics, but as I said all it gives is a mutilated log entry. I'm going to look into the source to see what I can do about this. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Jochen at herr-schmitt.de Tue May 3 16:02:03 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 03 May 2005 18:02:03 +0200 Subject: Review Request: inadyn In-Reply-To: <1114731248.5061.40.camel@ignacio.ignacio.lan> References: <0MKxQS-1DQo9k40Yz-00056x@mrelayeu.kundenserver.de> <1114614916.5061.12.camel@ignacio.ignacio.lan> <1114642372.5061.18.camel@ignacio.ignacio.lan> <1114699593.5061.27.camel@ignacio.ignacio.lan> <0ML2Dk-1DRDb81Qoz-0002e8@mrelayeu.kundenserver.de> <1114729727.5061.34.camel@ignacio.ignacio.lan> <1114730272.4620.33.camel@localhost.localdomain> <1114731248.5061.40.camel@ignacio.ignacio.lan> Message-ID: <0ML25U-1DSzqU1HQ2-0007FA@mrelayeu.kundenserver.de> On Thu, 28 Apr 2005 19:34:08 -0400, you wrote: >What really bugs me about this problem is that I don't get any useful >diagnostics from the program whatsoever, even at maximum verbosity. I have import a new version of the SPEC file and the initscript, becouse on http://www.fedoraproject.org, I have read, that you should use /sbin/service to control initscript in the scrptlets. Becouse, Ignacio have some trouble during the test of inadyn, it will be nice, if an other person may test the package too. The problem is, that it's very deficuilt to determinate, why the test fails on Ignaicio's computer. Best Regards: Jochen Schmitt From Jochen at herr-schmitt.de Tue May 3 16:05:59 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 03 May 2005 18:05:59 +0200 Subject: Review Request: inadyn In-Reply-To: <1115135743.5462.3.camel@ignacio.ignacio.lan> References: <0MKxQS-1DQo9k40Yz-00056x@mrelayeu.kundenserver.de> <1114614916.5061.12.camel@ignacio.ignacio.lan> <1114642372.5061.18.camel@ignacio.ignacio.lan> <1114699593.5061.27.camel@ignacio.ignacio.lan> <0ML2Dk-1DRDb81Qoz-0002e8@mrelayeu.kundenserver.de> <1114729727.5061.34.camel@ignacio.ignacio.lan> <0ML25U-1DSJOO3PY8-0008Qk@mrelayeu.kundenserver.de> <1115135743.5462.3.camel@ignacio.ignacio.lan> Message-ID: On Tue, 03 May 2005 11:55:42 -0400, you wrote: >Yes, this is pretty much exactly what I was doing. I'd love to be able >to give you more diagnostics, but as I said all it gives is a mutilated >log entry. I'm going to look into the source to see what I can do about >this. It's possible to get your /etc/inadyn.conf file without your password? Best Regards: Jochen Schmitt From ivazquez at ivazquez.net Tue May 3 16:22:19 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 03 May 2005 12:22:19 -0400 Subject: Review Request: inadyn In-Reply-To: References: <0MKxQS-1DQo9k40Yz-00056x@mrelayeu.kundenserver.de> <1114614916.5061.12.camel@ignacio.ignacio.lan> <1114642372.5061.18.camel@ignacio.ignacio.lan> <1114699593.5061.27.camel@ignacio.ignacio.lan> <0ML2Dk-1DRDb81Qoz-0002e8@mrelayeu.kundenserver.de> <1114729727.5061.34.camel@ignacio.ignacio.lan> <0ML25U-1DSJOO3PY8-0008Qk@mrelayeu.kundenserver.de> <1115135743.5462.3.camel@ignacio.ignacio.lan> Message-ID: <1115137339.5462.5.camel@ignacio.ignacio.lan> On Tue, 2005-05-03 at 18:05 +0200, Jochen Schmitt wrote: > On Tue, 03 May 2005 11:55:42 -0400, you wrote: > > >Yes, this is pretty much exactly what I was doing. I'd love to be able > >to give you more diagnostics, but as I said all it gives is a mutilated > >log entry. I'm going to look into the source to see what I can do about > >this. > > It's possible to get your /etc/inadyn.conf file without your > password? username password alias ignacio-test.dnsalias.org update_period 60000 background verbose 5 syslog -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mricon at gmail.com Tue May 3 16:49:21 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Tue, 3 May 2005 12:49:21 -0400 Subject: New package: SCIM In-Reply-To: <427727FC.8040001@mbm.nifty.com> References: <427727FC.8040001@mbm.nifty.com> Message-ID: On 5/3/05, Ryo Dairiki wrote: > Hi, > I'm thinking of add the package of SCIM to fedora extras. > Could you review them and report me problems? > > You can get my packages from here: > http://sourceforge.net/projects/scim Hello, Ryo: Your packages are pretty good, but not exactly in the style of fedora extras. When I was working on creating SCIM packages for Fedora, before finding out that you're already working on them, I've created several packages where I have tried to adjust the specfile to be as close as possible to what is usually accepted by the extras community (i.e., so that Michael Schwendt has no more than 10-15 remarks to make :)). You may take a look at them here, if you are interested: http://phy.duke.edu/~icon/misc/fedora-extras/ I've only packages scim, scim-pinyin, and scim-tables, though. Thanks for your work on this! Regards, -- Konstantin Ryabitsev Zlotniks, INC From mpeters at mac.com Tue May 3 17:05:51 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 03 May 2005 10:05:51 -0700 Subject: Complicated post script Message-ID: <1115139951.2974.19.camel@fc4t2.mpeters.local> The package is tilp (software for linking Texas Instruments graphing calculators) I do not know if I want to submit this to extras or not, but I want my spec file to be "right" so that if I ever do (or someone else wants something to start with) it will be fine. Primary reason I may not want to submit to Extras is I have trouble getting it work at all as non root user with the SilverLink cable (same cable works in WinXP) and the serial cable, while it works as non root, often reports data corruption - and once it does, continues to do so until the next reboot (again, not an issue in WinXP), so until it actually _works_ consistently, it would never get passed my own QA let alone Extras. Supposedly the SVN version is better, so maybe with the next release ... Currently it does not build in rawhide (using gcc4 or gcc32) so I suspect that it has some issues with updated gtk2 stuff, it does compile in fc3. Anyway, the spec file needs to add some stuff to /usr/share/file/magic and if applicable - gnome and kde specific stuff. I have a feeling the best way to do it is through trigger scripts, I'm not sure on the proper way to remove them if the package is uninstalled - they may not need to be. This is what I have been doing in fc3 %post # update magic stuff from brokem Makefile MAGIC=%_datadir/file/magic GNOME_MAGIC=/etc/gnome-vfs-mime-magic KDE_MAGIC=/usr/share/mimelnk/magic if [ -f ${MAGIC} ]; then # see if it needs updating if ! grep "\*\*TI85\*\*" ${MAGIC}; then cat %_datadir/tilp/magic/magic >> ${MAGIC} fi fi if [ -f ${GNOME_MAGIC} ]; then # see if it needs updating if ! grep "\*\*TI" ${GNOME_MAGIC}; then cat %_datadir/tilp/magic/gnome-vfs-mime-magic >> ${GNOME_MAGIC} fi fi if [ -f ${KDE_MAGIC} ]; then # see if it needs updating if ! grep "\*\*TI85" /usr/share/mimelnk/magic; then cat %_datadir/tilp/magic/kde.magic >> ${KDE_MAGIC} fi fi update-desktop-database %{_datadir}/applications %postun update-desktop-database %{_datadir}/applications -=- The first if block should not be an if block, it should require %_datadir/file/magic. It does need to check though if it is already installed. The other two if blocks should not be required, they should be trigger scripts triggered by the packages that own the files being modified, correct? If I'm not mistaken - update-desktop-database needs to be done AFTER the gnome and kde specific mime stuff is updated, so would that need to be in each triggerin script, or is there a way to say "run this trigger script after any and all others"? I'm guessing the former, which means it would be run twice for users with both KDE and Gnome, not the end of the world I guess. Rather that cat-ing the mime stuff - is there a "proper" utility that will modify the mime files? That would seem to be a better way to do it, as it would allow the format of those files to potentially change. Am I even going about it the right way? Is this the appropriate list for these kinds of questions? I did not _see_ anything in the wiki about updating the mime stuff. From Jochen at herr-schmitt.de Tue May 3 17:12:22 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 03 May 2005 19:12:22 +0200 Subject: Review Request: inadyn In-Reply-To: <1115137339.5462.5.camel@ignacio.ignacio.lan> References: <1114642372.5061.18.camel@ignacio.ignacio.lan> <1114699593.5061.27.camel@ignacio.ignacio.lan> <0ML2Dk-1DRDb81Qoz-0002e8@mrelayeu.kundenserver.de> <1114729727.5061.34.camel@ignacio.ignacio.lan> <0ML25U-1DSJOO3PY8-0008Qk@mrelayeu.kundenserver.de> <1115135743.5462.3.camel@ignacio.ignacio.lan> <1115137339.5462.5.camel@ignacio.ignacio.lan> Message-ID: <0ML29c-1DT0wX2sZR-0000Kv@mrelayeu.kundenserver.de> On Tue, 03 May 2005 12:22:19 -0400, you wrote: >alias ignacio-test.dnsalias.org Thank your for your answer. I have make some tests. It's seem, that is something wrong with your hostname. When I make a ping, I get a error message, that the hostname is unknewn. When I start up a internet connection without calling inadyn, I don't get this kind of error message when I ping my own dynDSN hostname. instead I get a message, which complaints, that the sent IP packages are gone lost. So I must assume, that something with your registration of your hostname on dynDSN was going wrong. Best Regards: Jochen Schmitt From ivazquez at ivazquez.net Tue May 3 17:20:52 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 03 May 2005 13:20:52 -0400 Subject: Review Request: inadyn In-Reply-To: <0ML29c-1DT0wX2sZR-0000Kv@mrelayeu.kundenserver.de> References: <1114642372.5061.18.camel@ignacio.ignacio.lan> <1114699593.5061.27.camel@ignacio.ignacio.lan> <0ML2Dk-1DRDb81Qoz-0002e8@mrelayeu.kundenserver.de> <1114729727.5061.34.camel@ignacio.ignacio.lan> <0ML25U-1DSJOO3PY8-0008Qk@mrelayeu.kundenserver.de> <1115135743.5462.3.camel@ignacio.ignacio.lan> <1115137339.5462.5.camel@ignacio.ignacio.lan> <0ML29c-1DT0wX2sZR-0000Kv@mrelayeu.kundenserver.de> Message-ID: <1115140852.5462.10.camel@ignacio.ignacio.lan> On Tue, 2005-05-03 at 19:12 +0200, Jochen Schmitt wrote: > On Tue, 03 May 2005 12:22:19 -0400, you wrote: > >alias ignacio-test.dnsalias.org > So I must assume, that something with your registration of your > hostname on dynDSN was going wrong. *sigh* Yes, I took another look and saw that I had registered .com, not .org. My bad. I still don't like the lack of diagnostic messages in the log though. Approved, provided you add a note somewhere stating that the hostname has to be registered via the web interface initially and tell the upstream author to fix that diagnostic issue. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Jochen at herr-schmitt.de Tue May 3 17:36:33 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 03 May 2005 19:36:33 +0200 Subject: Review Request: inadyn In-Reply-To: <1115140852.5462.10.camel@ignacio.ignacio.lan> References: <1114699593.5061.27.camel@ignacio.ignacio.lan> <0ML2Dk-1DRDb81Qoz-0002e8@mrelayeu.kundenserver.de> <1114729727.5061.34.camel@ignacio.ignacio.lan> <0ML25U-1DSJOO3PY8-0008Qk@mrelayeu.kundenserver.de> <1115135743.5462.3.camel@ignacio.ignacio.lan> <1115137339.5462.5.camel@ignacio.ignacio.lan> <0ML29c-1DT0wX2sZR-0000Kv@mrelayeu.kundenserver.de> <1115140852.5462.10.camel@ignacio.ignacio.lan> Message-ID: On Tue, 03 May 2005 13:20:52 -0400, you wrote: >Approved, provided you add a note somewhere stating that the hostname >has to be registered via the web interface initially and tell the >upstream author to fix that diagnostic issue. I thought, it's normal, that you have to registered the hostname via the web interface at the first time. Best Regards: Jochen Schmitt From Jochen at herr-schmitt.de Tue May 3 18:04:02 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 03 May 2005 20:04:02 +0200 Subject: Review Request: inadyn In-Reply-To: <1115140852.5462.10.camel@ignacio.ignacio.lan> References: <1114699593.5061.27.camel@ignacio.ignacio.lan> <0ML2Dk-1DRDb81Qoz-0002e8@mrelayeu.kundenserver.de> <1114729727.5061.34.camel@ignacio.ignacio.lan> <0ML25U-1DSJOO3PY8-0008Qk@mrelayeu.kundenserver.de> <1115135743.5462.3.camel@ignacio.ignacio.lan> <1115137339.5462.5.camel@ignacio.ignacio.lan> <0ML29c-1DT0wX2sZR-0000Kv@mrelayeu.kundenserver.de> <1115140852.5462.10.camel@ignacio.ignacio.lan> Message-ID: <0MKxQS-1DT1kW1AQP-0004tt@mrelayeu.kundenserver.de> On Tue, 03 May 2005 13:20:52 -0400, you wrote: >Approved, provided you add a note somewhere stating that the hostname >has to be registered via the web interface initially and tell the >upstream author to fix that diagnostic issue. I have add a short note to the package which explains, that you have to register the hostname via the web interface at the first time. It will be nice, if you can take a look to this file to avoids typos and so on. Best Regards: Jochen Schmitt From ville.skytta at iki.fi Tue May 3 18:22:10 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 03 May 2005 21:22:10 +0300 Subject: Complicated post script In-Reply-To: <1115139951.2974.19.camel@fc4t2.mpeters.local> References: <1115139951.2974.19.camel@fc4t2.mpeters.local> Message-ID: <1115144530.16399.33.camel@bobcat.mine.nu> On Tue, 2005-05-03 at 10:05 -0700, Michael A. Peters wrote: > Anyway, the spec file needs to add some stuff to /usr/share/file/magic That will break "rpm -V" of the file package. Doesn't /etc/magic work? Modifying that instead of the /usr/share one would sound better, but even better than that would be an /etc/magic.d or somesuch dir where packages could just drop their additions in. RFE in Bugzilla if such a thing doesn't yet exist? > Is this the appropriate list for these kinds of questions? The fedora-packaging list might be more appropriate, but people here probably don't mind. From perbj at stanford.edu Tue May 3 18:37:50 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Tue, 03 May 2005 11:37:50 -0700 Subject: Complicated post script In-Reply-To: <1115144530.16399.33.camel@bobcat.mine.nu> References: <1115139951.2974.19.camel@fc4t2.mpeters.local> <1115144530.16399.33.camel@bobcat.mine.nu> Message-ID: <1115145470.4779.26.camel@localhost.localdomain> On Tue, 2005-05-03 at 21:22 +0300, Ville Skytt? wrote: > On Tue, 2005-05-03 at 10:05 -0700, Michael A. Peters wrote: > > > Anyway, the spec file needs to add some stuff to /usr/share/file/magic > > That will break "rpm -V" of the file package. Doesn't /etc/magic work? > Modifying that instead of the /usr/share one would sound better, but > even better than that would be an /etc/magic.d or somesuch dir where > packages could just drop their additions in. RFE in Bugzilla if such a > thing doesn't yet exist? Well, it seems that the free desktop is moving toward the Freedesktop shared-mime-info spec (Gnome implements it since a while back, I don't think that KDE does yet though?): http://www.freedesktop.org/wiki/Standards_2fshared_2dmime_2dinfo_2dspec I guess 'file' won't actually pick this up though... but if the intent is to make the file type useful in the desktop environment this should be the way to go. If I read this correctly, it seems that the directory /usr/share/mime/packages is the place to drop a specification file in the shared-mime-spec XML format, then run update-mime-database. Then there should be a hint in the .desktop file that a program can handle a certain MIME type, which is registered by running update- desktop-database. I guess KDE still needs the old way of doing it though. /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From ivazquez at ivazquez.net Tue May 3 18:54:14 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 03 May 2005 14:54:14 -0400 Subject: Review Request: inadyn In-Reply-To: <0MKxQS-1DT1kW1AQP-0004tt@mrelayeu.kundenserver.de> References: <1114699593.5061.27.camel@ignacio.ignacio.lan> <0ML2Dk-1DRDb81Qoz-0002e8@mrelayeu.kundenserver.de> <1114729727.5061.34.camel@ignacio.ignacio.lan> <0ML25U-1DSJOO3PY8-0008Qk@mrelayeu.kundenserver.de> <1115135743.5462.3.camel@ignacio.ignacio.lan> <1115137339.5462.5.camel@ignacio.ignacio.lan> <0ML29c-1DT0wX2sZR-0000Kv@mrelayeu.kundenserver.de> <1115140852.5462.10.camel@ignacio.ignacio.lan> <0MKxQS-1DT1kW1AQP-0004tt@mrelayeu.kundenserver.de> Message-ID: <1115146454.5462.17.camel@ignacio.ignacio.lan> On Tue, 2005-05-03 at 20:04 +0200, Jochen Schmitt wrote: > On Tue, 03 May 2005 13:20:52 -0400, you wrote: > > >Approved, provided you add a note somewhere stating that the hostname > >has to be registered via the web interface initially and tell the > >upstream author to fix that diagnostic issue. > > I have add a short note to the package which explains, that you > have to register the hostname via the web interface at the first > time. > > It will be nice, if you can take a look to this file to avoids > typos and so on. How about the following: "Before using inadyn for the first time you must use the DynDNS provider's web interface to create the entry for the hostname. You should then fill in /etc/inadyn.conf with the appropriate details." Also, I'm thinking that this can fit right into %description instead of being a separate file. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Jochen at herr-schmitt.de Tue May 3 19:59:27 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 03 May 2005 21:59:27 +0200 Subject: Review Request: inadyn In-Reply-To: <1115146454.5462.17.camel@ignacio.ignacio.lan> References: <1114729727.5061.34.camel@ignacio.ignacio.lan> <0ML25U-1DSJOO3PY8-0008Qk@mrelayeu.kundenserver.de> <1115135743.5462.3.camel@ignacio.ignacio.lan> <1115137339.5462.5.camel@ignacio.ignacio.lan> <0ML29c-1DT0wX2sZR-0000Kv@mrelayeu.kundenserver.de> <1115140852.5462.10.camel@ignacio.ignacio.lan> <0MKxQS-1DT1kW1AQP-0004tt@mrelayeu.kundenserver.de> <1115146454.5462.17.camel@ignacio.ignacio.lan> Message-ID: <0MKwh2-1DT3YG12PC-0002Ge@mrelayeu.kundenserver.de> On Tue, 03 May 2005 14:54:14 -0400, you wrote: >How about the following: > >"Before using inadyn for the first time you must use the DynDNS >provider's web interface to create the entry for the hostname. You >should then fill in /etc/inadyn.conf with the appropriate details." > >Also, I'm thinking that this can fit right into %description instead of >being a separate file. It's sounds good. I have intergrate it in the SPEC file and checked in. Best Regards: Jochen Schmitt From tian at c-sait.net Tue May 3 20:09:37 2005 From: tian at c-sait.net (Tian) Date: Tue, 3 May 2005 22:09:37 +0200 Subject: Self-Introduction: Christian Jodar (Tian) Message-ID: <20050503220937.4df887c2@tianbox> Hello, I think I was a bit confused with the user creation and sponsoring process. So maybe I should have introduce myself before my review request. Here it is. My full name is Christian Jodar, but I use Tian nickname on the web. I am from south of France, near Cannes in the French Riviera. I work as a computer engineer doing some developments for Unix servers. They are done using C++ and Oracle database. The company I work for is Amadeus, a company providing software for airlines and travel agencies. I'd like to contribute in the project by becoming in the first time maintainer of GCfilms package, a project I am responsible of ( https://gna.org/projects/gcfilms/ ). I am webmaster of "Site d'Aide Informatique de Tian" ( http://www.c-sait.net/ ) a french website containing articles about computers and GNU/Linux. It also includes a toolbox with shell script, PHP sources, and other stuff I wrote. Previous works also include a C++ API for LCDProc ( http://www.c-sait.net/lcdapi/ ), some SuperKaramba plugins (Karmix and KarDevices) and a toolbar for Firefox and Mozilla, CPCMozBar, for a french website and forum. I am also maintainer of the french translation of the Orca Forum and Blog ( http://www.greywyvern.com/orca ). It has been 6 years since I am using GNU/Linux systems: Red Hat and SUSE ones first. And now Fedora core since its second version. My Gna! profile contains a summary of my technical skills: https://gna.org/people/viewprofile.php?user_id=2226 I also added the .src.rpm for GCfilms package. It can be found here: http://download.gna.org/gcfilms/fedora/3/gcfilms-5.0-1.src.rpm Thanks a lot for your attention. Please let me know if another action or information are required from me. Here is my GPG KEYID and fingerprint (already uploaded to pgp.mit.edu) > gpg --fingerprint BF2FB628 pub 1024D/BF2FB628 2005-05-02 Christian Jodar (Tian) Key fingerprint = 113D 3265 D3C6 94A1 2E7D CC14 7A57 B9F0 BF2F B628 sub 1024g/B1AF1AF4 2005-05-02 Tian. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Tue May 3 20:50:13 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 03 May 2005 23:50:13 +0300 Subject: Complicated post script In-Reply-To: <1115145470.4779.26.camel@localhost.localdomain> References: <1115139951.2974.19.camel@fc4t2.mpeters.local> <1115144530.16399.33.camel@bobcat.mine.nu> <1115145470.4779.26.camel@localhost.localdomain> Message-ID: <1115153413.16399.158.camel@bobcat.mine.nu> On Tue, 2005-05-03 at 11:37 -0700, Per Bjornsson wrote: > Well, it seems that the free desktop is moving toward the Freedesktop > shared-mime-info spec (Gnome implements it since a while back, I don't > think that KDE does yet though?): > http://www.freedesktop.org/wiki/Standards_2fshared_2dmime_2dinfo_2dspec Right, thanks. Forgot that this stuff isn't limited to examining filenames. From chrisw at osdl.org Tue May 3 23:29:39 2005 From: chrisw at osdl.org (Chris Wright) Date: Tue, 3 May 2005 16:29:39 -0700 Subject: New package: cogito Message-ID: <20050503232939.GZ18917@shell0.pdx.osdl.net> Here's a proposal to add the cogito package. Cogito is both the lowlevel backend storage provided by Git, as well as the frontend usable as an SCM. I don't know of any issues with the package. I don't have Fedora Extras CVS access, so need a sponsor for that. Description (from spec file): GIT comes in two layers. The bottom layer is merely an extremely fast and flexible filesystem-based database designed to store directory trees with regard to their history. The top layer is a SCM-like tool which enables human beings to work with the database in a manner to a degree similar to other SCM tools (like CVS, BitKeeper or Monotone). A .src.rpm is available here: http://www.kernel.org/pub/software/scm/cogito/RPMS/cogito-0.8-2.src.rpm And the spec file is here: http://www.kernel.org/pub/software/scm/cogito/RPMS/git.spec thanks, -chris From davej at redhat.com Tue May 3 23:35:18 2005 From: davej at redhat.com (Dave Jones) Date: Tue, 3 May 2005 19:35:18 -0400 Subject: New package: cogito In-Reply-To: <20050503232939.GZ18917@shell0.pdx.osdl.net> References: <20050503232939.GZ18917@shell0.pdx.osdl.net> Message-ID: <20050503233517.GA17380@redhat.com> On Tue, May 03, 2005 at 04:29:39PM -0700, Chris Wright wrote: > Here's a proposal to add the cogito package. Cogito is both the lowlevel > backend storage provided by Git, as well as the frontend usable as an SCM. > I don't know of any issues with the package. I don't have Fedora Extras > CVS access, so need a sponsor for that. > > Description (from spec file): > > GIT comes in two layers. The bottom layer is merely an extremely fast > and flexible filesystem-based database designed to store directory trees > with regard to their history. The top layer is a SCM-like tool which > enables human beings to work with the database in a manner to a degree > similar to other SCM tools (like CVS, BitKeeper or Monotone). Hey Chris, I was pondering packaging up git myself too, but held off for one reason. Right now, Linus has the perogative to say "oh shit, this is wrong" and redesign the meta-data to work around whatever comes up, and the only projects really affected are his own (and subsequent clones). If we package up git now, and people started using it to host their own projects, what happens when the next release of git won't read their old repositories ? I'd be tempted to sit things out a bit longer before its added, even to extras, until its got a few more battle-scars. Dave From jwboyer at jdub.homelinux.org Wed May 4 01:28:15 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 03 May 2005 20:28:15 -0500 Subject: New package: cogito In-Reply-To: <20050503233517.GA17380@redhat.com> References: <20050503232939.GZ18917@shell0.pdx.osdl.net> <20050503233517.GA17380@redhat.com> Message-ID: <1115170095.27280.25.camel@jdub.homelinux.org> On Tue, 2005-05-03 at 19:35 -0400, Dave Jones wrote: > On Tue, May 03, 2005 at 04:29:39PM -0700, Chris Wright wrote: > > Here's a proposal to add the cogito package. Cogito is both the lowlevel > > backend storage provided by Git, as well as the frontend usable as an SCM. > > I don't know of any issues with the package. I don't have Fedora Extras > > CVS access, so need a sponsor for that. > > > > Description (from spec file): > > > > GIT comes in two layers. The bottom layer is merely an extremely fast > > and flexible filesystem-based database designed to store directory trees > > with regard to their history. The top layer is a SCM-like tool which > > enables human beings to work with the database in a manner to a degree > > similar to other SCM tools (like CVS, BitKeeper or Monotone). > > Hey Chris, > I was pondering packaging up git myself too, but held off for one reason. > Right now, Linus has the perogative to say "oh shit, this is wrong" > and redesign the meta-data to work around whatever comes up, and > the only projects really affected are his own (and subsequent clones). > > If we package up git now, and people started using it to host their > own projects, what happens when the next release of git won't read > their old repositories ? > > I'd be tempted to sit things out a bit longer before its added, > even to extras, until its got a few more battle-scars. Yep, I agree. I have also been playing around with packaging cogito, but I've held off trying to submit anything until it stabilizes a bit. josh From byte at aeon.com.my Wed May 4 01:43:42 2005 From: byte at aeon.com.my (Colin Charles) Date: Wed, 04 May 2005 11:43:42 +1000 Subject: Fortune Program -Moving->RE: Wanda is broken In-Reply-To: <1114271548.6273.36.camel@laptopd505.fenrus.org> References: <1114271548.6273.36.camel@laptopd505.fenrus.org> Message-ID: <1115171022.14607.11.camel@arena.soho.bytebot.net> On Sat, 2005-04-23 at 17:52 +0200, Arjan van de Ven wrote: > historic reasons; some of the fortune quotes were not seen as > politically correct or even offensive for some users/customers, and > people somehow get really upset by that. (Remember the treads about > that > screen saver that made shapes that someone "recognized" as being one > of > his body parts; things like this get people really upset and thus the > alternative to not shipping fortune is shipping it but vetting every > single fortune text as seen from several different cultures) Actually, with xscreensaver, we patch out webcollage (and possibly others). This would be an ideal package to sit in Extras or something to provide for it -- Colin Charles, http://www.bytebot.net/ From jwboyer at jdub.homelinux.org Wed May 4 01:50:47 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 03 May 2005 20:50:47 -0500 Subject: make tag and %{?dist} Message-ID: <1115171447.27280.38.camel@jdub.homelinux.org> Hi, I'm trying to figure out how the %{dist} macro is supposed to work with the 'make tag' command in CVS. According to http://www.fedoraproject.org/wiki/DistTag one can append %{?dist} to the Release field in the spec file and it will be expanded to the correct value when the package is built by the build system. However, unless the spec file contains something like: %define dist .fc4 the 'make tag' command will not pick up the dist tag part of the Release field because it is not defined. Where that becomes a problem is if a package is essentially the same for both FC3 and FC4. Since the dist tag isn't expanded, a 'make tag' will result in the same tag for both branches, and that isn't allowed. So, is it valid to "hardcode" %{dist} as above? If so, what's the point of even using %{?dist}, since you could just hard code the .fc4 into the Release field? Hopefully I'm just confused. Any pointers would be appreciated. thx, josh From mattdm at mattdm.org Wed May 4 01:57:11 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 3 May 2005 21:57:11 -0400 Subject: make tag and %{?dist} In-Reply-To: <1115171447.27280.38.camel@jdub.homelinux.org> References: <1115171447.27280.38.camel@jdub.homelinux.org> Message-ID: <20050504015711.GA17402@jadzia.bu.edu> On Tue, May 03, 2005 at 08:50:47PM -0500, Josh Boyer wrote: > According to http://www.fedoraproject.org/wiki/DistTag one can append > %{?dist} to the Release field in the spec file and it will be expanded > to the correct value when the package is built by the build system. > However, unless the spec file contains something like: > %define dist .fc4 Presumably, the build system defines this so it doesn't have to be in the spec files. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From ivazquez at ivazquez.net Wed May 4 02:00:43 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 03 May 2005 22:00:43 -0400 Subject: make tag and %{?dist} In-Reply-To: <1115171447.27280.38.camel@jdub.homelinux.org> References: <1115171447.27280.38.camel@jdub.homelinux.org> Message-ID: <1115172043.5462.20.camel@ignacio.ignacio.lan> On Tue, 2005-05-03 at 20:50 -0500, Josh Boyer wrote: > Hi, > > I'm trying to figure out how the %{dist} macro is supposed to work with > the 'make tag' command in CVS. > > According to http://www.fedoraproject.org/wiki/DistTag one can append > %{?dist} to the Release field in the spec file and it will be expanded > to the correct value when the package is built by the build system. > > However, unless the spec file contains something like: > > %define dist .fc4 > > the 'make tag' command will not pick up the dist tag part of the Release > field because it is not defined. > > Where that becomes a problem is if a package is essentially the same for > both FC3 and FC4. Since the dist tag isn't expanded, a 'make tag' will > result in the same tag for both branches, and that isn't allowed. > > So, is it valid to "hardcode" %{dist} as above? If so, what's the point > of even using %{?dist}, since you could just hard code the .fc4 into the > Release field? > > Hopefully I'm just confused. Any pointers would be appreciated. You need the "scary macro voodoo" that the wiki article talks about if you want to do it on your machine. http://fedora.ivazquez.net/files/macros.disttag Although I'm not sure if it's actually used in the Extras build system. If not then there's no point to the 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 jwboyer at jdub.homelinux.org Wed May 4 02:04:21 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 03 May 2005 21:04:21 -0500 Subject: make tag and %{?dist} In-Reply-To: <20050504015711.GA17402@jadzia.bu.edu> References: <1115171447.27280.38.camel@jdub.homelinux.org> <20050504015711.GA17402@jadzia.bu.edu> Message-ID: <1115172261.27280.45.camel@jdub.homelinux.org> On Tue, 2005-05-03 at 21:57 -0400, Matthew Miller wrote: > On Tue, May 03, 2005 at 08:50:47PM -0500, Josh Boyer wrote: > > According to http://www.fedoraproject.org/wiki/DistTag one can append > > %{?dist} to the Release field in the spec file and it will be expanded > > to the correct value when the package is built by the build system. > > However, unless the spec file contains something like: > > %define dist .fc4 > > Presumably, the build system defines this so it doesn't have to be in the > spec files. Yes, I know that. That's not my problem. My problem is that it's _not_ defined on non-build system machines or in the magic CVS make targets. So if I have something like this: Name: foo Version: 1.0 Release: 1%{?dist} in my spec file for both the devel and FC3 branches, the 'make tag' command creates a tag that looks like this: foo_1.0_1 since %{dist} is undefined. That is bad because that means I need to manually go modify the spec file to have a different Release field since the same tag can't be used in two different branches. josh From jwboyer at jdub.homelinux.org Wed May 4 02:28:03 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 03 May 2005 21:28:03 -0500 Subject: make tag and %{?dist} In-Reply-To: <1115172043.5462.20.camel@ignacio.ignacio.lan> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> Message-ID: <1115173684.27280.55.camel@jdub.homelinux.org> On Tue, 2005-05-03 at 22:00 -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2005-05-03 at 20:50 -0500, Josh Boyer wrote: > > > > So, is it valid to "hardcode" %{dist} as above? If so, what's the point > > of even using %{?dist}, since you could just hard code the .fc4 into the > > Release field? > > > > Hopefully I'm just confused. Any pointers would be appreciated. > > You need the "scary macro voodoo" that the wiki article talks about if > you want to do it on your machine. Yeah, but that "scary macro voodoo" is something I want to avoid, and it doesn't really solve the problem. That would just define %{dist} to whatever version of the distro the user had installed at the time. Here is more of what I was thinking: Perhaps the make targets in CVS could define %{dist} for the user based on what branch the command is being run. For example, if you run 'make i386' in the devel branch %{dist} gets defined to ".fc4" automatically. Similarly, if you run it in the FC-3 branch, it gets defined to ".fc3". That would allow packagers to build RPMs and get the benefits of %{dist} without having to hardcode it for each spec file in each CVS branch. It would also solve my current problem, since 'make tag' would do the Right Thing when it came to the %{dist} macro. In an IRC conversation, Ignacio suggested a data file in the common subdir that could have CVS branch -> dist tag mappings. This seems fairly simple to me. Thoughts? josh From jdennis at redhat.com Wed May 4 02:45:12 2005 From: jdennis at redhat.com (John Dennis) Date: Tue, 03 May 2005 22:45:12 -0400 Subject: make tag and %{?dist} In-Reply-To: <20050504015711.GA17402@jadzia.bu.edu> References: <1115171447.27280.38.camel@jdub.homelinux.org> <20050504015711.GA17402@jadzia.bu.edu> Message-ID: <1115174712.26495.8.camel@localhost.localdomain> On Tue, 2005-05-03 at 21:57 -0400, Matthew Miller wrote: > On Tue, May 03, 2005 at 08:50:47PM -0500, Josh Boyer wrote: > > According to http://www.fedoraproject.org/wiki/DistTag one can append > > %{?dist} to the Release field in the spec file and it will be expanded > > to the correct value when the package is built by the build system. > > However, unless the spec file contains something like: > > %define dist .fc4 > > Presumably, the build system defines this so it doesn't have to be in the > spec files. One would hope so, but it doesn't. One would think the build system could bump the release number too, but it doesn't. It's still a manual error prone process dependent on spec file editing, CVS commits, and make tags. The good news is the build system won't accept duplicates. Caveat: My comments refer to the core build system, I believe Seth is working on a build system for extras and perhaps he has addressed this issue. However, it would be a shame if the core build system and the extras build system were divergent in such a fundamental way. -- John Dennis From mattdm at mattdm.org Wed May 4 02:48:46 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 3 May 2005 22:48:46 -0400 Subject: make tag and %{?dist} In-Reply-To: <1115173684.27280.55.camel@jdub.homelinux.org> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> Message-ID: <20050504024846.GA19087@jadzia.bu.edu> On Tue, May 03, 2005 at 09:28:03PM -0500, Josh Boyer wrote: > Yeah, but that "scary macro voodoo" is something I want to avoid, and it > doesn't really solve the problem. That would just define %{dist} to > whatever version of the distro the user had installed at the time. Right.... what's wrong with that? In fact, isn't it the point? > Perhaps the make targets in CVS could define %{dist} for the user based > on what branch the command is being run. For example, if you run 'make > i386' in the devel branch %{dist} gets defined to ".fc4" automatically. > Similarly, if you run it in the FC-3 branch, it gets defined to ".fc3". So that way, when you accidentally build the package from the wrong branch, it gets tagged with with the wrong tag for the build, and if you don't notice, your final file gets copied to the wrong place? If your spec files are actually different across distro releases, I don't think you wanna be using dist tags -- in that case, you hard-code it because functional differences in the file effectively hard-code a distinction anyway. The dist tag provides a way so that it doesn't *matter* where you happen to get the spec file from (since it's identical) and your package is still built and clearly labelled as belonging on the release on which you built it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From jwboyer at jdub.homelinux.org Wed May 4 03:13:56 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 03 May 2005 22:13:56 -0500 Subject: make tag and %{?dist} In-Reply-To: <20050504024846.GA19087@jadzia.bu.edu> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> <20050504024846.GA19087@jadzia.bu.edu> Message-ID: <1115176436.27280.69.camel@jdub.homelinux.org> On Tue, 2005-05-03 at 22:48 -0400, Matthew Miller wrote: > On Tue, May 03, 2005 at 09:28:03PM -0500, Josh Boyer wrote: > > Yeah, but that "scary macro voodoo" is something I want to avoid, and it > > doesn't really solve the problem. That would just define %{dist} to > > whatever version of the distro the user had installed at the time. > > Right.... what's wrong with that? In fact, isn't it the point? No, that's exactly what I'm trying to avoid. > > > Perhaps the make targets in CVS could define %{dist} for the user based > > on what branch the command is being run. For example, if you run 'make > > i386' in the devel branch %{dist} gets defined to ".fc4" automatically. > > Similarly, if you run it in the FC-3 branch, it gets defined to ".fc3". > > So that way, when you accidentally build the package from the wrong branch, > it gets tagged with with the wrong tag for the build, and if you don't > notice, your final file gets copied to the wrong place? What final file? The RPM? I'm talking about making things easier for the packagers here. If users are building their own packages from the stuff in CVS rather than downloading the officially built RPMs, they should know what they are doing already. > > If your spec files are actually different across distro releases, I don't > think you wanna be using dist tags -- in that case, you hard-code it because > functional differences in the file effectively hard-code a distinction > anyway. But my spec files are _not_ different except for the fact that the CVS and build systems require them to have a different Release field for each distro. Which is what %{dist} theoretically could be used for if it was actually defined. Have you actually tried to use the same spec file in both the devel and FC-3 branches and get a package built? It doesn't work because you have to run 'make tag' first which creates a CVS tag based on the Name, Version, and Release fields in the spec file. When you use the same spec file for both branches, 'make tag' fails in the second branch because the same CVS tag can't be in multiple branches. With what I'm proposing, 'make tag' would expand %{dist} based on the CVS branch it was run in, and the CVS tags would be different. Now you can use the exact same spec file for both branches (assuming there are no functional differences), and builds can still occur. Problem solved. > > The dist tag provides a way so that it doesn't *matter* where you happen to > get the spec file from (since it's identical) and your package is still > built and clearly labelled as belonging on the release on which you built > it. > Exactly. So if I am in the devel branch of Extras CVS, I better damn well realize that any package built from there would have .fc4 in the Release section of the RPM. I think we are missing one another's points. josh From mattdm at mattdm.org Wed May 4 03:22:16 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 3 May 2005 23:22:16 -0400 Subject: make tag and %{?dist} In-Reply-To: <1115176436.27280.69.camel@jdub.homelinux.org> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> Message-ID: <20050504032216.GA20031@jadzia.bu.edu> On Tue, May 03, 2005 at 10:13:56PM -0500, Josh Boyer wrote: > > So that way, when you accidentally build the package from the wrong branch, > > it gets tagged with with the wrong tag for the build, and if you don't > > notice, your final file gets copied to the wrong place? > What final file? The RPM? Yeah. [...] > But my spec files are _not_ different except for the fact that the CVS > and build systems require them to have a different Release field for > each distro. Which is what %{dist} theoretically could be used for if > it was actually defined. Agreed.... > Have you actually tried to use the same spec file in both the devel and > FC-3 branches and get a package built? It doesn't work because you have > to run 'make tag' first which creates a CVS tag based on the Name, > Version, and Release fields in the spec file. When you use the same > spec file for both branches, 'make tag' fails in the second branch > because the same CVS tag can't be in multiple branches. I haven't yet, but I do use a similar system for our different releases at BU. > With what I'm proposing, 'make tag' would expand %{dist} based on the > CVS branch it was run in, and the CVS tags would be different. Now you > can use the exact same spec file for both branches (assuming there are > no functional differences), and builds can still occur. Problem > solved. Okay, maybe I'm confused now. I don't understand why you would tie this to the (somewhat arbitrary and external) CVS branch rather than to the direct connection -- what release the system you build the package on is running. > Exactly. So if I am in the devel branch of Extras CVS, I better damn > well realize that any package built from there would have .fc4 in the > Release section of the RPM. Ideally, if it's a spec file that can be built on multiple releases, you shouldn't have to realize anything.... it'd just always do the right thing, no matter where you got the spec file from. > I think we are missing one another's points. Maybe. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From ivazquez at ivazquez.net Wed May 4 03:39:44 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 03 May 2005 23:39:44 -0400 Subject: make tag and %{?dist} In-Reply-To: <20050504032216.GA20031@jadzia.bu.edu> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> Message-ID: <1115177984.5462.23.camel@ignacio.ignacio.lan> On Tue, 2005-05-03 at 23:22 -0400, Matthew Miller wrote: > On Tue, May 03, 2005 at 10:13:56PM -0500, Josh Boyer wrote: > > With what I'm proposing, 'make tag' would expand %{dist} based on the > > CVS branch it was run in, and the CVS tags would be different. Now you > > can use the exact same spec file for both branches (assuming there are > > no functional differences), and builds can still occur. Problem > > solved. > > Okay, maybe I'm confused now. I don't understand why you would tie this to > the (somewhat arbitrary and external) CVS branch rather than to the direct > connection -- what release the system you build the package on is running. Running 'make tag' in a branch should theoretically create a tag appropriate for the branch regardless of what actual version is being used. This is why you have the make system fill in %dist appropriately and then use it in the spec file. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Wed May 4 03:51:20 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 03 May 2005 22:51:20 -0500 Subject: make tag and %{?dist} In-Reply-To: <20050504032216.GA20031@jadzia.bu.edu> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> Message-ID: <1115178680.27280.91.camel@jdub.homelinux.org> On Tue, 2005-05-03 at 23:22 -0400, Matthew Miller wrote: > > With what I'm proposing, 'make tag' would expand %{dist} based on the > > CVS branch it was run in, and the CVS tags would be different. Now you > > can use the exact same spec file for both branches (assuming there are > > no functional differences), and builds can still occur. Problem > > solved. > > Okay, maybe I'm confused now. I don't understand why you would tie this to > the (somewhat arbitrary and external) CVS branch rather than to the direct > connection -- what release the system you build the package on is running. For the actual RPM build, on the actual Red Hat build systems, this is how it would be/is done. That is where the "scary macro voodoo" that Ignacio mentioned in another thread comes into play. But, the process to get a package actually built on the Red Hat build systems from Fedora Extras CVS requires the spec file, sources file, patches, etc. to be tagged with a CVS tag. That is how the build system knows what to build when a build request is made on http://www.fedoraproject.org/wiki/Extras_2fFC4Status See, http://www.fedoraproject.org/wiki/Extras_2fUsingCvsFaq down in the Hints section for where this is pointed out. > > Exactly. So if I am in the devel branch of Extras CVS, I better damn > > well realize that any package built from there would have .fc4 in the > > Release section of the RPM. > > Ideally, if it's a spec file that can be built on multiple releases, you > shouldn't have to realize anything.... it'd just always do the right thing, > no matter where you got the spec file from. I don't disagree with that for spec files in general. But when one is using Extras CVS, I don't think the expectation of building in the correct directory (e.g. FC-3, FC-2, devel, etc) is too much. So with what I'm proposing, packagers wouldn't need to hard code a "%define dist .fcX" in their spec files. They could simply use %{dist} and the Red Hat build system will define it depending on which distro it's being built for. And for users that want to build everything themselves instead of getting the RPMs from the Fedora servers, they would simply need to choose the correct directory in their CVS checkout. > > > I think we are missing one another's points. > > Maybe. :) It's late here and I'm tired. Before I start rambling on incoherently, I think I'll head to bed. But I'll be back in the morning ;). josh From ivazquez at ivazquez.net Wed May 4 04:20:32 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 04 May 2005 00:20:32 -0400 Subject: Review Request: inadyn In-Reply-To: <0MKwh2-1DT3YG12PC-0002Ge@mrelayeu.kundenserver.de> References: <1114729727.5061.34.camel@ignacio.ignacio.lan> <0ML25U-1DSJOO3PY8-0008Qk@mrelayeu.kundenserver.de> <1115135743.5462.3.camel@ignacio.ignacio.lan> <1115137339.5462.5.camel@ignacio.ignacio.lan> <0ML29c-1DT0wX2sZR-0000Kv@mrelayeu.kundenserver.de> <1115140852.5462.10.camel@ignacio.ignacio.lan> <0MKxQS-1DT1kW1AQP-0004tt@mrelayeu.kundenserver.de> <1115146454.5462.17.camel@ignacio.ignacio.lan> <0MKwh2-1DT3YG12PC-0002Ge@mrelayeu.kundenserver.de> Message-ID: <1115180432.5462.27.camel@ignacio.ignacio.lan> On Tue, 2005-05-03 at 21:59 +0200, Jochen Schmitt wrote: > It's sounds good. I have intergrate it in the SPEC file and > checked in. Good stuff. Don't forget to take the changes to the devel branch and apply it to the FC-3 branch. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Wed May 4 04:40:58 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 04 May 2005 00:40:58 -0400 Subject: buildsystem stuff Message-ID: <1115181658.15831.45.camel@cutter> Hey folks, I've been doing a lot of tests today and I have some good news to report. 1. the xml-rpc communication is working pretty well. We can spawn builds out to different hosts than the queuer and get feedback on what broke in the build and/or why. 2. I've cleaned up the code and on my set of 2 systems (x86_64 and ppc) I can build for all 3 architectures w/o having to manually run anything. You can see the code here: http://linux.duke.edu/~skvidal/misc/buildsys/ Gist of how it is used: The queuer runs, figures out what needs to be built by getting the list from the /cvs/extras/common/tobuild file. It preps for the build by: - checking out the tag from cvs - making all the necessary dirs (name/v-r/a) - making the srpm Then it dispatches the build to the right archwelder classes. These classes build the packages and put the files into the right places if they succeed; or output the logs if they fail. After the build runs the queuer will notify the person requesting the build of success or failure. In the event of a failure on any one architecture the other builds are stopped and logs are reported. That's the short version of how it works - a list of todos are at the top of the two important files. I've got a few more tests to do and then I'll probably make the 'tobuild' file open to anyone with cvs commit access so you can run 'make build' to request your own builds. let me know what you think, even if I've wasted my time. -sv From daniel-wittenberg at starken.com Wed May 4 04:42:12 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Tue, 03 May 2005 23:42:12 -0500 Subject: Review request: snort Message-ID: <1115181733.12189.27.camel@plasma.starken.com> Yeah it's that time again...we've been busy getting the snort.spec updated for the new 2.4 release and wanted to run it by you guys to see how far off you think this one is. There is still some debates going on within the snort/sf teams about what to do with rules/signatures, so far now we're planning the old way until something is pinned down. http://www.starken.com/snort/snort.spec Dan From skvidal at phy.duke.edu Wed May 4 04:58:13 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 04 May 2005 00:58:13 -0400 Subject: make tag and %{?dist} In-Reply-To: <1115174712.26495.8.camel@localhost.localdomain> References: <1115171447.27280.38.camel@jdub.homelinux.org> <20050504015711.GA17402@jadzia.bu.edu> <1115174712.26495.8.camel@localhost.localdomain> Message-ID: <1115182693.15831.48.camel@cutter> > One would hope so, but it doesn't. One would think the build system > could bump the release number too, but it doesn't. It's still a manual > error prone process dependent on spec file editing, CVS commits, and > make tags. The good news is the build system won't accept duplicates. > > Caveat: My comments refer to the core build system, I believe Seth is > working on a build system for extras and perhaps he has addressed this > issue. However, it would be a shame if the core build system and the > extras build system were divergent in such a fundamental way. No, the things I'm working on do not provide such functionality. And if you want the core and extras buildsystems to not be divergent then you can take the following actions: 1. release the beehive code 2. have people who have seen what it is that beehive does work on the buildsystem code for fedora extras 3. get more people to give a shit. -sv From ivazquez at ivazquez.net Wed May 4 05:05:10 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 04 May 2005 01:05:10 -0400 Subject: Review request: snort In-Reply-To: <1115181733.12189.27.camel@plasma.starken.com> References: <1115181733.12189.27.camel@plasma.starken.com> Message-ID: <1115183110.5462.30.camel@ignacio.ignacio.lan> On Tue, 2005-05-03 at 23:42 -0500, Daniel Wittenberg wrote: > Yeah it's that time again...we've been busy getting the snort.spec > updated for the new 2.4 release and wanted to run it by you guys to see > how far off you think this one is. > > There is still some debates going on within the snort/sf teams about > what to do with rules/signatures, so far now we're planning the old way > until something is pinned down. > > http://www.starken.com/snort/snort.spec initDir should possibly be /etc/rc.d/init.d, and Fedora already defines %_initrddir for that. Also, /etc is in %_sysconfdir. -- 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 daniel-wittenberg at starken.com Wed May 4 05:16:56 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Wed, 04 May 2005 00:16:56 -0500 Subject: Review request: snort In-Reply-To: <1115183110.5462.30.camel@ignacio.ignacio.lan> References: <1115181733.12189.27.camel@plasma.starken.com> <1115183110.5462.30.camel@ignacio.ignacio.lan> Message-ID: <1115183816.12189.32.camel@plasma.starken.com> On Wed, 2005-05-04 at 01:05 -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2005-05-03 at 23:42 -0500, Daniel Wittenberg wrote: > > Yeah it's that time again...we've been busy getting the snort.spec > > updated for the new 2.4 release and wanted to run it by you guys to see > > how far off you think this one is. > > > > There is still some debates going on within the snort/sf teams about > > what to do with rules/signatures, so far now we're planning the old way > > until something is pinned down. > > > > http://www.starken.com/snort/snort.spec > > initDir should possibly be /etc/rc.d/init.d, and Fedora already defines > %_initrddir for that. We actually use /etc/init.d as it is much more portable to other systems and is still compatible with RH/fedora. > Also, /etc is in %_sysconfdir. Actually %_sysconfdir is %{_prefix}/etc which is not what I wanted. Thanks! Dan From ivazquez at ivazquez.net Wed May 4 05:21:52 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 04 May 2005 01:21:52 -0400 Subject: Review request: snort In-Reply-To: <1115183816.12189.32.camel@plasma.starken.com> References: <1115181733.12189.27.camel@plasma.starken.com> <1115183110.5462.30.camel@ignacio.ignacio.lan> <1115183816.12189.32.camel@plasma.starken.com> Message-ID: <1115184112.5462.32.camel@ignacio.ignacio.lan> On Wed, 2005-05-04 at 00:16 -0500, Daniel Wittenberg wrote: > On Wed, 2005-05-04 at 01:05 -0400, Ignacio Vazquez-Abrams wrote: > > Also, /etc is in %_sysconfdir. > > Actually %_sysconfdir is %{_prefix}/etc which is not what I wanted. Not in Fedora. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Wed May 4 05:30:21 2005 From: wtogami at redhat.com (Warren Togami) Date: Tue, 03 May 2005 19:30:21 -1000 Subject: make tag and %{?dist} In-Reply-To: <1115171447.27280.38.camel@jdub.homelinux.org> References: <1115171447.27280.38.camel@jdub.homelinux.org> Message-ID: <42785DED.7060705@redhat.com> Josh Boyer wrote: > Hi, > > I'm trying to figure out how the %{dist} macro is supposed to work with > the 'make tag' command in CVS. > > According to http://www.fedoraproject.org/wiki/DistTag one can append > %{?dist} to the Release field in the spec file and it will be expanded > to the correct value when the package is built by the build system. Huh? We came to agreement around 2 months ago that the scary macro voodoo had to be rewritten because we must not use rpm query during rpmbuild. Spot had a set of scripts to replace them. Don't know what happened after that. Warren From daniel-wittenberg at starken.com Wed May 4 05:30:43 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Wed, 04 May 2005 00:30:43 -0500 Subject: Review request: snort In-Reply-To: <1115184112.5462.32.camel@ignacio.ignacio.lan> References: <1115181733.12189.27.camel@plasma.starken.com> <1115183110.5462.30.camel@ignacio.ignacio.lan> <1115183816.12189.32.camel@plasma.starken.com> <1115184112.5462.32.camel@ignacio.ignacio.lan> Message-ID: <1115184643.12189.37.camel@plasma.starken.com> Really? plasma.starken $ rpm -q fedora-release fedora-release-3-9 plasma.starken $ grep ^%_sysconfdir /usr/lib/rpm/macros %_sysconfdir %{_prefix}/etc Dan On Wed, 2005-05-04 at 01:21 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-05-04 at 00:16 -0500, Daniel Wittenberg wrote: > > On Wed, 2005-05-04 at 01:05 -0400, Ignacio Vazquez-Abrams wrote: > > > Also, /etc is in %_sysconfdir. > > > > Actually %_sysconfdir is %{_prefix}/etc which is not what I wanted. > > Not in Fedora. > From adrian at lisas.de Wed May 4 05:34:53 2005 From: adrian at lisas.de (Adrian Reber) Date: Wed, 4 May 2005 07:34:53 +0200 Subject: Review request: snort In-Reply-To: <1115184643.12189.37.camel@plasma.starken.com> References: <1115181733.12189.27.camel@plasma.starken.com> <1115183110.5462.30.camel@ignacio.ignacio.lan> <1115183816.12189.32.camel@plasma.starken.com> <1115184112.5462.32.camel@ignacio.ignacio.lan> <1115184643.12189.37.camel@plasma.starken.com> Message-ID: <20050504053453.GA16130@lisas.de> On Wed, May 04, 2005 at 12:30:43AM -0500, Daniel Wittenberg wrote: > Really? > > plasma.starken $ rpm -q fedora-release > fedora-release-3-9 > > plasma.starken $ grep ^%_sysconfdir /usr/lib/rpm/macros > %_sysconfdir %{_prefix}/etc try: $ rpm --showrc | grep sysconfdir ... -14: _sysconfdir /etc ... > On Wed, 2005-05-04 at 01:21 -0400, Ignacio Vazquez-Abrams wrote: > > On Wed, 2005-05-04 at 00:16 -0500, Daniel Wittenberg wrote: > > > On Wed, 2005-05-04 at 01:05 -0400, Ignacio Vazquez-Abrams wrote: > > > > Also, /etc is in %_sysconfdir. > > > > > > Actually %_sysconfdir is %{_prefix}/etc which is not what I wanted. > > > > Not in Fedora. Adrian -- Adrian Reber http://lisas.de/~adrian/ Amy: "What about Umbrielle?" Fry: "Well, it turned out I loved her, but I wasn't in love with her." Amy: "Trouble in bed." From ivazquez at ivazquez.net Wed May 4 05:43:27 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 04 May 2005 01:43:27 -0400 Subject: Review request: snort In-Reply-To: <20050504053453.GA16130@lisas.de> References: <1115181733.12189.27.camel@plasma.starken.com> <1115183110.5462.30.camel@ignacio.ignacio.lan> <1115183816.12189.32.camel@plasma.starken.com> <1115184112.5462.32.camel@ignacio.ignacio.lan> <1115184643.12189.37.camel@plasma.starken.com> <20050504053453.GA16130@lisas.de> Message-ID: <1115185408.5462.34.camel@ignacio.ignacio.lan> On Wed, 2005-05-04 at 07:34 +0200, Adrian Reber wrote: > On Wed, May 04, 2005 at 12:30:43AM -0500, Daniel Wittenberg wrote: > > Really? > > > > plasma.starken $ rpm -q fedora-release > > fedora-release-3-9 > > > > plasma.starken $ grep ^%_sysconfdir /usr/lib/rpm/macros > > %_sysconfdir %{_prefix}/etc > > try: > $ rpm --showrc | grep sysconfdir > ... > -14: _sysconfdir /etc > ... Or even just: $ rpm --eval "%_sysconfdir" /etc -- 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 daniel-wittenberg at starken.com Wed May 4 05:48:12 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Wed, 04 May 2005 00:48:12 -0500 Subject: Review request: snort In-Reply-To: <20050504053453.GA16130@lisas.de> References: <1115181733.12189.27.camel@plasma.starken.com> <1115183110.5462.30.camel@ignacio.ignacio.lan> <1115183816.12189.32.camel@plasma.starken.com> <1115184112.5462.32.camel@ignacio.ignacio.lan> <1115184643.12189.37.camel@plasma.starken.com> <20050504053453.GA16130@lisas.de> Message-ID: <1115185692.12189.43.camel@plasma.starken.com> On Wed, 2005-05-04 at 07:34 +0200, Adrian Reber wrote: > On Wed, May 04, 2005 at 12:30:43AM -0500, Daniel Wittenberg wrote: > > Really? > > > > plasma.starken $ rpm -q fedora-release > > fedora-release-3-9 > > > > plasma.starken $ grep ^%_sysconfdir /usr/lib/rpm/macros > > %_sysconfdir %{_prefix}/etc > > try: > $ rpm --showrc | grep sysconfdir > ... > -14: _sysconfdir /etc > ... > Ahh...I see the other rpmrc and macro files that can override this. Thanks for the extra info. I've updated the spec and found another /var/ macro to replace so I think that's most of the macro updates. http://www.starken.com/snort/snort.spec Dan From daniel-wittenberg at starken.com Wed May 4 05:48:50 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Wed, 04 May 2005 00:48:50 -0500 Subject: Review request: snort In-Reply-To: <1115185408.5462.34.camel@ignacio.ignacio.lan> References: <1115181733.12189.27.camel@plasma.starken.com> <1115183110.5462.30.camel@ignacio.ignacio.lan> <1115183816.12189.32.camel@plasma.starken.com> <1115184112.5462.32.camel@ignacio.ignacio.lan> <1115184643.12189.37.camel@plasma.starken.com> <20050504053453.GA16130@lisas.de> <1115185408.5462.34.camel@ignacio.ignacio.lan> Message-ID: <1115185731.12189.45.camel@plasma.starken.com> On Wed, 2005-05-04 at 01:43 -0400, Ignacio Vazquez-Abrams wrote: > Or even just: > > $ rpm --eval "%_sysconfdir" > /etc > Yup, thanks again for info. Dan From bugs.michael at gmx.net Wed May 4 08:24:22 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 4 May 2005 10:24:22 +0200 Subject: make tag and %{?dist} In-Reply-To: <1115178680.27280.91.camel@jdub.homelinux.org> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> <1115178680.27280.91.camel@jdub.homelinux.org> Message-ID: <20050504102422.24f85598.bugs.michael@gmx.net> On Tue, 03 May 2005 22:51:20 -0500, Josh Boyer wrote: > For the actual RPM build, on the actual Red Hat build systems, this is > how it would be/is done. That is where the "scary macro voodoo" that > Ignacio mentioned in another thread comes into play. Revisiting the dist-tag related thread on fedora-packaging list would make sense. As long as I cannot store a single src.rpm revision in a single branch and build this single src.rpm for multiple target distributions, the system is flawed. It is more convenient to just hardcode .fc4, .fc3 and friends in the spec file, because we duplicate packages in multiple branch directories. > But, the process to get a package actually built on the Red Hat build > systems from Fedora Extras CVS There is no such build system. Seth Vidal has been building packages with the help of a few scripts and later a yum-ified mach, and he's working on creating a tag-based automated build system, too. So far, tags have not been necessary for any builds. But tags are useful, and hence they are mentioned in the Hints section. Whether contributors revisit the Wiki pages occasionally, I don't know. From bugs.michael at gmx.net Wed May 4 08:31:21 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 4 May 2005 10:31:21 +0200 Subject: Review request: snort In-Reply-To: <1115185408.5462.34.camel@ignacio.ignacio.lan> References: <1115181733.12189.27.camel@plasma.starken.com> <1115183110.5462.30.camel@ignacio.ignacio.lan> <1115183816.12189.32.camel@plasma.starken.com> <1115184112.5462.32.camel@ignacio.ignacio.lan> <1115184643.12189.37.camel@plasma.starken.com> <20050504053453.GA16130@lisas.de> <1115185408.5462.34.camel@ignacio.ignacio.lan> Message-ID: <20050504103121.57855b48.bugs.michael@gmx.net> On Wed, 04 May 2005 01:43:27 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-05-04 at 07:34 +0200, Adrian Reber wrote: > > On Wed, May 04, 2005 at 12:30:43AM -0500, Daniel Wittenberg wrote: > > > Really? > > > > > > plasma.starken $ rpm -q fedora-release > > > fedora-release-3-9 > > > > > > plasma.starken $ grep ^%_sysconfdir /usr/lib/rpm/macros > > > %_sysconfdir %{_prefix}/etc > > > > try: > > $ rpm --showrc | grep sysconfdir > > ... > > -14: _sysconfdir /etc > > ... > > Or even just: > > $ rpm --eval "%_sysconfdir" > /etc Or: $ grep ^%_sysconfdir /usr/lib/rpm/redhat/* /usr/lib/rpm/redhat/macros:%_sysconfdir /etc > We actually use /etc/init.d as it is much more portable to other systems > and is still compatible with RH/fedora. I still disagree with using /etc/init.d/, because that file is a symlink, and the full path /etc/init.d/rc.d/ should appear in packages. From rc040203 at freenet.de Wed May 4 08:34:16 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 May 2005 10:34:16 +0200 Subject: make tag and %{?dist} In-Reply-To: <20050504102422.24f85598.bugs.michael@gmx.net> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> Message-ID: <1115195657.24385.590.camel@mccallum.corsepiu.local> On Wed, 2005-05-04 at 10:24 +0200, Michael Schwendt wrote: > On Tue, 03 May 2005 22:51:20 -0500, Josh Boyer wrote: > > > For the actual RPM build, on the actual Red Hat build systems, this is > > how it would be/is done. That is where the "scary macro voodoo" that > > Ignacio mentioned in another thread comes into play. > > Revisiting the dist-tag related thread on fedora-packaging list would > make sense. As long as I cannot store a single src.rpm revision in a > single branch and build this single src.rpm for multiple target > distributions, the system is flawed. It is more convenient to just > hardcode .fc4, .fc3 and friends in the spec file, because we duplicate > packages in multiple branch directories. ACK, well spoken. IMHO, FE's CVS not using actual CVS branches is a real fundamental design flaw of it - something that ought to be changed. Ralf From jwboyer at jdub.homelinux.org Wed May 4 11:05:40 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 04 May 2005 06:05:40 -0500 Subject: make tag and %{?dist} In-Reply-To: <20050504102422.24f85598.bugs.michael@gmx.net> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> Message-ID: <1115204740.27280.97.camel@jdub.homelinux.org> On Wed, 2005-05-04 at 10:24 +0200, Michael Schwendt wrote: > On Tue, 03 May 2005 22:51:20 -0500, Josh Boyer wrote: > > > For the actual RPM build, on the actual Red Hat build systems, this is > > how it would be/is done. That is where the "scary macro voodoo" that > > Ignacio mentioned in another thread comes into play. > > Revisiting the dist-tag related thread on fedora-packaging list would > make sense. As long as I cannot store a single src.rpm revision in a > single branch and build this single src.rpm for multiple target > distributions, the system is flawed. It is more convenient to just > hardcode .fc4, .fc3 and friends in the spec file, because we duplicate > packages in multiple branch directories. Sorry, I don't follow that list at the moment. I'll have to dig around in the archives. As for hardcoding being convenient, I disagree. I think it's a pain. I do not see why everyone should have to hardcode that when it could be done by the make targets. > > But, the process to get a package actually built on the Red Hat build > > systems from Fedora Extras CVS > > There is no such build system. Seth Vidal has been building packages with > the help of a few scripts and later a yum-ified mach, and he's working on > creating a tag-based automated build system, too. So far, tags have not > been necessary for any builds. But tags are useful, and hence they are > mentioned in the Hints section. Whether contributors revisit the Wiki > pages occasionally, I don't know. Are you sure tags aren't currently needed? Take a look at the tobuild file. I certainly see tags listed there... And if they aren't needed, how does the build system (aka Seth) know what to build? josh From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed May 4 11:07:15 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 4 May 2005 13:07:15 +0200 Subject: buildsystem stuff In-Reply-To: <1115181658.15831.45.camel@cutter> References: <1115181658.15831.45.camel@cutter> Message-ID: <20050504130715.51f466c7@python2> seth vidal wrote : > That's the short version of how it works - a list of todos are at the > top of the two important files. I've got a few more tests to do and then > I'll probably make the 'tobuild' file open to anyone with cvs commit > access so you can run 'make build' to request your own builds. > > let me know what you think, even if I've wasted my time. I personally think this is great, THANKS seth! :-) I've got two questions : - Have your last tobuild tests worked alright? Is this ready to use? - How do the resulting packages show up in the Extras tree? That second point is the most important, I guess, as we might want to review binary packages after they're built "just in case". Next, the signing stage should probably stay "manual", eventually when that review occurs, and just before the packages go out to the public tree? Last, how do the old packages get cleaned out? For this last question, here's the solution I've been using myself for years : I have my main tree (it could be a private one in this case) which is organized as "//" in which I remove all files in "" when a new package of "package name" is built, then I add all the new files. I then run a mass clean-out, followed by hard-linking of all those sub-dirs in the repository-enabled tree. This makes me avoid complicated version comparisons and such, and takes care of the corner cases such as when the new packages no longer include a given sub-package. Anyway... once again... great work, seth! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.20_FC3 Load : 0.42 0.21 0.35 From bugs.michael at gmx.net Wed May 4 11:32:57 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 4 May 2005 13:32:57 +0200 Subject: make tag and %{?dist} In-Reply-To: <1115204740.27280.97.camel@jdub.homelinux.org> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> Message-ID: <20050504133257.54903ae3.bugs.michael@gmx.net> On Wed, 04 May 2005 06:05:40 -0500, Josh Boyer wrote: > On Wed, 2005-05-04 at 10:24 +0200, Michael Schwendt wrote: > > On Tue, 03 May 2005 22:51:20 -0500, Josh Boyer wrote: > > > > > For the actual RPM build, on the actual Red Hat build systems, this is > > > how it would be/is done. That is where the "scary macro voodoo" that > > > Ignacio mentioned in another thread comes into play. > > > > Revisiting the dist-tag related thread on fedora-packaging list would > > make sense. As long as I cannot store a single src.rpm revision in a > > single branch and build this single src.rpm for multiple target > > distributions, the system is flawed. It is more convenient to just > > hardcode .fc4, .fc3 and friends in the spec file, because we duplicate > > packages in multiple branch directories. > > Sorry, I don't follow that list at the moment. I'll have to dig around > in the archives. > > As for hardcoding being convenient, I disagree. I think it's a pain. I > do not see why everyone should have to hardcode that when it could be > done by the make targets. Everything that is added to the tag on-the-fly is non-intuitive and bad. I would not like it if cvs-import.sh altered my spec file, and I would not like it if "make tag" used too much "magic" (like relying on CVS branch directory file names instead of evaluating RPM macros). A bigger pain for package developers is that they want to do mass-upgrades for multiple distributions first. Only due to that comes their apparent need to release a single src.rpm for multiple distribution versions. If it's just the "Release" field that should be different, it takes only a second to alter it prior to cvs commit. At some point of time, most multi-dist spec files start introducing an increasing number of dist-dependent macros. And that's where the real time consuming maintenance requirements are. > > > But, the process to get a package actually built on the Red Hat build > > > systems from Fedora Extras CVS > > > > There is no such build system. Seth Vidal has been building packages with > > the help of a few scripts and later a yum-ified mach, and he's working on > > creating a tag-based automated build system, too. So far, tags have not > > been necessary for any builds. But tags are useful, and hence they are > > mentioned in the Hints section. Whether contributors revisit the Wiki > > pages occasionally, I don't know. > > Are you sure tags aren't currently needed? Take a look at the tobuild > file. I certainly see tags listed there... And if they aren't needed, > how does the build system (aka Seth) know what to build? Yes, I'm sure. We have not needed tags for building so far, since we haven't used the tobuild file yet. It's only Seth who experiments with it so far. We have requested builds via the Wiki. And it was me who added the note about "make tag" to the documentation. ;) From jwboyer at jdub.homelinux.org Wed May 4 12:09:33 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 4 May 2005 07:09:33 -0500 Subject: make tag and %{?dist} In-Reply-To: <20050504133257.54903ae3.bugs.michael@gmx.net> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> Message-ID: <20050504120933.GA25802@yoda.jdub.homelinux.org> On Wed, May 04, 2005 at 01:32:57PM +0200, Michael Schwendt wrote: > > > > As for hardcoding being convenient, I disagree. I think it's a pain. I > > do not see why everyone should have to hardcode that when it could be > > done by the make targets. > > Everything that is added to the tag on-the-fly is non-intuitive and bad. > I would not like it if cvs-import.sh altered my spec file, and I would not > like it if "make tag" used too much "magic" (like relying on CVS branch > directory file names instead of evaluating RPM macros). I don't think what I'm proposing would change the spec file. If you have a %{?dist} in your Release field, then it would evaluate to the correct value. If a spec file didn't use %{dist} at all, then nothing happens anyway... > > A bigger pain for package developers is that they want to do mass-upgrades > for multiple distributions first. Only due to that comes their apparent > need to release a single src.rpm for multiple distribution versions. If > it's just the "Release" field that should be different, it takes only a > second to alter it prior to cvs commit. Yeah, it only takes a second. But it's non-intuitive to me, and it could be automated so I don't have to do that. What's the point of using %{dist} at all if I have to manually define it every single time? Seems silly. And yes, the goal is to do upgrades to multiple distributions for packages that are simple enough to do that with. The correct solution, as you described, is to use the same spec file or src.rpm for all of the distributions, but that doesn't work with the CVS setup we have today. > > > > Are you sure tags aren't currently needed? Take a look at the tobuild > > file. I certainly see tags listed there... And if they aren't needed, > > how does the build system (aka Seth) know what to build? > > Yes, I'm sure. We have not needed tags for building so far, since we > haven't used the tobuild file yet. It's only Seth who experiments with > it so far. We have requested builds via the Wiki. And it was me who > added the note about "make tag" to the documentation. ;) Ok, but how does the builder know what to build today? Is it simply taken from CVS HEAD in each branch? You might not need tags at this moment, but with the work Seth is doing you will so I still think my proposal would be easier in general. But that's just my opinion I guess. josh From skvidal at phy.duke.edu Wed May 4 13:30:54 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 04 May 2005 09:30:54 -0400 Subject: make tag and %{?dist} In-Reply-To: <20050504133257.54903ae3.bugs.michael@gmx.net> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> Message-ID: <1115213454.15831.53.camel@cutter> > Yes, I'm sure. We have not needed tags for building so far, since we > haven't used the tobuild file yet. It's only Seth who experiments with > it so far. We have requested builds via the Wiki. And it was me who > added the note about "make tag" to the documentation. ;) and I posted to this list and to -maintainers asking everyone to make tag on the packages they wanted to get built so I could do my tests. -sv From bugs.michael at gmx.net Wed May 4 13:40:41 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 4 May 2005 15:40:41 +0200 Subject: make tag and %{?dist} In-Reply-To: <20050504120933.GA25802@yoda.jdub.homelinux.org> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> <20050504120933.GA25802@yoda.jdub.homelinux.org> Message-ID: <20050504154041.00657847.bugs.michael@gmx.net> On Wed, 4 May 2005 07:09:33 -0500, Josh Boyer wrote: > I don't think what I'm proposing would change the spec file. If you have a > %{?dist} in your Release field, then it would evaluate to the correct value. > If a spec file didn't use %{dist} at all, then nothing happens anyway... No, but in an environment where %dist is defined, e.g. because the corresponding rpm macros are included in the redhat-rpm-config package (useful!), you do want the tag creation script to ignore the value and create one from the CVS branch directory name instead, don't you? > > A bigger pain for package developers is that they want to do mass-upgrades > > for multiple distributions first. Only due to that comes their apparent > > need to release a single src.rpm for multiple distribution versions. If > > it's just the "Release" field that should be different, it takes only a > > second to alter it prior to cvs commit. > > Yeah, it only takes a second. But it's non-intuitive to me, and it could be > automated so I don't have to do that. How often do you have to? With current CVS setup, you would need to copy your external working copy of a package into the individual branch directories first, anyway. > What's the point of using %{dist} at all > if I have to manually define it every single time? Seems silly. See fedora-packaging list. Talk to the proponents of dist tags. If and only if %dist comes predefined for every of our supported distributions, dist tags can be beneficial. A conflict between current usage of cvs tags, package NEVR, and directory based branches is something else to discuss, > > > Are you sure tags aren't currently needed? Take a look at the tobuild > > > file. I certainly see tags listed there... And if they aren't needed, > > > how does the build system (aka Seth) know what to build? > > > > Yes, I'm sure. We have not needed tags for building so far, since we > > haven't used the tobuild file yet. It's only Seth who experiments with > > it so far. We have requested builds via the Wiki. And it was me who > > added the note about "make tag" to the documentation. ;) > > Ok, but how does the builder know what to build today? Is it simply taken from > CVS HEAD in each branch? Yes. From tcallawa at redhat.com Wed May 4 13:43:25 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 04 May 2005 08:43:25 -0500 Subject: make tag and %{?dist} In-Reply-To: <20050504120933.GA25802@yoda.jdub.homelinux.org> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> <20050504120933.GA25802@yoda.jdub.homelinux.org> Message-ID: <1115214205.4106.29.camel@localhost.localdomain> On Wed, 2005-05-04 at 07:09 -0500, Josh Boyer wrote: > On Wed, May 04, 2005 at 01:32:57PM +0200, Michael Schwendt wrote: > > > > > > As for hardcoding being convenient, I disagree. I think it's a pain. I > > > do not see why everyone should have to hardcode that when it could be > > > done by the make targets. > > > > Everything that is added to the tag on-the-fly is non-intuitive and bad. > > I would not like it if cvs-import.sh altered my spec file, and I would not > > like it if "make tag" used too much "magic" (like relying on CVS branch > > directory file names instead of evaluating RPM macros). > > I don't think what I'm proposing would change the spec file. If you have a > %{?dist} in your Release field, then it would evaluate to the correct value. > If a spec file didn't use %{dist} at all, then nothing happens anyway... The proposal I made (revision 240,764,842 or so) was the following: If you wanted to have "automagic" dist values set, you could (if implemented), pass a flag like "--usedist" to cvs-import.sh, or call something like "make tag-dist" where it is explicitly performing the magic, but not forcing it on those who don't give a red monkey's behind. In the interim, what I've been doing (because I am the law), is hardcoding dist tags into some of my packages to differentiate them. There are two branches now (FC-3 and devel), and in the worst forseeable case, we'll have four active branches, so thats a really minor one time spec file change to make. The primary reason I didn't want to hardcode the macros was to prevent people from abusing the priviledge like so: %define dist .FC3sucksandJoeWuzHereSoSuckIt But, in retrospect, I realized that we would hopefully catch most of these before they were built. So, here's how you can use dist tags, right now: If you want to use dist tags today, you have to hardcode the value in your spec. There is no buildsystem checking to enforce that you're doing it right, so I highly suggest that you checkin a spec for each branch without a dist tag, do a full cvs checkout, then make the changes, and cvs commit. In the spec, as the first two lines, you should put: %define dist .fc3 %define fedora 3 Where .fc3 is the appropriate value for the branch that the spec resides in. Currently, the only permitted values are: .fc3 .fc4 We're not building RHEL Extras (yet), so you shouldn't care about that or the RHL values (.el4 or .rhl8). (However, Sopwith and I wrote a shell script to do auto magic voodoo dist resolution, which should be in CVS for redhat-rpm-config already). In the same line, "fedora" is the only other var you should care about (rhl and rhel are the other correct values, but again, not used in FE). Once this is done, you can change your Release from: Release: 2 to Release: 2%{?dist} If you need to bump the release number, remember to change 2%{?dist} to 3%{?dist}. The second variable (%fedora) is there so that you can perform numeric conditionals like: # Do something for FC4 and beyond. %if "%fedora" >= "4" # ... %endif or distro conditionals like: # One-liners, here set a default switch. %{?fedora:%define _with_xfce --with-xfce} Now, here is the mini-FAQ: Q: Do I have to use dist tags? A: No. You don't. Q: Can I hardcode something other than .fc3 or .fc4 into %dist? A: No. Q: Does .fc3 have to be lowercase? A: Yes. This is for consistency. Q: Can't I just hardcode the .fc3 into the Release? A: No. Q: Can I put the actual release number after the %{?dist}? A: No. Q: I don't have any conditionals that use the %fedora macro, do I have to define it? A: Yes. Consistency (and it serves as a quick reminder that you've used the right value). Now, wrt to the automagic adding of dist, if there is enough interest in that, you can either wait until I've got the time to add these things to cvs-import.sh and the Makefile, or you can send me patches for review. Hopefully, that clears up dist tag usage (although, its just as likely to spawn another flame war). ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ivazquez at ivazquez.net Wed May 4 13:58:57 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 04 May 2005 09:58:57 -0400 Subject: make tag and %{?dist} In-Reply-To: <1115214205.4106.29.camel@localhost.localdomain> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> <20050504120933.GA25802@yoda.jdub.homelinux.org> <1115214205.4106.29.camel@localhost.localdomain> Message-ID: <1115215137.5462.43.camel@ignacio.ignacio.lan> On Wed, 2005-05-04 at 08:43 -0500, Tom 'spot' Callaway wrote: > In the spec, as the first two lines, you should put: > > %define dist .fc3 > %define fedora 3 What about: %{!?dist: %define dist .fc3 } %{!?fedora: %define fedora 3 } -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Wed May 4 14:01:26 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 4 May 2005 16:01:26 +0200 Subject: make tag and %{?dist} In-Reply-To: <1115214205.4106.29.camel@localhost.localdomain> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> <20050504120933.GA25802@yoda.jdub.homelinux.org> <1115214205.4106.29.camel@localhost.localdomain> Message-ID: <20050504160126.4eae5087.bugs.michael@gmx.net> On Wed, 04 May 2005 08:43:25 -0500, Tom 'spot' Callaway wrote: > Q: Does .fc3 have to be lowercase? > A: Yes. This is for consistency. And consistency is necessary or else: .fc3 > .FC4 > Q: Can't I just hardcode the .fc3 into the Release? > A: No. An increasing number of packages do this already. There is no difference between hardcoding %dist or using a constant instead. > Q: I don't have any conditionals that use the %fedora macro, do I have > to define it? > A: Yes. Consistency (and it serves as a quick reminder that you've used > the right value). Do I read this correctly? You want every spec file to define %fedora? (uhmm...) > Hopefully, that clears up dist tag usage (although, its just as likely > to spawn another flame war). Right. A good bait. From tcallawa at redhat.com Wed May 4 14:07:04 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 04 May 2005 09:07:04 -0500 Subject: make tag and %{?dist} In-Reply-To: <20050504160126.4eae5087.bugs.michael@gmx.net> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> <20050504120933.GA25802@yoda.jdub.homelinux.org> <1115214205.4106.29.camel@localhost.localdomain> <20050504160126.4eae5087.bugs.michael@gmx.net> Message-ID: <1115215624.4106.31.camel@localhost.localdomain> On Wed, 2005-05-04 at 16:01 +0200, Michael Schwendt wrote: > On Wed, 04 May 2005 08:43:25 -0500, Tom 'spot' Callaway wrote: > > > Q: Does .fc3 have to be lowercase? > > A: Yes. This is for consistency. > > And consistency is necessary or else: .fc3 > .FC4 > > > Q: Can't I just hardcode the .fc3 into the Release? > > A: No. > > An increasing number of packages do this already. There is > no difference between hardcoding %dist or using a constant instead. Well, there's no time better than the present to stop. :) > > Q: I don't have any conditionals that use the %fedora macro, do I have > > to define it? > > A: Yes. Consistency (and it serves as a quick reminder that you've used > > the right value). > > Do I read this correctly? You want every spec file to define %fedora? > (uhmm...) If you're using %dist, then yes. You can't have one without the oooother. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From toshio at tiki-lounge.com Wed May 4 14:00:34 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 4 May 2005 07:00:34 -0700 Subject: New package: cogito In-Reply-To: <1115170095.27280.25.camel@jdub.homelinux.org>; from jwboyer@jdub.homelinux.org on Tue, May 03, 2005 at 08:28:15PM -0500 References: <20050503232939.GZ18917@shell0.pdx.osdl.net> <20050503233517.GA17380@redhat.com> <1115170095.27280.25.camel@jdub.homelinux.org> Message-ID: <20050504070034.A17520@tiki-lounge.com> On Tue, May 03, 2005 at 08:28:15PM -0500, Josh Boyer wrote: > On Tue, 2005-05-03 at 19:35 -0400, Dave Jones wrote: > > On Tue, May 03, 2005 at 04:29:39PM -0700, Chris Wright wrote: > > > Here's a proposal to add the cogito package. Cogito is both the lowlevel > > > backend storage provided by Git, as well as the frontend usable as an SCM. > > > I don't know of any issues with the package. I don't have Fedora Extras > > > CVS access, so need a sponsor for that. > > > > > > Description (from spec file): > > > > > > GIT comes in two layers. The bottom layer is merely an extremely fast > > > and flexible filesystem-based database designed to store directory trees > > > with regard to their history. The top layer is a SCM-like tool which > > > enables human beings to work with the database in a manner to a degree > > > similar to other SCM tools (like CVS, BitKeeper or Monotone). > > > > Hey Chris, > > I was pondering packaging up git myself too, but held off for one reason. > > Right now, Linus has the perogative to say "oh shit, this is wrong" > > and redesign the meta-data to work around whatever comes up, and > > the only projects really affected are his own (and subsequent clones). > > > > If we package up git now, and people started using it to host their > > own projects, what happens when the next release of git won't read > > their old repositories ? > > > > I'd be tempted to sit things out a bit longer before its added, > > even to extras, until its got a few more battle-scars. > > Yep, I agree. I have also been playing around with packaging cogito, > but I've held off trying to submit anything until it stabilizes a bit. > > josh > Do we still have separate repositories for this? (On fedora.us there was unstable and testing.) I'm not sure if the new testing repository is more like the Fedora Core Testing repo.... If we plan on implementing the "Every OSS package is potentially a candidate for Extras" then we need some structure to handle packages of unstable libraries, SCMs, etc that are: "Use these at your own risk. Breakage-free migration (even day-to-day) is not guarenteed." -Toshio From tcallawa at redhat.com Wed May 4 14:08:41 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 04 May 2005 09:08:41 -0500 Subject: make tag and %{?dist} In-Reply-To: <1115215137.5462.43.camel@ignacio.ignacio.lan> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> <20050504120933.GA25802@yoda.jdub.homelinux.org> <1115214205.4106.29.camel@localhost.localdomain> <1115215137.5462.43.camel@ignacio.ignacio.lan> Message-ID: <1115215721.4106.35.camel@localhost.localdomain> On Wed, 2005-05-04 at 09:58 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-05-04 at 08:43 -0500, Tom 'spot' Callaway wrote: > > In the spec, as the first two lines, you should put: > > > > %define dist .fc3 > > %define fedora 3 > > What about: > > %{!?dist: %define dist .fc3 } > %{!?fedora: %define fedora 3 } Nothing's defining %dist or %fedora in the buildsystem, so this is unnecessary. Although, if you're importing a package from an outside repo (where the buildsystem is defining these macros), then that might be necessary. Unless there is a strict case against, I'll permit that syntax, but not require it. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jwboyer at jdub.homelinux.org Wed May 4 14:17:15 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 4 May 2005 09:17:15 -0500 Subject: make tag and %{?dist} In-Reply-To: <1115215721.4106.35.camel@localhost.localdomain> References: <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> <20050504120933.GA25802@yoda.jdub.homelinux.org> <1115214205.4106.29.camel@localhost.localdomain> <1115215137.5462.43.camel@ignacio.ignacio.lan> <1115215721.4106.35.camel@localhost.localdomain> Message-ID: <20050504141715.GA25979@yoda.jdub.homelinux.org> On Wed, May 04, 2005 at 09:08:41AM -0500, Tom 'spot' Callaway wrote: > On Wed, 2005-05-04 at 09:58 -0400, Ignacio Vazquez-Abrams wrote: > > On Wed, 2005-05-04 at 08:43 -0500, Tom 'spot' Callaway wrote: > > > In the spec, as the first two lines, you should put: > > > > > > %define dist .fc3 > > > %define fedora 3 > > > > What about: > > > > %{!?dist: %define dist .fc3 } > > %{!?fedora: %define fedora 3 } > > Nothing's defining %dist or %fedora in the buildsystem, so this is > unnecessary. Although, if you're importing a package from an outside > repo (where the buildsystem is defining these macros), then that might > be necessary. Ok, the fact that the buildsystem wasn't defining those macros had escaped me. Mind if I explicitly point that out on the Wiki? josh From tcallawa at redhat.com Wed May 4 14:20:59 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 04 May 2005 09:20:59 -0500 Subject: make tag and %{?dist} In-Reply-To: <20050504141715.GA25979@yoda.jdub.homelinux.org> References: <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> <20050504120933.GA25802@yoda.jdub.homelinux.org> <1115214205.4106.29.camel@localhost.localdomain> <1115215137.5462.43.camel@ignacio.ignacio.lan> <1115215721.4106.35.camel@localhost.localdomain> <20050504141715.GA25979@yoda.jdub.homelinux.org> Message-ID: <1115216459.4106.38.camel@localhost.localdomain> On Wed, 2005-05-04 at 09:17 -0500, Josh Boyer wrote: > On Wed, May 04, 2005 at 09:08:41AM -0500, Tom 'spot' Callaway wrote: > > On Wed, 2005-05-04 at 09:58 -0400, Ignacio Vazquez-Abrams wrote: > > > On Wed, 2005-05-04 at 08:43 -0500, Tom 'spot' Callaway wrote: > > > > In the spec, as the first two lines, you should put: > > > > > > > > %define dist .fc3 > > > > %define fedora 3 > > > > > > What about: > > > > > > %{!?dist: %define dist .fc3 } > > > %{!?fedora: %define fedora 3 } > > > > Nothing's defining %dist or %fedora in the buildsystem, so this is > > unnecessary. Although, if you're importing a package from an outside > > repo (where the buildsystem is defining these macros), then that might > > be necessary. > > Ok, the fact that the buildsystem wasn't defining those macros had escaped me. > Mind if I explicitly point that out on the Wiki? The wiki page needs a complete rewrite. I put this on the top of it: NOTE! These guidelines need to be rewritten. You should ignore them for the time being. But apparently, it wasn't big or bold enough. :) ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From mattdm at mattdm.org Wed May 4 14:20:10 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 4 May 2005 10:20:10 -0400 Subject: make tag and %{?dist} In-Reply-To: <20050504160126.4eae5087.bugs.michael@gmx.net> References: <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> <20050504120933.GA25802@yoda.jdub.homelinux.org> <1115214205.4106.29.camel@localhost.localdomain> <20050504160126.4eae5087.bugs.michael@gmx.net> Message-ID: <20050504142010.GA4598@jadzia.bu.edu> On Wed, May 04, 2005 at 04:01:26PM +0200, Michael Schwendt wrote: > > Q: Can't I just hardcode the .fc3 into the Release? > > A: No. > An increasing number of packages do this already. There is > no difference between hardcoding %dist or using a constant instead. In fact, I think using a constant is *better*. That way, the %dist macro can be used to indicate "this should build on any currently-supported release" and hard-coded values imply "there's some per-distro-release differences in this spec file". And then, ideally, %dist is actually defined using the "voodoo" in the system-wide RPM macros -- although it's really not that much voodoo, especialyl compared to some of the other standard RPM macros (like the debuginfo package stuff!). -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 75 degrees Fahrenheit. From jwboyer at jdub.homelinux.org Wed May 4 14:36:48 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 4 May 2005 09:36:48 -0500 Subject: make tag and %{?dist} In-Reply-To: <1115216459.4106.38.camel@localhost.localdomain> References: <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> <20050504120933.GA25802@yoda.jdub.homelinux.org> <1115214205.4106.29.camel@localhost.localdomain> <1115215137.5462.43.camel@ignacio.ignacio.lan> <1115215721.4106.35.camel@localhost.localdomain> <20050504141715.GA25979@yoda.jdub.homelinux.org> <1115216459.4106.38.camel@localhost.localdomain> Message-ID: <20050504143648.GA26050@yoda.jdub.homelinux.org> On Wed, May 04, 2005 at 09:20:59AM -0500, Tom 'spot' Callaway wrote: > > Ok, the fact that the buildsystem wasn't defining those macros had escaped me. > > Mind if I explicitly point that out on the Wiki? > > The wiki page needs a complete rewrite. I put this on the top of it: > > NOTE! These guidelines need to be rewritten. You should ignore them for > the time being. > > But apparently, it wasn't big or bold enough. :) Heh, I guess not. Or maybe I'm just overly ambitious and my eyes decided not to send that text to my brain. :) josh From rc040203 at freenet.de Wed May 4 14:51:05 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 May 2005 16:51:05 +0200 Subject: make tag and %{?dist} In-Reply-To: <1115215624.4106.31.camel@localhost.localdomain> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> <20050504120933.GA25802@yoda.jdub.homelinux.org> <1115214205.4106.29.camel@localhost.localdomain> <20050504160126.4eae5087.bugs.michael@gmx.net> <1115215624.4106.31.camel@localhost.localdomain> Message-ID: <1115218265.24385.632.camel@mccallum.corsepiu.local> On Wed, 2005-05-04 at 09:07 -0500, Tom 'spot' Callaway wrote: > On Wed, 2005-05-04 at 16:01 +0200, Michael Schwendt wrote: > > On Wed, 04 May 2005 08:43:25 -0500, Tom 'spot' Callaway wrote: > > > > > Q: Does .fc3 have to be lowercase? > > > A: Yes. This is for consistency. > > > > And consistency is necessary or else: .fc3 > .FC4 > > > > > Q: Can't I just hardcode the .fc3 into the Release? > > > A: No. > > > > An increasing number of packages do this already. There is > > no difference between hardcoding %dist or using a constant instead. > > Well, there's no time better than the present to stop. :) Except, if there are bad conventions - With all due respect, what you described its waaaaay toooo complicated and means asking for trouble. Instead, implement one, single, mandatory convention or even let the buildsystem automatically assign, "Release" numbers which are guaranteed to be steadily increasing and conflict-free between FC release. Ralf From tcallawa at redhat.com Wed May 4 15:00:22 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 04 May 2005 10:00:22 -0500 Subject: make tag and %{?dist} In-Reply-To: <1115218265.24385.632.camel@mccallum.corsepiu.local> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> <20050504120933.GA25802@yoda.jdub.homelinux.org> <1115214205.4106.29.camel@localhost.localdomain> <20050504160126.4eae5087.bugs.michael@gmx.net> <1115215624.4106.31.camel@localhost.localdomain> <1115218265.24385.632.camel@mccallum.corsepiu.local> Message-ID: <1115218822.4106.43.camel@localhost.localdomain> On Wed, 2005-05-04 at 16:51 +0200, Ralf Corsepius wrote: > Except, if there are bad conventions - With all due respect, what you > described its waaaaay toooo complicated and means asking for trouble. Adding two lines to the top of a spec file is too complicated? :) > Instead, implement one, single, mandatory convention or even let the > buildsystem automatically assign, "Release" numbers which are guaranteed > to be steadily increasing and conflict-free between FC release. The buildsystem does not automatically assign anything. It builds packages, thats all it does. If you want it to do more, then Seth seems more than willing to let someone else take it over. So, unless you're willing to write, maintain, and run the Fedora Extras buildsystem for the next year at least, the buildsystem isn't going to define %dist (or any other field) for us. However, in lieu of that, all packages need to be tagged before the buildsystem builds them. What I described is the simplest way to do this that I could come up with. I'm certainly open to suggestions on how to make it simpler. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From lfarkas at bppiac.hu Wed May 4 15:02:11 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Wed, 04 May 2005 17:02:11 +0200 Subject: synce spec file thoughts Message-ID: <4278E3F3.9020401@bppiac.hu> hi, after i install synce from extras and try to install recompile... other components from the synce project i've got a few questions: - would it be possible to include other part of the synce project in extras? ie. synce-gnomevfs, synce-multisync_plugin, synce-software-manager, synce-trayicon, unshield, orange and dynamite? - why do you modify the include files from /usr/include/rra to /usr/include? first of all it makes harder to recompile other packages and for me eg. /usr/include/task.h or /usr/include/timezone.h doesn't look as the best choise over /usr/include/rra/task.h, /usr/include/rra/timezone.h! yours. -- Levente "Si vis pacem para bellum!" From j.w.r.degoede at hhs.nl Wed May 4 15:16:29 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 04 May 2005 17:16:29 +0200 Subject: Imported to CVS, review requested: Glide3 In-Reply-To: <20050503020541.5046d453@python2> References: <42712EA1.2050401@hhs.nl> <20050429120923.0fd0a318@python2> <42735CC8.60208@hhs.nl> <20050503020541.5046d453@python2> Message-ID: <4278E74D.1090201@hhs.nl> Matthias Saou wrote: > Hans de Goede wrote : > > >>This and a bunch of other stuff should be fixed in CVS now, please try >>the current CVS version. > > > Still fails for me on FC 3 x86_64 :-/ (my Devel root is trashed ATM) > Thanks for testing and reporting, this should be fixed in CVS now a Fedora-devel build would also be nice / better since gcc4 is more picky then 3.4 Regards, Hans From tcallawa at redhat.com Wed May 4 15:20:04 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 04 May 2005 10:20:04 -0500 Subject: make tag and %{?dist} In-Reply-To: <1115218822.4106.43.camel@localhost.localdomain> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> <20050504120933.GA25802@yoda.jdub.homelinux.org> <1115214205.4106.29.camel@localhost.localdomain> <20050504160126.4eae5087.bugs.michael@gmx.net> <1115215624.4106.31.camel@localhost.localdomain> <1115218265.24385.632.camel@mccallum.corsepiu.local> <1115218822.4106.43.camel@localhost.localdomain> Message-ID: <1115220004.4106.45.camel@localhost.localdomain> On Wed, 2005-05-04 at 10:00 -0500, Tom 'spot' Callaway wrote: > However, in lieu of that, all packages need to be tagged before the > buildsystem builds them. To clarify, all packages where the packager wants to use a tag, need to be tagged before the buildsystem builds them. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From chrisw at osdl.org Wed May 4 15:19:39 2005 From: chrisw at osdl.org (Chris Wright) Date: Wed, 4 May 2005 08:19:39 -0700 Subject: New package: cogito In-Reply-To: <1115170095.27280.25.camel@jdub.homelinux.org> References: <20050503232939.GZ18917@shell0.pdx.osdl.net> <20050503233517.GA17380@redhat.com> <1115170095.27280.25.camel@jdub.homelinux.org> Message-ID: <20050504151939.GG18917@shell0.pdx.osdl.net> * Josh Boyer (jwboyer at jdub.homelinux.org) wrote: > On Tue, 2005-05-03 at 19:35 -0400, Dave Jones wrote: > > On Tue, May 03, 2005 at 04:29:39PM -0700, Chris Wright wrote: > > > Here's a proposal to add the cogito package. Cogito is both the lowlevel > > > backend storage provided by Git, as well as the frontend usable as an SCM. > > > I don't know of any issues with the package. I don't have Fedora Extras > > > CVS access, so need a sponsor for that. > > > > > > Description (from spec file): > > > > > > GIT comes in two layers. The bottom layer is merely an extremely fast > > > and flexible filesystem-based database designed to store directory trees > > > with regard to their history. The top layer is a SCM-like tool which > > > enables human beings to work with the database in a manner to a degree > > > similar to other SCM tools (like CVS, BitKeeper or Monotone). > > > > Hey Chris, > > I was pondering packaging up git myself too, but held off for one reason. > > Right now, Linus has the perogative to say "oh shit, this is wrong" > > and redesign the meta-data to work around whatever comes up, and > > the only projects really affected are his own (and subsequent clones). > > > > If we package up git now, and people started using it to host their > > own projects, what happens when the next release of git won't read > > their old repositories ? > > > > I'd be tempted to sit things out a bit longer before its added, > > even to extras, until its got a few more battle-scars. > > Yep, I agree. I have also been playing around with packaging cogito, > but I've held off trying to submit anything until it stabilizes a bit. OK. I'll keep putting them up on kernel.org as I have been, and resubmit as we see some stabilization. Thanks for the comments. thanks, -chris From mattdm at mattdm.org Wed May 4 15:27:24 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 4 May 2005 11:27:24 -0400 Subject: make tag and %{?dist} In-Reply-To: <1115218822.4106.43.camel@localhost.localdomain> References: <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> <20050504120933.GA25802@yoda.jdub.homelinux.org> <1115214205.4106.29.camel@localhost.localdomain> <20050504160126.4eae5087.bugs.michael@gmx.net> <1115215624.4106.31.camel@localhost.localdomain> <1115218265.24385.632.camel@mccallum.corsepiu.local> <1115218822.4106.43.camel@localhost.localdomain> Message-ID: <20050504152724.GA7220@jadzia.bu.edu> On Wed, May 04, 2005 at 10:00:22AM -0500, Tom 'spot' Callaway wrote: > > Except, if there are bad conventions - With all due respect, what you > > described its waaaaay toooo complicated and means asking for trouble. > Adding two lines to the top of a spec file is too complicated? :) To every spec file, yeah, it's kind of a complication. > > Instead, implement one, single, mandatory convention or even let the > > buildsystem automatically assign, "Release" numbers which are guaranteed > > to be steadily increasing and conflict-free between FC release. > The buildsystem does not automatically assign anything. It builds > packages, thats all it does. If you want it to do more, then Seth seems > more than willing to let someone else take it over. So, unless you're > willing to write, maintain, and run the Fedora Extras buildsystem for > the next year at least, the buildsystem isn't going to define %dist (or > any other field) for us. But this doesn't need to be in the buildsystem that Seth is making at all. It just needs to be in the redhat-rpm-config macros. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 75 degrees Fahrenheit. From skvidal at phy.duke.edu Wed May 4 15:59:34 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 04 May 2005 11:59:34 -0400 Subject: Package Build Report Message-ID: <1115222375.15831.84.camel@cutter> Packages that failed to build on Fedora Development: uim synergy QuantLib galeon verbiste wxGTK You can see build results and logs at: http://extras64.linux.duke.edu/failed/development/ Packages that have succeeded on the builds on all archs are available at: http://extras64.linux.duke.edu/needsign/development/ These have not been signed by the fedora extras key yet and won't be until we're finished with some other builds. Once they are signed they will be pushed into the normal fedora extras repositories. Thanks, -sv From rc040203 at freenet.de Wed May 4 16:01:12 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 May 2005 18:01:12 +0200 Subject: make tag and %{?dist} In-Reply-To: <20050504152724.GA7220@jadzia.bu.edu> References: <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> <20050504120933.GA25802@yoda.jdub.homelinux.org> <1115214205.4106.29.camel@localhost.localdomain> <20050504160126.4eae5087.bugs.michael@gmx.net> <1115215624.4106.31.camel@localhost.localdomain> <1115218265.24385.632.camel@mccallum.corsepiu.local> <1115218822.4106.43.camel@localhost.localdomain> <20050504152724.GA7220@jadzia.bu.edu> Message-ID: <1115222472.24385.676.camel@mccallum.corsepiu.local> On Wed, 2005-05-04 at 11:27 -0400, Matthew Miller wrote: > On Wed, May 04, 2005 at 10:00:22AM -0500, Tom 'spot' Callaway wrote: > > > Except, if there are bad conventions - With all due respect, what you > > > described its waaaaay toooo complicated and means asking for trouble. > > Adding two lines to the top of a spec file is too complicated? :) > > To every spec file, yeah, it's kind of a complication. Exactly - furthermore, Tom's proposal leaves too much freedom. This freedom is the cause of this (avoidable) discussion. Why not keeping things simple to users? Just tell them: Any package in FE must use a Release-Tag of this form "Release: XYZ%{dist}" or whatever you prefer. To me the point in using dist-tags as a package maintainer is being able keep the differences for the same package in different FE releases as small as possible and to keep the release numbers conflict free and steadily increasing. As %{dist} currently is not provided by rpm-macros, I am using hard coded {.fc3|.fc4} to enable users to be able to rebuild the rpms. Cluttering spec files with constructs like %define fedora 3 %{?!dist:%define dist .fc3} and the like to me is simply beyond reason. > > > Instead, implement one, single, mandatory convention or even let the > > > buildsystem automatically assign, "Release" numbers which are guaranteed > > > to be steadily increasing and conflict-free between FC release. > > The buildsystem does not automatically assign anything. True, the buildsystem _currently_ does not assign anything, nothing that couldn't be reconsidered and changed. Other distribution's buildsystems do. They are using the release tag as "buildnumber". > > It builds packages, thats all it does. Well, I agree assigning release tags during builds is arguable, because they might probably better be automatically assigned as part of "spec file submission" or "rebuild request". > But this doesn't need to be in the buildsystem that Seth is making at all. > It just needs to be in the redhat-rpm-config macros. Though I am opposed to this "macro magic" in general, this would be a viable solution. Ralf From ville.skytta at iki.fi Wed May 4 16:12:03 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 04 May 2005 19:12:03 +0300 Subject: Package Build Report In-Reply-To: <1115222375.15831.84.camel@cutter> References: <1115222375.15831.84.camel@cutter> Message-ID: <1115223123.4566.25.camel@bobcat.mine.nu> On Wed, 2005-05-04 at 11:59 -0400, seth vidal wrote: > You can see build results and logs at: > http://extras64.linux.duke.edu/failed/development/ Hm, all these build logs seem to contain stuff like this: [...] Rebuilding source rpm wxGTK-2.4.2-10.src.rpm ERROR: something went wrong rebuilding the .src.rpm ERROR: inspect rpm build log /var/tmp/mach/fedora-development-x86_64-core/wxGTK-2.4.2-10/rpm.log ERROR: failed to rebuild SRPMs Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.77890 [...] The SRPM build fails, but nevertheless the build continues? From skvidal at phy.duke.edu Wed May 4 16:17:38 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 04 May 2005 12:17:38 -0400 Subject: Package Build Report In-Reply-To: <1115223123.4566.25.camel@bobcat.mine.nu> References: <1115222375.15831.84.camel@cutter> <1115223123.4566.25.camel@bobcat.mine.nu> Message-ID: <1115223458.15831.90.camel@cutter> On Wed, 2005-05-04 at 19:12 +0300, Ville Skytt? wrote: > On Wed, 2005-05-04 at 11:59 -0400, seth vidal wrote: > > > You can see build results and logs at: > > http://extras64.linux.duke.edu/failed/development/ > > Hm, all these build logs seem to contain stuff like this: > > [...] > Rebuilding source rpm wxGTK-2.4.2-10.src.rpm > ERROR: something went wrong rebuilding the .src.rpm > ERROR: inspect rpm build log /var/tmp/mach/fedora-development-x86_64-core/wxGTK-2.4.2-10/rpm.log > ERROR: failed to rebuild SRPMs > Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.77890 > [...] > > The SRPM build fails, but nevertheless the build continues? > I don't see the problem with continuing the build if the recreation of the srpm fails. We already have the srpm, we're not starting from spec files. -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed May 4 16:22:48 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 4 May 2005 18:22:48 +0200 Subject: Imported to CVS, review requested: Glide3 In-Reply-To: <4278E74D.1090201@hhs.nl> References: <42712EA1.2050401@hhs.nl> <20050429120923.0fd0a318@python2> <42735CC8.60208@hhs.nl> <20050503020541.5046d453@python2> <4278E74D.1090201@hhs.nl> Message-ID: <20050504182248.6480b81f@python2> Hans de Goede wrote : > > Still fails for me on FC 3 x86_64 :-/ (my Devel root is trashed ATM) > > Thanks for testing and reporting, this should be fixed in CVS now a > Fedora-devel build would also be nice / better since gcc4 is more picky > then 3.4 Just tried a rebuild on FC Devel x86_64 with the changes you just committed to CVS and get this : [...] gcc -DX11 -fomit-frame-pointer -funroll-loops -fexpensive-optimizations - ffast-math -DBIG_OPT -Wall -DGLIDE_LIB -DGLIDE3 -DGLIDE3_ALPHA -DH3 - DGLIDE_PACKET3_TRI_SETUP=1 -DUSE_PACKET_FIFO=1 - DGLIDE_HW_TRI_SETUP=1 -DFX_GLIDE_NAPALM=1 - DFX_GLIDE_H5_CSIM=1 -DGLIDE_PLUG -DGLIDE_SPLASH -DFX_STATIC_BUILD - DGLIDE_INIT_HWC -DGLIDE_USE_C_TRISETUP -I../../../../h5/glide3/src - I../../../h5/incsrc -I../../../../h5/incsrc -I../../../../h5/minihwc -I. - I../../../../swlibs/fxmemmap -I../../../../swlibs/fxmisc -I../../../../ swlibs/newpci/pcilib -I../../../../swlibs/texus2/lib -O2 -g - pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona -O6 -Wno- unknown-pragmas -Wno-unused-value -Wno-unused -c ../../../../h5/ glide3/src/fxgasm.c ../../../../h5/glide3/src/fxgasm.c: In function 'main': ../../../../h5/glide3/src/fxgasm.c:102: warning: format '%X' expects type 'unsigned int', but argument 3 has type 'long unsigned int' ../../../../h5/glide3/src/fxgasm.c:106: warning: format '%X' expects type 'unsigned int', but argument 3 has type 'long unsigned int' ../../../../h5/glide3/src/fxgasm.c:109: warning: format '%X' expects type 'unsigned int', but argument 3 has type 'long unsigned int' ../../../../h5/glide3/src/fxgasm.c:112: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'long unsigned int' ../../../../h5/glide3/src/fxgasm.c:216: error: 'struct _GlideRoot_s' has no member named 'CPUType' ../../../../h5/glide3/src/fxgasm.c:216: error: 'struct _GlideRoot_s' has no member named 'CPUType' ../../../../h5/ glide3/src/fxgasm.c:220: warning: format '%08x' expects type 'unsigned int', but argument 4 has type 'long unsigned int' ../../../../h5/glide3/ src/fxgasm.c:220: warning: format '%10d' expects type 'int', but argument 4 has type 'long unsigned int' ../../../../h5/glide3/src/fxgasm.c:221: warning: format '%08x' expects type 'unsigned int', but argument 4 has type 'long unsigned int' ../../../../h5/glide3/src/fxgasm.c:221: warning: format '%10d' expects type 'int', but argument 4 has type 'long unsigned int' ../../../../h5/glide3/src/fxgasm.c:230: warning: format '%08x' expects type 'unsigned int', but argument 4 has type 'long unsigned int' ../../../../h5/glide3/src/fxgasm.c:230: warning: format '%10d' expects type 'int', but argument 4 has type 'long unsigned int' make[3]: *** [fxgasm.o] Error 1 make[3]: Leaving directory `/usr/src/rpm/BUILD/ Glide3/build-5/h5/glide3/src' I get the exact same error on FC3 FWIW. If you want me to test some further changes before you check them into CVS, and to not bother this list too much, we can take this off-list. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.20_FC3 Load : 1.19 1.31 1.19 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed May 4 16:30:36 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 4 May 2005 18:30:36 +0200 Subject: Package Build Report In-Reply-To: <1115223458.15831.90.camel@cutter> References: <1115222375.15831.84.camel@cutter> <1115223123.4566.25.camel@bobcat.mine.nu> <1115223458.15831.90.camel@cutter> Message-ID: <20050504183036.120fe28d@python2> seth vidal wrote : > On Wed, 2005-05-04 at 19:12 +0300, Ville Skytt? wrote: > > On Wed, 2005-05-04 at 11:59 -0400, seth vidal wrote: > > > > > You can see build results and logs at: > > > http://extras64.linux.duke.edu/failed/development/ > > > > Hm, all these build logs seem to contain stuff like this: > > > > [...] > > Rebuilding source rpm wxGTK-2.4.2-10.src.rpm > > ERROR: something went wrong rebuilding the .src.rpm > > ERROR: inspect rpm build log /var/tmp/mach/fedora-development-x86_64-core/wxGTK-2.4.2-10/rpm.log > > ERROR: failed to rebuild SRPMs > > Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.77890 > > [...] > > > > The SRPM build fails, but nevertheless the build continues? > > > > I don't see the problem with continuing the build if the recreation of > the srpm fails. We already have the srpm, we're not starting from spec > files. I think that the output at the top is actually mach's output. Once the build has failed, you get the whole output of the build appended, which was actually generated before the first "ERROR" got printed, right? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.20_FC3 Load : 1.62 1.42 1.28 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed May 4 16:32:02 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 4 May 2005 18:32:02 +0200 Subject: Package Build Report In-Reply-To: <1115222375.15831.84.camel@cutter> References: <1115222375.15831.84.camel@cutter> Message-ID: <20050504183202.73e99823@python2> seth vidal wrote : > Packages that failed to build on Fedora Development: > [...] > synergy > [...] I think this one was a silly tag problem (I kept the same release the last tag already had), so I now need to request a rebuild... can I already try "tobuild"? :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.20_FC3 Load : 0.67 1.17 1.20 From ville.skytta at iki.fi Wed May 4 16:34:30 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 04 May 2005 19:34:30 +0300 Subject: Package Build Report In-Reply-To: <1115223458.15831.90.camel@cutter> References: <1115222375.15831.84.camel@cutter> <1115223123.4566.25.camel@bobcat.mine.nu> <1115223458.15831.90.camel@cutter> Message-ID: <1115224470.4566.40.camel@bobcat.mine.nu> On Wed, 2005-05-04 at 12:17 -0400, seth vidal wrote: > On Wed, 2005-05-04 at 19:12 +0300, Ville Skytt? wrote: > > The SRPM build fails, but nevertheless the build continues? > > I don't see the problem with continuing the build if the recreation of > the srpm fails. We already have the srpm, we're not starting from spec > files. Where does that SRPM come from? IIRC if it's not (re)built in the target build root, the build deps mach gets can be incorrect because they're resolved from a SRPM, and the stuff that ends up in the SRPM header's build deps can vary depending on where it was built. From bugs.michael at gmx.net Wed May 4 16:41:46 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 4 May 2005 18:41:46 +0200 Subject: New package: cogito In-Reply-To: <20050504070034.A17520@tiki-lounge.com> References: <20050503232939.GZ18917@shell0.pdx.osdl.net> <20050503233517.GA17380@redhat.com> <1115170095.27280.25.camel@jdub.homelinux.org> <20050504070034.A17520@tiki-lounge.com> Message-ID: <20050504184146.005aae6d.bugs.michael@gmx.net> On Wed, 4 May 2005 07:00:34 -0700, Toshio Kuratomi wrote: > > > I'd be tempted to sit things out a bit longer before its added, > > > even to extras, until its got a few more battle-scars. > > > > Yep, I agree. I have also been playing around with packaging cogito, > > but I've held off trying to submit anything until it stabilizes a bit. > > > > josh > > > Do we still have separate repositories for this? No. > (On fedora.us there was > unstable and testing.) ... and confused many users, since (1) no document explained the philosophy behind a classification into stable/testing/unstable, (2) other repositories use a different classification, (3) hardly any user who, runs into problems with packages from "testing" or "unstable", would report a bug, (4) repository mixing becomes even funnier, (5) inter-repository dependencies (e.g. "livna") get more funny, too, (6) example yum config files apparently suggested to enable all repositories by default, and (7) an upgrade path from half-baked packages/software often is impracticable. > I'm not sure if the new testing repository is more > like the Fedora Core Testing repo.... It is and should not be abused for overly experimental stuff. From bugs.michael at gmx.net Wed May 4 16:50:31 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 4 May 2005 18:50:31 +0200 Subject: make tag and %{?dist} In-Reply-To: <1115222472.24385.676.camel@mccallum.corsepiu.local> References: <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> <20050504120933.GA25802@yoda.jdub.homelinux.org> <1115214205.4106.29.camel@localhost.localdomain> <20050504160126.4eae5087.bugs.michael@gmx.net> <1115215624.4106.31.camel@localhost.localdomain> <1115218265.24385.632.camel@mccallum.corsepiu.local> <1115218822.4106.43.camel@localhost.localdomain> <20050504152724.GA7220@jadzia.bu.edu> <1115222472.24385.676.camel@mccallum.corsepiu.local> Message-ID: <20050504185031.6fdbe6f2.bugs.michael@gmx.net> On Wed, 04 May 2005 18:01:12 +0200, Ralf Corsepius wrote: > As %{dist} currently is not provided by rpm-macros, I am using hard > coded {.fc3|.fc4} to enable users to be able to rebuild the rpms. Same here. If permitted, I use these dist tags for convenience, so that I don't have to do release number comparisons between multiple distribution versions -- doing that would not be a big issue either, though, but in some cases a packager needs to coordinate with Fedora Core, too (e.g. security updates for packages moved between Extras and Core and vice versa -- Sylpheed in my case). > Cluttering spec files with constructs like > %define fedora 3 > %{?!dist:%define dist .fc3} > and the like to me is simply beyond reason. Exactly. What's the purpose of defining something, which isn't used in the spec file? It's just a source of errors, if e.g. I copy a spec to an older distribution version and forget to adapt the constants. From bugs.michael at gmx.net Wed May 4 16:55:19 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 4 May 2005 18:55:19 +0200 Subject: make tag and %{?dist} In-Reply-To: <1115215721.4106.35.camel@localhost.localdomain> References: <1115171447.27280.38.camel@jdub.homelinux.org> <1115172043.5462.20.camel@ignacio.ignacio.lan> <1115173684.27280.55.camel@jdub.homelinux.org> <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> <20050504120933.GA25802@yoda.jdub.homelinux.org> <1115214205.4106.29.camel@localhost.localdomain> <1115215137.5462.43.camel@ignacio.ignacio.lan> <1115215721.4106.35.camel@localhost.localdomain> Message-ID: <20050504185519.0054c030.bugs.michael@gmx.net> On Wed, 04 May 2005 09:08:41 -0500, Tom 'spot' Callaway wrote: > On Wed, 2005-05-04 at 09:58 -0400, Ignacio Vazquez-Abrams wrote: > > On Wed, 2005-05-04 at 08:43 -0500, Tom 'spot' Callaway wrote: > > > In the spec, as the first two lines, you should put: > > > > > > %define dist .fc3 > > > %define fedora 3 > > > > What about: > > > > %{!?dist: %define dist .fc3 } > > %{!?fedora: %define fedora 3 } > > Nothing's defining %dist or %fedora in the buildsystem, so this is > unnecessary. What's the purpose of those macros then? Obviously, you cannot build the same src.rpm for multiple distribution versions without editing it. If, however, you used Ignacio's version, you could rpmbuild --define "fedora 4" --define "dist .fc4" and build the same src.rpm for FC4. Exactly *that* was one of the benefits of dist tags defined outside of the package and applied at build-time. If we need to edit the spec, we can as well do that in CVS prior to commit. From bugs.michael at gmx.net Wed May 4 17:08:06 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 4 May 2005 19:08:06 +0200 Subject: make tag and %{?dist} In-Reply-To: <20050504142010.GA4598@jadzia.bu.edu> References: <20050504024846.GA19087@jadzia.bu.edu> <1115176436.27280.69.camel@jdub.homelinux.org> <20050504032216.GA20031@jadzia.bu.edu> <1115178680.27280.91.camel@jdub.homelinux.org> <20050504102422.24f85598.bugs.michael@gmx.net> <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> <20050504120933.GA25802@yoda.jdub.homelinux.org> <1115214205.4106.29.camel@localhost.localdomain> <20050504160126.4eae5087.bugs.michael@gmx.net> <20050504142010.GA4598@jadzia.bu.edu> Message-ID: <20050504190806.1faa7af4.bugs.michael@gmx.net> On Wed, 4 May 2005 10:20:10 -0400, Matthew Miller wrote: > On Wed, May 04, 2005 at 04:01:26PM +0200, Michael Schwendt wrote: > > > Q: Can't I just hardcode the .fc3 into the Release? > > > A: No. > > An increasing number of packages do this already. There is > > no difference between hardcoding %dist or using a constant instead. > > In fact, I think using a constant is *better*. That way, the %dist macro can > be used to indicate "this should build on any currently-supported release" > and hard-coded values imply "there's some per-distro-release differences in > this spec file". Good point, actually. Using these macros pretends that the package supports multiple build platforms through a simple change of a few macro definitions. A package should not do that, if it was made for [and tested with] a specific distribution version only. Effectively, if a spec file doesn't access either %fedora or %rhel, it should not define them. And if it defines them, it should not override system-wide settings, such as predefined by redhat-rpm-config. From bugs.michael at gmx.net Wed May 4 17:22:26 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 4 May 2005 19:22:26 +0200 Subject: wxGTK build failure (was: Re: Package Build Report) In-Reply-To: <1115223123.4566.25.camel@bobcat.mine.nu> References: <1115222375.15831.84.camel@cutter> <1115223123.4566.25.camel@bobcat.mine.nu> Message-ID: <20050504192226.64804770.bugs.michael@gmx.net> > Rebuilding source rpm wxGTK-2.4.2-10.src.rpm At least "BuildRequires: libGL-devel" needed, depending on what else it tries to link, perhaps also "BuildRequires: libGLU-devel". From daniel-wittenberg at starken.com Wed May 4 18:16:51 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Wed, 04 May 2005 13:16:51 -0500 Subject: Review request: snort In-Reply-To: <20050504103121.57855b48.bugs.michael@gmx.net> References: <1115181733.12189.27.camel@plasma.starken.com> <1115183110.5462.30.camel@ignacio.ignacio.lan> <1115183816.12189.32.camel@plasma.starken.com> <1115184112.5462.32.camel@ignacio.ignacio.lan> <1115184643.12189.37.camel@plasma.starken.com> <20050504053453.GA16130@lisas.de> <1115185408.5462.34.camel@ignacio.ignacio.lan> <20050504103121.57855b48.bugs.michael@gmx.net> Message-ID: <1115230611.7136.7.camel@plasma.starken.com> initDir now replaced with _initdir. I also updated some other macros and building snort inline rpms now work too. http://www.starken.com/snort/snort.spec We'll be doing some more testing on the built RPM's but if those are good then we'll be ready for the full 2.4 release and maybe we can get it into extras at that time. Dan > > We actually use /etc/init.d as it is much more portable to other systems > > and is still compatible with RH/fedora. > > I still disagree with using /etc/init.d/, because that file is a symlink, > and the full path /etc/init.d/rc.d/ should appear in packages. > From mattdm at mattdm.org Wed May 4 18:17:57 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 4 May 2005 14:17:57 -0400 Subject: make tag and %{?dist} In-Reply-To: <1115222472.24385.676.camel@mccallum.corsepiu.local> References: <1115204740.27280.97.camel@jdub.homelinux.org> <20050504133257.54903ae3.bugs.michael@gmx.net> <20050504120933.GA25802@yoda.jdub.homelinux.org> <1115214205.4106.29.camel@localhost.localdomain> <20050504160126.4eae5087.bugs.michael@gmx.net> <1115215624.4106.31.camel@localhost.localdomain> <1115218265.24385.632.camel@mccallum.corsepiu.local> <1115218822.4106.43.camel@localhost.localdomain> <20050504152724.GA7220@jadzia.bu.edu> <1115222472.24385.676.camel@mccallum.corsepiu.local> Message-ID: <20050504181757.GA13771@jadzia.bu.edu> On Wed, May 04, 2005 at 06:01:12PM +0200, Ralf Corsepius wrote: > > But this doesn't need to be in the buildsystem that Seth is making at all. > > It just needs to be in the redhat-rpm-config macros. > Though I am opposed to this "macro magic" in general, this would be a > viable solution. It's not really any particularly special magic -- look at %perl-sitelib, or %requires_eq that are already in the macros file. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From mricon at gmail.com Wed May 4 20:00:14 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Wed, 4 May 2005 16:00:14 -0400 Subject: Try #3: Co-sponsor pylint. Message-ID: Hello again: I've had pylint packaged and ready to be imported, but the procedures dictate that I must find someone else to co-sponsor it before I can add it to extras. However, nobody seems to care enough to say "yeah, sure," even though I think it's a very useful package to provide in Extras. So, again: will anyone co-sponsor "pylint" with me? Please? PS: is anyone else following that "co-sponsor" rule? Sometimes I see packages just added, which makes me wonder... Regards, -- Konstantin Ryabitsev Zlotniks, INC From bdpepple at ameritech.net Wed May 4 20:17:38 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Wed, 04 May 2005 16:17:38 -0400 Subject: Try #3: Co-sponsor pylint. In-Reply-To: References: Message-ID: <1115237859.5541.3.camel@localhost.localdomain> On Wed, 2005-05-04 at 16:00 -0400, Konstantin Ryabitsev wrote: > Hello again: > > I've had pylint packaged and ready to be imported, but the procedures > dictate that I must find someone else to co-sponsor it before I can > add it to extras. However, nobody seems to care enough to say "yeah, > sure," even though I think it's a very useful package to provide in > Extras. > > So, again: will anyone co-sponsor "pylint" with me? Please? > > PS: is anyone else following that "co-sponsor" rule? Sometimes I see > packages just added, which makes me wonder... I'll be willing to co-sponsor your package. Give me a chance to look it over, and I'll send an official follow-up later this evening. /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 mricon at gmail.com Wed May 4 20:27:13 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Wed, 4 May 2005 16:27:13 -0400 Subject: Try #3: Co-sponsor pylint. In-Reply-To: <1115237859.5541.3.camel@localhost.localdomain> References: <1115237859.5541.3.camel@localhost.localdomain> Message-ID: On 5/4/05, Brian Pepple wrote: > I'll be willing to co-sponsor your package. Give me a chance to look it > over, and I'll send an official follow-up later this evening. http://phy.duke.edu/~icon/misc/fedora-extras/ Thanks! -- Konstantin Ryabitsev Zlotniks, INC From toshio at tiki-lounge.com Wed May 4 20:23:09 2005 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 04 May 2005 16:23:09 -0400 Subject: New package: cogito In-Reply-To: <20050504184146.005aae6d.bugs.michael@gmx.net> References: <20050503232939.GZ18917@shell0.pdx.osdl.net> <20050503233517.GA17380@redhat.com> <1115170095.27280.25.camel@jdub.homelinux.org> <20050504070034.A17520@tiki-lounge.com> <20050504184146.005aae6d.bugs.michael@gmx.net> Message-ID: <1115238190.303.34.camel@Madison.badger.com> On Wed, 2005-05-04 at 18:41 +0200, Michael Schwendt wrote: > > (On fedora.us there was > > unstable and testing.) > > ... and confused many users, since (1) no document explained the > philosophy behind a classification into stable/testing/unstable, (2) other > repositories use a different classification, (3) hardly any user who, runs > into problems with packages from "testing" or "unstable", would report a > bug, (4) repository mixing becomes even funnier, (5) inter-repository > dependencies (e.g. "livna") get more funny, too, (6) example yum config > files apparently suggested to enable all repositories by default, and (7) > an upgrade path from half-baked packages/software often is impracticable. > > > I'm not sure if the new testing repository is more > > like the Fedora Core Testing repo.... > > It is and should not be abused for overly experimental stuff. > I'll accept all this as for the good. But reiterate the part you snipped: there's all sorts of broken but actively developed, dependency-inducing software that people will want to package. There is not currently any policy of exclusion for such software. Unless that changes, at some point there has to be some policy of how to minimize breakage when including it. -Toshio -- toshio \ Questions for the Would Morticia wear it? @tiki- \ 21st Century! Would it look better on me? lounge.com=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From smooge at gmail.com Wed May 4 21:41:04 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 4 May 2005 15:41:04 -0600 Subject: Review request: snort In-Reply-To: <1115230611.7136.7.camel@plasma.starken.com> References: <1115181733.12189.27.camel@plasma.starken.com> <1115183110.5462.30.camel@ignacio.ignacio.lan> <1115183816.12189.32.camel@plasma.starken.com> <1115184112.5462.32.camel@ignacio.ignacio.lan> <1115184643.12189.37.camel@plasma.starken.com> <20050504053453.GA16130@lisas.de> <1115185408.5462.34.camel@ignacio.ignacio.lan> <20050504103121.57855b48.bugs.michael@gmx.net> <1115230611.7136.7.camel@plasma.starken.com> Message-ID: <80d7e40905050414414f46295@mail.gmail.com> On 5/4/05, Daniel Wittenberg wrote: > initDir now replaced with _initdir. I also updated some other macros > and building snort inline rpms now work too. > > http://www.starken.com/snort/snort.spec > > We'll be doing some more testing on the built RPM's but if those are > good then we'll be ready for the full 2.4 release and maybe we can get > it into extras at that time. > > Dan Ok a couple of questions: 1) setting %vendor might cause confusion with other organizations using this src.rpm 2) same with Packager. If I rebuild the RPM I am not the official builder for snort. 3) where it says plain, it should probably use the word base (more in line with other RPM packaging references) base Snort (this package, required) mysql Snort with mysql (optional) 4)this section looks like the %if needs to be further out. %package postgresql Summary: Snort with PostgreSQL support Group: Applications/Internet Requires: %{name} = %{version}-%{release} %if %{postgresql} BuildRequires: postgresql-devel %endif 5) Style point to be more inline with other rpms (or at least the ones I have been looking at this week). Move the main %description under the main package versus below the other sections. I am working through the logic of the rest.. but I know that using this spec file will build a 2.3.3 one (if you dont use --inline ;)). Hope this is useful. -- Stephen J Smoogen. CSIRT/Linux System Administrator From bdpepple at ameritech.net Wed May 4 22:01:56 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Wed, 04 May 2005 18:01:56 -0400 Subject: python-logilab-common In-Reply-To: References: <1115237859.5541.3.camel@localhost.localdomain> Message-ID: <1115244116.10004.6.camel@localhost.localdomain> On Wed, 2005-05-04 at 16:27 -0400, Konstantin Ryabitsev wrote: > On 5/4/05, Brian Pepple wrote: > > I'll be willing to co-sponsor your package. Give me a chance to look it > > over, and I'll send an official follow-up later this evening. > > http://phy.duke.edu/~icon/misc/fedora-extras/ MD5Sums: 27d1c71e5ff8eef0a5c2e957c80311cc python-logilab-common-0.9.3-2.src.rpm bfbe68606f2448b58836fb79b2582e71 common-0.9.3.tar.gz 2c658acf746a3d7c256ff949ced2449e python-logilab-common.spec Good: * Verified license - GPL. * Upstream source tarball verified * Package name conforms to the Fedora Naming Guidelines * All necessary BuildRequires listed. * Package rebuilds as non-root user * Rpmlint does not find problems Needs Work: One thing I noticed right off the bat with both of your specs, is that when you are removing files, your using $RPM_BUILD_ROOT/% {_python_sitelib} instead of $RPM_BUILD_ROOT%{_python_sitelib}. This should show up in your build logs as: + rm -rf /var/tmp/python-logilab-common-0.9.3-2-root- machbuild//usr/lib/python2.4/site-packages/logilab/common/test After this is corrected, the python-logilab-common package can be imported into CVS. /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 bdpepple at ameritech.net Thu May 5 00:11:25 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Wed, 04 May 2005 20:11:25 -0400 Subject: New Package: Gossip & Loudmouth In-Reply-To: <1114976827.25152.4.camel@localhost.localdomain> References: <1114976827.25152.4.camel@localhost.localdomain> Message-ID: <1115251885.11623.1.camel@localhost.localdomain> On Sun, 2005-05-01 at 19:47 +0000, Brian Pepple wrote: > Gossip: Gnome Jabber client. > http://piedmont.homelinux.org/fedora/gossip/gossip.spec > http://piedmont.homelinux.org/fedora/gossip/gossip-0.8-2.src.rpm > > Loudmouth: C library for programming with the Jabber protocol. > http://piedmont.homelinux.org/fedora/gossip/loudmouth.spec > http://piedmont.homelinux.org/fedora/gossip/loudmouth-0.17.2-1.src.rpm Anyone? /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazquez at ivazquez.net Thu May 5 02:05:00 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 04 May 2005 22:05:00 -0400 Subject: Review request: snort In-Reply-To: <80d7e40905050414414f46295@mail.gmail.com> References: <1115181733.12189.27.camel@plasma.starken.com> <1115183110.5462.30.camel@ignacio.ignacio.lan> <1115183816.12189.32.camel@plasma.starken.com> <1115184112.5462.32.camel@ignacio.ignacio.lan> <1115184643.12189.37.camel@plasma.starken.com> <20050504053453.GA16130@lisas.de> <1115185408.5462.34.camel@ignacio.ignacio.lan> <20050504103121.57855b48.bugs.michael@gmx.net> <1115230611.7136.7.camel@plasma.starken.com> <80d7e40905050414414f46295@mail.gmail.com> Message-ID: <1115258700.8685.2.camel@ignacio.ignacio.lan> On Wed, 2005-05-04 at 15:41 -0600, Stephen J. Smoogen wrote: > On 5/4/05, Daniel Wittenberg wrote: > > http://www.starken.com/snort/snort.spec > 4)this section looks like the %if needs to be further out. > > %package postgresql > Summary: Snort with PostgreSQL support > Group: Applications/Internet > Requires: %{name} = %{version}-%{release} > %if %{postgresql} > BuildRequires: postgresql-devel > %endif Actually, this is not a problem since there's also a %if around its % files section, and if a subpackage has no %files section then the subpackage doesn't get generated at all. As to whether it's acceptable style, that's a different issue. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From denis at poolshark.org Thu May 5 02:21:14 2005 From: denis at poolshark.org (Denis Leroy) Date: Wed, 04 May 2005 19:21:14 -0700 Subject: New Package: Gossip & Loudmouth In-Reply-To: <1115251885.11623.1.camel@localhost.localdomain> References: <1114976827.25152.4.camel@localhost.localdomain> <1115251885.11623.1.camel@localhost.localdomain> Message-ID: <4279831A.4000306@poolshark.org> Brian Pepple wrote: >On Sun, 2005-05-01 at 19:47 +0000, Brian Pepple wrote: > > >>Gossip: Gnome Jabber client. >>http://piedmont.homelinux.org/fedora/gossip/gossip.spec >>http://piedmont.homelinux.org/fedora/gossip/gossip-0.8-2.src.rpm >> >>Loudmouth: C library for programming with the Jabber protocol. >>http://piedmont.homelinux.org/fedora/gossip/loudmouth.spec >>http://piedmont.homelinux.org/fedora/gossip/loudmouth-0.17.2-1.src.rpm >> >> > >Anyone? > >/B > > Sure, i'll review it tonight. -denis From bdpepple at ameritech.net Thu May 5 03:51:42 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Wed, 04 May 2005 23:51:42 -0400 Subject: New Package: Gossip & Loudmouth In-Reply-To: <4279831A.4000306@poolshark.org> References: <1114976827.25152.4.camel@localhost.localdomain> <1115251885.11623.1.camel@localhost.localdomain> <4279831A.4000306@poolshark.org> Message-ID: <1115265102.12697.0.camel@localhost.localdomain> On Wed, 2005-05-04 at 19:21 -0700, Denis Leroy wrote: > > > Sure, i'll review it tonight. Thanks. /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 bdpepple at ameritech.net Thu May 5 04:38:10 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Thu, 05 May 2005 00:38:10 -0400 Subject: pylint In-Reply-To: References: <1115237859.5541.3.camel@localhost.localdomain> Message-ID: <1115267890.14655.2.camel@localhost.localdomain> On Wed, 2005-05-04 at 16:27 -0400, Konstantin Ryabitsev wrote: > On 5/4/05, Brian Pepple wrote: > > I'll be willing to co-sponsor your package. Give me a chance to look it > > over, and I'll send an official follow-up later this evening. > > http://phy.duke.edu/~icon/misc/fedora-extras/ MD5Sums: aad6743f6588aa424d520f93eaf5c465 pylint-0.6.4-2.src.rpm 7b15dc734ea91995256da22ad6a3aeb0 pylint-0.6.4.tar.gz 0febacb3982d351a6e6c9a28ce926f21 pylint.spec Good: * Verified license - GPL. * Upstream source tarball verified * Package name conforms to the Fedora Naming Guidelines * Group Tag is from the official list * Package rebuilds as non-root user Needs Work: * Rpmlint errors: remove zero-length file: /usr/share/doc/pylint-0.6.4/quickstart.html * Unnecessary BuildRequires: python-logilab-common * Unnecessary '/' between $RPM_BUILD_ROOT/%{_python_sitelib}. After these 3 items are fixed, pylint can be imported into CVS. /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 wtogami at redhat.com Thu May 5 05:34:32 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 04 May 2005 19:34:32 -1000 Subject: Try #3: Co-sponsor pylint. In-Reply-To: References: Message-ID: <4279B068.9030204@redhat.com> Konstantin Ryabitsev wrote: > Hello again: > > I've had pylint packaged and ready to be imported, but the procedures > dictate that I must find someone else to co-sponsor it before I can > add it to extras. However, nobody seems to care enough to say "yeah, > sure," even though I think it's a very useful package to provide in > Extras. > > So, again: will anyone co-sponsor "pylint" with me? Please? > > PS: is anyone else following that "co-sponsor" rule? Sometimes I see > packages just added, which makes me wonder... > > Regards, Please stop using the word "sponsor" when referring to packages. Any previous use of the word "sponsor" was done in error and continuing to do so only confuses the issue. Ask if anyone is willing to "approve" your package. Warren From denis at poolshark.org Thu May 5 06:01:44 2005 From: denis at poolshark.org (Denis Leroy) Date: Wed, 04 May 2005 23:01:44 -0700 Subject: New Package: Loudmouth In-Reply-To: <1115251885.11623.1.camel@localhost.localdomain> References: <1114976827.25152.4.camel@localhost.localdomain> <1115251885.11623.1.camel@localhost.localdomain> Message-ID: <4279B6C8.7090005@poolshark.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Pepple wrote: > On Sun, 2005-05-01 at 19:47 +0000, Brian Pepple wrote: > >> >>Loudmouth: C library for programming with the Jabber protocol. >>http://piedmont.homelinux.org/fedora/gossip/loudmouth.spec >>http://piedmont.homelinux.org/fedora/gossip/loudmouth-0.17.2-1.src.rpm > > > Anyone? Good: - - MD5sums: db5dd069f3c7de18d5347ebaaee4ad61 loudmouth-0.17.2.tar.bz2 ba8a10bc6c5f6034df7816cccfa96a63 loudmouth-0.17.2-1.src.rpm - - License is LGPL - - Upstream tarball verified - - Naming guidelines - - rpmlint ok Nitpicks: - - mach builds it for FC-devel, but on FC3 it compiles without SSL. It looks like it needs %if %{with_ssl} BuildRequires: libgcrypt-devel %endif - - replace %{_prefix}/include with %{_includedir} - - I noticed very few spec files in Extras include Requires(post): /sbin/ldconfig Requires(postun): /sbin/ldconfig Is it considered overkill ? Overall, i approve this package. - -denis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCebbHN21V2B2op6oRAqt7AJ9yy/ps1kC+PurhP7qddHyFi2MbWgCgir9w ByVDG7LuhFKP6TABoPtMcS0= =pcyM -----END PGP SIGNATURE----- From denis at poolshark.org Thu May 5 06:29:19 2005 From: denis at poolshark.org (Denis Leroy) Date: Wed, 04 May 2005 23:29:19 -0700 Subject: New Package: Gossip In-Reply-To: <1115251885.11623.1.camel@localhost.localdomain> References: <1114976827.25152.4.camel@localhost.localdomain> <1115251885.11623.1.camel@localhost.localdomain> Message-ID: <4279BD3F.8080204@poolshark.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Pepple wrote: > On Sun, 2005-05-01 at 19:47 +0000, Brian Pepple wrote: > >>Gossip: Gnome Jabber client. >>http://piedmont.homelinux.org/fedora/gossip/gossip.spec >>http://piedmont.homelinux.org/fedora/gossip/gossip-0.8-2.src.rpm OK: - - MD5sums a593dfc42055daf88f18aa85a5cfbb70 gossip-0.8-2.src.rpm 8bbe3dac8d0da7e0b936971a01545f14 gossip-0.8.tar.bz2 - - upstream tarball verified - - license is GPL - - packaging guidelines - - rpmlint ok Blockers: - - builds on FC3 but NOT on FC4t2. At first glance, it looks as though it can't compile against dbus 0.33 (while FC3 has dbus 0.22). - - /usr/share/gossip/ and /usr/share/gossip/protocols/ not owned by RPM. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCeb0/N21V2B2op6oRAi6WAJ98XSRwfum6v6dBF2YoOOeN4whdjwCeNiaT vKfclKuYczJ90UEyUldUD1s= =fO9O -----END PGP SIGNATURE----- From skvidal at phy.duke.edu Thu May 5 06:30:19 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 05 May 2005 02:30:19 -0400 Subject: Package Build Reports - Fedora Extras Development Message-ID: <1115274619.22456.14.camel@cutter> Package Build Errors: bazaar perl-Pod-Coverage gstreamer-python verbiste tla xfwm4 See: http://extras64.linux.duke.edu/failed/development/ for the logs. For successful builds see: http://extras64.linux.duke.edu/needsign/development/ More are building right now on all platforms. I caught a couple of additional bugs in the buildsystem and resolved them. If the rest of these build I'll ask Jeremy to open up 'make build' to others and we'll see if we can let it run on its own through the weekend. Thanks, -sv From rc040203 at freenet.de Thu May 5 06:51:22 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 05 May 2005 08:51:22 +0200 Subject: New Package: Loudmouth In-Reply-To: <4279B6C8.7090005@poolshark.org> References: <1114976827.25152.4.camel@localhost.localdomain> <1115251885.11623.1.camel@localhost.localdomain> <4279B6C8.7090005@poolshark.org> Message-ID: <1115275882.24385.691.camel@mccallum.corsepiu.local> On Wed, 2005-05-04 at 23:01 -0700, Denis Leroy wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Brian Pepple wrote: > > On Sun, 2005-05-01 at 19:47 +0000, Brian Pepple wrote: > > > >> > >>Loudmouth: C library for programming with the Jabber protocol. > >>http://piedmont.homelinux.org/fedora/gossip/loudmouth.spec > >>http://piedmont.homelinux.org/fedora/gossip/loudmouth-0.17.2-1.src.rpm > - - I noticed very few spec files in Extras include > Requires(post): /sbin/ldconfig > Requires(postun): /sbin/ldconfig > Is it considered overkill ? No, it's not overkill. It's just redundant if using %{post|postun} -p /sbin/ldconfig It's not redundant if not using "-p /sbin/ldconfig" in %post|postun etc. scriptlets. In any case it isn't wrong and also doesn't hurt. Ralf From skvidal at phy.duke.edu Thu May 5 06:59:19 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 05 May 2005 02:59:19 -0400 Subject: Package Build Report In-Reply-To: <20050504183202.73e99823@python2> References: <1115222375.15831.84.camel@cutter> <20050504183202.73e99823@python2> Message-ID: <1115276359.22456.39.camel@cutter> On Wed, 2005-05-04 at 18:32 +0200, Matthias Saou wrote: > seth vidal wrote : > > > Packages that failed to build on Fedora Development: > > [...] > > synergy > > [...] > > I think this one was a silly tag problem (I kept the same release the last > tag already had), so I now need to request a rebuild... can I already try > "tobuild"? :-) not yet. You'd need to run 'make build'. Right now Jeremy and I are the only folks who can run the command and have it succeed. If the rest of these builds finish tonight, I'll clear out the ones that finished from the wiki, do the make build on the fc3 items and ask jeremy to open it up. The only thing you'll have to be on the watch for is cvs conflicts when you run make build. That's something that will actually be a problem in the not-so-distant future. I was talking to Jeremy some about this and it seems he and I had a similar idea: use the .fedora.cert files to authenticate to an xml-rpc server and register the build request into a lightweight database. That's got finer granularity and it means tracking the progress of the build is easier than reloading a directory listing over and over again. :) I've got to spend some time on yum in the next week or so, so I won't have time to do that much with it right now but here's what it needs: - xml-rpc auth via ssl cert to a big pile of the right certs. - sqldb with fields: - cvs tag - cvs repo - distro target - username requesting build - timestamp (duh) - pkg name (would be nicer for output) - status it's actually not that much code and depending on the locking you might be able to get away with ultra-light-weight sqlite for the backend. Things that need to be done to the buildsystem: 1. new mach-yum release and some bug fixes. 2. timer on the cvs functions to make sure they don't stall out on the server connection 3. look at the nonblocking popen2 routine that menno pointed me to 4. log reports more sensibly 5. config files for everything - local path to stages dir - http url to stages dir - email address for the 'from' field. - email domain for the 'to' field. - dict of xmlrpc build servers - ssl certificate location/paths. That's all I have on my short-list for now. -sv From skvidal at phy.duke.edu Thu May 5 07:07:17 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 05 May 2005 03:07:17 -0400 Subject: buildsystem stuff In-Reply-To: <20050504130715.51f466c7@python2> References: <1115181658.15831.45.camel@cutter> <20050504130715.51f466c7@python2> Message-ID: <1115276838.22456.48.camel@cutter> > I've got two questions : > - Have your last tobuild tests worked alright? Is this ready to use? the last 30 or so packages have built correctly. I've seen a couple of deadlocks on *something* when doing cvs co of the tag and I think I just need a simple timer on the popen call to watch for hung things. I already have a timer on the build calls. > - How do the resulting packages show up in the Extras tree? There's another script I run when I sign the packages that moves things around. The signing script HAS to be done by _someone_ b/c, well, they have to sign them. > That second point is the most important, I guess, as we might want to > review binary packages after they're built "just in case". Adding a stage like 'NEEDSQA' wouldn't be very hard. It would just mean moving a package that successfully built from 'active' into a different dir and notifying the right places of the event. > Next, the signing stage should probably stay "manual", eventually when that review > occurs, and just before the packages go out to the public tree? Last, how > do the old packages get cleaned out? Well, I've been using repomanage.py -o /path/to/repo | xargs rm -f, But I know that Notting wants to use something that keeps around older versions for about 28 days before deleting them. So, in short, that does it. > For this last question, here's the solution I've been using myself for > years : I have my main tree (it could be a private one in this case) which > is organized as "//" in which I > remove all files in "" when a new package of "package > name" is built, then I add all the new files. I then run a mass clean-out, > followed by hard-linking of all those sub-dirs in the repository-enabled > tree. This makes me avoid complicated version comparisons and such, and > takes care of the corner cases such as when the new packages no longer > include a given sub-package. Take a look at how 'repomanage' works. The only difficulty is, of course, that sometimes you don't want the newest package to be the 'released' package. I thought of adding two flags to createrepo to make this stuff simpler: --includefrom and --excludefrom. They would each take a list of rpms. So you could run repomanage -n /path/to/repo > includefile. Then pass that to createrepo and it would only index the packages in the includefile and only include those in the repository. Then you wouldn't have to remove anything but you'd only be showing the newest versions to the world. If you've not seen repomanage go to: http://linux.duke.edu/yum/download/misc/ I'm certain that will also be available in the yum-utils package that Gijs has been working on. Lots of completely cool stuff in yum-utils now. -sv From j.w.r.degoede at hhs.nl Thu May 5 09:02:35 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 05 May 2005 11:02:35 +0200 Subject: Imported to CVS, review requested: Glide3 In-Reply-To: <20050504182248.6480b81f@python2> References: <42712EA1.2050401@hhs.nl> <20050429120923.0fd0a318@python2> <42735CC8.60208@hhs.nl> <20050503020541.5046d453@python2> <4278E74D.1090201@hhs.nl> <20050504182248.6480b81f@python2> Message-ID: <4279E12B.4060204@hhs.nl> Yeah, I already meant to take this off list but didn't look where my mail was going. I'll get back to you personally once I've got this fixed. Anyone who is interested in where this is going send me mail and I'll keeo this on the list. Regards, Hans Matthias Saou wrote: > Hans de Goede wrote : > > >>>Still fails for me on FC 3 x86_64 :-/ (my Devel root is trashed ATM) >> >>Thanks for testing and reporting, this should be fixed in CVS now a >>Fedora-devel build would also be nice / better since gcc4 is more picky >>then 3.4 > > > Just tried a rebuild on FC Devel x86_64 with the changes you just > committed to CVS and get this : > > [...] > gcc -DX11 -fomit-frame-pointer -funroll-loops -fexpensive-optimizations - > ffast-math -DBIG_OPT -Wall -DGLIDE_LIB -DGLIDE3 -DGLIDE3_ALPHA -DH3 - > DGLIDE_PACKET3_TRI_SETUP=1 -DUSE_PACKET_FIFO=1 - > DGLIDE_HW_TRI_SETUP=1 -DFX_GLIDE_NAPALM=1 - > DFX_GLIDE_H5_CSIM=1 -DGLIDE_PLUG -DGLIDE_SPLASH -DFX_STATIC_BUILD - > DGLIDE_INIT_HWC -DGLIDE_USE_C_TRISETUP -I../../../../h5/glide3/src - > I../../../h5/incsrc -I../../../../h5/incsrc -I../../../../h5/minihwc -I. - > I../../../../swlibs/fxmemmap -I../../../../swlibs/fxmisc -I../../../../ > swlibs/newpci/pcilib -I../../../../swlibs/texus2/lib -O2 -g - > pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona -O6 -Wno- > unknown-pragmas -Wno-unused-value -Wno-unused -c ../../../../h5/ > glide3/src/fxgasm.c ../../../../h5/glide3/src/fxgasm.c: In function > 'main': ../../../../h5/glide3/src/fxgasm.c:102: warning: format '%X' > expects type 'unsigned int', but argument 3 has type 'long unsigned > int' ../../../../h5/glide3/src/fxgasm.c:106: warning: format '%X' expects > type 'unsigned int', but argument 3 has type 'long unsigned > int' ../../../../h5/glide3/src/fxgasm.c:109: warning: format '%X' expects > type 'unsigned int', but argument 3 has type 'long unsigned > int' ../../../../h5/glide3/src/fxgasm.c:112: warning: format '%x' expects > type 'unsigned int', but argument 3 has type 'long unsigned > int' ../../../../h5/glide3/src/fxgasm.c:216: error: 'struct _GlideRoot_s' > has no member named 'CPUType' ../../../../h5/glide3/src/fxgasm.c:216: > error: 'struct _GlideRoot_s' has no member named 'CPUType' ../../../../h5/ > glide3/src/fxgasm.c:220: warning: format '%08x' expects type 'unsigned > int', but argument 4 has type 'long unsigned int' ../../../../h5/glide3/ > src/fxgasm.c:220: warning: format '%10d' expects type 'int', but argument > 4 has type 'long unsigned int' ../../../../h5/glide3/src/fxgasm.c:221: > warning: format '%08x' expects type 'unsigned int', but argument 4 has > type 'long unsigned int' ../../../../h5/glide3/src/fxgasm.c:221: warning: > format '%10d' expects type 'int', but argument 4 has type 'long unsigned > int' ../../../../h5/glide3/src/fxgasm.c:230: warning: format '%08x' > expects type 'unsigned int', but argument 4 has type 'long unsigned > int' ../../../../h5/glide3/src/fxgasm.c:230: warning: format '%10d' > expects type 'int', but argument 4 has type 'long unsigned int' make[3]: > *** [fxgasm.o] Error 1 make[3]: Leaving directory `/usr/src/rpm/BUILD/ > Glide3/build-5/h5/glide3/src' > > I get the exact same error on FC3 FWIW. If you want me to test some > further changes before you check them into CVS, and to not bother this > list too much, we can take this off-list. > > Matthias > From j.w.r.degoede at hhs.nl Thu May 5 09:11:35 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 05 May 2005 11:11:35 +0200 Subject: Imported to CVS, review requested: Glide3 In-Reply-To: <20050504182248.6480b81f@python2> References: <42712EA1.2050401@hhs.nl> <20050429120923.0fd0a318@python2> <42735CC8.60208@hhs.nl> <20050503020541.5046d453@python2> <4278E74D.1090201@hhs.nl> <20050504182248.6480b81f@python2> Message-ID: <4279E347.6020500@hhs.nl> 1) Could you reply to me directly to take this of list with a valid reply to I'm not getting through your spam protection thias is not in the virtuser table of freshrpms.net . 2) Any chance you could set me up with a shell account on an x86_64 box that might speed the process up a bit. Thanks & Regards, Hans Matthias Saou wrote: > Hans de Goede wrote : > > >>>Still fails for me on FC 3 x86_64 :-/ (my Devel root is trashed ATM) >> >>Thanks for testing and reporting, this should be fixed in CVS now a >>Fedora-devel build would also be nice / better since gcc4 is more picky >>then 3.4 > > > Just tried a rebuild on FC Devel x86_64 with the changes you just > committed to CVS and get this : > > [...] > gcc -DX11 -fomit-frame-pointer -funroll-loops -fexpensive-optimizations - > ffast-math -DBIG_OPT -Wall -DGLIDE_LIB -DGLIDE3 -DGLIDE3_ALPHA -DH3 - > DGLIDE_PACKET3_TRI_SETUP=1 -DUSE_PACKET_FIFO=1 - > DGLIDE_HW_TRI_SETUP=1 -DFX_GLIDE_NAPALM=1 - > DFX_GLIDE_H5_CSIM=1 -DGLIDE_PLUG -DGLIDE_SPLASH -DFX_STATIC_BUILD - > DGLIDE_INIT_HWC -DGLIDE_USE_C_TRISETUP -I../../../../h5/glide3/src - > I../../../h5/incsrc -I../../../../h5/incsrc -I../../../../h5/minihwc -I. - > I../../../../swlibs/fxmemmap -I../../../../swlibs/fxmisc -I../../../../ > swlibs/newpci/pcilib -I../../../../swlibs/texus2/lib -O2 -g - > pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona -O6 -Wno- > unknown-pragmas -Wno-unused-value -Wno-unused -c ../../../../h5/ > glide3/src/fxgasm.c ../../../../h5/glide3/src/fxgasm.c: In function > 'main': ../../../../h5/glide3/src/fxgasm.c:102: warning: format '%X' > expects type 'unsigned int', but argument 3 has type 'long unsigned > int' ../../../../h5/glide3/src/fxgasm.c:106: warning: format '%X' expects > type 'unsigned int', but argument 3 has type 'long unsigned > int' ../../../../h5/glide3/src/fxgasm.c:109: warning: format '%X' expects > type 'unsigned int', but argument 3 has type 'long unsigned > int' ../../../../h5/glide3/src/fxgasm.c:112: warning: format '%x' expects > type 'unsigned int', but argument 3 has type 'long unsigned > int' ../../../../h5/glide3/src/fxgasm.c:216: error: 'struct _GlideRoot_s' > has no member named 'CPUType' ../../../../h5/glide3/src/fxgasm.c:216: > error: 'struct _GlideRoot_s' has no member named 'CPUType' ../../../../h5/ > glide3/src/fxgasm.c:220: warning: format '%08x' expects type 'unsigned > int', but argument 4 has type 'long unsigned int' ../../../../h5/glide3/ > src/fxgasm.c:220: warning: format '%10d' expects type 'int', but argument > 4 has type 'long unsigned int' ../../../../h5/glide3/src/fxgasm.c:221: > warning: format '%08x' expects type 'unsigned int', but argument 4 has > type 'long unsigned int' ../../../../h5/glide3/src/fxgasm.c:221: warning: > format '%10d' expects type 'int', but argument 4 has type 'long unsigned > int' ../../../../h5/glide3/src/fxgasm.c:230: warning: format '%08x' > expects type 'unsigned int', but argument 4 has type 'long unsigned > int' ../../../../h5/glide3/src/fxgasm.c:230: warning: format '%10d' > expects type 'int', but argument 4 has type 'long unsigned int' make[3]: > *** [fxgasm.o] Error 1 make[3]: Leaving directory `/usr/src/rpm/BUILD/ > Glide3/build-5/h5/glide3/src' > > I get the exact same error on FC3 FWIW. If you want me to test some > further changes before you check them into CVS, and to not bother this > list too much, we can take this off-list. > > Matthias > From j.w.r.degoede at hhs.nl Thu May 5 09:45:22 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 05 May 2005 11:45:22 +0200 Subject: Imported to CVS, review requested: Glide3 In-Reply-To: <20050504182248.6480b81f@python2> References: <42712EA1.2050401@hhs.nl> <20050429120923.0fd0a318@python2> <42735CC8.60208@hhs.nl> <20050503020541.5046d453@python2> <4278E74D.1090201@hhs.nl> <20050504182248.6480b81f@python2> Message-ID: <4279EB32.1070206@hhs.nl> This too should be fixed in CVS, I should have caught this one yesterday. anyways please try again I hope this as the last one. Regards, Hans Matthias Saou wrote: > Hans de Goede wrote : > > >>>Still fails for me on FC 3 x86_64 :-/ (my Devel root is trashed ATM) >> >>Thanks for testing and reporting, this should be fixed in CVS now a >>Fedora-devel build would also be nice / better since gcc4 is more picky >>then 3.4 > > > Just tried a rebuild on FC Devel x86_64 with the changes you just > committed to CVS and get this : > > [...] > gcc -DX11 -fomit-frame-pointer -funroll-loops -fexpensive-optimizations - > ffast-math -DBIG_OPT -Wall -DGLIDE_LIB -DGLIDE3 -DGLIDE3_ALPHA -DH3 - > DGLIDE_PACKET3_TRI_SETUP=1 -DUSE_PACKET_FIFO=1 - > DGLIDE_HW_TRI_SETUP=1 -DFX_GLIDE_NAPALM=1 - > DFX_GLIDE_H5_CSIM=1 -DGLIDE_PLUG -DGLIDE_SPLASH -DFX_STATIC_BUILD - > DGLIDE_INIT_HWC -DGLIDE_USE_C_TRISETUP -I../../../../h5/glide3/src - > I../../../h5/incsrc -I../../../../h5/incsrc -I../../../../h5/minihwc -I. - > I../../../../swlibs/fxmemmap -I../../../../swlibs/fxmisc -I../../../../ > swlibs/newpci/pcilib -I../../../../swlibs/texus2/lib -O2 -g - > pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona -O6 -Wno- > unknown-pragmas -Wno-unused-value -Wno-unused -c ../../../../h5/ > glide3/src/fxgasm.c ../../../../h5/glide3/src/fxgasm.c: In function > 'main': ../../../../h5/glide3/src/fxgasm.c:102: warning: format '%X' > expects type 'unsigned int', but argument 3 has type 'long unsigned > int' ../../../../h5/glide3/src/fxgasm.c:106: warning: format '%X' expects > type 'unsigned int', but argument 3 has type 'long unsigned > int' ../../../../h5/glide3/src/fxgasm.c:109: warning: format '%X' expects > type 'unsigned int', but argument 3 has type 'long unsigned > int' ../../../../h5/glide3/src/fxgasm.c:112: warning: format '%x' expects > type 'unsigned int', but argument 3 has type 'long unsigned > int' ../../../../h5/glide3/src/fxgasm.c:216: error: 'struct _GlideRoot_s' > has no member named 'CPUType' ../../../../h5/glide3/src/fxgasm.c:216: > error: 'struct _GlideRoot_s' has no member named 'CPUType' ../../../../h5/ > glide3/src/fxgasm.c:220: warning: format '%08x' expects type 'unsigned > int', but argument 4 has type 'long unsigned int' ../../../../h5/glide3/ > src/fxgasm.c:220: warning: format '%10d' expects type 'int', but argument > 4 has type 'long unsigned int' ../../../../h5/glide3/src/fxgasm.c:221: > warning: format '%08x' expects type 'unsigned int', but argument 4 has > type 'long unsigned int' ../../../../h5/glide3/src/fxgasm.c:221: warning: > format '%10d' expects type 'int', but argument 4 has type 'long unsigned > int' ../../../../h5/glide3/src/fxgasm.c:230: warning: format '%08x' > expects type 'unsigned int', but argument 4 has type 'long unsigned > int' ../../../../h5/glide3/src/fxgasm.c:230: warning: format '%10d' > expects type 'int', but argument 4 has type 'long unsigned int' make[3]: > *** [fxgasm.o] Error 1 make[3]: Leaving directory `/usr/src/rpm/BUILD/ > Glide3/build-5/h5/glide3/src' > > I get the exact same error on FC3 FWIW. If you want me to test some > further changes before you check them into CVS, and to not bother this > list too much, we can take this off-list. > > Matthias > From mfleming at enlartenment.com Thu May 5 11:18:14 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Thu, 5 May 2005 21:18:14 +1000 Subject: Review request: mlmmj 1.2.5 Message-ID: <20050505211814.09c96e8e.mfleming@enlartenment.com> Hi Folks, I've imported a current stable release of mlmmj (Mailing Lists Made Joyful) 1.2.5. A version can be checked out of the CVS -devel branch for the brave, or the complete contents & source RPM can be found at http://www.enlartenment.com/extras/ For those who looked over the last version: - I've dropped the large listtext patch from my last version as it was accepted upstream (for which I'm thankful :-)) - The new version also implements the "listname+list at domain.tld" command to get the list of subscribers. Reading the README* files is of course highly recommended. - This version works nicely with Sendmail now too, due to the Gentoo project using it for their lists (See README.sendmail for sendmail config info) Comments and corrections/pointers welcome, Cheers. Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From mihamina.rakotomandimby at etu.univ-orleans.fr Thu May 5 12:00:35 2005 From: mihamina.rakotomandimby at etu.univ-orleans.fr (Rakotomandimby (R12y) Mihamina) Date: Thu, 05 May 2005 14:00:35 +0200 Subject: Maintaining some packages Message-ID: <1115294435.15638.5.camel@fctmp> Hi, I'm learning Ocaml at school, and i was looking for findlib (providing ocamlfind/ocamlfind-mini) rpm for Fedora Core 3 (I'm running it for the moment). I did not find. The only things I found was some src.rpms from the altlinux distribution. I made then my src.rpms from theirs. The src.rpms are: pcre-ocaml, findlib, ocamlnet. I would like them to be integrated to "Extras", and would like to maintain them. I looked at the process for beeing maintainer, and did not find the step-by-step way. The only page I found is: http://www.fedoraproject.org/wiki/Extras So... What is the (step by step?) way of work to submit src.rpms to the "Extra"? Thak you guys :-) -- Get a fully managed dedicated server for ?200/month ($257/month) No time limit for taking care of your server. You keep the "root" acces if you want. Billing periods are 3 months. See the conditions at http://aspo.rktmb.org/activities/managed_servers From skvidal at phy.duke.edu Thu May 5 12:35:48 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 05 May 2005 08:35:48 -0400 Subject: Package Build Report - Fedora Extras Development Message-ID: <1115296548.24970.11.camel@cutter> The following packages failed to build on Fedora Extras Development: cone librx perl-OLE-Storage_Lite blacs scalapack R-RScaLAPACK uudeview qemu cdo gconfmm26 libgnomeuimm26 inkscape Coin2 csmash See: http://extras64.linux.duke.edu/failed/development/ for logs. Successful builds: http://extras64.linux.duke.edu/needsign/development/ Packages are still building. -sv From bdpepple at ameritech.net Thu May 5 13:43:17 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Thu, 05 May 2005 09:43:17 -0400 Subject: New Package: Loudmouth In-Reply-To: <4279B6C8.7090005@poolshark.org> References: <1114976827.25152.4.camel@localhost.localdomain> <1115251885.11623.1.camel@localhost.localdomain> <4279B6C8.7090005@poolshark.org> Message-ID: <1115300598.5676.1.camel@localhost.localdomain> On Wed, 2005-05-04 at 23:01 -0700, Denis Leroy wrote: > Nitpicks: > > - - mach builds it for FC-devel, but on FC3 it compiles without SSL. It > looks like it needs > > %if %{with_ssl} > BuildRequires: libgcrypt-devel > %endif > > - - replace %{_prefix}/include with %{_includedir} Changes made, and I'll now import this into CVS. Thanks, /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 Thu May 5 13:39:42 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 05 May 2005 15:39:42 +0200 Subject: Package Build Report - Fedora Extras Development In-Reply-To: <1115296548.24970.11.camel@cutter> References: <1115296548.24970.11.camel@cutter> Message-ID: <1115300382.5804.14.camel@notebook.thl.home> Am Donnerstag, den 05.05.2005, 08:35 -0400 schrieb seth vidal: > The following packages failed to build on Fedora Extras Development: > [...] > Coin2 > [...] > See: http://extras64.linux.duke.edu/failed/development/ > for logs. Seth, on x86_64 the buildsystem/mach/yum installs the 32-bit version of libGLU (xorg-x11-Mesa-libGLU-6.8.2-1.FC3.13.i386) and not the 64bit- version (xorg-x11-Mesa-libGLU-6.8.2-1.FC3.13.x86_64) for the "BuildRequire libGLU.so.1". The build fails due to that. I wanted to look into this already known problem but did not find the time/it got lost. Sorry for that. So, how do we fix that? I'm a bit unsure. I suppose (but did not try) that the build system would install the x86_64 Version if we would BuildRequires: libGLU >= 1 as suggested by mharris in https://www.redhat.com/archives/fedora-maintainers/2005-March/msg00128.html But this only works in devel :-( Another way to fix maybe would be to do a %ifarch x86_64 BuildRequires: libGLU.so.1()((64bit) %else BuildRequires: libGLU.so.1 %endif (was suggested my Michael Schwendt iirc). Also untested and imho ugly. Or do you consider it as a buildsystem/yum bug? Shall I file a bugreport? Why does this problem only show up with this package (or are there others I missed?). -- Thorsten Leemhuis From bugs.michael at gmx.net Thu May 5 14:30:59 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 5 May 2005 16:30:59 +0200 Subject: Maintaining some packages In-Reply-To: <1115294435.15638.5.camel@fctmp> References: <1115294435.15638.5.camel@fctmp> Message-ID: <20050505163059.38145bdd.bugs.michael@gmx.net> On Thu, 05 May 2005 14:00:35 +0200, Rakotomandimby (R12y) Mihamina wrote: > Hi, > > I'm learning Ocaml at school, and i was looking for findlib (providing > ocamlfind/ocamlfind-mini) rpm for Fedora Core 3 (I'm running it for the > moment). I did not find. > The only things I found was some src.rpms from the altlinux > distribution. > I made then my src.rpms from theirs. The src.rpms are: > pcre-ocaml, findlib, ocamlnet. > I would like them to be integrated to "Extras", and would like to > maintain them. I looked at the process for beeing maintainer, and did > not find the step-by-step way. The only page I found is: > http://www.fedoraproject.org/wiki/Extras Help me understand what your problem with that page is. > So... What is the (step by step?) way of work to submit src.rpms to the > "Extra"? It's on the page, isn't it? From tcallawa at redhat.com Thu May 5 14:57:24 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 05 May 2005 09:57:24 -0500 Subject: Package Build Report - Fedora Extras Development In-Reply-To: <1115296548.24970.11.camel@cutter> References: <1115296548.24970.11.camel@cutter> Message-ID: <1115305044.4106.103.camel@localhost.localdomain> On Thu, 2005-05-05 at 08:35 -0400, seth vidal wrote: > The following packages failed to build on Fedora Extras Development: > librx Fixed, was missing BuildRequires: texinfo, both FC-3 and devel branch re-tagged. > perl-OLE-Storage_Lite I can't figure out why this failed from the log. > blacs Fixed, both FC-3 and devel branch re-tagged. > scalapack > R-RScaLAPACK Both failed because blacs failed. R-gnomeGUI is also on your website as failed, but the logs don't indicate whether it really failed or not (or if it did, why). ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From kevin-fedora-extras at scrye.com Thu May 5 15:39:00 2005 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Thu, 5 May 2005 09:39:00 -0600 Subject: Package Build Reports - Fedora Extras Development References: <1115274619.22456.14.camel@cutter> Message-ID: <20050505153904.26F2B454362@ningauble.scrye.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "seth" == seth vidal writes: seth> Package Build Errors: seth> ... seth> xfwm4 seth> See: http://extras64.linux.duke.edu/failed/development/ for the seth> logs. Looks like the problem was that it failed on ppc in requirements: libxfce4mcs-devel >= 4.2.1 is needed by xfwm4-4.2.1-5.fc4.ppc libxfcegui4-devel >= 4.2.1 is needed by xfwm4-4.2.1-5.fc4.ppc xfce-mcs-manager-devel >= 4.2.1 is needed by xfwm4-4.2.1-5.fc4.ppc All the other Xfce packages were not built on ppc, so it doesn't have the requirements. I have no idea if the packages do build correctly on ppc (not having a ppc test machine around), but it would be cool if they did. ;) So, should I wait and request builds of the other Xfce packages on ppc? Or is there some way to just request i386/x86_64 builds with the new build setup? The build system looks really cool... thanks for the great work you guys have put in on it! kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 iD8DBQFCej4X3imCezTjY0ERAti2AJ40vZyr2/1HEINEOs8BrMnn73G0egCdG8Tr UhA13Z3Giwrc5MZK5HCq41c= =MIEN -----END PGP SIGNATURE----- From rc040203 at freenet.de Thu May 5 15:39:03 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 05 May 2005 17:39:03 +0200 Subject: Package Build Report - Fedora Extras Development In-Reply-To: <1115300382.5804.14.camel@notebook.thl.home> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> Message-ID: <1115307543.24385.698.camel@mccallum.corsepiu.local> On Thu, 2005-05-05 at 15:39 +0200, Thorsten Leemhuis wrote: > Am Donnerstag, den 05.05.2005, 08:35 -0400 schrieb seth vidal: > > The following packages failed to build on Fedora Extras Development: > > [...] > > Coin2 > > [...] > > See: http://extras64.linux.duke.edu/failed/development/ > > for logs. > > Seth, on x86_64 the buildsystem/mach/yum installs the 32-bit version of > libGLU (xorg-x11-Mesa-libGLU-6.8.2-1.FC3.13.i386) and not the 64bit- > version (xorg-x11-Mesa-libGLU-6.8.2-1.FC3.13.x86_64) for the > "BuildRequire libGLU.so.1". The build fails due to that. I wanted to > look into this already known problem but did not find the time/it got > lost. Sorry for that. > > So, how do we fix that? By Seth fixing his build system. > I'm a bit unsure. I suppose (but did not try) > that the build system would install the x86_64 Version if we would > > BuildRequires: libGLU >= 1 > > as suggested by mharris in > https://www.redhat.com/archives/fedora-maintainers/2005-March/msg00128.html > But this only works in devel :-( > > Another way to fix maybe would be to do a > > %ifarch x86_64 > BuildRequires: libGLU.so.1()((64bit) > %else > BuildRequires: libGLU.so.1 > %endif Sorry, but that's nuts - rpm must handle this case by itself. > (was suggested my Michael Schwendt iirc). Also untested and imho ugly. > > Or do you consider it as a buildsystem/yum bug? Well I am not sure, as I don't have access to i68_64 systems. What does rpm -qf /usr/lib/libGLU.so and rpm -qf /usr/lib64/libGLU.so say, rsp. what does "rpm -q --whatprovides libGLU.so" with a both versions of libGLU.so installed report? > Why does this problem only show up with this package (or are > there others I missed?). Many possibilities. Ralf From ed at eh3.com Thu May 5 15:40:56 2005 From: ed at eh3.com (Ed Hill) Date: Thu, 05 May 2005 11:40:56 -0400 Subject: Package Build Report - Fedora Extras Development In-Reply-To: <1115305044.4106.103.camel@localhost.localdomain> References: <1115296548.24970.11.camel@cutter> <1115305044.4106.103.camel@localhost.localdomain> Message-ID: <1115307657.12158.18.camel@ernie> On Thu, 2005-05-05 at 09:57 -0500, Tom 'spot' Callaway wrote: > On Thu, 2005-05-05 at 08:35 -0400, seth vidal wrote: > > The following packages failed to build on Fedora Extras Development: Hi Seth, First, many thanks for all the work that you've been doing on builds and the build system. The cdo package failed to build because it failed to get a dependency on the ppc architecture: http://extras64.linux.duke.edu/failed/development/cdo/0.9.6-2/ppc/ "Building source rpm cdo-0.9.6-2.src.rpm Installing BuildRequires .../ERROR: BuildRequires not met: error: Failed build dependencies: netcdf-devel is needed by cdo-0.9.6-2.ppc" So, how am I (or we) supposed to fix this dependency? Someone please help me! ;-) 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu May 5 15:49:42 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 5 May 2005 17:49:42 +0200 Subject: Package Build Report - Fedora Extras Development In-Reply-To: <1115300382.5804.14.camel@notebook.thl.home> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> Message-ID: <20050505174942.1707e8ca@python2> Thorsten Leemhuis wrote : > Seth, on x86_64 the buildsystem/mach/yum installs the 32-bit version of > libGLU (xorg-x11-Mesa-libGLU-6.8.2-1.FC3.13.i386) and not the 64bit- > version (xorg-x11-Mesa-libGLU-6.8.2-1.FC3.13.x86_64) for the > "BuildRequire libGLU.so.1". The build fails due to that. I wanted to > look into this already known problem but did not find the time/it got > lost. Sorry for that. > > So, how do we fix that? [...] My opinion would be to only have x86_64 and noarch packages available for the x86_64 build root, and no let any i?86 packages be available to it, since it makes no sense anyway for a build root. I've already bumped into this problem myself, and my solution has been to create a "static" RPMS directory with all i?86.rpm packages removed and createrepo re-run on top of that. The cleaner fix would be to disable multiarch support in the yum used for the x86_64 build root, but I don't think that's possible with the current yum (seth will know for sure ;-)). Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.20_FC3 Load : 1.03 1.74 1.54 From katzj at redhat.com Thu May 5 16:04:43 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 05 May 2005 12:04:43 -0400 Subject: buildsystem stuff In-Reply-To: <1115300266.16211.19.camel@dcbw.boston.redhat.com> References: <1115181658.15831.45.camel@cutter> <1115300266.16211.19.camel@dcbw.boston.redhat.com> Message-ID: <1115309084.16366.70.camel@bree.local.net> On Thu, 2005-05-05 at 09:37 -0400, Dan Williams wrote: > A couple of comments, some of which I'd even be willing to do the work > for :) > > 1) CVS/tobuild - Could this code be separated into an XML-RPC client? > So you'd have the Queuer be an XMLRPC server, and clients would connect > to it and feed it build jobs. For Aurora at least, we're probably not > going to have CVS of this type, and "tobuild" seems somewhat cumbersome. This was definitely intended as the eventual direction. But we wanted to get something going quickly, and write a file was far simpler. :-) Especially since at first, there wasn't going to be the need for XML-RPC -- that came later as a need for kicking off the ppc builds. Any help down this path would definitely be appreciated, otherwise it's at least on my todo list. The key is to keep the client as simple as possible so that we don't have a big list of deps like you end up with for the beehive client. Basic python + included modules should be fairly sane, though. And using the client certs for the fedora account system stuff seems like the obvious auth mechanism then. Jeremy From bugs.michael at gmx.net Thu May 5 16:15:22 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 5 May 2005 18:15:22 +0200 Subject: Package Build Report - Fedora Extras Development In-Reply-To: <1115307543.24385.698.camel@mccallum.corsepiu.local> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> <1115307543.24385.698.camel@mccallum.corsepiu.local> Message-ID: <20050505181522.30e74d4c.bugs.michael@gmx.net> On Thu, 05 May 2005 17:39:03 +0200, Ralf Corsepius wrote: > On Thu, 2005-05-05 at 15:39 +0200, Thorsten Leemhuis wrote: > > Am Donnerstag, den 05.05.2005, 08:35 -0400 schrieb seth vidal: > > > The following packages failed to build on Fedora Extras Development: > > > [...] > > > Coin2 > > > [...] > > > See: http://extras64.linux.duke.edu/failed/development/ > > > for logs. > > > > Seth, on x86_64 the buildsystem/mach/yum installs the 32-bit version of > > libGLU (xorg-x11-Mesa-libGLU-6.8.2-1.FC3.13.i386) and not the 64bit- > > version (xorg-x11-Mesa-libGLU-6.8.2-1.FC3.13.x86_64) for the > > "BuildRequire libGLU.so.1". The build fails due to that. I wanted to > > look into this already known problem but did not find the time/it got > > lost. Sorry for that. > > > > So, how do we fix that? > By Seth fixing his build system. > > > I'm a bit unsure. I suppose (but did not try) > > that the build system would install the x86_64 Version if we would > > > > BuildRequires: libGLU >= 1 > > > > as suggested by mharris in > > https://www.redhat.com/archives/fedora-maintainers/2005-March/msg00128.html > > But this only works in devel :-( > > > > Another way to fix maybe would be to do a > > > > %ifarch x86_64 > > BuildRequires: libGLU.so.1()((64bit) > > %else > > BuildRequires: libGLU.so.1 > > %endif > Sorry, but that's nuts - rpm must handle this case by itself. Sure it's nuts, but a temporary (!) work-around I could think of. Both libGLU.so.1()(64bit) and libGL.so.1()(64bit) virtual provides do exist. > > (was suggested my Michael Schwendt iirc). Also untested and imho ugly. > > > > Or do you consider it as a buildsystem/yum bug? > > Well I am not sure, as I don't have access to i68_64 systems. > > What does > rpm -qf /usr/lib/libGLU.so > and > rpm -qf /usr/lib64/libGLU.so You get both times xorg-x11-devel, IIRC, but with different arch. > say, rsp. what does > "rpm -q --whatprovides libGLU.so" > > with a both versions of libGLU.so installed report? No package would ever provide that as a SONAME. Only querying the actual files with complete paths [as above] works. > > Why does this problem only show up with this package (or are > > there others I missed?). > Many possibilities. BuildRequires: xorg-x11-devel here simply pulls in the i386 package and not the x86_64 package. Problem hasn't surfaced earlier, because no x86_64 packages have been built in mach[+yum] before, at least not at fedora.us, and initial builds for pre-Extras were made in full installations. From laroche at redhat.com Thu May 5 16:24:09 2005 From: laroche at redhat.com (Florian La Roche) Date: Thu, 5 May 2005 18:24:09 +0200 Subject: Package Build Report - Fedora Extras Development In-Reply-To: <20050505174942.1707e8ca@python2> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> <20050505174942.1707e8ca@python2> Message-ID: <20050505162409.GA4437@dudweiler.stuttgart.redhat.com> On Thu, May 05, 2005 at 05:49:42PM +0200, Matthias Saou wrote: > Thorsten Leemhuis wrote : > > > Seth, on x86_64 the buildsystem/mach/yum installs the 32-bit version of > > libGLU (xorg-x11-Mesa-libGLU-6.8.2-1.FC3.13.i386) and not the 64bit- > > version (xorg-x11-Mesa-libGLU-6.8.2-1.FC3.13.x86_64) for the > > "BuildRequire libGLU.so.1". The build fails due to that. I wanted to > > look into this already known problem but did not find the time/it got > > lost. Sorry for that. > > > > So, how do we fix that? [...] > > My opinion would be to only have x86_64 and noarch packages available for > the x86_64 build root, and no let any i?86 packages be available to it, > since it makes no sense anyway for a build root. > > I've already bumped into this problem myself, and my solution has been to > create a "static" RPMS directory with all i?86.rpm packages removed and > createrepo re-run on top of that. The cleaner fix would be to disable > multiarch support in the yum used for the x86_64 build root, but I don't > think that's possible with the current yum (seth will know for sure ;-)). You can craft an exclude statement to exclude all of *.i386.rpm, but still leave glibc/gcc multilib. greetings, Florian La Roche From rc040203 at freenet.de Thu May 5 16:35:33 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 05 May 2005 18:35:33 +0200 Subject: Package Build Report - Fedora Extras Development In-Reply-To: <20050505181522.30e74d4c.bugs.michael@gmx.net> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> <1115307543.24385.698.camel@mccallum.corsepiu.local> <20050505181522.30e74d4c.bugs.michael@gmx.net> Message-ID: <1115310933.24385.711.camel@mccallum.corsepiu.local> On Thu, 2005-05-05 at 18:15 +0200, Michael Schwendt wrote: > On Thu, 05 May 2005 17:39:03 +0200, Ralf Corsepius wrote: > > > On Thu, 2005-05-05 at 15:39 +0200, Thorsten Leemhuis wrote: > > > Am Donnerstag, den 05.05.2005, 08:35 -0400 schrieb seth vidal: > > > BuildRequires: libGLU >= 1 > > > > > > as suggested by mharris in > > > https://www.redhat.com/archives/fedora-maintainers/2005-March/msg00128.html > > > But this only works in devel :-( > > > > > > Another way to fix maybe would be to do a > > > > > > %ifarch x86_64 > > > BuildRequires: libGLU.so.1()((64bit) > > > %else > > > BuildRequires: libGLU.so.1 > > > %endif > > Sorry, but that's nuts - rpm must handle this case by itself. > > Sure it's nuts, but a temporary (!) work-around I could think of. Well, AFAICT, something is broken elsewhere, either in rpm, the buildsystem or inside of the GLU's packaging. > Both libGLU.so.1()(64bit) and libGL.so.1()(64bit) virtual provides do exist. The actual question here is: What does "provides: libGLU.so.1" mean? > > > (was suggested my Michael Schwendt iirc). Also untested and imho ugly. > > > > > > Or do you consider it as a buildsystem/yum bug? > > > > Well I am not sure, as I don't have access to i68_64 systems. > > > > What does > > rpm -qf /usr/lib/libGLU.so > > and > > rpm -qf /usr/lib64/libGLU.so > > You get both times xorg-x11-devel, IIRC, but with different arch. > > > say, rsp. what does > > "rpm -q --whatprovides libGLU.so" > > > > with a both versions of libGLU.so installed report? > > No package would ever provide that as a SONAME. Only querying > the actual files with complete paths [as above] works. Sorry, I meant rpm -q --whatprovides libGLU.so.1 Ralf From bugs.michael at gmx.net Thu May 5 17:27:54 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 5 May 2005 19:27:54 +0200 Subject: Package Build Report - Fedora Extras Development In-Reply-To: <1115310933.24385.711.camel@mccallum.corsepiu.local> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> <1115307543.24385.698.camel@mccallum.corsepiu.local> <20050505181522.30e74d4c.bugs.michael@gmx.net> <1115310933.24385.711.camel@mccallum.corsepiu.local> Message-ID: <20050505192754.729380cd.bugs.michael@gmx.net> On Thu, 05 May 2005 18:35:33 +0200, Ralf Corsepius wrote: > Well, AFAICT, something is broken elsewhere, either in rpm, the > buildsystem or inside of the GLU's packaging. > > > Both libGLU.so.1()(64bit) and libGL.so.1()(64bit) virtual provides do exist. > The actual question here is: > What does "provides: libGLU.so.1" mean? Well, first of all it means that the package includes a shared object library with the SONAME libGLU.so.1 and stores this library in dynamic linker's search path. (If it stores it elsewhere, that's a package bug IMHO). Due to multilib it has become more complicated, apparently, as the SONAME is identical on every architecture, and only RPM seems to mark the 64-bit version in a package. > > > say, rsp. what does > > > "rpm -q --whatprovides libGLU.so" > > > > > > with a both versions of libGLU.so installed report? > > > > No package would ever provide that as a SONAME. Only querying > > the actual files with complete paths [as above] works. > Sorry, I meant > rpm -q --whatprovides libGLU.so.1 An i386 package. :) From bugs.michael at gmx.net Thu May 5 17:33:39 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 5 May 2005 19:33:39 +0200 Subject: Package Build Report - Fedora Extras Development In-Reply-To: <1115307657.12158.18.camel@ernie> References: <1115296548.24970.11.camel@cutter> <1115305044.4106.103.camel@localhost.localdomain> <1115307657.12158.18.camel@ernie> Message-ID: <20050505193339.5b37d003.bugs.michael@gmx.net> On Thu, 05 May 2005 11:40:56 -0400, Ed Hill wrote: > On Thu, 2005-05-05 at 09:57 -0500, Tom 'spot' Callaway wrote: > > On Thu, 2005-05-05 at 08:35 -0400, seth vidal wrote: > > > The following packages failed to build on Fedora Extras Development: > > Hi Seth, > > First, many thanks for all the work that you've been doing on builds and > the build system. > > The cdo package failed to build because it failed to get a dependency on > the ppc architecture: > > http://extras64.linux.duke.edu/failed/development/cdo/0.9.6-2/ppc/ > > "Building source rpm cdo-0.9.6-2.src.rpm > Installing BuildRequires .../ERROR: BuildRequires not met: > error: Failed build dependencies: > netcdf-devel is needed by cdo-0.9.6-2.ppc" > > So, how am I (or we) supposed to fix this dependency? Someone please > help me! ;-) Means that netcdf hasn't been built for ppc before, so increase the package release, tag it, and request a rebuild for all architectures (either now or as soon as the build system is announced and opened for all packagers). From skvidal at phy.duke.edu Thu May 5 17:53:36 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 05 May 2005 13:53:36 -0400 Subject: buildsystem stuff In-Reply-To: <1115310674.16211.35.camel@dcbw.boston.redhat.com> References: <1115181658.15831.45.camel@cutter> <1115300266.16211.19.camel@dcbw.boston.redhat.com> <1115309084.16366.70.camel@bree.local.net> <1115310674.16211.35.camel@dcbw.boston.redhat.com> Message-ID: <1115315616.3669.8.camel@cutter> On Thu, 2005-05-05 at 12:31 -0400, Dan Williams wrote: > On Thu, 2005-05-05 at 12:04 -0400, Jeremy Katz wrote: > > On Thu, 2005-05-05 at 09:37 -0400, Dan Williams wrote: > > > A couple of comments, some of which I'd even be willing to do the work > > > for :) > > > > > > 1) CVS/tobuild - Could this code be separated into an XML-RPC client? > > > So you'd have the Queuer be an XMLRPC server, and clients would connect > > > to it and feed it build jobs. For Aurora at least, we're probably not > > > going to have CVS of this type, and "tobuild" seems somewhat cumbersome. > > > > This was definitely intended as the eventual direction. But we wanted > > to get something going quickly, and write a file was far simpler. :-) > > Especially since at first, there wasn't going to be the need for XML-RPC > > -- that came later as a need for kicking off the ppc builds. > > > > Any help down this path would definitely be appreciated, otherwise it's > > at least on my todo list. The key is to keep the client as simple as > > possible so that we don't have a big list of deps like you end up with > > for the beehive client. Basic python + included modules should be > > fairly sane, though. And using the client certs for the fedora account > > system stuff seems like the obvious auth mechanism then. > > Ok, I'll try to do this in the next couple days then. Is there CVS > somewhere for the scripts? I don't want to do the work and then do > manual merges really. > code is in extras-buildsys-temp in /cvs/fedora look in the dir 'automation' in that module. If you want the code that does the 2-way auth via ssl certs you should look at m2crypto. CCing this to icon so he can tell you where to look for the code. -sv From terraformers at gmail.com Thu May 5 13:39:55 2005 From: terraformers at gmail.com (Lars G) Date: Thu, 05 May 2005 15:39:55 +0200 Subject: graveman needs rebuild against flac Message-ID: ...as it tells Error: Missing Dependency: libFLAC.so.4 is needed by package graveman cheers lars From katzj at redhat.com Thu May 5 18:54:19 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 05 May 2005 14:54:19 -0400 Subject: [PATCH] let Makefile.common respect $RPM_BUILD_DIR In-Reply-To: <87ll6zccmr.fsf@kosh.bigo.ensc.de> References: <87ll6zccmr.fsf@kosh.bigo.ensc.de> Message-ID: <1115319259.16366.95.camel@bree.local.net> On Sun, 2005-05-01 at 15:13 +0200, Enrico Scholz wrote: > makes the 'patch' and 'rediff' > targets work when $(RPM_BUILD_DIR) was set to another directory. > Applied. Thanks Jeremy From rc040203 at freenet.de Thu May 5 19:52:50 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 05 May 2005 21:52:50 +0200 Subject: Package Build Report - Fedora Extras Development In-Reply-To: <20050505192754.729380cd.bugs.michael@gmx.net> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> <1115307543.24385.698.camel@mccallum.corsepiu.local> <20050505181522.30e74d4c.bugs.michael@gmx.net> <1115310933.24385.711.camel@mccallum.corsepiu.local> <20050505192754.729380cd.bugs.michael@gmx.net> Message-ID: <1115322770.24385.716.camel@mccallum.corsepiu.local> On Thu, 2005-05-05 at 19:27 +0200, Michael Schwendt wrote: > On Thu, 05 May 2005 18:35:33 +0200, Ralf Corsepius wrote: > > > Well, AFAICT, something is broken elsewhere, either in rpm, the > > buildsystem or inside of the GLU's packaging. > > > > > Both libGLU.so.1()(64bit) and libGL.so.1()(64bit) virtual provides do exist. > > The actual question here is: > > What does "provides: libGLU.so.1" mean? > > Well, first of all it means that the package includes a shared object > library with the SONAME libGLU.so.1 and stores this library in dynamic > linker's search path. (If it stores it elsewhere, that's a package bug > IMHO). Due to multilib it has become more complicated, apparently, as > the SONAME is identical on every architecture, and only RPM seems to > mark the 64-bit version in a package. > > > > > say, rsp. what does > > > > "rpm -q --whatprovides libGLU.so" > > > > > > > > with a both versions of libGLU.so installed report? > > > > > > No package would ever provide that as a SONAME. Only querying > > > the actual files with complete paths [as above] works. > > Sorry, I meant > > rpm -q --whatprovides libGLU.so.1 > > An i386 package. :) Urgh, in other words, SONAME provides have become meaningless and useless, i.e. rpm on x86-64 is severely borked :( Ralf. From ivazquez at ivazquez.net Thu May 5 20:47:04 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 05 May 2005 16:47:04 -0400 Subject: graveman needs rebuild against flac In-Reply-To: References: Message-ID: <1115326024.8962.9.camel@ignacio.ignacio.lan> On Thu, 2005-05-05 at 15:39 +0200, Lars G wrote: > ...as it tells > > Error: Missing Dependency: libFLAC.so.4 is needed by package graveman http://bugzilla.redhat.com/ -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mricon at gmail.com Thu May 5 21:04:20 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Thu, 5 May 2005 17:04:20 -0400 Subject: buildsystem stuff In-Reply-To: <1115315616.3669.8.camel@cutter> References: <1115181658.15831.45.camel@cutter> <1115300266.16211.19.camel@dcbw.boston.redhat.com> <1115309084.16366.70.camel@bree.local.net> <1115310674.16211.35.camel@dcbw.boston.redhat.com> <1115315616.3669.8.camel@cutter> Message-ID: On 5/5/05, seth vidal wrote: > If you want the code that does the 2-way auth via ssl certs you should > look at m2crypto. CCing this to icon so he can tell you where to look > for the code. http://www.linux.duke.edu/~icon/misc/xmlrpcssl.py NB: Apparently almost every m2crypto package that has shipped with Fedora Core is a little broken in the sense that establishing HTTPS connections doesn't work. The only way to make it work is to rebuild the 0.13-2 package currently in rawhide, though, very humorously, it doesn't work with python-2.4 because of this bug: https://bugzilla.osafoundation.org/show_bug.cgi?id=2840 I've filed the problem in rh bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156979 You'll need to get a working version of m2crypto on your system before you can use this code. Cheers, -- Konstantin Ryabitsev Zlotniks, INC From katzj at redhat.com Thu May 5 21:09:40 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 05 May 2005 17:09:40 -0400 Subject: Package Build Report - Fedora Extras Development In-Reply-To: <1115322770.24385.716.camel@mccallum.corsepiu.local> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> <1115307543.24385.698.camel@mccallum.corsepiu.local> <20050505181522.30e74d4c.bugs.michael@gmx.net> <1115310933.24385.711.camel@mccallum.corsepiu.local> <20050505192754.729380cd.bugs.michael@gmx.net> <1115322770.24385.716.camel@mccallum.corsepiu.local> Message-ID: <1115327380.3374.8.camel@bree.local.net> On Thu, 2005-05-05 at 21:52 +0200, Ralf Corsepius wrote: > Urgh, in other words, SONAME provides have become meaningless and > useless, i.e. rpm on x86-64 is severely borked :( No, because the soname provides/requires are auto-generated -- if you ever manually put Requires: libfoo.so.1 in a spec file, then you are doing something wrong. Jeremy From smooge at gmail.com Thu May 5 22:00:41 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Thu, 5 May 2005 16:00:41 -0600 Subject: Valid Group names Message-ID: <80d7e40905050515003b6b3d23@mail.gmail.com> I think I am missing the obvious, but is there a page in the Wiki with the valid Group names that can be used when creating packages? Looking at Fedora-development and doing a rpm -qp --qf='%{Group}\n' I came up with the following numbers: Amusements/Games Amusements/Graphics Applications/Archiving Applications/CPAN Applications/Communications Applications/Databases Applications/Editors Applications/Engineering Applications/File Applications/Internet Applications/Multimedia Applications/Productivity Applications/Publishing Applications/Shells Applications/System Applications/Text Desktop/Accessibility Development/Build Tools Development/Code Generators Development/Debuggers Development/Java Development/Languages Development/Libraries Development/Libraries/Application Frameworks Development/Libraries/Java Development/System Development/Testing Development/Tools Documentation Internet/WWW/Servers Networking/Daemons Productivity/Security Security/Cryptography System Environment/Base System Environment/Daemons System Environment/Kernel System Environment/Libraries System Environment/Shells System Environment/System System/Boot System/Logging Text Editors/Integrated Development Environments (IDE) Text Processing/Markup/XML User Interface/Desktops User Interface/X User Interface/X Hardware Support Utilities Utilities/System I am trying to figure out where to stick various packages like: Snort, php-base, arpd, honeyd, barnyard Is it Internet/Security Security/Internet Applications/Internet -- Stephen J Smoogen. CSIRT/Linux System Administrator From mricon at gmail.com Thu May 5 22:06:44 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Thu, 5 May 2005 18:06:44 -0400 Subject: Valid Group names In-Reply-To: <80d7e40905050515003b6b3d23@mail.gmail.com> References: <80d7e40905050515003b6b3d23@mail.gmail.com> Message-ID: On 5/5/05, Stephen J. Smoogen wrote: > I think I am missing the obvious, but is there a page in the Wiki with > the valid Group names that can be used when creating packages? /usr/share/doc/rpm-*/GROUPS http://fedoraproject.org/wiki/RPMGroups -- Konstantin Ryabitsev Zlotniks, INC From terraformers at gmail.com Thu May 5 20:57:31 2005 From: terraformers at gmail.com (Lars G) Date: Thu, 05 May 2005 22:57:31 +0200 Subject: graveman needs rebuild against flac References: <1115326024.8962.9.camel@ignacio.ignacio.lan> Message-ID: On Thu, 05 May 2005 16:47:04 -0400, Ignacio Vazquez-Abrams wrote: > On Thu, 2005-05-05 at 15:39 +0200, Lars G wrote: >> ...as it tells >> >> Error: Missing Dependency: libFLAC.so.4 is needed by package graveman > > http://bugzilla.redhat.com/ done lars From mattdm at mattdm.org Thu May 5 22:20:06 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 5 May 2005 18:20:06 -0400 Subject: Valid Group names In-Reply-To: References: <80d7e40905050515003b6b3d23@mail.gmail.com> Message-ID: <20050505222006.GA6691@jadzia.bu.edu> On Thu, May 05, 2005 at 06:06:44PM -0400, Konstantin Ryabitsev wrote: > > I think I am missing the obvious, but is there a page in the Wiki with > > the valid Group names that can be used when creating packages? > /usr/share/doc/rpm-*/GROUPS > http://fedoraproject.org/wiki/RPMGroups It's kind of a weird list -- anything remotely related to math or science ends up getting lumpted into "Applications/Engineering". Personally, I think the list should be reduced to: Core Extras . For various reasons, it's been found to be more useful to keep the updated version of this metainformation externally -- in comps.xml and the (same format) yum groupfiles. Given that that's the case, having this slightly-askew list of round-peg-square-hole categories in the RPM itself ought to go. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From skvidal at phy.duke.edu Thu May 5 22:24:27 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 05 May 2005 18:24:27 -0400 Subject: Valid Group names In-Reply-To: <20050505222006.GA6691@jadzia.bu.edu> References: <80d7e40905050515003b6b3d23@mail.gmail.com> <20050505222006.GA6691@jadzia.bu.edu> Message-ID: <1115331867.3669.15.camel@cutter> On Thu, 2005-05-05 at 18:20 -0400, Matthew Miller wrote: > On Thu, May 05, 2005 at 06:06:44PM -0400, Konstantin Ryabitsev wrote: > > > I think I am missing the obvious, but is there a page in the Wiki with > > > the valid Group names that can be used when creating packages? > > /usr/share/doc/rpm-*/GROUPS > > http://fedoraproject.org/wiki/RPMGroups > > It's kind of a weird list -- anything remotely related to math or science > ends up getting lumpted into "Applications/Engineering". > > Personally, I think the list should be reduced to: > > Core > Extras > > . > > For various reasons, it's been found to be more useful to keep the updated > version of this metainformation externally -- in comps.xml and the (same > format) yum groupfiles. Given that that's the case, having this > slightly-askew list of round-peg-square-hole categories in the RPM itself > ought to go. or better yet 86 the group list. -sv From smooge at gmail.com Thu May 5 22:38:34 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Thu, 5 May 2005 16:38:34 -0600 Subject: Valid Group names In-Reply-To: <1115331867.3669.15.camel@cutter> References: <80d7e40905050515003b6b3d23@mail.gmail.com> <20050505222006.GA6691@jadzia.bu.edu> <1115331867.3669.15.camel@cutter> Message-ID: <80d7e4090505051538196cc1cf@mail.gmail.com> On 5/5/05, seth vidal wrote: > On Thu, 2005-05-05 at 18:20 -0400, Matthew Miller wrote: > > On Thu, May 05, 2005 at 06:06:44PM -0400, Konstantin Ryabitsev wrote: > > > > I think I am missing the obvious, but is there a page in the Wiki with > > > > the valid Group names that can be used when creating packages? > > > /usr/share/doc/rpm-*/GROUPS > > > http://fedoraproject.org/wiki/RPMGroups > > > > It's kind of a weird list -- anything remotely related to math or science > > ends up getting lumpted into "Applications/Engineering". > > > > Personally, I think the list should be reduced to: > > > > Core > > Extras > > > > . > > > > For various reasons, it's been found to be more useful to keep the updated > > version of this metainformation externally -- in comps.xml and the (same > > format) yum groupfiles. Given that that's the case, having this > > slightly-askew list of round-peg-square-hole categories in the RPM itself > > ought to go. > > > > or better yet 86 the group list. > Well that is above my 'paygrade' to decide. I was just trying to figure out what I should do currently. I can not use the field if that is what Extras prefers. -- Stephen J Smoogen. CSIRT/Linux System Administrator From mattdm at mattdm.org Fri May 6 00:12:18 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 5 May 2005 20:12:18 -0400 Subject: Valid Group names In-Reply-To: <80d7e4090505051538196cc1cf@mail.gmail.com> References: <80d7e40905050515003b6b3d23@mail.gmail.com> <20050505222006.GA6691@jadzia.bu.edu> <1115331867.3669.15.camel@cutter> <80d7e4090505051538196cc1cf@mail.gmail.com> Message-ID: <20050506001218.GA9741@jadzia.bu.edu> On Thu, May 05, 2005 at 04:38:34PM -0600, Stephen J. Smoogen wrote: > Well that is above my 'paygrade' to decide. I was just trying to > figure out what I should do currently. I can not use the field if that > is what Extras prefers. For now, I think you should pick something from The List. For FC5, we should do something more drastic. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From rc040203 at freenet.de Fri May 6 02:29:01 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 06 May 2005 04:29:01 +0200 Subject: Package Build Report - Fedora Extras Development In-Reply-To: <1115327380.3374.8.camel@bree.local.net> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> <1115307543.24385.698.camel@mccallum.corsepiu.local> <20050505181522.30e74d4c.bugs.michael@gmx.net> <1115310933.24385.711.camel@mccallum.corsepiu.local> <20050505192754.729380cd.bugs.michael@gmx.net> <1115322770.24385.716.camel@mccallum.corsepiu.local> <1115327380.3374.8.camel@bree.local.net> Message-ID: <1115346541.24385.724.camel@mccallum.corsepiu.local> On Thu, 2005-05-05 at 17:09 -0400, Jeremy Katz wrote: > On Thu, 2005-05-05 at 21:52 +0200, Ralf Corsepius wrote: > > Urgh, in other words, SONAME provides have become meaningless and > > useless, i.e. rpm on x86-64 is severely borked :( > > No, because the soname provides/requires are auto-generated -- if you > ever manually put > Requires: libfoo.so.1 > in a spec file, then you are doing something wrong. What? It is prohibited to use autogenerated virtual provides in rpm.specs? Show me the piece of documentation where a) the semantics of *.so.xx provides/requires is documented b) it is documented that using autogenerated virtual provides in manually written dependencies is prohibited. Ralf From j.w.r.degoede at hhs.nl Fri May 6 05:58:04 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 06 May 2005 07:58:04 +0200 Subject: -Lxxxxx/lib64 Message-ID: <427B076C.7010904@hhs.nl> Hi, In order to get Glide3 to build on x86_64 I need to add -L/usr/X11R6/lib64 to the CFLAGS. Now I know (think) that adding this for other archs is not a problem since those have xxx/lib64 it will effectivly do nothing. I wonder however what will happen if I add this and leave xxx/lib in the library-path on x86_64 and the i386 version of the library is also installed. Will the linker do the right thing, IOW will the linker only use x86_64 libs when linking an x86_64 app/lib? Thanks & Regards, Hans From pmatilai at welho.com Fri May 6 09:47:37 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 6 May 2005 12:47:37 +0300 (EEST) Subject: -Lxxxxx/lib64 In-Reply-To: <427B076C.7010904@hhs.nl> References: <427B076C.7010904@hhs.nl> Message-ID: On Fri, 6 May 2005, Hans de Goede wrote: > Hi, > > In order to get Glide3 to build on x86_64 I need to add -L/usr/X11R6/lib64 to > the CFLAGS. Now I know (think) that adding this for other archs is not a > problem since those have xxx/lib64 it will effectivly do nothing. > > I wonder however what will happen if I add this and leave xxx/lib in the > library-path on x86_64 and the i386 version of the library is also installed. > Will the linker do the right thing, IOW will the linker only use x86_64 libs > when linking an x86_64 app/lib? If you're setting CFLAGS from the spec itself you can use "CFLAGS=-L/usr/X11R6/%{_lib}" to get the path right. - Panu - From j.w.r.degoede at hhs.nl Fri May 6 09:53:18 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 06 May 2005 11:53:18 +0200 Subject: -Lxxxxx/lib64 In-Reply-To: References: <427B076C.7010904@hhs.nl> Message-ID: <427B3E8E.6040803@hhs.nl> Panu Matilainen wrote: > On Fri, 6 May 2005, Hans de Goede wrote: > >> Hi, >> >> In order to get Glide3 to build on x86_64 I need to add >> -L/usr/X11R6/lib64 to the CFLAGS. Now I know (think) that adding this >> for other archs is not a problem since those have xxx/lib64 it will >> effectivly do nothing. >> >> I wonder however what will happen if I add this and leave xxx/lib in >> the library-path on x86_64 and the i386 version of the library is also >> installed. Will the linker do the right thing, IOW will the linker >> only use x86_64 libs when linking an x86_64 app/lib? > > > If you're setting CFLAGS from the spec itself you can use > "CFLAGS=-L/usr/X11R6/%{_lib}" to get the path right. > > - Panu - > Nope I'm not (setting CFLAGS from the spec) what should I do in that case? Regards, Hans From paul at city-fan.org Fri May 6 10:58:32 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 06 May 2005 11:58:32 +0100 Subject: Self-Introduction: Paul Howarth Message-ID: <427B4DD8.7020103@city-fan.org> Hi there, I'm Paul Howarth from Manchester (UK) and would like to be a Fedora Extras developer. I've already registered on the accounts page and submitted the license agreement successfuly. I'm currently employed as a chip designer by a company called Xyratex, who are in Storage and Networking. However, my activities as a developer are done in my spare time and are not company-related. I currently maintain the Red Hat/Fedora RPM packages for the following projects: * libspf2 (http://www.libspf2.org/) * GTorrentViewer (http://gtorrentviewer.sourceforge.net/index.html) * PPTP Client (http://pptpclient.sourceforge.net/) I would eventually like to port these packages into Extras, starting with PPTP Client, which enables Unix/Linux systems to connect to Microsoft VPN servers. I am also happy to help with QA for other packages. I'm quite familar with C, sh and awk, but tend to focus more on packaging than actual development these days. To this end, I currently maintain my own repository of packages, which I use to keep my own home and work systems updated (http://www.city-fan.org/ftp/contrib/). I am also a regular contributor on fedora-list GPG details: pub 1024D/161C06B1 1997-09-25 Paul Howarth Key fingerprint = A511 62B6 9B79 580C E0B9 1770 7A65 92CF 161C 06B1 uid Paul Howarth sub 2048g/CA62663C 1997-09-25 Would anyone care to sponsor me for CVS access? Cheers, Paul. From ivazquez at ivazquez.net Fri May 6 11:10:02 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 06 May 2005 07:10:02 -0400 Subject: Request for review: OpenEXR, swish-e In-Reply-To: <1114335625.7784.41.camel@ignacio.ignacio.lan> References: <1114335625.7784.41.camel@ignacio.ignacio.lan> Message-ID: <1115377802.7124.1.camel@ignacio.ignacio.lan> On Sun, 2005-04-24 at 05:40 -0400, Ignacio Vazquez-Abrams wrote: > OpenEXR: A high dynamic-range (HDR) image file format > > OpenEXR is a high dynamic-range (HDR) image file format developed by > Industrial Light & Magic for use in computer imaging applications. This > package contains libraries and sample applications for handling the > format. > > http://fedora.ivazquez.net/files/OpenEXR-1.2.2-1.src.rpm > > swish-e: Simple Web Indexing System for Humans - Enhanced > > Swish-e is Simple Web Indexing System for Humans - Enhanced. Swish-e can > quickly and easily index directories of files or remote web sites and > search the generated indexes. > > http://fedora.ivazquez.net/files/swish-e-2.4.3-1.src.rpm Bump? -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Fri May 6 11:23:02 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 6 May 2005 13:23:02 +0200 Subject: -Lxxxxx/lib64 In-Reply-To: <427B3E8E.6040803@hhs.nl> References: <427B076C.7010904@hhs.nl> <427B3E8E.6040803@hhs.nl> Message-ID: <20050506132302.794a298f.bugs.michael@gmx.net> On Fri, 06 May 2005 11:53:18 +0200, Hans de Goede wrote: > > > Panu Matilainen wrote: > > On Fri, 6 May 2005, Hans de Goede wrote: > > > >> Hi, > >> > >> In order to get Glide3 to build on x86_64 I need to add > >> -L/usr/X11R6/lib64 to the CFLAGS. Now I know (think) that adding this > >> for other archs is not a problem since those have xxx/lib64 it will > >> effectivly do nothing. > >> > >> I wonder however what will happen if I add this and leave xxx/lib in > >> the library-path on x86_64 and the i386 version of the library is also > >> installed. Will the linker do the right thing, IOW will the linker > >> only use x86_64 libs when linking an x86_64 app/lib? > > > > > > If you're setting CFLAGS from the spec itself you can use > > "CFLAGS=-L/usr/X11R6/%{_lib}" to get the path right. > > > > - Panu - > > > > Nope I'm not (setting CFLAGS from the spec) what should I do in that case? A possible solution: In your patch, use -L/usr/X11R6/_MULTILIB_ or something unique and substitute it with sed -i in %prep. From gabbath at gmail.com Fri May 6 12:00:37 2005 From: gabbath at gmail.com (Dan Gabriel Ghita) Date: Fri, 6 May 2005 15:00:37 +0300 Subject: [REQUEST] kguitar Message-ID: hello, it's my first time doing this and i'm not exactly sure what to write. i'd like if you can to include this program into fedora extras package. if you could i'd be really grateful as i've had a horrible time installing it (i don't even have the latest version and right now i didn't yet manage to get it working properly because it uses midi and that's a bit difficult for me to configure as a newbie). i've managed with help from a friend who knows linux a lot better than i do (if it weren't for him i would have quit) and i've installed it along with its dependencies from an apt repository off www.rockerssoft.org but unfortunately the rpms are for fc2 and i'm experiencing some problems with it. i'd be really grateful if you can include this as it would be a whole lot easier just doing yum install kguitar. i know it would be really useful too as a lot of people who use windows use guitar pro 4 which kguitar can import files from. so that would help guitarists migrate easier from windows to linux. if you can help me the program's homepage is http://kguitar.sourceforge.net where it has sources plus some ALT linux rpms (which i couldn't install). uh, i think that's a bit too much information. if you can, i'd be happy if you would send me a response with your decision, thanks again, gabriel -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.w.r.degoede at hhs.nl Fri May 6 12:07:18 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 06 May 2005 14:07:18 +0200 Subject: -Lxxxxx/lib64 In-Reply-To: <20050506132302.794a298f.bugs.michael@gmx.net> References: <427B076C.7010904@hhs.nl> <427B3E8E.6040803@hhs.nl> <20050506132302.794a298f.bugs.michael@gmx.net> Message-ID: <427B5DF6.9090204@hhs.nl> Michael Schwendt wrote: > On Fri, 06 May 2005 11:53:18 +0200, Hans de Goede wrote: > > >> >>Panu Matilainen wrote: >> >>>On Fri, 6 May 2005, Hans de Goede wrote: >>> >>> >>>>Hi, >>>> >>>>In order to get Glide3 to build on x86_64 I need to add >>>>-L/usr/X11R6/lib64 to the CFLAGS. Now I know (think) that adding this >>>>for other archs is not a problem since those have xxx/lib64 it will >>>>effectivly do nothing. >>>> >>>>I wonder however what will happen if I add this and leave xxx/lib in >>>>the library-path on x86_64 and the i386 version of the library is also >>>>installed. Will the linker do the right thing, IOW will the linker >>>>only use x86_64 libs when linking an x86_64 app/lib? >>> >>> >>>If you're setting CFLAGS from the spec itself you can use >>>"CFLAGS=-L/usr/X11R6/%{_lib}" to get the path right. >>> >>> - Panu - >>> >> >>Nope I'm not (setting CFLAGS from the spec) what should I do in that case? > > > A possible solution: In your patch, use -L/usr/X11R6/_MULTILIB_ or > something unique and substitute it with sed -i in %prep. > Erm, preferably I would just use "-L/usr/X11R6/lib -L/usr/X11R6/lib64", on archs without /usr/X11R6/lib64 this will do nothing on archs with I am hoping / assuming that the linker will pick the right version. Regards, Hans From bugs.michael at gmx.net Fri May 6 12:05:36 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 6 May 2005 14:05:36 +0200 Subject: Self-Introduction: Paul Howarth In-Reply-To: <427B4DD8.7020103@city-fan.org> References: <427B4DD8.7020103@city-fan.org> Message-ID: <20050506140536.437a269d.bugs.michael@gmx.net> On Fri, 06 May 2005 11:58:32 +0100, Paul Howarth wrote: > Hi there, > > I'm Paul Howarth from Manchester (UK) and would like to be a Fedora > Extras developer. I've already registered on the accounts page and > submitted the license agreement successfuly. > > I'm currently employed as a chip designer by a company called Xyratex, > who are in Storage and Networking. However, my activities as a developer > are done in my spare time and are not company-related. > > I currently maintain the Red Hat/Fedora RPM packages for the following > projects: > > * libspf2 (http://www.libspf2.org/) > * GTorrentViewer (http://gtorrentviewer.sourceforge.net/index.html) > * PPTP Client (http://pptpclient.sourceforge.net/) > > I would eventually like to port these packages into Extras, starting > with PPTP Client, which enables Unix/Linux systems to connect to > Microsoft VPN servers. I am also happy to help with QA for other packages. > > I'm quite familar with C, sh and awk, but tend to focus more on > packaging than actual development these days. To this end, I currently > maintain my own repository of packages, which I use to keep my own home > and work systems updated (http://www.city-fan.org/ftp/contrib/). > > I am also a regular contributor on fedora-list > > GPG details: > pub 1024D/161C06B1 1997-09-25 Paul Howarth > Key fingerprint = A511 62B6 9B79 580C E0B9 1770 7A65 92CF 161C 06B1 > uid Paul Howarth > sub 2048g/CA62663C 1997-09-25 > > Would anyone care to sponsor me for CVS access? If you included direct links to your candidate src.rpm packages, that might be beneficial. I've tried to take a brief look at your repository, but got lost in the number of sub-directories and packages. The libspf2 src.rpm I found is bloated with macros and conditional spec file sections. From paul at city-fan.org Fri May 6 12:21:41 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 06 May 2005 13:21:41 +0100 Subject: Self-Introduction: Paul Howarth In-Reply-To: <20050506140536.437a269d.bugs.michael@gmx.net> References: <427B4DD8.7020103@city-fan.org> <20050506140536.437a269d.bugs.michael@gmx.net> Message-ID: <427B6155.7050903@city-fan.org> Michael Schwendt wrote: > If you included direct links to your candidate src.rpm packages, that > might be beneficial. OK, will do. > I've tried to take a brief look at your repository, > but got lost in the number of sub-directories and packages. Sorry about that; it's structured like that largely for historical reasons, and there are quite a few sites deep-linking in there so I'm loathed to restructure it. > The libspf2 src.rpm I found is bloated with macros and conditional spec file sections. True. I wouldn't be submitting a spec file like that for extras; project spec files have different goals, e.g. being more distribution-agnostic (the package is designed to build on Mandrake too etc.), and there's also a facility to build a compat- package containing only the shared libraries that can be installed alongside a later version of the library for compatibility with older apps. These things would be removed from a fedora-specific extras package. However, I'm not so sure about my use of macros such as %{__rm}, %{__make} etc. Why is it bad to use these? If these are bad things, why does every version of rpm I've ever seen include the definitions? Why does the Fedora template spec file use: %{__id_u} instead of: /usr/bin/id -u ? Is there an official policy on the use of macros like these? Paul. From bugs.michael at gmx.net Fri May 6 12:47:05 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 6 May 2005 14:47:05 +0200 Subject: Self-Introduction: Paul Howarth In-Reply-To: <427B6155.7050903@city-fan.org> References: <427B4DD8.7020103@city-fan.org> <20050506140536.437a269d.bugs.michael@gmx.net> <427B6155.7050903@city-fan.org> Message-ID: <20050506144705.2f8205ff.bugs.michael@gmx.net> On Fri, 06 May 2005 13:21:41 +0100, Paul Howarth wrote: > However, I'm not so sure about my use of macros such as %{__rm}, > %{__make} etc. Why is it bad to use these? I didn't comment on them. From paul at city-fan.org Fri May 6 13:03:25 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 06 May 2005 14:03:25 +0100 Subject: Self-Introduction: Paul Howarth In-Reply-To: <20050506144705.2f8205ff.bugs.michael@gmx.net> References: <427B4DD8.7020103@city-fan.org> <20050506140536.437a269d.bugs.michael@gmx.net> <427B6155.7050903@city-fan.org> <20050506144705.2f8205ff.bugs.michael@gmx.net> Message-ID: <427B6B1D.5070200@city-fan.org> Michael Schwendt wrote: > On Fri, 06 May 2005 13:21:41 +0100, Paul Howarth wrote: > >>However, I'm not so sure about my use of macros such as %{__rm}, >>%{__make} etc. Why is it bad to use these? > > > I didn't comment on them. So what were you referring to when you said "bloated with macros"? pptp package for consideration: http://www.city-fan.org/~paul/extras/pptp/ Cheers, Paul. From ed at eh3.com Fri May 6 13:04:23 2005 From: ed at eh3.com (Ed Hill) Date: Fri, 06 May 2005 09:04:23 -0400 Subject: Self-Introduction: Paul Howarth In-Reply-To: <427B6155.7050903@city-fan.org> References: <427B4DD8.7020103@city-fan.org> <20050506140536.437a269d.bugs.michael@gmx.net> <427B6155.7050903@city-fan.org> Message-ID: <1115384664.24408.97.camel@ernie> On Fri, 2005-05-06 at 13:21 +0100, Paul Howarth wrote: > Michael Schwendt wrote: > > If you included direct links to your candidate src.rpm packages, that > > might be beneficial. > > OK, will do. Hi Paul, Yes, please post URLs for the SRPMs that you'd like to submit. Then newbies (me!) and more experienced packagers (eg. Michael) will probably take a look. ;-) Generally, folks get sponsored for CVS access after they've gotten one or more SRPMs through some amount of review. 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 paul at city-fan.org Fri May 6 15:16:45 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 06 May 2005 16:16:45 +0100 Subject: Self-Introduction: Paul Howarth In-Reply-To: <1115384664.24408.97.camel@ernie> References: <427B4DD8.7020103@city-fan.org> <20050506140536.437a269d.bugs.michael@gmx.net> <427B6155.7050903@city-fan.org> <1115384664.24408.97.camel@ernie> Message-ID: <427B8A5D.9010205@city-fan.org> Ed Hill wrote: > On Fri, 2005-05-06 at 13:21 +0100, Paul Howarth wrote: > >>Michael Schwendt wrote: >> >>>If you included direct links to your candidate src.rpm packages, that >>>might be beneficial. >> >>OK, will do. > > > > Hi Paul, > > Yes, please post URLs for the SRPMs that you'd like to submit. Then > newbies (me!) and more experienced packagers (eg. Michael) will probably > take a look. ;-) > > Generally, folks get sponsored for CVS access after they've gotten one > or more SRPMs through some amount of review. In addition to the pptp package I referred to earlier (http://www.city-fan.org/~paul/extras/pptp/), I now have a GTorrentViewer package available for inspection: http://www.city-fan.org/~paul/extras/GTorrentViewer/ Cheers, Paul. From katzj at redhat.com Fri May 6 15:17:12 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 06 May 2005 11:17:12 -0400 Subject: Package Build Report - Fedora Extras Development In-Reply-To: <1115346541.24385.724.camel@mccallum.corsepiu.local> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> <1115307543.24385.698.camel@mccallum.corsepiu.local> <20050505181522.30e74d4c.bugs.michael@gmx.net> <1115310933.24385.711.camel@mccallum.corsepiu.local> <20050505192754.729380cd.bugs.michael@gmx.net> <1115322770.24385.716.camel@mccallum.corsepiu.local> <1115327380.3374.8.camel@bree.local.net> <1115346541.24385.724.camel@mccallum.corsepiu.local> Message-ID: <1115392633.3302.41.camel@bree.local.net> On Fri, 2005-05-06 at 04:29 +0200, Ralf Corsepius wrote: > On Thu, 2005-05-05 at 17:09 -0400, Jeremy Katz wrote: > > On Thu, 2005-05-05 at 21:52 +0200, Ralf Corsepius wrote: > > > Urgh, in other words, SONAME provides have become meaningless and > > > useless, i.e. rpm on x86-64 is severely borked :( > > > > No, because the soname provides/requires are auto-generated -- if you > > ever manually put > > Requires: libfoo.so.1 > > in a spec file, then you are doing something wrong. > > What? It is prohibited to use autogenerated virtual provides in > rpm.specs? The provides are auto-generated based on elf headers; they get used by the auto-generated requires which also look at the elf headers. These two are consistent in how they do things. Listing it in a specfile is _always_ going to require an ifarch hack, and realistically, a requirement like this should get picked up by the auto-generated requires. If it's not, then you have a bug in your package. They're autogenerated and thus semantics are subject to change. Granted, they haven't changed in ... a long time. The libfoo.so.1(64bit) has been being done on all 64bit platforms[1] since the dawn of time. How else do you want to differentiate between a provide of the 32bit libfoo.so.1 and the 64bit one? > Show me the piece of documentation where > a) the semantics of *.so.xx provides/requires is documented Maximum RPM and the Red Hat RPM Guide both provide a start at this. If you want the gory details, take a look at rpm/build/rpmfc.c (or alternately, the no longer generally used rpm/autodeps/linux.{req,prov}). If you really want me to go into it, I will, but it won't be pretty ;-) Note that the (64bit) markers have been being added on 64-bit platforms[1] essentially forever on Linux just to handle the question I ask about differentiation above. > b) it is documented that using autogenerated virtual provides in > manually written dependencies is prohibited. I think that Maximum RPM pretty clearly shows that you should be doing names of packages (or something that's explicitly listed as Provides: bar in another package's specfile). Also, the Red Hat RPM Guide calls it out more explicitly in Chapter 11. Jeremy [1] With the exception of alpha. But some might argue it predates forever ;-) From kaboom at oobleck.net Fri May 6 17:41:22 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Fri, 6 May 2005 13:41:22 -0400 (EDT) Subject: packages for review: openbox and friends In-Reply-To: <20050503064842.GA8791@lisas.de> References: <20050420052915.GA11961@lisas.de> <20050423155830.GB9919@lisas.de> <20050503064842.GA8791@lisas.de> Message-ID: On Tue, 3 May 2005, Adrian Reber wrote: > On Mon, Apr 25, 2005 at 04:21:50PM -0400, Chris Ricker wrote: > > > > The pkconfig files in openbox-devel require at least libxml2-devel, > glib2-devel and xorg-x11-devel so that these Requires should be added to > openbox-devel. > > It would be really nice if the default menu openbox shows would include > some other applications. Instead of mozilla I would prefer that firefox > is there. I also think that it doesn't make much sense to have quark in > the Applications menu as well as any of the games which may not be > there. Maybe you could replace the entries in the game menu with games > that are available from FE. I fixed the dependencies for the -devel For the menu, I took out all the non-{FC,FE} apps and put in some of the more common gui stuff (firefox, thunderbird, evolution, oo.o). I just killed the games stuff entirely -- I don't really pay attention there to even know what's available or good or commonly used.... If you had some stuff in mind I can certainly add it back Thanks! later, chris From kaboom at oobleck.net Fri May 6 17:46:13 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Fri, 6 May 2005 13:46:13 -0400 (EDT) Subject: Try #3: Co-sponsor pylint. In-Reply-To: References: Message-ID: On Wed, 4 May 2005, Konstantin Ryabitsev wrote: > Hello again: > > I've had pylint packaged and ready to be imported, but the procedures > dictate that I must find someone else to co-sponsor it before I can > add it to extras. However, nobody seems to care enough to say "yeah, > sure," even though I think it's a very useful package to provide in > Extras. s/co-sponser/approve/g ;-) > PS: is anyone else following that "co-sponsor" rule? Sometimes I see > packages just added, which makes me wonder... To me, that's the most confusing thing. It appears that some people put in CVS before review, some during review, and some only after they've gotten to the point of APPROVED and are ready to request a build.... later, chris From skvidal at phy.duke.edu Fri May 6 18:44:56 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 06 May 2005 14:44:56 -0400 Subject: buildsystem stuff In-Reply-To: References: <1115181658.15831.45.camel@cutter> <1115300266.16211.19.camel@dcbw.boston.redhat.com> <1115309084.16366.70.camel@bree.local.net> <1115310674.16211.35.camel@dcbw.boston.redhat.com> <1115315616.3669.8.camel@cutter> Message-ID: <1115405096.6805.52.camel@cutter> On Thu, 2005-05-05 at 17:04 -0400, Konstantin Ryabitsev wrote: > On 5/5/05, seth vidal wrote: > > If you want the code that does the 2-way auth via ssl certs you should > > look at m2crypto. CCing this to icon so he can tell you where to look > > for the code. > > http://www.linux.duke.edu/~icon/misc/xmlrpcssl.py > > NB: Apparently almost every m2crypto package that has shipped with > Fedora Core is a little broken in the sense that establishing HTTPS > connections doesn't work. The only way to make it work is to rebuild > the 0.13-2 package currently in rawhide, though, very humorously, it > doesn't work with python-2.4 because of this bug: > https://bugzilla.osafoundation.org/show_bug.cgi?id=2840 > > I've filed the problem in rh bugzilla: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156979 > > You'll need to get a working version of m2crypto on your system before > you can use this code. That rocks, Thanks Icon! Having a 2-way ssl cert-auth xml-rpc class should make lots of little authenticated utilities a lot easier. -sv From mricon at gmail.com Fri May 6 20:09:47 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Fri, 6 May 2005 16:09:47 -0400 Subject: Review: pylint, python-logilab-common Message-ID: Hello, folks: Please review the following two packages currently in devel cvs: -- Name: pylint Version: 0.6.4 Release: 3 Summary: Analyzes Python code looking for bugs and signs of poor quality Pylint is a python tool that checks if a module satisfy a coding standard. Pylint can be seen as another PyChecker since nearly all tests you can do with PyChecker can also be done with Pylint. But Pylint offers some more features, like checking line-code's length, checking if variable names are well-formed according to your coding standard, or checking if declared interfaces are truly implemented, and much more. The big advantage with Pylint is that it is highly configurable, customizable, and you can easily write a small plugin to add a personal feature. -- And a package that is required for it to run: -- Name: python-logilab-common Version: 0.9.3 Release: 3 Summary: Common libraries for Logilab projects This package contains several modules providing low level functionality shared among some python projects developed by logilab. -- Regards, -- Konstantin Ryabitsev Zlotniks, INC From qspencer at ieee.org Fri May 6 21:25:24 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Fri, 06 May 2005 16:25:24 -0500 Subject: Approval needed: fftw3 In-Reply-To: References: Message-ID: <427BE0C4.1040204@ieee.org> This is more or less identical to the fftw that is already in Extras, but is a package of the new version 3 that is incompatible with old fftw. A couple of minor issues were raised when I checked it into CVS, and they have been corrected. From qspencer at ieee.org Fri May 6 21:27:52 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Fri, 06 May 2005 16:27:52 -0500 Subject: Review needed: octave In-Reply-To: References: Message-ID: <427BE158.9030004@ieee.org> Octave is being removed from Core, so I have updated the spec file from version FC3 and checked it into CVS. The main changes are a new version from upstream, and a new dependency on FFTW3, which is in CVS and needs approval. regards, Quentin From smooge at gmail.com Fri May 6 21:50:51 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Fri, 6 May 2005 15:50:51 -0600 Subject: Review request: snort In-Reply-To: <80d7e40905050414414f46295@mail.gmail.com> References: <1115181733.12189.27.camel@plasma.starken.com> <1115183110.5462.30.camel@ignacio.ignacio.lan> <1115183816.12189.32.camel@plasma.starken.com> <1115184112.5462.32.camel@ignacio.ignacio.lan> <1115184643.12189.37.camel@plasma.starken.com> <20050504053453.GA16130@lisas.de> <1115185408.5462.34.camel@ignacio.ignacio.lan> <20050504103121.57855b48.bugs.michael@gmx.net> <1115230611.7136.7.camel@plasma.starken.com> <80d7e40905050414414f46295@mail.gmail.com> Message-ID: <80d7e409050506145071ef3a24@mail.gmail.com> On 5/4/05, Stephen J. Smoogen wrote: > On 5/4/05, Daniel Wittenberg wrote: > > initDir now replaced with _initdir. I also updated some other macros > > and building snort inline rpms now work too. > > > > http://www.starken.com/snort/snort.spec > > > > We'll be doing some more testing on the built RPM's but if those are > > good then we'll be ready for the full 2.4 release and maybe we can get > > it into extras at that time. > > > > Dan > > Ok a couple of questions: > 1) setting %vendor might cause confusion with other organizations > using this src.rpm > 2) same with Packager. If I rebuild the RPM I am not the official > builder for snort. Going through the rpmlint errors E: snort configure-without-libdir-spec if [ "$1" = "mysql" ]; then ./configure $SNORT_BASE_CONFIG \ --with-mysql \ --without-postgresql \ --without-oracle \ %{?EnableFlexresp} %{?EnableFlexresp2} fi Not sure what the best fix for this is.. my take on the logic was a complete rewrite which usually means I dont understand the problem :). > 3) where it says plain, it should probably use the word base (more in > line with other RPM packaging references) > > base Snort (this package, required) > mysql Snort with mysql (optional) > > 4)this section looks like the %if needs to be further out. > > %package postgresql > Summary: Snort with PostgreSQL support > Group: Applications/Internet > Requires: %{name} = %{version}-%{release} > %if %{postgresql} > BuildRequires: postgresql-devel > %endif > > 5) Style point to be more inline with other rpms (or at least the ones > I have been looking at this week). Move the main %description under > the main package versus below the other sections. > > I am working through the logic of the rest.. but I know that using > this spec file will build a 2.3.3 one (if you dont use --inline ;)). > Hope this is useful. > > -- > Stephen J Smoogen. > CSIRT/Linux System Administrator > -- Stephen J Smoogen. CSIRT/Linux System Administrator From daniel-wittenberg at starken.com Fri May 6 22:14:54 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Fri, 06 May 2005 17:14:54 -0500 Subject: Review request: snort In-Reply-To: <80d7e409050506145071ef3a24@mail.gmail.com> References: <1115181733.12189.27.camel@plasma.starken.com> <1115183110.5462.30.camel@ignacio.ignacio.lan> <1115183816.12189.32.camel@plasma.starken.com> <1115184112.5462.32.camel@ignacio.ignacio.lan> <1115184643.12189.37.camel@plasma.starken.com> <20050504053453.GA16130@lisas.de> <1115185408.5462.34.camel@ignacio.ignacio.lan> <20050504103121.57855b48.bugs.michael@gmx.net> <1115230611.7136.7.camel@plasma.starken.com> <80d7e40905050414414f46295@mail.gmail.com> <80d7e409050506145071ef3a24@mail.gmail.com> Message-ID: <1115417695.6245.24.camel@tholian.starken.com> So is this just complaining because we're not specifying the libdir in configure? I'm not real familiar with rpmlint's errors, usually just fix big critical stuff. Dan On Fri, 2005-05-06 at 15:50 -0600, Stephen J. Smoogen wrote: > Going through the rpmlint errors > > E: snort configure-without-libdir-spec > if [ "$1" = "mysql" ]; then > ./configure $SNORT_BASE_CONFIG \ > --with-mysql \ > --without-postgresql \ > --without-oracle \ > %{?EnableFlexresp} %{?EnableFlexresp2} > fi > > Not sure what the best fix for this is.. my take on the logic was a > complete rewrite which usually means I dont understand the problem :). -- ======================= Daniel Wittenberg RHCE President/CTO The Starken Group Ltd. http://www.starken.com From toshio at tiki-lounge.com Fri May 6 22:37:59 2005 From: toshio at tiki-lounge.com (Toshio) Date: Fri, 06 May 2005 18:37:59 -0400 Subject: Review request: snort (subpackage names) In-Reply-To: <1115417695.6245.24.camel@tholian.starken.com> References: <1115181733.12189.27.camel@plasma.starken.com> <1115183110.5462.30.camel@ignacio.ignacio.lan> <1115183816.12189.32.camel@plasma.starken.com> <1115184112.5462.32.camel@ignacio.ignacio.lan> <1115184643.12189.37.camel@plasma.starken.com> <20050504053453.GA16130@lisas.de> <1115185408.5462.34.camel@ignacio.ignacio.lan> <20050504103121.57855b48.bugs.michael@gmx.net> <1115230611.7136.7.camel@plasma.starken.com> <80d7e40905050414414f46295@mail.gmail.com> <80d7e409050506145071ef3a24@mail.gmail.com> <1115417695.6245.24.camel@tholian.starken.com> Message-ID: <1115419079.20106.19.camel@Madison.badger.com> From Package Naming Guidelines: When naming packages for Fedora, the maintainer should use the dash '-' as the delimiter for name parts. The maintainer should NOT use an underscore '_', a plus '+', or a period '.' as a delimiter. Looks like the snort subpackages: snort-plain+flexresp, snort-mysql+flexresp, snort-postgresql+flexresp, snort-snmp+flexresp, and snort-mysql+postgresql+flexresp+snmp should be changed. -Toshio -- _________________ Attraction's easy; love is hard ______________________ t o s h i o @ t i k i - l o u n g e . c o m GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From daniel-wittenberg at starken.com Fri May 6 22:43:42 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Fri, 06 May 2005 17:43:42 -0500 Subject: Review request: snort (subpackage names) In-Reply-To: <1115419079.20106.19.camel@Madison.badger.com> References: <1115181733.12189.27.camel@plasma.starken.com> <1115183110.5462.30.camel@ignacio.ignacio.lan> <1115183816.12189.32.camel@plasma.starken.com> <1115184112.5462.32.camel@ignacio.ignacio.lan> <1115184643.12189.37.camel@plasma.starken.com> <20050504053453.GA16130@lisas.de> <1115185408.5462.34.camel@ignacio.ignacio.lan> <20050504103121.57855b48.bugs.michael@gmx.net> <1115230611.7136.7.camel@plasma.starken.com> <80d7e40905050414414f46295@mail.gmail.com> <80d7e409050506145071ef3a24@mail.gmail.com> <1115417695.6245.24.camel@tholian.starken.com> <1115419079.20106.19.camel@Madison.badger.com> Message-ID: <1115419422.6245.26.camel@tholian.starken.com> Well, unless I'ved really missed something, we don't change the package name for adding flexresp, and we aren't doing anything with snmp, so I think we're ok on this one. Dan On Fri, 2005-05-06 at 18:37 -0400, Toshio wrote: > From Package Naming Guidelines: > When naming packages for Fedora, the maintainer should use the dash '-' as > the delimiter for name parts. The maintainer should NOT use an underscore > '_', a plus '+', or a period '.' as a delimiter. > > Looks like the snort subpackages: snort-plain+flexresp, > snort-mysql+flexresp, snort-postgresql+flexresp, snort-snmp+flexresp, and > snort-mysql+postgresql+flexresp+snmp should be changed. > > -Toshio > From jpo at di.uminho.pt Sat May 7 00:02:36 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Sat, 07 May 2005 01:02:36 +0100 Subject: Review request: tetex-perltex Message-ID: <427C059C.60105@di.uminho.pt> Summary: Define LaTeX macros in terms of Perl code URL: http://www.ctan.org/tex-archive/help/Catalogue/entries/perltex.html Description: PerlTeX is a combination Perl script (perltex) and LaTeX2e style file (perltex.sty) that, together, give the user the ability to define LaTeX macros in terms of Perl code. Once defined, a Perl macro becomes indistinguishable from any other LaTeX macro. PerlTeX thereby combines LaTeX's typesetting power with Perl's programmability. Signed SRPM: http://gsd.di.uminho.pt/jpo/software/fedora/tetex-perltex-1.2-1.src.rpm Specfile: http://gsd.di.uminho.pt/jpo/software/fedora/tetex-perltex.spec -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From toshio at tiki-lounge.com Sat May 7 00:14:29 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 6 May 2005 17:14:29 -0700 Subject: Review request: snort (subpackage names) In-Reply-To: <1115419422.6245.26.camel@tholian.starken.com>; from daniel-wittenberg@starken.com on Fri, May 06, 2005 at 05:43:42PM -0500 References: <1115184643.12189.37.camel@plasma.starken.com> <20050504053453.GA16130@lisas.de> <1115185408.5462.34.camel@ignacio.ignacio.lan> <20050504103121.57855b48.bugs.michael@gmx.net> <1115230611.7136.7.camel@plasma.starken.com> <80d7e40905050414414f46295@mail.gmail.com> <80d7e409050506145071ef3a24@mail.gmail.com> <1115417695.6245.24.camel@tholian.starken.com> <1115419079.20106.19.camel@Madison.badger.com> <1115419422.6245.26.camel@tholian.starken.com> Message-ID: <20050506171429.A22744@tiki-lounge.com> Apologies -- I was looking at the snort in extras cvs which isn't your updated package. -Toshio On Fri, May 06, 2005 at 05:43:42PM -0500, Daniel Wittenberg wrote: > Well, unless I'ved really missed something, we don't change the package > name for adding flexresp, and we aren't doing anything with snmp, so I > think we're ok on this one. > > Dan > > On Fri, 2005-05-06 at 18:37 -0400, Toshio wrote: > > From Package Naming Guidelines: > > When naming packages for Fedora, the maintainer should use the dash '-' as > > the delimiter for name parts. The maintainer should NOT use an underscore > > '_', a plus '+', or a period '.' as a delimiter. > > > > Looks like the snort subpackages: snort-plain+flexresp, > > snort-mysql+flexresp, snort-postgresql+flexresp, snort-snmp+flexresp, and > > snort-mysql+postgresql+flexresp+snmp should be changed. > > > > -Toshio > > > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list From jpo at di.uminho.pt Sat May 7 00:29:38 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Sat, 07 May 2005 01:29:38 +0100 Subject: Review request: syslog-ng (syslog replacement daemon) Message-ID: <427C0BF2.9000304@di.uminho.pt> Summary: Syslog replacement daemon URL: http://www.balabit.com/products/syslog_ng/ Description: syslog-ng, as the name shows, is a syslogd replacement, but with new functionality for the new generation. The original syslogd allows messages only to be sorted based on priority/facility pairs; syslog-ng adds the possibility to filter based on message contents using regular expressions. The new configuration scheme is intuitive and powerful. Forwarding logs over TCP and remembering all forwarding hops makes it ideal for firewalled environments. SELinux notes: 1) See comment #30 https://bugzilla.fedora.us/show_bug.cgi?id=1332 2) https://www.redhat.com/archives/fedora-packaging/2005-April/msg00020.html Notes: * Stops the syslog daemon during installation * Changes a file from another package (/etc/logrotate.d/syslog from the sysklogd rpm) * currently it doesn't change the use_syslogng SELinux boolean SRPM at Fedora Extras CVS: cvs co syslog-ng -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From skvidal at phy.duke.edu Sat May 7 01:22:54 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 06 May 2005 21:22:54 -0400 Subject: Fedora Extras Development Build Report Message-ID: <1115428974.15593.11.camel@cutter> Failed builds: QuantLib synergy perl-String-ShellQuote enigma netcdf - untagged build - run make tag cdo seahorse Coin2 Logs available at: http://extras64.linux.duke.edu/failed/development/ -sv From ed at eh3.com Sat May 7 02:01:28 2005 From: ed at eh3.com (Ed Hill) Date: Fri, 06 May 2005 22:01:28 -0400 Subject: Approval needed: fftw3 In-Reply-To: <427BE0C4.1040204@ieee.org> References: <427BE0C4.1040204@ieee.org> Message-ID: <1115431288.24408.153.camel@ernie> On Fri, 2005-05-06 at 16:25 -0500, Quentin Spencer wrote: > This is more or less identical to the fftw that is already in Extras, > but is a package of the new version 3 that is incompatible with old > fftw. A couple of minor issues were raised when I checked it into CVS, > and they have been corrected. Hi Quentin, On an FC4t2 system, I checked out the latest fftw3 and all the following seemed to be in order: * specfile is very neat and easy on the eyes [;-)] * no errors from rpmlint * built, installed, and un-installed cleanly * played with the fftwf-wisdom binary (but was not patient enough for for any exhaustive runs) * checked file permissions & ownership I can't find anything the matter with it so please add my name to a "reviewed and approved-by" message. 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 mfleming at enlartenment.com Sat May 7 02:02:06 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Sat, 7 May 2005 12:02:06 +1000 Subject: Approval needed: mlmmj Message-ID: <20050507120206.4f791a8f.mfleming@enlartenment.com> Hi, I've cleaned up the spec file for the mlmmj package - thanks to Michael Schwendt for pointing out the longstanding errors and sundry small issues. I've also added a patch from the upstream author that fixes a potential race condition with moderation. Lists with multiple moderators may see multiples of the same message, if more than one moderator approves it before it's removed from the pending queue - the mod. request is now renamed after the first moderation approval to prevent this. I believe this will be merged into 1.2.6 It's in CVS (cvs co mlmmj) and also at http://www.enlartenment.com/extras/ if you wish to review it or otherwise give it a spin. I've been running it myself without problems (i386 / Core 3 box) but am interested in others' experiences I do have a couple of style/content queries for consideration though: - As the package should require a mail transport agent, what would be the best means of ensuring this? I've seen and used "Requires: smtpdaemon" previously (having seen it in RH specs). Would including this virtual req. still be the best practice? - The source package also contains two web frontends (one in Perl and another in PHP) for maintaining the lists and allowing visitors to sign up. Should they be split off into a subpackage, included in %doc (which I've seen done for some other packages) or omitted completely (the current status). Otherwise creation of new lists is via a small shell script included in the current package - fine for shell access but not overly convenient. Cheers, Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From bugs.michael at gmx.net Sat May 7 03:10:54 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 May 2005 05:10:54 +0200 Subject: Fedora Extras Development Build Report In-Reply-To: <1115428974.15593.11.camel@cutter> References: <1115428974.15593.11.camel@cutter> Message-ID: <20050507051054.195e5e08.bugs.michael@gmx.net> On Fri, 06 May 2005 21:22:54 -0400, seth vidal wrote: > Failed builds: > ... > seahorse > ... Hmmm, missing gpgme-devel on ppc, most likely because gnupg2 fails to build there. If there are still proponents of the "one failing arch blocks all other archs", it's about time for arch-specific community contributors to help with fixing packages which fail. From skvidal at phy.duke.edu Sat May 7 03:15:10 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 06 May 2005 23:15:10 -0400 Subject: Fedora Extras Development Build Report In-Reply-To: <20050507051054.195e5e08.bugs.michael@gmx.net> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> Message-ID: <1115435710.15593.18.camel@cutter> On Sat, 2005-05-07 at 05:10 +0200, Michael Schwendt wrote: > On Fri, 06 May 2005 21:22:54 -0400, seth vidal wrote: > > > Failed builds: > > ... > > seahorse > > ... > > Hmmm, missing gpgme-devel on ppc, most likely because gnupg2 fails > to build there. > > If there are still proponents of the "one failing arch blocks all other > archs", it's about time for arch-specific community contributors to help > with fixing packages which fail. > seahorse is mine. I'll look at it. -sv From jpo at di.uminho.pt Sat May 7 03:26:56 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Sat, 07 May 2005 04:26:56 +0100 Subject: Package Build Report - Fedora Extras Development (perl-OLE-Storage_Lite, ...) In-Reply-To: <1115305044.4106.103.camel@localhost.localdomain> References: <1115296548.24970.11.camel@cutter> <1115305044.4106.103.camel@localhost.localdomain> Message-ID: <427C3580.6040205@di.uminho.pt> Tom 'spot' Callaway wrote: > On Thu, 2005-05-05 at 08:35 -0400, seth vidal wrote: > >>perl-OLE-Storage_Lite > > I can't figure out why this failed from the log. The solution may be here: https://www.redhat.com/archives/fedora-extras-commits/2005-April/msg01416.html Also check the message https://www.redhat.com/archives/fedora-extras-commits/2005-April/msg01417.html for perl-SpreadSheet-WriteExcel problems. Both messages include patches. Regards, jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ed at eh3.com Sat May 7 03:53:07 2005 From: ed at eh3.com (Ed Hill) Date: Fri, 06 May 2005 23:53:07 -0400 Subject: Review needed: octave In-Reply-To: <427BE158.9030004@ieee.org> References: <427BE158.9030004@ieee.org> Message-ID: <1115437988.24408.171.camel@ernie> On Fri, 2005-05-06 at 16:27 -0500, Quentin Spencer wrote: > Octave is being removed from Core, so I have updated the spec file from > version FC3 and checked it into CVS. The main changes are a new version > from upstream, and a new dependency on FFTW3, which is in CVS and needs > approval. Hi Quentin, Since fftw3 seems to be in order, I tried your freshly-checked-in octave update: good: * builds, installs, & un-installs cleanly on FC4t2 system * binary seems fine on some simple tests * based on the specfile from Core nits: * rpmlint on SRPM & i386 RPM: "summary-ended-with-dot" "configure-without-libdir-spec" "incoherent-version-in-changelog" I really need more time to do a thorough review -- the build took a bit longer than I had anticipated and its getting late... 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 katzj at redhat.com Sat May 7 04:22:47 2005 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 07 May 2005 00:22:47 -0400 Subject: Review needed: octave In-Reply-To: <427BE158.9030004@ieee.org> References: <427BE158.9030004@ieee.org> Message-ID: <1115439768.3302.66.camel@bree.local.net> On Fri, 2005-05-06 at 16:27 -0500, Quentin Spencer wrote: > Octave is being removed from Core, so I have updated the spec file from > version FC3 and checked it into CVS. The main changes are a new version > from upstream, and a new dependency on FFTW3, which is in CVS and needs > approval. Packages being moved from Core to Extras are fair game to import and go ahead and request a build. That doesn't mean there aren't cleanups which could be done, but basically, they're not a blocker for keeping the package available. Jeremy From jpo at di.uminho.pt Sat May 7 04:29:20 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Sat, 07 May 2005 05:29:20 +0100 Subject: Splint: removed from Fedora Core Message-ID: <427C4420.101@di.uminho.pt> Splint was removed from Rawhide (Fedora Core) in 2005-04-05. Could someone import it into Extras CVS and maybe explain why it was removed from Core? Thanks in advance, jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From j.w.r.degoede at hhs.nl Sat May 7 08:08:45 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 07 May 2005 10:08:45 +0200 Subject: [REQUEST] kguitar In-Reply-To: References: Message-ID: <427C778D.3010304@hhs.nl> Dan Gabriel Ghita wrote: > hello, it's my first time doing this and i'm not exactly sure what to > write. i'd like if you can to include this program into fedora extras > package. if you could i'd be really grateful as i've had a horrible time > installing it (i don't even have the latest version and right now i > didn't yet manage to get it working properly because it uses midi and > that's a bit difficult for me to configure as a newbie). i've managed > with help from a friend who knows linux a lot better than i do (if it > weren't for him i would have quit) and i've installed it along with its > dependencies from an apt repository off www.rockerssoft.org > but unfortunately the rpms are for fc2 and > i'm experiencing some problems with it. i'd be really grateful if you > can include this as it would be a whole lot easier just doing yum > install kguitar. i know it would be really useful too as a lot of people > who use windows use guitar pro 4 which kguitar can import files from. so > that would help guitarists migrate easier from windows to linux. if you > can help me the program's homepage is http://kguitar.sourceforge.net > where it has sources plus some ALT > linux rpms (which i couldn't install). uh, i think that's a bit too much > information. > if you can, i'd be happy if you would send me a response with your decision, > Dan, The whole idea behind extras is that it is a volunteer driven effort. So if you would like to see/have a good package of kguitar, the best way to get such a package is to volunteer to make it, each piece of software needs a packager preferrably one who is actually using the piece of software. I understand from your mail that you're not all that experienced with Linux and/or packaging. This good be a good and fun oppurtinity to learn about and to contribute to Linux. The process for becoming a Fedora Extras contributer and for creating a new package is outlined at: http://fedoraproject.org/wiki/NewPackageProcess I'm willing to be your sponsor for CVS access and I'm going to be your primary reviewer. For now I think it best not to start the CVS access procedure but first try to get a package and then I'll import it into CVS. I'm also willing to help you with the actual packaging, but I can't do it completly for you since I'm not a regular user of kguitar and as such don't know what options to in/exclude and I'm going to be no good in testing it. For starters I suggest that you find the srpm for the altlinux rpm, this is a special rpm containing the source code and the specfile a specfile is a file which contains instructions for rpm on howto build the rpm. You also need to have the rpmbuild package installed. Once the rpmbuild package is installed, install the srpm from altlinux with "rpm -ivh ". Now you should have a kguitar.spec in /usr/src/redhat/SPECS, goto this directory and do an "rpmbuild -bb kguitar.spec" getting an initial rpm build might be as easy as that. Once that is done review the specfile and make it match: http://fedoraproject.org/wiki/PackagingGuidelines Then do an rpmbuild -bs kguitar.spec, now a srpm should show up under /usr/src/redhat/SRPMS, put the srpm somewhere on the web and mail a link to it to the fedora-extras list with a review request. Regards, Hans From ivazquez at ivazquez.net Sat May 7 08:39:54 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 07 May 2005 04:39:54 -0400 Subject: Request for review: OpenEXR, swish-e In-Reply-To: <1115377802.7124.1.camel@ignacio.ignacio.lan> References: <1114335625.7784.41.camel@ignacio.ignacio.lan> <1115377802.7124.1.camel@ignacio.ignacio.lan> Message-ID: <1115455194.7124.7.camel@ignacio.ignacio.lan> On Fri, 2005-05-06 at 07:10 -0400, Ignacio Vazquez-Abrams wrote: > On Sun, 2005-04-24 at 05:40 -0400, Ignacio Vazquez-Abrams wrote: > > OpenEXR: A high dynamic-range (HDR) image file format > > > > OpenEXR is a high dynamic-range (HDR) image file format developed by > > Industrial Light & Magic for use in computer imaging applications. This > > package contains libraries and sample applications for handling the > > format. > > > > http://fedora.ivazquez.net/files/OpenEXR-1.2.2-1.src.rpm > > > > swish-e: Simple Web Indexing System for Humans - Enhanced > > > > Swish-e is Simple Web Indexing System for Humans - Enhanced. Swish-e can > > quickly and easily index directories of files or remote web sites and > > search the generated indexes. > > > > http://fedora.ivazquez.net/files/swish-e-2.4.3-1.src.rpm > > Bump? Okay, let me reword the question. Does anyone mind if I import these into CVS? -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Sat May 7 12:13:31 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 May 2005 14:13:31 +0200 Subject: [REQUEST] kguitar In-Reply-To: <427C778D.3010304@hhs.nl> References: <427C778D.3010304@hhs.nl> Message-ID: <20050507141331.1ae4b2a3.bugs.michael@gmx.net> On Sat, 07 May 2005 10:08:45 +0200, Hans de Goede wrote: [in reply to Dan Gabriel Ghita] > I'm willing to be your sponsor for CVS access and I'm going to be your > primary reviewer. For now I think it best not to start the CVS access > procedure but first try to get a package and then I'll import it into CVS. When contributors become sponsors is not documented as it has not been decided yet. The current list of sponsors can be found at: http://fedoraproject.org/wiki/Extras/Contributors The list of contributors is out-of-date since the web based accounts system has been opened. From kaboom at oobleck.net Sat May 7 12:15:37 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Sat, 7 May 2005 08:15:37 -0400 (EDT) Subject: Approval needed: fftw3 In-Reply-To: <1115431288.24408.153.camel@ernie> References: <427BE0C4.1040204@ieee.org> <1115431288.24408.153.camel@ernie> Message-ID: On Fri, 6 May 2005, Ed Hill wrote: > Hi Quentin, > > On an FC4t2 system, I checked out the latest fftw3 and all the following > seemed to be in order: > > * specfile is very neat and easy on the eyes [;-)] > * no errors from rpmlint > * built, installed, and un-installed cleanly > * played with the fftwf-wisdom binary (but was not patient > enough for for any exhaustive runs) > * checked file permissions & ownership > > I can't find anything the matter with it so please add my name to a > "reviewed and approved-by" message. My understanding of the new-and-improved package submission process is that you (Ed), not Quentin, would be the one to send the APPROVED message to f-e-commits. I may well have missed something though ;-) later, chris From kaboom at oobleck.net Sat May 7 12:21:24 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Sat, 7 May 2005 08:21:24 -0400 (EDT) Subject: Approval needed: mlmmj In-Reply-To: <20050507120206.4f791a8f.mfleming@enlartenment.com> References: <20050507120206.4f791a8f.mfleming@enlartenment.com> Message-ID: On Sat, 7 May 2005, Michael Fleming wrote: > - As the package should require a mail transport agent, what would be the > best means of ensuring this? I've seen and used "Requires: smtpdaemon" > previously (having seen it in RH specs). Would including this virtual req. > still be the best practice? As long as any ol' MTA will suffice. "Requires: smtpdaemon" will be satisfied by having any one of the 3 MTAs in Core and Extras installed > - The source package also contains two web frontends (one in Perl and > another in PHP) for maintaining the lists and allowing visitors to sign up. > Should they be split off into a subpackage, included in %doc (which I've > seen done for some other packages) or omitted completely (the current > status). Otherwise creation of new lists is via a small shell script > included in the current package - fine for shell access but not overly > convenient. subpackages would be nicest, I'd think later, chris From kaboom at oobleck.net Sat May 7 12:22:37 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Sat, 7 May 2005 08:22:37 -0400 (EDT) Subject: Review request: syslog-ng (syslog replacement daemon) In-Reply-To: <427C0BF2.9000304@di.uminho.pt> References: <427C0BF2.9000304@di.uminho.pt> Message-ID: On Sat, 7 May 2005, Jos? Pedro Oliveira wrote: > * Changes a file from another package > (/etc/logrotate.d/syslog from the sysklogd rpm) I know people (with good reason!) try to avoid using alternatives, but isn't this a good case to use them? later, chris From mfleming at enlartenment.com Sat May 7 13:14:16 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Sat, 7 May 2005 23:14:16 +1000 Subject: Approval needed: mlmmj In-Reply-To: References: <20050507120206.4f791a8f.mfleming@enlartenment.com> Message-ID: <20050507231416.45417926.mfleming@enlartenment.com> On Sat, 7 May 2005 08:21:24 -0400 (EDT). Chris Ricker waffled thusly: > On Sat, 7 May 2005, Michael Fleming wrote: > > > - As the package should require a mail transport agent, what would be > > the best means of ensuring this? I've seen and used "Requires: > > smtpdaemon" previously (having seen it in RH specs). Would including > > this virtual req. still be the best practice? > > As long as any ol' MTA will suffice. If the MTA understands foo+bar style extensions it should be fine. VERP support is a plus for bounce handling. > "Requires: smtpdaemon" will be > satisfied by having any one of the 3 MTAs in Core and Extras installed Sendmail / Postfix / Exim as shipped by FC / FE should be fine with this software. The only obviously problematic MTAs would be qmail and courier, but they have their own mailing list management software anyway ;-) > > > - The source package also contains two web frontends (one in Perl and > > another in PHP) for maintaining the lists and allowing visitors to sign > > up. Should they be split off into a subpackage, included in %doc (which > > I've seen done for some other packages) or omitted completely (the > > current status). Otherwise creation of new lists is via a small shell > > script included in the current package - fine for shell access but not > > overly convenient. > > subpackages would be nicest, I'd think This is possible, probably simpler - but the Requires: would be a case of "left as an exercise for the reader" unless you want it to get a little hairy (not /everyone/ has *both* PHP and perl on the system..) Catering for users of servers != httpd/Apache could be interesting though.. I'll look into it - once the main package gets approved and built first :-) > later, > chris Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From ed at eh3.com Sat May 7 13:24:24 2005 From: ed at eh3.com (Ed Hill) Date: Sat, 07 May 2005 09:24:24 -0400 Subject: Approval needed: fftw3 In-Reply-To: References: <427BE0C4.1040204@ieee.org> <1115431288.24408.153.camel@ernie> Message-ID: <1115472265.24408.198.camel@ernie> On Sat, 2005-05-07 at 08:15 -0400, Chris Ricker wrote: > On Fri, 6 May 2005, Ed Hill wrote: > > I can't find anything the matter with it so please add my name to a > > "reviewed and approved-by" message. > > My understanding of the new-and-improved package submission process is > that you (Ed), not Quentin, would be the one to send the APPROVED message > to f-e-commits. I may well have missed something though ;-) Hi Chris, Is that true? If so, I'll try to follow it next time around. Please understand that I have only a tenuous grasp of the "official process". It seems to be a moving target. ;-) Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From bugs.michael at gmx.net Sat May 7 13:27:22 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 May 2005 15:27:22 +0200 Subject: Review request: syslog-ng (syslog replacement daemon) In-Reply-To: References: <427C0BF2.9000304@di.uminho.pt> Message-ID: <20050507152722.059a0444.bugs.michael@gmx.net> On Sat, 7 May 2005 08:22:37 -0400 (EDT), Chris Ricker wrote: > On Sat, 7 May 2005, Jos? Pedro Oliveira wrote: > > > * Changes a file from another package > > (/etc/logrotate.d/syslog from the sysklogd rpm) > > I know people (with good reason!) try to avoid using alternatives, but > isn't this a good case to use them? Unless we continue with discussion of the old "Fedora Alternatives" concept, a package that changes a file from another package and even stops Core's syslog service in its scriptlets, sounds very much like it's unacceptable. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Sat May 7 13:37:17 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 May 2005 15:37:17 +0200 Subject: wxGTK (was: Re: Package Build Report - Fedora Extras Development) In-Reply-To: <1115346541.24385.724.camel@mccallum.corsepiu.local> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> <1115307543.24385.698.camel@mccallum.corsepiu.local> <20050505181522.30e74d4c.bugs.michael@gmx.net> <1115310933.24385.711.camel@mccallum.corsepiu.local> <20050505192754.729380cd.bugs.michael@gmx.net> <1115322770.24385.716.camel@mccallum.corsepiu.local> <1115327380.3374.8.camel@bree.local.net> <1115346541.24385.724.camel@mccallum.corsepiu.local> Message-ID: <20050507153717.430443bf.bugs.michael@gmx.net> So, meanwhile I tried the more recent approach, Buildrequires: libGL libGLU which is new since FC4 Development. They are virtual provides in the xorg-x11-Mesa-libGL and xorg-x11-Mesa-libGLU packages. Interestingly, on x86_64, the build still fails in the new build system: checking for GL/gl.h... yes checking for -lGL... no checking for -lMesaGL... no configure: error: OpenGL libraries not available error: Bad exit status from /var/tmp/rpm-tmp.48063 (%build) So, what packages did yum install? The i386 versions again? Mesa is multilib for x86_64. [Note that we managed to build the same package for x86_64 earlier.] From rc040203 at freenet.de Sat May 7 13:58:48 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 07 May 2005 15:58:48 +0200 Subject: wxGTK (was: Re: Package Build Report - Fedora Extras Development) In-Reply-To: <20050507153717.430443bf.bugs.michael@gmx.net> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> <1115307543.24385.698.camel@mccallum.corsepiu.local> <20050505181522.30e74d4c.bugs.michael@gmx.net> <1115310933.24385.711.camel@mccallum.corsepiu.local> <20050505192754.729380cd.bugs.michael@gmx.net> <1115322770.24385.716.camel@mccallum.corsepiu.local> <1115327380.3374.8.camel@bree.local.net> <1115346541.24385.724.camel@mccallum.corsepiu.local> <20050507153717.430443bf.bugs.michael@gmx.net> Message-ID: <1115474329.8237.25.camel@mccallum.corsepiu.local> On Sat, 2005-05-07 at 15:37 +0200, Michael Schwendt wrote: > So, meanwhile I tried the more recent approach, > > Buildrequires: libGL libGLU > > which is new since FC4 Development. They are virtual provides in the > xorg-x11-Mesa-libGL and xorg-x11-Mesa-libGLU packages. Interestingly, > on x86_64, the build still fails in the new build system: > > checking for GL/gl.h... yes > checking for -lGL... no > checking for -lMesaGL... no > configure: error: OpenGL libraries not available > error: Bad exit status from /var/tmp/rpm-tmp.48063 (%build) > > So, what packages did yum install? The i386 versions again? Probably. > Mesa is > multilib for x86_64. # rpm -q --provides -p /tmp/xorg-x11-Mesa-libGL-6.8.2-19.x86_64.rpm Mesa libGL = 1 libGL.so.1()(64bit) xorg-x11-Mesa-libGL = 6.8.2-19 As you can see, libGL is not "arched" while "libGL.so.1" is :) > [Note that we managed to build the same package for x86_64 earlier.] I guess yum first searches packagenames "by architecture" (Therefore xorg-x11-Mesa-libGL succeeds), then virtual provides ... (And finds one at random). Realize it "virtual provides" are just "fscked up" and have become unusable :( Ralf From mattdm at mattdm.org Sat May 7 14:03:49 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 7 May 2005 10:03:49 -0400 Subject: Review request: syslog-ng (syslog replacement daemon) In-Reply-To: References: <427C0BF2.9000304@di.uminho.pt> Message-ID: <20050507140349.GA10387@jadzia.bu.edu> On Sat, May 07, 2005 at 08:22:37AM -0400, Chris Ricker wrote: > > * Changes a file from another package > > (/etc/logrotate.d/syslog from the sysklogd rpm) > I know people (with good reason!) try to avoid using alternatives, but > isn't this a good case to use them? I haven't looked at this particular case, but if this is the only change needed, might there be a way to generalize the /etc/logrotate.d/syslog file in the syslog RPM? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 75 degrees Fahrenheit. From bugs.michael at gmx.net Sat May 7 14:15:17 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 May 2005 16:15:17 +0200 Subject: wxGTK (was: Re: Package Build Report - Fedora Extras Development) In-Reply-To: <1115474329.8237.25.camel@mccallum.corsepiu.local> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> <1115307543.24385.698.camel@mccallum.corsepiu.local> <20050505181522.30e74d4c.bugs.michael@gmx.net> <1115310933.24385.711.camel@mccallum.corsepiu.local> <20050505192754.729380cd.bugs.michael@gmx.net> <1115322770.24385.716.camel@mccallum.corsepiu.local> <1115327380.3374.8.camel@bree.local.net> <1115346541.24385.724.camel@mccallum.corsepiu.local> <20050507153717.430443bf.bugs.michael@gmx.net> <1115474329.8237.25.camel@mccallum.corsepiu.local> Message-ID: <20050507161517.33e3333a.bugs.michael@gmx.net> On Sat, 07 May 2005 15:58:48 +0200, Ralf Corsepius wrote: > On Sat, 2005-05-07 at 15:37 +0200, Michael Schwendt wrote: > > So, meanwhile I tried the more recent approach, > > > > Buildrequires: libGL libGLU > > > > which is new since FC4 Development. They are virtual provides in the > > xorg-x11-Mesa-libGL and xorg-x11-Mesa-libGLU packages. Interestingly, > > on x86_64, the build still fails in the new build system: > > > > checking for GL/gl.h... yes > > checking for -lGL... no > > checking for -lMesaGL... no > > configure: error: OpenGL libraries not available > > error: Bad exit status from /var/tmp/rpm-tmp.48063 (%build) > > > > So, what packages did yum install? The i386 versions again? > Probably. > > > Mesa is > > multilib for x86_64. > # rpm -q --provides -p /tmp/xorg-x11-Mesa-libGL-6.8.2-19.x86_64.rpm > Mesa > libGL = 1 > libGL.so.1()(64bit) > xorg-x11-Mesa-libGL = 6.8.2-19 > > As you can see, libGL is not "arched" while "libGL.so.1" is :) "Buildrequires: xorg-x11-devel" is not arch-specific either, so what do we get when using it in a spec file? What is installed into the mach chroot for an x86_64 build? The i386 version? The x86_64 version? Or both? For a package which did built fine in a full multilib installation before (else I can't explain why we do have wxGTK for x86_64), what do we get now for "Buildrequires: foo-devel" on x86_64 in the clean chroot? Just the x86_64 package or i386 _and_ x86_64 package if both are available? From bugs.michael at gmx.net Sat May 7 14:21:08 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 May 2005 16:21:08 +0200 Subject: Approval needed: fftw3 In-Reply-To: <1115472265.24408.198.camel@ernie> References: <427BE0C4.1040204@ieee.org> <1115431288.24408.153.camel@ernie> <1115472265.24408.198.camel@ernie> Message-ID: <20050507162108.2d9c0b72.bugs.michael@gmx.net> On Sat, 07 May 2005 09:24:24 -0400, Ed Hill wrote: > On Sat, 2005-05-07 at 08:15 -0400, Chris Ricker wrote: > > On Fri, 6 May 2005, Ed Hill wrote: > > > I can't find anything the matter with it so please add my name to a > > > "reviewed and approved-by" message. > > > > My understanding of the new-and-improved package submission process is > > that you (Ed), not Quentin, would be the one to send the APPROVED message > > to f-e-commits. I may well have missed something though ;-) > > Hi Chris, > > Is that true? If so, I'll try to follow it next time around. > > Please understand that I have only a tenuous grasp of the "official > process". It seems to be a moving target. ;-) It isn't a moving target. Feel free to compare the old page version in the Wiki with the current version. Either version only says that explicit approval must be posted. It is not said who must send the message. From toshio at tiki-lounge.com Sat May 7 14:26:12 2005 From: toshio at tiki-lounge.com (Toshio) Date: Sat, 07 May 2005 10:26:12 -0400 Subject: Approval needed: mlmmj In-Reply-To: <20050507231416.45417926.mfleming@enlartenment.com> References: <20050507120206.4f791a8f.mfleming@enlartenment.com> <20050507231416.45417926.mfleming@enlartenment.com> Message-ID: <1115475973.4296.1.camel@Madison.badger.com> On Sat, 2005-05-07 at 23:14 +1000, Michael Fleming wrote: > On Sat, 7 May 2005 08:21:24 -0400 (EDT). Chris Ricker waffled thusly: > > > On Sat, 7 May 2005, Michael Fleming wrote: > > > - The source package also contains two web frontends (one in Perl and > > > another in PHP) for maintaining the lists and allowing visitors to sign > > > up. Should they be split off into a subpackage, included in %doc (which > > > I've seen done for some other packages) or omitted completely (the > > > current status). Otherwise creation of new lists is via a small shell > > > script included in the current package - fine for shell access but not > > > overly convenient. > > > > subpackages would be nicest, I'd think > > This is possible, probably simpler - but the Requires: would be a case of > "left as an exercise for the reader" unless you want it to get a little > hairy (not /everyone/ has *both* PHP and perl on the system..) > Why not separate subpackages for each front-end? Seems most admins would install one that uses php _or_ one that uses perl, not both. -Toshio -- ______S______U______B______L______I______M______I______N______A______L______ t o s h i o @ t i k i - l o u n g e . c o m GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Sat May 7 14:42:47 2005 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 07 May 2005 10:42:47 -0400 Subject: Review request: syslog-ng (syslog replacement daemon) In-Reply-To: <20050507140349.GA10387@jadzia.bu.edu> References: <427C0BF2.9000304@di.uminho.pt> <20050507140349.GA10387@jadzia.bu.edu> Message-ID: <1115476967.3302.70.camel@bree.local.net> On Sat, 2005-05-07 at 10:03 -0400, Matthew Miller wrote: > On Sat, May 07, 2005 at 08:22:37AM -0400, Chris Ricker wrote: > > > * Changes a file from another package > > > (/etc/logrotate.d/syslog from the sysklogd rpm) > > I know people (with good reason!) try to avoid using alternatives, but > > isn't this a good case to use them? > > I haven't looked at this particular case, but if this is the only change > needed, might there be a way to generalize the /etc/logrotate.d/syslog file > in the syslog RPM? My guess (just from a quick look at /etc/logrotate.d/syslog) is that this is due to the kill -HUP of the syslog process. Having syslog-ng use the same pid file could work, but could have other consequences that I'm not thinking of at the moment. Especially as I haven't looked at syslog-ng in a long time :-) Jeremy From skvidal at phy.duke.edu Sat May 7 14:44:49 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 07 May 2005 10:44:49 -0400 Subject: Fedora Extras 3 Build Report Message-ID: <1115477089.15593.28.camel@cutter> Failed: gcl graveman python-cherrypy - cvs tag seems wrong amarok - timed out (how long does it take to build this) ulogd - wrong source file uploaded js - timeout on x86_64 xfce4-session xfcalendar xfce4-mixer gnome-applet-netspeed cone blacs scalapack R-RScaLAPACK librx pam_mount - cvs tag for FC-3 is wrong enigma http://extras64.linux.duke.edu/failed/3/ About the timeout: In order to keep a job from getting stuck in an infinite loop or other hanging problem I put a 1 hour limit on any 1 build process. If the job isn't finished w/i an hour it will be killed. amarok and js both timed out trying to complete their builds. I'm going to raise the time to 2 hours and resubmit the jobs. Thanks, -sv From j.w.r.degoede at hhs.nl Sat May 7 14:48:45 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 07 May 2005 16:48:45 +0200 Subject: [REQUEST] kguitar In-Reply-To: <20050507141331.1ae4b2a3.bugs.michael@gmx.net> References: <427C778D.3010304@hhs.nl> <20050507141331.1ae4b2a3.bugs.michael@gmx.net> Message-ID: <427CD54D.9030108@hhs.nl> Michael Schwendt wrote: > On Sat, 07 May 2005 10:08:45 +0200, Hans de Goede wrote: > > [in reply to Dan Gabriel Ghita] > > >>I'm willing to be your sponsor for CVS access and I'm going to be your >>primary reviewer. For now I think it best not to start the CVS access >>procedure but first try to get a package and then I'll import it into CVS. > > > When contributors become sponsors is not documented as it has not been > decided yet. The current list of sponsors can be found at: > http://fedoraproject.org/wiki/Extras/Contributors > > The list of contributors is out-of-date since the web based accounts > system has been opened. > Ah, My bad, I thought I could sponsor people because since I've got CVS-access I've been getting these mails that there were people looking for sponsors, since these mails did not come through the fedora-extras list I assumed they were targeted at people who could sponsor. Anyways as said Dan Gabriel Ghita: Just go ahead and try to create a srpm I'll review and commit it to CVS, once you're familiar with spec files and CVS you can ask for a CVsSaccount, unfortunatly I can't sponsor you but I'm sure someone else will. Regards, Hans From katzj at redhat.com Sat May 7 14:48:26 2005 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 07 May 2005 10:48:26 -0400 Subject: Review request: syslog-ng (syslog replacement daemon) In-Reply-To: <427C0BF2.9000304@di.uminho.pt> References: <427C0BF2.9000304@di.uminho.pt> Message-ID: <1115477307.3302.77.camel@bree.local.net> On Sat, 2005-05-07 at 01:29 +0100, Jos? Pedro Oliveira wrote: > Notes: > * Stops the syslog daemon during installation This definitely seems non-ideal. You don't want to be stopping a different service when you install yourself. The fact that you can't run both of them at once just means you have to do a little bit of service configuration to get the one you want running after you install it. This is no different than installing, eg, an http daemon other than httpd. > * Changes a file from another package > (/etc/logrotate.d/syslog from the sysklogd rpm) Better to figure out how to generalize this. See my later mail. > * currently it doesn't change the use_syslogng SELinux boolean I don't see any other packages doing anything like this at the moment, and I'm not entirely sure how I feel about it.[1] Looking at what the boolean allows, I think that some of them at least are valid in the case of sysklogd where you're using a remote syslog server. cc'ing Dan to see if he has an opinion here. Jeremy [1] I still maintain that policy for a package should be maintained with and shipped in the package. That would make this a much easier question :-) Unfortunately, policy tools aren't there yet although I'm hopeful about progress in this area over time. From dwmw2 at infradead.org Sat May 7 14:56:31 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 07 May 2005 15:56:31 +0100 Subject: Fedora Extras Development Build Report In-Reply-To: <20050507051054.195e5e08.bugs.michael@gmx.net> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> Message-ID: <1115477793.29495.116.camel@localhost.localdomain> On Sat, 2005-05-07 at 05:10 +0200, Michael Schwendt wrote: > Hmmm, missing gpgme-devel on ppc, most likely because gnupg2 fails > to build there. No, gnupg2 builds fine on PPC. According to the log the failure seems to have been due to the absence of gpgme -- although I'm not entirely sure why that should be the case; gpgme builds fine too. As does seahorse, if its dependencies are actually installed correctly before you try to build it. I've looked at three supposed PPC failures today, two of which were apparently due to a simple failure to install dependencies, and the third of which lacks a build log but I guess it was probably the same. All three of those packages build fine for me. > If there are still proponents of the "one failing arch blocks all other > archs", it's about time for arch-specific community contributors to help > with fixing packages which fail. The offer of access to a PPC machine for package maintainers if they're having problems is still open. The machine I set aside for that is still on FC3 at the moment, but I suppose I should update it to FC4 some time soon. While I'm happy enough to help out if anyone is having difficulty, we do need _maintainers_ for Extras packages, not just package-monkeys. -- dwmw2 From bugs.michael at gmx.net Sat May 7 15:03:53 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 May 2005 17:03:53 +0200 Subject: Fedora Extras Development Build Report In-Reply-To: <1115477793.29495.116.camel@localhost.localdomain> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> Message-ID: <20050507170353.47f61c37.bugs.michael@gmx.net> On Sat, 07 May 2005 15:56:31 +0100, David Woodhouse wrote: > On Sat, 2005-05-07 at 05:10 +0200, Michael Schwendt wrote: > > Hmmm, missing gpgme-devel on ppc, most likely because gnupg2 fails > > to build there. > > No, gnupg2 builds fine on PPC. It did not. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156213 http://fedoraproject.org/extras/development/build-logs/ppc/gnupg2-1.9.15-2.log Sometimes build failures are specific to mach or clean(er) chroots. From skvidal at phy.duke.edu Sat May 7 15:08:08 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 07 May 2005 11:08:08 -0400 Subject: Package Build Report - Fedora Extras Development In-Reply-To: <1115305044.4106.103.camel@localhost.localdomain> References: <1115296548.24970.11.camel@cutter> <1115305044.4106.103.camel@localhost.localdomain> Message-ID: <1115478488.15593.38.camel@cutter> On Thu, 2005-05-05 at 09:57 -0500, Tom 'spot' Callaway wrote: > On Thu, 2005-05-05 at 08:35 -0400, seth vidal wrote: > > The following packages failed to build on Fedora Extras Development: > > librx > > Fixed, was missing BuildRequires: texinfo, both FC-3 and devel branch > re-tagged. > > > perl-OLE-Storage_Lite > > I can't figure out why this failed from the log. > > > blacs > > Fixed, both FC-3 and devel branch re-tagged. > > > scalapack > > R-RScaLAPACK > > Both failed because blacs failed. > > R-gnomeGUI is also on your website as failed, but the logs don't > indicate whether it really failed or not (or if it did, why). If you would - go ahead and resubmit these to the build system please. just use make build etc etc. thanks -sv From bugs.michael at gmx.net Sat May 7 15:10:09 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 May 2005 17:10:09 +0200 Subject: Fedora Extras 3 Build Report In-Reply-To: <1115477089.15593.28.camel@cutter> References: <1115477089.15593.28.camel@cutter> Message-ID: <20050507171009.08999e42.bugs.michael@gmx.net> On Sat, 07 May 2005 10:44:49 -0400, seth vidal wrote: > Failed: > gcl > graveman > python-cherrypy - cvs tag seems wrong > amarok - timed out (how long does it take to build this) > ulogd - wrong source file uploaded > js - timeout on x86_64 > xfce4-session > xfcalendar > xfce4-mixer > gnome-applet-netspeed > cone > blacs > scalapack > R-RScaLAPACK > librx > pam_mount - cvs tag for FC-3 is wrong > enigma > > http://extras64.linux.duke.edu/failed/3/ > > About the timeout: In order to keep a job from getting stuck in an > infinite loop or other hanging problem I put a 1 hour limit on any 1 > build process. If the job isn't finished w/i an hour it will be killed. > amarok and js both timed out trying to complete their builds. I'm going > to raise the time to 2 hours and resubmit the jobs. I don't understand this. For instance, you've built "cone" successfully before into updates-testing. If I read the Wiki page correctly, the request asked to move the updates-testing version into the main repository. Why did the unexpected rebuild fail? And why are there complete i386 binaries, but the x86_64 log is empty except for the timeout message? Did it time out because it's C++ code which took more than an hour to build? I can't believe that. Do you build the packages in the queue in parallel or one by one? -- Fedora Core release 3 (Heidelberg) - Linux 2.6.11-1.14_FC3 loadavg: 1.29 1.17 1.16 From dwmw2 at infradead.org Sat May 7 15:12:36 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 07 May 2005 16:12:36 +0100 Subject: Fedora Extras Development Build Report In-Reply-To: <20050507170353.47f61c37.bugs.michael@gmx.net> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> Message-ID: <1115478757.29495.122.camel@localhost.localdomain> On Sat, 2005-05-07 at 17:03 +0200, Michael Schwendt wrote: > It did not. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156213 > http://fedoraproject.org/extras/development/build-logs/ppc/gnupg2-1.9.15-2.log Strange. It did for me an hour or two ago. > Sometimes build failures are specific to mach or clean(er) chroots. It could also have been a gcc bug which is since fixed. Did the package maintainer actually look into it? _Is_ there a package maintainer? Why is there a gnupg2-1.9.15-2.i386.rpm in Extras for i386? If the package fails to build, it shouldn't get into the tree. -- dwmw2 From skvidal at phy.duke.edu Sat May 7 15:14:21 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 07 May 2005 11:14:21 -0400 Subject: Package Build Report - Fedora Extras Development In-Reply-To: <20050505174942.1707e8ca@python2> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> <20050505174942.1707e8ca@python2> Message-ID: <1115478861.15593.43.camel@cutter> > My opinion would be to only have x86_64 and noarch packages available for > the x86_64 build root, and no let any i?86 packages be available to it, > since it makes no sense anyway for a build root. > > I've already bumped into this problem myself, and my solution has been to > create a "static" RPMS directory with all i?86.rpm packages removed and > createrepo re-run on top of that. The cleaner fix would be to disable > multiarch support in the yum used for the x86_64 build root, but I don't > think that's possible with the current yum (seth will know for sure ;-)). maybe another way would be to see about using --exclude*.i?86 instead. There's no good way to disable multilib support in yum. It'd be ridiculous to include such a feature, really, b/c you can just exclude ix86 packages and multilib has no meaning. -sv From skvidal at phy.duke.edu Sat May 7 15:15:31 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 07 May 2005 11:15:31 -0400 Subject: Package Build Reports - Fedora Extras Development In-Reply-To: <20050505153904.26F2B454362@ningauble.scrye.com> References: <1115274619.22456.14.camel@cutter> <20050505153904.26F2B454362@ningauble.scrye.com> Message-ID: <1115478932.15593.45.camel@cutter> On Thu, 2005-05-05 at 09:39 -0600, Kevin Fenzi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>>>> "seth" == seth vidal writes: > > seth> Package Build Errors: > seth> ... > seth> xfwm4 > > seth> See: http://extras64.linux.duke.edu/failed/development/ for the > seth> logs. > > Looks like the problem was that it failed on ppc in requirements: > > libxfce4mcs-devel >= 4.2.1 is needed by xfwm4-4.2.1-5.fc4.ppc > libxfcegui4-devel >= 4.2.1 is needed by xfwm4-4.2.1-5.fc4.ppc > xfce-mcs-manager-devel >= 4.2.1 is needed by xfwm4-4.2.1-5.fc4.ppc > > All the other Xfce packages were not built on ppc, so it doesn't have > the requirements. > > I have no idea if the packages do build correctly on ppc (not having a > ppc test machine around), but it would be cool if they did. ;) > > So, should I wait and request builds of the other Xfce packages on > ppc? > > Or is there some way to just request i386/x86_64 builds with the new > build setup? > > The build system looks really cool... thanks for the great work you > guys have put in on it! as I just posted to fedora-maintainers - you can now request builds. request them in the right order, of course. just built packages are available as dependencies to building packages. -sv From skvidal at phy.duke.edu Sat May 7 15:17:11 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 07 May 2005 11:17:11 -0400 Subject: Fedora Extras 3 Build Report In-Reply-To: <20050507171009.08999e42.bugs.michael@gmx.net> References: <1115477089.15593.28.camel@cutter> <20050507171009.08999e42.bugs.michael@gmx.net> Message-ID: <1115479031.15593.47.camel@cutter> > I don't understand this. For instance, you've built "cone" successfully > before into updates-testing. If I read the Wiki page correctly, the > request asked to move the updates-testing version into the main > repository. Why did the unexpected rebuild fail? And why are there > complete i386 binaries, but the x86_64 log is empty except for the > timeout message? Did it time out because it's C++ code which took > more than an hour to build? I can't believe that. > > Do you build the packages in the queue in parallel or one by one? They build one by one. The arches build in parallel for any one package. it is probably the case that cone failed to rebuild b/c c++ takes so long to rebuild. I'll be glad to resubmit it. -sv From bugs.michael at gmx.net Sat May 7 15:28:00 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 May 2005 17:28:00 +0200 Subject: Fedora Extras Development Build Report In-Reply-To: <1115478757.29495.122.camel@localhost.localdomain> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> <1115478757.29495.122.camel@localhost.localdomain> Message-ID: <20050507172800.6eec367c.bugs.michael@gmx.net> On Sat, 07 May 2005 16:12:36 +0100, David Woodhouse wrote: > On Sat, 2005-05-07 at 17:03 +0200, Michael Schwendt wrote: > > It did not. > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156213 > > http://fedoraproject.org/extras/development/build-logs/ppc/gnupg2-1.9.15-2.log > > Strange. It did for me an hour or two ago. > > > Sometimes build failures are specific to mach or clean(er) chroots. > > It could also have been a gcc bug which is since fixed. Did the package > maintainer actually look into it? _Is_ there a package maintainer? > > Why is there a gnupg2-1.9.15-2.i386.rpm in Extras for i386? If the > package fails to build, it shouldn't get into the tree. We did not build for ppc when Fedora Extras started. Later x86_64 was added. And then ppc. "Where we are" with regard to maintaining packages, is something we need to find out... From dwmw2 at infradead.org Sat May 7 15:33:51 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 07 May 2005 16:33:51 +0100 Subject: Fedora Extras Development Build Report In-Reply-To: <20050507172800.6eec367c.bugs.michael@gmx.net> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> <1115478757.29495.122.camel@localhost.localdomain> <20050507172800.6eec367c.bugs.michael@gmx.net> Message-ID: <1115480032.29495.127.camel@localhost.localdomain> On Sat, 2005-05-07 at 17:28 +0200, Michael Schwendt wrote: > We did not build for ppc when Fedora Extras started. > Later x86_64 was added. And then ppc. > > "Where we are" with regard to maintaining packages, is something we > need to find out... Agreed. We really need to work with the same policy as Core does -- a build failure on one arch is a build failure on all. We can't let package versions just drift out of sync between architectures due to spurious failures. It's bad enough in Core when people can just add ExcludeArch: to work around temporary problems and get a package through the build system. We really ought to have a policy of requiring a bug to be filed for every exclusion, even in Core. _Certainly_ we shouldn't be allowing a build to succeed for one architecture while it fails on others. -- dwmw2 From ed at eh3.com Sat May 7 15:39:43 2005 From: ed at eh3.com (Ed Hill) Date: Sat, 07 May 2005 11:39:43 -0400 Subject: [REQUEST] kguitar In-Reply-To: <427CD54D.9030108@hhs.nl> References: <427C778D.3010304@hhs.nl> <20050507141331.1ae4b2a3.bugs.michael@gmx.net> <427CD54D.9030108@hhs.nl> Message-ID: <1115480384.24408.203.camel@ernie> On Sat, 2005-05-07 at 16:48 +0200, Hans de Goede wrote: > > The list of contributors is out-of-date since the web based accounts > > system has been opened. > > My bad, I thought I could sponsor people because since I've got > CVS-access I've been getting these mails that there were people looking > for sponsors, since these mails did not come through the fedora-extras > list I assumed they were targeted at people who could sponsor. Yeah, I was meaning to ask that question as well. I assumed that the email was sent to me in error but you just don't 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 denis at poolshark.org Sat May 7 15:42:25 2005 From: denis at poolshark.org (Denis Leroy) Date: Sat, 07 May 2005 08:42:25 -0700 Subject: New Package: Gossip In-Reply-To: <4279BD3F.8080204@poolshark.org> References: <1114976827.25152.4.camel@localhost.localdomain> <1115251885.11623.1.camel@localhost.localdomain> <4279BD3F.8080204@poolshark.org> Message-ID: <427CE1E1.3030008@poolshark.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Denis Leroy wrote: > Brian Pepple wrote: > >>>On Sun, 2005-05-01 at 19:47 +0000, Brian Pepple wrote: >>> >>> >>>>Gossip: Gnome Jabber client. >>>>http://piedmont.homelinux.org/fedora/gossip/gossip.spec >>>>http://piedmont.homelinux.org/fedora/gossip/gossip-0.8-2.src.rpm > > > OK: > > - MD5sums > a593dfc42055daf88f18aa85a5cfbb70 gossip-0.8-2.src.rpm > 8bbe3dac8d0da7e0b936971a01545f14 gossip-0.8.tar.bz2 > - upstream tarball verified > - license is GPL > - packaging guidelines > - rpmlint ok > > Blockers: > > - builds on FC3 but NOT on FC4t2. At first glance, it looks as though > it can't compile against dbus 0.33 (while FC3 has dbus 0.22). > > - /usr/share/gossip/ and /usr/share/gossip/protocols/ not owned by RPM. > http://piedmont.homelinux.org/fedora/gossip/gossip.spec http://piedmont.homelinux.org/fedora/gossip/gossip-0.8-3.src.rpm MD5sums: 7bfce7f3c07b69a1fa2dd816e1d01b26 gossip-0.8-3.src.rpm 8bbe3dac8d0da7e0b936971a01545f14 gossip-0.8.tar.bz2 Blockers above were fixed. All looking good to me, i hereby approve of this package. :-) Cheers, - -denis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCfOHhN21V2B2op6oRAgE0AJ9jzYh7kzpPHRwxQJopMKjkTodHPQCfaDud qjMtp82yfjX3V00PlyE2+LI= =MyJB -----END PGP SIGNATURE----- From bugs.michael at gmx.net Sat May 7 15:46:00 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 May 2005 17:46:00 +0200 Subject: Fedora Account System alert mails (was: Re: [REQUEST] kguitar) In-Reply-To: <1115480384.24408.203.camel@ernie> References: <427C778D.3010304@hhs.nl> <20050507141331.1ae4b2a3.bugs.michael@gmx.net> <427CD54D.9030108@hhs.nl> <1115480384.24408.203.camel@ernie> Message-ID: <20050507174600.573976e2.bugs.michael@gmx.net> On Sat, 07 May 2005 11:39:43 -0400, Ed Hill wrote: > > My bad, I thought I could sponsor people because since I've got > > CVS-access I've been getting these mails that there were people looking > > for sponsors, since these mails did not come through the fedora-extras > > list I assumed they were targeted at people who could sponsor. > > Yeah, I was meaning to ask that question as well. I assumed that the > email was sent to me in error but you just don't know... ;-) It is sent in error unless you see yourself in the accounts system as being flagged as a "sponsor". From fedora at leemhuis.info Sat May 7 15:54:42 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 07 May 2005 17:54:42 +0200 Subject: wxGTK (was: Re: Package Build Report - Fedora Extras Development) In-Reply-To: <20050507161517.33e3333a.bugs.michael@gmx.net> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> <1115307543.24385.698.camel@mccallum.corsepiu.local> <20050505181522.30e74d4c.bugs.michael@gmx.net> <1115310933.24385.711.camel@mccallum.corsepiu.local> <20050505192754.729380cd.bugs.michael@gmx.net> <1115322770.24385.716.camel@mccallum.corsepiu.local> <1115327380.3374.8.camel@bree.local.net> <1115346541.24385.724.camel@mccallum.corsepiu.local> <20050507153717.430443bf.bugs.michael@gmx.net> <1115474329.8237.25.camel@mccallum.corsepiu.local> <20050507161517.33e3333a.bugs.michael@gmx.net> Message-ID: <1115481282.5422.3.camel@notebook.thl.home> Am Samstag, den 07.05.2005, 16:15 +0200 schrieb Michael Schwendt: > On Sat, 07 May 2005 15:58:48 +0200, Ralf Corsepius wrote: > > On Sat, 2005-05-07 at 15:37 +0200, Michael Schwendt wrote: > > > Mesa is > > > multilib for x86_64. > > # rpm -q --provides -p /tmp/xorg-x11-Mesa-libGL-6.8.2-19.x86_64.rpm > > Mesa > > libGL = 1 > > libGL.so.1()(64bit) > > xorg-x11-Mesa-libGL = 6.8.2-19 > > > > As you can see, libGL is not "arched" while "libGL.so.1" is :) > "Buildrequires: xorg-x11-devel" is not arch-specific either, so what > do we get when using it in a spec file? > > What is installed into the mach chroot for an x86_64 build? The i386 > version? The x86_64 version? Or both? Both (at last will all yum-mach versions I've used). -- Thorsten Leemhuis From skvidal at phy.duke.edu Sat May 7 15:57:20 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 07 May 2005 11:57:20 -0400 Subject: wxGTK (was: Re: Package Build Report - Fedora Extras Development) In-Reply-To: <1115481282.5422.3.camel@notebook.thl.home> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> <1115307543.24385.698.camel@mccallum.corsepiu.local> <20050505181522.30e74d4c.bugs.michael@gmx.net> <1115310933.24385.711.camel@mccallum.corsepiu.local> <20050505192754.729380cd.bugs.michael@gmx.net> <1115322770.24385.716.camel@mccallum.corsepiu.local> <1115327380.3374.8.camel@bree.local.net> <1115346541.24385.724.camel@mccallum.corsepiu.local> <20050507153717.430443bf.bugs.michael@gmx.net> <1115474329.8237.25.camel@mccallum.corsepiu.local> <20050507161517.33e3333a.bugs.michael@gmx.net> <1115481282.5422.3.camel@notebook.thl.home> Message-ID: <1115481440.15593.52.camel@cutter> > > > > What is installed into the mach chroot for an x86_64 build? The i386 > > version? The x86_64 version? Or both? > > Both (at last will all yum-mach versions I've used). It seems like a build error to me if it won't build with both installed. -sv From bugs.michael at gmx.net Sat May 7 16:07:27 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 May 2005 18:07:27 +0200 Subject: wxGTK (was: Re: Package Build Report - Fedora Extras Development) In-Reply-To: <1115481440.15593.52.camel@cutter> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> <1115307543.24385.698.camel@mccallum.corsepiu.local> <20050505181522.30e74d4c.bugs.michael@gmx.net> <1115310933.24385.711.camel@mccallum.corsepiu.local> <20050505192754.729380cd.bugs.michael@gmx.net> <1115322770.24385.716.camel@mccallum.corsepiu.local> <1115327380.3374.8.camel@bree.local.net> <1115346541.24385.724.camel@mccallum.corsepiu.local> <20050507153717.430443bf.bugs.michael@gmx.net> <1115474329.8237.25.camel@mccallum.corsepiu.local> <20050507161517.33e3333a.bugs.michael@gmx.net> <1115481282.5422.3.camel@notebook.thl.home> <1115481440.15593.52.camel@cutter> Message-ID: <20050507180727.3e5a2fe2.bugs.michael@gmx.net> On Sat, 07 May 2005 11:57:20 -0400, seth vidal wrote: > > > > > > What is installed into the mach chroot for an x86_64 build? The i386 > > > version? The x86_64 version? Or both? > > > > Both (at last will all yum-mach versions I've used). > > It seems like a build error to me if it won't build with both > installed. Fine. Before anyone spends time on looking into it, how did you manage to build it successfully before (at least for FC3 x86_64)? IIRC, you used a complete installation. From toshio at tiki-lounge.com Sat May 7 16:25:01 2005 From: toshio at tiki-lounge.com (Toshio) Date: Sat, 07 May 2005 12:25:01 -0400 Subject: Approval needed: fftw3 In-Reply-To: <20050507162108.2d9c0b72.bugs.michael@gmx.net> References: <427BE0C4.1040204@ieee.org> <1115431288.24408.153.camel@ernie> <1115472265.24408.198.camel@ernie> <20050507162108.2d9c0b72.bugs.michael@gmx.net> Message-ID: <1115483104.4296.32.camel@Madison.badger.com> On Sat, 2005-05-07 at 16:21 +0200, Michael Schwendt wrote: > On Sat, 07 May 2005 09:24:24 -0400, Ed Hill wrote: > > > On Sat, 2005-05-07 at 08:15 -0400, Chris Ricker wrote: > > > On Fri, 6 May 2005, Ed Hill wrote: > > > > I can't find anything the matter with it so please add my name to a > > > > "reviewed and approved-by" message. > > > > > > My understanding of the new-and-improved package submission process is > > > that you (Ed), not Quentin, would be the one to send the APPROVED message > > > to f-e-commits. I may well have missed something though ;-) > > > > Hi Chris, > > > > Is that true? If so, I'll try to follow it next time around. > > > > Please understand that I have only a tenuous grasp of the "official > > process". It seems to be a moving target. ;-) > > It isn't a moving target. Feel free to compare the old page version in > the Wiki with the current version. Either version only says that > explicit approval must be posted. It is not said who must send the > message. It is a moving target when it gets changed at 9:30 in the morning to make this comparison correct :-) Thanks for the clarification work, though. And thanks for the clarification that the new wording should embody the same process as the old, just with clearer language. -Toshio -- ______S______U______B______L______I______M______I______N______A______L______ t o s h i o @ t i k i - l o u n g e . c o m GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Sat May 7 16:33:12 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 May 2005 18:33:12 +0200 Subject: Approval needed: fftw3 In-Reply-To: <1115483104.4296.32.camel@Madison.badger.com> References: <427BE0C4.1040204@ieee.org> <1115431288.24408.153.camel@ernie> <1115472265.24408.198.camel@ernie> <20050507162108.2d9c0b72.bugs.michael@gmx.net> <1115483104.4296.32.camel@Madison.badger.com> Message-ID: <20050507183312.5dbfa36f.bugs.michael@gmx.net> On Sat, 07 May 2005 12:25:01 -0400, Toshio wrote: > On Sat, 2005-05-07 at 16:21 +0200, Michael Schwendt wrote: > > On Sat, 07 May 2005 09:24:24 -0400, Ed Hill wrote: > > > > > On Sat, 2005-05-07 at 08:15 -0400, Chris Ricker wrote: > > > > On Fri, 6 May 2005, Ed Hill wrote: > > > > > I can't find anything the matter with it so please add my name to a > > > > > "reviewed and approved-by" message. > > > > > > > > My understanding of the new-and-improved package submission process is > > > > that you (Ed), not Quentin, would be the one to send the APPROVED message > > > > to f-e-commits. I may well have missed something though ;-) > > > > > > Hi Chris, > > > > > > Is that true? If so, I'll try to follow it next time around. > > > > > > Please understand that I have only a tenuous grasp of the "official > > > process". It seems to be a moving target. ;-) > > > > It isn't a moving target. Feel free to compare the old page version in > > the Wiki with the current version. Either version only says that > > explicit approval must be posted. It is not said who must send the > > message. > > It is a moving target when it gets changed at 9:30 in the morning to > make this comparison correct :-) Thanks for the clarification work, > though. And thanks for the clarification that the new wording should > embody the same process as the old, just with clearer language. I've not changed the "Approval" paragraph. But I've changed the wording in the summary a bit -- pedantic people could still read between the lines and complain. Obviously, without prior approval from the reviewer, the packager cannot send the approval message on behalf of the approver. Only more formal language could avoid ambiguities. From fedora at leemhuis.info Sat May 7 17:15:05 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 07 May 2005 19:15:05 +0200 Subject: wxGTK (was: Re: Package Build Report - Fedora Extras Development) In-Reply-To: <20050507180727.3e5a2fe2.bugs.michael@gmx.net> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> <1115307543.24385.698.camel@mccallum.corsepiu.local> <20050505181522.30e74d4c.bugs.michael@gmx.net> <1115310933.24385.711.camel@mccallum.corsepiu.local> <20050505192754.729380cd.bugs.michael@gmx.net> <1115322770.24385.716.camel@mccallum.corsepiu.local> <1115327380.3374.8.camel@bree.local.net> <1115346541.24385.724.camel@mccallum.corsepiu.local> <20050507153717.430443bf.bugs.michael@gmx.net> <1115474329.8237.25.camel@mccallum.corsepiu.local> <20050507161517.33e3333a.bugs.michael@gmx.net> <1115481282.5422.3.camel@notebook.thl.home> <1115481440.15593.52.camel@cutter> <20050507180727.3e5a2fe2.bugs.michael@gmx.net> Message-ID: <1115486106.5422.10.camel@notebook.thl.home> Am Samstag, den 07.05.2005, 18:07 +0200 schrieb Michael Schwendt: > On Sat, 07 May 2005 11:57:20 -0400, seth vidal wrote: > > > > > > > > > What is installed into the mach chroot for an x86_64 build? The i386 > > > > version? The x86_64 version? Or both? > > > > > > Both (at last will all yum-mach versions I've used). > > > > It seems like a build error to me if it won't build with both > > installed. ++ (okay, it sometimes is the reason for some of those x86_64 build problems and makes a lot of those "autoreconf-patches" necessary -- but I also think is should be fixed, otherwise a lot of users might run into problems) > Fine. Before anyone spends time on looking into it,[...] I did a quick look. I can't get the current version in cvs (devel or FC3) or the published srpm for extras/3/ to build inside or outside mach on FC3 currently. I'll try to look into this deeper later or tomorrow. But I think the buildsystem/seth/yum is innocent ;-) -- Thorsten Leemhuis From toshio at tiki-lounge.com Sat May 7 17:48:43 2005 From: toshio at tiki-lounge.com (Toshio) Date: Sat, 07 May 2005 13:48:43 -0400 Subject: Review: pylint, python-logilab-common In-Reply-To: References: Message-ID: <1115488124.4296.41.camel@Madison.badger.com> On Fri, 2005-05-06 at 16:09 -0400, Konstantin Ryabitsev wrote: > Hello, folks: > > Please review the following two packages currently in devel cvs: > > -- > Name: pylint > Version: 0.6.4 > Release: 3 Quick note: * Man page in man/pylint.1 should be installed * examples/ subdirectory would be helpful for those looking to customize. -Toshio -- toshio \ "A lasting friendship is one where you never expect anything, @tiki \ always working to make the friendship better. A good friendship -lounge \ is one where the other person does the same." .com \____________________________________________________ GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Sat May 7 18:02:53 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 May 2005 20:02:53 +0200 Subject: wxGTK (was: Re: Package Build Report - Fedora Extras Development) In-Reply-To: <1115486106.5422.10.camel@notebook.thl.home> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> <1115307543.24385.698.camel@mccallum.corsepiu.local> <20050505181522.30e74d4c.bugs.michael@gmx.net> <1115310933.24385.711.camel@mccallum.corsepiu.local> <20050505192754.729380cd.bugs.michael@gmx.net> <1115322770.24385.716.camel@mccallum.corsepiu.local> <1115327380.3374.8.camel@bree.local.net> <1115346541.24385.724.camel@mccallum.corsepiu.local> <20050507153717.430443bf.bugs.michael@gmx.net> <1115474329.8237.25.camel@mccallum.corsepiu.local> <20050507161517.33e3333a.bugs.michael@gmx.net> <1115481282.5422.3.camel@notebook.thl.home> <1115481440.15593.52.camel@cutter> <20050507180727.3e5a2fe2.bugs.michael@gmx.net> <1115486106.5422.10.camel@notebook.thl.home> Message-ID: <20050507200253.7337b066.bugs.michael@gmx.net> On Sat, 07 May 2005 19:15:05 +0200, Thorsten Leemhuis wrote: > Am Samstag, den 07.05.2005, 18:07 +0200 schrieb Michael Schwendt: > > On Sat, 07 May 2005 11:57:20 -0400, seth vidal wrote: > > > > > > > > > > > > What is installed into the mach chroot for an x86_64 build? The i386 > > > > > version? The x86_64 version? Or both? > > > > > > > > Both (at last will all yum-mach versions I've used). > > > > > > It seems like a build error to me if it won't build with both > > > installed. > > ++ (okay, it sometimes is the reason for some of those x86_64 build > problems and makes a lot of those "autoreconf-patches" necessary -- but > I also think is should be fixed, otherwise a lot of users might run into > problems) > > > Fine. Before anyone spends time on looking into it,[...] > > I did a quick look. I can't get the current version in cvs (devel or > FC3) or the published srpm for extras/3/ to build inside or outside mach > on FC3 currently. I'll try to look into this deeper later or tomorrow. > But I think the buildsystem/seth/yum is innocent ;-) "configure" script has /usr/lib and /usr/X11R6/lib hardcoded in at least half a dozen places and also does things like s/include/lib/g in order to derive a list of library search paths from a list of header search paths. Should be fixable for somebody with an x86_64 box and maybe a few tries (to see what else is broken in there). Really strange that the same software did built for x86_64 before. From bdpepple at ameritech.net Sat May 7 18:08:22 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Sat, 07 May 2005 14:08:22 -0400 Subject: Review: Loudmouth, Gossip Message-ID: <1115489302.12960.4.camel@localhost.localdomain> Please review the following two packages currently in devel cvs: Name: gossip Version: 0.8 Release: 3 Summary: Gnome Jabber Client Gossip aims at making Jabber easy to use and tries to give GNOME users a real user friendly way of chatting with their friends. --- Name: loudmouth Version: 0.17.2 Release: 3 Summary: Loudmouth is a Jabber programming library written in C Loudmouth is a lightweight and easy-to-use C library for programming with the Jabber protocol. It's designed to be easy to get started with and yet extensible to let you do anything the Jabber protocol allows. Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazquez at ivazquez.net Sat May 7 18:18:51 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 07 May 2005 14:18:51 -0400 Subject: Request for review: OpenEXR, swish-e In-Reply-To: <1115455194.7124.7.camel@ignacio.ignacio.lan> References: <1114335625.7784.41.camel@ignacio.ignacio.lan> <1115377802.7124.1.camel@ignacio.ignacio.lan> <1115455194.7124.7.camel@ignacio.ignacio.lan> Message-ID: <1115489931.12675.0.camel@ignacio.ignacio.lan> On Sat, 2005-05-07 at 04:39 -0400, Ignacio Vazquez-Abrams wrote: > On Fri, 2005-05-06 at 07:10 -0400, Ignacio Vazquez-Abrams wrote: > > On Sun, 2005-04-24 at 05:40 -0400, Ignacio Vazquez-Abrams wrote: > > > OpenEXR: A high dynamic-range (HDR) image file format > > > > > > OpenEXR is a high dynamic-range (HDR) image file format developed by > > > Industrial Light & Magic for use in computer imaging applications. This > > > package contains libraries and sample applications for handling the > > > format. > > > > > > http://fedora.ivazquez.net/files/OpenEXR-1.2.2-1.src.rpm > > > > > > swish-e: Simple Web Indexing System for Humans - Enhanced > > > > > > Swish-e is Simple Web Indexing System for Humans - Enhanced. Swish-e can > > > quickly and easily index directories of files or remote web sites and > > > search the generated indexes. > > > > > > http://fedora.ivazquez.net/files/swish-e-2.4.3-1.src.rpm > > > > Bump? > > Okay, let me reword the question. Does anyone mind if I import these > into CVS? Since there are no objections I'm going to go ahead and import these into CVS. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mpeters at mac.com Sat May 7 18:22:27 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 07 May 2005 11:22:27 -0700 Subject: Problem with mach Message-ID: <1115490147.21300.3.camel@fc4t2.mpeters.local> I'm trying to use mach according to the instructions at http://www.fedoraproject.org/wiki/UsingMach I have mach-0.4.6.1-1.yum.0.20050321.031334 installed mach -r fedora-development-$your_arch-core setup build works mach -r fedora-development-$your_arch-extras setup build does not work. However, after some playing, I found that - mach -r fedora-development-$your_arch-extras-stable setup build almost works - it leaves me though with the following error: ERROR: su/runuser did not get installed properly What I am I missing? From jpo at di.uminho.pt Sat May 7 18:13:33 2005 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sat, 7 May 2005 19:13:33 +0100 (WEST) Subject: Review request: syslog-ng (syslog replacement daemon) In-Reply-To: <20050507152722.059a0444.bugs.michael@gmx.net> References: <427C0BF2.9000304@di.uminho.pt> <20050507152722.059a0444.bugs.michael@gmx.net> Message-ID: <1136.213.13.86.72.1115489613.squirrel@webmail.lsd.di.uminho.pt> > On Sat, 7 May 2005 08:22:37 -0400 (EDT), Chris Ricker wrote: > >> On Sat, 7 May 2005, Jos? Pedro Oliveira wrote: >> >> > * Changes a file from another package >> > (/etc/logrotate.d/syslog from the sysklogd rpm) >> >> I know people (with good reason!) try to avoid using alternatives, but >> isn't this a good case to use them? > > Unless we continue with discussion of the old "Fedora Alternatives" > concept, a package that changes a file from another package and even stops > Core's syslog service in its scriptlets, sounds very much like it's > unacceptable. How do we re-open the "Fedora Alternatives"? I really would like to see syslog-ng as an alternative to sysklogd, and unless there is an Fedora Alternative policy I will never see syslog-ng package approved (logrotate problem, stopping the syslogd daemon in %post scripts). Marking syslog-ng as confliting with sysklogd doesn't solve the problem. People will have to remove sysklog with the --nodeps option before installing syslog-ng. jpo PS - Is there an archive of old "Fedora Alternatives" discussion? -- 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 jpo at di.uminho.pt Sat May 7 18:26:08 2005 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sat, 7 May 2005 19:26:08 +0100 (WEST) Subject: Review request: syslog-ng (syslog replacement daemon) In-Reply-To: <1115477307.3302.77.camel@bree.local.net> References: <427C0BF2.9000304@di.uminho.pt> <1115477307.3302.77.camel@bree.local.net> Message-ID: <1153.213.13.86.72.1115490368.squirrel@webmail.lsd.di.uminho.pt> > On Sat, 2005-05-07 at 01:29 +0100, Jos?? Pedro Oliveira wrote: >> Notes: >> * Stops the syslog daemon during installation > > This definitely seems non-ideal. You don't want to be stopping a > different service when you install yourself. The fact that you can't > run both of them at once just means you have to do a little bit of > service configuration to get the one you want running after you install > it. This is no different than installing, eg, an http daemon other than > httpd. > >> * Changes a file from another package >> (/etc/logrotate.d/syslog from the sysklogd rpm) > > Better to figure out how to generalize this. See my later mail. Don't know how to do it without using alternatives. The best solution I came up with was to comment the /etc/logrotate.d/syslog lines using triggers. (previous comments in https://bugzilla.fedora.us/show_bug.cgi?id=1332) >> * currently it doesn't change the use_syslogng SELinux boolean > > I don't see any other packages doing anything like this at the moment, > and I'm not entirely sure how I feel about it.[1] Looking at what the > boolean allows, I think that some of them at least are valid in the case > of sysklogd where you're using a remote syslog server. cc'ing Dan to > see if he has an opinion here. As the use_syslogng SELinux boolean is for syslog_ng, I don't see any problem in enabling/disabling it using the post scripts (see the message in trhe fedora-packaging mailing list). > Jeremy > > [1] I still maintain that policy for a package should be maintained with > and shipped in the package. That would make this a much easier > question :-) Unfortunately, policy tools aren't there yet although I'm > hopeful about progress in this area over time. -- 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 fedora at leemhuis.info Sat May 7 19:00:06 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 07 May 2005 21:00:06 +0200 Subject: wxGTK (was: Re: Package Build Report - Fedora Extras Development) In-Reply-To: <20050507200253.7337b066.bugs.michael@gmx.net> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> <1115307543.24385.698.camel@mccallum.corsepiu.local> <20050505181522.30e74d4c.bugs.michael@gmx.net> <1115310933.24385.711.camel@mccallum.corsepiu.local> <20050505192754.729380cd.bugs.michael@gmx.net> <1115322770.24385.716.camel@mccallum.corsepiu.local> <1115327380.3374.8.camel@bree.local.net> <1115346541.24385.724.camel@mccallum.corsepiu.local> <20050507153717.430443bf.bugs.michael@gmx.net> <1115474329.8237.25.camel@mccallum.corsepiu.local> <20050507161517.33e3333a.bugs.michael@gmx.net> <1115481282.5422.3.camel@notebook.thl.home> <1115481440.15593.52.camel@cutter> <20050507180727.3e5a2fe2.bugs.michael@gmx.net> <1115486106.5422.10.camel@notebook.thl.home> <20050507200253.7337b066.bugs.michael@gmx.net> Message-ID: <1115492406.5646.12.camel@notebook.thl.home> Am Samstag, den 07.05.2005, 20:02 +0200 schrieb Michael Schwendt: > On Sat, 07 May 2005 19:15:05 +0200, Thorsten Leemhuis wrote: > "configure" script has /usr/lib and /usr/X11R6/lib hardcoded in > at least half a dozen places and also does things like s/include/lib/g > in order to derive a list of library search paths from a list of header > search paths. Should be fixable for somebody with an x86_64 box and > maybe a few tries (to see what else is broken in there). -sed -i -e 's|/usr/lib\b|%{_libdir}|' wx-config.in +sed -i -e 's|/usr/lib\b|%{_libdir}|' wx-config.in configure Fixes build on x86_64. If no one has objections I'll update cvs tomorrow with this change. Or do you think digging deeper into the configure- script is worth the trouble? BTW: 2.6.0 of wxGTK is out > Really strange that the same software did built for x86_64 before. Indeed. -- Thorsten Leemhuis From jpo at di.uminho.pt Sat May 7 18:03:01 2005 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sat, 7 May 2005 19:03:01 +0100 (WEST) Subject: Review request: syslog-ng (syslog replacement daemon) In-Reply-To: <1115476967.3302.70.camel@bree.local.net> References: <427C0BF2.9000304@di.uminho.pt><20050507140349.GA10387@jadzia.bu.edu> <1115476967.3302.70.camel@bree.local.net> Message-ID: <1132.213.13.86.72.1115488981.squirrel@webmail.lsd.di.uminho.pt> > On Sat, 2005-05-07 at 10:03 -0400, Matthew Miller wrote: >> On Sat, May 07, 2005 at 08:22:37AM -0400, Chris Ricker wrote: >> > > * Changes a file from another package >> > > (/etc/logrotate.d/syslog from the sysklogd rpm) >> > I know people (with good reason!) try to avoid using alternatives, but >> > isn't this a good case to use them? >> >> I haven't looked at this particular case, but if this is the only change >> needed, might there be a way to generalize the /etc/logrotate.d/syslog >> file >> in the syslog RPM? > > My guess (just from a quick look at /etc/logrotate.d/syslog) is that > this is due to the kill -HUP of the syslog process. Having syslog-ng > use the same pid file could work, but could have other consequences that > I'm not thinking of at the moment. Especially as I haven't looked at > syslog-ng in a long time :-) It won't work. People will change the syslog/syslog-ng configuration files to modify/create/remove logging rules and logging destinations. 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 bugs.michael at gmx.net Sat May 7 19:16:03 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 May 2005 21:16:03 +0200 Subject: wxGTK (was: Re: Package Build Report - Fedora Extras Development) In-Reply-To: <1115492406.5646.12.camel@notebook.thl.home> References: <1115296548.24970.11.camel@cutter> <1115300382.5804.14.camel@notebook.thl.home> <1115307543.24385.698.camel@mccallum.corsepiu.local> <20050505181522.30e74d4c.bugs.michael@gmx.net> <1115310933.24385.711.camel@mccallum.corsepiu.local> <20050505192754.729380cd.bugs.michael@gmx.net> <1115322770.24385.716.camel@mccallum.corsepiu.local> <1115327380.3374.8.camel@bree.local.net> <1115346541.24385.724.camel@mccallum.corsepiu.local> <20050507153717.430443bf.bugs.michael@gmx.net> <1115474329.8237.25.camel@mccallum.corsepiu.local> <20050507161517.33e3333a.bugs.michael@gmx.net> <1115481282.5422.3.camel@notebook.thl.home> <1115481440.15593.52.camel@cutter> <20050507180727.3e5a2fe2.bugs.michael@gmx.net> <1115486106.5422.10.camel@notebook.thl.home> <20050507200253.7337b066.bugs.michael@gmx.net> <1115492406.5646.12.camel@notebook.thl.home> Message-ID: <20050507211603.4e0a52e5.bugs.michael@gmx.net> On Sat, 07 May 2005 21:00:06 +0200, Thorsten Leemhuis wrote: > > "configure" script has /usr/lib and /usr/X11R6/lib hardcoded in > > at least half a dozen places and also does things like s/include/lib/g > > in order to derive a list of library search paths from a list of header > > search paths. Should be fixable for somebody with an x86_64 box and > > maybe a few tries (to see what else is broken in there). > > -sed -i -e 's|/usr/lib\b|%{_libdir}|' wx-config.in > +sed -i -e 's|/usr/lib\b|%{_libdir}|' wx-config.in configure > > Fixes build on x86_64. If no one has objections I'll update cvs tomorrow > with this change. Or do you think digging deeper into the configure- > script is worth the trouble? Can't comment on that, since I can't test where [else] it fails. ;) > BTW: 2.6.0 of wxGTK is out Yes. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154618 But major updates need a good bit of testing and compatibility checks with existing dependencies. From mattdm at mattdm.org Sat May 7 19:36:45 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 7 May 2005 15:36:45 -0400 Subject: Review request: syslog-ng (syslog replacement daemon) In-Reply-To: <1132.213.13.86.72.1115488981.squirrel@webmail.lsd.di.uminho.pt> References: <1115476967.3302.70.camel@bree.local.net> <1132.213.13.86.72.1115488981.squirrel@webmail.lsd.di.uminho.pt> Message-ID: <20050507193645.GA21441@jadzia.bu.edu> On Sat, May 07, 2005 at 07:03:01PM +0100, Jose Pedro Oliveira wrote: > >> I haven't looked at this particular case, but if this is the only > >> change needed, might there be a way to generalize the > >> /etc/logrotate.d/syslog file in the syslog RPM? [...] > It won't work. People will change the syslog/syslog-ng configuration > files to modify/create/remove logging rules and logging destinations. Are you saying you have a magic syslog-ng logrotate configuration that works with all possible ways to configure syslog-ng but which cannot work with regular syslog? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 74 degrees Fahrenheit. From mattdm at mattdm.org Sat May 7 19:42:13 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 7 May 2005 15:42:13 -0400 Subject: wxGTK (was: Re: Package Build Report - Fedora Extras Development) In-Reply-To: <20050507211603.4e0a52e5.bugs.michael@gmx.net> References: <20050507153717.430443bf.bugs.michael@gmx.net> <1115474329.8237.25.camel@mccallum.corsepiu.local> <20050507161517.33e3333a.bugs.michael@gmx.net> <1115481282.5422.3.camel@notebook.thl.home> <1115481440.15593.52.camel@cutter> <20050507180727.3e5a2fe2.bugs.michael@gmx.net> <1115486106.5422.10.camel@notebook.thl.home> <20050507200253.7337b066.bugs.michael@gmx.net> <1115492406.5646.12.camel@notebook.thl.home> <20050507211603.4e0a52e5.bugs.michael@gmx.net> Message-ID: <20050507194213.GB21441@jadzia.bu.edu> On Sat, May 07, 2005 at 09:16:03PM +0200, Michael Schwendt wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154618 > But major updates need a good bit of testing and compatibility checks > with existing dependencies. For one thing, you need the cvs version of audacity -- current stable release won't build (even with the "2.4 compatibility" flags in the wxGTK build turned on). -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 74 degrees Fahrenheit. From jpo at di.uminho.pt Sat May 7 19:57:13 2005 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sat, 7 May 2005 20:57:13 +0100 (WEST) Subject: Review request: syslog-ng (syslog replacement daemon) In-Reply-To: <20050507193645.GA21441@jadzia.bu.edu> References: <1115476967.3302.70.camel@bree.local.net><1132.213.13.86.72.1115488981.squirrel@webmail.lsd.di.uminho.pt> <20050507193645.GA21441@jadzia.bu.edu> Message-ID: <1549.213.13.86.72.1115495833.squirrel@webmail.lsd.di.uminho.pt> > On Sat, May 07, 2005 at 07:03:01PM +0100, Jose Pedro Oliveira wrote: >> >> I haven't looked at this particular case, but if this is the only >> >> change needed, might there be a way to generalize the >> >> /etc/logrotate.d/syslog file in the syslog RPM? > [...] >> It won't work. People will change the syslog/syslog-ng configuration >> files to modify/create/remove logging rules and logging destinations. > > Are you saying you have a magic syslog-ng logrotate configuration that > works > with all possible ways to configure syslog-ng but which cannot work with > regular syslog? No I'm not. After installing the syslog-ng package you will have two logrotate files 1) /etc/logrotate.d/syslog (owned by sysklogd) 2) /etc/logrotate.d/syslog-ng (owned by syslog-ng) But in order for logrotate to do its work I comment every line on the first one (/etc/logrotate.d/syslog) as logrotate refuses to run if a logfile is mentioned more than once. The syslog-ng configuration mimics the default syslog configuration shipped by Red Hat (ie: same log destinations). jpo PS - More information available in https://bugzilla.fedora.us/show_bug.cgi?id=1332 -- 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 bugs.michael at gmx.net Sat May 7 20:04:53 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 May 2005 22:04:53 +0200 Subject: Review request: syslog-ng (syslog replacement daemon) In-Reply-To: <1136.213.13.86.72.1115489613.squirrel@webmail.lsd.di.uminho.pt> References: <427C0BF2.9000304@di.uminho.pt> <20050507152722.059a0444.bugs.michael@gmx.net> <1136.213.13.86.72.1115489613.squirrel@webmail.lsd.di.uminho.pt> Message-ID: <20050507220453.6493fc20.bugs.michael@gmx.net> On Sat, 7 May 2005 19:13:33 +0100 (WEST), Jose Pedro Oliveira wrote: > > On Sat, 7 May 2005 08:22:37 -0400 (EDT), Chris Ricker wrote: > > > >> On Sat, 7 May 2005, Jos? Pedro Oliveira wrote: > >> > >> > * Changes a file from another package > >> > (/etc/logrotate.d/syslog from the sysklogd rpm) > >> > >> I know people (with good reason!) try to avoid using alternatives, but > >> isn't this a good case to use them? > > > > Unless we continue with discussion of the old "Fedora Alternatives" > > concept, a package that changes a file from another package and even stops > > Core's syslog service in its scriptlets, sounds very much like it's > > unacceptable. > > How do we re-open the "Fedora Alternatives"? > > I really would like to see syslog-ng as an alternative to sysklogd, and > unless there is an Fedora Alternative policy I will never see syslog-ng > package approved (logrotate problem, stopping the syslogd daemon in > %post scripts). Marking syslog-ng as confliting with sysklogd doesn't > solve the problem. People will have to remove sysklog with the --nodeps > option before installing syslog-ng. > > jpo > > PS - Is there an archive of old "Fedora Alternatives" discussion? There used to be a rough definition of "Fedora Alternatives" below the definition of "Fedora Extras" on the fedora.redhat.com "Terminology" page. It described a package class which would make it possible to replace packages from Fedora Core with packages which offer similar functionality. It has been decided to focus on Core and Extras. And Extras must not conflict with Core. I consider the syslog-ng package in its present form, with scriptlets which stop Core's syslog and start (!) syslog-ng right after package installation, a conflict with Core. Installation must not do that IMO. From denis at poolshark.org Sat May 7 20:16:02 2005 From: denis at poolshark.org (Denis Leroy) Date: Sat, 07 May 2005 13:16:02 -0700 Subject: Problem with mach In-Reply-To: <1115490147.21300.3.camel@fc4t2.mpeters.local> References: <1115490147.21300.3.camel@fc4t2.mpeters.local> Message-ID: <427D2202.7070107@poolshark.org> Michael A. Peters wrote: > I'm trying to use mach according to the instructions at > > http://www.fedoraproject.org/wiki/UsingMach > > I have mach-0.4.6.1-1.yum.0.20050321.031334 installed > > mach -r fedora-development-$your_arch-core setup build > > works > > mach -r fedora-development-$your_arch-extras setup build > > does not work. However, after some playing, I found that - > > mach -r fedora-development-$your_arch-extras-stable setup build > > almost works - it leaves me though with the following error: > > ERROR: su/runuser did not get installed properly > > What I am I missing? I've run into that same problem several times. Usually when doing a new build with the -k (keep) option. It removes existing RPMs including runuser, after that any mach operation results in a 'error 127', until i do a 'mach clean' (unpleasant when you had packages in there that took hours to compile...). -denis From denis at poolshark.org Sat May 7 20:17:39 2005 From: denis at poolshark.org (Denis Leroy) Date: Sat, 07 May 2005 13:17:39 -0700 Subject: Problem with mach In-Reply-To: <427D2202.7070107@poolshark.org> References: <1115490147.21300.3.camel@fc4t2.mpeters.local> <427D2202.7070107@poolshark.org> Message-ID: <427D2263.9060901@poolshark.org> Denis Leroy wrote: > I've run into that same problem several times. Usually when doing a new > build with the -k (keep) option. It removes existing RPMs including s/with/without/ > runuser, after that any mach operation results in a 'error 127', until i > do a 'mach clean' (unpleasant when you had packages in there that took > hours to compile...). > > -denis > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list From ville.skytta at iki.fi Sat May 7 20:22:07 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 07 May 2005 23:22:07 +0300 Subject: Request for review: OpenEXR, swish-e In-Reply-To: <1115489931.12675.0.camel@ignacio.ignacio.lan> References: <1114335625.7784.41.camel@ignacio.ignacio.lan> <1115377802.7124.1.camel@ignacio.ignacio.lan> <1115455194.7124.7.camel@ignacio.ignacio.lan> <1115489931.12675.0.camel@ignacio.ignacio.lan> Message-ID: <1115497327.9556.5.camel@bobcat.mine.nu> On Sat, 2005-05-07 at 14:18 -0400, Ignacio Vazquez-Abrams wrote: > Since there are no objections I'm going to go ahead and import these > into CVS. Unless you've found someone to review these packages, please read http://fedoraproject.org/wiki/NewPackageProcess again. From jpo at di.uminho.pt Sat May 7 20:26:10 2005 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sat, 7 May 2005 21:26:10 +0100 (WEST) Subject: Review request: syslog-ng (syslog replacement daemon) In-Reply-To: <20050507220453.6493fc20.bugs.michael@gmx.net> References: <427C0BF2.9000304@di.uminho.pt><20050507152722.059a0444.bugs.michael@gmx.net><1136.213.13.86.72.1115489613.squirrel@webmail.lsd.di.uminho.pt> <20050507220453.6493fc20.bugs.michael@gmx.net> Message-ID: <1656.213.13.86.72.1115497570.squirrel@webmail.lsd.di.uminho.pt> > On Sat, 7 May 2005 19:13:33 +0100 (WEST), Jose Pedro Oliveira wrote: > >> > On Sat, 7 May 2005 08:22:37 -0400 (EDT), Chris Ricker wrote: >> > >> >> On Sat, 7 May 2005, Jos? Pedro Oliveira wrote: >> >> >> >> > * Changes a file from another package >> >> > (/etc/logrotate.d/syslog from the sysklogd rpm) >> >> >> >> I know people (with good reason!) try to avoid using alternatives, >> but >> >> isn't this a good case to use them? >> > >> > Unless we continue with discussion of the old "Fedora Alternatives" >> > concept, a package that changes a file from another package and even >> stops >> > Core's syslog service in its scriptlets, sounds very much like it's >> > unacceptable. >> >> How do we re-open the "Fedora Alternatives"? >> >> I really would like to see syslog-ng as an alternative to sysklogd, and >> unless there is an Fedora Alternative policy I will never see syslog-ng >> package approved (logrotate problem, stopping the syslogd daemon in >> %post scripts). Marking syslog-ng as confliting with sysklogd doesn't >> solve the problem. People will have to remove sysklog with the --nodeps >> option before installing syslog-ng. >> >> jpo >> >> PS - Is there an archive of old "Fedora Alternatives" discussion? > > There used to be a rough definition of "Fedora Alternatives" below the > definition of "Fedora Extras" on the fedora.redhat.com "Terminology" > page. It described a package class which would make it possible to replace > packages from Fedora Core with packages which offer similar > functionality. It has been decided to focus on Core and Extras. And Extras > must not conflict with Core. > > I consider the syslog-ng package in its present form, with scriptlets > which stop Core's syslog and start (!) syslog-ng right after package > installation, a conflict with Core. Installation must not do that IMO. That can be fixed. But the main problem still remains: the logrotate file conflict. 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 ivazquez at ivazquez.net Sat May 7 20:33:08 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 07 May 2005 16:33:08 -0400 Subject: Request for review: OpenEXR, swish-e In-Reply-To: <1115497327.9556.5.camel@bobcat.mine.nu> References: <1114335625.7784.41.camel@ignacio.ignacio.lan> <1115377802.7124.1.camel@ignacio.ignacio.lan> <1115455194.7124.7.camel@ignacio.ignacio.lan> <1115489931.12675.0.camel@ignacio.ignacio.lan> <1115497327.9556.5.camel@bobcat.mine.nu> Message-ID: <1115497988.20211.1.camel@ignacio.ignacio.lan> On Sat, 2005-05-07 at 23:22 +0300, Ville Skytt? wrote: > On Sat, 2005-05-07 at 14:18 -0400, Ignacio Vazquez-Abrams wrote: > > > Since there are no objections I'm going to go ahead and import these > > into CVS. > > Unless you've found someone to review these packages, please read > http://fedoraproject.org/wiki/NewPackageProcess again. Oh look, a response. Finally. I was beginning to wonder if anyone even saw the messages I sent about package reviews anymore. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mpeters at mac.com Sat May 7 20:40:47 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 07 May 2005 13:40:47 -0700 Subject: Request for Review: libvisual-plugins In-Reply-To: <1114692761.24385.213.camel@mccallum.corsepiu.local> References: <1114670959.11644.61.camel@fc4t2.mpeters.local> <1114684377.11644.80.camel@fc4t2.mpeters.local> <1114692761.24385.213.camel@mccallum.corsepiu.local> Message-ID: <1115498447.18558.31.camel@laptop.mpeters.local> On Thu, 2005-04-28 at 14:52 +0200, Ralf Corsepius wrote: > Well, this actually is an underdeveloped Makefile.am. > > Better patch the Makefile.am and Makefile.in to use $(mkinstalldirs) > instead of mkdirhier. Done New specfile theoretically should not require the xorg-x11 package. I'm not getting mach to play nice so I haven't verified, but it should build now without needing xorg-x11 New spec file: http://mpeters.us/fc_extras/libvisual-plugins.spec Patch: http://mpeters.us/fc_extras/libvisual-plugins-0.2.0.mkinstalldirs.patch src.rpm: http://mpeters.us/fc_extras/libvisual-plugins-0.2.0-0.4.src.rpm -=- Can it be co-sponsored now so it can be imported into CVS? From mpeters at mac.com Sat May 7 20:51:09 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 07 May 2005 13:51:09 -0700 Subject: Request for Review: gstreamer-plugins-extras Message-ID: <1115499070.18558.42.camel@laptop.mpeters.local> This package provides some gstreamer plugins that do not ship with Fedora Core and depend only upon libraries currently available in Extras. It is built from the same patent cleansed patched gst-plugins tarball as the Fedora rawhide gstreamer-plugins package. Included plugins: /usr/lib/gstreamer-0.8/libgstaasink.so /usr/lib/gstreamer-0.8/libgstladspa.so /usr/lib/gstreamer-0.8/libgstlibvisual.so /usr/lib/gstreamer-0.8/libgstshout.so /usr/lib/gstreamer-0.8/libgstsid.so /usr/lib/gstreamer-0.8/libgstsndfile.so This package is instead of my previously submitted gstreamer-plugins-libvisual package. spec file: http://mpeters.us/fc_extras/gstreamer-plugins-extras.spec src.rpm: http://mpeters.us/fc_extras/gstreamer-plugins-extras-0.8.8-0.3.src.rpm It builds with libraries currently available in extras-development Installation depends upon my libvisual-plugins package also submitted. That requires is because gst-register-0.8 will spit out errors about not finding any available plugins if they aren't installed (it still loads, but loads with zero features) Targets Fedora Rawhide, should also build for fc3 if branched and the tarball is changed to fc3 version of gst-plugins. I don't personally see much point though, but if others do, it's an easy change. From gauret at free.fr Sat May 7 21:03:02 2005 From: gauret at free.fr (Aurelien Bompard) Date: Sat, 07 May 2005 23:03:02 +0200 Subject: Request for Review: libvisual-plugins References: <1114670959.11644.61.camel@fc4t2.mpeters.local> <1114684377.11644.80.camel@fc4t2.mpeters.local> <1114692761.24385.213.camel@mccallum.corsepiu.local> <1115498447.18558.31.camel@laptop.mpeters.local> Message-ID: Michael A. Peters wrote: > Can it be co-sponsored now so it can be imported into CVS? Yep, you've got my approval. Please let me test it some more in mach before requesting a build. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : abompard at jabber.fr "Never trust a computer you can't throw out a window." -- Steve Wozniak From katzj at redhat.com Sat May 7 21:06:34 2005 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 07 May 2005 17:06:34 -0400 Subject: Review request: syslog-ng (syslog replacement daemon) In-Reply-To: <1153.213.13.86.72.1115490368.squirrel@webmail.lsd.di.uminho.pt> References: <427C0BF2.9000304@di.uminho.pt> <1115477307.3302.77.camel@bree.local.net> <1153.213.13.86.72.1115490368.squirrel@webmail.lsd.di.uminho.pt> Message-ID: <1115499994.9762.16.camel@bree.local.net> On Sat, 2005-05-07 at 19:26 +0100, Jose Pedro Oliveira wrote: > > On Sat, 2005-05-07 at 01:29 +0100, Jos?? Pedro Oliveira wrote: > >> * Changes a file from another package > >> (/etc/logrotate.d/syslog from the sysklogd rpm) > > > > Better to figure out how to generalize this. See my later mail. > > Don't know how to do it without using alternatives. The best solution > I came up with was to comment the /etc/logrotate.d/syslog lines > using triggers. > (previous comments in https://bugzilla.fedora.us/show_bug.cgi?id=1332) The only difference between the two files right now is what pid file they cat to figure out what service to restart. Using a trigger to comment all of the sysklogd package's version of this file is *BROKEN* as just because a package is installed, doesn't mean it's being used. Not to mention that the trigger strikes me as being relatively prone to causing problems down the line. As far as generalizing it, you could do this with a relatively trivial change to the initscript. In the start/stop, create and remove a symlink of /var/run/syslog.pid that points to the syslog-ng pidfile. Sure, it's a bit hacky, but it's better than sed'ing provided config files all the time. > >> * currently it doesn't change the use_syslogng SELinux boolean > > > > I don't see any other packages doing anything like this at the moment, > > and I'm not entirely sure how I feel about it.[1] Looking at what the > > boolean allows, I think that some of them at least are valid in the case > > of sysklogd where you're using a remote syslog server. cc'ing Dan to > > see if he has an opinion here. > > As the use_syslogng SELinux boolean is for syslog_ng, I don't see > any problem in enabling/disabling it using the post scripts > (see the message in trhe fedora-packaging mailing list). Sometimes, the right answer to how to package a piece of software includes getting other things in the distribution fixed. And in this case, I'm not convinced that syslog-ng's basic needs shouldn't be covered by the standard syslog policy already, although there may be gaps or bugs which should legitimately be looked at. Let's look at the things which the boolean allows: if (use_syslogng) { # Allow access to /proc/kmsg for syslog-ng allow syslogd_t proc_t:dir search; allow syslogd_t proc_kmsg_t:file { getattr read }; It looks like klogd uses /proc/kmsg by default for accessing kernel messages, so why should this be covered under the boolean? allow syslogd_t kernel_t:system { syslog_mod syslog_console }; allow syslogd_t self:capability { sys_admin chown fsetid }; This looks like it's already allowed for klogd allow syslogd_t var_log_t:dir { create setattr }; sysklogd would need this functionality as well if it is allowed to create arbitrary, not existing already log files. allow syslogd_t syslogd_port_t:tcp_socket name_bind; You want to allow this for remote logging with sysklogd as well allow syslogd_t rsh_port_t:tcp_socket name_connect; Not clear at all one why syslog-ng would need access to bind to the rsh socket. Source grepping a bit shows that it's being used for network logging. Aside from the brokenness of re-using a standard port, having people be aware of the need to allow the operation if they configure syslog-ng in this fashion doesn't strike me as a bad idea. Jeremy From ed at eh3.com Sat May 7 22:02:29 2005 From: ed at eh3.com (Ed Hill) Date: Sat, 07 May 2005 18:02:29 -0400 Subject: Request for review: OpenEXR, swish-e In-Reply-To: <1115497988.20211.1.camel@ignacio.ignacio.lan> References: <1114335625.7784.41.camel@ignacio.ignacio.lan> <1115377802.7124.1.camel@ignacio.ignacio.lan> <1115455194.7124.7.camel@ignacio.ignacio.lan> <1115489931.12675.0.camel@ignacio.ignacio.lan> <1115497327.9556.5.camel@bobcat.mine.nu> <1115497988.20211.1.camel@ignacio.ignacio.lan> Message-ID: <1115503349.24408.317.camel@ernie> On Sat, 2005-05-07 at 16:33 -0400, Ignacio Vazquez-Abrams wrote: > On Sat, 2005-05-07 at 23:22 +0300, Ville Skytt? wrote: > > On Sat, 2005-05-07 at 14:18 -0400, Ignacio Vazquez-Abrams wrote: > > > > > Since there are no objections I'm going to go ahead and import these > > > into CVS. > > > > Unless you've found someone to review these packages, please read > > http://fedoraproject.org/wiki/NewPackageProcess again. > > Oh look, a response. Finally. I was beginning to wonder if anyone even > saw the messages I sent about package reviews anymore. Hi Ignacio, I've been meaning to look at OpenEXR since it looks like a cool tool but have been busy this week. In any case, heres a review: good: - source matches upstream - license appears to be BSD or mighty similar and the license is included as it stipulates (good) - no serious errors from rpmlint on the SRPM blockers: - should be: BuildRequires: fltk-devel >= 1.1 instead of: BuildRequires: fltk >= 1.1 - you're installing shared libs so I think you ought to have: %post -p /sbin/ldconfig %postun -p /sbin/ldconfig - the ownership of the "%files devel" is wrong, you need another: "%defattr(-,root,root,-)" for the devel package - please delete all the hidden ".deps" files such as: /usr/share/doc/OpenEXR-devel-1.2.2/IlmImfExamples/.deps not sure about this one: - Can the "%{_libdir}/*.la" files be discarded? Or are they really needed? So while there are a few blockers they can probably (?) be fixed without too much effort. Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jpo at di.uminho.pt Sat May 7 22:14:33 2005 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sat, 7 May 2005 23:14:33 +0100 (WEST) Subject: Review request: syslog-ng (syslog replacement daemon) In-Reply-To: <1115499994.9762.16.camel@bree.local.net> References: <427C0BF2.9000304@di.uminho.pt> <1115477307.3302.77.camel@bree.local.net> <1153.213.13.86.72.1115490368.squirrel@webmail.lsd.di.uminho.pt> <1115499994.9762.16.camel@bree.local.net> Message-ID: <2287.213.13.86.72.1115504073.squirrel@webmail.lsd.di.uminho.pt> > On Sat, 2005-05-07 at 19:26 +0100, Jose Pedro Oliveira wrote: >> > On Sat, 2005-05-07 at 01:29 +0100, Jos???? Pedro Oliveira wrote: >> >> * Changes a file from another package >> >> (/etc/logrotate.d/syslog from the sysklogd rpm) >> > >> > Better to figure out how to generalize this. See my later mail. >> >> Don't know how to do it without using alternatives. The best solution >> I came up with was to comment the /etc/logrotate.d/syslog lines >> using triggers. >> (previous comments in https://bugzilla.fedora.us/show_bug.cgi?id=1332) > > The only difference between the two files right now is what pid file > they cat to figure out what service to restart. Using a trigger to > comment all of the sysklogd package's version of this file is *BROKEN* > as just because a package is installed, doesn't mean it's being used. > Not to mention that the trigger strikes me as being relatively prone to > causing problems down the line. Can we expect that no changes are made to the syslog logrotate file? Sure it isn't the best solution but it appears to be the one that is less harmful. The triggers are only activated during install and removal of sysklogd or syslog-ng. > As far as generalizing it, you could do this with a relatively trivial > change to the initscript. In the start/stop, create and remove a > symlink of /var/run/syslog.pid that points to the syslog-ng pidfile. > Sure, it's a bit hacky, but it's better than sed'ing provided config > files all the time. It doesn't work for the following cenario: 1) FC system with sysklogd 2) install syslog-ng 3) stop syslog 4) start syslog-ng 5) remove sysklogd => no logrotate file (!) Shouldn't the symlink idea be expanded to "alternatives" ? >> >> * currently it doesn't change the use_syslogng SELinux boolean >> > >> > I don't see any other packages doing anything like this at the moment, >> > and I'm not entirely sure how I feel about it.[1] Looking at what the >> > boolean allows, I think that some of them at least are valid in the >> case >> > of sysklogd where you're using a remote syslog server. cc'ing Dan to >> > see if he has an opinion here. >> >> As the use_syslogng SELinux boolean is for syslog_ng, I don't see >> any problem in enabling/disabling it using the post scripts >> (see the message in trhe fedora-packaging mailing list). > > Sometimes, the right answer to how to package a piece of software > includes getting other things in the distribution fixed. And in this > case, I'm not convinced that syslog-ng's basic needs shouldn't be > covered by the standard syslog policy already, although there may be > gaps or bugs which should legitimately be looked at. Let's look at the > things which the boolean allows: This is a moving target and I am a newbie when it comes to SELinux. But in FC3 you wouldn't be able to start syslog-ng without (most of) the following rules: ... bool use_syslogng false; if (use_syslogng) { # Allow access to /proc/kmsg for syslog-ng allow syslogd_t proc_t:dir search; allow syslogd_t proc_kmsg_t:file { getattr read }; allow syslogd_t kernel_t:system { syslog_mod syslog_console }; allow syslogd_t self:capability { sys_admin chown fsetid }; allow syslogd_t var_log_t:dir { create setattr }; } Source: RPM: selinux-policy-targeted-sources-1.17.30-2.96 File: /etc/selinux/targeted/src/policy/domains/program/syslogd.te Hoping that Dan Walsh will answer the following questions: > if (use_syslogng) { > # Allow access to /proc/kmsg for syslog-ng > allow syslogd_t proc_t:dir search; > allow syslogd_t proc_kmsg_t:file { getattr read }; > > It looks like klogd uses /proc/kmsg by default for accessing kernel > messages, so why should this be covered under the boolean? > > allow syslogd_t kernel_t:system { syslog_mod syslog_console }; > allow syslogd_t self:capability { sys_admin chown fsetid }; > > This looks like it's already allowed for klogd > > allow syslogd_t var_log_t:dir { create setattr }; > > sysklogd would need this functionality as well if it is allowed to > create arbitrary, not existing already log files. > > allow syslogd_t syslogd_port_t:tcp_socket name_bind; > > You want to allow this for remote logging with sysklogd as well > > allow syslogd_t rsh_port_t:tcp_socket name_connect; > > Not clear at all one why syslog-ng would need access to bind to the rsh > socket. Source grepping a bit shows that it's being used for network > logging. Aside from the brokenness of re-using a standard port, having > people be aware of the need to allow the operation if they configure > syslog-ng in this fashion doesn't strike me as a bad idea. > > Jeremy > 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 dwmw2 at infradead.org Sat May 7 22:49:31 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 07 May 2005 23:49:31 +0100 Subject: FC4 Status and the addition of PPC arch In-Reply-To: <1113368244.4360.4.camel@thl.ct.heise.de> References: <1113355996.16486.2.camel@arena.soho.bytebot.net> <1113368244.4360.4.camel@thl.ct.heise.de> Message-ID: <1115506172.29495.141.camel@localhost.localdomain> On Wed, 2005-04-13 at 06:57 +0200, Thorsten Leemhuis wrote: > Why not normally omit the architecture there completely? Then nobody > can forget ppc ;-) > > It seems in 95-98% of the cases the rebuilding was done (and should be > done) for all archs supported. For the other 2-5% we simply could > write: Seriously, we should be following a policy of requiring a bug number to be given as 'excuse' for any architecture exclusion. Since the wiki page seems to be obsolescent, I suspect we should just be using ExclusiveArch: or ExcludeArch: directives in specfiles now instead of listing architectures in the build requests. So the bug number should be in the specfile too, referring to the 'excuse' for omitting certain architectures. Even if it's a GCC bug which prevents a build on a given architecture, causing you to temporarily exclude that arch -- make _sure_ the bug is filed, and refer to it in your specfile along with the exclusion. -- dwmw2 From byte at aeon.com.my Sat May 7 22:54:03 2005 From: byte at aeon.com.my (Colin Charles) Date: Sun, 08 May 2005 08:54:03 +1000 Subject: FC4 Status and the addition of PPC arch In-Reply-To: <1115506172.29495.141.camel@localhost.localdomain> References: <1113355996.16486.2.camel@arena.soho.bytebot.net> <1113368244.4360.4.camel@thl.ct.heise.de> <1115506172.29495.141.camel@localhost.localdomain> Message-ID: <1115506444.4052.20.camel@arena.soho.bytebot.net> On Sat, 2005-05-07 at 23:49 +0100, David Woodhouse wrote: > > Why not normally omit the architecture there completely? Then nobody > > can forget ppc ;-) > > > > It seems in 95-98% of the cases the rebuilding was done (and should be > > done) for all archs supported. For the other 2-5% we simply could > > write: > > Seriously, we should be following a policy of requiring a bug number to > be given as 'excuse' for any architecture exclusion. I like this > Even if it's a GCC bug which prevents a build on a given architecture, > causing you to temporarily exclude that arch -- make _sure_ the bug is > filed, and refer to it in your specfile along with the exclusion. Agreed. If its not in Bugzilla, it doesn't exist Now, this is to package maintainers, and not to Seth (who's already doing an excellent job, albeit being overworked): if your build fails on a certain arch and you ExcludeArch temporarily, it is /your/ responsibility to make sure the bug is filed Michael has recently gone and done this in Bugzilla, and its mighty helpful with tracking. At least I now know what bugs need fixing, quickly -- Colin Charles, http://www.bytebot.net/ From rc040203 at freenet.de Sun May 8 04:45:52 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 08 May 2005 06:45:52 +0200 Subject: Fedora Extras Development Build Report In-Reply-To: <1115480032.29495.127.camel@localhost.localdomain> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> <1115478757.29495.122.camel@localhost.localdomain> <20050507172800.6eec367c.bugs.michael@gmx.net> <1115480032.29495.127.camel@localhost.localdomain> Message-ID: <1115527553.8237.35.camel@mccallum.corsepiu.local> On Sat, 2005-05-07 at 16:33 +0100, David Woodhouse wrote: > On Sat, 2005-05-07 at 17:28 +0200, Michael Schwendt wrote: > > We did not build for ppc when Fedora Extras started. > > Later x86_64 was added. And then ppc. > > > > "Where we are" with regard to maintaining packages, is something we > > need to find out... > > Agreed. We really need to work with the same policy as Core does -- a > build failure on one arch is a build failure on all. I strongly disagree. > We can't let > package versions just drift out of sync between architectures due to > spurious failures. Are you aware about how much effort had been required to get packages compiled on x86_64, when x86_64 was new? It took years. Adding any new architecture will impose a similar footprint and will, if a policy of "one arch blocks all" is implemented, this policy will block packages on archs not being affected by the "blocking bug on one arch". Also, once the number of architectures increases, the probability of tripping such "arch specific bugs" will increase. > It's bad enough in Core when people can just add ExcludeArch: to work > around temporary problems and get a package through the build system. We > really ought to have a policy of requiring a bug to be filed for every > exclusion, even in Core. _Certainly_ we shouldn't be allowing a build to > succeed for one architecture while it fails on others. IMO, we should have a target architecture matrix to selectively build packages for selected architectures. Ralf From a.kurtz at hardsun.net Sun May 8 08:40:59 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Sun, 08 May 2005 01:40:59 -0700 Subject: Self-Introduction: Paul Howarth In-Reply-To: <427B8A5D.9010205@city-fan.org> References: <427B4DD8.7020103@city-fan.org> <20050506140536.437a269d.bugs.michael@gmx.net> <427B6155.7050903@city-fan.org> <1115384664.24408.97.camel@ernie> <427B8A5D.9010205@city-fan.org> Message-ID: <1115541659.5768.1.camel@rydia.hardsun.net> On Fri, 2005-05-06 at 16:16 +0100, Paul Howarth wrote: > In addition to the pptp package I referred to earlier > (http://www.city-fan.org/~paul/extras/pptp/), I now have a > GTorrentViewer package available for inspection: > > http://www.city-fan.org/~paul/extras/GTorrentViewer/ Ah, interesting package, with some nice features I haven't seen elsewhere. Compiles and works without a problem. As for the spec, first off, I'd suggest calling it gtorrentviewer instead. It's what the binary is after all. See http://fedoraproject.org/wiki/PackageNamingGuidelines#head-26057558c8d1ceba1dfb290d88fd8159c1794732 as well. Second, NEWS is a zero-length file, so take it out of the %doc line. Third, I don't believe the use of the various %(__rm) and %(__make) macros are necessary, and seem to go against the usual Fedora style. I'd also suggest the use of Dist Tags to make it easier to have different e:v-r between releases. http://fedoraproject.org/wiki/DistTag -- Aaron Kurtz From dwmw2 at infradead.org Sun May 8 09:10:39 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 08 May 2005 10:10:39 +0100 Subject: Fedora Extras Development Build Report In-Reply-To: <1115527553.8237.35.camel@mccallum.corsepiu.local> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> <1115478757.29495.122.camel@localhost.localdomain> <20050507172800.6eec367c.bugs.michael@gmx.net> <1115480032.29495.127.camel@localhost.localdomain> <1115527553.8237.35.camel@mccallum.corsepiu.local> Message-ID: <1115543440.29495.161.camel@localhost.localdomain> On Sun, 2005-05-08 at 06:45 +0200, Ralf Corsepius wrote: > Are you aware about how much effort had been required to get packages > compiled on x86_64, when x86_64 was new? It took years. It'll never be that difficult again. We already have something 64-bit and something big-endian. > Adding any new architecture will impose a similar footprint and will, if > a policy of "one arch blocks all" is implemented, this policy will block > packages on archs not being affected by the "blocking bug on one arch". That result wouldn't be acceptable; you're right. But neither is it what I'm suggesting. Of _course_ we should be able to drop a problematic architecture from the build to allow new packages to get built -- I'm suggesting that it needs to be done _deliberately_ by use of ExcludeArch, rather than merely by acting on spurious build failures. It needs to be a conscious decision on the part of the package maintainer, not random happenstance. -- dwmw2 From ivazquez at ivazquez.net Sun May 8 09:35:27 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 08 May 2005 05:35:27 -0400 Subject: Request for review: OpenEXR In-Reply-To: <1115503349.24408.317.camel@ernie> References: <1114335625.7784.41.camel@ignacio.ignacio.lan> <1115377802.7124.1.camel@ignacio.ignacio.lan> <1115455194.7124.7.camel@ignacio.ignacio.lan> <1115489931.12675.0.camel@ignacio.ignacio.lan> <1115497327.9556.5.camel@bobcat.mine.nu> <1115497988.20211.1.camel@ignacio.ignacio.lan> <1115503349.24408.317.camel@ernie> Message-ID: <1115544927.13384.5.camel@ignacio.ignacio.lan> On Sat, 2005-05-07 at 18:02 -0400, Ed Hill wrote: > blockers: > - should be: BuildRequires: fltk-devel >= 1.1 > instead of: BuildRequires: fltk >= 1.1 > - you're installing shared libs so I think you ought to have: > %post -p /sbin/ldconfig > %postun -p /sbin/ldconfig > - the ownership of the "%files devel" is wrong, you need another: > "%defattr(-,root,root,-)" for the devel package All fixed. > - please delete all the hidden ".deps" files such as: > /usr/share/doc/OpenEXR-devel-1.2.2/IlmImfExamples/.deps I couldn't do this directly, and I couldn't find where in the makefile it copied .deps, so I did a small hack to get around it. > not sure about this one: > - Can the "%{_libdir}/*.la" files be discarded? Or are they > really needed? In this case they don't seem to add any dependency bloat, so it appears safe to leave them in. http://fedora.ivazquez.net/files/OpenEXR-1.2.2-2.src.rpm -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Sun May 8 09:34:56 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 08 May 2005 10:34:56 +0100 Subject: Fedora Extras Development Build Report In-Reply-To: <20050507170353.47f61c37.bugs.michael@gmx.net> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> Message-ID: <1115544898.29495.164.camel@localhost.localdomain> On Sat, 2005-05-07 at 17:03 +0200, Michael Schwendt wrote: > > No, gnupg2 builds fine on PPC. > > It did not. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156213 > http://fedoraproject.org/extras/development/build-logs/ppc/gnupg2-1.9.15-2.log > > Sometimes build failures are specific to mach or clean(er) chroots. I bumped the release number and resubmitted it, and this time it failed on x86_64, in the same place.... make[2]: Entering directory `/usr/src/rpm/BUILD/gnupg-1.9.15/tests' asschk: read_assuan: received incomplete line on fd 8 FAIL: sm-sign+verify PASS: sm-verify ====================================== 1 of 2 tests failed Please report to gnupg-devel at gnupg.org ====================================== -- dwmw2 From paul at city-fan.org Sun May 8 09:53:48 2005 From: paul at city-fan.org (Paul Howarth) Date: Sun, 08 May 2005 10:53:48 +0100 Subject: Self-Introduction: Paul Howarth In-Reply-To: <1115541659.5768.1.camel@rydia.hardsun.net> References: <427B4DD8.7020103@city-fan.org> <20050506140536.437a269d.bugs.michael@gmx.net> <427B6155.7050903@city-fan.org> <1115384664.24408.97.camel@ernie> <427B8A5D.9010205@city-fan.org> <1115541659.5768.1.camel@rydia.hardsun.net> Message-ID: <1115546028.4727.14.camel@laurel.intra.city-fan.org> On Sun, 2005-05-08 at 01:40 -0700, Aaron Kurtz wrote: > On Fri, 2005-05-06 at 16:16 +0100, Paul Howarth wrote: > > > In addition to the pptp package I referred to earlier > > (http://www.city-fan.org/~paul/extras/pptp/), I now have a > > GTorrentViewer package available for inspection: > > > > http://www.city-fan.org/~paul/extras/GTorrentViewer/ > > Ah, interesting package, with some nice features I haven't seen > elsewhere. Compiles and works without a problem. Thanks for looking at this. > As for the spec, first off, I'd suggest calling it gtorrentviewer > instead. It's what the binary is after all. See > http://fedoraproject.org/wiki/PackageNamingGuidelines#head-26057558c8d1ceba1dfb290d88fd8159c1794732 as well. I looked at the packaging guidelines earlier and this was one of those cases where it could go either way. Even the upstream author doesn't seem too sure, because all the references on the website (and indeed the tarball name) are mixed case, but the binary is, as you say, lower case. Anyone else have any thoughts on this? > Second, NEWS is a zero-length file, so take it out of the %doc line. Will do; surprised I missed that. > Third, I don't believe the use of the various %(__rm) and %(__make) macros are necessary, and seem to go against the usual Fedora style. I can certainly do that, but does replacing them actually make the package any better? Anyone else have any comments on that? > I'd also suggest the use of Dist Tags to make it easier to have > different e:v-r between releases. http://fedoraproject.org/wiki/DistTag I read the "make tag and %{?dist}" thread earlier this month and got the impression that all of this stuff was in a state of flux, which is why I left it out. I noted Warren Togami's post (https://www.redhat.com/archives/fedora-extras-list/2005- May/msg00061.html) that the "scary macro voodoo" was supposed to be being replaced by some scripting. I actually happen to like macros personally as they aid building cross-distro/release packages from the same spec file, so I'll probably do something like: %{!?dist: %define dist .fc3} as suggested by Ignacio Vazquez-Abrams (https://www.redhat.com/archives/fedora-extras-list/2005- May/msg00077.html) in the hope that it will be future-proof (). Paul. -- Paul Howarth From rc040203 at freenet.de Sun May 8 10:04:34 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 08 May 2005 12:04:34 +0200 Subject: Fedora Extras Development Build Report In-Reply-To: <1115543440.29495.161.camel@localhost.localdomain> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> <1115478757.29495.122.camel@localhost.localdomain> <20050507172800.6eec367c.bugs.michael@gmx.net> <1115480032.29495.127.camel@localhost.localdomain> <1115527553.8237.35.camel@mccallum.corsepiu.local> <1115543440.29495.161.camel@localhost.localdomain> Message-ID: <1115546674.8237.50.camel@mccallum.corsepiu.local> On Sun, 2005-05-08 at 10:10 +0100, David Woodhouse wrote: > On Sun, 2005-05-08 at 06:45 +0200, Ralf Corsepius wrote: > > Are you aware about how much effort had been required to get packages > > compiled on x86_64, when x86_64 was new? It took years. > > It'll never be that difficult again. We already have something 64-bit > and something big-endian. > > > Adding any new architecture will impose a similar footprint and will, if > > a policy of "one arch blocks all" is implemented, this policy will block > > packages on archs not being affected by the "blocking bug on one arch". > > That result wouldn't be acceptable; you're right. But neither is it what > I'm suggesting. Could you elaborate? It's how I understood your proposal and how Seth seems to have implemented the FE build system: ATM, one build failure on one of i386, x86_64 or ppc prevents building a package for the other architectures and therefore disqualifies a package from being upgraded. > Of _course_ we should be able to drop a problematic architecture from > the build to allow new packages to get built -- I'm suggesting that it > needs to be done _deliberately_ by use of ExcludeArch, rather than > merely by acting on spurious build failures. > > It needs to be a conscious decision on the part of the package > maintainer, not random happenstance. That's reasonable. We should try to provide the same packages for all supported architectures, but we should not let packages failing for some architectures block the package for those it does not fail. In practice, developers will only have access to a limited set of architectures, in some cases developers do not/do not want to support some architectures, so ... there will always be "second class citizen packages" on some architectures ... Ralf From ivazquez at ivazquez.net Sun May 8 10:09:18 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 08 May 2005 06:09:18 -0400 Subject: Self-Introduction: Paul Howarth In-Reply-To: <1115546028.4727.14.camel@laurel.intra.city-fan.org> References: <427B4DD8.7020103@city-fan.org> <20050506140536.437a269d.bugs.michael@gmx.net> <427B6155.7050903@city-fan.org> <1115384664.24408.97.camel@ernie> <427B8A5D.9010205@city-fan.org> <1115541659.5768.1.camel@rydia.hardsun.net> <1115546028.4727.14.camel@laurel.intra.city-fan.org> Message-ID: <1115546958.13384.10.camel@ignacio.ignacio.lan> On Sun, 2005-05-08 at 10:53 +0100, Paul Howarth wrote: > On Sun, 2005-05-08 at 01:40 -0700, Aaron Kurtz wrote: > > Third, I don't believe the use of the various %(__rm) and %(__make) > > macros are necessary, and seem to go against the usual Fedora style. > > I can certainly do that, but does replacing them actually make the > package any better? Anyone else have any comments on that? I don't think it really matters. If there's an upstream or umbrella spec file that you're trying to keep in sync with and it uses those macros then I'd say go ahead and leave them in. > > I'd also suggest the use of Dist Tags to make it easier to have > > different e:v-r between releases. http://fedoraproject.org/wiki/DistTag > > I read the "make tag and %{?dist}" thread earlier this month and got the > impression that all of this stuff was in a state of flux, which is why I > left it out. I noted Warren Togami's post > (https://www.redhat.com/archives/fedora-extras-list/2005- > May/msg00061.html) that the "scary macro voodoo" was supposed to be > being replaced by some scripting. I actually happen to like macros > personally as they aid building cross-distro/release packages from the > same spec file, so I'll probably do something like: > > %{!?dist: %define dist .fc3} > > as suggested by Ignacio Vazquez-Abrams > (https://www.redhat.com/archives/fedora-extras-list/2005- > May/msg00077.html) in the hope that it will be future-proof ( fingers>). I did find a problem whereby if you have %dist defined as per the macro definitions on the wiki page it can interfere with make tag, but I suppose that's why you should be using mach (and why the disttag macros should *not* go into redhat-rpm-config). -- 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 dwmw2 at infradead.org Sun May 8 11:13:38 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 08 May 2005 12:13:38 +0100 Subject: Fedora Extras Development Build Report In-Reply-To: <1115546674.8237.50.camel@mccallum.corsepiu.local> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> <1115478757.29495.122.camel@localhost.localdomain> <20050507172800.6eec367c.bugs.michael@gmx.net> <1115480032.29495.127.camel@localhost.localdomain> <1115527553.8237.35.camel@mccallum.corsepiu.local> <1115543440.29495.161.camel@localhost.localdomain> <1115546674.8237.50.camel@mccallum.corsepiu.local> Message-ID: <1115550819.29495.191.camel@localhost.localdomain> On Sun, 2005-05-08 at 12:04 +0200, Ralf Corsepius wrote: > It's how I understood your proposal and how Seth seems to have > implemented the FE build system: ATM, one build failure on one of i386, > x86_64 or ppc prevents building a package for the other architectures > and therefore disqualifies a package from being upgraded. We need to distinguish between a build failure which is observed by the build system, and the deliberate exclusion of a given architecture by use of ExcludeArch: in the spec file. The former _should_ be treated as an error and should prevent the package build from completing successfully. That's what you seem to be referring to above, and it's a good thing. The latter is OK, but should be used with care, and a bug should be filed in all cases when an ExcludeArch: is used. If a package fails to build, the package maintainer is expected to investigate the failure and determine the cause of the problem. If it's something which is actually arch-specific and repeatable, like a compiler bug, then the maintainer is free to add an ExcludeArch: for the offending architecture, with a comment referencing the bug which is preventing the build from working. Then the build can be retried, and should complete successfully. If the problem is within the package itself, the maintainer is expected to fix the problem as soon as possible -- that's what maintainers are for, after all. If the maintainer doesn't have time to fix the problem immediately, a bug should be filed explaining the problem and _perhaps_ an ExcludeArch: could be added in the meantime. > In practice, developers will only have access to a limited set of > architectures, in some cases developers do not/do not want to support > some architectures, so ... there will always be "second class citizen > packages" on some architectures ... I'm not sure who you're referring to when you say 'developers'. If you mean the upstream developers of the code in question, then it sounds like the package should never have been imported -- we should require sane, portable code in packages built for Extras. If you mean that the maintainer of the Extras package can't be bothered to do their job properly, then a more suitable maintainer can be found or the package dropped. -- dwmw2 From monkeyiq at users.sourceforge.net Sun May 8 13:08:59 2005 From: monkeyiq at users.sourceforge.net (Ben Martin) Date: Sun, 08 May 2005 23:08:59 +1000 Subject: STLPort 4.6.2 for possible inclusion in Fedora Extras. Message-ID: <1115557739.364.14.camel@sam> Hi, After chatting with some Fedora folks at linux.conf.au I have decided to start the process of packaging libferris available [1] via extras. I'm he author of the libferris project and many of its spin off sublibraries. To start the process I have decided to put forward STLport for inclusion. In keeping with [2] I have updated my existing specfile and rolled a src.rpm which are both available: http://kvo.itee.uq.edu.au/~martin/STLport.spec http://kvo.itee.uq.edu.au/~martin/STLport-4.6.2-1.src.rpm The specfile creates a pkg-config .pc file and as such requires knowing where prefix and libdir are going to be. I don't really mind removing the .pc file and if that is done the specfile should be more "normal". The main reason I include the .pc file generation is that it makes ./configure on clients much faster if you don't have to poke around the system and try_link() all the time to find your stlport. Of course the ./configures I have that *use* the stlport package all drop back to probing and try_link() but they first attempt to find by pkg- config. rpmlint complains about the protections of the source + patches being incorrect, a lack no-soname for the library and wrong-script-end-of- line-encoding for some headers. I suspect the header thing is either rpmlint being overparanoid or I have forgotten a directive in the specfile. The soname thing I am unsure of how to fix. The hardcoded-library-path error is to do with the fact that I need to know where the library is to make a .pc file for it. The License in the spec is not quite right, see its README for details. I thought at this point I'd throw the package out there and see what interest there is. I'll probably remove it from the webserver after a little while. $ rpmlint /tmp/rpmbuild/RPM/SRPMS/STLport-4.6.2-1.src.rpm E: STLport no-signature W: STLport strange-permission STLport.spec 0660 W: STLport strange-permission STLport-4.6.2.tar.gz 0400 W: STLport strange-permission STLport-4.6.2-make.patch 0400 W: STLport strange-permission STLport-64bit.patch 0660 W: STLport strange-permission STLport-4.6.2-paths.patch 0400 E: STLport hardcoded-library-path in /usr/lib $ rpmlint /tmp/rpmbuild/RPM/RPMS/athlon/STLport-4.6.2-1.athlon.rpm W: STLport no-soname /usr/lib/libstlport_gcc.so.4.6 E: STLport no-signature $ rpmlint /tmp/rpmbuild/RPM/RPMS/athlon/STLport-devel-4.6.2-1.athlon.rpm W: STLport-devel no-major-in-name STLport-devel W: STLport-devel no-documentation E: STLport-devel wrong-script-end-of-line- encoding /usr/include/stlport/stl/debug/_relops_hash_cont.h E: STLport-devel wrong-script-end-of-line- encoding /usr/include/stlport/stl/debug/_relops_cont.h E: STLport-devel wrong-script-end-of-line- encoding /usr/include/stlport/config/_msvc_warnings_off.h E: STLport-devel zero-length /usr/include/stlport/stl/_exception.h E: STLport-devel no-signature [1] http://witme.sourceforge.net/libferris.web/download/buildorder.html [2] http://fedoraproject.org/wiki/NewPackageProcess -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Sun May 8 13:09:35 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 8 May 2005 15:09:35 +0200 Subject: Fedora Extras Development Build Report In-Reply-To: <1115550819.29495.191.camel@localhost.localdomain> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> <1115478757.29495.122.camel@localhost.localdomain> <20050507172800.6eec367c.bugs.michael@gmx.net> <1115480032.29495.127.camel@localhost.localdomain> <1115527553.8237.35.camel@mccallum.corsepiu.local> <1115543440.29495.161.camel@localhost.localdomain> <1115546674.8237.50.camel@mccallum.corsepiu.local> <1115550819.29495.191.camel@localhost.localdomain> Message-ID: <20050508150935.1589e5f3.bugs.michael@gmx.net> On Sun, 08 May 2005 12:13:38 +0100, David Woodhouse wrote: > If the maintainer doesn't have time to fix the problem > immediately, a bug should be filed explaining the problem and _perhaps_ > an ExcludeArch: could be added in the meantime. It is also a matter of lack of interest, lack of motivation, lack of hardware, and lack of knowledge/experience. A packager, who builds and tests on i386 only, bases his decisions on the test results on this platform. It is really bad if a package, which is believed to be ready, fails to build on an untested platform and blocks the release of an update. Rest assured, this is a turn-off criterion for many volunteers. It is bad enough already, that i386 is not built first, so packagers get told that a build failed on another platform, and they don't know whether i386 would succeed in the build system. This is a wrong decision IMO. We do need the effort of an arch-specific community of developers and users, who help with making their special architecture as strong and supported as i386. Publishing untested packages is really bad. But currently, we're forced to publish packages for three architectures, two of them being untested for the majority of packages. Once marked ExcludeArch, a packager won't ever give rebuilds for the excluded architectures a try, as long as testing and testbuilding in his own development environment is only done for the architectures he has access to and interest in. > If the problem is within the package itself, the maintainer is expected > to fix the problem as soon as possible -- that's what maintainers are > for, after all. I'd like to suggest that such expectations towards volunteer packagers are documented somewhere soon. It is a pretty crucial requirement, if you distinguish strongly between package maintainers and "package-monkeys" (quote). Your messages in this thread [and earlier on] read very much like you are grumpy, initially when a packager suggested "ExcludeArch: ppc" to flag a package which fails to build on ppc. I still feel really bad about this sudden change in Fedora Extras philosophy, where ExcludeArch would be criticised. In my point of view, we have been good at fedora.us, where we only built for i386, in blocking broken packages and broken software releases from entering the repository. Well, except for a very few cases [e.g. "mach" -- Ralf might argue about this ;)], but that was also due to giving new contributors the opportunity to review and approve new packages from other new contributors on their own, i.e. without their judgement being questioned too much. It would have been a major hindrance, if one of the "trusted" contributors had to verify a new contributor's review in detail (and e.g. verify run-time stability, too). At some point in time, all packages were attempted to be rebuilt for x86_64 by Justin Forbes, and where multilib problems didn't hit us hard, segfaults did at run-time. Building for x86_64 was discontinued due to lack of contributor time, but was reintroduced with pre-Extras, and again, it broke packages, which were prepared and tested on the packagers primary i386 platform. > > In practice, developers will only have access to a limited set of > > architectures, in some cases developers do not/do not want to support > > some architectures, so ... there will always be "second class citizen > > packages" on some architectures ... > > I'm not sure who you're referring to when you say 'developers'. > > If you mean the upstream developers of the code in question, then it > sounds like the package should never have been imported -- we should > require sane, portable code in packages built for Extras. With all due respect, but here it's time for a quick reality check, I say, since what you want to require, requires the availability of test machines first _and_ contributors' interest in spending extra time on other architectures. > If you mean that the maintainer of the Extras package can't be bothered > to do their job properly, then a more suitable maintainer can be found > or the package dropped. Have fun with that! FWIW, I value contributors, who don't want to publish untested packages, more than contributors who release what seems to build. If, however, you are successful in finding volunteers, who focus on three architectures and also take over the testing not done by upstream developers, that would be good news for Fedora Extras. From skvidal at phy.duke.edu Sun May 8 14:12:07 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 08 May 2005 10:12:07 -0400 Subject: Fedora Extras Development Build Report In-Reply-To: <1115550819.29495.191.camel@localhost.localdomain> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> <1115478757.29495.122.camel@localhost.localdomain> <20050507172800.6eec367c.bugs.michael@gmx.net> <1115480032.29495.127.camel@localhost.localdomain> <1115527553.8237.35.camel@mccallum.corsepiu.local> <1115543440.29495.161.camel@localhost.localdomain> <1115546674.8237.50.camel@mccallum.corsepiu.local> <1115550819.29495.191.camel@localhost.localdomain> Message-ID: <1115561527.21549.0.camel@cutter> On Sun, 2005-05-08 at 12:13 +0100, David Woodhouse wrote: > On Sun, 2005-05-08 at 12:04 +0200, Ralf Corsepius wrote: > > It's how I understood your proposal and how Seth seems to have > > implemented the FE build system: ATM, one build failure on one of i386, > > x86_64 or ppc prevents building a package for the other architectures > > and therefore disqualifies a package from being upgraded. > > We need to distinguish between a build failure which is observed by the > build system, and the deliberate exclusion of a given architecture by > use of ExcludeArch: in the spec file. > ExcludeArch, ExclusiveArch and BuildArch are all taken into account by the buildsystem. It only builds the packages on the requested archs. -sv From dwmw2 at infradead.org Sun May 8 14:11:58 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 08 May 2005 15:11:58 +0100 Subject: Fedora Extras Development Build Report In-Reply-To: <20050508150935.1589e5f3.bugs.michael@gmx.net> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> <1115478757.29495.122.camel@localhost.localdomain> <20050507172800.6eec367c.bugs.michael@gmx.net> <1115480032.29495.127.camel@localhost.localdomain> <1115527553.8237.35.camel@mccallum.corsepiu.local> <1115543440.29495.161.camel@localhost.localdomain> <1115546674.8237.50.camel@mccallum.corsepiu.local> <1115550819.29495.191.camel@localhost.localdomain> <20050508150935.1589e5f3.bugs.michael@gmx.net> Message-ID: <1115561519.29495.244.camel@localhost.localdomain> On Sun, 2005-05-08 at 15:09 +0200, Michael Schwendt wrote: > On Sun, 08 May 2005 12:13:38 +0100, David Woodhouse wrote: > > > If the maintainer doesn't have time to fix the problem > > immediately, a bug should be filed explaining the problem and _perhaps_ > > an ExcludeArch: could be added in the meantime. > > It is also a matter of lack of interest, lack of motivation, Those are not traits which are expected of a maintainer. > lack of hardware, and lack of knowledge/experience. Access to hardware can be arranged, as can assistance from those with more arch-specific knowledge or experience. > A packager, who builds and tests on i386 only, bases his decisions on the > test results on this platform. This is true. As it happens, I base my decisions almost exclusively on the test results for PPC -- even for the packages I maintain in Core. This is because most of the problems I'm likely to see are independent of architecture. There will _always_ be some bugs which don't happen to show up for the maintainer, even with the most rigorous test regime. Yes, the fact that maintainers often test on only one platform instead of all seven is a part of that -- but even if maintainers have sufficient hardware, time and inclination to repeat whatever testing they do on all of the available platforms, there'd still be plenty of bugs which slipped through. > It is really bad if a package, which is believed to be ready, fails to > build on an untested platform and blocks the release of an update. > Rest assured, this is a turn-off criterion for many volunteers. I can see _spurious_ build failures being a turn-off, and I'm a little concerned by the ones I've seen in the last day or so. But build failures which show _real_ problems are what the volunteer has volunteered for, surely? Dealing with that is the r?le of the package maintainer. > It is bad enough already, that i386 is not built first, so packagers get > told that a build failed on another platform, and they don't know whether > i386 would succeed in the build system. This is a wrong decision IMO. I'm not sure I see the logic. For any given version of a package, there may be any number of bugs which prevent it from building. The package maintainer needs to look at each one individually and fix it before moving on to the next. Any given pass through the build system will only show up one such error before it bails out -- why does the ordering really matter? It's sort of expected that the package is observed to build locally on at least _one_ platform before the maintainer even commits it and requests a build. If the maintainer is working on i386, then presumably she already knows that the i386 version builds? > We do need the effort of an arch-specific community of developers and > users, who help with making their special architecture as strong and > supported as i386. Agreed. Some stuff really is arch-specific and does need to be looked at by someone with a little more experience. If a package maintainer needs help fixing a bug which she has determined is PPC-specific, then I'm more than happy to be added to the Cc list in bugzilla. I'm sure there are people who will do the same for i386- and x86-64-specific problems; not everyone speaks i386 assembly, for example. > Publishing untested packages is really bad. But currently, we're forced > to publish packages for three architectures, two of them being untested > for the majority of packages. That's just a special case of "you can't test _every_ situation". Most bugs aren't arch-specific, and most of the bugs I've dealt with recently which _have_ been arch-specific have shown up at build time, not at run time. You really don't lose out on much by testing only on one platform. > Once marked ExcludeArch, a packager won't ever give rebuilds for the > excluded architectures a try, as long as testing and testbuilding in his > own development environment is only done for the architectures he has > access to and interest in. This is why we should be requiring an open bugzilla bug for every such exclusion. Otherwise the exclusion lasts for ever and people forget why it was there. This is something I want to see in Core too. > > If the problem is within the package itself, the maintainer is expected > > to fix the problem as soon as possible -- that's what maintainers are > > for, after all. > > I'd like to suggest that such expectations towards volunteer packagers are > documented somewhere soon. > > It is a pretty crucial requirement, if you distinguish strongly between > package maintainers and "package-monkeys" (quote). I agree, and I don't want to discourage volunteers. It should be clear that assistance is available for volunteers who _want_ to help but are concerned that they may not currently be _capable_ of being anything more than a 'package-monkey'. > Your messages in this thread [and earlier on] read very much like you are > grumpy, initially when a packager suggested "ExcludeArch: ppc" to flag a > package which fails to build on ppc. I'm not grumpy; I'm not aware that anyone had done such a thing. I happened to notice a build failure on PPC and tried to help debug it. Then we digressed into a discussion of policy, after I realised that gnupg2-1.9.15-2 was present on i386 but not on PPC due to a _spurious_ build failure. > I still feel really bad about this sudden change in Fedora Extras > philosophy, where ExcludeArch would be criticised. I'm not saying that ExcludeArch should necessarily be criticised; I'm saying that it should be used sparingly, and only with reference to a bug report which explains what the actual problem was. For example, I _would_ have been grumpy if gnupg2 had ended up with an unexplained 'ExcludeArch: ppc' just because of the spurious build failure which seems to happen on x86_64 now too. > > If you mean the upstream developers of the code in question, then it > > sounds like the package should never have been imported -- we should > > require sane, portable code in packages built for Extras. > > With all due respect, but here it's time for a quick reality check, I say, > since what you want to require, requires the availability of test machines > first _and_ contributors' interest in spending extra time on other > architectures. No, really. You don't need test machines in order to write sane, portable code. You just need a modicum of clue, and a little bit of attention to detail. You don't make assumptions about word size, you don't make assumptions about endianness, etc. Yes, you do need to be interested in writing good code. That is an interest which should be encouraged -- lazy people are going to write bad code which breaks even on i386 at times, not just on other platforms. > > If you mean that the maintainer of the Extras package can't be bothered > > to do their job properly, then a more suitable maintainer can be found > > or the package dropped. > > Have fun with that! FWIW, I value contributors, who don't want to publish > untested packages, more than contributors who release what seems to build. > If, however, you are successful in finding volunteers, who focus on three > architectures and also take over the testing not done by upstream > developers, that would be good news for Fedora Extras. I think you overestimate the benefit you'd gain from repeating your testing on multiple platforms. Those packages with automated tests can already run those tests during the RPM build phase -- the gnupg2 failure mentioned above was actually in _testing_ not actually during the compilation stage, for example. Those packages with only ad-hoc testing would benefit more from developing an automated test suite than they would from repeating whatever tests the packager feels like doing, but on multiple platforms. -- dwmw2 From fedora at leemhuis.info Sun May 8 14:32:56 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 08 May 2005 16:32:56 +0200 Subject: Fedora Extras Development Build Report In-Reply-To: <20050508150935.1589e5f3.bugs.michael@gmx.net> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> <1115478757.29495.122.camel@localhost.localdomain> <20050507172800.6eec367c.bugs.michael@gmx.net> <1115480032.29495.127.camel@localhost.localdomain> <1115527553.8237.35.camel@mccallum.corsepiu.local> <1115543440.29495.161.camel@localhost.localdomain> <1115546674.8237.50.camel@mccallum.corsepiu.local> <1115550819.29495.191.camel@localhost.localdomain> <20050508150935.1589e5f3.bugs.michael@gmx.net> Message-ID: <1115562777.5431.49.camel@notebook.thl.home> Am Sonntag, den 08.05.2005, 15:09 +0200 schrieb Michael Schwendt: > On Sun, 08 May 2005 12:13:38 +0100, David Woodhouse wrote: > > If the maintainer doesn't have time to fix the problem > > immediately, a bug should be filed explaining the problem and _perhaps_ > > an ExcludeArch: could be added in the meantime. > > It is also a matter of lack of interest, lack of motivation, lack of > hardware, and lack of knowledge/experience. > > A packager, who builds and tests on i386 only, bases his decisions on the > test results on this platform. It is really bad if a package, which is > believed to be ready, fails to build on an untested platform and blocks > the release of an update. [...] Just a side node for this discussion: What do we want do to in case of a security update? Block the updated package also if it failed on one of the archs? IMHO a bad decision if the resulting delay might be longer than one or two days. > It is bad enough already, that i386 is not built first, so packagers get > told that a build failed on another platform, and they don't know whether > i386 would succeed in the build system. This is a wrong decision IMO. IMO too. *Maybe* the build-systems also could (it has nothing other to build) try to build a "failed on one arch" package on the others archs to see if those are working (okay, often it's a general problem: so maybe better: if it worked on i386 try on all the others). > We do need the effort of an arch-specific community of developers and > users, who help with making their special architecture as strong and > supported as i386. Well, you propose this more then once here for some weeks now iirc. What is needed to get this "official". Did you discuss it on the FESCO- Meetings? I'm all for such a solution (as long as the burden lies on more than one shoulder per arch). I ask cause I tried to fix some of the x86_64 problems and often did it myself in the cvs -- some of the maintainers might wonder what the heck this stupid person (e.g. me) was doing there. I would feel better if this work was "official" in some way. With such a group of persons (or even maillinglists extras-ppc and extras-x86_64 [yes, I know, we have enough list already so forget the last sentence]) the maintainers would know who to contact in case of problems they can't solve on their own. > Publishing untested packages is really bad. But currently, we're forced > to publish packages for three architectures, two of them being untested > for the majority of packages. As I said before: Testing them before publishing is IMHO a good idea. But sometimes I don't think it's possible: In the longer run there might be too many packages for this and sometimes it's hard to test if a package works if you don't know it (e.g. Coin2, ocaml, ...). [...] > > > In practice, developers will only have access to a limited set of > > > architectures, in some cases developers do not/do not want to support > > > some architectures, so ... there will always be "second class citizen > > > packages" on some architectures ... > > > > I'm not sure who you're referring to when you say 'developers'. > > > > If you mean the upstream developers of the code in question, then it > > sounds like the package should never have been imported -- we should > > require sane, portable code in packages built for Extras. > > With all due respect, but here it's time for a quick reality check, I say, > since what you want to require, requires the availability of test machines > first _and_ contributors' interest in spending extra time on other > architectures. And the knowledge/experience in C, C++/"Whatever Language my Package is in". I'm one of those who learned to package RPMS in the last two years in fedora.us & co, but my programming experience (besides scripts in bash) is near NULL. So if my package does not build on PPC I only can fix it myself if is something trivial. (BTW, Michael und Adrian, thanks for fixing GCC4 problems in some of my extras packages) And those who know "their" arch imho can fix problems a lot faster then others. I think I've seen most of the x86_64 problems now and know how to fix them -- for the maintainers it might be hard and very disappointing. We should not burn their energy if they don't want to fix it own their own. > > If you mean that the maintainer of the Extras package can't be bothered > > to do their job properly, then a more suitable maintainer can be found > > or the package dropped. Seems i must leave then ;-) > Have fun with that! FWIW, I value contributors, who don't want to publish > untested packages, more than contributors who release what seems to build. > If, however, you are successful in finding volunteers, who focus on three > architectures and also take over the testing not done by upstream > developers, that would be good news for Fedora Extras. ...but is unlikely afaics. -- Thorsten Leemhuis From rc040203 at freenet.de Sun May 8 15:07:42 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 08 May 2005 17:07:42 +0200 Subject: Fedora Extras Development Build Report In-Reply-To: <1115561527.21549.0.camel@cutter> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> <1115478757.29495.122.camel@localhost.localdomain> <20050507172800.6eec367c.bugs.michael@gmx.net> <1115480032.29495.127.camel@localhost.localdomain> <1115527553.8237.35.camel@mccallum.corsepiu.local> <1115543440.29495.161.camel@localhost.localdomain> <1115546674.8237.50.camel@mccallum.corsepiu.local> <1115550819.29495.191.camel@localhost.localdomain> <1115561527.21549.0.camel@cutter> Message-ID: <1115564862.8237.64.camel@mccallum.corsepiu.local> On Sun, 2005-05-08 at 10:12 -0400, seth vidal wrote: > On Sun, 2005-05-08 at 12:13 +0100, David Woodhouse wrote: > > On Sun, 2005-05-08 at 12:04 +0200, Ralf Corsepius wrote: > > > It's how I understood your proposal and how Seth seems to have > > > implemented the FE build system: ATM, one build failure on one of i386, > > > x86_64 or ppc prevents building a package for the other architectures > > > and therefore disqualifies a package from being upgraded. > > > > We need to distinguish between a build failure which is observed by the > > build system, and the deliberate exclusion of a given architecture by > > use of ExcludeArch: in the spec file. > > > > ExcludeArch, ExclusiveArch and BuildArch are all taken into account by > the buildsystem. It only builds the packages on the requested archs. Great - That's good news - This covers build failures. Who is going to "validate run-time function" of packages, original package developers and FE package maintainers can't/don't want to test a package on? Unleash a package to the public and wait for what's going to happen? Ralf From dwmw2 at infradead.org Sun May 8 15:38:44 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 08 May 2005 16:38:44 +0100 Subject: Fedora Extras Development Build Report In-Reply-To: <1115562777.5431.49.camel@notebook.thl.home> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> <1115478757.29495.122.camel@localhost.localdomain> <20050507172800.6eec367c.bugs.michael@gmx.net> <1115480032.29495.127.camel@localhost.localdomain> <1115527553.8237.35.camel@mccallum.corsepiu.local> <1115543440.29495.161.camel@localhost.localdomain> <1115546674.8237.50.camel@mccallum.corsepiu.local> <1115550819.29495.191.camel@localhost.localdomain> <20050508150935.1589e5f3.bugs.michael@gmx.net> <1115562777.5431.49.camel@notebook.thl.home> Message-ID: <1115566724.3755.26.camel@localhost.localdomain> On Sun, 2005-05-08 at 16:32 +0200, Thorsten Leemhuis wrote: > Just a side node for this discussion: What do we want do to in case of a > security update? Block the updated package also if it failed on one of > the archs? IMHO a bad decision if the resulting delay might be longer > than one or two days. Security fixes are generally fairly minimal. The chances of them introducing build failures are somewhat unlikely. > > It is bad enough already, that i386 is not built first, so packagers get > > told that a build failed on another platform, and they don't know whether > > i386 would succeed in the build system. This is a wrong decision IMO. > > IMO too. *Maybe* the build-systems also could (it has nothing other to > build) try to build a "failed on one arch" package on the others archs > to see if those are working (okay, often it's a general problem: so > maybe better: if it worked on i386 try on all the others). What's the point? If it doesn't build on all the platforms it claims to build on, it's broken. If it's _known_ not to build on a given architecture, then the maintainer needs to make sure an appropriate bug is filed, and then add an ExcludeArch: and resubmit the build. Why does it help to let it run to completion on other architectures? > > We do need the effort of an arch-specific community of developers and > > users, who help with making their special architecture as strong and > > supported as i386. > > Well, you propose this more then once here for some weeks now iirc. What > is needed to get this "official". Did you discuss it on the FESCO- > Meetings? I'm all for such a solution (as long as the burden lies on > more than one shoulder per arch). It isn't really an arch-specific thing either. You pointed out that there were a bunch of people who helped with gcc4 build failures; why should that be considered different? If you really want to treat arch-specific 'helpers' differently, then you probably don't need more than one per arch. The incidence of bugs which really are arch-specific just isn't that high. > As I said before: Testing them before publishing is IMHO a good idea. > But sometimes I don't think it's possible: In the longer run there might > be too many packages for this and sometimes it's hard to test if a > package works if you don't know it (e.g. Coin2, ocaml, ...). You can run automated test suites as part of the RPM build process. > And the knowledge/experience in C, C++/"Whatever Language my Package is > in". I'm one of those who learned to package RPMS in the last two years > in fedora.us & co, but my programming experience (besides scripts in > bash) is near NULL. So if my package does not build on PPC I only can > fix it myself if is something trivial. > > (BTW, Michael und Adrian, thanks for fixing GCC4 problems in some of my > extras packages) > > And those who know "their" arch imho can fix problems a lot faster then > others. I think I've seen most of the x86_64 problems now and know how > to fix them -- for the maintainers it might be hard and very > disappointing. We should not burn their energy if they don't want to fix > it own their own. That's fine -- assistance is always on hand. Nobody's suggesting that package maintainers should be all-capable. Just that it's unacceptable for them to declare that a problem is uninteresting just because it happens to be on an architecture which they don't personally use. Along the same lines, it's unacceptable that a package maintainer should ignore bugs even on one of the architectures they _do_ use, just because the reporter of the bug is trying to do something which the maintainer himself doesn't need. If you're maintaining a package which correctly does only what _you_ want it for and nothing more, you might as well just maintain it privately, not in Extras. > > > If you mean that the maintainer of the Extras package can't be bothered > > > to do their job properly, then a more suitable maintainer can be found > > > or the package dropped. > > Seems i must leave then ;-) Not at all. AFAICT you know when to ask for assistance, and you're willing to chase up reported bugs which don't affect you personally. That's perfectly reasonable. -- dwmw2 From fedora at leemhuis.info Sun May 8 15:53:07 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 08 May 2005 17:53:07 +0200 Subject: Delay between cvs commit and build-request/build Message-ID: <1115567587.5431.79.camel@notebook.thl.home> Hi * We had something like the following once before, I can't find it in the archives (did not search very long), but it is somewhere. The purpose of the "Fedora Extras CVS commits " Mailinglist was/is to make it possible for others like sponsors, package reviewers or other interested parties to check the fixes/changes that were committed to cvs before they get build/published. With the build-system now working automatically most packagers (including myself ;-) ) request build directly after committing. So actually no real check before build/publish (the latter actually depends on sign-time) is possible. Should there be a delay in this process somewhere? At least 24 hours for example? Requesting build after commit is imho understandable and okay (if the publish can be canceled somehow) -- with this way you don't have to come back later to request the build (otherwise it might be forgotten if you touch a lot of different packages on one day). But maybe the packages should not be signed/pushed in the 24 hours (or maybe 48 hours) after the build-request/cvs-commit?! Opinions? -- Thorsten Leemhuis From rc040203 at freenet.de Sun May 8 16:12:44 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 08 May 2005 18:12:44 +0200 Subject: Fedora Extras Development Build Report In-Reply-To: <1115562777.5431.49.camel@notebook.thl.home> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> <1115478757.29495.122.camel@localhost.localdomain> <20050507172800.6eec367c.bugs.michael@gmx.net> <1115480032.29495.127.camel@localhost.localdomain> <1115527553.8237.35.camel@mccallum.corsepiu.local> <1115543440.29495.161.camel@localhost.localdomain> <1115546674.8237.50.camel@mccallum.corsepiu.local> <1115550819.29495.191.camel@localhost.localdomain> <20050508150935.1589e5f3.bugs.michael@gmx.net> <1115562777.5431.49.camel@notebook.thl.home> Message-ID: <1115568764.8237.102.camel@mccallum.corsepiu.local> On Sun, 2005-05-08 at 16:32 +0200, Thorsten Leemhuis wrote: > Am Sonntag, den 08.05.2005, 15:09 +0200 schrieb Michael Schwendt: > > On Sun, 08 May 2005 12:13:38 +0100, David Woodhouse wrote: > > > If the maintainer doesn't have time to fix the problem > > > immediately, a bug should be filed explaining the problem and _perhaps_ > > > an ExcludeArch: could be added in the meantime. > > > > It is also a matter of lack of interest, lack of motivation, lack of > > hardware, and lack of knowledge/experience. > > > > A packager, who builds and tests on i386 only, bases his decisions on the > > test results on this platform. It is really bad if a package, which is > > believed to be ready, fails to build on an untested platform and blocks > > the release of an update. [...] > > We do need the effort of an arch-specific community of developers and > > users, who help with making their special architecture as strong and > > supported as i386. > I ask cause I tried to fix some of the x86_64 problems and often did it > myself in the cvs -- some of the maintainers might wonder what the heck > this stupid person (e.g. me) was doing there. I would feel better if > this work was "official" in some way. ACK - IMO, the way you have been handling x86_64 problems is the FE packaging should work. Packaging should be considered a collaborative effort and must not degenerate to "setup claims". > With such a group of persons (or even maillinglists extras-ppc and > extras-x86_64 [yes, I know, we have enough list already so forget the > last sentence]) the maintainers would know who to contact in case of > problems they can't solve on their own. I would prefer to see this thought generalized, i.e. not only with regard to architectures, but to general "fields of competence" (Everybody's knowledge is limited, everybody is human and nobody is omniscient). > > > If you mean that the maintainer of the Extras package can't be bothered > > > to do their job properly, then a more suitable maintainer can be found > > > or the package dropped. And how do you guarantee 24/7/365 reachability and sustainable development? Remember, this is supposed to be a project run by volunteers. You can't commit anybody to do anything, nor can you make anybody liable for anything - IMO, the only solution is to KISS and to team up. > Seems i must leave then ;-) ... same here. Ralf From fedora at leemhuis.info Sun May 8 16:15:31 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 08 May 2005 18:15:31 +0200 Subject: Fedora Extras Development Build Report In-Reply-To: <1115566724.3755.26.camel@localhost.localdomain> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> <1115478757.29495.122.camel@localhost.localdomain> <20050507172800.6eec367c.bugs.michael@gmx.net> <1115480032.29495.127.camel@localhost.localdomain> <1115527553.8237.35.camel@mccallum.corsepiu.local> <1115543440.29495.161.camel@localhost.localdomain> <1115546674.8237.50.camel@mccallum.corsepiu.local> <1115550819.29495.191.camel@localhost.localdomain> <20050508150935.1589e5f3.bugs.michael@gmx.net> <1115562777.5431.49.camel@notebook.thl.home> <1115566724.3755.26.camel@localhost.localdomain> Message-ID: <1115568931.5431.98.camel@notebook.thl.home> Am Sonntag, den 08.05.2005, 16:38 +0100 schrieb David Woodhouse: > On Sun, 2005-05-08 at 16:32 +0200, Thorsten Leemhuis wrote: > > Just a side node for this discussion: What do we want do to in case of a > > security update? Block the updated package also if it failed on one of > > the archs? IMHO a bad decision if the resulting delay might be longer > > than one or two days. > > Security fixes are generally fairly minimal. The chances of them > introducing build failures are somewhat unlikely. I tend to think the same -- but sooner or later it will happen ;-) > > > It is bad enough already, that i386 is not built first, so packagers get > > > told that a build failed on another platform, and they don't know whether > > > i386 would succeed in the build system. This is a wrong decision IMO. > > > > IMO too. *Maybe* the build-systems also could (it has nothing other to > > build) try to build a "failed on one arch" package on the others archs > > to see if those are working (okay, often it's a general problem: so > > maybe better: if it worked on i386 try on all the others). > > What's the point? If it doesn't build on all the platforms it claims to > build on, it's broken. If it's _known_ not to build on a given > architecture, then the maintainer needs to make sure an appropriate bug > is filed, and then add an ExcludeArch: and resubmit the build. Why does > it help to let it run to completion on other architectures? With three archs currently I tend to agree. But let make this four or five: - request build - build fails on x86_64 - fix + request build - build fails on ppc - fix + request build - build fails on IA64 - fix + request build - build fails on sparc - fix + request build - done against: - request build - build fails on x86_64, PPC, IA64,sparc - fix + request build - done A lot easier IMHO > > > We do need the effort of an arch-specific community of developers and > > > users, who help with making their special architecture as strong and > > > supported as i386. > > > > Well, you propose this more then once here for some weeks now iirc. What > > is needed to get this "official". Did you discuss it on the FESCO- > > Meetings? I'm all for such a solution (as long as the burden lies on > > more than one shoulder per arch). > > It isn't really an arch-specific thing either. You pointed out that > there were a bunch of people who helped with gcc4 build failures; why > should that be considered different? Yes, maybe there should be such a maintainer-group also when such big changes are ahead. But those changes happen only about once a year (or even rarer) with together with bigger Core updates. Arch-Problems can happen each day. And then the maintainer needs to know whom to ask. > If you really want to treat arch-specific 'helpers' differently, then > you probably don't need more than one per arch. The incidence of bugs > which really are arch-specific just isn't that high. At least two imho. > > As I said before: Testing them before publishing is IMHO a good idea. > > But sometimes I don't think it's possible: In the longer run there might > > be too many packages for this and sometimes it's hard to test if a > > package works if you don't know it (e.g. Coin2, ocaml, ...). > > You can run automated test suites as part of the RPM build process. In some packages, not in all. But I don't have a strong opinion here. Imho we simply should use extras/testing (or something like that) for this. Put it there after building (before signing? Signed with an automatic key?). If someone verifies push it after out after at least 2 days. If not, put it out after 14 days without verifying. > > And the knowledge/experience in C, C++/"Whatever Language my Package is > > in". I'm one of those who learned to package RPMS in the last two years > > in fedora.us & co, but my programming experience (besides scripts in > > bash) is near NULL. So if my package does not build on PPC I only can > > fix it myself if is something trivial. > > > > (BTW, Michael und Adrian, thanks for fixing GCC4 problems in some of my > > extras packages) > > > > And those who know "their" arch imho can fix problems a lot faster then > > others. I think I've seen most of the x86_64 problems now and know how > > to fix them -- for the maintainers it might be hard and very > > disappointing. We should not burn their energy if they don't want to fix > > it own their own. > > That's fine -- assistance is always on hand. Nobody's suggesting that > package maintainers should be all-capable. Just that it's unacceptable > for them to declare that a problem is uninteresting just because it > happens to be on an architecture which they don't personally use. > > Along the same lines, it's unacceptable that a package maintainer should > ignore bugs even on one of the architectures they _do_ use, just because > the reporter of the bug is trying to do something which the maintainer > himself doesn't need. > > If you're maintaining a package which correctly does only what _you_ > want it for and nothing more, you might as well just maintain it > privately, not in Extras. We agree here. > > > > If you mean that the maintainer of the Extras package can't be bothered > > > > to do their job properly, then a more suitable maintainer can be found > > > > or the package dropped. > > > > Seems i must leave then ;-) > > Not at all. AFAICT you know when an whom ;-) That imho something that not every current extras-packages knows for x86_64 and ppc > to ask for assistance, and you're > willing to chase up reported bugs which don't affect you personally. > That's perfectly reasonable. -- Thorsten Leemhuis From mattdm at mattdm.org Sun May 8 16:41:47 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 8 May 2005 12:41:47 -0400 Subject: Fedora Extras Development Build Report In-Reply-To: <1115568931.5431.98.camel@notebook.thl.home> References: <20050507172800.6eec367c.bugs.michael@gmx.net> <1115480032.29495.127.camel@localhost.localdomain> <1115527553.8237.35.camel@mccallum.corsepiu.local> <1115543440.29495.161.camel@localhost.localdomain> <1115546674.8237.50.camel@mccallum.corsepiu.local> <1115550819.29495.191.camel@localhost.localdomain> <20050508150935.1589e5f3.bugs.michael@gmx.net> <1115562777.5431.49.camel@notebook.thl.home> <1115566724.3755.26.camel@localhost.localdomain> <1115568931.5431.98.camel@notebook.thl.home> Message-ID: <20050508164147.GA1908@jadzia.bu.edu> On Sun, May 08, 2005 at 06:15:31PM +0200, Thorsten Leemhuis wrote: > > Security fixes are generally fairly minimal. The chances of them > > introducing build failures are somewhat unlikely. > I tend to think the same -- but sooner or later it will happen ;-) Especially considering the policy of going to new upstream versions for security fixes rather than applying patches -- a new version could fix the problem *and* break some arch. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 73 degrees Fahrenheit. From skvidal at phy.duke.edu Sun May 8 16:44:31 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 08 May 2005 12:44:31 -0400 Subject: Fedora Extras Development Build Report In-Reply-To: <1115564862.8237.64.camel@mccallum.corsepiu.local> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> <1115478757.29495.122.camel@localhost.localdomain> <20050507172800.6eec367c.bugs.michael@gmx.net> <1115480032.29495.127.camel@localhost.localdomain> <1115527553.8237.35.camel@mccallum.corsepiu.local> <1115543440.29495.161.camel@localhost.localdomain> <1115546674.8237.50.camel@mccallum.corsepiu.local> <1115550819.29495.191.camel@localhost.localdomain> <1115561527.21549.0.camel@cutter> <1115564862.8237.64.camel@mccallum.corsepiu.local> Message-ID: <1115570671.21549.11.camel@cutter> > Great - That's good news - This covers build failures. > > Who is going to "validate run-time function" of packages, original > package developers and FE package maintainers can't/don't want to test a > package on? > > Unleash a package to the public and wait for what's going to happen? > -ENOTMYPROBLEM -sv From bugs.michael at gmx.net Sun May 8 16:48:18 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 8 May 2005 18:48:18 +0200 Subject: Fedora Extras Development Build Report In-Reply-To: <1115561519.29495.244.camel@localhost.localdomain> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> <1115478757.29495.122.camel@localhost.localdomain> <20050507172800.6eec367c.bugs.michael@gmx.net> <1115480032.29495.127.camel@localhost.localdomain> <1115527553.8237.35.camel@mccallum.corsepiu.local> <1115543440.29495.161.camel@localhost.localdomain> <1115546674.8237.50.camel@mccallum.corsepiu.local> <1115550819.29495.191.camel@localhost.localdomain> <20050508150935.1589e5f3.bugs.michael@gmx.net> <1115561519.29495.244.camel@localhost.localdomain> Message-ID: <20050508184818.176c632d.bugs.michael@gmx.net> On Sun, 08 May 2005 15:11:58 +0100, David Woodhouse wrote: > There will _always_ be some bugs which don't happen to show up for the > maintainer, even with the most rigorous test regime. > > Yes, the fact that maintainers often test on only one platform instead > of all seven is a part of that -- but even if maintainers have > sufficient hardware, time and inclination to repeat whatever testing > they do on all of the available platforms, there'd still be plenty of > bugs which slipped through. This describes a scenario which is very different from the one I refer to: publishing completely untested builds, which fail badly and make Fedora Extras look bad. E.g. we've had immediate crashes with a few packages on x86_64. In more than one case we offered something, which didn't work at all. That's a worst-case scenario IMO. And the packager could not be blamed, because he had not asked for a release on x86_64. > > It is really bad if a package, which is believed to be ready, fails to > > build on an untested platform and blocks the release of an update. > > Rest assured, this is a turn-off criterion for many volunteers. > > I can see _spurious_ build failures being a turn-off, and I'm a little > concerned by the ones I've seen in the last day or so. But build > failures which show _real_ problems are what the volunteer has > volunteered for, surely? Dealing with that is the r?le of the package > maintainer. Example: when I mentioned the failed rebuild of gnupg2, which was reported to fail in its tests on PPC, you suggested that maybe a bug in the compiler was fixed meanwhile. When the same package builds fine on i386 (which must be checked, most likely with ExcludeArch, because the build system would not build for i386 if it failed for the archs built earlier), this is an indication of side-effects, or unportable code, which causes run-time misbehaviour. Perhaps due to different endianess, abuse of C-style casts or other things coders do, but maybe because something else in the PPC environment is broken. Effectively, the volunteer packager is expected to expand his interest and care for development and support of a platform, which he doesn't use, and probably related specific mailing-lists and topics of discussion. In case he's not, he could just add ExcludeArch, file an arch-specific bug report, and move on [and hopefully have more time to keep contact with upstream activity, do testing and release well-selected quality updates, which please the user community]. Arch-specific fixes could be requested and contributed upstream. > > It is bad enough already, that i386 is not built first, so packagers get > > told that a build failed on another platform, and they don't know whether > > i386 would succeed in the build system. This is a wrong decision IMO. > > I'm not sure I see the logic. For any given version of a package, there > may be any number of bugs which prevent it from building. The package > maintainer needs to look at each one individually and fix it before > moving on to the next. > > Any given pass through the build system will only show up one such error > before it bails out -- why does the ordering really matter? If you usually prepare and test your package on i386, you would start debugging and fixing problems on i386 when the build system reports an unexpected build failure for that arch. If the build request stops with an error on x86_64, would you start debugging on i386 only to find that a) you can't seem to reproduce the failure, b) you would need to re-run "make" on an x86_64 machine more than a dozen times to locate e.g. type-specific compilation errors in many places which don't show up on i386, or c) you are stuck in a loop of failed builds, because a contributed fix for one arch breaks a different arch unexpectedly. The information that not just your private build on i386, but also the i386 build in the official build system, did succeed, would be a helpful time saver. That would result in a known good state like "i386 built fine, x86_64 failed" as opposed to "i386 unknown, x86_64 failed". > I'm not saying that ExcludeArch should necessarily be criticised; I'm > saying that it should be used sparingly, and only with reference to a > bug report which explains what the actual problem was. +1 > For example, I _would_ have been grumpy if gnupg2 had ended up with an > unexplained 'ExcludeArch: ppc' just because of the spurious build > failure which seems to happen on x86_64 now too. It would not surprise me if somewhere deep in the code there's a race condition similar to the one I tracked down and avoided in gpgme (upstream acknowledged the problem, but a real fix would require a bit of a rewrite/redesign). From bugs.michael at gmx.net Sun May 8 16:48:25 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 8 May 2005 18:48:25 +0200 Subject: Fedora Extras Development Build Report In-Reply-To: <1115562777.5431.49.camel@notebook.thl.home> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> <1115478757.29495.122.camel@localhost.localdomain> <20050507172800.6eec367c.bugs.michael@gmx.net> <1115480032.29495.127.camel@localhost.localdomain> <1115527553.8237.35.camel@mccallum.corsepiu.local> <1115543440.29495.161.camel@localhost.localdomain> <1115546674.8237.50.camel@mccallum.corsepiu.local> <1115550819.29495.191.camel@localhost.localdomain> <20050508150935.1589e5f3.bugs.michael@gmx.net> <1115562777.5431.49.camel@notebook.thl.home> Message-ID: <20050508184825.60a10d1c.bugs.michael@gmx.net> On Sun, 08 May 2005 16:32:56 +0200, Thorsten Leemhuis wrote: > Just a side node for this discussion: What do we want do to in case of a > security update? Block the updated package also if it failed on one of > the archs? IMHO a bad decision if the resulting delay might be longer > than one or two days. Right. It's a scenario that would move us back to the beginning. It would be evidence that something doesn't work well. Currently, we pretend that the existing packages are supported for three architectures. When a problem comes up in a security related version upgrade, such a package may need the love and care of a team of maintainers instead of a single arch-specific maintainer. > > We do need the effort of an arch-specific community of developers and > > users, who help with making their special architecture as strong and > > supported as i386. > > Well, you propose this more then once here for some weeks now iirc. What > is needed to get this "official". Did you discuss it on the FESCO- > Meetings? I'm all for such a solution (as long as the burden lies on > more than one shoulder per arch). > > I ask cause I tried to fix some of the x86_64 problems and often did it > myself in the cvs -- some of the maintainers might wonder what the heck > this stupid person (e.g. me) was doing there. I would feel better if > this work was "official" in some way. Bah! If a maintainer thinks like that, he ought to talk to you and/or create the README.cvs file as outlined in the Wiki. You would put the package on your personal black-list and avoid it like the plague. Else you contribute your fixes where you like to, and, in particular, where open bug reports are not dealt with or where help is requested explicitly. > With such a group of persons (or even maillinglists extras-ppc and > extras-x86_64 [yes, I know, we have enough list already so forget the > last sentence]) the maintainers would know who to contact in case of > problems they can't solve on their own. In case you want to collect a list of contributors, who offer help for arch-specific problems, how about creating a Wiki page or an arch-specific tracker ticket in bugzilla, where maintainers can add bugs via the "depends on" field? On fedora-extras-list, guidelines could suggest that the architecture is mentioned in the subject-line, e.g. [ppc] [x86_64], to aid filtering. From bugs.michael at gmx.net Sun May 8 17:01:31 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 8 May 2005 19:01:31 +0200 Subject: Delay between cvs commit and build-request/build In-Reply-To: <1115567587.5431.79.camel@notebook.thl.home> References: <1115567587.5431.79.camel@notebook.thl.home> Message-ID: <20050508190131.3807be74.bugs.michael@gmx.net> On Sun, 08 May 2005 17:53:07 +0200, Thorsten Leemhuis wrote: > We had something like the following once before, I can't find it in the > archives (did not search very long), but it is somewhere. > > The purpose of the "Fedora Extras CVS commits commits at redhat.com>" Mailinglist was/is to make it possible for others > like sponsors, package reviewers or other interested parties to check > the fixes/changes that were committed to cvs before they get > build/published. With the build-system now working automatically most > packagers (including myself ;-) ) request build directly after > committing. So actually no real check before build/publish (the latter > actually depends on sign-time) is possible. > > Should there be a delay in this process somewhere? At least 24 hours for > example? No. No mandatory delays, please. This would be considered too limiting. If you need to work on your set of packages today, you don't want delays that force you to wait until tomorrow before trying to build them. Just apply common sense when committing major changes, which may result in a flood of comments or harsh criticism. I'm sure that whoever rushes with build requests, would be ashamed if it caused trouble that could have been avoided. > Requesting build after commit is imho understandable and okay (if the > publish can be canceled somehow) -- with this way you don't have to come > back later to request the build (otherwise it might be forgotten if you > touch a lot of different packages on one day). But maybe the packages > should not be signed/pushed in the 24 hours (or maybe 48 hours) after > the build-request/cvs-commit?! > > Opinions? A quick way to veto/block packages would be helpful, provided that we ever need it. For instance, if changes are discovered, which would break the repository [dependencies], blocking binary builds from being published might be necessary. Ordinary message to fedora-extras-list might not be seen by the release team. From sopwith at redhat.com Sun May 8 17:46:15 2005 From: sopwith at redhat.com (Elliot Lee) Date: Sun, 8 May 2005 13:46:15 -0400 (EDT) Subject: Delay between cvs commit and build-request/build In-Reply-To: <1115567587.5431.79.camel@notebook.thl.home> References: <1115567587.5431.79.camel@notebook.thl.home> Message-ID: The key assumption is "most packagers request build directly after committing". That can be changed if the pre-build review needs it, e.g. to enforce approval. Certainly more review is better. I believe that most of the package review should be done after builds but before the package makes it into the main repo. This is important because it allows the reviewer to look not only at the .spec file but at the resulting packages. Frequently there will be problems that aren't easy to find in the .spec file. Doing QA on the final result means that we'll be looking at things from the same perspective as the user: does the package install, upgrade, and run correctly? Best, -- Elliot On Sun, 8 May 2005, Thorsten Leemhuis wrote: > Hi * > > We had something like the following once before, I can't find it in the > archives (did not search very long), but it is somewhere. > > The purpose of the "Fedora Extras CVS commits commits at redhat.com>" Mailinglist was/is to make it possible for others > like sponsors, package reviewers or other interested parties to check > the fixes/changes that were committed to cvs before they get > build/published. With the build-system now working automatically most > packagers (including myself ;-) ) request build directly after > committing. So actually no real check before build/publish (the latter > actually depends on sign-time) is possible. > > Should there be a delay in this process somewhere? At least 24 hours for > example? > > Requesting build after commit is imho understandable and okay (if the > publish can be canceled somehow) -- with this way you don't have to come > back later to request the build (otherwise it might be forgotten if you > touch a lot of different packages on one day). But maybe the packages > should not be signed/pushed in the 24 hours (or maybe 48 hours) after > the build-request/cvs-commit?! > > Opinions? > > From fedora at leemhuis.info Sun May 8 17:51:33 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 08 May 2005 19:51:33 +0200 Subject: Delay between cvs commit and build-request/build In-Reply-To: <20050508190131.3807be74.bugs.michael@gmx.net> References: <1115567587.5431.79.camel@notebook.thl.home> <20050508190131.3807be74.bugs.michael@gmx.net> Message-ID: <1115574693.5431.109.camel@notebook.thl.home> Am Sonntag, den 08.05.2005, 19:01 +0200 schrieb Michael Schwendt: > On Sun, 08 May 2005 17:53:07 +0200, Thorsten Leemhuis wrote: [we meant the same but my description maybe was not the best] > A quick way to veto/block packages would be helpful, provided that we ever > need it. Yeah. > For instance, if changes are discovered, which would break the > repository [dependencies], blocking binary builds from being published > might be necessary. Ordinary message to fedora-extras-list might not be > seen by the release team. And how to we (technically) want to achieve this? -- Thorsten Leemhuis From jfontain at free.fr Sun May 8 17:48:00 2005 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Sun, 08 May 2005 19:48:00 +0200 Subject: problem importing src.rpm package Message-ID: <427E50D0.60000@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 common$ export CVSROOT=:ext:XXXXXX at cvs.fedora.redhat.com:/cvs/extras CVS_RSH=ssh common$ ./cvs-import.sh ~/released/moodss-20.0-1.src.rpm Checking out the modules file... Module 'moodss' already exists... Checking out module: 'moodss' Unpacking source package: moodss-20.0-1.src.rpm... L moodss-20.0.tar.bz2 U moodss.spec Checking : moodss-20.0.tar.bz2 on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... ERROR: could not check remote file status make: *** [upload] Error 255 ERROR: Uploading the source tarballs failed! I followed the http://fedoraproject.org/wiki/Extras_2fUsingCvsFaq documentation. I must be doing something wrong but what? Many thanks in advance for your help. - -- Jean-Luc Fontaine http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCflDQkG/MMvcT1qQRAoMHAKCz2TQzT7Aj+HsXexqFcQrgkCmHXACfVdiq 5jh+4mYX61ERevV7ejf20WM= =G3yc -----END PGP SIGNATURE----- From tian at c-sait.net Sun May 8 18:14:52 2005 From: tian at c-sait.net (Tian) Date: Sun, 8 May 2005 20:14:52 +0200 Subject: Information needed Message-ID: <20050508201452.119331e4@tianbox> Hello, About one week ago, I sent a mail concerning an RPM I created to have some feedbacks about its conformance: https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00017.html Maybe I did everything in a wrong order, but I then sent a self introduction and asked if I need to do something else for the sponsor process : https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00037.html I didn't get any answer or acknowledgment. So I just need to know now if something was not done as expected or if in fact something is in progress about that. I do not expect to have any kind of positive answer. For the moment I just want to know if I have to do something else or if I only have to wait. Thanks a lot. Tian. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Sun May 8 18:15:22 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 08 May 2005 21:15:22 +0300 Subject: problem importing src.rpm package In-Reply-To: <427E50D0.60000@free.fr> References: <427E50D0.60000@free.fr> Message-ID: <1115576122.9556.29.camel@bobcat.mine.nu> On Sun, 2005-05-08 at 19:48 +0200, Jean-Luc Fontaine wrote: > Checking : moodss-20.0.tar.bz2 on > https://cvs.fedora.redhat.com/repo/extras/upload.cgi... > ERROR: could not check remote file status > make: *** [upload] Error 255 > ERROR: Uploading the source tarballs failed! > > I followed the http://fedoraproject.org/wiki/Extras_2fUsingCvsFaq > documentation. Most likely you failed to grab and install the required client-side certificate. See https://admin.fedora.redhat.com/accounts/ I've added a note about this to the CVS FAQ. From jfontain at free.fr Sun May 8 18:28:19 2005 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Sun, 08 May 2005 20:28:19 +0200 Subject: problem importing src.rpm package In-Reply-To: <1115576122.9556.29.camel@bobcat.mine.nu> References: <427E50D0.60000@free.fr> <1115576122.9556.29.camel@bobcat.mine.nu> Message-ID: <427E5A43.1080407@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ville Skytt? wrote: > On Sun, 2005-05-08 at 19:48 +0200, Jean-Luc Fontaine wrote: > >> Checking : moodss-20.0.tar.bz2 on >> https://cvs.fedora.redhat.com/repo/extras/upload.cgi... ERROR: >> could not check remote file status make: *** [upload] Error 255 >> ERROR: Uploading the source tarballs failed! >> >> I followed the http://fedoraproject.org/wiki/Extras_2fUsingCvsFaq >> documentation. > > > Most likely you failed to grab and install the required client-side > certificate. See https://admin.fedora.redhat.com/accounts/ I've > added a note about this to the CVS FAQ. That was it indeed, sorry. Thanks, it worked. - -- Jean-Luc Fontaine http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCflpCkG/MMvcT1qQRAlWFAJ42oIWYuTire+Fzl1OiTmkGesUXdACgwv76 IDa3kQgPYLv69F0lmCRquJA= =1B3a -----END PGP SIGNATURE----- From dwmw2 at infradead.org Sun May 8 19:54:44 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 08 May 2005 20:54:44 +0100 Subject: Fedora Extras Development Build Report In-Reply-To: <20050508184818.176c632d.bugs.michael@gmx.net> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> <1115478757.29495.122.camel@localhost.localdomain> <20050507172800.6eec367c.bugs.michael@gmx.net> <1115480032.29495.127.camel@localhost.localdomain> <1115527553.8237.35.camel@mccallum.corsepiu.local> <1115543440.29495.161.camel@localhost.localdomain> <1115546674.8237.50.camel@mccallum.corsepiu.local> <1115550819.29495.191.camel@localhost.localdomain> <20050508150935.1589e5f3.bugs.michael@gmx.net> <1115561519.29495.244.camel@localhost.localdomain> <20050508184818.176c632d.bugs.michael@gmx.net> Message-ID: <1115582084.3755.33.camel@localhost.localdomain> On Sun, 2005-05-08 at 18:48 +0200, Michael Schwendt wrote: > Effectively, the volunteer packager is expected to expand his interest > and care for development and support of a platform, which he doesn't > use, and probably related specific mailing-lists and topics of > discussion. That is the job for which they volunteered; that is the job of the package maintainer. All the package maintainer really needs to do, if they lack the knowledge necessary to fix the problem, is isolate it and call for help. If they don't want that responsibility, that's fine. They can take their toys and go home. We won't miss them. As I already said -- if the packager is only interested in the parts of the package which _they_ use, and on _their_ platform(s), then they might as well just package it privately, not for Extras. However, this is a purely theoretical discussion. I don't think that there's any real evidence that our package maintainers really are that lax -- and if they do turn out to be, we can cross that bridge if/when we come to it. -- dwmw2 From dwmw2 at infradead.org Sun May 8 20:06:14 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 08 May 2005 21:06:14 +0100 Subject: Fedora Extras Development Build Report In-Reply-To: <1115568931.5431.98.camel@notebook.thl.home> References: <1115428974.15593.11.camel@cutter> <20050507051054.195e5e08.bugs.michael@gmx.net> <1115477793.29495.116.camel@localhost.localdomain> <20050507170353.47f61c37.bugs.michael@gmx.net> <1115478757.29495.122.camel@localhost.localdomain> <20050507172800.6eec367c.bugs.michael@gmx.net> <1115480032.29495.127.camel@localhost.localdomain> <1115527553.8237.35.camel@mccallum.corsepiu.local> <1115543440.29495.161.camel@localhost.localdomain> <1115546674.8237.50.camel@mccallum.corsepiu.local> <1115550819.29495.191.camel@localhost.localdomain> <20050508150935.1589e5f3.bugs.michael@gmx.net> <1115562777.5431.49.camel@notebook.thl.home> <1115566724.3755.26.camel@localhost.localdomain> <1115568931.5431.98.camel@notebook.thl.home> Message-ID: <1115582774.3755.40.camel@localhost.localdomain> On Sun, 2005-05-08 at 18:15 +0200, Thorsten Leemhuis wrote: > With three archs currently I tend to agree. But let make this four or > five: > > - request build > - build fails on x86_64 > - fix + request build > - build fails on ppc > - fix + request build > - build fails on IA64 > - fix + request build > - build fails on sparc > - fix + request build > - done > > against: > - request build > - build fails on x86_64, PPC, IA64,sparc > - fix + request build > - done > > A lot easier IMHO Trust me; even with the seven we build Core for, it never really works like that. You won't find that a _different_ arch-specific bug is introduced for each architecture, all at the same time. The closest you might find is "function X needs implementing for each arch", and TBH if you haven't managed to work that out for yourself by the time you hit the second failure, you're being very silly. :) -- dwmw2 From ivazquez at ivazquez.net Sun May 8 20:22:44 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 08 May 2005 16:22:44 -0400 Subject: Information needed In-Reply-To: <20050508201452.119331e4@tianbox> References: <20050508201452.119331e4@tianbox> Message-ID: <1115583764.17312.12.camel@ignacio.ignacio.lan> On Sun, 2005-05-08 at 20:14 +0200, Tian wrote: > About one week ago, I sent a mail concerning an RPM I created to have > some feedbacks about its conformance: > > https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00017.html > > Maybe I did everything in a wrong order, but I then sent a self introduction > and asked if I need to do something else for the sponsor process : > > https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00037.html > > I didn't get any answer or acknowledgment. So I just need to know now if > something was not done as expected or if in fact something is in progress > about that. > > I do not expect to have any kind of positive answer. For the moment I just > want to know if I have to do something else or if I only have to wait. Did you apply for an account in the Fedora Accounts System as mentioned in the Wiki? https://admin.fedora.redhat.com/accounts/ -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tian at c-sait.net Sun May 8 21:11:41 2005 From: tian at c-sait.net (Tian) Date: Sun, 8 May 2005 23:11:41 +0200 Subject: Information needed In-Reply-To: <1115583764.17312.12.camel@ignacio.ignacio.lan> References: <20050508201452.119331e4@tianbox> <1115583764.17312.12.camel@ignacio.ignacio.lan> Message-ID: <20050508231141.3450e67f@tianbox> > Did you apply for an account in the Fedora Accounts System as mentioned > in the Wiki? > > https://admin.fedora.redhat.com/accounts/ Yes I did that. My username is Tian. I also signed the CLA and edit my account to apply for cvsextras group. I think I did all the steps I could do on my own. Regards, Tian. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gauret at free.fr Sun May 8 21:13:33 2005 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 08 May 2005 23:13:33 +0200 Subject: GCC4 build failure in wv Message-ID: Hi all I know very little of C, and I've got a build failure with GCC4 I'd need help with : in the "wv" package : wvConfig.c:2134: error: static declaration of 'startElement' follows non-static declaration /usr/include/libxml2/libxml/SAX.h:110: error: previous declaration of 'startElement' was here wvConfig.c:3098: error: static declaration of 'endElement' follows non-static declaration /usr/include/libxml2/libxml/SAX.h:113: error: previous declaration of 'endElement' was here In the wvConfig.c file, at line 2134 and 3098, startElement and endElement are defined, in about 950 and 250 code lines respectively. What should I do in this case ? Thanks for your help Aur?lien -- http://gauret.free.fr ~~~~ Jabber : abompard at jabber.fr Unix IS user-friendly. It is just very picky about who his friends are. From bugs.michael at gmx.net Sun May 8 21:20:20 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 8 May 2005 23:20:20 +0200 Subject: ANNOUNCE: Fedora Extras FC4 target bugs Message-ID: <20050508232020.28cd5919.bugs.michael@gmx.net> For your tracking pleasure: https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=157183 This is a list of bugs in Fedora Extras which ought to be fixed before the release of FC4. Mostly contains all the packages in Fedora Extras FC3 which failed to build for FC4 so far. Accepting suggestions of other major/critical bugs in Fedora Extras Development. Please don't add bugs directly unless you are an active Fedora Extras contributor. From robert at marcanoonline.com Sun May 8 23:10:47 2005 From: robert at marcanoonline.com (Robert Marcano) Date: Sun, 08 May 2005 19:10:47 -0400 Subject: Self-Introduction: Robert Marcano Message-ID: <1115593847.20177.16.camel@localhost.localdomain> 1. Full legal name Robert Jes?s Marcano Varela 2. Country, City Venezuela, Caracas 3. Profession or Student status System Architect 4. Company or School Programaci?n Mecanizada C.A. 5. Your goals in the Fedora Project I want to help to package more Java based applications like "byline" http://byline.objectweb.org/ . To start I have a small package "kanatest" to begin with. 6. Historical qualifications * What other projects have you worked on in the past? I have not been committed to a single project, a few patches here and there * What computer languages and other skills do you know? Daily work with Java, C/C++, and Smalltalk, HTML/XML. Introductory knowledge of PHP and python. Spanish is my native language * Why should we trust you? <--- too blunt? Why not? http://www.google.com/search?q=Robert+Marcano if you find something wrong please tell me :-P 7. GPG KEYID and fingerprint pub 1024D/72A0DCFD 2005-05-08 Robert Marcano Key fingerprint = AE5B BE56 BA83 3BA3 1FCF 9D35 B0C6 F655 72A0 DCFD sub 4096g/7BAF6CC3 2005-05-08 ________________________________________ Robert Marcano web: http://www.marcanoonline.com/ blog: http://www.marcanoonline.com/plog/ From robert at marcanoonline.com Mon May 9 00:08:54 2005 From: robert at marcanoonline.com (Robert Marcano) Date: Sun, 08 May 2005 20:08:54 -0400 Subject: New package: kanatest Message-ID: <1115597334.20177.21.camel@localhost.localdomain> Kanatest is a simple, GTK 2-based kana drill tool. It offers three drill modes: hiragana, katakana, and mixed mode. The tester shows random kana characters and waits until you enter the romaji equivalent in an entry field. At the end, statistics are provided. SRPM: http://www.marcanoonline.com/downloads/fedora/package_submissions/kanatest/kanatest-0.3.6-1.src.rpm SPEC: http://www.marcanoonline.com/downloads/fedora/package_submissions/kanatest/kanatest.spec Any help to review the package? TIA ________________________________________ Robert Marcano web: http://www.marcanoonline.com/ blog: http://www.marcanoonline.com/plog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazquez at ivazquez.net Mon May 9 00:10:00 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 08 May 2005 20:10:00 -0400 Subject: GCC4 build failure in wv In-Reply-To: References: Message-ID: <1115597400.20014.5.camel@ignacio.ignacio.lan> On Sun, 2005-05-08 at 23:13 +0200, Aurelien Bompard wrote: > I know very little of C, and I've got a build failure with GCC4 I'd need > help with : > in the "wv" package : > wvConfig.c:2134: error: static declaration of 'startElement' follows > non-static declaration > /usr/include/libxml2/libxml/SAX.h:110: error: previous declaration of > 'startElement' was here > wvConfig.c:3098: error: static declaration of 'endElement' follows > non-static declaration > /usr/include/libxml2/libxml/SAX.h:113: error: previous declaration of > 'endElement' was here > > In the wvConfig.c file, at line 2134 and 3098, startElement and endElement > are defined, in about 950 and 250 code lines respectively. > What should I do in this case ? Looks like the upstream developer is abusing the compiler. I'm not certain whether the declarations should be changed to match the ones in the headers, or if the function names should be changed. Give me a few hours and I can look at it deeper. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazquez at ivazquez.net Mon May 9 00:13:28 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 08 May 2005 20:13:28 -0400 Subject: Information needed In-Reply-To: <20050508231141.3450e67f@tianbox> References: <20050508201452.119331e4@tianbox> <1115583764.17312.12.camel@ignacio.ignacio.lan> <20050508231141.3450e67f@tianbox> Message-ID: <1115597608.20014.7.camel@ignacio.ignacio.lan> On Sun, 2005-05-08 at 23:11 +0200, Tian wrote: > > Did you apply for an account in the Fedora Accounts System as mentioned > > in the Wiki? > > > > https://admin.fedora.redhat.com/accounts/ > > Yes I did that. My username is Tian. I also signed the CLA and edit my > account to apply for cvsextras group. > > I think I did all the steps I could do on my own. Don't forget to subscribe to the f-e-commits and f-maintainers-readonly mailing lists and watch the traffic in there. And yes, unfortunately wait. I'll take a look at your packages tomorrow though. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ed at eh3.com Mon May 9 02:04:00 2005 From: ed at eh3.com (Ed Hill) Date: Sun, 08 May 2005 22:04:00 -0400 Subject: Request for review: OpenEXR In-Reply-To: <1115544927.13384.5.camel@ignacio.ignacio.lan> References: <1114335625.7784.41.camel@ignacio.ignacio.lan> <1115377802.7124.1.camel@ignacio.ignacio.lan> <1115455194.7124.7.camel@ignacio.ignacio.lan> <1115489931.12675.0.camel@ignacio.ignacio.lan> <1115497327.9556.5.camel@bobcat.mine.nu> <1115497988.20211.1.camel@ignacio.ignacio.lan> <1115503349.24408.317.camel@ernie> <1115544927.13384.5.camel@ignacio.ignacio.lan> Message-ID: <1115604240.24408.471.camel@ernie> On Sun, 2005-05-08 at 05:35 -0400, Ignacio Vazquez-Abrams wrote: > On Sat, 2005-05-07 at 18:02 -0400, Ed Hill wrote: > > blockers: > > - should be: BuildRequires: fltk-devel >= 1.1 > > instead of: BuildRequires: fltk >= 1.1 > > - you're installing shared libs so I think you ought to have: > > %post -p /sbin/ldconfig > > %postun -p /sbin/ldconfig > > - the ownership of the "%files devel" is wrong, you need another: > > "%defattr(-,root,root,-)" for the devel package > > All fixed. Good! > > - please delete all the hidden ".deps" files such as: > > /usr/share/doc/OpenEXR-devel-1.2.2/IlmImfExamples/.deps > > I couldn't do this directly, and I couldn't find where in the makefile > it copied .deps, so I did a small hack to get around it. OK, works for me. I look at the spec and it seems to be in order now. Also, it built, installed, the binaries ran, etc. on an FC3 system. > > not sure about this one: > > - Can the "%{_libdir}/*.la" files be discarded? Or are they > > really needed? > > In this case they don't seem to add any dependency bloat, so it appears > safe to leave them in. I think that unused *.la files are generally deleted, but I could be wrong. And as you point out, its probably not a big deal. So I'll send an approved message. Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From tcallawa at redhat.com Mon May 9 03:25:13 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 08 May 2005 22:25:13 -0500 Subject: Review needed: gnet2 In-Reply-To: <1114335627.7784.42.camel@ignacio.ignacio.lan> References: <1114335627.7784.42.camel@ignacio.ignacio.lan> Message-ID: <1115609113.3017.39.camel@localhost.localdomain> On Sun, 2005-04-24 at 05:40 -0400, Ignacio Vazquez-Abrams wrote: > gnet2: A simple network library built upon glib > > GNet is a simple network library. It is written in C, object-oriented, > and built upon GLib. It is intended to be easy to use and port. Reviewed and approved the current version in CVS, no changes I can see that need making. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ivazquez at ivazquez.net Mon May 9 03:26:04 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 08 May 2005 23:26:04 -0400 Subject: GCC4 build failure in wv In-Reply-To: <1115597400.20014.5.camel@ignacio.ignacio.lan> References: <1115597400.20014.5.camel@ignacio.ignacio.lan> Message-ID: <1115609164.21984.3.camel@ignacio.ignacio.lan> On Sun, 2005-05-08 at 20:10 -0400, Ignacio Vazquez-Abrams wrote: > On Sun, 2005-05-08 at 23:13 +0200, Aurelien Bompard wrote: > > I know very little of C, and I've got a build failure with GCC4 I'd need > > help with : > > in the "wv" package : > > wvConfig.c:2134: error: static declaration of 'startElement' follows > > non-static declaration > > /usr/include/libxml2/libxml/SAX.h:110: error: previous declaration of > > 'startElement' was here > > wvConfig.c:3098: error: static declaration of 'endElement' follows > > non-static declaration > > /usr/include/libxml2/libxml/SAX.h:113: error: previous declaration of > > 'endElement' was here > > > > In the wvConfig.c file, at line 2134 and 3098, startElement and endElement > > are defined, in about 950 and 250 code lines respectively. > > What should I do in this case ? > > Looks like the upstream developer is abusing the compiler. I'm not > certain whether the declarations should be changed to match the ones in > the headers, or if the function names should be changed. Give me a few > hours and I can look at it deeper. Okay, give this one a try. Make sure that the app itself still works as expected after. -- 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: wv-1.0.0-gcc4.patch Type: text/x-patch Size: 1215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Mon May 9 05:46:42 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 09 May 2005 07:46:42 +0200 Subject: Build Result: SoQt on 3 In-Reply-To: <20050509044601.12DB7858D@extras64.linux.duke.edu> References: <20050509044601.12DB7858D@extras64.linux.duke.edu> Message-ID: <1115617602.8237.139.camel@mccallum.corsepiu.local> On Mon, 2005-05-09 at 00:46 -0400, buildsys at fedoraproject.org wrote: > Build of SoQt on 3 failed to complete on one or more archs. Please see logs at: > http://extras64.linux.duke.edu/failed/3/SoQt Seth, this build x86_64 error is bizarre. ... Rebuild source rpm SoQt-1.2.0-4.fc3.src.rpm ERROR: something went wrong rebuilding the .src.rpm ERROR: inspect rpm build log /var/tmp/mach/fedora-3-x86_64- core/SoQt-1.2.0-4.fc3/rpm.log ERROR: failed to rebuild SRPMs Incomprehensible to me, but ... the build continues: Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.278 ... ... until it finally fails: ... checking if we can compile and link with the Coin library... false configure: WARNING: Compilation and/or linking with the Coin main library SDK failed, for unknown reason. If you are familiar with configure-based configuration and building, investigate the 'config.log' file for clues. If you can not figure out what went wrong, please forward the 'config.log' ... As it seem to me, SoQt is missing Coin2-devel. ATM, Coin2/x86_64 has not been released, but seems to have been successfully build in your build system (http://extras64.linux.duke.edu/needsign/3/Coin2/2.3.0-8.fc3/x86_64) Am I right in concluding from this observation that the build system only considers already _released_ packages and does not to consider packages inside of the build system? IMO, this behavior is not helpful, because it prevents "batch updates" of sets of packages which depend on each other (Here: Coin2->SoQt). Ralf From skvidal at phy.duke.edu Mon May 9 06:15:42 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 09 May 2005 02:15:42 -0400 Subject: Build Result: SoQt on 3 In-Reply-To: <1115617602.8237.139.camel@mccallum.corsepiu.local> References: <20050509044601.12DB7858D@extras64.linux.duke.edu> <1115617602.8237.139.camel@mccallum.corsepiu.local> Message-ID: <1115619342.21549.63.camel@cutter> > As it seem to me, SoQt is missing Coin2-devel. > > ATM, Coin2/x86_64 has not been released, but seems to have been > successfully build in your build system > (http://extras64.linux.duke.edu/needsign/3/Coin2/2.3.0-8.fc3/x86_64) > > > Am I right in concluding from this observation that the build system > only considers already _released_ packages and does not to consider > packages inside of the build system? No, you're wrong. the buildsystem: 1. has access to the rpms in needsign 2. runs createrepo before each new build to verify that the metadata there is up to date. -sv From rc040203 at freenet.de Mon May 9 06:22:40 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 09 May 2005 08:22:40 +0200 Subject: Build Result: SoQt on 3 In-Reply-To: <1115619342.21549.63.camel@cutter> References: <20050509044601.12DB7858D@extras64.linux.duke.edu> <1115617602.8237.139.camel@mccallum.corsepiu.local> <1115619342.21549.63.camel@cutter> Message-ID: <1115619760.8237.142.camel@mccallum.corsepiu.local> On Mon, 2005-05-09 at 02:15 -0400, seth vidal wrote: > > As it seem to me, SoQt is missing Coin2-devel. > > > > ATM, Coin2/x86_64 has not been released, but seems to have been > > successfully build in your build system > > (http://extras64.linux.duke.edu/needsign/3/Coin2/2.3.0-8.fc3/x86_64) > > > > > > Am I right in concluding from this observation that the build system > > only considers already _released_ packages and does not to consider > > packages inside of the build system? > > No, you're wrong. > > > the buildsystem: > 1. has access to the rpms in needsign > 2. runs createrepo before each new build to verify that the metadata > there is up to date. So tell me what's going wrong there. I see 2 separate errors: 1. the rebuilding src.rpm error. 2. the building breakdown. Ralf From skvidal at phy.duke.edu Mon May 9 06:25:58 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 09 May 2005 02:25:58 -0400 Subject: Build Result: SoQt on 3 In-Reply-To: <1115619760.8237.142.camel@mccallum.corsepiu.local> References: <20050509044601.12DB7858D@extras64.linux.duke.edu> <1115617602.8237.139.camel@mccallum.corsepiu.local> <1115619342.21549.63.camel@cutter> <1115619760.8237.142.camel@mccallum.corsepiu.local> Message-ID: <1115619959.21549.66.camel@cutter> > So tell me what's going wrong there. > > I see 2 separate errors: > 1. the rebuilding src.rpm error. > 2. the building breakdown. Ralf, It's not my responsibility to tell you how to fix your package. Try to duplicate the error using the mach packages that are out there and see if you can sort it out. -sv From rc040203 at freenet.de Mon May 9 06:37:01 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 09 May 2005 08:37:01 +0200 Subject: Build Result: SoQt on 3 In-Reply-To: <1115619959.21549.66.camel@cutter> References: <20050509044601.12DB7858D@extras64.linux.duke.edu> <1115617602.8237.139.camel@mccallum.corsepiu.local> <1115619342.21549.63.camel@cutter> <1115619760.8237.142.camel@mccallum.corsepiu.local> <1115619959.21549.66.camel@cutter> Message-ID: <1115620621.8237.149.camel@mccallum.corsepiu.local> On Mon, 2005-05-09 at 02:25 -0400, seth vidal wrote: > > So tell me what's going wrong there. > > > > I see 2 separate errors: > > 1. the rebuilding src.rpm error. > > 2. the building breakdown. > > Ralf, > It's not my responsibility to tell you how to fix your package. Try to > duplicate the error using the mach packages that are out there and see > if you can sort it out. 1. These packages have been built with mach/apt (i386), have been part of Fedora.us and are reported to build on x86_64 and i386. 2. I don't have any possibility to build on x86_64. 3. The error messages your mach is giving are providing sufficient information to enable me to investigate these errors, neither /var/tmp/mach/fedora-3-x86_64-core/SoQt-1.2.0-4.fc3/rpm.log nor $RPM_BUILD_DIR/config.log are accessible to the public. Ralf From rc040203 at freenet.de Mon May 9 06:38:50 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 09 May 2005 08:38:50 +0200 Subject: Build Result: SoQt on 3 In-Reply-To: <1115620621.8237.149.camel@mccallum.corsepiu.local> References: <20050509044601.12DB7858D@extras64.linux.duke.edu> <1115617602.8237.139.camel@mccallum.corsepiu.local> <1115619342.21549.63.camel@cutter> <1115619760.8237.142.camel@mccallum.corsepiu.local> <1115619959.21549.66.camel@cutter> <1115620621.8237.149.camel@mccallum.corsepiu.local> Message-ID: <1115620730.8237.151.camel@mccallum.corsepiu.local> On Mon, 2005-05-09 at 08:37 +0200, Ralf Corsepius wrote: > On Mon, 2005-05-09 at 02:25 -0400, seth vidal wrote: > > > So tell me what's going wrong there. > > > > > > I see 2 separate errors: > > > 1. the rebuilding src.rpm error. > > > 2. the building breakdown. > > > > Ralf, > > It's not my responsibility to tell you how to fix your package. Try to > > duplicate the error using the mach packages that are out there and see > > if you can sort it out. > > 1. These packages have been built with mach/apt (i386), have been part > of Fedora.us and are reported to build on x86_64 and i386. > > 2. I don't have any possibility to build on x86_64. > > 3. The error messages your mach is giving are providing sufficient s/sufficient/insufficient/ > information to enable me to investigate these errors, neither > /var/tmp/mach/fedora-3-x86_64-core/SoQt-1.2.0-4.fc3/rpm.log > nor $RPM_BUILD_DIR/config.log are accessible to the public. Ralf From j.w.r.degoede at hhs.nl Mon May 9 07:30:39 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 09 May 2005 09:30:39 +0200 Subject: Fedora Account System alert mails In-Reply-To: <20050507174600.573976e2.bugs.michael@gmx.net> References: <427C778D.3010304@hhs.nl> <20050507141331.1ae4b2a3.bugs.michael@gmx.net> <427CD54D.9030108@hhs.nl> <1115480384.24408.203.camel@ernie> <20050507174600.573976e2.bugs.michael@gmx.net> Message-ID: <427F119F.8030107@hhs.nl> Michael Schwendt wrote: > On Sat, 07 May 2005 11:39:43 -0400, Ed Hill wrote: > > >>>My bad, I thought I could sponsor people because since I've got >>>CVS-access I've been getting these mails that there were people looking >>>for sponsors, since these mails did not come through the fedora-extras >>>list I assumed they were targeted at people who could sponsor. >> >>Yeah, I was meaning to ask that question as well. I assumed that the >>email was sent to me in error but you just don't know... ;-) > > > It is sent in error unless you see yourself in the accounts system as > being flagged as a "sponsor". > How do I know if I'm flagged as a sponser? Regards, Hans From tian at c-sait.net Mon May 9 07:46:42 2005 From: tian at c-sait.net (tian at c-sait.net) Date: Mon, 9 May 2005 09:46:42 +0200 (CEST) Subject: Information needed In-Reply-To: <1115597608.20014.7.camel@ignacio.ignacio.lan> References: <20050508201452.119331e4@tianbox> <1115583764.17312.12.camel@ignacio.ignacio.lan> <20050508231141.3450e67f@tianbox> <1115597608.20014.7.camel@ignacio.ignacio.lan> Message-ID: <27923.62.210.124.226.1115624802.squirrel@62.210.124.226> > Don't forget to subscribe to the f-e-commits and f-maintainers-readonly > mailing lists and watch the traffic in there. OK I will do so. I will also browse their archives to better know them. > And yes, unfortunately wait. Not a problem. I just wanted to know if I have anything else to do. I can wait now. > I'll take a look at your packages tomorrow > though. Thanks a lot. But nothing is urgent there. Tian. From buildsys at fedoraproject.org Mon May 9 08:48:46 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 9 May 2005 04:48:46 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050509084846.5D326858D@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 45 Coin2-2.3.0-8.fc3 R-2.1.0-2 R-gnomeGUI-2.1.0-1.fc3 TeXmacs-1.0.5-1 alsa-tools-1.0.6-3 apachetop-0.12.5-1 bazaar-1.3.2-2 cdo-0.9.6-2 enigma-0.91-4 feh-1.3.1-1.fc3 galeon-1.3.20-2.fc3 gnome-applet-netspeed-0.11-1.fc3 gnome-theme-clearlooks-0.5-4 gnotime-2.2.1-5.fc3.8.1 gtk-xfce-engine-2.2.6-3.fc3 help2man-1.35.1-1.fc3 ipython-0.6.13-1 leafpad-0.8.0-1.fc3 libcdio-0.73-1 libol-0.3.16-1 librx-1.5-4.fc3 linphone-1.0.1-2.fc3 lirc-0.7.1-1 netcdf-3.6.0-2.p1.fc3 nmh-1.1-7.fc3 notemeister-0.1.7-6 perl-Authen-SASL-2.09-1 perl-Config-IniFiles-2.39-1 perl-Config-Tiny-2.01-1 perl-Devel-Cycle-1.04-1 perl-Module-CoreList-2.01-1 perl-Pod-Coverage-0.17-1.1 perl-Test-Memory-Cycle-1.00-2 plt-scheme-299.100-1 python-cherrytemplate-1.0.0-1 python-crypto-2.0-3 quilt-0.40-2.fc3 sylpheed-claws-1.0.4-1 udunits-1.12.4-7.fc3 xfcalendar-4.2.1-5.fc3 xfce4-appfinder-4.2.1-3.fc3 xfce4-icon-theme-4.2.1-5.fc3 xfce4-mixer-4.2.1-5.fc3 xfce4-toys-4.2.1-4.fc3 xfce4-trigger-launcher-4.2.1-4.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bdpepple at ameritech.net Mon May 9 08:49:15 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Mon, 09 May 2005 04:49:15 -0400 Subject: Fedora Account System alert mails In-Reply-To: <427F119F.8030107@hhs.nl> References: <427C778D.3010304@hhs.nl> <20050507141331.1ae4b2a3.bugs.michael@gmx.net> <427CD54D.9030108@hhs.nl> <1115480384.24408.203.camel@ernie> <20050507174600.573976e2.bugs.michael@gmx.net> <427F119F.8030107@hhs.nl> Message-ID: <1115628555.11664.8.camel@localhost.localdomain> On Mon, 2005-05-09 at 09:30 +0200, Hans de Goede wrote: > Michael Schwendt wrote: > > > > It is sent in error unless you see yourself in the accounts system as > > being flagged as a "sponsor". > > > > How do I know if I'm flagged as a sponser? > What is your role type when you edit your CVS account (https://admin.fedora.redhat.com/accounts/)? It's located in the lower right hand corner in the Existing memberships box. I'm guessing, since your asking, that it is user not sponsor. /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 buildsys at fedoraproject.org Mon May 9 08:58:28 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 9 May 2005 04:58:28 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050509085828.DAACF858D@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 82 R-2.1.0-51 abicheck-1.2-5 alsa-tools-1.0.8-3 blacs-1.1-6.fc4 c-ares-1.2.1-2 ccache-2.4-3 cyrus-imapd-2.2.12-6.fc4 d4x-2.5.0-5 enigma-0.81-5 exim-4.50-2 exim-4.51-1 exim-doc-4.50-1 feh-1.3.1-1.fc4 fluxbox-0.9.9-4 freeciv-2.0.1-1.fc4 gai-pal-0.7-5 gconfmm26-2.10.0-2 gkrellmms-2.1.22-3 glibmm24-2.6.1-1 glunarclock-0.32.2-4 gnome-applet-netspeed-0.12.1-2.fc4 gnome-vfsmm26-2.10.0-1 gnotime-2.2.1-8 gtkmm24-2.6.2-2 gwget-0.93-2 help2man-1.35.1-1.fc4 hfsplusutils-1.0.4-5 ipython-0.6.13-2 irssi-0.8.9-7 js-1.5-0.rc6a.6 leafpad-0.8.0-1.fc4 libassuan-0.6.9-4 libcdio-0.73-2 libglademm24-2.6.0-1 libgnomecanvasmm26-2.10.0-1 libgnomemm26-2.10.0-1 libgnomeuimm26-2.10.0-1 libol-0.3.16-1.fc4 libosip-0.9.7-7 librx-1.5-4.fc4 libsigc++20-2.0.11-1 liferea-0.9.1-2 linphone-1.0.1-2.fc4 lirc-0.7.1-2 lock-keys-applet-1.0-9 manedit-0.5.11-5 mknbi-1.4.4-2 moodss-20.0-2 ncftp-3.1.9-1 nmh-1.1-7.fc4 notecase-0.8.2-7 notemeister-0.1.7-5 notemeister-0.1.7-7 p7zip-4.16-1 pam_mount-0.9.23-1 perl-Config-Record-1.1.0-2 perl-Config-Tiny-2.01-2 perl-Module-Build-0.2610-3 perl-Spreadsheet-WriteExcel-2.13-2 perl-String-ShellQuote-1.03-2 putty-0.58-1 python-cherrypy-2.0.0-0.2.b python-cherrypy-2.0.0-1 python-cherrytemplate-1.0.0-1 python-crypto-2.0-4 python-durus-1.5-2 quilt-0.40-1 quilt-0.40-2.fc4 revelation-0.4.3-3 stellarium-0.6.2-4 sylpheed-claws-1.0.4-2 udftools-1.0.0b3-3 ulogd-1.23-1.fc4 wxGTK-2.4.2-10 wxGTK-2.4.2-12 x3270-3.3.4-3 xemacs-21.4.17-3 xemacs-sumo-20050505-1 xfwm4-themes-4.2.1-3.fc4 xmms-1.2.10-16 xmms-arts-0.7.1-1 xmms-skins-1.2.10-15 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From pmatilai at welho.com Mon May 9 09:03:18 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Mon, 9 May 2005 12:03:18 +0300 (EEST) Subject: Fedora Extras development Package Build Report In-Reply-To: <20050509085828.DAACF858D@extras64.linux.duke.edu> References: <20050509085828.DAACF858D@extras64.linux.duke.edu> Message-ID: On Mon, 9 May 2005 buildsys at fedoraproject.org wrote: > > Packages built and released for Fedora Extras development: 82 > > R-2.1.0-51 > abicheck-1.2-5 ... Nice. Even better if we could have the changelog deltas for these like the rawhide build reports have - maybe the same script could be reused? - Panu - From skvidal at phy.duke.edu Mon May 9 09:05:37 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 09 May 2005 05:05:37 -0400 Subject: Fedora Extras development Package Build Report In-Reply-To: References: <20050509085828.DAACF858D@extras64.linux.duke.edu> Message-ID: <1115629537.21549.73.camel@cutter> On Mon, 2005-05-09 at 12:03 +0300, Panu Matilainen wrote: > On Mon, 9 May 2005 buildsys at fedoraproject.org wrote: > > > > Packages built and released for Fedora Extras development: 82 > > > > R-2.1.0-51 > > abicheck-1.2-5 > ... > > Nice. Even better if we could have the changelog deltas for these like the > rawhide build reports have - maybe the same script could be reused? > We need to record the former state of the extras repo. Something that's just not available right now. If you want to see the changelog stuff take a look at the repoview for the repositories. -sv From rc040203 at freenet.de Mon May 9 09:50:04 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 09 May 2005 11:50:04 +0200 Subject: Build Result: SoQt on 3 In-Reply-To: <1115620730.8237.151.camel@mccallum.corsepiu.local> References: <20050509044601.12DB7858D@extras64.linux.duke.edu> <1115617602.8237.139.camel@mccallum.corsepiu.local> <1115619342.21549.63.camel@cutter> <1115619760.8237.142.camel@mccallum.corsepiu.local> <1115619959.21549.66.camel@cutter> <1115620621.8237.149.camel@mccallum.corsepiu.local> <1115620730.8237.151.camel@mccallum.corsepiu.local> Message-ID: <1115632204.8237.176.camel@mccallum.corsepiu.local> On Mon, 2005-05-09 at 08:38 +0200, Ralf Corsepius wrote: > On Mon, 2005-05-09 at 08:37 +0200, Ralf Corsepius wrote: > > On Mon, 2005-05-09 at 02:25 -0400, seth vidal wrote: > > > > So tell me what's going wrong there. > > > > > > > > I see 2 separate errors: > > > > 1. the rebuilding src.rpm error. > > > > 2. the building breakdown. > > > > > > Ralf, > > > It's not my responsibility to tell you how to fix your package. Try to > > > duplicate the error using the mach packages that are out there and see > > > if you can sort it out. Just resubmitting the package without me having changed anything on the package, somehow "magically" fixed this issue. Traces of both build attempts can be found on your server: http://extras64.linux.duke.edu/failed/3/SoQt/1.2.0-4.fc3/ http://extras64.linux.duke.edu/needsign/3/SoQt/1.2.0-4.fc3/ #:() Ralf From mfleming at enlartenment.com Mon May 9 10:30:14 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Mon, 9 May 2005 20:30:14 +1000 Subject: Approval needed: mlmmj In-Reply-To: <1115475973.4296.1.camel@Madison.badger.com> References: <20050507120206.4f791a8f.mfleming@enlartenment.com> <20050507231416.45417926.mfleming@enlartenment.com> <1115475973.4296.1.camel@Madison.badger.com> Message-ID: <20050509203014.1725d882.mfleming@enlartenment.com> On Sat, 07 May 2005 10:26:12 -0400. Toshio waffled thusly: > On Sat, 2005-05-07 at 23:14 +1000, Michael Fleming wrote: > > On Sat, 7 May 2005 08:21:24 -0400 (EDT). Chris Ricker waffled thusly: > > > > > On Sat, 7 May 2005, Michael Fleming wrote: > > > > - The source package also contains two web frontends (one in Perl > > > > and another in PHP) for maintaining the lists and allowing visitors > > > > to sign up. Should they be split off into a subpackage, included in > > > > %doc (which I've seen done for some other packages) or omitted > > > > completely (the current status). Otherwise creation of new lists is > > > > via a small shell script included in the current package - fine for > > > > shell access but not overly convenient. > > > > > > subpackages would be nicest, I'd think > > > > This is possible, probably simpler - but the Requires: would be a case > > of "left as an exercise for the reader" unless you want it to get a > > little hairy (not /everyone/ has *both* PHP and perl on the system..) > > > Why not separate subpackages for each front-end? Seems most admins > would install one that uses php _or_ one that uses perl, not both. How does: mlmmj-contrib-perl mlmmj-contrib-php ....sound? I /could/ put the files under /usr/share/mlmmj/contrib/ (rather than a mess of webserver-dependent roots)- this way admins can copy the respective trees to wherever their webserver requires them and give permissions/ ownership accordingly. By the way, I've updated my RPM to the latest upstream 1.2.6.1, which folds in the moderation race with the previous version, cuts the clutter and fixes many other issues. Reviews (and package approval!) welcomed. > -Toshio Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From ivazquez at ivazquez.net Mon May 9 11:44:29 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 09 May 2005 07:44:29 -0400 Subject: Self-Introduction: Christian Jodar (Tian) In-Reply-To: <20050503220937.4df887c2@tianbox> References: <20050503220937.4df887c2@tianbox> Message-ID: <1115639069.21984.18.camel@ignacio.ignacio.lan> On Tue, 2005-05-03 at 22:09 +0200, Tian wrote: > http://download.gna.org/gcfilms/fedora/3/gcfilms-5.0-1.src.rpm > Summary: GCfilms, movies collection management Summary should not contain %name in any form. > Source0: gcfilms-%{version}-bin.tar.gz RPMs should be built from pristine source. As such, unless there's a super-extra-special reason, this should be http://download.gna.org/gcfilms/gcfilms-5.0.tar.gz. > %if %{!?_without_freedesktop:1}0 Fedora packages should always be built to FreeDesktop specs, so you can assume that this conditional will always be 1 and therefore you can drop it. > %post > %postun Good, you got the scriptlets right. Now you just have to add desktop- file-utils and shared-mime-info to Requires(post) and Requires(postun). > %dir %{_datadir}/gcfilms/doc > %doc %{_datadir}/gcfilms/doc/README > %doc %{_datadir}/gcfilms/doc/CHANGELOG This sort of stuff should be in %{_defaultdocdir}/%{name}-%{version}. > %dir %{_libdir}/gcfilms/ Since you appear to include every file under here without any %doc, % config, or %ghost directives, you can just include %{_libdir}/gcfilms instead and pick them all up in one fell swoop. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon May 9 11:45:06 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 9 May 2005 13:45:06 +0200 Subject: buildsystem stuff In-Reply-To: <1115276838.22456.48.camel@cutter> References: <1115181658.15831.45.camel@cutter> <20050504130715.51f466c7@python2> <1115276838.22456.48.camel@cutter> Message-ID: <20050509134506.0bc83340@python2> seth vidal wrote : [...] > If you've not seen repomanage go to: > http://linux.duke.edu/yum/download/misc/ > > I'm certain that will also be available in the yum-utils package that > Gijs has been working on. Lots of completely cool stuff in yum-utils > now. Thanks for all those answers, and also for pointing me at repomanage, as it seems to be _the_ tool I've been searching for for soooo long! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.20_FC3 Load : 0.75 0.68 0.81 From ivazquez at ivazquez.net Mon May 9 12:05:29 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 09 May 2005 08:05:29 -0400 Subject: New package: kanatest In-Reply-To: <1115597334.20177.21.camel@localhost.localdomain> References: <1115597334.20177.21.camel@localhost.localdomain> Message-ID: <1115640329.21984.22.camel@ignacio.ignacio.lan> On Sun, 2005-05-08 at 20:08 -0400, Robert Marcano wrote: > http://www.marcanoonline.com/downloads/fedora/package_submissions/kanatest/kanatest.spec - Summary contains %name - Explicit Requires in a binary package ? Why not use d-f-i with %SOURCE1 directly? - Use %find_lang instead of handling locale stuff manually -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From paul at city-fan.org Mon May 9 12:07:31 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 09 May 2005 13:07:31 +0100 Subject: Review Request: gtorrentviewer Message-ID: <427F5283.9060300@city-fan.org> An earlier version of my package was kindly reviewed by Aaron Kurtz in the "Self-Introduction: Paul Howarth" thread (https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00264.html). Having made a number of changes, I thought it was probably better to start a new thread with a more sensible subject header regarding the updated version. Summary: A GTK2-based viewer and editor for BitTorrent meta files Description: The purpose of GTorrentViewer is to give the ability to see and modify all the possible information from .torrent files without having to start downloading and the ability to see in real time the current number of seeds and peers on the torrent, so you will always know the status before starting the download. Spec file: http://www.city-fan.org/~paul/extras/gtorrentviewer/gtorrentviewer.spec SRPM: http://www.city-fan.org/~paul/extras/gtorrentviewer/gtorrentviewer-0.2b-2.fc3.src.rpm Cheers, Paul. From ivazquez at ivazquez.net Mon May 9 12:18:59 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 09 May 2005 08:18:59 -0400 Subject: Review Request: gtorrentviewer In-Reply-To: <427F5283.9060300@city-fan.org> References: <427F5283.9060300@city-fan.org> Message-ID: <1115641139.21984.23.camel@ignacio.ignacio.lan> On Mon, 2005-05-09 at 13:07 +0100, Paul Howarth wrote: > http://www.city-fan.org/~paul/extras/gtorrentviewer/gtorrentviewer.spec > %{__sed} -i -e 's at Exec=gtorrentviewer at Exec=%{_bindir}/gtorrentviewer@' \ > -e 's at Icon=gtorrentviewer.png at Icon=%{_datadir}/pixmaps/gtorrentviewer.png@' \ > data/gtorrentviewer.desktop.in Completely unnecessary. -- 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 tian at c-sait.net Mon May 9 13:46:10 2005 From: tian at c-sait.net (tian at c-sait.net) Date: Mon, 9 May 2005 15:46:10 +0200 (CEST) Subject: Self-Introduction: Christian Jodar (Tian) In-Reply-To: <1115639069.21984.18.camel@ignacio.ignacio.lan> References: <20050503220937.4df887c2@tianbox> <1115639069.21984.18.camel@ignacio.ignacio.lan> Message-ID: <41039.62.210.124.226.1115646370.squirrel@62.210.124.226> I will do required changes. But I won't be able to do so before tonight (GMT +2). In the meantime, I have some remarks/questions. > RPMs should be built from pristine source. As such, unless there's a > super-extra-special reason, this should be > http://download.gna.org/gcfilms/gcfilms-5.0.tar.gz. OK. In fact, I generated a special .tar.gz for the RPM creation. But I will change that to use the offical one (that is also downloadable). Previous .tar.gz was created with correct tree structure, containing /usr directory and sub directories with files. If I use the other ones, I will have to this stuff in the %build section. Am I right? This application is a pure Perl one, so it doesn't require any compilation. >> %dir %{_datadir}/gcfilms/doc >> %doc %{_datadir}/gcfilms/doc/README >> %doc %{_datadir}/gcfilms/doc/CHANGELOG > > This sort of stuff should be in %{_defaultdocdir}/%{name}-%{version}. I thought that specifying %doc leads to copy the files in the correct directory. If I use the Source0 mentionned before, these files are for the moment in the .tar.gz root directory. With new version, would that be correct to have: %dir %{_defaultdocdir}/%{name}-%{version} %doc README %doc CHANGELOG ? Maybe the %dir line is useless. Or should I before in the %build step copy them to %{_defaultdocdir}/%{name}-%{version} and use this path in the %files section? Many thanks, Tian. From ivazquez at ivazquez.net Mon May 9 13:53:30 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 09 May 2005 09:53:30 -0400 Subject: Self-Introduction: Christian Jodar (Tian) In-Reply-To: <41039.62.210.124.226.1115646370.squirrel@62.210.124.226> References: <20050503220937.4df887c2@tianbox> <1115639069.21984.18.camel@ignacio.ignacio.lan> <41039.62.210.124.226.1115646370.squirrel@62.210.124.226> Message-ID: <1115646810.21984.30.camel@ignacio.ignacio.lan> On Mon, 2005-05-09 at 15:46 +0200, tian at c-sait.net wrote: > Previous .tar.gz was created with correct tree structure, containing > /usr directory and sub directories with files. If I use the other ones, > I will have to this stuff in the %build section. Am I right? This > application is a pure Perl one, so it doesn't require any compilation. No, it should go in %install. > >> %dir %{_datadir}/gcfilms/doc > >> %doc %{_datadir}/gcfilms/doc/README > >> %doc %{_datadir}/gcfilms/doc/CHANGELOG > > > > This sort of stuff should be in %{_defaultdocdir}/%{name}-%{version}. > > I thought that specifying %doc leads to copy the files in the correct > directory. Only if you don't specify a directory, in which case it will grab the files from $RPM_BUILD_DIR. > %dir %{_defaultdocdir}/%{name}-%{version} > %doc README > %doc CHANGELOG > > ? Maybe the %dir line is useless. Correct. rpmbuild will mark it %doc automagically. > Or should I before in the %build step copy them to > %{_defaultdocdir}/%{name}-%{version} and use this path in the %files > section? %build is only used to build files required for installation. Putting stuff in the right (final) place should happen in %install. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From paul at city-fan.org Mon May 9 13:57:04 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 09 May 2005 14:57:04 +0100 Subject: Self-Introduction: Christian Jodar (Tian) In-Reply-To: <41039.62.210.124.226.1115646370.squirrel@62.210.124.226> References: <20050503220937.4df887c2@tianbox> <1115639069.21984.18.camel@ignacio.ignacio.lan> <41039.62.210.124.226.1115646370.squirrel@62.210.124.226> Message-ID: <427F6C30.3020000@city-fan.org> tian at c-sait.net wrote: > I will do required changes. But I won't be able to do so before tonight > (GMT +2). In the meantime, I have some remarks/questions. > > >>RPMs should be built from pristine source. As such, unless there's a >>super-extra-special reason, this should be >>http://download.gna.org/gcfilms/gcfilms-5.0.tar.gz. > > > OK. In fact, I generated a special .tar.gz for the RPM creation. But I > will change that to use the offical one (that is also downloadable). > > Previous .tar.gz was created with correct tree structure, containing > /usr directory and sub directories with files. If I use the other ones, > I will have to this stuff in the %build section. Am I right? This > application is a pure Perl one, so it doesn't require any compilation. Perhaps you could take a look at the spec file template for perl modules in the fedora-rpmdevtools package and base the build phase of the package on that? >>>%dir %{_datadir}/gcfilms/doc >>>%doc %{_datadir}/gcfilms/doc/README >>>%doc %{_datadir}/gcfilms/doc/CHANGELOG >> >>This sort of stuff should be in %{_defaultdocdir}/%{name}-%{version}. > > > I thought that specifying %doc leads to copy the files in the correct > directory. If I use the Source0 mentionned before, these files are for the > moment in the .tar.gz root directory. > > With new version, would that be correct to have: > > %dir %{_defaultdocdir}/%{name}-%{version} > %doc README > %doc CHANGELOG > > ? Maybe the %dir line is useless. Correct; you can reduce this to: %doc README CHANGELOG > > Or should I before in the %build step copy them to > %{_defaultdocdir}/%{name}-%{version} and use this path in the %files > section? No need to do that. Paul. From tian at c-sait.net Mon May 9 14:10:41 2005 From: tian at c-sait.net (tian at c-sait.net) Date: Mon, 9 May 2005 16:10:41 +0200 (CEST) Subject: Self-Introduction: Christian Jodar (Tian) In-Reply-To: <1115646810.21984.30.camel@ignacio.ignacio.lan> References: <20050503220937.4df887c2@tianbox> <1115639069.21984.18.camel@ignacio.ignacio.lan> <41039.62.210.124.226.1115646370.squirrel@62.210.124.226> <1115646810.21984.30.camel@ignacio.ignacio.lan> Message-ID: <25482.62.210.124.226.1115647841.squirrel@62.210.124.226> > No, it should go in %install. OK. So I think my %build section will remain empty. Maybe the doc macro should be added to this page: http://www.fedoraproject.org/wiki/Extras_2fRPMMacros But I am not sure this list is the correct place to point out that. Tian. From tian at c-sait.net Mon May 9 14:16:12 2005 From: tian at c-sait.net (tian at c-sait.net) Date: Mon, 9 May 2005 16:16:12 +0200 (CEST) Subject: Self-Introduction: Christian Jodar (Tian) In-Reply-To: <427F6C30.3020000@city-fan.org> References: <20050503220937.4df887c2@tianbox> <1115639069.21984.18.camel@ignacio.ignacio.lan> <41039.62.210.124.226.1115646370.squirrel@62.210.124.226> <427F6C30.3020000@city-fan.org> Message-ID: <32838.62.210.124.226.1115648172.squirrel@62.210.124.226> > Perhaps you could take a look at the spec file template for perl modules > in the fedora-rpmdevtools package and base the build phase of the > package on that? I already looked it. But actually, it doesn't fit with my package. GCfilms is a Perl application, not a Perl module. So it doesn't have to be installed in the same way. No compilation is required. Only files have to be copied as for an application. I didn't find in CVS extras example of another pure Perl application to have a model. If someone knows one, it could be useful. Best regards, Tian. From paul at city-fan.org Mon May 9 15:08:06 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 09 May 2005 16:08:06 +0100 Subject: Self-Introduction: Christian Jodar (Tian) In-Reply-To: <32838.62.210.124.226.1115648172.squirrel@62.210.124.226> References: <20050503220937.4df887c2@tianbox> <1115639069.21984.18.camel@ignacio.ignacio.lan> <41039.62.210.124.226.1115646370.squirrel@62.210.124.226> <427F6C30.3020000@city-fan.org> <32838.62.210.124.226.1115648172.squirrel@62.210.124.226> Message-ID: <427F7CD6.3010006@city-fan.org> tian at c-sait.net wrote: >>Perhaps you could take a look at the spec file template for perl modules >>in the fedora-rpmdevtools package and base the build phase of the >>package on that? > > > I already looked it. But actually, it doesn't fit with my package. > GCfilms is a Perl application, not a Perl module. So it doesn't have to > be installed in the same way. No compilation is required. Only files have > to be copied as for an application. > > I didn't find in CVS extras example of another pure Perl application to > have a model. If someone knows one, it could be useful. Looking at the "install" program in the gcfiles tarball, I think there are a couple of problems with it: 1. It seems to initialize perl-Gtk2 (and hence require DISPLAY to be set) even if you're doing a text-mode install. This is never going to work in an RPM build environment (you'll also need perl-Gtk2 as a BuildRequires). 2. The installer accepts a "prefix" directory but doesn't offer any more fine-grained specification of directories, e.g. lib, bin, share etc. Whilst this will work OK on some platforms, you might have problems with building on other architectures. What I'd suggest is to not bother with the "install" script and instead use Requires: entries for all the dependency checks and use a bunch of "%{_bindir}/install" commands to actually install all the files in the right places. Since you've already enumerated the list of files in the %files section, this shouldn't be too big a problem. Paul. From skvidal at phy.duke.edu Mon May 9 15:17:52 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 09 May 2005 11:17:52 -0400 Subject: buildsystem stuff In-Reply-To: <20050509134506.0bc83340@python2> References: <1115181658.15831.45.camel@cutter> <20050504130715.51f466c7@python2> <1115276838.22456.48.camel@cutter> <20050509134506.0bc83340@python2> Message-ID: <1115651872.21549.100.camel@cutter> > Thanks for all those answers, and also for pointing me at repomanage, as > it seems to be _the_ tool I've been searching for for soooo long! > which is kinda sad considering how little it does :) You should see some of the spiffy, spiffy things Gijs and Panu have done that are in yum-utils. -sv From tian at c-sait.net Mon May 9 15:42:34 2005 From: tian at c-sait.net (tian at c-sait.net) Date: Mon, 9 May 2005 17:42:34 +0200 (CEST) Subject: Self-Introduction: Christian Jodar (Tian) In-Reply-To: <427F7CD6.3010006@city-fan.org> References: <20050503220937.4df887c2@tianbox> <1115639069.21984.18.camel@ignacio.ignacio.lan> <41039.62.210.124.226.1115646370.squirrel@62.210.124.226> <427F6C30.3020000@city-fan.org> <32838.62.210.124.226.1115648172.squirrel@62.210.124.226> <427F7CD6.3010006@city-fan.org> Message-ID: <58739.62.210.124.226.1115653354.squirrel@62.210.124.226> > Looking at the "install" program in the gcfiles tarball, I think there > are a couple of problems with it: Thanks a lot for these remarks. I will change that even if I don't use it for the RPM creation, because it could be useful for everyone. > What I'd suggest is to not bother with the "install" script and instead > use Requires: entries for all the dependency checks and use a bunch of > "%{_bindir}/install" commands to actually install all the files in the > right places. Since you've already enumerated the list of files in the > %files section, this shouldn't be too big a problem. Does it act the same way if I use %{__install} macro? Concerning the Requires, it seems that rpmbuild check for Perl dependancies and it should not be needed. To be able to use GCfilms install script in %install section, I should also add a --nocheck option. Depending on time it will take for these 2 solutions, I will use one of them. I'll let you know when everyhting is fixed. Tian. From toshio at tiki-lounge.com Mon May 9 15:40:20 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 9 May 2005 08:40:20 -0700 Subject: Approval needed: mlmmj In-Reply-To: <20050509203014.1725d882.mfleming@enlartenment.com>; from mfleming@enlartenment.com on Mon, May 09, 2005 at 08:30:14PM +1000 References: <20050507120206.4f791a8f.mfleming@enlartenment.com> <20050507231416.45417926.mfleming@enlartenment.com> <1115475973.4296.1.camel@Madison.badger.com> <20050509203014.1725d882.mfleming@enlartenment.com> Message-ID: <20050509084020.A16113@tiki-lounge.com> On Mon, May 09, 2005 at 08:30:14PM +1000, Michael Fleming wrote: > On Sat, 07 May 2005 10:26:12 -0400. Toshio waffled thusly: > > > On Sat, 2005-05-07 at 23:14 +1000, Michael Fleming wrote: > > > On Sat, 7 May 2005 08:21:24 -0400 (EDT). Chris Ricker waffled thusly: > > > > > > > On Sat, 7 May 2005, Michael Fleming wrote: > > > > > - The source package also contains two web frontends (one in Perl > > > > > and another in PHP) for maintaining the lists and allowing visitors > > > > > to sign up. Should they be split off into a subpackage, included in > > > > > %doc (which I've seen done for some other packages) or omitted > > > > > completely (the current status). Otherwise creation of new lists is > > > > > via a small shell script included in the current package - fine for > > > > > shell access but not overly convenient. > > > > > > > > subpackages would be nicest, I'd think > > > > > > This is possible, probably simpler - but the Requires: would be a case > > > of "left as an exercise for the reader" unless you want it to get a > > > little hairy (not /everyone/ has *both* PHP and perl on the system..) > > > > > Why not separate subpackages for each front-end? Seems most admins > > would install one that uses php _or_ one that uses perl, not both. > > How does: > > mlmmj-contrib-perl > mlmmj-contrib-php > > ....sound? > If not having a web front end is a major loss in functionality, then mlmmj-webgui-perl and mlmmj-webgui-python might be better. Something that says that the packages provide an integral piece of functionality. > I /could/ put the files under /usr/share/mlmmj/contrib/ (rather than a mess > of webserver-dependent roots)- this way admins can copy the respective > trees to wherever their webserver requires them and give permissions/ > ownership accordingly. > If an admin has to copy the files over, it should probably go in %doc. But again, if the webgui is pretty key to making mlmmj a good package, it's best to set them up as a works out of the box subpackage. If you're worried about where exactly the webroots live, I believe you should be able to set the mlmmj guis up in /var/ somewhere and then include an /etc/httpd/conf.d/mlmmj-webgui-*.conf file to add the program to apache. Not sure how crucial that is, though. -Toshio From paul at city-fan.org Mon May 9 15:48:30 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 09 May 2005 16:48:30 +0100 Subject: Self-Introduction: Christian Jodar (Tian) In-Reply-To: <58739.62.210.124.226.1115653354.squirrel@62.210.124.226> References: <20050503220937.4df887c2@tianbox> <1115639069.21984.18.camel@ignacio.ignacio.lan> <41039.62.210.124.226.1115646370.squirrel@62.210.124.226> <427F6C30.3020000@city-fan.org> <32838.62.210.124.226.1115648172.squirrel@62.210.124.226> <427F7CD6.3010006@city-fan.org> <58739.62.210.124.226.1115653354.squirrel@62.210.124.226> Message-ID: <427F864E.1020607@city-fan.org> tian at c-sait.net wrote: >>Looking at the "install" program in the gcfiles tarball, I think there >>are a couple of problems with it: > > > Thanks a lot for these remarks. I will change that even if I don't use > it for the RPM creation, because it could be useful for everyone. > > >>What I'd suggest is to not bother with the "install" script and instead >>use Requires: entries for all the dependency checks and use a bunch of >>"%{_bindir}/install" commands to actually install all the files in the >>right places. Since you've already enumerated the list of files in the >>%files section, this shouldn't be too big a problem. > > > Does it act the same way if I use %{__install} macro? Yes, that is what I would use, though some people suggest just using "install", "rm", "mv" rather than "%{__install}", "%{__rm}", "%{__mv}". I certainly prefer the macros personally. I mentioned %{_bindir}/install so as to distinguish it from "./install". > Concerning the Requires, it seems that rpmbuild check for Perl > dependancies and it should not be needed. True. > To be able to use GCfilms install script in %install section, I should > also add a --nocheck option. Depending on time it will take for these 2 > solutions, I will use one of them. I'll let you know when everyhting is > fixed. You may also need to add BuildRequires: for any perl modules that the GCfilms install script uses, as rpm will not be able to figure those out for itself. Paul. From robert at marcanoonline.com Mon May 9 15:49:20 2005 From: robert at marcanoonline.com (Robert Marcano) Date: Mon, 09 May 2005 11:49:20 -0400 Subject: New package: kanatest In-Reply-To: <1115640329.21984.22.camel@ignacio.ignacio.lan> References: <1115597334.20177.21.camel@localhost.localdomain> <1115640329.21984.22.camel@ignacio.ignacio.lan> Message-ID: <1115653760.11898.6.camel@tprobert.intranet.promca.com> On Mon, 2005-05-09 at 08:05 -0400, Ignacio Vazquez-Abrams wrote: > On Sun, 2005-05-08 at 20:08 -0400, Robert Marcano wrote: > > http://www.marcanoonline.com/downloads/fedora/package_submissions/kanatest/kanatest.spec > > - Summary contains %name Ready.. that was really difficult.. I was looking for $name literally, until I got it, removed the reference to Kanatest :$ > - Explicit Requires in a binary package Removed > ? Why not use d-f-i with %SOURCE1 directly? i do not understand this one, what means d-f-i? > - Use %find_lang instead of handling locale stuff manually Leaned how to use it and done ________________________________________ Robert Marcano web: http://www.marcanoonline.com/ gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD From katzj at redhat.com Mon May 9 15:51:20 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 09 May 2005 11:51:20 -0400 Subject: Review request: syslog-ng (syslog replacement daemon) In-Reply-To: <2287.213.13.86.72.1115504073.squirrel@webmail.lsd.di.uminho.pt> References: <427C0BF2.9000304@di.uminho.pt> <1115477307.3302.77.camel@bree.local.net> <1153.213.13.86.72.1115490368.squirrel@webmail.lsd.di.uminho.pt> <1115499994.9762.16.camel@bree.local.net> <2287.213.13.86.72.1115504073.squirrel@webmail.lsd.di.uminho.pt> Message-ID: <1115653880.9762.43.camel@bree.local.net> On Sat, 2005-05-07 at 23:14 +0100, Jose Pedro Oliveira wrote: > > On Sat, 2005-05-07 at 19:26 +0100, Jose Pedro Oliveira wrote: > >> > On Sat, 2005-05-07 at 01:29 +0100, Jos???? Pedro Oliveira wrote: > >> >> * Changes a file from another package > >> >> (/etc/logrotate.d/syslog from the sysklogd rpm) > >> > > >> > Better to figure out how to generalize this. See my later mail. > >> > >> Don't know how to do it without using alternatives. The best solution > >> I came up with was to comment the /etc/logrotate.d/syslog lines > >> using triggers. > >> (previous comments in https://bugzilla.fedora.us/show_bug.cgi?id=1332) > > > > The only difference between the two files right now is what pid file > > they cat to figure out what service to restart. Using a trigger to > > comment all of the sysklogd package's version of this file is *BROKEN* > > as just because a package is installed, doesn't mean it's being used. > > Not to mention that the trigger strikes me as being relatively prone to > > causing problems down the line. > > Can we expect that no changes are made to the syslog logrotate file? Can you expect no changes will be made that won't cause problems with your trigger? Trust me, I've seen the most benign triggers fail and cause all kinds of fun upgrade problems. Environments have a habit of changing in ways that you least expect. > Sure it isn't the best solution but it appears to be the one that > is less harmful. The triggers are only activated during install > and removal of sysklogd or syslog-ng. > > > As far as generalizing it, you could do this with a relatively trivial > > change to the initscript. In the start/stop, create and remove a > > symlink of /var/run/syslog.pid that points to the syslog-ng pidfile. > > Sure, it's a bit hacky, but it's better than sed'ing provided config > > files all the time. > > It doesn't work for the following cenario: > 1) FC system with sysklogd > 2) install syslog-ng > 3) stop syslog > 4) start syslog-ng > 5) remove sysklogd > => no logrotate file (!) Then you can either a) have syslog-ng require sysklogd b) include an identical (md5sum) logrotate file. If you do the latter, you'll even get the advantage of a conflict if the sysklogd one changes to make it obvious that you need to take a look. Jeremy From ivazquez at ivazquez.net Mon May 9 15:57:32 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 09 May 2005 11:57:32 -0400 Subject: New package: kanatest In-Reply-To: <1115653760.11898.6.camel@tprobert.intranet.promca.com> References: <1115597334.20177.21.camel@localhost.localdomain> <1115640329.21984.22.camel@ignacio.ignacio.lan> <1115653760.11898.6.camel@tprobert.intranet.promca.com> Message-ID: <1115654252.21984.37.camel@ignacio.ignacio.lan> On Mon, 2005-05-09 at 11:49 -0400, Robert Marcano wrote: > On Mon, 2005-05-09 at 08:05 -0400, Ignacio Vazquez-Abrams wrote: > > ? Why not use d-f-i with %SOURCE1 directly? > > i do not understand this one, what means d-f-i? desktop-file-install -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From paul at city-fan.org Mon May 9 15:57:30 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 09 May 2005 16:57:30 +0100 Subject: New package: kanatest In-Reply-To: <1115653760.11898.6.camel@tprobert.intranet.promca.com> References: <1115597334.20177.21.camel@localhost.localdomain> <1115640329.21984.22.camel@ignacio.ignacio.lan> <1115653760.11898.6.camel@tprobert.intranet.promca.com> Message-ID: <427F886A.9080307@city-fan.org> Robert Marcano wrote: > On Mon, 2005-05-09 at 08:05 -0400, Ignacio Vazquez-Abrams wrote: >>? Why not use d-f-i with %SOURCE1 directly? > > > i do not understand this one, what means d-f-i? desktop-file-install, part of the desktop-file-utils package. See also: http://fedoraproject.org/wiki/Extras_2fFedoraDesktopEntryGuidelines Paul. From perbj at stanford.edu Mon May 9 15:53:29 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Mon, 09 May 2005 08:53:29 -0700 Subject: New package: kanatest In-Reply-To: <1115653760.11898.6.camel@tprobert.intranet.promca.com> References: <1115597334.20177.21.camel@localhost.localdomain> <1115640329.21984.22.camel@ignacio.ignacio.lan> <1115653760.11898.6.camel@tprobert.intranet.promca.com> Message-ID: <1115654009.20150.2.camel@localhost.localdomain> On Mon, 2005-05-09 at 11:49 -0400, Robert Marcano wrote: > > ? Why not use d-f-i with %SOURCE1 directly? > i do not understand this one, what means d-f-i? Just shorthand for desktop-file-install . /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From kaboom at oobleck.net Mon May 9 16:10:17 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Mon, 9 May 2005 12:10:17 -0400 (EDT) Subject: wiki edit access Message-ID: Can I get wiki edit access to ? Wiki login is ChrisRicker later, chris From robert at marcanoonline.com Mon May 9 16:36:12 2005 From: robert at marcanoonline.com (Robert Marcano) Date: Mon, 09 May 2005 12:36:12 -0400 Subject: New package: kanatest In-Reply-To: <1115654009.20150.2.camel@localhost.localdomain> References: <1115597334.20177.21.camel@localhost.localdomain> <1115640329.21984.22.camel@ignacio.ignacio.lan> <1115653760.11898.6.camel@tprobert.intranet.promca.com> <1115654009.20150.2.camel@localhost.localdomain> Message-ID: <1115656573.17797.2.camel@tprobert.intranet.promca.com> On Mon, 2005-05-09 at 08:53 -0700, Per Bjornsson wrote: > On Mon, 2005-05-09 at 11:49 -0400, Robert Marcano wrote: > > > > ? Why not use d-f-i with %SOURCE1 directly? I saw the install and the the d-f-i in two steps on the extras CVS, but I do not remember the package > > i do not understand this one, what means d-f-i? > > Just shorthand for desktop-file-install . Updated and uploaded http://www.marcanoonline.com/downloads/fedora/package_submissions/kanatest/kanatest-0.3.6-2.src.rpm http://www.marcanoonline.com/downloads/fedora/package_submissions/kanatest/kanatest.spec > /Per > ________________________________________ Robert Marcano web: http://www.marcanoonline.com/ gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD From Jochen at herr-schmitt.de Mon May 9 16:24:49 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 09 May 2005 18:24:49 +0200 Subject: Review Request: inadyn In-Reply-To: <1115180432.5462.27.camel@ignacio.ignacio.lan> References: <1115135743.5462.3.camel@ignacio.ignacio.lan> <1115137339.5462.5.camel@ignacio.ignacio.lan> <0ML29c-1DT0wX2sZR-0000Kv@mrelayeu.kundenserver.de> <1115140852.5462.10.camel@ignacio.ignacio.lan> <0MKxQS-1DT1kW1AQP-0004tt@mrelayeu.kundenserver.de> <1115146454.5462.17.camel@ignacio.ignacio.lan> <0MKwh2-1DT3YG12PC-0002Ge@mrelayeu.kundenserver.de> <1115180432.5462.27.camel@ignacio.ignacio.lan> Message-ID: <0ML29c-1DVB3o3dDq-0005mP@mrelayeu.kundenserver.de> On Wed, 04 May 2005 00:20:32 -0400, you wrote: >Good stuff. Don't forget to take the changes to the devel branch and >apply it to the FC-3 branch. I have copied the changes from the devel branch to the FC-3 branch, so they should be in sync. It will be nice, if you can approved me. Best Regards: Jochen Schmitt From katzj at redhat.com Mon May 9 16:40:11 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 09 May 2005 12:40:11 -0400 Subject: wiki edit access In-Reply-To: References: Message-ID: <1115656811.9762.52.camel@bree.local.net> On Mon, 2005-05-09 at 12:10 -0400, Chris Ricker wrote: > Can I get wiki edit access to > ? > > Wiki login is ChrisRicker Added Jeremy From qspencer at ieee.org Mon May 9 16:46:42 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Mon, 09 May 2005 11:46:42 -0500 Subject: Question about epochs In-Reply-To: <20050507183312.5dbfa36f.bugs.michael@gmx.net> References: <427BE0C4.1040204@ieee.org> <1115431288.24408.153.camel@ernie> <1115472265.24408.198.camel@ernie> <20050507162108.2d9c0b72.bugs.michael@gmx.net> <1115483104.4296.32.camel@Madison.badger.com> <20050507183312.5dbfa36f.bugs.michael@gmx.net> Message-ID: <427F93F2.9020204@ieee.org> I think I remember something like this coming up here a while ago. I recently imported octave from core to extras, and it has had an epoch defined for years. I'm not sure why this was done, as octave has always had very consistent version names. Since the use of the epoch tag now seems to be frowned upon, would it cause problems if I removed the epoch from the new Extras octave package? -Quentin From ivazquez at ivazquez.net Mon May 9 16:49:16 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 09 May 2005 12:49:16 -0400 Subject: Review Request: inadyn In-Reply-To: <0ML29c-1DVB3o3dDq-0005mP@mrelayeu.kundenserver.de> References: <1115135743.5462.3.camel@ignacio.ignacio.lan> <1115137339.5462.5.camel@ignacio.ignacio.lan> <0ML29c-1DT0wX2sZR-0000Kv@mrelayeu.kundenserver.de> <1115140852.5462.10.camel@ignacio.ignacio.lan> <0MKxQS-1DT1kW1AQP-0004tt@mrelayeu.kundenserver.de> <1115146454.5462.17.camel@ignacio.ignacio.lan> <0MKwh2-1DT3YG12PC-0002Ge@mrelayeu.kundenserver.de> <1115180432.5462.27.camel@ignacio.ignacio.lan> <0ML29c-1DVB3o3dDq-0005mP@mrelayeu.kundenserver.de> Message-ID: <1115657356.21984.39.camel@ignacio.ignacio.lan> On Mon, 2005-05-09 at 18:24 +0200, Jochen Schmitt wrote: > On Wed, 04 May 2005 00:20:32 -0400, you wrote: > > >Good stuff. Don't forget to take the changes to the devel branch and > >apply it to the FC-3 branch. > > I have copied the changes from the devel branch to the FC-3 > branch, so they should be in sync. > > It will be nice, if you can approved me. https://www.redhat.com/archives/fedora-extras-commits/2005-May/msg00088.html -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazquez at ivazquez.net Mon May 9 16:51:02 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 09 May 2005 12:51:02 -0400 Subject: Question about epochs In-Reply-To: <427F93F2.9020204@ieee.org> References: <427BE0C4.1040204@ieee.org> <1115431288.24408.153.camel@ernie> <1115472265.24408.198.camel@ernie> <20050507162108.2d9c0b72.bugs.michael@gmx.net> <1115483104.4296.32.camel@Madison.badger.com> <20050507183312.5dbfa36f.bugs.michael@gmx.net> <427F93F2.9020204@ieee.org> Message-ID: <1115657462.21984.41.camel@ignacio.ignacio.lan> On Mon, 2005-05-09 at 11:46 -0500, Quentin Spencer wrote: > I think I remember something like this coming up here a while ago. I > recently imported octave from core to extras, and it has had an epoch > defined for years. I'm not sure why this was done, as octave has always > had very consistent version names. Since the use of the epoch tag now > seems to be frowned upon, would it cause problems if I removed the epoch > from the new Extras octave package? Yes, since the Epoch is non-zero and you're still expected to be able to handle updates/upgrades from FC3. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Mon May 9 16:58:23 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 09 May 2005 19:58:23 +0300 Subject: Review Request: gtorrentviewer In-Reply-To: <1115641139.21984.23.camel@ignacio.ignacio.lan> References: <427F5283.9060300@city-fan.org> <1115641139.21984.23.camel@ignacio.ignacio.lan> Message-ID: <1115657903.7472.2.camel@bobcat.mine.nu> On Mon, 2005-05-09 at 08:18 -0400, Ignacio Vazquez-Abrams wrote: > On Mon, 2005-05-09 at 13:07 +0100, Paul Howarth wrote: > > http://www.city-fan.org/~paul/extras/gtorrentviewer/gtorrentviewer.spec > > > %{__sed} -i -e 's at Exec=gtorrentviewer at Exec=%{_bindir}/gtorrentviewer@' \ > > -e 's at Icon=gtorrentviewer.png at Icon=%{_datadir}/pixmaps/gtorrentviewer.png@' \ > > data/gtorrentviewer.desktop.in > > Completely unnecessary. Some might say that the latter (Icon= with a hardcoded path) is actually harmful because it'll probably prevent icon theming from working for this particular icon. Not that it'd be a big deal right now, but in principle. From jpo at di.uminho.pt Mon May 9 17:09:51 2005 From: jpo at di.uminho.pt (=?windows-1252?Q?Jos=E9_Pedro_Oliveira?=) Date: Mon, 09 May 2005 18:09:51 +0100 Subject: Review request: syslog-ng (syslog replacement daemon) In-Reply-To: <427F812F.6040605@redhat.com> References: <427C0BF2.9000304@di.uminho.pt> <1115477307.3302.77.camel@bree.local.net> <1153.213.13.86.72.1115490368.squirrel@webmail.lsd.di.uminho.pt> <1115499994.9762.16.camel@bree.local.net> <2287.213.13.86.72.1115504073.squirrel@webmail.lsd.di.uminho.pt> <427F812F.6040605@redhat.com> Message-ID: <427F995F.8020601@di.uminho.pt> Daniel J Walsh wrote: > Jose Pedro Oliveira wrote: > >>> On Sat, 2005-05-07 at 19:26 +0100, Jose Pedro Oliveira wrote: >>> >>> >>>>> On Sat, 2005-05-07 at 01:29 +0100, Jos???? Pedro Oliveira wrote: >>>>> >>>>> >>>>>> * Changes a file from another package >>>>>> (/etc/logrotate.d/syslog from the sysklogd rpm) >>>>>> >>>>> >>>>> Better to figure out how to generalize this. See my later mail. >>>>> >>>> >>>> Don't know how to do it without using alternatives. The best solution >>>> I came up with was to comment the /etc/logrotate.d/syslog lines >>>> using triggers. >>>> (previous comments in https://bugzilla.fedora.us/show_bug.cgi?id=1332) >>>> >>> >>> The only difference between the two files right now is what pid file >>> they cat to figure out what service to restart. Using a trigger to >>> comment all of the sysklogd package's version of this file is *BROKEN* >>> as just because a package is installed, doesn't mean it's being used. >>> Not to mention that the trigger strikes me as being relatively prone to >>> causing problems down the line. >>> >> >> >> Can we expect that no changes are made to the syslog logrotate file? >> >> Sure it isn't the best solution but it appears to be the one that >> is less harmful. The triggers are only activated during install >> and removal of sysklogd or syslog-ng. >> >> >> >>> As far as generalizing it, you could do this with a relatively trivial >>> change to the initscript. In the start/stop, create and remove a >>> symlink of /var/run/syslog.pid that points to the syslog-ng pidfile. >>> Sure, it's a bit hacky, but it's better than sed'ing provided config >>> files all the time. >>> >> >> >> It doesn't work for the following cenario: >> 1) FC system with sysklogd >> 2) install syslog-ng >> 3) stop syslog >> 4) start syslog-ng >> 5) remove sysklogd >> => no logrotate file (!) >> >> Shouldn't the symlink idea be expanded to "alternatives" ? >> >> >> >>>>>> * currently it doesn't change the use_syslogng SELinux boolean >>>>>> >>>>> >>>>> I don't see any other packages doing anything like this at the moment, >>>>> and I'm not entirely sure how I feel about it.[1] Looking at what the >>>>> boolean allows, I think that some of them at least are valid in the >>>>> >>>> >>>> case >>>> >>>> >>>>> of sysklogd where you're using a remote syslog server. cc'ing Dan to >>>>> see if he has an opinion here. >>>>> >>>> >>>> As the use_syslogng SELinux boolean is for syslog_ng, I don't see >>>> any problem in enabling/disabling it using the post scripts >>>> (see the message in trhe fedora-packaging mailing list). >>>> >>> >>> Sometimes, the right answer to how to package a piece of software >>> includes getting other things in the distribution fixed. And in this >>> case, I'm not convinced that syslog-ng's basic needs shouldn't be >>> covered by the standard syslog policy already, although there may be >>> gaps or bugs which should legitimately be looked at. Let's look at the >>> things which the boolean allows: >>> >> >> >> This is a moving target and I am a newbie when it comes to SELinux. >> But in FC3 you wouldn't be able to start syslog-ng without (most of) the >> following rules: >> >> ... >> bool use_syslogng false; >> >> if (use_syslogng) { >> # Allow access to /proc/kmsg for syslog-ng >> allow syslogd_t proc_t:dir search; >> allow syslogd_t proc_kmsg_t:file { getattr read }; >> allow syslogd_t kernel_t:system { syslog_mod syslog_console }; >> allow syslogd_t self:capability { sys_admin chown fsetid }; >> allow syslogd_t var_log_t:dir { create setattr }; >> } >> >> Source: >> RPM: selinux-policy-targeted-sources-1.17.30-2.96 >> File: /etc/selinux/targeted/src/policy/domains/program/syslogd.te >> >> Hoping that Dan Walsh will answer the following questions: >> >> >> >>> if (use_syslogng) { >>> # Allow access to /proc/kmsg for syslog-ng >>> allow syslogd_t proc_t:dir search; >>> allow syslogd_t proc_kmsg_t:file { getattr read }; >>> >>> It looks like klogd uses /proc/kmsg by default for accessing kernel >>> messages, so why should this be covered under the boolean? >>> >>> allow syslogd_t kernel_t:system { syslog_mod syslog_console }; >>> allow syslogd_t self:capability { sys_admin chown fsetid }; >>> >>> This looks like it's already allowed for klogd >>> >>> allow syslogd_t var_log_t:dir { create setattr }; >>> >>> sysklogd would need this functionality as well if it is allowed to >>> create arbitrary, not existing already log files. >>> >>> allow syslogd_t syslogd_port_t:tcp_socket name_bind; >>> >>> You want to allow this for remote logging with sysklogd as well >>> >>> allow syslogd_t rsh_port_t:tcp_socket name_connect; >>> >>> Not clear at all one why syslog-ng would need access to bind to the rsh >>> socket. Source grepping a bit shows that it's being used for network >>> logging. Aside from the brokenness of re-using a standard port, having >>> people be aware of the need to allow the operation if they configure >>> syslog-ng in this fashion doesn't strike me as a bad idea. >>> >>> Jeremy >>> >> >> jpo >> >> > I am removing the boolean from prolicy. Dan, Will you also backport it to FC3 (and RHEL)? TIA, jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From paul at city-fan.org Mon May 9 17:27:30 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 09 May 2005 18:27:30 +0100 Subject: Review Request: gtorrentviewer In-Reply-To: <1115657903.7472.2.camel@bobcat.mine.nu> References: <427F5283.9060300@city-fan.org> <1115641139.21984.23.camel@ignacio.ignacio.lan> <1115657903.7472.2.camel@bobcat.mine.nu> Message-ID: <427F9D82.6000305@city-fan.org> Ville Skytt? wrote: > On Mon, 2005-05-09 at 08:18 -0400, Ignacio Vazquez-Abrams wrote: > >>On Mon, 2005-05-09 at 13:07 +0100, Paul Howarth wrote: >> >>>http://www.city-fan.org/~paul/extras/gtorrentviewer/gtorrentviewer.spec >> >>>%{__sed} -i -e 's at Exec=gtorrentviewer at Exec=%{_bindir}/gtorrentviewer@' \ >>> -e 's at Icon=gtorrentviewer.png at Icon=%{_datadir}/pixmaps/gtorrentviewer.png@' \ >>> data/gtorrentviewer.desktop.in >> >>Completely unnecessary. > > > Some might say that the latter (Icon= with a hardcoded path) is actually > harmful because it'll probably prevent icon theming from working for > this particular icon. Not that it'd be a big deal right now, but in > principle. I've reverted back to the relative path now. I did the edit to use absolute paths because the NewPackageProcess Wiki page refers to the logjam package as an example, and the desktop file in that package uses absolute paths; I thought it might be a portability thing. I've also added a call to update-desktop-database in the %post and %postun scripts, and added Requires(post) and Requires(postun) dependencies on desktop-file-utils accordingly. Paul. From a.kurtz at hardsun.net Mon May 9 17:49:33 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Mon, 09 May 2005 10:49:33 -0700 Subject: Review Request: gtorrentviewer In-Reply-To: <427F5283.9060300@city-fan.org> References: <427F5283.9060300@city-fan.org> Message-ID: <1115660973.14957.13.camel@rydia.hardsun.net> On Mon, 2005-05-09 at 13:07 +0100, Paul Howarth wrote: > An earlier version of my package was kindly reviewed by Aaron Kurtz in > the "Self-Introduction: Paul Howarth" thread > (https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00264.html). > Having made a number of changes, I thought it was probably better to > start a new thread with a more sensible subject header regarding the > updated version. > > Summary: > A GTK2-based viewer and editor for BitTorrent meta files > > Description: > The purpose of GTorrentViewer is to give the ability to see and modify > all the possible information from .torrent files without having to start > downloading and the ability to see in real time the current number of > seeds and peers on the torrent, so you will always know the status > before starting the download. > > Spec file: > http://www.city-fan.org/~paul/extras/gtorrentviewer/gtorrentviewer.spec > > SRPM: > http://www.city-fan.org/~paul/extras/gtorrentviewer/gtorrentviewer-0.2b-2.fc3.src.rpm - /usr/share/GTorrentViewer/README and the README in docs are duplicates. - Lacks a Provides and Obsoletes for older users of capitalized package, although this isn't crucial. + MD5sums match, compiles and runs without a problem. Everything else I was going to mention has been dealt with in 0.2b-3 release. I'm guessing you don't have CVS access, so I'd be willing to import it for you. Also, I noticed you have a package for torrentsniff. Any chance of you putting that forward for Extras? -- Aaron Kurtz From bugs.michael at gmx.net Mon May 9 17:51:04 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 9 May 2005 19:51:04 +0200 Subject: Review Request: gtorrentviewer In-Reply-To: <427F9D82.6000305@city-fan.org> References: <427F5283.9060300@city-fan.org> <1115641139.21984.23.camel@ignacio.ignacio.lan> <1115657903.7472.2.camel@bobcat.mine.nu> <427F9D82.6000305@city-fan.org> Message-ID: <20050509195104.11bb3f09.bugs.michael@gmx.net> On Mon, 09 May 2005 18:27:30 +0100, Paul Howarth wrote: > >>>%{__sed} -i -e 's at Exec=gtorrentviewer at Exec=%{_bindir}/gtorrentviewer@' \ > >>> -e 's at Icon=gtorrentviewer.png at Icon=%{_datadir}/pixmaps/gtorrentviewer.png@' \ > >>> data/gtorrentviewer.desktop.in > >> > >>Completely unnecessary. > > > > > > Some might say that the latter (Icon= with a hardcoded path) is actually > > harmful because it'll probably prevent icon theming from working for > > this particular icon. Not that it'd be a big deal right now, but in > > principle. > > I've reverted back to the relative path now. I did the edit to use > absolute paths because the NewPackageProcess Wiki page refers to the > logjam package as an example, and the desktop file in that package uses > absolute paths; I thought it might be a portability thing. Please ignore the yellow box at the bottom of that Wiki page. It doesn't belong there. From qspencer at ieee.org Mon May 9 18:16:16 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Mon, 09 May 2005 13:16:16 -0500 Subject: Build System In-Reply-To: <20050509175809.7F019852C@extras64.linux.duke.edu> References: <20050509175809.7F019852C@extras64.linux.duke.edu> Message-ID: <427FA8F0.8020503@ieee.org> I recently got an error from the build system because I forgot to do "make tag" on my package before requesting a build. I've done that now. Will the build system try again, or will I need to re-submit the build request? -Quentin From skvidal at phy.duke.edu Mon May 9 18:17:33 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 09 May 2005 14:17:33 -0400 Subject: Build System In-Reply-To: <427FA8F0.8020503@ieee.org> References: <20050509175809.7F019852C@extras64.linux.duke.edu> <427FA8F0.8020503@ieee.org> Message-ID: <1115662653.21549.109.camel@cutter> On Mon, 2005-05-09 at 13:16 -0500, Quentin Spencer wrote: > I recently got an error from the build system because I forgot to do > "make tag" on my package before requesting a build. I've done that now. > Will the build system try again, or will I need to re-submit the build > request? resubmit. -sv From tcallawa at redhat.com Mon May 9 19:39:24 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 09 May 2005 14:39:24 -0500 Subject: dist tags, build targets, and sparcs! Message-ID: <1115667564.3017.92.camel@localhost.localdomain> Thanks to the fine work of Ignacio Vazquez-Abrams and Jeremy Katz, we've got some more of this tricky packaging stuff figured out. To get all this goodness, you need to make sure you've got the latest copy of common/ from CVS. Doing a cvs update in your checkout dir should grab it. 1. dist tags: Dist tags are now very very easy. So easy, even I can use it properly. Here is how you use it. Take your: Release: 5. Append %{?dist} to the end. It should now look like: Release: 5%{?dist} Then, run: make tag. Thats all. The buildsystem defines %{dist} (and helper variables such as %{fedora}) based on the cvs branch that you're sitting in. The same thing is true for make build. No more wacky macros. No more shell scripts. No more hardcoding values into spec files. The Dist Tag documentation has been updated to reflect this: http://www.fedoraproject.org/wiki/DistTag You don't have to use the dist tag if you don't want to, but now its very easy to use. 2. build targets If you're in the FC-3 directory of your package checkout, you can just type: make build, and it will do the right thing. Same thing goes for devel, or any other cvs branch. The make build TARGET= syntax still works, but its no longer necessary. (If you do something stupid like run make build TARGET=devel in your FC-3 directory, it will do bad things, so don't do that.) 3. sparcs No, not yet. Just seeing if anyone reads this far. :) ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From mricon at gmail.com Mon May 9 19:41:01 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Mon, 9 May 2005 15:41:01 -0400 Subject: Review: pylint, python-logilab-common In-Reply-To: <1115488124.4296.41.camel@Madison.badger.com> References: <1115488124.4296.41.camel@Madison.badger.com> Message-ID: On 5/7/05, Toshio wrote: > * Man page in man/pylint.1 should be installed > * examples/ subdirectory would be helpful for those looking to > customize. Well-noted. I've also added the elisp directory to the %doc macro. Cheers, -- Konstantin Ryabitsev Zlotniks, INC "? ????? ???? ?? ??? ???? ?????????????." --???? From tcallawa at redhat.com Mon May 9 19:42:42 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 09 May 2005 14:42:42 -0500 Subject: dist tags, build targets, and sparcs! In-Reply-To: <1115667564.3017.92.camel@localhost.localdomain> References: <1115667564.3017.92.camel@localhost.localdomain> Message-ID: <1115667762.3017.94.camel@localhost.localdomain> On Mon, 2005-05-09 at 14:39 -0500, Tom 'spot' Callaway wrote: > Take your: > Release: 5. > > Append %{?dist} to the end. It should now look like: > Release: 5%{?dist} Obviously, you should run: cvs commit here... then run make tag. :) Sorry for the confusion, ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jwboyer at jdub.homelinux.org Mon May 9 19:43:06 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 9 May 2005 14:43:06 -0500 Subject: dist tags, build targets, and sparcs! In-Reply-To: <1115667564.3017.92.camel@localhost.localdomain> References: <1115667564.3017.92.camel@localhost.localdomain> Message-ID: <20050509194306.GA6741@yoda.jdub.homelinux.org> On Mon, May 09, 2005 at 02:39:24PM -0500, Tom 'spot' Callaway wrote: > Thanks to the fine work of Ignacio Vazquez-Abrams and Jeremy Katz, we've > got some more of this tricky packaging stuff figured out. > > To get all this goodness, you need to make sure you've got the latest > copy of common/ from CVS. Doing a cvs update in your checkout dir should > grab it. > > 1. dist tags: > Dist tags are now very very easy. So easy, even I can use it properly. > Here is how you use it. > > Take your: > Release: 5. > > Append %{?dist} to the end. It should now look like: > Release: 5%{?dist} > > Then, run: make tag. > > Thats all. The buildsystem defines %{dist} (and helper variables such as > %{fedora}) based on the cvs branch that you're sitting in. The same > thing is true for make build. Ok, very cool. This is exactly what I was asking for in my thread from last week. Thanks Ignacio and Tom. josh From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon May 9 19:44:20 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 9 May 2005 21:44:20 +0200 Subject: dist tags, build targets, and sparcs! In-Reply-To: <1115667564.3017.92.camel@localhost.localdomain> References: <1115667564.3017.92.camel@localhost.localdomain> Message-ID: <20050509214420.342888a0@python2> Tom 'spot' Callaway wrote : [...] > 3. sparcs > > No, not yet. Just seeing if anyone reads this far. :) Pfffew, that was a close one :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.20_FC3 Load : 0.40 0.17 0.32 From kaboom at oobleck.net Mon May 9 19:43:22 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Mon, 9 May 2005 15:43:22 -0400 (EDT) Subject: dist tags, build targets, and sparcs! In-Reply-To: <1115667762.3017.94.camel@localhost.localdomain> References: <1115667564.3017.92.camel@localhost.localdomain> <1115667762.3017.94.camel@localhost.localdomain> Message-ID: On Mon, 9 May 2005, Tom 'spot' Callaway wrote: > On Mon, 2005-05-09 at 14:39 -0500, Tom 'spot' Callaway wrote: > > > Take your: > > Release: 5. > > > > Append %{?dist} to the end. It should now look like: > > Release: 5%{?dist} > > Obviously, you should run: cvs commit here... then run make tag. :) [kaboom at urd xdaliclock]$ make tag error: Macro %dist has empty body error: Macro %dist has empty body error: Macro %dist has empty body error: Macro % has illegal name (%define) error: Macro % has illegal name (%define) error: Macro %dist has empty body error: Macro %dist has empty body error: Macro %dist has empty body error: Macro % has illegal name (%define) error: Macro % has illegal name (%define) error: Macro %dist has empty body error: Macro %dist has empty body error: Macro %dist has empty body error: Macro % has illegal name (%define) error: Macro % has illegal name (%define) error: Macro %dist has empty body error: Macro %dist has empty body error: Macro %dist has empty body error: Macro % has illegal name (%define) error: Macro % has illegal name (%define) cvs tag -c xdaliclock-2_20-2 ERROR: This script can only deal with modules from /cvs/extras/rpms cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first! make: *** [tag] Error 1 [kaboom at urd xdaliclock]$ Is it broken, or is it me? :-) (this is xdaliclock spec in devel branch, release is Release: 2%{?dist}) later, chris From jdennis at redhat.com Mon May 9 19:55:17 2005 From: jdennis at redhat.com (John Dennis) Date: Mon, 09 May 2005 15:55:17 -0400 Subject: dist tags, build targets, and sparcs! In-Reply-To: <1115667564.3017.92.camel@localhost.localdomain> References: <1115667564.3017.92.camel@localhost.localdomain> Message-ID: <1115668517.7689.2.camel@finch.boston.redhat.com> On Mon, 2005-05-09 at 14:39 -0500, Tom 'spot' Callaway wrote: > 1. dist tags: > Dist tags are now very very easy. So easy, even I can use it properly. > Here is how you use it. > Thats all. The buildsystem defines %{dist} (and helper variables such as > %{fedora}) based on the cvs branch that you're sitting in. The same > thing is true for make build. > > No more wacky macros. No more shell scripts. No more hardcoding values > into spec files. Excellent! Kudos to all! Now, any chance we can get this into the Red Hat build system? -- John Dennis From ivazquez at ivazquez.net Mon May 9 19:56:26 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 09 May 2005 15:56:26 -0400 Subject: dist tags, build targets, and sparcs! In-Reply-To: References: <1115667564.3017.92.camel@localhost.localdomain> <1115667762.3017.94.camel@localhost.localdomain> Message-ID: <1115668586.21984.45.camel@ignacio.ignacio.lan> On Mon, 2005-05-09 at 15:43 -0400, Chris Ricker wrote: > Is it broken, or is it me? :-) Did you run 'cvs update' in the common subdir? -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kaboom at oobleck.net Mon May 9 20:06:33 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Mon, 9 May 2005 16:06:33 -0400 (EDT) Subject: dist tags, build targets, and sparcs! In-Reply-To: <1115668586.21984.45.camel@ignacio.ignacio.lan> References: <1115667564.3017.92.camel@localhost.localdomain> <1115667762.3017.94.camel@localhost.localdomain> <1115668586.21984.45.camel@ignacio.ignacio.lan> Message-ID: On Mon, 9 May 2005, Ignacio Vazquez-Abrams wrote: > On Mon, 2005-05-09 at 15:43 -0400, Chris Ricker wrote: > > Is it broken, or is it me? :-) > > Did you run 'cvs update' in the common subdir? I just figured it out - stupid user error on my part. I was trying to do something that was effectively the equivalent of: $ mkdir foo $ cd foo $ cvs co devel $ cd devel/xdaliclock $ make tag which blows up horribly doing: $ mkdir foo $ cd foo $ cvs co xdaliclock $ cd xdaliclock/devel $ make tag works for me Should I now just delete the broken build request in common/tobuild (kaboom devel/xdaliclock xdaliclock-2_20-2 development) and do a new make build? later, chris From ivazquez at ivazquez.net Mon May 9 20:14:08 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 09 May 2005 16:14:08 -0400 Subject: dist tags, build targets, and sparcs! In-Reply-To: References: <1115667564.3017.92.camel@localhost.localdomain> <1115667762.3017.94.camel@localhost.localdomain> <1115668586.21984.45.camel@ignacio.ignacio.lan> Message-ID: <1115669648.21984.47.camel@ignacio.ignacio.lan> On Mon, 2005-05-09 at 16:06 -0400, Chris Ricker wrote: > Should I now just delete the broken build request in common/tobuild > (kaboom devel/xdaliclock xdaliclock-2_20-2 development) and > do a new make build? Sounds like a plan. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From paul at city-fan.org Mon May 9 20:44:47 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 09 May 2005 21:44:47 +0100 Subject: Review Request: gtorrentviewer In-Reply-To: <1115660973.14957.13.camel@rydia.hardsun.net> References: <427F5283.9060300@city-fan.org> <1115660973.14957.13.camel@rydia.hardsun.net> Message-ID: <1115671488.4727.30.camel@laurel.intra.city-fan.org> On Mon, 2005-05-09 at 10:49 -0700, Aaron Kurtz wrote: > On Mon, 2005-05-09 at 13:07 +0100, Paul Howarth wrote: > > An earlier version of my package was kindly reviewed by Aaron Kurtz in > > the "Self-Introduction: Paul Howarth" thread > > (https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00264.html). > > Having made a number of changes, I thought it was probably better to > > start a new thread with a more sensible subject header regarding the > > updated version. > > > > Summary: > > A GTK2-based viewer and editor for BitTorrent meta files > > > > Description: > > The purpose of GTorrentViewer is to give the ability to see and modify > > all the possible information from .torrent files without having to start > > downloading and the ability to see in real time the current number of > > seeds and peers on the torrent, so you will always know the status > > before starting the download. > > > > Spec file: > > http://www.city-fan.org/~paul/extras/gtorrentviewer/gtorrentviewer.spec > > > > SRPM: > > http://www.city-fan.org/~paul/extras/gtorrentviewer/gtorrentviewer-0.2b-2.fc3.src.rpm > > - /usr/share/GTorrentViewer/README and the README in docs are > duplicates. I've now removed /usr/share/GTorrentViewer/README, which does not appear to be referenced within the application itself. > - Lacks a Provides and Obsoletes for older users of capitalized package, > although this isn't crucial. I decided to omit these because there was no previous capitalised package in Fedora Core/Extras, so the only place user are likely to have found such a package is my site. And if they found that, they'll probably want to decide for themselves which version they want, without having one obsolete the other. > + MD5sums match, compiles and runs without a problem. > > Everything else I was going to mention has been dealt with in 0.2b-3 > release. I've also removed the horrible, ugly, wasteful, hard-coded dist tag in 0.2b-4 :-) > I'm guessing you don't have CVS access, so I'd be willing to > import it for you. Elliot Lee has kindly sponsored me for CVS access, so all I really need is someone to approve the package... > Also, I noticed you have a package for torrentsniff. Any chance of you > putting that forward for Extras? I wasn't planning to because: * it hasn't been updated in several years * it has problems with a significant proportion of trackers * I don't think it provides any information that gtorrentviewer doesn't In fact I think the only advantage it has over gtorrentviewer is that it's a command-line client and can therefore be used in scripts. Can't you think of any other advantage? Paul. -- Paul Howarth From jfontain at free.fr Mon May 9 21:03:23 2005 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Mon, 09 May 2005 23:03:23 +0200 Subject: make build problem Message-ID: <427FD01B.8020406@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I did a make build in the FC-3 sub-directory and got this: Subject: Prep Error: moodss-20_0-2 on 3 From: buildsys at fedoraproject.org To: jfontain at fedora.redhat.com could not find path /var/tmp/moodss-20_0-2zRgWwF/rpms/moodss/FC-3 for moodss-20_0-2. Could it be because I had done a make tag in the devel sub-directory, which gave me moodss-20_0-2 at the time, then did the same in FC-3, which failed? - -- Jean-Luc Fontaine http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCf9AbkG/MMvcT1qQRAhU4AJsFlwiUOvLYbUHRXtu/rn4yOkSSkgCgmg4K 2pAQ/lwl468VLKVnm8nphqQ= =ayq4 -----END PGP SIGNATURE----- From katzj at redhat.com Mon May 9 21:14:33 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 09 May 2005 17:14:33 -0400 Subject: dist tags, build targets, and sparcs! In-Reply-To: References: <1115667564.3017.92.camel@localhost.localdomain> <1115667762.3017.94.camel@localhost.localdomain> <1115668586.21984.45.camel@ignacio.ignacio.lan> Message-ID: <1115673273.9762.76.camel@bree.local.net> On Mon, 2005-05-09 at 16:06 -0400, Chris Ricker wrote: > I just figured it out - stupid user error on my part. I was trying to do > something that was effectively the equivalent of: > > $ mkdir foo > $ cd foo > $ cvs co devel > $ cd devel/xdaliclock > $ make tag > > which blows up horribly This is supposed to work. And with the tweak I just made, it should again. Thanks for the catch. Jeremy From bugs.michael at gmx.net Mon May 9 21:45:51 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 9 May 2005 23:45:51 +0200 Subject: make build problem In-Reply-To: <427FD01B.8020406@free.fr> References: <427FD01B.8020406@free.fr> Message-ID: <20050509234551.145815b2.bugs.michael@gmx.net> On Mon, 09 May 2005 23:03:23 +0200, Jean-Luc Fontaine wrote: > I did a make build in the FC-3 sub-directory and got this: > > Subject: Prep Error: moodss-20_0-2 on 3 > From: buildsys at fedoraproject.org > To: jfontain at fedora.redhat.com > could not find path /var/tmp/moodss-20_0-2zRgWwF/rpms/moodss/FC-3 for > moodss-20_0-2. > > Could it be because I had done a make tag in the devel sub-directory, > which gave me moodss-20_0-2 at the time, then did the same in FC-3, > which failed? Right. The tags must be unique. On your "devel" tree are both tags, moodss-20_0-2 and moodss-20_0-3. The FC-3 branch has not been tagged since FC-3-start tag. From smooge at gmail.com Mon May 9 22:09:23 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Mon, 9 May 2005 16:09:23 -0600 Subject: Review request: snort In-Reply-To: <1115417695.6245.24.camel@tholian.starken.com> References: <1115181733.12189.27.camel@plasma.starken.com> <1115184112.5462.32.camel@ignacio.ignacio.lan> <1115184643.12189.37.camel@plasma.starken.com> <20050504053453.GA16130@lisas.de> <1115185408.5462.34.camel@ignacio.ignacio.lan> <20050504103121.57855b48.bugs.michael@gmx.net> <1115230611.7136.7.camel@plasma.starken.com> <80d7e40905050414414f46295@mail.gmail.com> <80d7e409050506145071ef3a24@mail.gmail.com> <1115417695.6245.24.camel@tholian.starken.com> Message-ID: <80d7e409050509150964b5e2b9@mail.gmail.com> On 5/6/05, Daniel Wittenberg wrote: > So is this just complaining because we're not specifying the libdir in > configure? I'm not real familiar with rpmlint's errors, usually just > fix big critical stuff. > > Dan > > On Fri, 2005-05-06 at 15:50 -0600, Stephen J. Smoogen wrote: > > > Going through the rpmlint errors > > > > E: snort configure-without-libdir-spec > > if [ "$1" = "mysql" ]; then > > ./configure $SNORT_BASE_CONFIG \ > > --with-mysql \ > > --without-postgresql \ > > --without-oracle \ > > %{?EnableFlexresp} %{?EnableFlexresp2} > > fi > > > > Not sure what the best fix for this is.. my take on the logic was a > > complete rewrite which usually means I dont understand the problem :). > > -- Not sure. I know that %configure without using the $SNORT_BASE_CONFIG fixes the problem (I removed it becuase it had over-lap). I feel that I dont have the packaging experience to say definately though. -- Stephen J Smoogen. CSIRT/Linux System Administrator From a.kurtz at hardsun.net Mon May 9 22:08:51 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Mon, 09 May 2005 15:08:51 -0700 Subject: Review Request: gtorrentviewer In-Reply-To: <1115671488.4727.30.camel@laurel.intra.city-fan.org> References: <427F5283.9060300@city-fan.org> <1115660973.14957.13.camel@rydia.hardsun.net> <1115671488.4727.30.camel@laurel.intra.city-fan.org> Message-ID: <1115676531.14957.23.camel@rydia.hardsun.net> On Mon, 2005-05-09 at 21:44 +0100, Paul Howarth wrote: > > I'm guessing you don't have CVS access, so I'd be willing to > > import it for you. > > Elliot Lee has kindly sponsored me for CVS access, so all I really need > is someone to approve the package... Approved. Feel free to wing an email over to fedora-extras-commits. > > Also, I noticed you have a package for torrentsniff. Any chance of you > > putting that forward for Extras? > > I wasn't planning to because: > * it hasn't been updated in several years > * it has problems with a significant proportion of trackers > * I don't think it provides any information that gtorrentviewer doesn't > > In fact I think the only advantage it has over gtorrentviewer is that > it's a command-line client and can therefore be used in scripts. Can't > you think of any other advantage? Scripts and remote shells, yeah. But the fact that it's not being maintained makes me back off my request, and it can live in my ~/bin dir easily enough. -- Aaron Kurtz From a.kurtz at hardsun.net Mon May 9 22:08:51 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Mon, 09 May 2005 15:08:51 -0700 Subject: Review Request: gtorrentviewer In-Reply-To: <1115671488.4727.30.camel@laurel.intra.city-fan.org> References: <427F5283.9060300@city-fan.org> <1115660973.14957.13.camel@rydia.hardsun.net> <1115671488.4727.30.camel@laurel.intra.city-fan.org> Message-ID: <1115676531.14957.23.camel@rydia.hardsun.net> On Mon, 2005-05-09 at 21:44 +0100, Paul Howarth wrote: > > I'm guessing you don't have CVS access, so I'd be willing to > > import it for you. > > Elliot Lee has kindly sponsored me for CVS access, so all I really need > is someone to approve the package... Approved. Feel free to wing an email over to fedora-extras-commits. > > Also, I noticed you have a package for torrentsniff. Any chance of you > > putting that forward for Extras? > > I wasn't planning to because: > * it hasn't been updated in several years > * it has problems with a significant proportion of trackers > * I don't think it provides any information that gtorrentviewer doesn't > > In fact I think the only advantage it has over gtorrentviewer is that > it's a command-line client and can therefore be used in scripts. Can't > you think of any other advantage? Scripts and remote shells, yeah. But the fact that it's not being maintained makes me back off my request, and it can live in my ~/bin dir easily enough. -- Aaron Kurtz From jpo at di.uminho.pt Mon May 9 22:22:33 2005 From: jpo at di.uminho.pt (=?UTF-8?B?Sm9zw6kgUGVkcm8gT2xpdmVpcmE=?=) Date: Mon, 09 May 2005 23:22:33 +0100 Subject: Review request: syslog-ng (syslog replacement daemon) In-Reply-To: <1115653880.9762.43.camel@bree.local.net> References: <427C0BF2.9000304@di.uminho.pt> <1115477307.3302.77.camel@bree.local.net> <1153.213.13.86.72.1115490368.squirrel@webmail.lsd.di.uminho.pt> <1115499994.9762.16.camel@bree.local.net> <2287.213.13.86.72.1115504073.squirrel@webmail.lsd.di.uminho.pt> <1115653880.9762.43.camel@bree.local.net> Message-ID: <427FE2A9.4070109@di.uminho.pt> Jeremy Katz wrote: > On Sat, 2005-05-07 at 23:14 +0100, Jose Pedro Oliveira wrote: > >>>On Sat, 2005-05-07 at 19:26 +0100, Jose Pedro Oliveira wrote: >>> >>>>>On Sat, 2005-05-07 at 01:29 +0100, Jos???? Pedro Oliveira wrote: >>>>> >>>>>> * Changes a file from another package >>>>>> (/etc/logrotate.d/syslog from the sysklogd rpm) >>>>> >>>>>Better to figure out how to generalize this. See my later mail. >>>> >>>>Don't know how to do it without using alternatives. The best solution >>>>I came up with was to comment the /etc/logrotate.d/syslog lines >>>>using triggers. >>>>(previous comments in https://bugzilla.fedora.us/show_bug.cgi?id=1332) >>> >>>The only difference between the two files right now is what pid file >>>they cat to figure out what service to restart. Using a trigger to >>>comment all of the sysklogd package's version of this file is *BROKEN* >>>as just because a package is installed, doesn't mean it's being used. >>>Not to mention that the trigger strikes me as being relatively prone to >>>causing problems down the line. >> >>Can we expect that no changes are made to the syslog logrotate file? > > > Can you expect no changes will be made that won't cause problems with > your trigger? Trust me, I've seen the most benign triggers fail and > cause all kinds of fun upgrade problems. Environments have a habit of > changing in ways that you least expect. > > >>Sure it isn't the best solution but it appears to be the one that >>is less harmful. The triggers are only activated during install >>and removal of sysklogd or syslog-ng. >> >> >>>As far as generalizing it, you could do this with a relatively trivial >>>change to the initscript. In the start/stop, create and remove a >>>symlink of /var/run/syslog.pid that points to the syslog-ng pidfile. >>>Sure, it's a bit hacky, but it's better than sed'ing provided config >>>files all the time. >> >>It doesn't work for the following cenario: >> 1) FC system with sysklogd >> 2) install syslog-ng >> 3) stop syslog >> 4) start syslog-ng >> 5) remove sysklogd >> => no logrotate file (!) > > > Then you can either > a) have syslog-ng require sysklogd > b) include an identical (md5sum) logrotate file. > > If you do the latter, you'll even get the advantage of a conflict if the > sysklogd one changes to make it obvious that you need to take a look. The second option appears to work (still have to test several more combinations of installation/removal/upgrading of sysklogd and syslog-ng). Syslog-ng devel branch updated. Thanks, jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ville.skytta at iki.fi Mon May 9 22:29:14 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 10 May 2005 01:29:14 +0300 Subject: debuginfo packages in the "main" repository? Message-ID: <1115677754.7472.45.camel@bobcat.mine.nu> I see new debuginfo packages have entered the "main" repository while previously they were in the "debug" subdir. Is this intentional? Perhaps Seth's commit to the build system today is/was related? http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/ http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/debug/ From ville.skytta at iki.fi Mon May 9 22:31:30 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 10 May 2005 01:31:30 +0300 Subject: debuginfo packages in the "main" repository? In-Reply-To: <1115677754.7472.45.camel@bobcat.mine.nu> References: <1115677754.7472.45.camel@bobcat.mine.nu> Message-ID: <1115677890.7472.46.camel@bobcat.mine.nu> On Tue, 2005-05-10 at 01:29 +0300, Ville Skytt? wrote: > I see new debuginfo packages have entered the "main" repository while > previously they were in the "debug" subdir. Is this intentional? > Perhaps Seth's commit to the build system today is/was related? Yep. I should have read -maintainers first, sorry about the noise. From tian at c-sait.net Mon May 9 22:58:26 2005 From: tian at c-sait.net (Tian) Date: Tue, 10 May 2005 00:58:26 +0200 Subject: New version of GCfilms package (was: Self-Introduction: Christian Jodar (Tian)) Message-ID: <20050510005826.4b211569@tianbox> Hello, I made a new version of the GCfilms .src.rpm thanks to the great help of Ignacio Vazquez-Abrams and Paul Howarth New file can be found here: http://download.gna.org/gcfilms/fedora/3/gcfilms-5.0-2.src.rpm Modified .spec is there: http://cvs.gna.org/viewcvs/gcfilms/gcfilms/packages/fedora/gcfilms.spec?rev=HEAD&content-type=text/vnd.viewcvs-markup Generated RPM is there: http://download.gna.org/gcfilms/fedora/3/gcfilms-5.0-2.noarch.rpm I also have some questions. Concerning the Source0 value, I used a URL for it. But during my build process, I needed to download it before. I thought that rpmbuild will do such a thing alone. When packages are integrated in Fedora Extras CVS how is it done? Is there a separate process that download sources if needed? As you may have notices, there is a lot of %{__install} commands in the %install section. As it seems there is no way to do some recursive copies with install (but I may be wrong) , is it really better to use it instead of a more classical cp? I got a notification email telling me my membership request in cvsextras group has been rejected. Does it mean I have to give up with all this stuff? Or do I first have to find a sponsor and then apply again? Or something else? Thanks again for your help. Tian. From sopwith at redhat.com Mon May 9 23:14:53 2005 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 9 May 2005 19:14:53 -0400 (EDT) Subject: New version of GCfilms package (was: Self-Introduction: Christian Jodar (Tian)) In-Reply-To: <20050510005826.4b211569@tianbox> References: <20050510005826.4b211569@tianbox> Message-ID: On Tue, 10 May 2005, Tian wrote: > I got a notification email telling me my membership request in cvsextras > group has been rejected. Does it mean I have to give up with all this stuff? > Or do I first have to find a sponsor and then apply again? Or something else? I rejected the request because it had been sitting there with nobody acting on it, and because a google search didn't show any activity from you on the mailing lists. If you find a sponsor I can certainly set it up for you to get membership again. Best, -- Elliot From tian at c-sait.net Mon May 9 23:24:25 2005 From: tian at c-sait.net (Tian) Date: Tue, 10 May 2005 01:24:25 +0200 Subject: New version of GCfilms package (was: Self-Introduction: Christian Jodar (Tian)) In-Reply-To: References: <20050510005826.4b211569@tianbox> Message-ID: <20050510012425.10ea9143@tianbox> > I rejected the request because it had been sitting there with nobody > acting on it, and because a google search didn't show any activity from > you on the mailing lists. If you find a sponsor I can certainly set it up > for you to get membership again. OK. Thanks a lot for your quick answer. I should have wait before this request. Before looking actively for a sponsor, I will have to fix my package and be sure of how I could contribute. Tian. From mfleming at enlartenment.com Mon May 9 23:52:31 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Tue, 10 May 2005 09:52:31 +1000 Subject: Approval needed: mlmmj In-Reply-To: <20050509084020.A16113@tiki-lounge.com> References: <20050507120206.4f791a8f.mfleming@enlartenment.com> <20050507231416.45417926.mfleming@enlartenment.com> <1115475973.4296.1.camel@Madison.badger.com> <20050509203014.1725d882.mfleming@enlartenment.com> <20050509084020.A16113@tiki-lounge.com> Message-ID: <20050509235231.GA6609@enlartenment.com> On Mon, May 09, 2005 at 08:40:20AM -0700, Toshio Kuratomi waffled thusly: > On Mon, May 09, 2005 at 08:30:14PM +1000, Michael Fleming wrote: > > On Sat, 07 May 2005 10:26:12 -0400. Toshio waffled thusly: > > > > > On Sat, 2005-05-07 at 23:14 +1000, Michael Fleming wrote: > > > > On Sat, 7 May 2005 08:21:24 -0400 (EDT). Chris Ricker waffled thusly: > > > > [sub-packaging mlmmj's contributed web frontends] > > > Why not separate subpackages for each front-end? Seems most admins > > > would install one that uses php _or_ one that uses perl, not both. > > > > How does: > > > > mlmmj-contrib-perl > > mlmmj-contrib-php > > > > ....sound? > > > If not having a web front end is a major loss in functionality, then > mlmmj-webgui-perl and mlmmj-webgui-python might be better. Something that > says that the packages provide an integral piece of functionality. I wouldn't say it was an integral part of the package - it works without it - however it would extremely useful for shared environments where a list admin may not have root or shell access. > > I /could/ put the files under /usr/share/mlmmj/contrib/ (rather than a mess > > of webserver-dependent roots)- this way admins can copy the respective > > trees to wherever their webserver requires them and give permissions/ > > ownership accordingly. > > > If an admin has to copy the files over, it should probably go in %doc. I used to put it in %doc (my own repo versions) however it seemed the resulting RPM picked up extra dependencies I didn't want, unless I removed execute access from those files. > But again, if the webgui is pretty key to making mlmmj a good package, it's > best to set them up as a works out of the box subpackage. > > If you're worried about where exactly the webroots live, I believe you > should be able to set the mlmmj guis up in /var/ somewhere and then include > an /etc/httpd/conf.d/mlmmj-webgui-*.conf file to add the program to apache. > Not sure how crucial that is, though. This would work OK - /var/www/mlmmj-web would make most sense to me (and should keep SELinux happy too) and generating an Apache .conf for it is trivial . Unfortunately users of other webservers with different roots would still need to adjust accordingly. Oh, well. However I'd need to get package approval and a build queued before I deal with that, as I've not been able to do the latter due to a lack of the former. > -Toshio > Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From rdieter at math.unl.edu Tue May 10 02:23:09 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 09 May 2005 21:23:09 -0500 Subject: Request for review: OpenEXR, swish-e In-Reply-To: <1115503349.24408.317.camel@ernie> References: <1114335625.7784.41.camel@ignacio.ignacio.lan> <1115377802.7124.1.camel@ignacio.ignacio.lan> <1115455194.7124.7.camel@ignacio.ignacio.lan> <1115489931.12675.0.camel@ignacio.ignacio.lan> <1115497327.9556.5.camel@bobcat.mine.nu> <1115497988.20211.1.camel@ignacio.ignacio.lan> <1115503349.24408.317.camel@ernie> Message-ID: Ed Hill wrote: > not sure about this one: > - Can the "%{_libdir}/*.la" files be discarded? Or are they > really needed? IMO, drop them. Not needed. -- Rex From buildsys at fedoraproject.org Tue May 10 04:33:32 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 10 May 2005 00:33:32 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050510043332.3B94383D4@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 22 Coin2-2.3.0-8.fc4 Glide3-20010520-36 OpenEXR-1.2.2-2 R-gnomeGUI-2.1.0-4 SoQt-1.2.0-4.fc4 apg-2.3.0b-1.fc4 bzflag-2.0.2-4 enigma-0.91-5 gcombust-0.1.55-6 gnet2-2.0.7-3 inadyn-1.90-11 jed-0.99.16-10 librx-1.5-5 moodss-20.0-3 nfswatch-4.99.2-2 perl-OLE-Storage_Lite-0.14-5 python-reportlab-1.20-3.fc4 synergy-1.2.2-3 udunits-1.12.4-7.fc4 udunits-1.12.4-8 verbiste-0.1.11-2 xdaliclock-2.20-2 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 May 10 04:49:19 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 10 May 2005 00:49:19 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050510044919.6598B83D4@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 9 Macaulay2-0.9.2-14 OpenEXR-1.2.2-2 SoQt-1.2.0-4.fc3 apg-2.3.0b-1 gnet2-2.0.7-3 graveman-0.3.11-2 librx-1.5-5 udunits-1.12.4-7.fc3 udunits-1.12.4-8 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 May 10 05:04:15 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 10 May 2005 07:04:15 +0200 Subject: Fedora Extras 3 Package Build Report In-Reply-To: <20050510044919.6598B83D4@extras64.linux.duke.edu> References: <20050510044919.6598B83D4@extras64.linux.duke.edu> Message-ID: <20050510070415.4e09689f.bugs.michael@gmx.net> On Tue, 10 May 2005 00:49:19 -0400 (EDT), buildsys at fedoraproject.org wrote: > > Packages built and released for Fedora Extras 3: 9 > > udunits-1.12.4-7.fc3 > udunits-1.12.4-8 Hmm, what's that? The effect of removing the hardcoded definition of %{dist}? It should have resulted in release 8.fc3, and looks like it's broken for FC3. The previous release 7.fc3 was in the repository already long before this announcement. It was listed in "Fedora Extras 3 Package Build Report" on May 9th as udunits-1.12.4-7.fc3. From daniel-wittenberg at starken.com Tue May 10 05:10:03 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Tue, 10 May 2005 00:10:03 -0500 Subject: Epoch + snort sponser Message-ID: <1115701804.25390.7.camel@plasma.starken.com> The new snort RPM's are about ready, but am wondering about stripping the Epoch out. I've noticed when I build RPM's without the Epoch then I can't simply 'rpm -Fvh' the rpm, it doesn't see it as an upgrade. If I put the Epoch back in the spec then it'll update just fine. Ideas on how to safely get rid of the Epoch? Or am I just stuck with it there forever? Since snort is about ready to roll out the new version + new RPM's I'd like to see if we can get it in Extras now if someone wants to help... Dan From paul at city-fan.org Tue May 10 06:11:52 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 10 May 2005 07:11:52 +0100 Subject: Approval needed: mlmmj In-Reply-To: <20050509235231.GA6609@enlartenment.com> References: <20050507120206.4f791a8f.mfleming@enlartenment.com> <20050507231416.45417926.mfleming@enlartenment.com> <1115475973.4296.1.camel@Madison.badger.com> <20050509203014.1725d882.mfleming@enlartenment.com> <20050509084020.A16113@tiki-lounge.com> <20050509235231.GA6609@enlartenment.com> Message-ID: <1115705512.4727.70.camel@laurel.intra.city-fan.org> On Tue, 2005-05-10 at 09:52 +1000, Michael Fleming wrote: > On Mon, May 09, 2005 at 08:40:20AM -0700, Toshio Kuratomi waffled thusly: > > On Mon, May 09, 2005 at 08:30:14PM +1000, Michael Fleming wrote: > > > On Sat, 07 May 2005 10:26:12 -0400. Toshio waffled thusly: > > > > > > > On Sat, 2005-05-07 at 23:14 +1000, Michael Fleming wrote: > > > > > On Sat, 7 May 2005 08:21:24 -0400 (EDT). Chris Ricker waffled thusly: > > > > > > > [sub-packaging mlmmj's contributed web frontends] > > > > > Why not separate subpackages for each front-end? Seems most admins > > > > would install one that uses php _or_ one that uses perl, not both. > > > > > > How does: > > > > > > mlmmj-contrib-perl > > > mlmmj-contrib-php > > > > > > ....sound? > > > > > If not having a web front end is a major loss in functionality, then > > mlmmj-webgui-perl and mlmmj-webgui-python might be better. Something that > > says that the packages provide an integral piece of functionality. > > I wouldn't say it was an integral part of the package - it works without > it - however it would extremely useful for shared environments where a > list admin may not have root or shell access. > > > > I /could/ put the files under /usr/share/mlmmj/contrib/ (rather than a mess > > > of webserver-dependent roots)- this way admins can copy the respective > > > trees to wherever their webserver requires them and give permissions/ > > > ownership accordingly. > > > > > If an admin has to copy the files over, it should probably go in %doc. > > I used to put it in %doc (my own repo versions) however it seemed the > resulting RPM picked up extra dependencies I didn't want, unless I > removed execute access from those files. You could prevent the extra dependencies being generated by using your own find_requires script, which calls the standard %{__find_requires} and then [carefully] greps out the bogus dependencies. For example: %define _use_internal_dependency_generator 0 %define my_find_requires %{_builddir}/%{name}-%{version}/find_requires %{__cat} <%{my_find_requires} #! /bin/sh exec %{__find_requires} | /bin/egrep -v '^(bogus dependency regex)$' exit 0 EOF chmod +x %{my_find_requires} %define __find_requires %{my_find_requires} Paul. -- Paul Howarth From ivazquez at ivazquez.net Tue May 10 07:47:06 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 10 May 2005 03:47:06 -0400 Subject: Fedora Extras 3 Package Build Report In-Reply-To: <20050510070415.4e09689f.bugs.michael@gmx.net> References: <20050510044919.6598B83D4@extras64.linux.duke.edu> <20050510070415.4e09689f.bugs.michael@gmx.net> Message-ID: <1115711226.21984.51.camel@ignacio.ignacio.lan> On Tue, 2005-05-10 at 07:04 +0200, Michael Schwendt wrote: > On Tue, 10 May 2005 00:49:19 -0400 (EDT), buildsys at fedoraproject.org wrote: > > > > > Packages built and released for Fedora Extras 3: 9 > > > > udunits-1.12.4-7.fc3 > > udunits-1.12.4-8 > > Hmm, what's that? The effect of removing the hardcoded definition of > %{dist}? It should have resulted in release 8.fc3, and looks like it's > broken for FC3. It appears as though the build system doesn't have the definitions of the disttags in place. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From paul at city-fan.org Tue May 10 09:31:09 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 10 May 2005 10:31:09 +0100 Subject: Review Request: gtorrentviewer In-Reply-To: <1115676531.14957.23.camel@rydia.hardsun.net> References: <427F5283.9060300@city-fan.org> <1115660973.14957.13.camel@rydia.hardsun.net> <1115671488.4727.30.camel@laurel.intra.city-fan.org> <1115676531.14957.23.camel@rydia.hardsun.net> Message-ID: <42807F5D.7040006@city-fan.org> Aaron Kurtz wrote: > On Mon, 2005-05-09 at 21:44 +0100, Paul Howarth wrote: > > >>> I'm guessing you don't have CVS access, so I'd be willing to >>>import it for you. >> >>Elliot Lee has kindly sponsored me for CVS access, so all I really need >>is someone to approve the package... > > > Approved. Feel free to wing an email over to fedora-extras-commits. Done: https://www.redhat.com/archives/fedora-extras-commits/2005-May/msg00597.html I've also imported the SRPM into CVS, which gives it a "devel" branch. I'd also like to create FC-2 and FC-3 branches, which according to the Extras/UsingCvsFaq page on the Wiki, I can do by editing the Extras/CVSSyncNeeded Wiki page. However, I don't have permission to edit that page. How do I go about getting the branches done? Similarly, the NewPackageProcess page tells me to create a bugzilla component for the package by editing the Extras/BugzillaAdmin page, but I can't edit that either. Finally, since gtorrentviewer is now in CVS (http://cvs.fedora.redhat.com/viewcvs/devel/gtorrentviewer/?root=extras), I'd like to request additional reviews of the package before I request a build, as suggested by the NewPackageProcess page. Paul. From pmatilai at welho.com Tue May 10 09:34:17 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 10 May 2005 12:34:17 +0300 (EEST) Subject: Epoch + snort sponser In-Reply-To: <1115701804.25390.7.camel@plasma.starken.com> References: <1115701804.25390.7.camel@plasma.starken.com> Message-ID: On Tue, 10 May 2005, Daniel Wittenberg wrote: > The new snort RPM's are about ready, but am wondering about stripping > the Epoch out. I've noticed when I build RPM's without the Epoch then I > can't simply 'rpm -Fvh' the rpm, it doesn't see it as an upgrade. If I > put the Epoch back in the spec then it'll update just fine. > > Ideas on how to safely get rid of the Epoch? Or am I just stuck with it > there forever? A non-zero Epoch can never be removed (without breaking upgradability, as you just noticed :) - Panu - From bugs.michael at gmx.net Tue May 10 09:55:37 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 10 May 2005 11:55:37 +0200 Subject: Review Request: gtorrentviewer In-Reply-To: <42807F5D.7040006@city-fan.org> References: <427F5283.9060300@city-fan.org> <1115660973.14957.13.camel@rydia.hardsun.net> <1115671488.4727.30.camel@laurel.intra.city-fan.org> <1115676531.14957.23.camel@rydia.hardsun.net> <42807F5D.7040006@city-fan.org> Message-ID: <20050510115537.4e11c2e3.bugs.michael@gmx.net> On Tue, 10 May 2005 10:31:09 +0100, Paul Howarth wrote: > I've also imported the SRPM into CVS, which gives it a "devel" branch. > I'd also like to create FC-2 and FC-3 branches, which according to the > Extras/UsingCvsFaq page on the Wiki, I can do by editing the > Extras/CVSSyncNeeded Wiki page. However, I don't have permission to edit > that page. How do I go about getting the branches done? Post your Wiki account name, so you can be added to the EditGroup. From bugs.michael at gmx.net Tue May 10 09:58:56 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 10 May 2005 11:58:56 +0200 Subject: Epoch + snort sponser In-Reply-To: References: <1115701804.25390.7.camel@plasma.starken.com> Message-ID: <20050510115856.549eb943.bugs.michael@gmx.net> On Tue, 10 May 2005 12:34:17 +0300 (EEST), Panu Matilainen wrote: > On Tue, 10 May 2005, Daniel Wittenberg wrote: > > > The new snort RPM's are about ready, but am wondering about stripping > > the Epoch out. I've noticed when I build RPM's without the Epoch then I > > can't simply 'rpm -Fvh' the rpm, it doesn't see it as an upgrade. If I > > put the Epoch back in the spec then it'll update just fine. > > > > Ideas on how to safely get rid of the Epoch? Or am I just stuck with it > > there forever? > > A non-zero Epoch can never be removed (without breaking upgradability, as > you just noticed :) A zero Epoch cannot be removed either due to above problem with rpm -Fvh, as we've experienced very early thanks to Ville (bug report in bugzilla). But the issue was not considered important enough, and nobody complained loudly when all zero Epochs were removed within devel CVS. From paul at city-fan.org Tue May 10 10:03:44 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 10 May 2005 11:03:44 +0100 Subject: Review Request: gtorrentviewer In-Reply-To: <20050510115537.4e11c2e3.bugs.michael@gmx.net> References: <427F5283.9060300@city-fan.org> <1115660973.14957.13.camel@rydia.hardsun.net> <1115671488.4727.30.camel@laurel.intra.city-fan.org> <1115676531.14957.23.camel@rydia.hardsun.net> <42807F5D.7040006@city-fan.org> <20050510115537.4e11c2e3.bugs.michael@gmx.net> Message-ID: <42808700.6070705@city-fan.org> Michael Schwendt wrote: > On Tue, 10 May 2005 10:31:09 +0100, Paul Howarth wrote: > > >>I've also imported the SRPM into CVS, which gives it a "devel" branch. >>I'd also like to create FC-2 and FC-3 branches, which according to the >>Extras/UsingCvsFaq page on the Wiki, I can do by editing the >>Extras/CVSSyncNeeded Wiki page. However, I don't have permission to edit >>that page. How do I go about getting the branches done? > > > Post your Wiki account name, so you can be added to the EditGroup. It's PaulHowarth Paul. From bugs.michael at gmx.net Tue May 10 10:17:09 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 10 May 2005 12:17:09 +0200 Subject: Review Request: gtorrentviewer In-Reply-To: <42808700.6070705@city-fan.org> References: <427F5283.9060300@city-fan.org> <1115660973.14957.13.camel@rydia.hardsun.net> <1115671488.4727.30.camel@laurel.intra.city-fan.org> <1115676531.14957.23.camel@rydia.hardsun.net> <42807F5D.7040006@city-fan.org> <20050510115537.4e11c2e3.bugs.michael@gmx.net> <42808700.6070705@city-fan.org> Message-ID: <20050510121709.29ada0a9.bugs.michael@gmx.net> On Tue, 10 May 2005 11:03:44 +0100, Paul Howarth wrote: > > Post your Wiki account name, so you can be added to the EditGroup. > > It's PaulHowarth Added. From paul at city-fan.org Tue May 10 10:45:34 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 10 May 2005 11:45:34 +0100 Subject: Review Request: pptp Message-ID: <428090CE.5070309@city-fan.org> Summary: Point-to-Point Tunneling Protocol (PPTP) Client Description: Client for the proprietary Microsoft Point-to-Point Tunneling Protocol, PPTP. Allows connection to a PPTP based VPN as used by employers and some cable and ADSL service providers. Spec file: http://www.city-fan.org/~paul/extras/pptp/pptp.spec SRPM: http://www.city-fan.org/~paul/extras/pptp/pptp-1.6.0-2.fc3.src.rpm The pptp package is already included in the SuSE, Mandrake, and Debian (as pptp-linux) distributions. See http://pptpclient.sourceforge.net/ An open source PPTP VPN server is also available, namely PoPToP (http://poptop.sourceforge.net/). I may package this for extras too at a later date if there's demand for it. Paul. From ivazquez at ivazquez.net Tue May 10 11:26:38 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 10 May 2005 07:26:38 -0400 Subject: Review Request: pptp In-Reply-To: <428090CE.5070309@city-fan.org> References: <428090CE.5070309@city-fan.org> Message-ID: <1115724398.21984.57.camel@ignacio.ignacio.lan> On Tue, 2005-05-10 at 11:45 +0100, Paul Howarth wrote: > http://www.city-fan.org/~paul/extras/pptp/pptp.spec Looks good. Don't forget to file a bug report against ppp. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 10 11:28:22 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 10 May 2005 13:28:22 +0200 Subject: Review Request: pptp In-Reply-To: <428090CE.5070309@city-fan.org> References: <428090CE.5070309@city-fan.org> Message-ID: <20050510132822.4ea68df7@python2> Paul Howarth wrote : > Spec file: > http://www.city-fan.org/~paul/extras/pptp/pptp.spec Nice and clean spec file :-) > SRPM: > http://www.city-fan.org/~paul/extras/pptp/pptp-1.6.0-2.fc3.src.rpm Rebuilds fine for me, and I can't see any obvious problems. I'm unable to fully test the functionalities, but am willing to approve the package for an initial import nevertheless. Looking at the homepage and install instructions that : 1) Once again there is a kernel module that could be added... 2) There are some nice config tools (in php-gtk!?) which could also be packaged :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.20_FC3 Load : 1.27 1.23 1.20 From paul at city-fan.org Tue May 10 11:43:56 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 10 May 2005 12:43:56 +0100 Subject: Review Request: pptp In-Reply-To: <20050510132822.4ea68df7@python2> References: <428090CE.5070309@city-fan.org> <20050510132822.4ea68df7@python2> Message-ID: <42809E7C.9010201@city-fan.org> Matthias Saou wrote: > Paul Howarth wrote : > > >>Spec file: >>http://www.city-fan.org/~paul/extras/pptp/pptp.spec > > > Nice and clean spec file :-) > > >>SRPM: >>http://www.city-fan.org/~paul/extras/pptp/pptp-1.6.0-2.fc3.src.rpm > > > Rebuilds fine for me, and I can't see any obvious problems. I'm unable to > fully test the functionalities, but am willing to approve the package for > an initial import nevertheless. > > Looking at the homepage and install instructions that : > 1) Once again there is a kernel module that could be added... Matt Domsch at Dell is working on getting the ppp_mppe module included in the upstream kernel. It's a long process though. A possible problem with providing a separate package for this module is that it requires patching (and hence replacing) the existing ppp_generic module. I don't know what the best way of doing that is. My intention was to wait for the module to appear upstream. > 2) There are some nice config tools (in php-gtk!?) which could also > be packaged :-) I already do the packages on the website there, and could import those in extras. However, as far as I know, php-gtk currently requires PHP4 (compiled with pcntl support, which is not included in FC3). It really would be better if it could be ported to something a bit more modern like PyGTK. Unfortunately that's beyond my abilities. Paul. From adrian at lisas.de Tue May 10 12:18:43 2005 From: adrian at lisas.de (Adrian Reber) Date: Tue, 10 May 2005 14:18:43 +0200 Subject: Review Request: gtorrentviewer In-Reply-To: <42807F5D.7040006@city-fan.org> References: <427F5283.9060300@city-fan.org> <1115660973.14957.13.camel@rydia.hardsun.net> <1115671488.4727.30.camel@laurel.intra.city-fan.org> <1115676531.14957.23.camel@rydia.hardsun.net> <42807F5D.7040006@city-fan.org> Message-ID: <20050510121843.GA25942@lisas.de> On Tue, May 10, 2005 at 10:31:09AM +0100, Paul Howarth wrote: > Finally, since gtorrentviewer is now in CVS > (http://cvs.fedora.redhat.com/viewcvs/devel/gtorrentviewer/?root=extras), > I'd like to request additional reviews of the package before I request a > build, as suggested by the NewPackageProcess page. I have some suggestions: You don't need all the BuildRequires. You can remove atk-devel, krb5-devel, pango-devel and zlib-devel. They are all pulled in by the other BuildRequires. And some personal preferences: I think it is better to not use a specific sf mirror as Source URL. I would recommend: http://dl.sf.net/gtorrentviewer/GTorrentViewer-%{version}.tar.gz I would also change the URL from http://gtorrentviewer.sourceforge.net/index.html to http://gtorrentviewer.sourceforge.net/ or http://gtorrentviewer.sf.net/ Adrian From kaboom at oobleck.net Tue May 10 12:23:59 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 10 May 2005 08:23:59 -0400 (EDT) Subject: dist tags, build targets, and sparcs! In-Reply-To: <1115673273.9762.76.camel@bree.local.net> References: <1115667564.3017.92.camel@localhost.localdomain> <1115667762.3017.94.camel@localhost.localdomain> <1115668586.21984.45.camel@ignacio.ignacio.lan> <1115673273.9762.76.camel@bree.local.net> Message-ID: On Mon, 9 May 2005, Jeremy Katz wrote: > This is supposed to work. And with the tweak I just made, it should > again. Thanks for the catch. Good deal, thanks! Doing this $ mkdir foo $ cd foo $ cvs co FC-3 $ cd FC-3/xdaliclock $ make tag now works. If I then do $ make build that fails -- just does [kaboom at urd xdaliclock]$ make build [kaboom at urd xdaliclock]$ However, if I do $ mkdir foo $ cd foo $ cvs co xdaliclock $ cd xdaliclock/FC-3 $ make build that works Similar problem? later, chris From paul at city-fan.org Tue May 10 12:37:49 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 10 May 2005 13:37:49 +0100 Subject: Review Request: gtorrentviewer In-Reply-To: <20050510121843.GA25942@lisas.de> References: <427F5283.9060300@city-fan.org> <1115660973.14957.13.camel@rydia.hardsun.net> <1115671488.4727.30.camel@laurel.intra.city-fan.org> <1115676531.14957.23.camel@rydia.hardsun.net> <42807F5D.7040006@city-fan.org> <20050510121843.GA25942@lisas.de> Message-ID: <4280AB1D.1030508@city-fan.org> Adrian Reber wrote: > On Tue, May 10, 2005 at 10:31:09AM +0100, Paul Howarth wrote: > >>Finally, since gtorrentviewer is now in CVS >>(http://cvs.fedora.redhat.com/viewcvs/devel/gtorrentviewer/?root=extras), >>I'd like to request additional reviews of the package before I request a >>build, as suggested by the NewPackageProcess page. > > > I have some suggestions: > > You don't need all the BuildRequires. You can remove atk-devel, > krb5-devel, pango-devel and zlib-devel. They are all pulled in by the > other BuildRequires. Thanks; I hadn't followed the dependency chains far enough. > And some personal preferences: > > I think it is better to not use a specific sf mirror as Source URL. I > would recommend: > http://dl.sf.net/gtorrentviewer/GTorrentViewer-%{version}.tar.gz Thanks again; I didn't know there was a general URL for sf.net downloads, which is why I was using a specific mirror in the first place. > I would also change the URL from > http://gtorrentviewer.sourceforge.net/index.html > to > http://gtorrentviewer.sourceforge.net/ Done. Cheers, Paul. From kaboom at oobleck.net Tue May 10 12:38:50 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 10 May 2005 08:38:50 -0400 (EDT) Subject: Review Request: pptp In-Reply-To: <428090CE.5070309@city-fan.org> References: <428090CE.5070309@city-fan.org> Message-ID: On Tue, 10 May 2005, Paul Howarth wrote: > Summary: > Point-to-Point Tunneling Protocol (PPTP) Client > > Description: > Client for the proprietary Microsoft Point-to-Point Tunneling > Protocol, PPTP. Allows connection to a PPTP based VPN as used > by employers and some cable and ADSL service providers. > > Spec file: > http://www.city-fan.org/~paul/extras/pptp/pptp.spec Spec looks good What are your thoughts on MPPE inclusion? Every Microsoft PPTP VPN I've ever seen required that as well.... It may be patent-encumbered though? Packaging of pptpconfig to go with this would be useful too > An open source PPTP VPN server is also available, namely PoPToP > (http://poptop.sourceforge.net/). I may package this for extras too at a later > date if there's demand for it. Given the general broken-ness of PPTP, it might be best not to encourage people to persist in furthering the use of it :-) later, chris From paul at city-fan.org Tue May 10 13:11:37 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 10 May 2005 14:11:37 +0100 Subject: Review Request: pptp In-Reply-To: References: <428090CE.5070309@city-fan.org> Message-ID: <4280B309.9020709@city-fan.org> Chris Ricker wrote: > On Tue, 10 May 2005, Paul Howarth wrote: > > >>Summary: >>Point-to-Point Tunneling Protocol (PPTP) Client >> >>Description: >>Client for the proprietary Microsoft Point-to-Point Tunneling >>Protocol, PPTP. Allows connection to a PPTP based VPN as used >>by employers and some cable and ADSL service providers. >> >>Spec file: >>http://www.city-fan.org/~paul/extras/pptp/pptp.spec > > > Spec looks good > > What are your thoughts on MPPE inclusion? Every Microsoft PPTP VPN I've > ever seen required that as well.... It may be patent-encumbered though? Whilst it's possible to set up an MS VPN server not to require MPPE, it's not very useful ;-) However, there are applications of PPTP that do not require encryption. For instance, I connect to my ADSL ISP using pptp. Regarding patents, I don't believe that the ppp_mppe module has any patent issues, but the alternative ppp_mppe_mppc module does. See: http://pptpclient.sourceforge.net/howto-diagnosis.phtml#running_pppd_after_connection > Packaging of pptpconfig to go with this would be useful too Well, yes, but that opens another can of worms as I mentioned earlier: https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00394.html The PHP4 in FC3 doesn't include the pcntl module, and FC4 ships with PHP5, which I believe (I haven't tried it) is incompatible with php-gtk. >>An open source PPTP VPN server is also available, namely PoPToP >>(http://poptop.sourceforge.net/). I may package this for extras too at a later >>date if there's demand for it. > > > Given the general broken-ness of PPTP, it might be best not to encourage > people to persist in furthering the use of it :-) Unfortunately some of us have no choice if we need to use $EMPLOYER's VPN. Cheers, Paul. From qspencer at ieee.org Tue May 10 13:18:03 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Tue, 10 May 2005 08:18:03 -0500 Subject: Fedora Extras development Package Build Report In-Reply-To: <20050510043332.3B94383D4@extras64.linux.duke.edu> References: <20050510043332.3B94383D4@extras64.linux.duke.edu> Message-ID: <4280B48B.9000003@ieee.org> buildsys at fedoraproject.org wrote: >Packages built and released for Fedora Extras development: 22 > > I submitted two packages yesterday to the build system that aren't on this list (fftw3 and octave). If there were build failures, wouldn't there have been a notice sent out for them as well? I had initially forgotten to do "make tag" before requesting a build, and received a notice of failure from the build system. After correcting the problem, I resubmitted the build request, so that the two packages were listed twice for a while yesterday. Would the system have automatically ignored the second request since the first failed? -Quentin From skvidal at phy.duke.edu Tue May 10 13:20:24 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 10 May 2005 09:20:24 -0400 Subject: Fedora Extras development Package Build Report In-Reply-To: <4280B48B.9000003@ieee.org> References: <20050510043332.3B94383D4@extras64.linux.duke.edu> <4280B48B.9000003@ieee.org> Message-ID: <1115731224.10234.1.camel@cutter> On Tue, 2005-05-10 at 08:18 -0500, Quentin Spencer wrote: > buildsys at fedoraproject.org wrote: > > >Packages built and released for Fedora Extras development: 22 > > > > > I submitted two packages yesterday to the build system that aren't on > this list (fftw3 and octave). If there were build failures, wouldn't > there have been a notice sent out for them as well? I had initially > forgotten to do "make tag" before requesting a build, and received a > notice of failure from the build system. After correcting the problem, I > resubmitted the build request, so that the two packages were listed > twice for a while yesterday. Would the system have automatically ignored > the second request since the first failed? if the tag was identical as before then, yes, it would have ignored the second entry. I've restarted the queuer - submit them now. -sv From kaboom at oobleck.net Tue May 10 13:28:07 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 10 May 2005 09:28:07 -0400 (EDT) Subject: Review Request: pptp In-Reply-To: <4280B309.9020709@city-fan.org> References: <428090CE.5070309@city-fan.org> <4280B309.9020709@city-fan.org> Message-ID: On Tue, 10 May 2005, Paul Howarth wrote: > Regarding patents, I don't believe that the ppp_mppe module has any patent > issues, but the alternative ppp_mppe_mppc module does. > See: > http://pptpclient.sourceforge.net/howto-diagnosis.phtml#running_pppd_after_connection Okay, looks like encryption's fine, but compression is patented? > > Packaging of pptpconfig to go with this would be useful too > > Well, yes, but that opens another can of worms as I mentioned earlier: > https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00394.html > > The PHP4 in FC3 doesn't include the pcntl module, and FC4 ships with PHP5, > which I believe (I haven't tried it) is incompatible with php-gtk. Yeah, I'd forgotten they're in php-gtk. I think the php-gtk plan is to skip over 5.0 and only support PHP5.1+? > > >An open source PPTP VPN server is also available, namely PoPToP > > >(http://poptop.sourceforge.net/). I may package this for extras too at a > > >later > > >date if there's demand for it. > > > > > > Given the general broken-ness of PPTP, it might be best not to encourage > > people to persist in furthering the use of it :-) > > Unfortunately some of us have no choice if we need to use $EMPLOYER's VPN. Right, and that's where the pptpclient enters in. My point was that it might be best not to package a PPTP server (poptop) because if you do, you'll just encourage people to persist in setting up more PPTP servers. later, chris From Christian.Iseli at licr.org Tue May 10 13:35:17 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Tue, 10 May 2005 15:35:17 +0200 Subject: Fedora Extras development Package Build Report In-Reply-To: Your message of "Tue, 10 May 2005 09:20:24 EDT." <1115731224.10234.1.camel@cutter> Message-ID: <200505101335.j4ADZHEt001687@localhost.localdomain> skvidal at phy.duke.edu said: > I've restarted the queuer - submit them now. Out of curiosity: how quickly can the entries be removed from the file ? IOW, is it an edge driven, or a state driven process ? Should each people who requests a build also remove the entry ? Up to now, it seems we relied on a few kind souls to cleanup once in a while :) BTW, this build process works quite nicely. Kudos and thanks, Christian From skvidal at phy.duke.edu Tue May 10 13:40:06 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 10 May 2005 09:40:06 -0400 Subject: Fedora Extras development Package Build Report In-Reply-To: <200505101335.j4ADZHEt001687@localhost.localdomain> References: <200505101335.j4ADZHEt001687@localhost.localdomain> Message-ID: <1115732406.10234.18.camel@cutter> On Tue, 2005-05-10 at 15:35 +0200, Christian.Iseli at licr.org wrote: > skvidal at phy.duke.edu said: > > I've restarted the queuer - submit them now. > > Out of curiosity: how quickly can the entries be removed from the file ? > IOW, is it an edge driven, or a state driven process ? I'm not familiar with these terms so I can't tell you which it is. Entries can be removed from the file once the build has occurred. > Should each people who requests a build also remove the entry ? it'd be nice - but not critical Soon(tm) we'll be changing how the queuer gets notified about the jobs. It won't be using a file in cvs but a db that jobs are submitted to via an xml-rpc server. it should make life a fair bit easier on all parts. the file in cvs just let things get off the ground faster. -sv From kaboom at oobleck.net Tue May 10 13:39:42 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 10 May 2005 09:39:42 -0400 (EDT) Subject: transient build errors? Message-ID: I got the following error for a build request Installing group 'minimal' ....error: /usr/sbin/mach-helper yum --installroot /var/lib/mach/roots/fedora-3-i386-core -c /var/lib/mach/states/fedora-3-i386-core/ yum.conf groupinstall build-minimal failed. Setting up Group Process Setting up Repos core 100% |=========================| 1.1 kB 00:00 extras 100% |=========================| 951 B 00:00 local 100% |=========================| 951 B 00:00 updates 100% |=========================| 951 B 00:00 http://linux.duke.edu/%7Eskvidal/mach/i386/repodata/repomd.xml: [Errno 4] IOErro r: Trying other mirror. Cannot open/read repomd.xml file for repository: groups failure: repodata/repomd.xml from groups: [Errno 256] No more mirrors to try. ERROR: Could not get build-minimal ! I assume that's just a transient build system problem? If so, will it automatically retry, or do I need to resubmit the build request? later, chris From skvidal at phy.duke.edu Tue May 10 13:44:02 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 10 May 2005 09:44:02 -0400 Subject: transient build errors? In-Reply-To: References: Message-ID: <1115732642.10234.20.camel@cutter> On Tue, 2005-05-10 at 09:39 -0400, Chris Ricker wrote: > I got the following error for a build request > > > > Installing group 'minimal' ....error: /usr/sbin/mach-helper yum > --installroot /var/lib/mach/roots/fedora-3-i386-core -c > /var/lib/mach/states/fedora-3-i386-core/ > yum.conf groupinstall build-minimal failed. > Setting up Group Process > Setting up Repos > core 100% |=========================| 1.1 kB 00:00 > extras 100% |=========================| 951 B 00:00 > local 100% |=========================| 951 B 00:00 > updates 100% |=========================| 951 B 00:00 > http://linux.duke.edu/%7Eskvidal/mach/i386/repodata/repomd.xml: [Errno 4] > IOErro > r: > Trying other mirror. > Cannot open/read repomd.xml file for repository: groups > failure: repodata/repomd.xml from groups: [Errno 256] No more mirrors to > try. > > ERROR: Could not get build-minimal > ! > > I assume that's just a transient build system problem? If so, will it > automatically retry, or do I need to resubmit the build request? > read the list from this morning. if the entry is still in the 'tobuild' file then don't restart it. -sv From jfontain at free.fr Tue May 10 13:45:36 2005 From: jfontain at free.fr (jfontain at free.fr) Date: Tue, 10 May 2005 15:45:36 +0200 Subject: how to detect 64 bit architecture in rpm spec? Message-ID: <1115732736.4280bb00b2f6e@imp1-q.free.fr> What is the best way to test that the architecture is 64 bit based? %ifarch? PS: I need that because a bug was fixed in Tcl 8.4.8 on 64 bit machines and I need to require that version on such architectures. Thanks, -- Jean-Luc From paul at city-fan.org Tue May 10 13:50:24 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 10 May 2005 14:50:24 +0100 Subject: Review Request: pptp In-Reply-To: References: <428090CE.5070309@city-fan.org> <4280B309.9020709@city-fan.org> Message-ID: <4280BC20.2030909@city-fan.org> Chris Ricker wrote: > On Tue, 10 May 2005, Paul Howarth wrote: > > >>Regarding patents, I don't believe that the ppp_mppe module has any patent >>issues, but the alternative ppp_mppe_mppc module does. >>See: >>http://pptpclient.sourceforge.net/howto-diagnosis.phtml#running_pppd_after_connection > > > Okay, looks like encryption's fine, but compression is patented? That's my understanding. >>>Packaging of pptpconfig to go with this would be useful too >> >>Well, yes, but that opens another can of worms as I mentioned earlier: >>https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00394.html >> >>The PHP4 in FC3 doesn't include the pcntl module, and FC4 ships with PHP5, >>which I believe (I haven't tried it) is incompatible with php-gtk. > > > Yeah, I'd forgotten they're in php-gtk. I think the php-gtk plan is to > skip over 5.0 and only support PHP5.1+? I don't know really. PHP-GTK-2 is not yet at "very early alpha" stage though (see: http://gtk.php.net/). What we currently do is to create a separate PHP4 build with pcntl support, installed somewhere like %_libdir/php-pcntl, and use that for pptpconfig. It's ugly but it works. >>>>An open source PPTP VPN server is also available, namely PoPToP >>>>(http://poptop.sourceforge.net/). I may package this for extras too at a >>>>later >>>>date if there's demand for it. >>> >>> >>>Given the general broken-ness of PPTP, it might be best not to encourage >>>people to persist in furthering the use of it :-) >> >>Unfortunately some of us have no choice if we need to use $EMPLOYER's VPN. > > > Right, and that's where the pptpclient enters in. My point was that it > might be best not to package a PPTP server (poptop) because if you do, > you'll just encourage people to persist in setting up more PPTP servers. Understood. Paul. From Christian.Iseli at licr.org Tue May 10 13:59:18 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Tue, 10 May 2005 15:59:18 +0200 Subject: Fedora Extras development Package Build Report In-Reply-To: Your message of "Tue, 10 May 2005 09:40:06 EDT." <1115732406.10234.18.camel@cutter> Message-ID: <200505101359.j4ADxIgJ001867@localhost.localdomain> skvidal at phy.duke.edu said: > On Tue, 2005-05-10 at 15:35 +0200, Christian.Iseli at licr.org wrote: > > Out of curiosity: how quickly can the entries be removed from the file ? > > IOW, is it an edge driven, or a state driven process ? > I'm not familiar with these terms so I can't tell you which it is. Sorry, let me try to explain: - edge driven would mean that the mere fact of adding an entry to the cvs file (even if the entry is deleted immediately afterward) is enough to trigger a build. In this case, the person requesting a build can delete the entry right after requesting a "make build". The key point is that the entry *is added* to the cvs file at some point. - state driven would mean that some process parses the file from time to time (aka polling) and builds whatever entries are found in the file at that time. In this case, the person requesting a build needs to wait for the build system to have at least started the build before removing the entry. The key point is that the entry *is* in the cvs file at some point. Cheers, Christian From skvidal at phy.duke.edu Tue May 10 14:02:18 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 10 May 2005 10:02:18 -0400 Subject: Fedora Extras development Package Build Report In-Reply-To: <200505101359.j4ADxIgJ001867@localhost.localdomain> References: <200505101359.j4ADxIgJ001867@localhost.localdomain> Message-ID: <1115733738.10234.28.camel@cutter> On Tue, 2005-05-10 at 15:59 +0200, Christian.Iseli at licr.org wrote: > skvidal at phy.duke.edu said: > > On Tue, 2005-05-10 at 15:35 +0200, Christian.Iseli at licr.org wrote: > > > Out of curiosity: how quickly can the entries be removed from the file ? > > > IOW, is it an edge driven, or a state driven process ? > > I'm not familiar with these terms so I can't tell you which it is. > > Sorry, let me try to explain: > - edge driven would mean that the mere fact of adding an entry to the cvs > file (even if the entry is deleted immediately afterward) is enough to > trigger a build. In this case, the person requesting a build can delete > the entry right after requesting a "make build". The key point is that the > entry *is added* to the cvs file at some point. > - state driven would mean that some process parses the file from time to time > (aka polling) and builds whatever entries are found in the file at that > time. In this case, the person requesting a build needs to wait for the > build system to have at least started the build before removing the entry. > The key point is that the entry *is* in the cvs file at some point. the latter. -sv From jdennis at redhat.com Tue May 10 14:07:06 2005 From: jdennis at redhat.com (John Dennis) Date: Tue, 10 May 2005 10:07:06 -0400 Subject: how to detect 64 bit architecture in rpm spec? In-Reply-To: <1115732736.4280bb00b2f6e@imp1-q.free.fr> References: <1115732736.4280bb00b2f6e@imp1-q.free.fr> Message-ID: <1115734026.12631.20.camel@localhost.localdomain> On Tue, 2005-05-10 at 15:45 +0200, jfontain at free.fr wrote: > What is the best way to test that the architecture is 64 bit based? > %ifarch? > > PS: I need that because a bug was fixed in Tcl 8.4.8 on 64 bit machines and I > need to require that version on such architectures. I would suggest you just require Tcl >= 8.4.8 and not try to conditionalize on the arch, its cleaner and less error prone. -- John Dennis From kaboom at oobleck.net Tue May 10 14:18:53 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 10 May 2005 10:18:53 -0400 (EDT) Subject: transient build errors? In-Reply-To: <1115732642.10234.20.camel@cutter> References: <1115732642.10234.20.camel@cutter> Message-ID: On Tue, 10 May 2005, seth vidal wrote: > > I assume that's just a transient build system problem? If so, will it > > automatically retry, or do I need to resubmit the build request? > > > > read the list from this morning. Okay, finally found it. It was posted to fedora-maintainers (which I'm not on yet) but not to here For anyone else who's wondering: > if the entry is still in the 'tobuild' file then don't restart it. Okay, thanks later, chris From katzj at redhat.com Tue May 10 15:28:31 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 10 May 2005 11:28:31 -0400 Subject: dist tags, build targets, and sparcs! In-Reply-To: References: <1115667564.3017.92.camel@localhost.localdomain> <1115667762.3017.94.camel@localhost.localdomain> <1115668586.21984.45.camel@ignacio.ignacio.lan> <1115673273.9762.76.camel@bree.local.net> Message-ID: <1115738912.23130.34.camel@bree.local.net> On Tue, 2005-05-10 at 08:23 -0400, Chris Ricker wrote: > On Mon, 9 May 2005, Jeremy Katz wrote: > > This is supposed to work. And with the tweak I just made, it should > > again. Thanks for the catch. > > Good deal, thanks! > > Doing this [snip] > now works. If I then do > > $ make build > > that fails -- just does > > [kaboom at urd xdaliclock]$ make build > [kaboom at urd xdaliclock]$ Hrmm, this looks like it works for me. I changed the actual commit of tobuild in Makefile.common to be an echo, but everything came out looking right. Any chance you can add some echos in the makefile to see where things are going wrong? Jeremy From bugs.michael at gmx.net Tue May 10 16:02:40 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 10 May 2005 18:02:40 +0200 Subject: dist tags, build targets, and sparcs! In-Reply-To: References: <1115667564.3017.92.camel@localhost.localdomain> <1115667762.3017.94.camel@localhost.localdomain> <1115668586.21984.45.camel@ignacio.ignacio.lan> <1115673273.9762.76.camel@bree.local.net> Message-ID: <20050510180240.6c1eb0ae.bugs.michael@gmx.net> On Tue, 10 May 2005 08:23:59 -0400 (EDT), Chris Ricker wrote: > On Mon, 9 May 2005, Jeremy Katz wrote: > > > This is supposed to work. And with the tweak I just made, it should > > again. Thanks for the catch. > > Good deal, thanks! > > Doing this > > $ mkdir foo > $ cd foo > $ cvs co FC-3 > $ cd FC-3/xdaliclock > $ make tag > > now works. If I then do > > $ make build > > that fails -- just does > > [kaboom at urd xdaliclock]$ make build > [kaboom at urd xdaliclock]$ I got similar misbehaviour early this morning. It looked like this: cvs co mod1 mod2 mod3 mod4 cd mod1/devel make build cd ../../mod2/devel make build [and so on] The first make build worked, and I got the usual output and syncmail message. The next two make builds did return without any output. The fourth make build did work again. That's why my build requests were not in order, i.e. not sorted alphabetically as I processed them. For my retry, I did "cvs up" in "common" for the two modules which had failed earlier. -- Fedora Core release 3.91 (Pre-FC4) - Linux 2.6.11-1.1287_FC4 loadavg: 2.50 2.29 2.22 From jfontain at free.fr Tue May 10 16:45:28 2005 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Tue, 10 May 2005 18:45:28 +0200 Subject: how to detect 64 bit architecture in rpm spec? In-Reply-To: <1115734026.12631.20.camel@localhost.localdomain> References: <1115732736.4280bb00b2f6e@imp1-q.free.fr> <1115734026.12631.20.camel@localhost.localdomain> Message-ID: <4280E528.2060303@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Dennis wrote: > On Tue, 2005-05-10 at 15:45 +0200, jfontain at free.fr wrote: > >> What is the best way to test that the architecture is 64 bit >> based? %ifarch? >> >> PS: I need that because a bug was fixed in Tcl 8.4.8 on 64 bit >> machines and I need to require that version on such >> architectures. > > > I would suggest you just require Tcl >= 8.4.8 and not try to > conditionalize on the arch, its cleaner and less error prone. OK. Thanks. - -- Jean-Luc Fontaine http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCgOUokG/MMvcT1qQRAh6hAJ9Wgaex7DfV3PpWcPLzo4zTrakzEwCeN6Ba kUHPOUA3d2zn/hhEb5hRh1k= =lvpF -----END PGP SIGNATURE----- From kaboom at oobleck.net Tue May 10 20:04:07 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 10 May 2005 16:04:07 -0400 (EDT) Subject: dist tags, build targets, and sparcs! In-Reply-To: <1115738912.23130.34.camel@bree.local.net> References: <1115667564.3017.92.camel@localhost.localdomain> <1115667762.3017.94.camel@localhost.localdomain> <1115668586.21984.45.camel@ignacio.ignacio.lan> <1115673273.9762.76.camel@bree.local.net> <1115738912.23130.34.camel@bree.local.net> Message-ID: On Tue, 10 May 2005, Jeremy Katz wrote: > > [kaboom at urd xdaliclock]$ make build > > [kaboom at urd xdaliclock]$ > > Hrmm, this looks like it works for me. I changed the actual commit of > tobuild in Makefile.common to be an echo, but everything came out > looking right. > > Any chance you can add some echos in the makefile to see where things > are going wrong? It looks like it's working now. I've been doing some playing around with checkouts of the full FC-3 tree and I can't get the make builds for individual packages to fail anymore.... later, chris From ivazquez at ivazquez.net Tue May 10 20:17:24 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 10 May 2005 16:17:24 -0400 Subject: dist tags, build targets, and sparcs! In-Reply-To: References: <1115667564.3017.92.camel@localhost.localdomain> <1115667762.3017.94.camel@localhost.localdomain> <1115668586.21984.45.camel@ignacio.ignacio.lan> <1115673273.9762.76.camel@bree.local.net> <1115738912.23130.34.camel@bree.local.net> Message-ID: <1115756244.21984.69.camel@ignacio.ignacio.lan> On Tue, 2005-05-10 at 16:04 -0400, Chris Ricker wrote: > On Tue, 10 May 2005, Jeremy Katz wrote: > > > > [kaboom at urd xdaliclock]$ make build > > > [kaboom at urd xdaliclock]$ > > > > Hrmm, this looks like it works for me. I changed the actual commit of > > tobuild in Makefile.common to be an echo, but everything came out > > looking right. > > > > Any chance you can add some echos in the makefile to see where things > > are going wrong? > > It looks like it's working now. I've been doing some playing around with > checkouts of the full FC-3 tree and I can't get the make builds for > individual packages to fail anymore.... And I've supplied a patch that should hopefully allow the disttags to be handled properly by the buildsystem as well. With any luck they'll be in soon enough. -- 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 smooge at gmail.com Tue May 10 23:48:57 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Tue, 10 May 2005 17:48:57 -0600 Subject: Epoch + snort sponser In-Reply-To: <1115701804.25390.7.camel@plasma.starken.com> References: <1115701804.25390.7.camel@plasma.starken.com> Message-ID: <80d7e409050510164830c08c2a@mail.gmail.com> On 5/9/05, Daniel Wittenberg wrote: > The new snort RPM's are about ready, but am wondering about stripping > the Epoch out. I've noticed when I build RPM's without the Epoch then I > can't simply 'rpm -Fvh' the rpm, it doesn't see it as an upgrade. If I > put the Epoch back in the spec then it'll update just fine. > > Ideas on how to safely get rid of the Epoch? Or am I just stuck with it > there forever? > > Since snort is about ready to roll out the new version + new RPM's I'd > like to see if we can get it in Extras now if someone wants to help... > I am interested in helping. I have been building the snort.org.spec files for a bit for our use, and would know most its workings. However.. havent done the QA process here yet. -- Stephen J Smoogen. CSIRT/Linux System Administrator From daniel-wittenberg at starken.com Wed May 11 00:55:04 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Tue, 10 May 2005 19:55:04 -0500 Subject: Epoch + snort sponser In-Reply-To: <80d7e409050510164830c08c2a@mail.gmail.com> References: <1115701804.25390.7.camel@plasma.starken.com> <80d7e409050510164830c08c2a@mail.gmail.com> Message-ID: <1115772905.5219.0.camel@localhost.localdomain> On Tue, 2005-05-10 at 17:48 -0600, Stephen J. Smoogen wrote: > > I am interested in helping. I have been building the snort.org.spec > files for a bit for our use, and would know most its workings. > However.. havent done the QA process here yet. I'm basically going to freeze the spec file tonight for the 2.4 rollout, but if you see anything or have other ideas let me know and we can put them in. Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora-extras-list at six-by-nine.com.au Wed May 11 05:08:52 2005 From: fedora-extras-list at six-by-nine.com.au (Peter Lawler) Date: Wed, 11 May 2005 15:08:52 +1000 Subject: Celestia and Stellarirum for Extras Message-ID: <42819364.1070607@six-by-nine.com.au> Hi! I'm offering to maintain/keep an eye on Celestia and Stellarium for Extras. I also have a view to other project for extras (see below). The current RPM version for FC3 is 1.3.2, and the current Celestia is 1.3.2. I've taken a look at the patch that the FC3 version ships with, and there's been no release from the Celestia team since 1.3.2, so I really can't think of anything I can do there to help. With regards to Stellarium, the same situation applies (however with their version at 0.6.2). I mentioned in #fedora-extras that merely re-building them would be a bit cheap for me, as it would not demonstrate I understand the packaging process. I'll just have to hedge my bets that trying to get Freejay/Veejay/Rosegarden happening on FC4test will be a little more useful for demonstrating my appreciation for the rules. Regards, Pete. From bugs.michael at gmx.net Wed May 11 07:29:52 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 11 May 2005 09:29:52 +0200 Subject: build time-out errors In-Reply-To: <1115757021.10234.102.camel@cutter> References: <200505101802.j4AI25Co029748@cvs-int.fedora.redhat.com> <20050510180840.GA29009@lisas.de> <20050510203150.3e3db280.bugs.michael@gmx.net> <42810B0F.2080506@ieee.org> <20050510215155.3eb7346b.bugs.michael@gmx.net> <1115755082.10234.96.camel@cutter> <428118CA.6080907@ieee.org> <1115757021.10234.102.camel@cutter> Message-ID: <20050511092952.468b9e5d.bugs.michael@gmx.net> On Tue, 10 May 2005 16:30:21 -0400, seth vidal wrote: > does octave time out EVERY time? > > if so then I'd like to use it to test some things. gnupg2 timed out on x86_64 (where I wanted to get the log) and on i386. Is it possible to resubmit the same tag into the queue? From skvidal at phy.duke.edu Wed May 11 07:33:59 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 11 May 2005 03:33:59 -0400 Subject: build time-out errors In-Reply-To: <20050511092952.468b9e5d.bugs.michael@gmx.net> References: <200505101802.j4AI25Co029748@cvs-int.fedora.redhat.com> <20050510180840.GA29009@lisas.de> <20050510203150.3e3db280.bugs.michael@gmx.net> <42810B0F.2080506@ieee.org> <20050510215155.3eb7346b.bugs.michael@gmx.net> <1115755082.10234.96.camel@cutter> <428118CA.6080907@ieee.org> <1115757021.10234.102.camel@cutter> <20050511092952.468b9e5d.bugs.michael@gmx.net> Message-ID: <1115796840.10234.138.camel@cutter> On Wed, 2005-05-11 at 09:29 +0200, Michael Schwendt wrote: > On Tue, 10 May 2005 16:30:21 -0400, seth vidal wrote: > > > does octave time out EVERY time? > > > > if so then I'd like to use it to test some things. > > gnupg2 timed out on x86_64 (where I wanted to get the log) and on i386. > > Is it possible to resubmit the same tag into the queue? yes, but I have to restart the queuer. It doesn't have any way of distinguishing b/t new jobs and duplicate submissions. Also I know why we've been getting timeouts a lot today. The mirror we use for populating the buildroots is busy b/c of test3 releases. Hence, pain. -sv From bugs.michael at gmx.net Wed May 11 07:51:04 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 11 May 2005 09:51:04 +0200 Subject: build time-out errors In-Reply-To: <1115796840.10234.138.camel@cutter> References: <200505101802.j4AI25Co029748@cvs-int.fedora.redhat.com> <20050510180840.GA29009@lisas.de> <20050510203150.3e3db280.bugs.michael@gmx.net> <42810B0F.2080506@ieee.org> <20050510215155.3eb7346b.bugs.michael@gmx.net> <1115755082.10234.96.camel@cutter> <428118CA.6080907@ieee.org> <1115757021.10234.102.camel@cutter> <20050511092952.468b9e5d.bugs.michael@gmx.net> <1115796840.10234.138.camel@cutter> Message-ID: <20050511095104.76dcce20.bugs.michael@gmx.net> On Wed, 11 May 2005 03:33:59 -0400, seth vidal wrote: > On Wed, 2005-05-11 at 09:29 +0200, Michael Schwendt wrote: > > On Tue, 10 May 2005 16:30:21 -0400, seth vidal wrote: > > > > > does octave time out EVERY time? > > > > > > if so then I'd like to use it to test some things. > > > > gnupg2 timed out on x86_64 (where I wanted to get the log) and on i386. > > > > Is it possible to resubmit the same tag into the queue? > > yes, but I have to restart the queuer. It doesn't have any way of > distinguishing b/t new jobs and duplicate submissions. > > Also I know why we've been getting timeouts a lot today. The mirror we > use for populating the buildroots is busy b/c of test3 releases. Hence, > pain. What does that mean? Bumping release and trying another rebuild is unlikely to finish either? I mean, it's good to know the cause of the time-outs, but it doesn't help us. From skvidal at phy.duke.edu Wed May 11 07:53:55 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 11 May 2005 03:53:55 -0400 Subject: build time-out errors In-Reply-To: <20050511095104.76dcce20.bugs.michael@gmx.net> References: <200505101802.j4AI25Co029748@cvs-int.fedora.redhat.com> <20050510180840.GA29009@lisas.de> <20050510203150.3e3db280.bugs.michael@gmx.net> <42810B0F.2080506@ieee.org> <20050510215155.3eb7346b.bugs.michael@gmx.net> <1115755082.10234.96.camel@cutter> <428118CA.6080907@ieee.org> <1115757021.10234.102.camel@cutter> <20050511092952.468b9e5d.bugs.michael@gmx.net> <1115796840.10234.138.camel@cutter> <20050511095104.76dcce20.bugs.michael@gmx.net> Message-ID: <1115798035.10234.154.camel@cutter> > What does that mean? Bumping release and trying another rebuild is > unlikely to finish either? > > I mean, it's good to know the cause of the time-outs, but it doesn't > help us. It means that right now the buildsystem is hampered by the realities of resources available to us. I'm going to be changing out two parts of the buildsys automation code tomorrow as a test for one of the timeout problems. I'll raise the time out to 3 hours at that time. -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed May 11 09:51:26 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 11 May 2005 11:51:26 +0200 Subject: build time-out errors In-Reply-To: <1115796840.10234.138.camel@cutter> References: <200505101802.j4AI25Co029748@cvs-int.fedora.redhat.com> <20050510180840.GA29009@lisas.de> <20050510203150.3e3db280.bugs.michael@gmx.net> <42810B0F.2080506@ieee.org> <20050510215155.3eb7346b.bugs.michael@gmx.net> <1115755082.10234.96.camel@cutter> <428118CA.6080907@ieee.org> <1115757021.10234.102.camel@cutter> <20050511092952.468b9e5d.bugs.michael@gmx.net> <1115796840.10234.138.camel@cutter> Message-ID: <20050511115126.0c355402@python2> seth vidal wrote : > Also I know why we've been getting timeouts a lot today. The mirror we > use for populating the buildroots is busy b/c of test3 releases. Hence, > pain. Wouldn't it be easier to sync (hourly for instance) locally on the build machines the files required for populating the build roots? It only means a few GBs per distribution, and could avoid these kind of problems. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.20_FC3 Load : 1.25 0.47 0.47 From mfleming at enlartenment.com Wed May 11 10:00:31 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Wed, 11 May 2005 20:00:31 +1000 Subject: New package for consideration - mod_security Message-ID: <20050511200031.70fff86b.mfleming@enlartenment.com> Hi, Would anyone be interested in looking over a package for mod_security (http://www.modsecurity.org/) that I have put together? >From the website blurb: "ModSecurity is an open source intrusion detection and prevention engine for web applications (or a web application firewall). Operating as an Apache Web server module or standalone, the purpose of ModSecurity is to increase web application security, protecting web applications from known and unknown attacks." It (the app, not necessarily my package - yet) is fairly well put together and I think an extra security module for Apache in Fedora would be useful. SRPM: http://www.enlartenment.com/extras/mod_security-1.8.7-4.fc3.mf.src.rpm Spec and extra sources (a simple example config file) for it in http://www.enlartenment.com/extras/ The site it's sitting on has been running with it for a couple of months now, so it /should/ be stable :-) Comments and experiences with it welcomed. Cheers, Michael (hoping that this will generate more interest than my last package submission :-P) -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From bugs.michael at gmx.net Wed May 11 11:58:06 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 11 May 2005 13:58:06 +0200 Subject: Questions [moved from fedora-extras-commits list] In-Reply-To: <4281D2AA.6010603@city-fan.org> References: <200505110837.j4B8bYdV019175@cvs-int.fedora.redhat.com> <20050511111233.413b22bd.bugs.michael@gmx.net> <4281CEBB.6050801@city-fan.org> <20050511113017.4324d148.bugs.michael@gmx.net> <4281D2AA.6010603@city-fan.org> Message-ID: <20050511135806.3eeb321f.bugs.michael@gmx.net> On Wed, 11 May 2005 10:38:50 +0100, Paul Howarth wrote: > So, if I wanted to do a build for FC-2, how would > I go about it? Just don't look back. Concentrate on FC3 and newer. ;) Old fedora.us infrastructure is only kept alive for errata support, provided that a packager still supports FC2 and older. > And why does the current Extras build system even support > branches for FC-2 and even older releases? Because as many src.rpms as possible were imported. And because keeping the packages in CVS has made it easier for the fedora.us people to prepare the occasional update for FC2 and older. Early CVS activity also resulted in early testing [of import scripts, Makefile.common e.g.]. -- Fedora Core release 3.91 (Pre-FC4) - Linux 2.6.11-1.1287_FC4 loadavg: 1.00 1.05 1.09 From dennis at ausil.us Wed May 11 00:19:06 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 10 May 2005 19:19:06 -0500 Subject: dist tags, build targets, and sparcs! In-Reply-To: <1115667564.3017.92.camel@localhost.localdomain> References: <1115667564.3017.92.camel@localhost.localdomain> Message-ID: <200505101919.11815.dennis@ausil.us> Once upon a time Monday 09 May 2005 2:39 pm, Tom 'spot' Callaway wrote: > Thanks to the fine work of Ignacio Vazquez-Abrams and Jeremy Katz, we've > got some more of this tricky packaging stuff figured out. > > 3. sparcs > > No, not yet. Just seeing if anyone reads this far. :) > > ~spot hmm sparcs, Just say when. What are the chances of getting a sparc build of FC? I have a couple of test machines and am willing to help out wherever i can. -- Dennis Gilmore RHCE http://www.ausil.us -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ivazquez at ivazquez.net Wed May 11 16:00:09 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 11 May 2005 12:00:09 -0400 Subject: Request for review: pyparsing Message-ID: <1115827209.21984.91.camel@ignacio.ignacio.lan> pyparsing: An object-oriented approach to text processing pyparsing is a module that can be used to easily and directly configure syntax definitions for any number of text parsing applications. http://pyparsing.sourceforge.net/ http://fedora.ivazquez.net/files/pyparsing-1.3-1.src.rpm -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From smooge at gmail.com Wed May 11 16:49:00 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 11 May 2005 10:49:00 -0600 Subject: Epoch + snort sponser In-Reply-To: <1115772905.5219.0.camel@localhost.localdomain> References: <1115701804.25390.7.camel@plasma.starken.com> <80d7e409050510164830c08c2a@mail.gmail.com> <1115772905.5219.0.camel@localhost.localdomain> Message-ID: <80d7e409050511094976e46cb2@mail.gmail.com> The one big thing I think that looking at the other fedora extras is that switches are frowned on in the auto-build system. I am thinking that for fedora a lot of the entries should be 1 versus 0 %define flexresp 1 %define mysql 1 %define postgresql 1 similar to how the caos one is done. I wonder if there is a %undefine RPM command.. as that would allow for the spec to cover the items that arent to be defined for Extras rpms (vendor, distro). On 5/10/05, Daniel Wittenberg wrote: > On Tue, 2005-05-10 at 17:48 -0600, Stephen J. Smoogen wrote: > > > > I am interested in helping. I have been building the snort.org.spec > > files for a bit for our use, and would know most its workings. > > However.. havent done the QA process here yet. > > I'm basically going to freeze the spec file tonight for the 2.4 rollout, > but if you see anything or have other ideas let me know and we can put > them in. > > Dan > > > BodyID:246010048.2.n.logpart (stored separately) > > -- Stephen J Smoogen. CSIRT/Linux System Administrator From dennis at ausil.us Wed May 11 18:06:48 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 11 May 2005 13:06:48 -0500 Subject: dist tags, build targets, and sparcs! In-Reply-To: <1115667564.3017.92.camel@localhost.localdomain> References: <1115667564.3017.92.camel@localhost.localdomain> Message-ID: <200505111306.57104.dennis@ausil.us> Once upon a time Monday 09 May 2005 2:39 pm, Tom 'spot' Callaway wrote: > Thanks to the fine work of Ignacio Vazquez-Abrams and Jeremy Katz, we've > got some more of this tricky packaging stuff figured out. > > 3. sparcs > > No, not yet. Just seeing if anyone reads this far. :) > > ~spot hmm sparcs, Just say when. What are the chances of getting a sparc build of FC? I have a couple of test machines and am willing to help out wherever i can. -- Dennis Gilmore RHCE http://www.ausil.us -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kaboom at oobleck.net Wed May 11 19:45:34 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Wed, 11 May 2005 15:45:34 -0400 (EDT) Subject: request for review: fping Message-ID: Anyone like to review / approve fping's essentially a scriptable parallelized ICMP echo-based ping. It's needed by hobbit.... thanks, chris From kaboom at oobleck.net Wed May 11 19:47:01 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Wed, 11 May 2005 15:47:01 -0400 (EDT) Subject: request for review: hobbit Message-ID: Anyone interested in reviewing hobbit? hobbit's a GPL'ed replacement for the server component of Big Brother. It works with the Big Brother client (non-free), or with the free hobbit clients which are under development, to monitor server / application / network / etc. status It's a complex web app, with all the usual suckiness-to-package which that implies, so be brutal :-) Also, hobbit BuildRequires fping, which I've also posted for review thanks, chris From qspencer at ieee.org Wed May 11 20:02:52 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Wed, 11 May 2005 15:02:52 -0500 Subject: Reviews Needed: cln, GiNaC In-Reply-To: <20050511115126.0c355402@python2> References: <200505101802.j4AI25Co029748@cvs-int.fedora.redhat.com> <20050510180840.GA29009@lisas.de> <20050510203150.3e3db280.bugs.michael@gmx.net> <42810B0F.2080506@ieee.org> <20050510215155.3eb7346b.bugs.michael@gmx.net> <1115755082.10234.96.camel@cutter> <428118CA.6080907@ieee.org> <1115757021.10234.102.camel@cutter> <20050511092952.468b9e5d.bugs.michael@gmx.net> <1115796840.10234.138.camel@cutter> <20050511115126.0c355402@python2> Message-ID: <428264EC.8050007@ieee.org> These two packages are in CVS and need final approval. The cln library is used by GiNaC. The best way to test these two packages is to build them both and then run ginsh from the GiNaC-utils package. cln (Class Library for Numbers): A collection of C++ math classes and functions, which are designed for memory and speed efficiency, and enable type safety and algebraic syntax. GiNaC GiNaC (which stands for "GiNaC is Not a CAS (Computer Algebra System)") is an open framework for symbolic computation within the C++ programming language. This package includes ginsh ("GiNaC interactive shell") which provides a simple and easy-to-use CAS-like interface to GiNaC for non-programmers, and the tool "viewgar" which displays the contents of GiNaC archives. From mpeters at mac.com Wed May 11 21:26:34 2005 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 11 May 2005 14:26:34 -0700 Subject: request for review: hobbit In-Reply-To: References: Message-ID: <1115846794.3251.17.camel@laptop.mpeters.local> On Wed, 2005-05-11 at 15:47 -0400, Chris Ricker wrote: > Anyone interested in reviewing hobbit? > > > > hobbit's a GPL'ed replacement for the server component of Big Brother. It > works with the Big Brother client (non-free), or with the free > hobbit clients which are under development, to monitor server / > application / network / etc. status Just a note - a company I used to work for had a webapp server that we wanted to call Gandalf, but the lawyers wouldn't let us because apparently the Tolkein family was legal happy or something. I don't know if hobbit would have the same issue, were hobbits something Tolkein took from lore, or is the name his invention? From smooge at gmail.com Wed May 11 21:56:15 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 11 May 2005 15:56:15 -0600 Subject: request for review: hobbit In-Reply-To: <1115846794.3251.17.camel@laptop.mpeters.local> References: <1115846794.3251.17.camel@laptop.mpeters.local> Message-ID: <80d7e409050511145656bb7eb8@mail.gmail.com> On 5/11/05, Michael A. Peters wrote: > On Wed, 2005-05-11 at 15:47 -0400, Chris Ricker wrote: > > Anyone interested in reviewing hobbit? > > > > > > > > hobbit's a GPL'ed replacement for the server component of Big Brother. It > > works with the Big Brother client (non-free), or with the free > > hobbit clients which are under development, to monitor server / > > application / network / etc. status > > Just a note - a company I used to work for had a webapp server that we > wanted to call Gandalf, but the lawyers wouldn't let us because > apparently the Tolkein family was legal happy or something. I don't know > if hobbit would have the same issue, were hobbits something Tolkein took > from lore, or is the name his invention? > hobbit's are an invention of Tolkein. They may be close enough to public domain due to the various uses in todays culture. For a while Tolkein had a lawsuit against TSR D&D for using 'magic rings'. It caused jokes about "Using a circular metal unit on my right hand that imbues invisibility" instead of ring of invisibility. > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- Stephen J Smoogen. CSIRT/Linux System Administrator From zipsonic at gmail.com Wed May 11 22:15:39 2005 From: zipsonic at gmail.com (Rick Stout) Date: Wed, 11 May 2005 15:15:39 -0700 Subject: Request for review: nx Message-ID: <4282840B.6010903@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Summary: NX provides a proxy system for the X Window System. Description: These are the GPL'd components of Nomachines X server/proxy system. They provide the backend for the GPL'd nxserver implementation - freenx. If you are unfamiliar with NX, you can find out more at: http://www.nomachine.com This package has a preliminary approval/review by Tom Callaway, and has been uploaded to cvs extras. I would appreciate additional review and feedback on this package. Regards, Rick Stout http://fedoranews.org/contributors/rick_stout/freenx/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCgoQLxbjDgrkK7nARAl3xAJsEal+7XhPGmsW0EWdv7wnFN2S9RQCfVz6N yzctVsN28uwuf4MHZBNv0xY= =1OiN -----END PGP SIGNATURE----- From zipsonic at gmail.com Wed May 11 22:22:16 2005 From: zipsonic at gmail.com (Rick Stout) Date: Wed, 11 May 2005 15:22:16 -0700 Subject: Request for review: freenx Message-ID: <42828598.3060907@gmail.com> Summary: freenx application/thin-client server Description: Freenx is an application/thin-client server based on nx technology. NoMachine nx is the next-generation X compression and roundtrip suppression scheme. It can operate remote X11 sessions over 56k modem dialup links or anything better. This package contains a free (GPL) implementation of the nxserver component. This package has a preliminary approval/review by Tom Callaway, and has been uploaded to cvs extras. I would appreciate additional review and feedback on this package. Regards, Rick Stout http://fedoranews.org/contributors/rick_stout/freenx/ From mfleming at enlartenment.com Thu May 12 01:38:41 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Thu, 12 May 2005 11:38:41 +1000 Subject: Approval needed: mlmmj In-Reply-To: <1115705512.4727.70.camel@laurel.intra.city-fan.org> References: <20050507120206.4f791a8f.mfleming@enlartenment.com> <20050507231416.45417926.mfleming@enlartenment.com> <1115475973.4296.1.camel@Madison.badger.com> <20050509203014.1725d882.mfleming@enlartenment.com> <20050509084020.A16113@tiki-lounge.com> <20050509235231.GA6609@enlartenment.com> <1115705512.4727.70.camel@laurel.intra.city-fan.org> Message-ID: <20050512013841.GA6517@enlartenment.com> On Tue, May 10, 2005 at 07:11:52AM +0100, Paul Howarth waffled thusly: > On Tue, 2005-05-10 at 09:52 +1000, Michael Fleming wrote: > > > > I used to put it in %doc (my own repo versions) however it seemed the > > resulting RPM picked up extra dependencies I didn't want, unless I > > removed execute access from those files. > > You could prevent the extra dependencies being generated by using your > own find_requires script, which calls the standard %{__find_requires} > and then [carefully] greps out the bogus dependencies. > > For example: > > %define _use_internal_dependency_generator 0 > %define my_find_requires %{_builddir}/%{name}-%{version}/find_requires > > %{__cat} <%{my_find_requires} > #! /bin/sh > exec %{__find_requires} | /bin/egrep -v '^(bogus dependency regex)$' > exit 0 > EOF > chmod +x %{my_find_requires} > %define __find_requires %{my_find_requires} > > Paul. I've decided in the interim to add the contributed files in %doc. Removing the executable bits on the .pl/.cgi files is enough to keep RPM's dependency handler from picking up the Perl deps - I'm not certain if they can all be satisfied from FC / FE RPMs alone. This I'll look into and put up any missing packages for review if necessary/desirable. The above scriptlet is helpful and might come in useful down the track if I want something a little more fine-grained. Thanks :-) Cheers, Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From byte at aeon.com.my Thu May 12 00:22:58 2005 From: byte at aeon.com.my (Colin Charles) Date: Thu, 12 May 2005 10:22:58 +1000 Subject: Review request: syslog-ng (syslog replacement daemon) In-Reply-To: <1136.213.13.86.72.1115489613.squirrel@webmail.lsd.di.uminho.pt> References: <427C0BF2.9000304@di.uminho.pt> <20050507152722.059a0444.bugs.michael@gmx.net> <1136.213.13.86.72.1115489613.squirrel@webmail.lsd.di.uminho.pt> Message-ID: <1115857378.4525.36.camel@arena.soho.bytebot.net> On Sat, 2005-05-07 at 19:13 +0100, Jose Pedro Oliveira wrote: > > PS - Is there an archive of old "Fedora Alternatives" discussion? No, we killed it at the meeting before FUDCon 1. Let's get Extras working 100% properly first -- Colin Charles, http://www.bytebot.net/ From buildsys at fedoraproject.org Thu May 12 05:09:26 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 12 May 2005 01:09:26 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050512050926.A285E8570@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 31 abicheck-1.2-6 antiword-0.36.1-2 aqhbci-qt-tools-1.0.1beta-5 blacs-1.1-8 chkrootkit-0.45-3 epylog-1.0.3-3 fbida-2.03-5 fftw3-3.0.1-3 fyre-1.0.0-6 gai-pal-0.7-6 gnome-common-2.8.0-3 gnupg2-1.9.16-2 gnupg2-1.9.16-2.fc4 gossip-0.8-3 gtorrentviewer-0.2b-5 gtranslator-1.1.5-3 imlib2-1.2.0-8.fc4 libksba-0.9.11-1 loudmouth-0.17.2-3 moodss-20.0-5 nmh-1.1-8.fc4 perl-OLE-Storage_Lite-0.14-6 perl-Spreadsheet-WriteExcel-2.13-3 pptp-1.6.0-3 proftpd-1.2.10-4 pylint-0.6.4-4 python-logilab-common-0.9.3-3 rdiff-backup-0.12.7-3 source-highlight-1.11-1 wxPythonGTK2-2.4.2.4-7 xdesktopwaves-1.3-4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From skvidal at phy.duke.edu Thu May 12 05:18:05 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 12 May 2005 01:18:05 -0400 Subject: Fedora Extras development Package Build Report In-Reply-To: <20050512050926.A285E8570@extras64.linux.duke.edu> References: <20050512050926.A285E8570@extras64.linux.duke.edu> Message-ID: <1115875085.4604.12.camel@cutter> > gnupg2-1.9.16-2 > gnupg2-1.9.16-2.fc4 This is a result of the change up using the dist tags. We've found a problem doing this but I'm working on a solution for it now. -sv From buildsys at fedoraproject.org Thu May 12 05:20:58 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 12 May 2005 01:20:58 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050512052058.6F7458570@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 13 fontforge-0.0-2.20050502.fc3 fyre-1.0.0-5 glibmm24-2.4.7-1 gstreamer-python-0.8.1-4 gtkmm24-2.4.11-1 gtorrentviewer-0.2b-5 libglademm24-2.4.2-1 moodss-20.0-4 nmh-1.1-8.fc3 perl-OLE-Storage_Lite-0.14-6 perl-Spreadsheet-WriteExcel-2.13-3 sodipodi-0.34-4 xdaliclock-2.20-2 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 Thu May 12 06:44:10 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 12 May 2005 08:44:10 +0200 Subject: Build system trouble with build requirements In-Reply-To: <20050512063130.5B1148570@extras64.linux.duke.edu> References: <20050512063130.5B1148570@extras64.linux.duke.edu> Message-ID: <20050512084410.5defd3c5.bugs.michael@gmx.net> On Thu, 12 May 2005 02:31:30 -0400 (EDT), buildsys at fedoraproject.org wrote: > > Build of sylpheed on development succeeded. > Impossible. gpgme-devel has not been built for ppc before. Build log at http://extras64.linux.duke.edu/needsign/development/sylpheed/1.0.4-2.fc4/ppc/sylpheed-1.0.4-2.fc4.rpm.log says: > checking whether to use GPGME... yes > checking for gpgme-config... no > ./configure: line 27437: no: command not found > checking for GPGME - version >= 0.4.5... no Build system is broken. Most likely it somehow failed to handle this: %{!?_without_gpgme:BuildRequires: gpgme-devel >= 1.0.0} Please don't publish the built binaries. From caillon at redhat.com Thu May 12 06:59:51 2005 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 12 May 2005 02:59:51 -0400 Subject: request for review: hobbit In-Reply-To: <80d7e409050511145656bb7eb8@mail.gmail.com> References: <1115846794.3251.17.camel@laptop.mpeters.local> <80d7e409050511145656bb7eb8@mail.gmail.com> Message-ID: <4282FEE7.5040105@redhat.com> Stephen J. Smoogen wrote: > On 5/11/05, Michael A. Peters wrote: > >>On Wed, 2005-05-11 at 15:47 -0400, Chris Ricker wrote: >> >>>Anyone interested in reviewing hobbit? >>> >>> >>> >>>hobbit's a GPL'ed replacement for the server component of Big Brother. It >>>works with the Big Brother client (non-free), or with the free >>>hobbit clients which are under development, to monitor server / >>>application / network / etc. status >> >>Just a note - a company I used to work for had a webapp server that we >>wanted to call Gandalf, but the lawyers wouldn't let us because >>apparently the Tolkein family was legal happy or something. I don't know >>if hobbit would have the same issue, were hobbits something Tolkein took >>from lore, or is the name his invention? >> > > > hobbit's are an invention of Tolkein. They may be close enough to > public domain due to the various uses in todays culture. For a while > Tolkein had a lawsuit against TSR D&D for using 'magic rings'. It > caused jokes about "Using a circular metal unit on my right hand that > imbues invisibility" instead of ring of invisibility. His name is spelled Tolkien. -- Christopher Aillon Middle Earth Historian From skvidal at phy.duke.edu Thu May 12 07:01:17 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 12 May 2005 03:01:17 -0400 Subject: request for review: hobbit In-Reply-To: <4282FEE7.5040105@redhat.com> References: <1115846794.3251.17.camel@laptop.mpeters.local> <80d7e409050511145656bb7eb8@mail.gmail.com> <4282FEE7.5040105@redhat.com> Message-ID: <1115881277.4604.26.camel@cutter> > > hobbit's are an invention of Tolkein. They may be close enough to > > public domain due to the various uses in todays culture. For a while > > Tolkein had a lawsuit against TSR D&D for using 'magic rings'. It > > caused jokes about "Using a circular metal unit on my right hand that > > imbues invisibility" instead of ring of invisibility. > > His name is spelled Tolkien. His body is rotting in the ground, I doubt he gives a damn. :-D -sv From bugs.michael at gmx.net Thu May 12 07:31:23 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 12 May 2005 09:31:23 +0200 Subject: Build system trouble with build requirements In-Reply-To: <20050512084410.5defd3c5.bugs.michael@gmx.net> References: <20050512063130.5B1148570@extras64.linux.duke.edu> <20050512084410.5defd3c5.bugs.michael@gmx.net> Message-ID: <20050512093123.0f9392a2.bugs.michael@gmx.net> On Thu, 12 May 2005 08:44:10 +0200, Michael Schwendt wrote: > > Build of sylpheed on development succeeded. > > > > Impossible. gpgme-devel has not been built for ppc before. > > Build log at > > http://extras64.linux.duke.edu/needsign/development/sylpheed/1.0.4-2.fc4/ppc/sylpheed-1.0.4-2.fc4.rpm.log > > says: > > > checking whether to use GPGME... yes > > checking for gpgme-config... no > > ./configure: line 27437: no: command not found > > checking for GPGME - version >= 0.4.5... no > > Build system is broken. Most likely it somehow failed to handle this: > > %{!?_without_gpgme:BuildRequires: gpgme-devel >= 1.0.0} > > > Please don't publish the built binaries. And whoever looks into this, be aware that the gpgme build request completed and only a moment ago put the built packages into "needsign", so only NOW they are available to the build system. They were not available when above ppc build was done. From rc040203 at freenet.de Thu May 12 07:31:40 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 12 May 2005 09:31:40 +0200 Subject: Build system trouble with build requirements In-Reply-To: <20050512084410.5defd3c5.bugs.michael@gmx.net> References: <20050512063130.5B1148570@extras64.linux.duke.edu> <20050512084410.5defd3c5.bugs.michael@gmx.net> Message-ID: <1115883100.8237.365.camel@mccallum.corsepiu.local> On Thu, 2005-05-12 at 08:44 +0200, Michael Schwendt wrote: > On Thu, 12 May 2005 02:31:30 -0400 (EDT), buildsys at fedoraproject.org wrote: > > > > > Build of sylpheed on development succeeded. > > > > Impossible. gpgme-devel has not been built for ppc before. > > Build log at > > http://extras64.linux.duke.edu/needsign/development/sylpheed/1.0.4-2.fc4/ppc/sylpheed-1.0.4-2.fc4.rpm.log > > says: > > > checking whether to use GPGME... yes > > checking for gpgme-config... no > > ./configure: line 27437: no: command not found BTW: This message indicates a broken configure script. Ralf From toni at willberg.fi Thu May 12 08:44:08 2005 From: toni at willberg.fi (Toni Willberg) Date: Thu, 12 May 2005 11:44:08 +0300 Subject: I plan to add bitlbee to extras Message-ID: <1115887448.25813.22.camel@l1503819> Bitlbee is a irc to {ICQ, MSN, Jabber, ...} gateway. There are Dag's packages already, so it looks easy to convert them to Fedora Extras packages. I just wanted to ask if anyone else had already thought about this to avoid duplicate work. I'm planning to do the work some day in near future unless someone has objections. (Tom sponsored my CVS account, Cc:ing him.) - Toni ps. http://www.bitlbee.org/main.php/intro.html From petersen at redhat.com Thu May 12 08:46:26 2005 From: petersen at redhat.com (Jens Petersen) Date: Thu, 12 May 2005 17:46:26 +0900 Subject: Need review: ghc Message-ID: <428317E2.4030107@redhat.com> GHC (Glasgow Haskell Compiler) is the most widely used compiler for the functional programming language Haskell: see . [For earlier discussion see: https://www.redhat.com/archives/fedora-extras-list/2005-February/msg00387.html ] After more work, ghc-6.4 is now finally ready for inclusion in Extras, I believe. :-) Since the source tarball is a bit big I took the liberty of importing ghc-6.4-8 into extras cvs - so it can be easily reviewed. Currently ghc-6.4 doesn't build yet with gcc4 so perhaps it is best just to target FC-3 for now? gcc4 support should hopefully come in the next upstream release if the changes required are not too major, otherwise ghc builds fine with compat-gcc-32 for now, though I gather using that is currently frowned upon for Extras FC-4? After reviewing, the remaining issue is just bootstrapping because ghc-6.4-8 requires ghc64 (its main subpackage) to build. Generating (arch dependent) bootstrap tarballs of C files with ghc would depend on ghc anyway so the recommended way to buildstrap ghc in buildroots is using such a pre-built binary package: indeed the Debian maintainer tells me this is also the way new archs are bootstrapped for debian. Signed binary packages for Fedora Core i386, ppc and x86_64 are available from Fedora Haskell : http://haskell.org/fedora/haskell/3/i386/RPMS.stable/ghc64-6.4-7.i386.rpm http://haskell.org/fedora/haskell/3/ppc/RPMS.stable/ghc64-6.4-1.ppc.rpm http://haskell.org/fedora/haskell/3/x86_64/RPMS.stable/ghc64-6.4-7.x86_64.rpm and can be used for the initial builds. I have waited a long time for this moment but hopefully soon we can finally have Haskell supported in Extras and add darcs and other goodies to Extras. :-) Jens From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu May 12 09:39:52 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 12 May 2005 11:39:52 +0200 Subject: request for review: fping In-Reply-To: References: Message-ID: <20050512113952.3c26676f@python2> Chris Ricker wrote : > Anyone like to review / approve > > > > fping's essentially a scriptable parallelized ICMP echo-based ping. It's > needed by hobbit.... Find attached a patch for some quick suggested changes, of which : - Drop the silly buildroot != / from %clean - Simplify the weird doc installation (did you do that??) - Don't strip the fping6 binary on install to get useful debuginfo If you apply at least the above 3 changes from the patch, I approve the package :-) (compilation and functionality tested too on i386) Actually, I've just noticed that the "fping6" binary included in the binary package doesn't get stripped automatically, whereas the main "fping" does. Strange. Could it be that both binaries share debug symbols etc.? Wondering if it could have been caused by the suid bit, I've looked at /bin/su on FC3... and it's not stripped either. Confusing :-) Maybe the explicit stripping of "fping6" should stay then, if the debug symbols extracted from "fping" are sufficient for both. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.20_FC3 Load : 1.26 0.58 0.35 -------------- next part -------------- A non-text attachment was scrubbed... Name: fping.spec.patch Type: application/octet-stream Size: 1254 bytes Desc: not available URL: From tian at c-sait.net Thu May 12 09:55:40 2005 From: tian at c-sait.net (tian at c-sait.net) Date: Thu, 12 May 2005 11:55:40 +0200 (CEST) Subject: install versus cp -a in %install Message-ID: <21262.62.210.124.226.1115891740.squirrel@62.210.124.226> Hello, There was a question about this topic in one of my previous mails. But it could have gone unoticed because there was a lot of other information in it ;) https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00374.html So the question is about the use of install program in %install section of a .spec to copy files. Is that better to use it instead of a more simple 'cp -a' A major drawback of install is that it doesn't have recursive mode. And its only advantage, from my point of view, is that it is possible to specify some permissions and ownerships. But as this last operation is performed in the %files section, I think there is no need to use this feature. Am I missing something there? If there is no advantages using install, I will be able to do a more concise and clean .spec file. Thanks a lot for your help. Tian. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu May 12 10:56:05 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 12 May 2005 12:56:05 +0200 Subject: request for review: hobbit In-Reply-To: <1115881277.4604.26.camel@cutter> References: <1115846794.3251.17.camel@laptop.mpeters.local> <80d7e409050511145656bb7eb8@mail.gmail.com> <4282FEE7.5040105@redhat.com> <1115881277.4604.26.camel@cutter> Message-ID: <20050512125605.753c2dca@python2> I've been looking at this package a little, since I've used bigbrother quite a bit, and really like the explanation for the name :-) "Why did you call it Hobbit ? Choosing a name is hard. I wanted a name that was easy to remember; could be interpreted as a somewhat meaningful acronym; and one that did not refer directly to the Big Brother origin. "Hobbit" could mean "High- performance Open-source BB ImplemenTation" but it might as well just be a name. If you're familiar with the Hobbit's in Tolkien's books, you will know that hobbits are very fond of things that are green - just like any systems- or network-administrator prefers his monitoring screen to be. They also pay a great deal of attention to what is happening around them, and are capable of doing things that you would not think they could when you first saw them. All of these characteristics apply well to the Hobbit monitor." Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.20_FC3 Load : 0.28 0.24 0.32 From ndbecker2 at gmail.com Thu May 12 11:42:30 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 12 May 2005 07:42:30 -0400 Subject: Request for review: nx References: <4282840B.6010903@gmail.com> Message-ID: Rick Stout wrote: [...] Description: > These are the GPL'd components of Nomachines X server/proxy system. They > provide the backend for the GPL'd nxserver implementation - freenx. If > you are unfamiliar with NX, you can find out more at: > > http://www.nomachine.com > > This package has a preliminary approval/review by Tom Callaway, and has > been uploaded to cvs extras. I would appreciate additional review and > feedback on this package. > Does this build on x86_64? Last time I tried it didn't. From qspencer at ieee.org Thu May 12 13:05:45 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 12 May 2005 08:05:45 -0500 Subject: Errors on x86_64 (broken c++ headers?) Message-ID: <428354A9.5040501@ieee.org> I resubmitted octave to be built yesterday, with more odd results. Everything looks fine for PPC, but for i386, the build appears to have completed, but there is still a failure.log file that says "Build process terminated by timeout". For x86_64, the build failed. Looking at the log file, there are a whole lot of errors that look something like this: g++ -c -fPIC -I. -I../.. -I../../liboctave -I../../src -I../../libcruft/misc -DHAVE_CONFIG_H -Wall -W -Wshadow -Wcast-align -Wcast-qual -Wpointer-arith -Wwrite-strings -Weffc++ -g -O2 quit.cc -o pic/quit.o In file included from quit.cc:30: /usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../include/c++/4.0.0/iostream:43:28: error: bits/c++config.h: No such file or directory In file included from /usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../include/c++/4.0.0/ios:43, from /usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../include/c++/4.0.0/ostream:44, from /usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../include/c++/4.0.0/iostream:44, from quit.cc:30: So, the errors appear to be caused by the c++ header files. How is it possible that the header files are broken on one arch and not another? Any other insights into what might have caused this and how to fix it? -Quentin From Jochen at herr-schmitt.de Thu May 12 14:18:37 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 12 May 2005 16:18:37 +0200 Subject: Request for Review: monotone In-Reply-To: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> References: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> Message-ID: <0MKwtQ-1DWEWM0tBu-0006up@mrelayeu.kundenserver.de> On Wed, 13 Apr 2005 15:10:09 -0500, you wrote: >(probably something related to gcc4). If anyone can get monotone >compiling on FC4 I'd appreciate it if you'd let me know. I have found that monotone-0.19 was relased. So I have downloaded the new release and make a build on the base of your Source-RPM with a gcc4. I can report, that the build was success and I was able to pull the monotone database in a test run. Becouse sqlite is part of FC4, we should examinate, if we can say '--with-bundled-sqllite3=no' in the configure script. Best Regards: Jochen Schmitt From pmatilai at welho.com Thu May 12 14:22:00 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 12 May 2005 17:22:00 +0300 (EEST) Subject: Errors on x86_64 (broken c++ headers?) In-Reply-To: <428354A9.5040501@ieee.org> References: <428354A9.5040501@ieee.org> Message-ID: On Thu, 12 May 2005, Quentin Spencer wrote: > I resubmitted octave to be built yesterday, with more odd results. Everything > looks fine for PPC, but for i386, the build appears to have completed, but > there is still a failure.log file that says "Build process terminated by > timeout". For x86_64, the build failed. Looking at the log file, there are a > whole lot of errors that look something like this: > > g++ -c -fPIC -I. -I../.. -I../../liboctave -I../../src -I../../libcruft/misc > -DHAVE_CONFIG_H -Wall -W -Wshadow -Wcast-align -Wcast-qual -Wpointer-arith > -Wwrite-strings -Weffc++ -g -O2 quit.cc -o pic/quit.o > In file included from quit.cc:30: > /usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../include/c++/4.0.0/iostream:43:28: > error: bits/c++config.h: No such file or directory > In file included from > /usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../include/c++/4.0.0/ios:43, > from > /usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../include/c++/4.0.0/ostream:44, > from > /usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../include/c++/4.0.0/iostream:44, > from quit.cc:30: > > So, the errors appear to be caused by the c++ header files. How is it > possible that the header files are broken on one arch and not another? Any > other insights into what might have caused this and how to fix it? There's something weird about mach and C++, I've seen this and some other weirdness just recently myself. The above can be worked around by setting a suitable CPPFLAGS=-I/usr/include/c++ ... before %configure. Another oddity I found is that for Wine to build within mach I had to use LDFLAGS="-lstdc++" %configure - which doesn't make any sense to me either. - Panu - From qspencer at ieee.org Thu May 12 15:03:09 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 12 May 2005 10:03:09 -0500 Subject: Errors on x86_64 (broken c++ headers?) In-Reply-To: References: <428354A9.5040501@ieee.org> Message-ID: <4283702D.7060208@ieee.org> Panu Matilainen wrote: > On Thu, 12 May 2005, Quentin Spencer wrote: > >> ... >> So, the errors appear to be caused by the c++ header files. How is it >> possible that the header files are broken on one arch and not >> another? Any other insights into what might have caused this and how >> to fix it? > > There's something weird about mach and C++, I've seen this and some > other weirdness just recently myself. The above can be worked around > by setting > a suitable CPPFLAGS=-I/usr/include/c++ ... before %configure. > > Another oddity I found is that for Wine to build within mach I had to use > LDFLAGS="-lstdc++" %configure - which doesn't make any sense to me > either. Thanks for the tips. So, this is a bug in mach then? Why only on x86_64? I'd like to get this thing to build finally, so I'm inclined to add this change to configure and submit a rebuild. However, it seems wrong to have to change the spec file because of a bug in something external. Can something be done about this? -Quentin From jpo at di.uminho.pt Thu May 12 15:35:24 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Thu, 12 May 2005 16:35:24 +0100 Subject: make build TARGET=... problem Message-ID: <428377BC.7070107@di.uminho.pt> I have been having a problem with make build (today already happened twice): it fails to update the repo copy. The first tentative only outputs the following: $ make build TARGET=development For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs $ Running make build a second time produces the expected output but submits two building requests. $ make build TARGET=development For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs **** Access allowed: jpo is in ACL for common. Checking in tobuild; /cvs/extras/common/tobuild,v <-- tobuild new revision: 1.431; previous revision: 1.430 done Running syncmail... Mailing cvsextras at fedora.redhat.com... ...syncmail done. $ Parcial email message: diff -u -r1.430 -r1.431 --- tobuild 12 May 2005 15:13:03 -0000 1.430 +++ tobuild 12 May 2005 15:26:04 -0000 1.431 @@ -38,3 +38,5 @@ jpo rpms/perl-Test-Builder-Tester/devel perl-Test-Builder-Tester-1_01-4_fc4 development jpo rpms/perl-Test-Manifest/devel perl-Test-Manifest-1_14-3_fc4 development jpo rpms/perl-Test-Exception/devel perl-Test-Exception-0_20-4_fc4 development +jpo rpms/perl-Test-Pod/devel perl-Test-Pod-1_20-3_fc4 development +jpo rpms/perl-Test-Pod/devel perl-Test-Pod-1_20-3_fc4 development Sould I delete the ../common/tobuild file before retrying the make build command? jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From rc040203 at freenet.de Thu May 12 15:45:11 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 12 May 2005 17:45:11 +0200 Subject: Errors on x86_64 (broken c++ headers?) In-Reply-To: <4283702D.7060208@ieee.org> References: <428354A9.5040501@ieee.org> <4283702D.7060208@ieee.org> Message-ID: <1115912711.8237.416.camel@mccallum.corsepiu.local> On Thu, 2005-05-12 at 10:03 -0500, Quentin Spencer wrote: > Panu Matilainen wrote: > > > On Thu, 12 May 2005, Quentin Spencer wrote: > > > >> ... > >> So, the errors appear to be caused by the c++ header files. How is it > >> possible that the header files are broken on one arch and not > >> another? Any other insights into what might have caused this and how > >> to fix it? > > > > There's something weird about mach and C++, I've seen this and some > > other weirdness just recently myself. The above can be worked around > > by setting > > a suitable CPPFLAGS=-I/usr/include/c++ ... before %configure. > > > > Another oddity I found is that for Wine to build within mach I had to use > > LDFLAGS="-lstdc++" %configure - which doesn't make any sense to me > > either. > > Thanks for the tips. Sorry, these are work-arounds to bugs. They should be inacceptable to be added to rpm specs. g++ is supposed to find its internal headers and libraries without any manual assistance. > So, this is a bug in mach then? Dunno. > Why only on x86_64? Probably multilibs. > I'd like to get this thing to build finally, so I'm inclined to add this > change to configure and submit a rebuild. However, it seems wrong to > have to change the spec file because of a bug in something external. It doesn't seem wrong, it is wrong! Ralf From pmatilai at welho.com Thu May 12 15:51:30 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 12 May 2005 18:51:30 +0300 (EEST) Subject: Errors on x86_64 (broken c++ headers?) In-Reply-To: <1115912711.8237.416.camel@mccallum.corsepiu.local> References: <428354A9.5040501@ieee.org> <4283702D.7060208@ieee.org> <1115912711.8237.416.camel@mccallum.corsepiu.local> Message-ID: On Thu, 12 May 2005, Ralf Corsepius wrote: > On Thu, 2005-05-12 at 10:03 -0500, Quentin Spencer wrote: >> Panu Matilainen wrote: >> >>> On Thu, 12 May 2005, Quentin Spencer wrote: >>> >>>> ... >>>> So, the errors appear to be caused by the c++ header files. How is it >>>> possible that the header files are broken on one arch and not >>>> another? Any other insights into what might have caused this and how >>>> to fix it? >>> >>> There's something weird about mach and C++, I've seen this and some >>> other weirdness just recently myself. The above can be worked around >>> by setting >>> a suitable CPPFLAGS=-I/usr/include/c++ ... before %configure. >>> >>> Another oddity I found is that for Wine to build within mach I had to use >>> LDFLAGS="-lstdc++" %configure - which doesn't make any sense to me >>> either. >> >> Thanks for the tips. > Sorry, these are work-arounds to bugs. They should be inacceptable to be > added to rpm specs. > > g++ is supposed to find its internal headers and libraries without any > manual assistance. > >> So, this is a bug in mach then? > Dunno. Something weird in the chroot environment obviously but what exactly causes it ... ideas would be more than welcome :) > >> Why only on x86_64? > Probably multilibs. It's not just multlib, for example the problem with Wine building happens on i386 chroot. - Panu - From qspencer at ieee.org Thu May 12 16:02:03 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 12 May 2005 11:02:03 -0500 Subject: Errors on x86_64 (broken c++ headers?) In-Reply-To: References: <428354A9.5040501@ieee.org> <4283702D.7060208@ieee.org> <1115912711.8237.416.camel@mccallum.corsepiu.local> Message-ID: <42837DFB.9030304@ieee.org> Panu Matilainen wrote: > On Thu, 12 May 2005, Ralf Corsepius wrote: > >> On Thu, 2005-05-12 at 10:03 -0500, Quentin Spencer wrote: >> >>> Panu Matilainen wrote: >>> >>>> On Thu, 12 May 2005, Quentin Spencer wrote: >>>> >>>>> ... >>>>> So, the errors appear to be caused by the c++ header files. How is it >>>>> possible that the header files are broken on one arch and not >>>>> another? Any other insights into what might have caused this and how >>>>> to fix it? >>>> >>>> >>>> There's something weird about mach and C++, I've seen this and some >>>> other weirdness just recently myself. The above can be worked around >>>> by setting >>>> a suitable CPPFLAGS=-I/usr/include/c++ ... before %configure. >>>> >>>> Another oddity I found is that for Wine to build within mach I had >>>> to use >>>> LDFLAGS="-lstdc++" %configure - which doesn't make any sense to me >>>> either. >>> >>> >>> Thanks for the tips. >> >> Sorry, these are work-arounds to bugs. They should be inacceptable to be >> added to rpm specs. >> >> g++ is supposed to find its internal headers and libraries without any >> manual assistance. >> >>> So, this is a bug in mach then? >> >> Dunno. > > Something weird in the chroot environment obviously but what exactly > causes it ... ideas would be more than welcome :) If something's wrong with the build environment that causes some packages to fail when they wouldn't otherwise, maybe we need to allow for manual builds when necessary. I agree that it's incorrect to be patching our spec files to work around these. I don't have any way of debugging this because of lack of access to the hardware, and I don't want my package sitting around indefinitely until someone figures out why these kind of things are going wrong. Suggestions? -Quentin From bugs.michael at gmx.net Thu May 12 16:12:27 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 12 May 2005 18:12:27 +0200 Subject: make build TARGET=... problem In-Reply-To: <428377BC.7070107@di.uminho.pt> References: <428377BC.7070107@di.uminho.pt> Message-ID: <20050512181227.6590632f.bugs.michael@gmx.net> On Thu, 12 May 2005 16:35:24 +0100, Jos? Pedro Oliveira wrote: > Parcial email message: > diff -u -r1.430 -r1.431 > --- tobuild 12 May 2005 15:13:03 -0000 1.430 > +++ tobuild 12 May 2005 15:26:04 -0000 1.431 > @@ -38,3 +38,5 @@ > jpo rpms/perl-Test-Builder-Tester/devel > perl-Test-Builder-Tester-1_01-4_fc4 development > jpo rpms/perl-Test-Manifest/devel perl-Test-Manifest-1_14-3_fc4 development > jpo rpms/perl-Test-Exception/devel perl-Test-Exception-0_20-4_fc4 > development > +jpo rpms/perl-Test-Pod/devel perl-Test-Pod-1_20-3_fc4 development > +jpo rpms/perl-Test-Pod/devel perl-Test-Pod-1_20-3_fc4 development > > > Sould I delete the ../common/tobuild file before retrying > the make build command? Should not be necessary, because the current Makefile.common checks out a fresh tobuild file _always_ (i.e. ignoring any changes in your local working copy) before appending a _single_ build request line (not two as in your example) prior to immediate commit, which should be enough for the majority of cases. In your case, according to cvs commit log, it really added two lines at once. Weird. Do you really have the most recent "common" files? From jpo at di.uminho.pt Thu May 12 16:26:05 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Thu, 12 May 2005 17:26:05 +0100 Subject: make build TARGET=... problem In-Reply-To: <20050512181227.6590632f.bugs.michael@gmx.net> References: <428377BC.7070107@di.uminho.pt> <20050512181227.6590632f.bugs.michael@gmx.net> Message-ID: <4283839D.5010703@di.uminho.pt> Michael, Michael Schwendt wrote: > In your case, according to cvs commit log, it really added two lines at once. > Weird. Do you really have the most recent "common" files? Yes. I had just done a "cvs co" of the package. Also in one of the make build retries (the second I had to make in the last couple of hours) I also got the following output ---- $ make build TARGET=development For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs cvs update: checksum failure after patch to ./tobuild; will refetch For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs cvs client: refetching unpatchable files $ ---- Note: I did a make build in another package before retying in the one that add failed: Replay: 1) perl-Test-Pod $ make build TARGET=development Status: Failure with only one line of output 2) perl-Test-Exception $ make build ... Status: OK 3) perl-Test-Pod $ make build TARGET=development Status: Failure with the above output 4) perl-Test-Pod $ make build TARGET=development Status: OK (but with two build requests) jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From bugs.michael at gmx.net Thu May 12 16:36:00 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 12 May 2005 18:36:00 +0200 Subject: install versus cp -a in %install In-Reply-To: <21262.62.210.124.226.1115891740.squirrel@62.210.124.226> References: <21262.62.210.124.226.1115891740.squirrel@62.210.124.226> Message-ID: <20050512183600.30ccabc4.bugs.michael@gmx.net> On Thu, 12 May 2005 11:55:40 +0200 (CEST), tian at c-sait.net wrote: > Hello, Would it be asked too much that you enter your real name in your messages? (presumably it's the one from whois c-sait.net) > There was a question about this topic in one of my previous mails. But it > could have gone unoticed because there was a lot of other information in > it ;) > > https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00374.html > > So the question is about the use of install program in %install section of > a .spec to copy files. Is that better to use it instead of a more simple > 'cp -a' > > A major drawback of install is that it doesn't have recursive mode. And > its only advantage, from my point of view, is that it is possible to > specify some permissions and ownerships. > > But as this last operation is performed in the %files section, I think > there is no need to use this feature. > > Am I missing something there? If there is no advantages using install, I > will be able to do a more concise and clean .spec file. Use what works for you. Use what is appropriate. Use what makes sense. "cp -a" makes sense when you want to transfer entire trees. Like "cp -p", "install -p" is one way to copy files with preserved time-stamps. "install" is also useful when you need to chmod at the same time and don't want to do it in the %files section. -- Fedora Core release 3.91 (Pre-FC4) - Linux 2.6.11-1.1290_FC4 loadavg: 1.11 1.06 1.12 From shahms at shahms.com Thu May 12 16:36:17 2005 From: shahms at shahms.com (Shahms King) Date: Thu, 12 May 2005 09:36:17 -0700 Subject: build failure log messages completely useless Message-ID: <42838601.2080704@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ERROR: something went wrong rebuilding the .src.rpm ERROR: inspect rpm build log /var/tmp/mach/fedora-development-ppc-core/tla-1.3.2-5/rpm.log ERROR: failed to rebuild SRPMs So ... the build failed. I figured that much from the "build failed on ppc" message. Is the rpm.log file only copied on success? Is there somewhere else I'm supposed to look for the detailed rpm.log? - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCg4YB/qs2NkWy11sRAp+7AJ9xt6nQMnWJfi5WMTMKy2USIeIIvgCfQEqj CTFHwBBCNXmCeDy+s2cVayg= =pqYf -----END PGP SIGNATURE----- From qspencer at ieee.org Thu May 12 16:40:55 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 12 May 2005 11:40:55 -0500 Subject: build failure log messages completely useless In-Reply-To: <42838601.2080704@shahms.com> References: <42838601.2080704@shahms.com> Message-ID: <42838717.8080806@ieee.org> Shahms King wrote: > ERROR: something went wrong rebuilding the .src.rpm > ERROR: inspect rpm build log > /var/tmp/mach/fedora-development-ppc-core/tla-1.3.2-5/rpm.log > ERROR: failed to rebuild SRPMs FWIW, the log of my failed octave build also showed this failure in x86_84, but then it went on to try to compile the binary anyway, which subsequently failed (see the "Errors on x86_64 ..." thread for more on those errors). I thought this error was kind of odd, but I assumed it didn't have anything to do with the other errors. Could it have? -Quentin From Jochen at herr-schmitt.de Thu May 12 16:44:01 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 12 May 2005 18:44:01 +0200 Subject: Request for Review: monotone In-Reply-To: <0MKwtQ-1DWEWM0tBu-0006up@mrelayeu.kundenserver.de> References: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> <0MKwtQ-1DWEWM0tBu-0006up@mrelayeu.kundenserver.de> Message-ID: <0ML21M-1DWGn33xVa-0005JZ@mrelayeu.kundenserver.de> On Thu, 12 May 2005 16:18:37 +0200, you wrote: >Becouse sqlite is part of FC4, we should examinate, if we can say >'--with-bundled-sqllite3=no' in the configure script. I have make a review on the SPEC file. 'It's contains '--with-bundled-sqlite3=no', but it's doesn't contrins '--with-bundled-boos=no'. Becouse there are a seperate RPM package for boost, it make sense to write '--with-bundled-boos=no'. Best Regards: Jochen Schmitt From Jochen at herr-schmitt.de Thu May 12 16:43:59 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 12 May 2005 18:43:59 +0200 Subject: Need review: ghc In-Reply-To: <428317E2.4030107@redhat.com> References: <428317E2.4030107@redhat.com> Message-ID: <0ML21M-1DWGn30deY-0005JZ@mrelayeu.kundenserver.de> On Thu, 12 May 2005 17:46:26 +0900, you wrote: >After reviewing, the remaining issue is just bootstrapping >because ghc-6.4-8 requires ghc64 (its main subpackage) to build. >Generating (arch dependent) bootstrap tarballs of C files >with ghc would depend on ghc anyway so the recommended way >to buildstrap ghc in buildroots is using such a pre-built binary >package: indeed the Debian maintainer tells me this is also >the way new archs are bootstrapped for debian. > >Signed binary packages for Fedora Core i386, ppc and x86_64 are >available from Fedora Haskell : > >http://haskell.org/fedora/haskell/3/i386/RPMS.stable/ghc64-6.4-7.i386.rpm >http://haskell.org/fedora/haskell/3/ppc/RPMS.stable/ghc64-6.4-1.ppc.rpm >http://haskell.org/fedora/haskell/3/x86_64/RPMS.stable/ghc64-6.4-7.x86_64.rpm > >and can be used for the initial builds. Special question? Does the build system able to handle such a situation, that a package need itself as a buildrequirement? Best Regards: Jochen Schmitt From bugs.michael at gmx.net Thu May 12 16:54:39 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 12 May 2005 18:54:39 +0200 Subject: make build TARGET=... problem In-Reply-To: <4283839D.5010703@di.uminho.pt> References: <428377BC.7070107@di.uminho.pt> <20050512181227.6590632f.bugs.michael@gmx.net> <4283839D.5010703@di.uminho.pt> Message-ID: <20050512185439.1c5acde3.bugs.michael@gmx.net> On Thu, 12 May 2005 17:26:05 +0100, Jos? Pedro Oliveira wrote: > Also in one of the make build retries (the second I had to make in the > last couple of hours) I also got the following output > > ---- > $ make build TARGET=development > For more information on using the Fedora CVS repositories, please > visit http://fedoraproject.org/wiki/UsingCvs > cvs update: checksum failure after patch to ./tobuild; will refetch Very unusual. As far as I know, a "checksum failure after patch" means that cvs downloaded a diff between your local working copy and the repository, tried to apply that diff and then noticed that the resulting file doesn't match the checksum it should have. I think with update -C it checks out a file completely instead of applying a patch. If you continue to run into problems, you could edit your Makefile.common and call "cvs -t update -C tobuild" instead of "cvs -Q ...". Or even drop -Q for some time, so it's not completely quiet. > For more information on using the Fedora CVS repositories, please > visit http://fedoraproject.org/wiki/UsingCvs > cvs client: refetching unpatchable files > $ And all this is still part of cvs update, so in the end it should get a tobuild file (whatever revision it may be) and append a single build request, then commit it. > ---- > > Note: I did a make build in another package before retying in the one > that add failed: > > Replay: > 1) perl-Test-Pod $ make build TARGET=development > Status: Failure with only one line of output > 2) perl-Test-Exception $ make build ... > Status: OK > 3) perl-Test-Pod $ make build TARGET=development > Status: Failure with the above output > 4) perl-Test-Pod $ make build TARGET=development > Status: OK (but with two build requests) > > > jpo Since the Makefile is not made for concurrent access, all steps after eachother, hopefully... Btw, you should not need to specify TARGET=... anymore. -- Fedora Core release 3.91 (Pre-FC4) - Linux 2.6.11-1.1290_FC4 loadavg: 1.03 1.07 1.08 From tian at c-sait.net Thu May 12 17:14:00 2005 From: tian at c-sait.net (Christian Jodar) Date: Thu, 12 May 2005 19:14:00 +0200 Subject: install versus cp -a in %install In-Reply-To: <20050512183600.30ccabc4.bugs.michael@gmx.net> References: <21262.62.210.124.226.1115891740.squirrel@62.210.124.226> <20050512183600.30ccabc4.bugs.michael@gmx.net> Message-ID: <20050512191400.3b7c136b@tianbox> Hello, > Would it be asked too much that you enter your real name in your > messages? (presumably it's the one from whois c-sait.net) Did you mean you want it into From field? I changed that. But there was no need to do a whois as it was in the title of my previous mail (the one I linked in my message). > Use what works for you. I thought the goal of Fedora Extras was to provide quality packages that follow some rules (that's why there are some packaging guidelines). So for me *Use what works for everybody* would be better. And as I have a little experience in this domain, I wanted to have some suggestions from more experienced people. > Use what is appropriate. That's my question. I wanted to know what is appropriate in this context. I know the options of each command. But as install is used most of the time, I thought I didn't get something (as cp is easier to use when many directories need to be copied) > Use what makes sense. I am not sure to understand what you meant there. But I have a more important question: Why did you use such a condescending tone? Christian Jodar. From ivazquez at ivazquez.net Thu May 12 17:17:18 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 12 May 2005 13:17:18 -0400 Subject: make build TARGET=... problem In-Reply-To: <428377BC.7070107@di.uminho.pt> References: <428377BC.7070107@di.uminho.pt> Message-ID: <1115918238.26688.7.camel@ignacio.ignacio.lan> On Thu, 2005-05-12 at 16:35 +0100, Jos? Pedro Oliveira wrote: > I have been having a problem with make build (today already happened > twice): it fails to update the repo copy. I just saw this myself when requesting a build of notecase for FC3. Fortunately I recognized it and was able to correct it, but I'd just like to say that it is happening to more than one person. -- 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 nutello at sweetness.com Thu May 12 17:23:03 2005 From: nutello at sweetness.com (Rudi Chiarito) Date: Thu, 12 May 2005 19:23:03 +0200 Subject: Errors on x86_64 (broken c++ headers?) In-Reply-To: References: <428354A9.5040501@ieee.org> Message-ID: <20050512172303.GC7304@plain.rackshack.net> On Thu, May 12, 2005 at 05:22:00PM +0300, Panu Matilainen wrote: > Another oddity I found is that for Wine to build within mach I had to use > LDFLAGS="-lstdc++" %configure - which doesn't make any sense to me either. This might not necessarily be a problem with Mach. I had a Wine build fail on a headless i686 machine, WITHOUT Mach. It was complaining about not being able to link STL stuff in - something that -lstdc++ would fix. Installing xorg-x11-Mesa-libGLU and rebuilding the same identical spec file fixed that somehow. A side-effect of some check in the configure tests? *shrug* -- Rudi From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu May 12 17:25:08 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 12 May 2005 19:25:08 +0200 Subject: Build failure on ppc : I am just so unlucky? Message-ID: <20050512192508.0d3139cc@python2> Here is what I got for synergy : [...] ---> Downloading header for mkinitrd to pack into transaction set. http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/ppc/Fedora/RPMS/mkinitrd-4.2.12-1.ppc.rpm: [Errno 4] IOError: HTTP Error 404: Date: Thu, 12 May 2005 16:27:58 GMT Content-Length: 345 Accept-Ranges: bytes Content-Type: text/html Server: lighttpd/1.3.13 Trying other mirror. Error: failure: Fedora/RPMS/mkinitrd-4.2.12-1.ppc.rpm from core: [Errno 256] No more mirrors to try. ERROR: Could not get build-minimal Could it be that the server was still syncing the ppc devel files? Last time I tried to build synergy, I got bitten by the timeout caused by the FC4test downloads, and now this :-( Seth : Wouldn't it be a good thing to sync locally the relevant trees on each build machine? ...and do it at a time of the day when the devel tree is known to have finished syncing? (if that was the cause) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.20_FC3 Load : 0.61 0.89 0.62 From skvidal at phy.duke.edu Thu May 12 17:29:21 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 12 May 2005 13:29:21 -0400 Subject: Build failure on ppc : I am just so unlucky? In-Reply-To: <20050512192508.0d3139cc@python2> References: <20050512192508.0d3139cc@python2> Message-ID: <1115918961.13475.2.camel@cutter> On Thu, 2005-05-12 at 19:25 +0200, Matthias Saou wrote: > Here is what I got for synergy : > > [...] > ---> Downloading header for mkinitrd to pack into transaction set. > http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/ppc/Fedora/RPMS/mkinitrd-4.2.12-1.ppc.rpm: > [Errno 4] IOError: HTTP Error 404: Date: Thu, 12 May 2005 16:27:58 GMT > Content-Length: 345 Accept-Ranges: bytes > Content-Type: text/html > Server: lighttpd/1.3.13 > Trying other mirror. > Error: failure: Fedora/RPMS/mkinitrd-4.2.12-1.ppc.rpm from core: [Errno > 256] No more mirrors to try. > > ERROR: Could not get build-minimal > > Could it be that the server was still syncing the ppc devel files? Last > time I tried to build synergy, I got bitten by the timeout caused by the > FC4test downloads, and now this :-( > > Seth : Wouldn't it be a good thing to sync locally the relevant trees on > each build machine? ...and do it at a time of the day when the devel tree > is known to have finished syncing? (if that was the cause) That'd be great - you got 26GB of disk space to share? -sv From robert at marcanoonline.com Thu May 12 17:30:17 2005 From: robert at marcanoonline.com (Robert Marcano) Date: Thu, 12 May 2005 13:30:17 -0400 Subject: New package: kanatest - Approval needed In-Reply-To: <1115656573.17797.2.camel@tprobert.intranet.promca.com> References: <1115597334.20177.21.camel@localhost.localdomain> <1115640329.21984.22.camel@ignacio.ignacio.lan> <1115653760.11898.6.camel@tprobert.intranet.promca.com> <1115654009.20150.2.camel@localhost.localdomain> <1115656573.17797.2.camel@tprobert.intranet.promca.com> Message-ID: <1115919017.19974.4.camel@tprobert.intranet.promca.com> On Mon, 2005-05-09 at 12:36 -0400, Robert Marcano wrote: ... > Updated and uploaded > > http://www.marcanoonline.com/downloads/fedora/package_submissions/kanatest/kanatest-0.3.6-2.src.rpm > http://www.marcanoonline.com/downloads/fedora/package_submissions/kanatest/kanatest.spec > I have updated the SPEC file following the recommendations given on this list. The next step is Sponsorship?... Anyone can help? ________________________________________ Robert Marcano web: http://www.marcanoonline.com/ gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD From bugs.michael at gmx.net Thu May 12 17:31:57 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 12 May 2005 19:31:57 +0200 Subject: install versus cp -a in %install In-Reply-To: <20050512191400.3b7c136b@tianbox> References: <21262.62.210.124.226.1115891740.squirrel@62.210.124.226> <20050512183600.30ccabc4.bugs.michael@gmx.net> <20050512191400.3b7c136b@tianbox> Message-ID: <20050512193157.79700d6e.bugs.michael@gmx.net> On Thu, 12 May 2005 19:14:00 +0200, Christian Jodar wrote: > Hello, > > > Would it be asked too much that you enter your real name in your > > messages? (presumably it's the one from whois c-sait.net) > > Did you mean you want it into From field? Yes. > I changed that. But there > was no need to do a whois as it was in the title of my previous mail > (the one I linked in my message). No time to follow every link. > > Use what works for you. > > I thought the goal of Fedora Extras was to provide quality packages > that follow some rules (that's why there are some packaging guidelines). > So for me *Use what works for everybody* would be better. And as I have > a little experience in this domain, I wanted to have some suggestions > from more experienced people. You asked specifically about "cp vs. install", I posted a comment about that. It was not a comment about packaging in general. For some things there are guidelines, for other things there are policies. > > Use what makes sense. > > I am not sure to understand what you meant there. Example: if "cp -a source-dir destination-dir" looks like a command that makes sense, why look for a different solution with which you may need to copy files manually? > But I have a more important question: Why did you use such a condescending > tone? That's a matter of opinion. I don't think I did. -- Fedora Core release 3.91 (Pre-FC4) - Linux 2.6.11-1.1290_FC4 loadavg: 1.32 1.11 1.09 From skvidal at phy.duke.edu Thu May 12 17:32:57 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 12 May 2005 13:32:57 -0400 Subject: Need review: ghc In-Reply-To: <0ML21M-1DWGn30deY-0005JZ@mrelayeu.kundenserver.de> References: <428317E2.4030107@redhat.com> <0ML21M-1DWGn30deY-0005JZ@mrelayeu.kundenserver.de> Message-ID: <1115919177.13475.4.camel@cutter> On Thu, 2005-05-12 at 18:43 +0200, Jochen Schmitt wrote: > On Thu, 12 May 2005 17:46:26 +0900, you wrote: > > >After reviewing, the remaining issue is just bootstrapping > >because ghc-6.4-8 requires ghc64 (its main subpackage) to build. > >Generating (arch dependent) bootstrap tarballs of C files > >with ghc would depend on ghc anyway so the recommended way > >to buildstrap ghc in buildroots is using such a pre-built binary > >package: indeed the Debian maintainer tells me this is also > >the way new archs are bootstrapped for debian. > > > >Signed binary packages for Fedora Core i386, ppc and x86_64 are > >available from Fedora Haskell : > > > >http://haskell.org/fedora/haskell/3/i386/RPMS.stable/ghc64-6.4-7.i386.rpm > >http://haskell.org/fedora/haskell/3/ppc/RPMS.stable/ghc64-6.4-1.ppc.rpm > >http://haskell.org/fedora/haskell/3/x86_64/RPMS.stable/ghc64-6.4-7.x86_64.rpm > > > >and can be used for the initial builds. > > Special question? > > Does the build system able to handle such a situation, that a > package need itself as a buildrequirement? > > Best Regards: > a package cannot require itself. that makes no sense at all. -sv From pmatilai at welho.com Thu May 12 17:55:51 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 12 May 2005 20:55:51 +0300 Subject: Errors on x86_64 (broken c++ headers?) In-Reply-To: <42837DFB.9030304@ieee.org> References: <428354A9.5040501@ieee.org> <4283702D.7060208@ieee.org> <1115912711.8237.416.camel@mccallum.corsepiu.local> <42837DFB.9030304@ieee.org> Message-ID: <1115920551.29062.22.camel@weasel.laiskiainen.org> On Thu, 2005-05-12 at 11:02 -0500, Quentin Spencer wrote: > Panu Matilainen wrote: > > > > Something weird in the chroot environment obviously but what exactly > > causes it ... ideas would be more than welcome :) > > If something's wrong with the build environment that causes some > packages to fail when they wouldn't otherwise, maybe we need to allow > for manual builds when necessary. I agree that it's incorrect to be > patching our spec files to work around these. I don't have any way of > debugging this because of lack of access to the hardware, and I don't > want my package sitting around indefinitely until someone figures out > why these kind of things are going wrong. Suggestions? Digging this right now and finding something odd... My Wine-problem was something else but the thing you're seeing is indeed a multilib thing like Ralf suspected. Watch this: After setting up a chroot for fc3-x86_64 with "mach -r fedora-3-x86_64-core setup build" things look like this: [root at weasel]# mach -r fedora-3-x86_64-core yum list|grep std libstdc++.x86_64 3.4.3-22.fc3 installed libstdc++-devel.x86_64 3.4.3-22.fc3 installed compat-libstdc++.i386 8-3.3.4.2 core compat-libstdc++.x86_64 8-3.3.4.2 core compat-libstdc++-devel.i386 8-3.3.4.2 core compat-libstdc++-devel.x86_64 8-3.3.4.2 core libstdc++.i386 3.4.3-22.fc3 updates libstdc++-devel.i386 3.4.3-22.fc3 updates So far so good. Now, when you install something that buildrequires libstdc++-devel this happens: [root at weasel]# mach -r fedora-3-x86_64-core yum install libstdc++-devel ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: libstdc++-devel i386 3.4.3-22.fc3 updates 8.5 M Transaction Summary ============================================================================= Install 1 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 8.5 M Installed: libstdc++-devel.i386 0:3.4.3-22.fc3 [root at weasel]# mach -r fedora-3-x86_64-core yum list|grep std libstdc++.x86_64 3.4.3-22.fc3 installed libstdc++-devel.i386 3.4.3-22.fc3 installed compat-libstdc++.i386 8-3.3.4.2 core compat-libstdc++.x86_64 8-3.3.4.2 core compat-libstdc++-devel.i386 8-3.3.4.2 core compat-libstdc++-devel.x86_64 8-3.3.4.2 core libstdc++.i386 3.4.3-22.fc3 updates libstdc++-devel.x86_64 3.4.3-22.fc3 updates libstdc++-devel.i386 got installed and libstdc++-devel.x86_64 *quietly removed*. Big surprise g++ doesn't work anymore... In fact, if you do successive runs of "yum install libstdc++-devel" inside or outside mach, yum (2.3.2) will flip-flop between i386 and x86_64 package. Can't be expected behavior really... Anyway, can be worked around by just excluding all i386 packages in the chroot's yum.conf. - Panu - From perbj at stanford.edu Thu May 12 17:59:26 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Thu, 12 May 2005 10:59:26 -0700 Subject: Need review: ghc In-Reply-To: <1115919177.13475.4.camel@cutter> References: <428317E2.4030107@redhat.com> <0ML21M-1DWGn30deY-0005JZ@mrelayeu.kundenserver.de> <1115919177.13475.4.camel@cutter> Message-ID: <1115920767.4856.51.camel@localhost.localdomain> On Thu, 2005-05-12 at 13:32 -0400, seth vidal wrote: > a package cannot require itself. > > that makes no sense at all. Well, if it weren't that GCC was considered part of the base build system I bet that GCC would have to build-require some C compiler in any case! (Yes I know it rebuilds itself with itself to get consistent results, but to kick off the first bootstrap stage some marginally competent C compiler is necessary.) In principle I guess this compiler could possibly BuildRequire something other than specifically "ghc", perhaps "some Haskell compiler". However, GHC seem to be the most popular one around, and there's certainly no other one in Fedora... Any other suggestions for how to deal with this bootstrap problem? Perhaps someone knows how the GNU Ada compiler (part of GCC, packaged as gcc-gnat) was first bootstrapped in Red Hat Linux? It's an Ada compiler written in Ada AFAIK... /Per From zipsonic at gmail.com Thu May 12 18:02:12 2005 From: zipsonic at gmail.com (Rick Stout) Date: Thu, 12 May 2005 11:02:12 -0700 Subject: Request for review: nx (Neal Becker) In-Reply-To: <20050512160104.0FDDB73CAB@hormel.redhat.com> References: <20050512160104.0FDDB73CAB@hormel.redhat.com> Message-ID: <42839A24.1050305@gmail.com> > Does this build on x86_64? Last time I tried it didn't. It will now build on x86_64, but due to some library differences, it still doesn't run on x86_64. Regards, Rick Stout From pmatilai at welho.com Thu May 12 18:11:34 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 12 May 2005 21:11:34 +0300 Subject: Errors on x86_64 (broken c++ headers?) In-Reply-To: <1115920551.29062.22.camel@weasel.laiskiainen.org> References: <428354A9.5040501@ieee.org> <4283702D.7060208@ieee.org> <1115912711.8237.416.camel@mccallum.corsepiu.local> <42837DFB.9030304@ieee.org> <1115920551.29062.22.camel@weasel.laiskiainen.org> Message-ID: <1115921494.29062.28.camel@weasel.laiskiainen.org> On Thu, 2005-05-12 at 20:55 +0300, Panu Matilainen wrote: > > In fact, if you do successive runs of "yum install libstdc++-devel" > inside or outside mach, yum (2.3.2) will flip-flop between i386 and > x86_64 package. Can't be expected behavior really... Hohum. The libstdc++-devel packages obsolete each other, that's why they flip-flop (happens with rpm -Uvh as well): [root at weasel]# rpm -q --obsoletes libstdc++-devel libstdc++3-devel libstdc++34-devel [root at weasel]# rpm -q --provides libstdc++-devel libstdc++34-devel libstdc++-devel = 3.4.3-22.fc3 - Panu - From qspencer at ieee.org Thu May 12 18:30:56 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 12 May 2005 13:30:56 -0500 Subject: Errors on x86_64 (broken c++ headers?) In-Reply-To: <1115921494.29062.28.camel@weasel.laiskiainen.org> References: <428354A9.5040501@ieee.org> <4283702D.7060208@ieee.org> <1115912711.8237.416.camel@mccallum.corsepiu.local> <42837DFB.9030304@ieee.org> <1115920551.29062.22.camel@weasel.laiskiainen.org> <1115921494.29062.28.camel@weasel.laiskiainen.org> Message-ID: <4283A0E0.2030203@ieee.org> Panu Matilainen wrote: >On Thu, 2005-05-12 at 20:55 +0300, Panu Matilainen wrote: > > >>In fact, if you do successive runs of "yum install libstdc++-devel" >>inside or outside mach, yum (2.3.2) will flip-flop between i386 and >>x86_64 package. Can't be expected behavior really... >> >> > >Hohum. The libstdc++-devel packages obsolete each other, that's why they >flip-flop (happens with rpm -Uvh as well): > >[root at weasel]# rpm -q --obsoletes libstdc++-devel >libstdc++3-devel >libstdc++34-devel >[root at weasel]# rpm -q --provides libstdc++-devel >libstdc++34-devel >libstdc++-devel = 3.4.3-22.fc3 > > So, does this mean that I have a 50-50 chance of getting the libraries I want if I resubmit the job? Just curious. Obviously this needs to be fixed, but if I had a reasonable chance of resubmitting the job and getting it to build, I might try before then. -Quentin From skvidal at phy.duke.edu Thu May 12 18:39:28 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 12 May 2005 14:39:28 -0400 Subject: Errors on x86_64 (broken c++ headers?) In-Reply-To: <4283A0E0.2030203@ieee.org> References: <428354A9.5040501@ieee.org> <4283702D.7060208@ieee.org> <1115912711.8237.416.camel@mccallum.corsepiu.local> <42837DFB.9030304@ieee.org> <1115920551.29062.22.camel@weasel.laiskiainen.org> <1115921494.29062.28.camel@weasel.laiskiainen.org> <4283A0E0.2030203@ieee.org> Message-ID: <1115923168.13475.22.camel@cutter> > > > > > So, does this mean that I have a 50-50 chance of getting the libraries I > want if I resubmit the job? Just curious. Obviously this needs to be > fixed, but if I had a reasonable chance of resubmitting the job and > getting it to build, I might try before then. > no it means we have to fix the buildroot creation so for x86_64 there are no i386/i686/etc packages allowed. I'm working on making that easier now. bear with me. -sv From notting at redhat.com Thu May 12 18:45:00 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 12 May 2005 14:45:00 -0400 Subject: devel/common Makefile.common,1.16,1.17 In-Reply-To: <200505121835.j4CIZaDq030367@cvs-int.fedora.redhat.com> References: <200505121835.j4CIZaDq030367@cvs-int.fedora.redhat.com> Message-ID: <20050512184500.GA16539@nostromo.devel.redhat.com> Michael Schwendt (fedora-extras-commits at redhat.com) said: > Author: mschwendt > > Update of /cvs/extras/devel/common > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv30350 > > Modified Files: > Makefile.common > Log Message: > Enough problem reports to test something more: Put back notting's rm -f tobuild, but this time _before_ checking out a fresh copy. Is the cvs update throwing errors, but we're just not catching it and proceeding? Or something else? Bill From bugs.michael at gmx.net Thu May 12 18:55:07 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 12 May 2005 20:55:07 +0200 Subject: devel/common Makefile.common,1.16,1.17 In-Reply-To: <20050512184500.GA16539@nostromo.devel.redhat.com> References: <200505121835.j4CIZaDq030367@cvs-int.fedora.redhat.com> <20050512184500.GA16539@nostromo.devel.redhat.com> Message-ID: <20050512205507.0b60ff92.bugs.michael@gmx.net> On Thu, 12 May 2005 14:45:00 -0400, Bill Nottingham wrote: > Michael Schwendt (fedora-extras-commits at redhat.com) said: > > Author: mschwendt > > > > Update of /cvs/extras/devel/common > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv30350 > > > > Modified Files: > > Makefile.common > > Log Message: > > Enough problem reports to test something more: Put back notting's rm -f tobuild, but this time _before_ checking out a fresh copy. > > Is the cvs update throwing errors, but we're just not catching it > and proceeding? Or something else? As discussed on extras list, jpo got errors and no syncmail output (which indicates the commit failed, too). Now if update -C fails to replace a non-existant local file, that would really surprise me. From pmatilai at welho.com Thu May 12 19:00:04 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 12 May 2005 22:00:04 +0300 Subject: Errors on x86_64 (broken c++ headers?) In-Reply-To: <1115923168.13475.22.camel@cutter> References: <428354A9.5040501@ieee.org> <4283702D.7060208@ieee.org> <1115912711.8237.416.camel@mccallum.corsepiu.local> <42837DFB.9030304@ieee.org> <1115920551.29062.22.camel@weasel.laiskiainen.org> <1115921494.29062.28.camel@weasel.laiskiainen.org> <4283A0E0.2030203@ieee.org> <1115923168.13475.22.camel@cutter> Message-ID: <1115924404.29062.33.camel@weasel.laiskiainen.org> On Thu, 2005-05-12 at 14:39 -0400, seth vidal wrote: > > > > > > > > So, does this mean that I have a 50-50 chance of getting the libraries I > > want if I resubmit the job? Just curious. Obviously this needs to be > > fixed, but if I had a reasonable chance of resubmitting the job and > > getting it to build, I might try before then. That's exactly what will happen - every other build will fail and succeed :) > > no it means we have to fix the buildroot creation so for x86_64 there > are no i386/i686/etc packages allowed. > > I'm working on making that easier now. bear with me. An easy way to deal with this would be adding exclude config setting into mach's per-root configuration and set exclude = *.i386 for all x86_64 roots, doesn't require much code. Or do you have something more sophisticated in mind? - Panu - From bugs.michael at gmx.net Thu May 12 19:05:43 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 12 May 2005 21:05:43 +0200 Subject: make build TARGET=... problem In-Reply-To: <1115918238.26688.7.camel@ignacio.ignacio.lan> References: <428377BC.7070107@di.uminho.pt> <1115918238.26688.7.camel@ignacio.ignacio.lan> Message-ID: <20050512210543.0bafa622.bugs.michael@gmx.net> On Thu, 12 May 2005 13:17:18 -0400, Ignacio Vazquez-Abrams wrote: > On Thu, 2005-05-12 at 16:35 +0100, Jos? Pedro Oliveira wrote: > > I have been having a problem with make build (today already happened > > twice): it fails to update the repo copy. > > I just saw this myself when requesting a build of notecase for FC3. > Fortunately I recognized it and was able to correct it, but I'd just > like to say that it is happening to more than one person. Commit conflicts are still possible. But since the next "make build" would check out a fresh working copy, there should never be any duplicate entries. -- Fedora Core release 3.91 (Pre-FC4) - Linux 2.6.11-1.1290_FC4 loadavg: 2.17 1.91 1.98 From toshio at tiki-lounge.com Thu May 12 19:02:03 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 12 May 2005 12:02:03 -0700 Subject: Need review: ghc In-Reply-To: <1115920767.4856.51.camel@localhost.localdomain>; from perbj@stanford.edu on Thu, May 12, 2005 at 10:59:26AM -0700 References: <428317E2.4030107@redhat.com> <0ML21M-1DWGn30deY-0005JZ@mrelayeu.kundenserver.de> <1115919177.13475.4.camel@cutter> <1115920767.4856.51.camel@localhost.localdomain> Message-ID: <20050512120203.B21493@tiki-lounge.com> On Thu, May 12, 2005 at 10:59:26AM -0700, Per Bjornsson wrote: > On Thu, 2005-05-12 at 13:32 -0400, seth vidal wrote: > > a package cannot require itself. > > > > that makes no sense at all. > > Well, if it weren't that GCC was considered part of the base build > system I bet that GCC would have to build-require some C compiler in any > case! (Yes I know it rebuilds itself with itself to get consistent > results, but to kick off the first bootstrap stage some marginally > competent C compiler is necessary.) > > In principle I guess this compiler could possibly BuildRequire > something other than specifically "ghc", perhaps "some Haskell > compiler". However, GHC seem to be the most popular one around, and > there's certainly no other one in Fedora... Any other suggestions for > how to deal with this bootstrap problem? > > Perhaps someone knows how the GNU Ada compiler (part of GCC, packaged as > gcc-gnat) was first bootstrapped in Red Hat Linux? It's an Ada compiler > written in Ada AFAIK... > I don't know how it was first bootstrapped, but this is in the gcc4.spec (of which gcc-gnat is a subpackage). %if %{build_ada} # Ada requires Ada to build BuildRequires: gcc-gnat >= 3.1, libgnat >= 3.1 %endif -Toshio From skvidal at phy.duke.edu Thu May 12 19:15:13 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 12 May 2005 15:15:13 -0400 Subject: Errors on x86_64 (broken c++ headers?) In-Reply-To: <1115924404.29062.33.camel@weasel.laiskiainen.org> References: <428354A9.5040501@ieee.org> <4283702D.7060208@ieee.org> <1115912711.8237.416.camel@mccallum.corsepiu.local> <42837DFB.9030304@ieee.org> <1115920551.29062.22.camel@weasel.laiskiainen.org> <1115921494.29062.28.camel@weasel.laiskiainen.org> <4283A0E0.2030203@ieee.org> <1115923168.13475.22.camel@cutter> <1115924404.29062.33.camel@weasel.laiskiainen.org> Message-ID: <1115925314.13475.34.camel@cutter> > An easy way to deal with this would be adding exclude config setting > into mach's per-root configuration and set exclude = *.i386 for all > x86_64 roots, doesn't require much code. Or do you have something more > sophisticated in mind? > I'm working on removing sophistication, actually. Right now mach does too much stuff that we don't need it to do. I'm removing functionality intentionally to make handling it easier and less 'ugh'. -sv From nutello at sweetness.com Thu May 12 19:15:37 2005 From: nutello at sweetness.com (Rudi Chiarito) Date: Thu, 12 May 2005 21:15:37 +0200 Subject: netcdf .a location Message-ID: <20050512191537.GD7304@plain.rackshack.net> The current netcdf-devel package places the libraries in /usr/lib/netcdf-3/. The rationale given in the spec file is that this in preparation for netcdf-4 (no, netcdf has historically never been a shared library...). Is this sanctioned/approved? It surely makes things a bit trickier, because builds have to explicitly augment the library search path and you can't say -lnetcdf-3/. I have looked for precedents. So far, netcdf's static libraries seem to be unique. cyrus-sasl-devel does indeed place .a files in a subdirectory, but they appear to be more like plugins. A more similar scenario is libpng's. libpng-devel and libpng10-devel install these files: /usr/lib/libpng10.a /usr/lib/libpng12.a /usr/lib/libpng.a -> libpng12.a Should netcdf follow that example? -- Rudi From bugs.michael at gmx.net Thu May 12 20:12:55 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 12 May 2005 22:12:55 +0200 Subject: netcdf .a location In-Reply-To: <20050512191537.GD7304@plain.rackshack.net> References: <20050512191537.GD7304@plain.rackshack.net> Message-ID: <20050512221255.4e31eed9.bugs.michael@gmx.net> On Thu, 12 May 2005 21:15:37 +0200, Rudi Chiarito wrote: > The current netcdf-devel package places the libraries in > /usr/lib/netcdf-3/. The rationale given in the spec file is that this in > preparation for netcdf-4 (no, netcdf has historically never been a > shared library...). Is this sanctioned/approved? It surely makes things > a bit trickier, because builds have to explicitly augment the library > search path and you can't say -lnetcdf-3/. > > I have looked for precedents. So far, netcdf's static libraries seem to > be unique. cyrus-sasl-devel does indeed place .a files in a > subdirectory, but they appear to be more like plugins. A more similar > scenario is libpng's. libpng-devel and libpng10-devel install these > files: > > /usr/lib/libpng10.a > /usr/lib/libpng12.a > /usr/lib/libpng.a -> libpng12.a > > Should netcdf follow that example? You mean, put the headers into a separate sub-directory like libpng10 does it? ;) From beartooth at adelphia.net Thu May 12 18:50:55 2005 From: beartooth at adelphia.net (beartooth) Date: Thu, 12 May 2005 14:50:55 -0400 Subject: OT Re: request for review: hobbit References: <1115846794.3251.17.camel@laptop.mpeters.local> <80d7e409050511145656bb7eb8@mail.gmail.com> <4282FEE7.5040105@redhat.com> <1115881277.4604.26.camel@cutter> Message-ID: On Thu, 12 May 2005 03:01:17 -0400, seth vidal wrote: >> His name is spelled Tolkien. > > His body is rotting in the ground, I doubt he gives a damn. :-D He was also an eminent historian of tongues, and a perfectionist : read any volume of his son Christopher's edition of the posthumous writings, especially the ones he calls collectively "History of Middle-earth" which deal with the process of writing the Lord of the Rings. And you remark would certainly offend many of his innumerable fans .... -- Beartooth Neo-Redneck, Linux Evangelist FC 1 YDL 4; Pine 4.63, Pan 0.14.2; Privoxy 3.0.3; Dillo 0.8.4, Opera 8.0, Firefox 1.0.3, Epiphany 1.0.4 Just for once, I know what I am talking about. From ed at eh3.com Thu May 12 20:32:42 2005 From: ed at eh3.com (Ed Hill) Date: Thu, 12 May 2005 16:32:42 -0400 Subject: netcdf .a location In-Reply-To: <20050512221255.4e31eed9.bugs.michael@gmx.net> References: <20050512191537.GD7304@plain.rackshack.net> <20050512221255.4e31eed9.bugs.michael@gmx.net> Message-ID: <1115929962.2051.135.camel@ernie> On Thu, 2005-05-12 at 22:12 +0200, Michael Schwendt wrote: > On Thu, 12 May 2005 21:15:37 +0200, Rudi Chiarito wrote: > > I have looked for precedents. So far, netcdf's static libraries seem to > > be unique. cyrus-sasl-devel does indeed place .a files in a > > subdirectory, but they appear to be more like plugins. A more similar > > scenario is libpng's. libpng-devel and libpng10-devel install these > > files: > > > > /usr/lib/libpng10.a > > /usr/lib/libpng12.a > > /usr/lib/libpng.a -> libpng12.a > > > > Should netcdf follow that example? > > You mean, put the headers into a separate sub-directory like libpng10 > does it? ;) Hi Rudy, The history of the netCDF packaging efforts are archived for your reading pleasure at: https://bugzilla.fedora.us/show_bug.cgi?id=1874 My view is that the current arrangement is entirely usable (even if it might be less-than-perfect) and I'm not at all interested in having another "where-do-the-files-go" re-hash. So, unless theres an actual bug or a violation of Fedora Extras policies [which I trust Michael would point out--hes very astute! ;-)], I'm in no hurry to shuffle things around. 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 nutello at sweetness.com Thu May 12 20:32:04 2005 From: nutello at sweetness.com (Rudi Chiarito) Date: Thu, 12 May 2005 22:32:04 +0200 Subject: netcdf .a location In-Reply-To: <20050512221255.4e31eed9.bugs.michael@gmx.net> References: <20050512191537.GD7304@plain.rackshack.net> <20050512221255.4e31eed9.bugs.michael@gmx.net> Message-ID: <20050512203204.GE7304@plain.rackshack.net> On Thu, May 12, 2005 at 10:12:55PM +0200, Michael Schwendt wrote: > You mean, put the headers into a separate sub-directory like libpng10 > does it? ;) If you are trying to write cross-platform software, that's still a bit less trouble. You just include if you are using the old API. Changing the library or include search path is trickier, especially if you also consider Windows or OSX. Let the compiler or linker figure it out when possible. -- Rudi From tian at c-sait.net Thu May 12 21:33:48 2005 From: tian at c-sait.net (Christian Jodar) Date: Thu, 12 May 2005 23:33:48 +0200 Subject: install versus cp -a in %install In-Reply-To: <20050512193157.79700d6e.bugs.michael@gmx.net> References: <21262.62.210.124.226.1115891740.squirrel@62.210.124.226> <20050512183600.30ccabc4.bugs.michael@gmx.net> <20050512191400.3b7c136b@tianbox> <20050512193157.79700d6e.bugs.michael@gmx.net> Message-ID: <20050512233348.25a1a5be@tianbox> > You asked specifically about "cp vs. install", I posted a comment about > that. It was not a comment about packaging in general. For some things > there are guidelines, for other things there are policies. Actually no. I asked about "cp vs. install _in %install_" So I was talking about what can be done in .spec files for RPMs to be included into Fedora Extras. I submitted a package to be reviewed and I wanted to do everything as expected. So if the answer is "There is no guideline about what you should better use for this case", it is perfect for me. > > But I have a more important question: Why did you use such a condescending > > tone? > > That's a matter of opinion. I don't think I did. Really? Bah, let's say it could be because english is not my mother tongue and translation for what you told (especially your first sentence) in my language sounds aggressive. But we are off-topic there. So for me we could stop with this part of the discussion and focus on technical aspect. Christian Jodar. From fedora-extras-list at six-by-nine.com.au Thu May 12 21:54:34 2005 From: fedora-extras-list at six-by-nine.com.au (Peter Lawler) Date: Fri, 13 May 2005 07:54:34 +1000 Subject: Mach setup Message-ID: <4283D09A.4090106@six-by-nine.com.au> Hi! This mach thing looks neat, but I can't get it set up. I've taken it from CVS, build my own rpm and installed it. (Someone on #fedora-extras wanted to know the following info, so I repost here for convenience). ls -l /usr/sbin/mach-helper -rwsr-x--- 1 root mach 7772 May 11 18:31 /usr/sbin/mach-helper Any help appreciated. Regards, Pete. [build at dick-wired ~]$ mach setup base No definition for packages found for fedora-3-i386-fedora-stable [build at dick-wired ~]$ mach -f -r fedora-3-i386-core setup build warning: overriding lock on root fedora-3-i386-core umount: /var/lib/mach/roots/fedora-3-i386-core/proc: not mounted umount: /var/lib/mach/roots/fedora-3-i386-core/dev/pts: not mounted Installing group 'minimal' ...Traceback (most recent call last): File "/usr/bin/mach", line 1992, in ? main (config, sys.argv[1:]) File "/usr/bin/mach", line 1965, in main output = Root.__dict__[command] (root, args[1:]) File "/usr/bin/mach", line 857, in setup Root.__dict__[method] (self) File "/usr/bin/mach", line 1330, in _setup_minimal self._groupinstall ('minimal') File "/usr/bin/mach", line 1444, in _groupinstall self.group_installer(groups, "Installing group '%s'" % set, True) File "/usr/bin/mach", line 549, in group_installer (status, output) = do_with_output (command, progress) File "/usr/bin/mach", line 1603, in do_with_output return do_progress (command) File "/usr/bin/mach", line 1556, in do_progress (fdin, pid) = pty_popen (cmd) File "/usr/bin/mach", line 1533, in pty_popen pid, fd = os.forkpty () OSError: [Errno 13] Permission denied [build at dick-wired ~]$ mach -f -r fedora-3-i386-core clean Brutishly removing /var/lib/mach/roots/fedora-3-i386-core ...Traceback (most recent call last): File "/usr/bin/mach", line 1992, in ? main (config, sys.argv[1:]) File "/usr/bin/mach", line 1965, in main output = Root.__dict__[command] (root, args[1:]) File "/usr/bin/mach", line 802, in clean self._bruteclean () File "/usr/bin/mach", line 787, in _bruteclean (status, output) = do_with_output (command, True) File "/usr/bin/mach", line 1603, in do_with_output return do_progress (command) File "/usr/bin/mach", line 1556, in do_progress (fdin, pid) = pty_popen (cmd) File "/usr/bin/mach", line 1533, in pty_popen pid, fd = os.forkpty () OSError: [Errno 13] Permission denied [build at dick-wired ~]$ From petersen at redhat.com Fri May 13 00:44:50 2005 From: petersen at redhat.com (Jens Petersen) Date: Fri, 13 May 2005 09:44:50 +0900 Subject: Need review: ghc In-Reply-To: <1115919177.13475.4.camel@cutter> References: <428317E2.4030107@redhat.com> <0ML21M-1DWGn30deY-0005JZ@mrelayeu.kundenserver.de> <1115919177.13475.4.camel@cutter> Message-ID: <4283F882.9070805@redhat.com> seth vidal wrote: > On Thu, 2005-05-12 at 18:43 +0200, Jochen Schmitt wrote: > >>On Thu, 12 May 2005 17:46:26 +0900, you wrote: >> >>>ghc[..] requires [itself] to build. >>>Generating (arch dependent) bootstrap tarballs of C files >>>with ghc would depend on ghc anyway so the recommended way >>>to buildstrap ghc in buildroots is using pre-built binary >>>package: indeed the Debian maintainer tells me this is also >>>the way new archs are bootstrapped for debian. >>> >>>Signed binary packages for Fedora Core i386, ppc and x86_64 are >>>available from Fedora Haskell : Alternatively rpms generated directly from the official binary upstream tarballs for generic Linux or the Debian packages could be used instead if people are uncomfortable with using the above packages as seeds. > a package cannot [build]require itself. > that makes no sense at all. Erm, well actually it makes perfect sense for a compiler. :) How do you think gcc builds itself? As I said above it is possible to bootstrap ghc from C files, but those C files will be compiler generated by ghc - in a sense it would be a bit like doing part of the compilation in advance (think assembler not portable C) and so is really just pushing the problem over the packager, and it is a *lot* of work for zero gain. Once the initial ghc package is in Extras all subsequent builds of ghc will buildrequire ghc anyway. See also: http://haskell.org/ghc/docs/latest/html/building/sec-pre-supposed.html and http://haskell.org/ghc/docs/latest/html/building/sec-porting-ghc.html . Cheers, Jens From zipsonic at gmail.com Fri May 13 01:12:51 2005 From: zipsonic at gmail.com (Rick Stout) Date: Thu, 12 May 2005 18:12:51 -0700 Subject: Request for review: nx (Neal Becker)] Message-ID: <4283FF13.1030504@gmail.com> > Does this build on x86_64? Last time I tried it didn't. It will now build on x86_64, but due to some library differences, it still doesn't run on x86_64. Regards, Rick Stout From petersen at redhat.com Fri May 13 04:08:15 2005 From: petersen at redhat.com (Jens Petersen) Date: Fri, 13 May 2005 13:08:15 +0900 Subject: Need review: ghc In-Reply-To: <0ML21M-1DWGn30deY-0005JZ@mrelayeu.kundenserver.de> References: <428317E2.4030107@redhat.com> <0ML21M-1DWGn30deY-0005JZ@mrelayeu.kundenserver.de> Message-ID: <4284282F.9000503@redhat.com> Jochen Schmitt wrote: > Does the build system able to handle such a situation, that a > package need itself as a buildrequirement? Ok, to workaround this technical difficulty and to avoid the need to build the initial ghc package by hand in the buildsystem, I propose to make a seed source rpm including the upstream binary tarballs for Linux i386, ppc and x86_64 as a seed for Extras. (This is also essentially what gentoo does for ghc btw.) Once the binary seed packages have been "built" for Extras, then they can be used to build the real haskell source ghc package that is already in cvs. :-) Does that sound reasonable? :) We really really don't want to go through the agony of generating bootstrap C files for all three archs - it is just too much "fun"... believe me. Btw how does inheritance work in the buildsystem between OS versions? Say ghc is built first for FC-3, then later when we want to build it in devel or FC-4 say, will the buildroot get setup with the BR ghc from FC-3 automatically? I hope we don't want to have to go through all this again when ghc is added to devel say... :) Jens From petersen at redhat.com Fri May 13 04:58:45 2005 From: petersen at redhat.com (Jens Petersen) Date: Fri, 13 May 2005 13:58:45 +0900 Subject: Mach setup In-Reply-To: <4283D09A.4090106@six-by-nine.com.au> References: <4283D09A.4090106@six-by-nine.com.au> Message-ID: <42843405.2040101@redhat.com> Peter Lawler wrote: > Hi! > This mach thing looks neat, but I can't get it set up. I've taken it > from CVS, build my own rpm and installed it. Did you try Seth's mach+yum rpm? http://linux.duke.edu/~skvidal/mach/pkgs/ mach-0.4.6.1-1.yum.0.20050503.142547 works for me anyway on FC3. :) Jens From fedora-extras-list at six-by-nine.com.au Fri May 13 05:08:43 2005 From: fedora-extras-list at six-by-nine.com.au (Peter Lawler) Date: Fri, 13 May 2005 15:08:43 +1000 Subject: Mach setup In-Reply-To: <42843405.2040101@redhat.com> References: <4283D09A.4090106@six-by-nine.com.au> <42843405.2040101@redhat.com> Message-ID: <4284365B.8030706@six-by-nine.com.au> Jens Petersen wrote: > Peter Lawler wrote: > >> Hi! >> This mach thing looks neat, but I can't get it set up. I've taken it >> from CVS, build my own rpm and installed it. > > > Did you try Seth's mach+yum rpm? > > http://linux.duke.edu/~skvidal/mach/pkgs/ > > mach-0.4.6.1-1.yum.0.20050503.142547 works for me anyway on FC3. :) > Heh, no. But since this post, someone else pointed me in Seth's rpm's direction. BAD BAD Warren for telling me to use CVS. :-) I'll try these out over this weekend. Regards, Pete. From petersen at redhat.com Fri May 13 08:25:13 2005 From: petersen at redhat.com (Jens Petersen) Date: Fri, 13 May 2005 17:25:13 +0900 Subject: Need review: ghc In-Reply-To: <4284282F.9000503@redhat.com> References: <428317E2.4030107@redhat.com> <0ML21M-1DWGn30deY-0005JZ@mrelayeu.kundenserver.de> <4284282F.9000503@redhat.com> Message-ID: <42846469.2070607@redhat.com> Jens Petersen wrote: > to avoid the need to build the initial ghc package by hand in the buildsystem, > I propose to make a seed source rpm including the upstream binary tarballs > for Linux i386, ppc and x86_64 as a seed for Extras. Ok here it is: http://people.redhat.com/petersen/extras/ghc-6.4-1.src.rpm (67MB) http://people.redhat.com/petersen/extras/ghc.spec -Jens From petersen at redhat.com Fri May 13 09:06:34 2005 From: petersen at redhat.com (Jens Petersen) Date: Fri, 13 May 2005 18:06:34 +0900 Subject: Mach setup In-Reply-To: <42843405.2040101@redhat.com> References: <4283D09A.4090106@six-by-nine.com.au> <42843405.2040101@redhat.com> Message-ID: <42846E1A.3010807@redhat.com> Jens Petersen wrote: > mach-0.4.6.1-1.yum.0.20050503.142547 works for me anyway on FC3. :) I should probably qualify that by saying that "mach setup" works for me at least. :) And after installing coreutils by hand in the buildroots I'm able to run "mach chroot" and "mach build" too, but the latter runs into some problems since rpm isn't installed. Also I'm getting errors for all %pre (and %post?) scripts when I try to install packages with "rpm --root" or "mach yum". I guess it is still work in progress, and perhaps I'm missing something? :) Perhaps I should try cvs too... where is the cvsroot? -Jens From bugs.michael at gmx.net Fri May 13 10:10:12 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 13 May 2005 12:10:12 +0200 Subject: netcdf .a location In-Reply-To: <1115929962.2051.135.camel@ernie> References: <20050512191537.GD7304@plain.rackshack.net> <20050512221255.4e31eed9.bugs.michael@gmx.net> <1115929962.2051.135.camel@ernie> Message-ID: <20050513121012.45c07522.bugs.michael@gmx.net> On Thu, 12 May 2005 16:32:42 -0400, Ed Hill wrote: > The history of the netCDF packaging efforts are archived for your > reading pleasure at: > > https://bugzilla.fedora.us/show_bug.cgi?id=1874 > > My view is that the current arrangement is entirely usable (even if it > might be less-than-perfect) and I'm not at all interested in having > another "where-do-the-files-go" re-hash. So, unless theres an actual > bug or a violation of Fedora Extras policies [which I trust Michael > would point out--hes very astute! ;-)], I'm in no hurry to shuffle > things around. FWIW, I still like the %{_libdir}/netcdf-3/{include,lib} proposal made there. ;o) Namespace pollution is not much of an issue with NetCDF, as all but one file in netcdf-devel are prefixed with "netcdf". Piping header files directly into top-level include directory is not nice in either case, regardless of whether other software does it, too. -- Fedora Core release 3.91 (Pre-FC4) - Linux 2.6.11-1.1290_FC4 loadavg: 0.03 0.07 0.23 From nicolas.mailhot at laposte.net Fri May 13 10:58:52 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 13 May 2005 12:58:52 +0200 (CEST) Subject: Need review: ghc In-Reply-To: <4283F882.9070805@redhat.com> References: <428317E2.4030107@redhat.com> <0ML21M-1DWGn30deY-0005JZ@mrelayeu.kundenserver.de> <1115919177.13475.4.camel@cutter> <4283F882.9070805@redhat.com> Message-ID: <54737.192.54.193.28.1115981932.squirrel@rousalka.dyndns.org> On Ven 13 mai 2005 2:44, Jens Petersen a ?crit : > seth vidal wrote: >> a package cannot [build]require itself. >> that makes no sense at all. > > Erm, well actually it makes perfect sense for a compiler. :) > How do you think gcc builds itself? Actually we have a ton of those bootstraps loops in the java world. Sometimes they are obvious like this, other times it's more indirect. For example : a java lib is build using ant but ant needs a version of this same lib to build (because ant uses it for xml parsing, error logging, etc) In the end of the day for any given language you need to declare basic facilities part of the core platform (so not Requires) or add a seed package of these very same utilities to the repository to break dependency loops. Seed package can be pre-built binary, util version with all build options disabled, basic version only good enougth to build the real one, etc I imagine it's the same for all non-interpretated languages. Regards, -- Nicolas Mailhot From ndbecker2 at gmail.com Fri May 13 11:29:15 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 13 May 2005 07:29:15 -0400 Subject: wxPython requires python-2.3 Message-ID: I just tried to install wxPython on FC4T3, using rawhide and extras-devel as repos, and yum says that wxPython needs python-2.3. From bugs.michael at gmx.net Fri May 13 11:51:30 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 13 May 2005 13:51:30 +0200 Subject: wxPython requires python-2.3 In-Reply-To: References: Message-ID: <20050513135130.49024220.bugs.michael@gmx.net> On Fri, 13 May 2005 07:29:15 -0400, Neal Becker wrote: > I just tried to install wxPython on FC4T3, using rawhide and extras-devel as > repos, and yum says that wxPython needs python-2.3. Which architecture? Which version of wxPythonGTK2? Both versions of wxPythonGTK2 in the extras-development repository are good. Bug reports should go into http://bugzilla.redhat.com -- Fedora Core release 3.91 (Pre-FC4) - Linux 2.6.11-1.1290_FC4 loadavg: 2.14 1.37 1.26 From rc040203 at freenet.de Fri May 13 12:20:02 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 13 May 2005 14:20:02 +0200 Subject: Need review: ghc In-Reply-To: <54737.192.54.193.28.1115981932.squirrel@rousalka.dyndns.org> References: <428317E2.4030107@redhat.com> <0ML21M-1DWGn30deY-0005JZ@mrelayeu.kundenserver.de> <1115919177.13475.4.camel@cutter> <4283F882.9070805@redhat.com> <54737.192.54.193.28.1115981932.squirrel@rousalka.dyndns.org> Message-ID: <1115986802.8237.557.camel@mccallum.corsepiu.local> On Fri, 2005-05-13 at 12:58 +0200, Nicolas Mailhot wrote: > On Ven 13 mai 2005 2:44, Jens Petersen a ?crit : > > seth vidal wrote: > > >> a package cannot [build]require itself. > >> that makes no sense at all. > > > > Erm, well actually it makes perfect sense for a compiler. :) > > How do you think gcc builds itself? > > Actually we have a ton of those bootstraps loops in the java world. > Sometimes they are obvious like this, other times it's more indirect. For > example : > a java lib is build using ant but ant needs a version of this same lib to > build (because ant uses it for xml parsing, error logging, etc) > > In the end of the day for any given language you need to declare basic > facilities part of the core platform (so not Requires) or add a seed > package of these very same utilities to the repository to break dependency > loops. The classical example for such a dependency chain on Linux is binutils, "c-compiler", libc and kernel - They all circularly depend on each other. > Seed package can be pre-built binary, util version with all build options > disabled, basic version only good enougth to build the real one, etc > > I imagine it's the same for all non-interpretated languages. Well, not quite - Or a matter of perspective and of compiler design. In GCC, the "seed" to any compiler/language is "a native c-toolchain", i.e. all compilers and all libraries are rooted at having "a native c- toolchain", i.e. to build any language you at minimum need a "c- toolchain". On Linux systems, this "native c-toolchain" typically will be an older GCC. This "native c-toolchain" then is used to build a "new native c-GCC", which then later is being used to build other languages. At this point, a compiler's design come into play. There exist languages in GCC which can be built with a c-only compiler (e.g. fortran), there exist languages which require a language specific-compiler (e.g. Ada). To work around all these problems GCC is being built multiple times (offical term: "multi-staged bootstrap"). What Jens describes, looks like an incomplete multi-staged bootstrap, with him wanting to take the "dirty" short-circuit. In theory, one would have 1. To bootstrap/build/provide the toolchains infrastructure needed to build a compiler with system-resources, only. 2. To bootstrap the toolchain using the resources having been build by step 1. Then it might be necessary to reiterate through steps 1.-2. several times, until a clean system has been built. In practice, this can become tedious, in some (exceptional) cases there exist situations where this is impossible to implement (IMO this is a strong indication for a badly designed toolchain), and one has to/or might want to prefer to resort to a short-cut solution, such a Jens. Try building a cross-GCC-4.0-GNAT toolchain on FC3 and you probably understand what I am talking about. I do this regularly and could write novels on this topic :-) To cut a long story short: I agree, there exist situations were building a package requires a binary of an older version of itself. In most cases these are strong symptoms of bad design which should be fixed upstream. In practice, these are inevitable, and are easy to work-around: Insert a binary package having been built outside of the buildsystem into the buildsystem once, and then use this binary package to rebuild the package. Ralf From bugs.michael at gmx.net Fri May 13 14:06:38 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 13 May 2005 16:06:38 +0200 Subject: common tobuild,1.442,1.443 In-Reply-To: <200505131320.j4DDKNc3021165@cvs-int.fedora.redhat.com> References: <200505131320.j4DDKNc3021165@cvs-int.fedora.redhat.com> Message-ID: <20050513160638.49bc1361.bugs.michael@gmx.net> On Fri, 13 May 2005 09:20:23 -0400, Michael Schwendt wrote: > Author: mschwendt > > Update of /cvs/extras/common > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv21148 > > Modified Files: > tobuild > Log Message: > request build of rpms/gnupg2/devel gnupg2-1_9_16-3_fc4 for devel x86_64 build system is broken currently, gives 404 not found for initscripts as repository seems to do its mirroring or something like that. Trying again later... From ndbecker2 at gmail.com Fri May 13 15:27:58 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 13 May 2005 11:27:58 -0400 Subject: Building KDE apps on FC4T3 (gcc4) Message-ID: I'm trying to build pwmanager-1.2.1 on FC4T3. Here's what happens: checking whether gcc is blacklisted... yes configure: error: [...] This seems to come from admin/acinclude.m4.in Anyone know what I should do to fix this? It seems gcc-4.0.0 is explicity blacklisted. From fedora at camperquake.de Fri May 13 15:39:02 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 13 May 2005 17:39:02 +0200 Subject: Building KDE apps on FC4T3 (gcc4) In-Reply-To: References: Message-ID: <20050513153902.GA11911@ryoko.camperquake.de> On Fri, May 13, 2005 at 11:27:58AM -0400, Neal Becker wrote: > Anyone know what I should do to fix this? It seems gcc-4.0.0 is explicity > blacklisted. gcc4 is known to miscompile some things in kde (has happened a few times during FC4 development so far). I do not know the current state of affairs wrt. the Fedora gcc4 and the Fedora kde. From adrian at lisas.de Fri May 13 16:01:18 2005 From: adrian at lisas.de (Adrian Reber) Date: Fri, 13 May 2005 18:01:18 +0200 Subject: Request for review: netselect Message-ID: <20050513160118.GA17721@lisas.de> http://lisas.de/~adrian/rpm/netselect-0.3-1.src.rpm An ultrafast intelligent parallelizing binary-search implementation of "ping". http://www.worldvisions.ca/~apenwarr/netselect/ In addition to the netselect program I have added a shell sript which reads the repo files and replaces the mirrorlist with the "best mirror". The best mirror is only determined by netselect which probably isn't the best way to select a mirror but it is a start. Adrian From a.kurtz at hardsun.net Fri May 13 17:52:32 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Fri, 13 May 2005 10:52:32 -0700 Subject: Request for review: netselect In-Reply-To: <20050513160118.GA17721@lisas.de> References: <20050513160118.GA17721@lisas.de> Message-ID: <1116006752.4707.15.camel@rydia.hardsun.net> On Fri, 2005-05-13 at 18:01 +0200, Adrian Reber wrote: > http://lisas.de/~adrian/rpm/netselect-0.3-1.src.rpm > > An ultrafast intelligent parallelizing binary-search > implementation of "ping". > > http://www.worldvisions.ca/~apenwarr/netselect/ > > In addition to the netselect program I have added a shell sript which > reads the repo files and replaces the mirrorlist with the "best mirror". > The best mirror is only determined by netselect which probably isn't the > best way to select a mirror but it is a start. Ah, apt-spy for Fedora. Good. - Do not use install -s to strip binaries - RPM handles this and sticks the information in a -debuginfo RPM. Plus, it dies on FC4t3 trying to strip the netselect-yum shell script. Whoops. - Considering this is Fedora Extras, an entirely separate -yum package is a bit unnecessary. Just roll it in. - This needs to run as root all the time? Some mention of this would be good. = DistTags. http://fedoraproject.org/wiki/DistTag = Perhaps rather than hitting all the mirrors, netselect-yum could hit just a region? Ideally this could be taken from /etc/sysconfig/clock's ZONE= setting. + SHA1SUMs check out, builds just fine once install -s has been fixed. -- Aaron Kurtz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Fri May 13 17:59:21 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 13 May 2005 19:59:21 +0200 Subject: Building KDE apps on FC4T3 (gcc4) In-Reply-To: <20050513153902.GA11911@ryoko.camperquake.de> References: <20050513153902.GA11911@ryoko.camperquake.de> Message-ID: <20050513195921.193f0177.bugs.michael@gmx.net> On Fri, 13 May 2005 17:39:02 +0200, Ralf Ertzinger wrote: > On Fri, May 13, 2005 at 11:27:58AM -0400, Neal Becker wrote: > > > Anyone know what I should do to fix this? It seems gcc-4.0.0 is explicity > > blacklisted. > > gcc4 is known to miscompile some things in kde (has happened a few times > during FC4 development so far). I do not know the current state of affairs > wrt. the Fedora gcc4 and the Fedora kde. Encountered such a version check in latest k3b (0.11.24) for k3b-mp3 and simply took out the check. It only examines GCC's version macros and does not take into account that patches may have been applied. For instance, when I look at "rpm --query --changelog gcc" I see lots of patch-work, such as fixes from CVS. And since Fedora Core 4 Development including KDE is built with the same compiler, I believe that Red Hat's compiler engineers work on fixing any problems that miscompile KDE. Blacklisting a specific GCC version may be useful for people, who use a pristine release of GCC, but is not useful for Fedora Core users. It reminds me somewhat of Red Hat's GCC 2.96, which was hated by many people, because of initial bugs and because it was so close to GCC 3 that it rejected a lot of non-standards compliant C/C++ code. -- Fedora Core release 3.91 (Pre-FC4) - Linux 2.6.11-1.1290_FC4 loadavg: 1.50 1.43 0.82 From ville.skytta at iki.fi Fri May 13 18:28:36 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 13 May 2005 21:28:36 +0300 Subject: Mach setup In-Reply-To: <42846E1A.3010807@redhat.com> References: <4283D09A.4090106@six-by-nine.com.au> <42843405.2040101@redhat.com> <42846E1A.3010807@redhat.com> Message-ID: <1116008916.14907.77.camel@bobcat.mine.nu> On Fri, 2005-05-13 at 18:06 +0900, Jens Petersen wrote: > Perhaps I should try cvs too... where is the cvsroot? Just added info about that to Wiki, see bottom of http://fedoraproject.org/wiki/UsingMach From fedora-extras-list at six-by-nine.com.au Fri May 13 19:50:49 2005 From: fedora-extras-list at six-by-nine.com.au (Peter Lawler) Date: Sat, 14 May 2005 05:50:49 +1000 Subject: Mach setup In-Reply-To: <4284365B.8030706@six-by-nine.com.au> References: <4283D09A.4090106@six-by-nine.com.au> <42843405.2040101@redhat.com> <4284365B.8030706@six-by-nine.com.au> Message-ID: <42850519.3060808@six-by-nine.com.au> Hi! I still get the same error as before: mach -r fedora-development-`uname -i`-core setup build Preparing root Making /dev devices Installing group 'minimal' ...Traceback (most recent call last): File "/usr/bin/mach", line 1991, in ? main (config, sys.argv[1:]) File "/usr/bin/mach", line 1964, in main output = Root.__dict__[command] (root, args[1:]) File "/usr/bin/mach", line 857, in setup Root.__dict__[method] (self) File "/usr/bin/mach", line 1329, in _setup_minimal self._groupinstall ('minimal') File "/usr/bin/mach", line 1443, in _groupinstall self.group_installer(groups, "Installing group '%s'" % set, True) File "/usr/bin/mach", line 549, in group_installer (status, output) = do_with_output (command, progress) File "/usr/bin/mach", line 1602, in do_with_output return do_progress (command) File "/usr/bin/mach", line 1555, in do_progress (fdin, pid) = pty_popen (cmd) File "/usr/bin/mach", line 1532, in pty_popen pid, fd = os.forkpty () OSError: [Errno 13] Permission denied Anyone got any more ideas? Pete. Peter Lawler wrote: > > > Jens Petersen wrote: > >> Peter Lawler wrote: >> >>> Hi! >>> This mach thing looks neat, but I can't get it set up. I've taken it >>> from CVS, build my own rpm and installed it. >> >> Did you try Seth's mach+yum rpm? >> >> http://linux.duke.edu/~skvidal/mach/pkgs/ >> >> mach-0.4.6.1-1.yum.0.20050503.142547 works for me anyway on FC3. :) >> > > Heh, no. But since this post, someone else pointed me in Seth's rpm's > direction. BAD BAD Warren for telling me to use CVS. :-) > > I'll try these out over this weekend. > From tibbs at math.uh.edu Fri May 13 20:12:29 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 13 May 2005 15:12:29 -0500 Subject: New package: denyhosts Message-ID: Denyhosts is a little bit of Python called out of cron that looks through /var/log/secure, picks out hosts doing those annoying mass SSH login attempts and stuffs them in /etc/hosts.deny. It lives at http://denyhosts.sf.net I'm relatively new at this, but I needed to make a package for denyhosts to deploy on my externally-facing login boxes and figured I'd try to do it the right way. There aren't many packages that would be simpler. RPM (not signed) and .spec are in http://www.math.uh.edu/~tibbs/denyhosts Various bits were cribbed from the yum package. I tried to please rpmlint, but it seems to complain excessively: W: denyhosts conffile-without-noreplace-flag /etc/rc.d/init.d/denyhosts E: denyhosts executable-marked-as-config-file /etc/rc.d/init.d/denyhosts I don't understand what I should do here; I copied what yum does. E: denyhosts zero-length /var/lib/denyhosts/offset E: denyhosts zero-length /var/lib/denyhosts/users-valid E: denyhosts zero-length /var/lib/denyhosts/suspicious-logins E: denyhosts zero-length /var/lib/denyhosts/users-invalid E: denyhosts zero-length /var/lib/denyhosts/users-hosts E: denyhosts zero-length /var/lib/denyhosts/hosts I'm not sure how to handle the files in /var/lib; they will be created on the first run (with warnings) but they should probably be removed when the package is. Just owning %{_localstatedir}/lib/denyhosts didn't seem good enough for that. E: denyhosts non-readable /etc/denyhosts.conf 0600 E: denyhosts non-standard-dir-perm /var/lib/denyhosts 0700 It's kind of dumb to complain about restrictive permissions for a system daemon. E: denyhosts no-signature E: denyhosts no-chkconfig-line /etc/rc.d/init.d/denyhosts The init.d file does have a chkconfig line, but rpmlint is picky about spaces versus tabs. I welcome your comments. If anyone believes that it would be useful to import this, I suppose I would need a sponsor. Thanks for your time, -- 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 jfontain at free.fr Fri May 13 20:24:03 2005 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Fri, 13 May 2005 22:24:03 +0200 Subject: New package: denyhosts In-Reply-To: References: Message-ID: <42850CE3.9080706@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jason L Tibbitts III wrote: > Denyhosts is a little bit of Python called out of cron that looks > through /var/log/secure, picks out hosts doing those annoying mass > SSH login attempts and stuffs them in /etc/hosts.deny. It lives at > http://denyhosts.sf.net > > I'm relatively new at this, but I needed to make a package for > denyhosts to deploy on my externally-facing login boxes and figured > I'd try to do it the right way. There aren't many packages that > would be simpler. RPM (not signed) and .spec are in > http://www.math.uh.edu/~tibbs/denyhosts > > Various bits were cribbed from the yum package. I tried to please > rpmlint, but it seems to complain excessively: > > W: denyhosts conffile-without-noreplace-flag > /etc/rc.d/init.d/denyhosts E: denyhosts > executable-marked-as-config-file /etc/rc.d/init.d/denyhosts I'd use this in files: %_initrddir/denyhosts Seems to make rpmlint happy with my package. - -- Jean-Luc Fontaine http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFChQzjkG/MMvcT1qQRApokAJ9t0fde1MAoqWLiCR1TzIAqIsaYEQCgux0T lxXcOJW49vyhJYaBDhwWsWQ= =8vU3 -----END PGP SIGNATURE----- From jpo at di.uminho.pt Fri May 13 20:28:38 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Fri, 13 May 2005 21:28:38 +0100 Subject: New package: denyhosts In-Reply-To: References: Message-ID: <42850DF6.8000601@di.uminho.pt> Jason, > E: denyhosts zero-length /var/lib/denyhosts/offset > E: denyhosts zero-length /var/lib/denyhosts/users-valid > E: denyhosts zero-length /var/lib/denyhosts/suspicious-logins > E: denyhosts zero-length /var/lib/denyhosts/users-invalid > E: denyhosts zero-length /var/lib/denyhosts/users-hosts > E: denyhosts zero-length /var/lib/denyhosts/hosts > > I'm not sure how to handle the files in /var/lib; they will be created > on the first run (with warnings) but they should probably be removed > when the package is. Just owning %{_localstatedir}/lib/denyhosts > didn't seem good enough for that. Check the %ghost directive: http://rpm-devel.colug.net/max-rpm/s1-rpm-inside-files-list-directives.html jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From daniel-wittenberg at starken.com Fri May 13 20:40:10 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Fri, 13 May 2005 15:40:10 -0500 Subject: Epoch + snort sponser In-Reply-To: <80d7e409050511094976e46cb2@mail.gmail.com> References: <1115701804.25390.7.camel@plasma.starken.com> <80d7e409050510164830c08c2a@mail.gmail.com> <1115772905.5219.0.camel@localhost.localdomain> <80d7e409050511094976e46cb2@mail.gmail.com> Message-ID: <1116016810.16434.11.camel@plasma.starken.com> Yeah, I was tyring to find a way to detect if it was a Fedora system or not, but didn't come up with anything. Anyone? Dan On Wed, 2005-05-11 at 10:49 -0600, Stephen J. Smoogen wrote: > The one big thing I think that looking at the other fedora extras is > that switches are frowned on in the auto-build system. I am thinking > that for fedora a lot of the entries should be 1 versus 0 > > %define flexresp 1 > %define mysql 1 > %define postgresql 1 > > similar to how the caos one is done. I wonder if there is a %undefine > RPM command.. as that would allow for the spec to cover the items that > arent to be defined for Extras rpms (vendor, distro). From paul at city-fan.org Fri May 13 20:51:07 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 13 May 2005 21:51:07 +0100 Subject: Epoch + snort sponser In-Reply-To: <1116016810.16434.11.camel@plasma.starken.com> References: <1115701804.25390.7.camel@plasma.starken.com> <80d7e409050510164830c08c2a@mail.gmail.com> <1115772905.5219.0.camel@localhost.localdomain> <80d7e409050511094976e46cb2@mail.gmail.com> <1116016810.16434.11.camel@plasma.starken.com> Message-ID: <1116017467.4628.64.camel@laurel.intra.city-fan.org> On Fri, 2005-05-13 at 15:40 -0500, Daniel Wittenberg wrote: > Yeah, I was tyring to find a way to detect if it was a Fedora system or > not, but didn't come up with anything. > > Anyone? > > Dan > > On Wed, 2005-05-11 at 10:49 -0600, Stephen J. Smoogen wrote: > > The one big thing I think that looking at the other fedora extras is > > that switches are frowned on in the auto-build system. I am thinking > > that for fedora a lot of the entries should be 1 versus 0 > > > > %define flexresp 1 > > %define mysql 1 > > %define postgresql 1 > > > > similar to how the caos one is done. I wonder if there is a %undefine > > RPM command.. as that would allow for the spec to cover the items that > > arent to be defined for Extras rpms (vendor, distro). Perhaps something like what's described at: http://fedoraproject.org/wiki/DistTag? action=highlight&value=CategoryExtras # Do something special if we're built for RHEL. %if !0%{?fedora} Vendor: blah Packager: blah %endif Paul. -- Paul Howarth From linuxerwang at gmail.com Fri May 13 21:53:08 2005 From: linuxerwang at gmail.com (Linuxer Wang) Date: Fri, 13 May 2005 14:53:08 -0700 Subject: How to build Octave under FC4 test3 Message-ID: <428521C4.1030204@gmail.com> Hello, everyone I find that octave has been moved from core to the extras, but I don't know how to compile it. Can anyone tell me how to do it? Thank you so much. From mattdm at mattdm.org Fri May 13 22:02:56 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 13 May 2005 18:02:56 -0400 Subject: How to build Octave under FC4 test3 In-Reply-To: <428521C4.1030204@gmail.com> References: <428521C4.1030204@gmail.com> Message-ID: <20050513220256.GA14010@jadzia.bu.edu> On Fri, May 13, 2005 at 02:53:08PM -0700, Linuxer Wang wrote: > I find that octave has been moved from core to the extras, but I don't > know how to compile it. Can anyone tell me how to do it? > Thank you so much. You shouldn't have to -- just install the RPMs from Extras. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From linuxerwang at gmail.com Fri May 13 22:12:20 2005 From: linuxerwang at gmail.com (Linuxer Wang) Date: Fri, 13 May 2005 15:12:20 -0700 Subject: How to build Octave under FC4 test3 In-Reply-To: <20050513220256.GA14010@jadzia.bu.edu> References: <428521C4.1030204@gmail.com> <20050513220256.GA14010@jadzia.bu.edu> Message-ID: <42852644.4010502@gmail.com> But where can I find the RPM package, I searched the Extras but not found. Thank you Matthew Miller wrote: >On Fri, May 13, 2005 at 02:53:08PM -0700, Linuxer Wang wrote: > > >>I find that octave has been moved from core to the extras, but I don't >>know how to compile it. Can anyone tell me how to do it? >>Thank you so much. >> >> > >You shouldn't have to -- just install the RPMs from Extras. > > > From bugs.michael at gmx.net Fri May 13 22:19:25 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 14 May 2005 00:19:25 +0200 Subject: How to build Octave under FC4 test3 In-Reply-To: <20050513220256.GA14010@jadzia.bu.edu> References: <428521C4.1030204@gmail.com> <20050513220256.GA14010@jadzia.bu.edu> Message-ID: <20050514001925.0d7d531e.bugs.michael@gmx.net> On Fri, 13 May 2005 18:02:56 -0400, Matthew Miller wrote: > On Fri, May 13, 2005 at 02:53:08PM -0700, Linuxer Wang wrote: > > I find that octave has been moved from core to the extras, but I don't > > know how to compile it. Can anyone tell me how to do it? > > Thank you so much. > > You shouldn't have to -- just install the RPMs from Extras. As discussed yesterday (or the day before), Octave failed to build on x86_64 (because of Standard C++ i386 headers being installed instead of x86_64 headers), and hence no builds are available yet. But building from Fedora Extras CVS should work. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1303_FC4 loadavg: 1.27 1.13 1.11 From linuxerwang at gmail.com Fri May 13 23:03:47 2005 From: linuxerwang at gmail.com (Linuxer Wang) Date: Fri, 13 May 2005 16:03:47 -0700 Subject: How to build Octave under FC4 test3 In-Reply-To: <20050514001925.0d7d531e.bugs.michael@gmx.net> References: <428521C4.1030204@gmail.com> <20050513220256.GA14010@jadzia.bu.edu> <20050514001925.0d7d531e.bugs.michael@gmx.net> Message-ID: <42853253.30505@gmail.com> I applied the patch in Extras cvs and compile, it proceeds more than without the patch, but finally, I get the following errors: ../liboctave/liboctave.a(file-ops.o)(.text+0x33ec): In function `file_ops::tempnam(std::basic_string, std::allocator > const&, std::basic_string, std::allocator > const&, std::basic_string, std::allocator >&)': /home/kenny/download/rpms/octave/devel/src/liboctave/file-ops.cc:420: warning: the use of `tempnam' is dangerous, better use `mkstemp' ../libcruft/libcruft.a(zbdsqr.o)(.text+0x8c5): In function `zbdsqr_': zbdsqr.f: undefined reference to `zdrot_' ../libcruft/libcruft.a(zbdsqr.o)(.text+0x924):zbdsqr.f: undefined reference to `zdrot_' ../libcruft/libcruft.a(zbdsqr.o)(.text+0x96d):zbdsqr.f: undefined reference to `zdrot_' collect2: ld returned 1 exit status make[2]: *** [octave] Error 1 make[2]: Leaving directory `/home/kenny/download/rpms/octave/devel/src/src' make[1]: *** [src] Error 2 make[1]: Leaving directory `/home/kenny/download/rpms/octave/devel/src' make: *** [all] Error 2 Michael Schwendt wrote: >On Fri, 13 May 2005 18:02:56 -0400, Matthew Miller wrote: > > > >>On Fri, May 13, 2005 at 02:53:08PM -0700, Linuxer Wang wrote: >> >> >>>I find that octave has been moved from core to the extras, but I don't >>>know how to compile it. Can anyone tell me how to do it? >>>Thank you so much. >>> >>> >>You shouldn't have to -- just install the RPMs from Extras. >> >> > >As discussed yesterday (or the day before), Octave failed to build on >x86_64 (because of Standard C++ i386 headers being installed instead of >x86_64 headers), and hence no builds are available yet. But building >from Fedora Extras CVS should work. > > > From bugs.michael at gmx.net Fri May 13 23:37:37 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 14 May 2005 01:37:37 +0200 Subject: How to build Octave under FC4 test3 In-Reply-To: <42853253.30505@gmail.com> References: <428521C4.1030204@gmail.com> <20050513220256.GA14010@jadzia.bu.edu> <20050514001925.0d7d531e.bugs.michael@gmx.net> <42853253.30505@gmail.com> Message-ID: <20050514013737.64310ae8.bugs.michael@gmx.net> On Fri, 13 May 2005 16:03:47 -0700, Linuxer Wang wrote: > I applied the patch in Extras cvs and compile, it proceeds more than > without the patch, but finally, I get the following errors: -snip- I don't know what you tried to apply against what and why you did not just rebuild what can be found in Extras CVS, so look here: http://extras64.linux.duke.edu/failed/development/octave/2.1.70-1/i386/ It's the i386 binaries as created by the Fedora Extras build system before it failed on x86_64. Oh, and please don't top-post. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1303_FC4 loadavg: 1.27 1.94 2.11 From ryo-dairiki at mbm.nifty.com Sat May 14 00:50:26 2005 From: ryo-dairiki at mbm.nifty.com (=?ISO-2022-JP?B?GyRCQmdOT048GyhC?=) Date: Sat, 14 May 2005 09:50:26 +0900 Subject: Approval needed: SCIM Message-ID: <42854B52.2080308@mbm.nifty.com> Hi, I'm thinking of adding the package of SCIM into Extras. Could anyone review it and give me an approval? You can see it here: http://briefcase.yahoo.co.jp/bc/ryo_dairiki/lst?.dir=/ Please download scim-1.2.2-1.src.rpm. Regards, Ryo Dairiki From petersen at redhat.com Sat May 14 03:16:17 2005 From: petersen at redhat.com (Jens Petersen) Date: Sat, 14 May 2005 12:16:17 +0900 Subject: Mach setup In-Reply-To: <42850519.3060808@six-by-nine.com.au> References: <4283D09A.4090106@six-by-nine.com.au> <42843405.2040101@redhat.com> <4284365B.8030706@six-by-nine.com.au> <42850519.3060808@six-by-nine.com.au> Message-ID: <42856D81.5040001@redhat.com> With anoncvs head of extras-buildsys-temp on FC-3 and rawhide, "mach setup" is ok, but not "mach setup build": % mach clean Brutishly removing /var/lib/mach/roots/fedora-3-i386-core ............. % mach setup build Preparing root Making /dev devices Installing group 'minimal' ...... Installing group 'base' .... Non-zero return value 127 on executing /usr/sbin/mach-helper chroot /var/lib/mach/roots/fedora-3-i386-core /sbin/runuser - root -c "mv /tmp/macros /etc/rpm" Traceback (most recent call last): File "/usr/bin/mach", line 1992, in ? main (config, sys.argv[1:]) File "/usr/bin/mach", line 1965, in main output = Root.__dict__[command] (root, args[1:]) File "/usr/bin/mach", line 857, in setup Root.__dict__[method] (self) File "/usr/bin/mach", line 1366, in _setup_build self.do_chroot ('mv /tmp/macros /etc/rpm', fatal = True) File "/usr/bin/mach", line 629, in do_chroot exit (ret) File "/usr/bin/mach", line 1528, in exit unlock (config) File "/usr/bin/mach", line 1781, in unlock statedir = get_config_dir (config, 'state') File "/usr/bin/mach", line 1706, in get_config_dir return config['dirs'][which + 's'] + '/' + config['root'] TypeError: unsubscriptable object Btw is this the right place to discuss mach+yum? :) Jens ps Why is coreutils not included in base btw? From fedora-extras-list at six-by-nine.com.au Sat May 14 04:15:52 2005 From: fedora-extras-list at six-by-nine.com.au (Peter Lawler) Date: Sat, 14 May 2005 14:15:52 +1000 Subject: Mach setup In-Reply-To: <42856D81.5040001@redhat.com> References: <4283D09A.4090106@six-by-nine.com.au> <42843405.2040101@redhat.com> <4284365B.8030706@six-by-nine.com.au> <42850519.3060808@six-by-nine.com.au> <42856D81.5040001@redhat.com> Message-ID: <42857B78.6080605@six-by-nine.com.au> Jens Petersen wrote: > TypeError: unsubscriptable object > > Btw is this the right place to discuss mach+yum? :) > No idea, Jens, but that's the same as me :-) From j.w.r.degoede at hhs.nl Sat May 14 06:05:48 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 14 May 2005 08:05:48 +0200 Subject: Approval needed: SCIM In-Reply-To: <42854B52.2080308@mbm.nifty.com> References: <42854B52.2080308@mbm.nifty.com> Message-ID: <4285953C.7080904@hhs.nl> What does it do? ??? wrote: > Hi, > I'm thinking of adding the package of SCIM into Extras. > Could anyone review it and give me an approval? > > You can see it here: > http://briefcase.yahoo.co.jp/bc/ryo_dairiki/lst?.dir=/ > > Please download scim-1.2.2-1.src.rpm. > > Regards, > Ryo Dairiki > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From wtogami at redhat.com Sat May 14 07:58:26 2005 From: wtogami at redhat.com (Warren Togami) Date: Fri, 13 May 2005 21:58:26 -1000 Subject: Approval needed: SCIM In-Reply-To: <42854B52.2080308@mbm.nifty.com> References: <42854B52.2080308@mbm.nifty.com> Message-ID: <4285AFA2.1030304@redhat.com> ??? wrote: > Hi, > I'm thinking of adding the package of SCIM into Extras. > Could anyone review it and give me an approval? > > You can see it here: > http://briefcase.yahoo.co.jp/bc/ryo_dairiki/lst?.dir=/ > > Please download scim-1.2.2-1.src.rpm. > > Regards, > Ryo Dairiki > NOTE: This is not a complete review. Please use attached spec patch. - Never include Packager tag - Requires not necessary, they will be implicitly Required - %clean can be simpler Assuming the sources match upstream, this is good enough, but I'd like Jens Petersen to do a sanity check since he has experience with this software. If someone else is willing to approve it before Jens Petersen, that is fine too. Additionally the binaries needlessly contain /usr/lib64 in RPATH when this is built on x86_64. This is not a huge problem, but would be nice to remove. + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot ERROR: file '/usr/bin/scim-config-agent' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR: file '/usr/bin/scim' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR: file '/usr/lib64/libscim-gtkutils-1.0.so.6.1.1' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR: file '/usr/lib64/gtk-2.0/immodules/im-scim.so' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR: file '/usr/lib64/scim-1.0/1.2.0/Config/socket.so' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR: file '/usr/lib64/scim-1.0/1.2.0/Config/simple.so' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR: file '/usr/lib64/scim-1.0/1.2.0/SetupUI/frontend-hotkeys-setup.so' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR: file '/usr/lib64/scim-1.0/1.2.0/SetupUI/aaa-imengine-setup.so' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR: file '/usr/lib64/scim-1.0/1.2.0/SetupUI/panel-gtk-setup.so' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR: file '/usr/lib64/scim-1.0/1.2.0/SetupUI/x11-frontend-setup.so' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR: file '/usr/lib64/scim-1.0/1.2.0/FrontEnd/x11.so' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR: file '/usr/lib64/scim-1.0/1.2.0/FrontEnd/socket.so' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR: file '/usr/lib64/scim-1.0/1.2.0/IMEngine/rawcode.so' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR: file '/usr/lib64/scim-1.0/1.2.0/IMEngine/socket.so' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR: file '/usr/lib64/scim-1.0/1.2.0/Helper/setup.so' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR: file '/usr/lib64/scim-1.0/scim-panel-gtk' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR: file '/usr/lib64/scim-1.0/scim-helper-launcher' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR: file '/usr/lib64/scim-1.0/scim-launcher' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR: file '/usr/lib64/scim-1.0/scim-helper-manager' contains a standard rpath '/usr/lib64' in [/usr/lib64] error: Bad exit status from /var/tmp/rpm-tmp.89791 (%install) -------------- next part -------------- A non-text attachment was scrubbed... Name: scim.spec.diff Type: text/x-patch Size: 1415 bytes Desc: not available URL: From petersen at redhat.com Sat May 14 11:22:48 2005 From: petersen at redhat.com (Jens Petersen) Date: Sat, 14 May 2005 20:22:48 +0900 Subject: Approval needed: SCIM In-Reply-To: <42854B52.2080308@mbm.nifty.com> References: <42854B52.2080308@mbm.nifty.com> Message-ID: <4285DF88.4070509@redhat.com> ??? wrote: > Could anyone review it and give me an approval? > > You can see it here: > http://briefcase.yahoo.co.jp/bc/ryo_dairiki/lst?.dir=/ > > Please download scim-1.2.2-1.src.rpm. Thanks looks much better now. :) I did a bit more cleanup and fixing. Could you take a look at the attached patch against your version. With these changes I think the package can basically be approved for inclusion. Cheers, Jens -------------- next part -------------- A non-text attachment was scrubbed... Name: scim-extras-cleanup.patch Type: text/x-patch Size: 6066 bytes Desc: not available URL: From petersen at redhat.com Sat May 14 11:29:33 2005 From: petersen at redhat.com (Jens Petersen) Date: Sat, 14 May 2005 20:29:33 +0900 Subject: Approval needed: SCIM In-Reply-To: <4285953C.7080904@hhs.nl> References: <42854B52.2080308@mbm.nifty.com> <4285953C.7080904@hhs.nl> Message-ID: <4285E11D.5060700@redhat.com> Hans de Goede wrote: > What does it do? Good question. SCIM is the Smart Common Input Method. Quoting from : "Welcome to Smart Common Input Method platform project, (in short SCIM), which provides not only a user friendly and full featured input method user interface [...], but also a development platform to make Input Method developer life easier." -Jens From petersen at redhat.com Sat May 14 11:37:55 2005 From: petersen at redhat.com (Jens Petersen) Date: Sat, 14 May 2005 20:37:55 +0900 Subject: Approval needed: SCIM In-Reply-To: <4285DF88.4070509@redhat.com> References: <42854B52.2080308@mbm.nifty.com> <4285DF88.4070509@redhat.com> Message-ID: <4285E313.8000100@redhat.com> A few more comments: Jens Petersen wrote: > -Release: 1%{?dist} > +Release: 9 Actually I don't know %dist is that an Extras-ism? Perhaps it should stay? > Requires: glib2 >= 2.0.0, gtk2 >= 2.3.5, pango >= 1.0.0, XFree86-libs >= 4.1.0 I agree with Warren this should go for Extras: unneeded and FC is well above these versions anyway. > BuildRequires: gtk2-devel >= 2.0.0, pango-devel >= 1.0.0, XFree86-devel >= 4.1.0, pkgconfig >= 0.12, desktop-file-utils Probably the versions should be dropped here too, though that is less important. > # Kill all .a and .la It is also debatable whether any .a and .la files need to be included in _libdir at all too. > %post > +set -x Oops, please ignore this... :) -Jens From mattdm at mattdm.org Sat May 14 14:07:53 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 14 May 2005 10:07:53 -0400 Subject: Craving Approval: python-ZSI, python-SOAPpy, python-fpconst Message-ID: <20050514140753.GA4071@jadzia.bu.edu> If someone could take a look at these and give me a thumbs-up for import, I'd appreciate it: . Thanks. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tcallawa at redhat.com Sat May 14 15:09:04 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 14 May 2005 10:09:04 -0500 Subject: Approval needed: SCIM In-Reply-To: <4285E313.8000100@redhat.com> References: <42854B52.2080308@mbm.nifty.com> <4285DF88.4070509@redhat.com> <4285E313.8000100@redhat.com> Message-ID: <1116083344.5350.43.camel@localhost.localdomain> On Sat, 2005-05-14 at 20:37 +0900, Jens Petersen wrote: > A few more comments: > > Jens Petersen wrote: > > -Release: 1%{?dist} > > +Release: 9 > > Actually I don't know %dist is that an Extras-ism? > Perhaps it should stay? The %{?dist} in release is valid. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From lemenkov at newmail.ru Sat May 14 18:11:20 2005 From: lemenkov at newmail.ru (Peter Lemenkov) Date: Sat, 14 May 2005 22:11:20 +0400 Subject: Request for review: rxvt-unicode, evilwm Message-ID: Hello, All! Can anyone check these spec-files for consistency? Rxvt-Unicode: -------------------------- Rxvt-unicode. rxvt-unicode is a clone of the well known terminal emulator rxvt. It's main features (many of them unique) over rxvt are: * Stores text in Unicode (either UCS-2 or UCS-4). * Uses locale-correct input, output and width: as long as your system supports the locale, rxvt-unicode will display correctly. * Daemon mode: one daemon can open multiple windows on multiple displays, which improves memory usage and startup time considerably. * Crash-free. At least I try, but rxvt-unicode certainly crashes much less often than rxvt and it's many clones, and reproducible bugs get fixed immediately. * Completely flicker-free. * Full combining character support (unlike xterm :). * Multiple fonts supported at the same time: No need to choose between nice japanese and ugly latin, or no japanese and nice latin characters :). * Supports Xft and core fonts in any combination. * Can easily be embedded into other applications. * All documentation accessible through manpages. * Locale-independent XIM support. * Many small improvements, such as improved and correct terminfo, improved secondary screen modes, italic and bold font support, tinting and shading. SPEC: http://paula.comtv.ru/rxvt-unicode.spec -------------------------- -------------------------- Evilwm. A minimalist window manager for the X Window System. 'Minimalist' here doesn't mean it's too bare to be usable - it just means it omits a lot of the stuff that make other window managers unusable. Here is a list of features: * No window decorations apart from a simple 1 pixel border. * No icons. * Good keyboard control, including repositioning and maximise toggles. * Solid window drags (compile time option - may be slow on old machines). * Snap-to-border support (command line option). * Virtual desktops (compile time option). * Small binary size (even with everything turned on). SPEC: http://paula.comtv.ru/evilwm.spec -------------------------- -- With best regards, Peter Lemenkov. From yuan.bbbush at gmail.com Sat May 14 20:36:58 2005 From: yuan.bbbush at gmail.com (Yuan Yijun) Date: Sun, 15 May 2005 04:36:58 +0800 Subject: How to build Octave under FC4 test3 In-Reply-To: <20050514013737.64310ae8.bugs.michael@gmx.net> References: <428521C4.1030204@gmail.com> <20050513220256.GA14010@jadzia.bu.edu> <20050514001925.0d7d531e.bugs.michael@gmx.net> <42853253.30505@gmail.com> <20050514013737.64310ae8.bugs.michael@gmx.net> Message-ID: <9792751e0505141336c7c549@mail.gmail.com> excuse me, but what is top-post? I'm learning how to manage a mailling list. thanks very much! 2005/5/14, Michael Schwendt : > On Fri, 13 May 2005 16:03:47 -0700, Linuxer Wang wrote: > > > I applied the patch in Extras cvs and compile, it proceeds more than > > without the patch, but finally, I get the following errors: > > -snip- > > I don't know what you tried to apply against what and why you did not > just rebuild what can be found in Extras CVS, so look here: > > http://extras64.linux.duke.edu/failed/development/octave/2.1.70-1/i386/ > > It's the i386 binaries as created by the Fedora Extras build system > before it failed on x86_64. > > Oh, and please don't top-post. > > -- > Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1303_FC4 > loadavg: 1.27 1.94 2.11 > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From mattdm at mattdm.org Sat May 14 20:46:35 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 14 May 2005 16:46:35 -0400 Subject: How to build Octave under FC4 test3 In-Reply-To: <9792751e0505141336c7c549@mail.gmail.com> References: <428521C4.1030204@gmail.com> <20050513220256.GA14010@jadzia.bu.edu> <20050514001925.0d7d531e.bugs.michael@gmx.net> <42853253.30505@gmail.com> <20050514013737.64310ae8.bugs.michael@gmx.net> <9792751e0505141336c7c549@mail.gmail.com> Message-ID: <20050514204635.GA22821@jadzia.bu.edu> On Sun, May 15, 2005 at 04:36:58AM +0800, Yuan Yijun wrote: > excuse me, but what is top-post? I'm learning how to manage a mailling list. > thanks very much! E-mail me off the list for further discussion -- this is off-topic. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 75 degrees Fahrenheit. From j.w.r.degoede at hhs.nl Sun May 15 05:37:54 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 15 May 2005 07:37:54 +0200 Subject: Request for review: rxvt-unicode, evilwm In-Reply-To: References: Message-ID: <4286E032.9040201@hhs.nl> Peter Lemenkov wrote: > > Hello, All! > > Can anyone check these spec-files for consistency? > > Rxvt-Unicode: > > -------------------------- > Rxvt-unicode. > > rxvt-unicode is a clone of the well known terminal emulator rxvt. > It's main features (many of them unique) over rxvt are: > > * Stores text in Unicode (either UCS-2 or UCS-4). > * Uses locale-correct input, output and width: as long as your > system supports the locale, rxvt-unicode will display correctly. > * Daemon mode: one daemon can open multiple windows on multiple > displays, which improves memory usage and startup time considerably. > * Crash-free. At least I try, but rxvt-unicode certainly crashes > much less often than rxvt and it's many clones, and reproducible bugs > get fixed immediately. > * Completely flicker-free. > * Full combining character support (unlike xterm :). > * Multiple fonts supported at the same time: No need to choose > between nice japanese and ugly latin, or no japanese and nice latin > characters :). > * Supports Xft and core fonts in any combination. > * Can easily be embedded into other applications. > * All documentation accessible through manpages. > * Locale-independent XIM support. > * Many small improvements, such as improved and correct terminfo, > improved secondary screen modes, italic and bold font support, tinting > and shading. > > SPEC: > > http://paula.comtv.ru/rxvt-unicode.spec > -------------------------- > Cool, I've been thinking about packaging this myself. How did you built the docs? Has upstream stopped using yodl? If someone else doesn't beat me to it I'll review this wednesday. Regards, Hans From j.w.r.degoede at hhs.nl Sun May 15 05:53:07 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 15 May 2005 07:53:07 +0200 Subject: Request for review: rxvt-unicode, evilwm In-Reply-To: References: Message-ID: <4286E3C3.2010602@hhs.nl> Since I had more time today then I thought I would have here are the results of a first quick look: -drop the Epoch 0, no need to set an explicit Epoch -you seem to disable a lott of features, last time I checked those could be disabled at runtime, please compile them in so that people who want them can use them. I know this makes the binary slightly bigger, but it is till no konsole or gnome-terminal. For example: -enable the scrollbars -enable all codepages -drop the INSTALL file from %doc -add the LICENCSE file to %doc Regards, Hans Peter Lemenkov wrote: > > Hello, All! > > Can anyone check these spec-files for consistency? > > Rxvt-Unicode: > > -------------------------- > Rxvt-unicode. > > rxvt-unicode is a clone of the well known terminal emulator rxvt. > It's main features (many of them unique) over rxvt are: > > * Stores text in Unicode (either UCS-2 or UCS-4). > * Uses locale-correct input, output and width: as long as your > system supports the locale, rxvt-unicode will display correctly. > * Daemon mode: one daemon can open multiple windows on multiple > displays, which improves memory usage and startup time considerably. > * Crash-free. At least I try, but rxvt-unicode certainly crashes > much less often than rxvt and it's many clones, and reproducible bugs > get fixed immediately. > * Completely flicker-free. > * Full combining character support (unlike xterm :). > * Multiple fonts supported at the same time: No need to choose > between nice japanese and ugly latin, or no japanese and nice latin > characters :). > * Supports Xft and core fonts in any combination. > * Can easily be embedded into other applications. > * All documentation accessible through manpages. > * Locale-independent XIM support. > * Many small improvements, such as improved and correct terminfo, > improved secondary screen modes, italic and bold font support, tinting > and shading. > > SPEC: > > http://paula.comtv.ru/rxvt-unicode.spec > -------------------------- > > -------------------------- > Evilwm. > A minimalist window manager for the X Window System. > > 'Minimalist' here doesn't mean it's too bare to be usable - it just > means it omits a lot of the stuff that make other window managers > unusable. Here is a list of features: > > * No window decorations apart from a simple 1 pixel border. > * No icons. > * Good keyboard control, including repositioning and maximise toggles. > * Solid window drags (compile time option - may be slow on old > machines). > * Snap-to-border support (command line option). > * Virtual desktops (compile time option). > * Small binary size (even with everything turned on). > > SPEC: > > http://paula.comtv.ru/evilwm.spec > > -------------------------- > From j.w.r.degoede at hhs.nl Sun May 15 06:09:05 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 15 May 2005 08:09:05 +0200 Subject: Request for review: rxvt-unicode, evilwm In-Reply-To: References: Message-ID: <4286E781.3020101@hhs.nl> Peter Lemenkov wrote: > > Hello, All! > > Can anyone check these spec-files for consistency? > > Rxvt-Unicode: Checking the upstream changelog I noticed the following: -yodl is indeed no longer needed -urxvt seems todo some stuff with fonthinting, is it nearly aware of freetype fonthinting, or does it do stuff with fonthinting itself. I as because fonthinting is a patented technology and patented technologies are a no no in Fedora. Regards, Hans From ville.skytta at iki.fi Sun May 15 10:09:32 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 15 May 2005 13:09:32 +0300 Subject: New package: denyhosts In-Reply-To: <42850DF6.8000601@di.uminho.pt> References: <42850DF6.8000601@di.uminho.pt> Message-ID: <1116151772.3870.2.camel@bobcat.mine.nu> On Fri, 2005-05-13 at 21:28 +0100, Jos? Pedro Oliveira wrote: > http://rpm-devel.colug.net/max-rpm/s1-rpm-inside-files-list-directives.html BTW, when referring to the max-rpm snapshot, I'd recommend pointing at http://rpm.org/max-rpm-snapshot/ , it's more likely up to date than the rpm-devel one. From symbiont at berlios.de Sun May 15 10:28:04 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sun, 15 May 2005 18:28:04 +0800 Subject: Mach setup In-Reply-To: <42856D81.5040001@redhat.com> References: <4283D09A.4090106@six-by-nine.com.au> <42850519.3060808@six-by-nine.com.au> <42856D81.5040001@redhat.com> Message-ID: <200505151828.04833.symbiont@berlios.de> On Saturday 14 May 2005 11:16, Jens Petersen wrote: > Btw is this the right place to discuss mach+yum? :) Most likely since mach+yum is pretty much a fork until mach3 comes out. Then, the mach devel list would be the place to discuss mach. (Unless mach+yum remains an indefinite fork..) take care, -- -jeff From skvidal at phy.duke.edu Sun May 15 18:01:11 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 15 May 2005 14:01:11 -0400 Subject: Mach setup In-Reply-To: <200505151828.04833.symbiont@berlios.de> References: <4283D09A.4090106@six-by-nine.com.au> <42850519.3060808@six-by-nine.com.au> <42856D81.5040001@redhat.com> <200505151828.04833.symbiont@berlios.de> Message-ID: <1116180071.12777.25.camel@cutter> On Sun, 2005-05-15 at 18:28 +0800, Jeff Pitman wrote: > On Saturday 14 May 2005 11:16, Jens Petersen wrote: > > Btw is this the right place to discuss mach+yum? :) > > Most likely since mach+yum is pretty much a fork until mach3 comes out. > Then, the mach devel list would be the place to discuss mach. (Unless > mach+yum remains an indefinite fork..) it's an indefinite fork - for other reasons which I'll explain soon. -sv From perbj at stanford.edu Sun May 15 18:32:57 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Sun, 15 May 2005 11:32:57 -0700 Subject: Request for review: rxvt-unicode, evilwm In-Reply-To: <4286E781.3020101@hhs.nl> References: <4286E781.3020101@hhs.nl> Message-ID: <1116181977.4929.33.camel@localhost.localdomain> On Sun, 2005-05-15 at 08:09 +0200, Hans de Goede wrote: > -urxvt seems todo some stuff with fonthinting, is it nearly aware of > freetype fonthinting, or does it do stuff with fonthinting itself. I as > because fonthinting is a patented technology and patented technologies > are a no no in Fedora. I tried to quickly figure our what you referring to here, but didn't really get anywhere... As far as I can tell rxvt-unicode uses either core X fonts or the Xft library. It appears to explicitly turn off autohinting for some fonts, but that's it. The autohinting is not patented, and is shipped with Fedora; turning it off will just give entirely unhinted fonts. Note that I only looked at the spots I thought seemed obvious, I haven't read through all the code... But my first impression is certainly that there shouldn't be any legal problem at all with the font handling. /Per From lemenkov at newmail.ru Sun May 15 18:52:41 2005 From: lemenkov at newmail.ru (Peter Lemenkov) Date: Sun, 15 May 2005 22:52:41 +0400 Subject: rxvt-unicode In-Reply-To: <4286E3C3.2010602@hhs.nl> References: <4286E3C3.2010602@hhs.nl> Message-ID: <3eikl2-4kb.ln1@Petro.home> Hans de Goede ?????: > Since I had more time today then I thought I would have here are the > results of a first quick look: > -drop the Epoch 0, no need to set an explicit Epoch Done. > -you seem to disable a lott of features, last time I checked those could > be disabled at runtime, please compile them in so that people who want Done. All options are enabled by default (although I don't noticed any difference :)). > them can use them. I know this makes the binary slightly bigger, but it > is till no konsole or gnome-terminal. For example: > -enable the scrollbars Done > -enable all codepages Done > -drop the INSTALL file from %doc Done > -add the LICENCSE file to %doc Done SPEC: http://paula.comtv.ru/rxvt-unicode.spec From lemenkov at newmail.ru Sun May 15 21:07:38 2005 From: lemenkov at newmail.ru (Peter Lemenkov) Date: Mon, 16 May 2005 01:07:38 +0400 Subject: What's the current status of GEOS? Message-ID: <5aqkl2-gie.ln1@Petro.home> Hello, All! The only story about this package, what I could found, described here: http://bugzilla.fedora.us/show_bug.cgi?id=1394 I don't understand, after reading this post, whether GEOS suitable for inclusion into Extras or not. Can anybody summarize what problems are still exists with GEOS? From bugs.michael at gmx.net Sun May 15 22:00:29 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 16 May 2005 00:00:29 +0200 Subject: What's the current status of GEOS? In-Reply-To: <5aqkl2-gie.ln1@Petro.home> References: <5aqkl2-gie.ln1@Petro.home> Message-ID: <20050516000029.0815f909.bugs.michael@gmx.net> On Mon, 16 May 2005 01:07:38 +0400, Peter Lemenkov wrote: > Hello, All! > > The only story about this package, what I could found, described here: > > http://bugzilla.fedora.us/show_bug.cgi?id=1394 > > I don't understand, after reading this post, whether GEOS suitable for > inclusion into Extras or not. Can anybody summarize what problems are > still exists with GEOS? Most important: a package maintainer is missing. From tian at c-sait.net Sun May 15 22:49:34 2005 From: tian at c-sait.net (Christian Jodar) Date: Mon, 16 May 2005 00:49:34 +0200 Subject: New package: GCfilms Message-ID: <20050516004934.234bfba2@tianbox> Hello, I'd like GCfilms application to be included in Fedora Extras. GCfilms is an application that can be used to manage a movie collection. It is written in Gtk2-Perl and have a plugin system to add easily some features. There are plugins for languages (English, French, Spanish and partially Italian are supported for the moment), for websites used to get automatically movies informations, for data exportation (HTML, XML, CSV, SQL and tar.gz plugins already exist) and for data importation (collection from Ant Movie Catalog and DVD Profiled can be imported). More information can be found on project page: https://gna.org/projects/gcfilms/ I made an RPM for this application that already had some feedbacks on this list. I think it should be OK now. .src.rpm can be found here: http://download.gna.org/gcfilms/fedora/3/gcfilms-5.0-3.src.rpm Spec file is here: http://cvs.gna.org/viewcvs/gcfilms/gcfilms/packages/fedora/gcfilms.spec?rev=HEAD&content-type=text/vnd.viewcvs-markup Generated RPM is there: http://download.gna.org/gcfilms/fedora/3/gcfilms-5.0-3.noarch.rpm Here is the output from rmplint: # rpmlint gcfilms-5.0-3.noarch.rpm E: gcfilms only-non-binary-in-usr-lib E: gcfilms no-signature I don't think first message is a real problem for this application as it is a pure Perl one. Second one is normal according to Extras Wiki. As it doesn't need any compilation and has few dependencies, I think the package could also be generated for FC4 without any modification. Someone could take care of it. I will provide updated.spec files when needed so there won't be a lot of work for the maintainer. But it would be a pleasure for me to be the maintainer for this package. I would then require also CVS access and so a sponsor for this. Thanks a lot for your attention. Do not hesitate to contact me should you need further information. Christian Jodar (Tian). -------------- 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 Mon May 16 00:08:14 2005 From: toshio at tiki-lounge.com (Toshio) Date: Sun, 15 May 2005 20:08:14 -0400 Subject: Moving noarch packages (scons blocks blender) Message-ID: <1116202097.18407.14.camel@Madison.badger.com> Hi gemi, all, blender is currently failing to build on x86_64 because scons is not installed. Is someone going to be moving the scons and other noarch packages listed on http://www.fedoraproject.org/wiki/Extras_2fFC4Status or would it be okay with you, gemi, if I requested a new build of scons? This will resolve these bugs: scons needs to be in the x86_64 repository: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157779 blender: Rebuild for FC4: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156498 Update to 2.36: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=153226 -Toshio -- ______S______U______B______L______I______M______I______N______A______L______ t o s h i o @ t i k i - l o u n g e . c o m GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at fedoraproject.org Mon May 16 04:49:30 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 16 May 2005 00:49:30 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050516044930.E643285FF@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 84 GtkAda-2.4.0-6 bazaar-1.3.2-4 bazaar-1.3.2-4.fc4 blacs-1.1-8 blacs-1.1-8.fc4 clamav-0.85-1 gnome-blog-0.8-7 gnome-blog-0.8-7.fc4 gnupg2-1.9.16-4 gnupg2-1.9.16-4.fc4 gpa-0.7.0-4 gpgme-1.0.2-3 gpgme-1.0.2-3.fc4 gqview-2.0.1-1 gtranslator-1.1.6-1 icu-3.2-3 libsamplerate-0.1.2-3%{dist} libsamplerate-0.1.2-3.fc4 libsidplay-1.36.57-8%{dist} libsidplay-1.36.57-8.fc4 libsndfile-1.0.11-3%{dist} libsndfile-1.0.11-3.fc4 loudmouth-0.90-2 loudmouth-0.90-2.fc4 mhash-0.9.2-3 pam_mount-0.9.23-1 pam_mount-0.9.24-1 pdfjam-1.20-3 pdfjam-1.20-3.fc4 perl-Authen-SASL-2.09-3 perl-Authen-SASL-2.09-3.fc4 perl-Config-IniFiles-2.39-3 perl-Config-IniFiles-2.39-3.fc4 perl-Devel-Cycle-1.04-3 perl-Devel-Cycle-1.04-3.fc4 perl-Module-CoreList-2.01-3 perl-Module-CoreList-2.01-3.fc4 perl-Pod-Coverage-0.17-4 perl-Pod-Coverage-0.17-4.fc4 perl-Spreadsheet-WriteExcel-2.14-1 perl-Spreadsheet-WriteExcel-2.14-1.fc4 perl-Test-Builder-Tester-1.01-4 perl-Test-Builder-Tester-1.01-4.fc4 perl-Test-Exception-0.20-4 perl-Test-Exception-0.20-4.fc4 perl-Test-Manifest-1.14-3 perl-Test-Manifest-1.14-3.fc4 perl-Test-Memory-Cycle-1.00-4 perl-Test-Memory-Cycle-1.00-4.fc4 perl-Test-Pod-1.20-3 perl-Test-Pod-1.20-3.fc4 perl-Test-Pod-Coverage-1.06-3 perl-Test-Pod-Coverage-1.06-3.fc4 pth-2.0.4-3 python-cherrypy-2.0.0-2 python-cherrypy-2.0.0-2.fc4 python-docutils-0.3.7-7 python-protocols-0.9.3-5 python-protocols-0.9.3-5.fc4 python-psycopg-1.1.18-4 python-psycopg-1.1.18-4.fc4 python-simpletal-3.12-4 python-simpletal-3.12-4.fc4 python-tpg-3.0.5-4 python-tpg-3.0.5-4.fc4 qa-assistant-0.4.1-3 scalapack-1.7-7 scalapack-1.7-7.fc4 swatch-3.1.1-3 swatch-3.1.1-3.fc4 sylpheed-1.0.4-2.fc4 sylpheed-1.0.4-3.fc4 tetex-beamer-3.01-3 tetex-beamer-3.01-3.fc4 tetex-bytefield-1.2-3 tetex-bytefield-1.2-3.fc4 tetex-pgf-0.65-3 tetex-pgf-0.65-3.fc4 tetex-unicode-0-4.20041017 tetex-unicode-0-4.20041017.fc4 tetex-xcolor-2.02-3 tetex-xcolor-2.02-3.fc4 wv-1.0.3-1 wv-1.0.3-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From skvidal at phy.duke.edu Mon May 16 04:51:32 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 16 May 2005 00:51:32 -0400 Subject: Fedora Extras development Package Build Report In-Reply-To: <20050516044930.E643285FF@extras64.linux.duke.edu> References: <20050516044930.E643285FF@extras64.linux.duke.edu> Message-ID: <1116219093.12777.73.camel@cutter> On Mon, 2005-05-16 at 00:49 -0400, buildsys at fedoraproject.org wrote: > Packages built and released for Fedora Extras development: 84 > > GtkAda-2.4.0-6 > bazaar-1.3.2-4 > bazaar-1.3.2-4.fc4 > blacs-1.1-8 > blacs-1.1-8.fc4 > clamav-0.85-1 > gnome-blog-0.8-7 > gnome-blog-0.8-7.fc4 > gnupg2-1.9.16-4 > gnupg2-1.9.16-4.fc4 > gpa-0.7.0-4 > gpgme-1.0.2-3 > gpgme-1.0.2-3.fc4 > gqview-2.0.1-1 > gtranslator-1.1.6-1 > icu-3.2-3 > libsamplerate-0.1.2-3%{dist} > libsamplerate-0.1.2-3.fc4 > libsidplay-1.36.57-8%{dist} > libsidplay-1.36.57-8.fc4 > libsndfile-1.0.11-3%{dist} > libsndfile-1.0.11-3.fc4 > loudmouth-0.90-2 > loudmouth-0.90-2.fc4 > mhash-0.9.2-3 > pam_mount-0.9.23-1 > pam_mount-0.9.24-1 > pdfjam-1.20-3 > pdfjam-1.20-3.fc4 > perl-Authen-SASL-2.09-3 > perl-Authen-SASL-2.09-3.fc4 > perl-Config-IniFiles-2.39-3 > perl-Config-IniFiles-2.39-3.fc4 > perl-Devel-Cycle-1.04-3 > perl-Devel-Cycle-1.04-3.fc4 > perl-Module-CoreList-2.01-3 > perl-Module-CoreList-2.01-3.fc4 > perl-Pod-Coverage-0.17-4 > perl-Pod-Coverage-0.17-4.fc4 > perl-Spreadsheet-WriteExcel-2.14-1 > perl-Spreadsheet-WriteExcel-2.14-1.fc4 > perl-Test-Builder-Tester-1.01-4 > perl-Test-Builder-Tester-1.01-4.fc4 > perl-Test-Exception-0.20-4 > perl-Test-Exception-0.20-4.fc4 > perl-Test-Manifest-1.14-3 > perl-Test-Manifest-1.14-3.fc4 > perl-Test-Memory-Cycle-1.00-4 > perl-Test-Memory-Cycle-1.00-4.fc4 > perl-Test-Pod-1.20-3 > perl-Test-Pod-1.20-3.fc4 > perl-Test-Pod-Coverage-1.06-3 > perl-Test-Pod-Coverage-1.06-3.fc4 > pth-2.0.4-3 > python-cherrypy-2.0.0-2 > python-cherrypy-2.0.0-2.fc4 > python-docutils-0.3.7-7 > python-protocols-0.9.3-5 > python-protocols-0.9.3-5.fc4 > python-psycopg-1.1.18-4 > python-psycopg-1.1.18-4.fc4 > python-simpletal-3.12-4 > python-simpletal-3.12-4.fc4 > python-tpg-3.0.5-4 > python-tpg-3.0.5-4.fc4 > qa-assistant-0.4.1-3 > scalapack-1.7-7 > scalapack-1.7-7.fc4 > swatch-3.1.1-3 > swatch-3.1.1-3.fc4 > sylpheed-1.0.4-2.fc4 > sylpheed-1.0.4-3.fc4 > tetex-beamer-3.01-3 > tetex-beamer-3.01-3.fc4 > tetex-bytefield-1.2-3 > tetex-bytefield-1.2-3.fc4 > tetex-pgf-0.65-3 > tetex-pgf-0.65-3.fc4 > tetex-unicode-0-4.20041017 > tetex-unicode-0-4.20041017.fc4 > tetex-xcolor-2.02-3 > tetex-xcolor-2.02-3.fc4 > wv-1.0.3-1 > wv-1.0.3-1.fc4 I'm cleaning up all the older duplicates now. sorry for the mistake. -sv From buildsys at fedoraproject.org Mon May 16 04:54:46 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 16 May 2005 00:54:46 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050516045446.39C4F85FF@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 17 bazaar-1.3.2-4 bazaar-1.3.2-4.fc3 blacs-1.1-8 blacs-1.1-8.fc3 gossip-0.8-3 inadyn-1.90-11.fc3 loudmouth-0.90-2 loudmouth-0.90-2.fc3 notecase-0.8.2-6 python-cherrypy-2.0.0-2 python-cherrypy-2.0.0-2.fc3 scalapack-1.7-7 scalapack-1.7-7.fc3 tetex-unicode-0-4.20041017 tetex-unicode-0-4.20041017.fc3 tla-1.3.2-5 tla-1.3.2-5.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From skvidal at phy.duke.edu Mon May 16 05:40:58 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 16 May 2005 01:40:58 -0400 Subject: Fedora Extras 3 Package Build Report In-Reply-To: <20050516045446.39C4F85FF@extras64.linux.duke.edu> References: <20050516045446.39C4F85FF@extras64.linux.duke.edu> Message-ID: <1116222058.12777.89.camel@cutter> On Mon, 2005-05-16 at 00:54 -0400, buildsys at fedoraproject.org wrote: > Packages built and released for Fedora Extras 3: 17 > [SNIP] > python-cherrypy-2.0.0-2 > python-cherrypy-2.0.0-2.fc3 > scalapack-1.7-7 > scalapack-1.7-7.fc3 > tetex-unicode-0-4.20041017 > tetex-unicode-0-4.20041017.fc3 > tla-1.3.2-5 > tla-1.3.2-5.fc3 And I've cleaned these up, too. A couple more items I did while I was pushing the updates: - cleaned up older releases in the extras trees - installed a new version of repoview so now the group output looks much prettier - copied all the noarch files that needed to be copied over to the appropriate archs as per the list on the FC4Status page. - cleaned up the empty dirs in active/needsign/failed dirs. -sv From j.w.r.degoede at hhs.nl Mon May 16 07:29:09 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 16 May 2005 09:29:09 +0200 Subject: Request for review: rxvt-unicode, evilwm In-Reply-To: <1116181977.4929.33.camel@localhost.localdomain> References: <4286E781.3020101@hhs.nl> <1116181977.4929.33.camel@localhost.localdomain> Message-ID: <42884BC5.60805@hhs.nl> Per Bjornsson wrote: > On Sun, 2005-05-15 at 08:09 +0200, Hans de Goede wrote: > >>-urxvt seems todo some stuff with fonthinting, is it nearly aware of >>freetype fonthinting, or does it do stuff with fonthinting itself. I as >>because fonthinting is a patented technology and patented technologies >>are a no no in Fedora. > > > I tried to quickly figure our what you referring to here, but didn't > really get anywhere... As far as I can tell rxvt-unicode uses either > core X fonts or the Xft library. It appears to explicitly turn off > autohinting for some fonts, but that's it. The autohinting is not > patented, and is shipped with Fedora; turning it off will just give > entirely unhinted fonts. > > Note that I only looked at the spots I thought seemed obvious, I haven't > read through all the code... But my first impression is certainly that > there shouldn't be any legal problem at all with the font handling. > I read about the autohinting in the ChangeLog anf confused this with the patented hinting. If autohinting is ok then I think urxvt is ok too. Regards, Hans From j.w.r.degoede at hhs.nl Mon May 16 07:38:50 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 16 May 2005 09:38:50 +0200 Subject: rxvt-unicode In-Reply-To: <3eikl2-4kb.ln1@Petro.home> References: <4286E3C3.2010602@hhs.nl> <3eikl2-4kb.ln1@Petro.home> Message-ID: <42884E0A.30403@hhs.nl> Peter Lemenkov wrote: > Hans de Goede ?????: > >> -you seem to disable a lott of features, last time I checked those could >> be disabled at runtime, please compile them in so that people who want > > > Done. All options are enabled by default (although I don't noticed any > difference :)). > Erm, you might have gone a bit overboard the other way this time. I have promised myself not to spend to much time behind my PC this (long) weekend. I'll do a thorough review (like actually compile the beast) wednesday and then I'll also take a look at all the options. Last time I used urxvt was some time ago * and if my memory serves me some options where better left turned off. This should also be in the docs. Regards, Hans * If you want to know how long ago: my name is in the changelog because of some patches I send back then From gemi at bluewin.ch Mon May 16 08:54:54 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 16 May 2005 10:54:54 +0200 Subject: Moving noarch packages (scons blocks blender) In-Reply-To: <1116202097.18407.14.camel@Madison.badger.com> References: <1116202097.18407.14.camel@Madison.badger.com> Message-ID: <1116233694.6685.0.camel@scriabin.tannenrauch.ch> On Sun, 2005-05-15 at 20:08 -0400, Toshio wrote: > Hi gemi, all, > > blender is currently failing to build on x86_64 because scons is not > installed. Is someone going to be moving the scons and other noarch > packages listed on http://www.fedoraproject.org/wiki/Extras_2fFC4Status > or would it be okay with you, gemi, if I requested a new build of scons? Yes, do it. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From adrian at lisas.de Mon May 16 09:11:51 2005 From: adrian at lisas.de (Adrian Reber) Date: Mon, 16 May 2005 11:11:51 +0200 Subject: Request for review: netselect In-Reply-To: <1116006752.4707.15.camel@rydia.hardsun.net> References: <20050513160118.GA17721@lisas.de> <1116006752.4707.15.camel@rydia.hardsun.net> Message-ID: <20050516091151.GA22153@lisas.de> On Fri, May 13, 2005 at 10:52:32AM -0700, Aaron Kurtz wrote: > On Fri, 2005-05-13 at 18:01 +0200, Adrian Reber wrote: > > http://lisas.de/~adrian/rpm/netselect-0.3-1.src.rpm > > - Do not use install -s to strip binaries - RPM handles this and sticks > the information in a -debuginfo RPM. Plus, it dies on FC4t3 trying to > strip the netselect-yum shell script. Whoops. Fixed -s errors. Cannot reproduce break during stripping on a machine following development packages. > - Considering this is Fedora Extras, an entirely separate -yum package > is a bit unnecessary. Just roll it in. I would rather like to leave it as two packages. > - This needs to run as root all the time? Some mention of this would be > good. ? The script can be run as non-root if netselect is suid, else it complains. Where should it be mentioned? %description > = DistTags. http://fedoraproject.org/wiki/DistTag Ahh... not yet. If it becomes necessary. > = Perhaps rather than hitting all the mirrors, netselect-yum could hit > just a region? Ideally this could be taken from /etc/sysconfig/clock's > ZONE= setting. Good idea, but I would rather like to do such things in a later version once the first version has been published. Adrian -- Adrian Reber http://lisas.de/~adrian/ COBOL is for morons. -- E.W. Dijkstra From paul at city-fan.org Mon May 16 10:06:00 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 16 May 2005 11:06:00 +0100 Subject: Review Request: pptp In-Reply-To: References: <428090CE.5070309@city-fan.org> <4280B309.9020709@city-fan.org> Message-ID: <42887088.9060008@city-fan.org> Chris Ricker wrote: > On Tue, 10 May 2005, Paul Howarth wrote: > >>Regarding patents, I don't believe that the ppp_mppe module has any patent >>issues, but the alternative ppp_mppe_mppc module does. >>See: >>http://pptpclient.sourceforge.net/howto-diagnosis.phtml#running_pppd_after_connection > > > Okay, looks like encryption's fine, but compression is patented? FWIW, Andrew Morton has recently included the MPPE module in his -mm tree (http://marc.theaimsgroup.com/?l=pptpclient-devel&m=111605104820043&w=2). Hopefully this is a major step in getting the module included upstream. >>>Packaging of pptpconfig to go with this would be useful too >> >>Well, yes, but that opens another can of worms as I mentioned earlier: >>https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00394.html >> >>The PHP4 in FC3 doesn't include the pcntl module, and FC4 ships with PHP5, >>which I believe (I haven't tried it) is incompatible with php-gtk. > > > Yeah, I'd forgotten they're in php-gtk. I think the php-gtk plan is to > skip over 5.0 and only support PHP5.1+? I'm about to make a proposal on pptpconfig but I'll do it in a separate thread because it'll involve an new PHP package. Paul. From paul at city-fan.org Mon May 16 10:15:13 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 16 May 2005 11:15:13 +0100 Subject: PHP4 in extras? Message-ID: <428872B1.5090001@city-fan.org> During reviews of my pptp package (https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00391.html), a couple of people suggested that I also package up the "pptpconfig" GUI configuration tool for pptp. I'm happy to do this, but it will also require packaging of some dependencies, one of which is version 4 of PHP, because pptpconfig is built using PHP-GTK (http://gtk.php.net/), which is not compatible with PHP5 as shipped in FC4. What I propose to do is to create the following packages: php4 - version of PHP 4.3.x, mainly imported from FC3 but renamed so that it can be co-installed with the regular FC4 PHP package. I would also be enabling the "pcntl" module, which is not enabled in FC3 PHP but is enabled in FC4's PHP package. This module is needed by pptpconfig. php-gtk - GTK toolkit for PHP4. pptpconfig - PPTP configuration GUI, built using php-gtk. Before I go ahead and create the packages for review, does anyone have any objections in principle to this approach, or any better suggestions for how to go about packaging pptpconfig? Paul. From ryo-dairiki at mbm.nifty.com Mon May 16 11:40:14 2005 From: ryo-dairiki at mbm.nifty.com (Ryo Dairiki) Date: Mon, 16 May 2005 20:40:14 +0900 Subject: Approval needed again: SCIM Message-ID: <4288869E.7060306@mbm.nifty.com> Hi, I've rewritten the specfile. Could you review it? Please visit here and check it: http://briefcase.yahoo.co.jp/bc/ryo_dairiki/lst?.dir=/ Regards, Ryo Dairiki From jspaleta at gmail.com Mon May 16 13:17:55 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 16 May 2005 09:17:55 -0400 Subject: PHP4 in extras? In-Reply-To: <428872B1.5090001@city-fan.org> References: <428872B1.5090001@city-fan.org> Message-ID: <604aa7910505160617b5a6863@mail.gmail.com> On 5/16/05, Paul Howarth wrote: > During reviews of my pptp package > (https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00391.html), > a couple of people suggested that I also package up the "pptpconfig" GUI > configuration tool for pptp. I'm happy to do this, but it will also > require packaging of some dependencies, one of which is version 4 of > PHP, because pptpconfig is built using PHP-GTK (http://gtk.php.net/), > which is not compatible with PHP5 as shipped in FC4. Do you know exactly why its not compatible with the php5 that's going to be in fc4? Inherent incompatibility with php5 or is this a compile time setting? If its a compile time setting issue have you communicated with the core php maintainer about whether there is room to negotiate compiletime changes before fc4 is released? -jef From paul at city-fan.org Mon May 16 13:21:25 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 16 May 2005 14:21:25 +0100 Subject: PHP4 in extras? In-Reply-To: <604aa7910505160617b5a6863@mail.gmail.com> References: <428872B1.5090001@city-fan.org> <604aa7910505160617b5a6863@mail.gmail.com> Message-ID: <42889E55.5030701@city-fan.org> Jeff Spaleta wrote: > On 5/16/05, Paul Howarth wrote: > >>During reviews of my pptp package >>(https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00391.html), >>a couple of people suggested that I also package up the "pptpconfig" GUI >>configuration tool for pptp. I'm happy to do this, but it will also >>require packaging of some dependencies, one of which is version 4 of >>PHP, because pptpconfig is built using PHP-GTK (http://gtk.php.net/), >>which is not compatible with PHP5 as shipped in FC4. > > > Do you know exactly why its not compatible with the php5 that's going > to be in fc4? > Inherent incompatibility with php5 or is this a compile time setting? > If its a compile time setting issue have you communicated with the > core php maintainer about whether there is room to negotiate > compiletime changes before fc4 is released? I believe it's an inherent incompatibility. I tried building with php5 from rawhide this morning and it fell over at a PHP version check in "configure", the error message being "PHP-GTK requires PHP version 4.3.x". Paul. From jspaleta at gmail.com Mon May 16 13:37:47 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 16 May 2005 09:37:47 -0400 Subject: PHP4 in extras? In-Reply-To: <42889E55.5030701@city-fan.org> References: <428872B1.5090001@city-fan.org> <604aa7910505160617b5a6863@mail.gmail.com> <42889E55.5030701@city-fan.org> Message-ID: <604aa79105051606375932c37e@mail.gmail.com> On 5/16/05, Paul Howarth wrote: > I believe it's an inherent incompatibility. I tried building with php5 > from rawhide this morning and it fell over at a PHP version check in > "configure", the error message being "PHP-GTK requires PHP version 4.3.x". that's interesting.. since the php-gtk website claims a requirement PHP version 4.3.4 or later http://gtk.php.net/manual/en/installunix.php You might want to track down a one of the php-gtk developers and ask if the configure version check is right or if the website is right. -jef From paul at city-fan.org Mon May 16 14:24:00 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 16 May 2005 15:24:00 +0100 Subject: PHP4 in extras? In-Reply-To: <604aa79105051606375932c37e@mail.gmail.com> References: <428872B1.5090001@city-fan.org> <604aa7910505160617b5a6863@mail.gmail.com> <42889E55.5030701@city-fan.org> <604aa79105051606375932c37e@mail.gmail.com> Message-ID: <4288AD00.8090203@city-fan.org> Jeff Spaleta wrote: > On 5/16/05, Paul Howarth wrote: > >>I believe it's an inherent incompatibility. I tried building with php5 >>from rawhide this morning and it fell over at a PHP version check in >>"configure", the error message being "PHP-GTK requires PHP version 4.3.x". > > > that's interesting.. since the php-gtk website claims a requirement > PHP version 4.3.4 or later > http://gtk.php.net/manual/en/installunix.php > > You might want to track down a one of the php-gtk developers and ask > if the configure > version check is right or if the website is right. I believe the website is out of date. PHP-GTK used to have two different build systems, a "historical" one and another that relied on PHP being 4.3.x. At version 1.0.1 of PHP-GTK, the "historical" build system was removed, thus PHP 4.3.x was required. The website doesn't reflect this change unfortunately. At the time, I don't think PHP5 had been released (I may be wrong about that though). I'll try hacking the configure script not to complain about PHP != 4.3.x and see how much further it gets. Paul. From toshio at tiki-lounge.com Mon May 16 14:33:54 2005 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 16 May 2005 10:33:54 -0400 Subject: Moving noarch packages (scons blocks blender) In-Reply-To: <1116233694.6685.0.camel@scriabin.tannenrauch.ch> References: <1116202097.18407.14.camel@Madison.badger.com> <1116233694.6685.0.camel@scriabin.tannenrauch.ch> Message-ID: <1116254035.23731.21.camel@Madison.badger.com> On Mon, 2005-05-16 at 10:54 +0200, G?rard Milmeister wrote: > On Sun, 2005-05-15 at 20:08 -0400, Toshio wrote: > > blender is currently failing to build on x86_64 because scons is not > > installed. Is someone going to be moving the scons and other noarch > > packages listed on http://www.fedoraproject.org/wiki/Extras_2fFC4Status > > or would it be okay with you, gemi, if I requested a new build of scons? > Yes, do it. Looks like Seth got scons and the other noarch packages copied. Thanks Seth! -Toshio -- toshio \ "The Difference between today and yesterday is not so much what has @tiki- \ changed between then and now as what I hope to change by tomorrow." lounge.com=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~= GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Mon May 16 14:52:08 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 16 May 2005 10:52:08 -0400 Subject: PHP4 in extras? In-Reply-To: <4288AD00.8090203@city-fan.org> References: <428872B1.5090001@city-fan.org> <604aa7910505160617b5a6863@mail.gmail.com> <42889E55.5030701@city-fan.org> <604aa79105051606375932c37e@mail.gmail.com> <4288AD00.8090203@city-fan.org> Message-ID: <604aa79105051607521e2f4873@mail.gmail.com> On 5/16/05, Paul Howarth wrote: > I'll try hacking the configure script not to complain about PHP != 4.3.x > and see how much further it gets. My personal feeling is that long term you will want to avoid having to maintain php in extras.. just for your own sanity. At some point you have to ask the hard question about whether trying to keep up with things like php4 security issues over the long haul is less of a resource burn than working with php-gtk developers to support php5. Unfortunately, confidently knowing that answer invovles seeing the future. You could however gain insight by finding a php-gtk developer and asking them about the state of php5 support. It might be a better use of your time to help them getting php-gtk working with php5, depending on the specific issues invovled. -jef From skvidal at phy.duke.edu Mon May 16 14:55:07 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 16 May 2005 10:55:07 -0400 Subject: PHP4 in extras? In-Reply-To: <604aa79105051607521e2f4873@mail.gmail.com> References: <428872B1.5090001@city-fan.org> <604aa7910505160617b5a6863@mail.gmail.com> <42889E55.5030701@city-fan.org> <604aa79105051606375932c37e@mail.gmail.com> <4288AD00.8090203@city-fan.org> <604aa79105051607521e2f4873@mail.gmail.com> Message-ID: <1116255307.16326.0.camel@cutter> On Mon, 2005-05-16 at 10:52 -0400, Jeff Spaleta wrote: > On 5/16/05, Paul Howarth wrote: > > I'll try hacking the configure script not to complain about PHP != 4.3.x > > and see how much further it gets. > > My personal feeling is that long term you will want to avoid having to > maintain php in extras.. just for your own sanity. At some point you > have to ask the hard question about whether trying to keep up with > things like php4 security issues over the long haul is less of a > resource burn than working with php-gtk developers to support php5. > Unfortunately, confidently knowing that answer invovles seeing the > future. You could however gain insight by finding a php-gtk developer > and asking them about the state of php5 support. It might be a better > use of your time to help them getting php-gtk working with php5, > depending on the specific issues invovled. or better yet convincing the person who wrote the php-gtk program that it is just crack and port it to something more sustainable on this distro. -sv From paul at city-fan.org Mon May 16 14:57:36 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 16 May 2005 15:57:36 +0100 Subject: PHP4 in extras? In-Reply-To: <604aa79105051607521e2f4873@mail.gmail.com> References: <428872B1.5090001@city-fan.org> <604aa7910505160617b5a6863@mail.gmail.com> <42889E55.5030701@city-fan.org> <604aa79105051606375932c37e@mail.gmail.com> <4288AD00.8090203@city-fan.org> <604aa79105051607521e2f4873@mail.gmail.com> Message-ID: <4288B4E0.8050909@city-fan.org> Jeff Spaleta wrote: > On 5/16/05, Paul Howarth wrote: > >>I'll try hacking the configure script not to complain about PHP != 4.3.x >>and see how much further it gets. > > > My personal feeling is that long term you will want to avoid having to > maintain php in extras.. just for your own sanity. At some point you > have to ask the hard question about whether trying to keep up with > things like php4 security issues over the long haul is less of a > resource burn than working with php-gtk developers to support php5. > Unfortunately, confidently knowing that answer invovles seeing the > future. You could however gain insight by finding a php-gtk developer > and asking them about the state of php5 support. It might be a better > use of your time to help them getting php-gtk working with php5, > depending on the specific issues invovled. Having taken at look at the php spec file from FC3, I think you're right. I may have to wait for php-gtk version 2; we'll see. Paul. From mricon at gmail.com Mon May 16 18:51:20 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Mon, 16 May 2005 14:51:20 -0400 Subject: Approval needed again: SCIM In-Reply-To: <4288869E.7060306@mbm.nifty.com> References: <4288869E.7060306@mbm.nifty.com> Message-ID: On 5/16/05, Ryo Dairiki wrote: > Hi, > I've rewritten the specfile. > Could you review it? > > Please visit here and check it: > http://briefcase.yahoo.co.jp/bc/ryo_dairiki/lst?.dir=/ Good day: I've reviewed the specfile, and there are several improvement suggestions I have. See http://phy.duke.edu/~icon/misc/fedora-extras/scim.spec.patch for the patch. Notably: 1. PreReq is not required, as everything listed there is assumed to exist on the core system. 2. gtk2-devel will pull in everything else via dependencies. 3. It's best to use mkdir with -m 755 just in case there are odd umasks in place. 4. rm ${RPM_BUILD_ROOT}/%{_libdir}/scim-1.0/*/*/*.{a,la} wasn't finding all the .a files, so I replaced it with a more general find statement. 5. ${RPM_BUILD_ROOT}/ : no {} required and no / on the end, as %{_bindir} and other macros already start with a /. 6. I've tried to make the specfile conform to the 80-character width limit for readability, wherever possible. 7. Several files were listed twice, which I fixed. Thanks for your work! Cheers, -- Konstantin Ryabitsev Zlotniks, INC "? ????? ???? ?? ??? ???? ?????????????." --???? From Jochen at herr-schmitt.de Mon May 16 20:09:32 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 16 May 2005 22:09:32 +0200 Subject: New Package: kyum Message-ID: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> Hello, I want to introduced kyum to Fedora Extras. Kyum is a GUI for yum for the KDE. A source RPM can download from: http://www.herr-schmitt.de/pub/kyum/kyum-0.6.3-0.src.rpm Best Regards: Jochen Schmitt From kaboom at oobleck.net Mon May 16 21:44:49 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Mon, 16 May 2005 17:44:49 -0400 (EDT) Subject: request for review: fping In-Reply-To: <20050512113952.3c26676f@python2> References: <20050512113952.3c26676f@python2> Message-ID: On Thu, 12 May 2005, Matthias Saou wrote: > Chris Ricker wrote : > > > Anyone like to review / approve > > > > > > > > fping's essentially a scriptable parallelized ICMP echo-based ping. It's > > needed by hobbit.... > > Find attached a patch for some quick suggested changes, of which : > - Drop the silly buildroot != / from %clean fixed > - Simplify the weird doc installation (did you do that??) fixed - no idea now why I did that > - Don't strip the fping6 binary on install to get useful debuginfo fixed > If you apply at least the above 3 changes from the patch, I approve the > package :-) (compilation and functionality tested too on i386) great. I'll import into CVS and post an approval in a sec The only other change I made was preserving timestamps (install -p) > Actually, I've just noticed that the "fping6" binary included in the > binary package doesn't get stripped automatically, whereas the main > "fping" does. Strange. Could it be that both binaries share debug symbols > etc.? Wondering if it could have been caused by the suid bit, I've looked > at /bin/su on FC3... and it's not stripped either. Confusing :-) > > Maybe the explicit stripping of "fping6" should stay then, if the debug > symbols extracted from "fping" are sufficient for both. I tested by doing a bt in gdb. If I don't strip fping6, then I get symbols for both fping and fping6 by installing the fping-debuginfo. If I do strip fping6, no symbols.... AFAICT, -debuginfo is working now. Want to double-check it before I request a build? Thanks! later, chris From daniel-wittenberg at starken.com Tue May 17 05:15:42 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Tue, 17 May 2005 00:15:42 -0500 Subject: Epoch + snort sponser In-Reply-To: <1116017467.4628.64.camel@laurel.intra.city-fan.org> References: <1115701804.25390.7.camel@plasma.starken.com> <80d7e409050510164830c08c2a@mail.gmail.com> <1115772905.5219.0.camel@localhost.localdomain> <80d7e409050511094976e46cb2@mail.gmail.com> <1116016810.16434.11.camel@plasma.starken.com> <1116017467.4628.64.camel@laurel.intra.city-fan.org> Message-ID: <1116306942.5189.5.camel@localhost.localdomain> Well, RHEL is only one...there are other RPM-based systems these are built on, so it would have to be something that says something like: %if 0%{?fedora} <- I don't understand this one %define flexresp 1 %define mysql 1 %define postgresql 1 %endif On Fri, 2005-05-13 at 21:51 +0100, Paul Howarth wrote: > On Fri, 2005-05-13 at 15:40 -0500, Daniel Wittenberg wrote: > > Yeah, I was tyring to find a way to detect if it was a Fedora system or > > not, but didn't come up with anything. > > > > Anyone? > > > > Dan > > > > On Wed, 2005-05-11 at 10:49 -0600, Stephen J. Smoogen wrote: > > > The one big thing I think that looking at the other fedora extras is > > > that switches are frowned on in the auto-build system. I am thinking > > > that for fedora a lot of the entries should be 1 versus 0 > > > > > > %define flexresp 1 > > > %define mysql 1 > > > %define postgresql 1 > > > > > > similar to how the caos one is done. I wonder if there is a %undefine > > > RPM command.. as that would allow for the spec to cover the items that > > > arent to be defined for Extras rpms (vendor, distro). > > Perhaps something like what's described at: > http://fedoraproject.org/wiki/DistTag? > action=highlight&value=CategoryExtras > > # Do something special if we're built for RHEL. > %if !0%{?fedora} > Vendor: blah > Packager: blah > %endif > > Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From paul at city-fan.org Tue May 17 07:21:38 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 17 May 2005 08:21:38 +0100 Subject: Epoch + snort sponser In-Reply-To: <1116306942.5189.5.camel@localhost.localdomain> References: <1115701804.25390.7.camel@plasma.starken.com> <80d7e409050510164830c08c2a@mail.gmail.com> <1115772905.5219.0.camel@localhost.localdomain> <80d7e409050511094976e46cb2@mail.gmail.com> <1116016810.16434.11.camel@plasma.starken.com> <1116017467.4628.64.camel@laurel.intra.city-fan.org> <1116306942.5189.5.camel@localhost.localdomain> Message-ID: <1116314498.4628.94.camel@laurel.intra.city-fan.org> On Tue, 2005-05-17 at 00:15 -0500, Daniel Wittenberg wrote: > Well, RHEL is only one...there are other RPM-based systems these are > built on, so it would have to be something that says something like: > > %if 0%{?fedora} <- I don't understand this one > %define flexresp 1 > %define mysql 1 > %define postgresql 1 > %endif The comment (above this snippet) didn't match the code. It should have said: # Do something special if we're not built for Fedora. %if !0%{?fedora} Vendor: blah Packager: blah %endif For RHEL it would have been "%if !0{?rhel}" Paul. -- Paul Howarth From paul at city-fan.org Tue May 17 07:33:37 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 17 May 2005 08:33:37 +0100 Subject: PHP4 in extras? In-Reply-To: <1116255307.16326.0.camel@cutter> References: <428872B1.5090001@city-fan.org> <604aa7910505160617b5a6863@mail.gmail.com> <42889E55.5030701@city-fan.org> <604aa79105051606375932c37e@mail.gmail.com> <4288AD00.8090203@city-fan.org> <604aa79105051607521e2f4873@mail.gmail.com> <1116255307.16326.0.camel@cutter> Message-ID: <1116315218.4628.98.camel@laurel.intra.city-fan.org> On Mon, 2005-05-16 at 10:55 -0400, seth vidal wrote: > On Mon, 2005-05-16 at 10:52 -0400, Jeff Spaleta wrote: > > On 5/16/05, Paul Howarth wrote: > > > I'll try hacking the configure script not to complain about PHP != 4.3.x > > > and see how much further it gets. > > > > My personal feeling is that long term you will want to avoid having to > > maintain php in extras.. just for your own sanity. At some point you > > have to ask the hard question about whether trying to keep up with > > things like php4 security issues over the long haul is less of a > > resource burn than working with php-gtk developers to support php5. > > Unfortunately, confidently knowing that answer invovles seeing the > > future. You could however gain insight by finding a php-gtk developer > > and asking them about the state of php5 support. It might be a better > > use of your time to help them getting php-gtk working with php5, > > depending on the specific issues invovled. > > or better yet convincing the person who wrote the php-gtk program that > it is just crack and port it to something more sustainable on this > distro. It would seem that a port to pygtk will be done for the next release :-) Paul. -- Paul Howarth From petersen at redhat.com Tue May 17 11:02:01 2005 From: petersen at redhat.com (Jens Petersen) Date: Tue, 17 May 2005 20:02:01 +0900 Subject: Approval needed again: SCIM In-Reply-To: References: <4288869E.7060306@mbm.nifty.com> Message-ID: <4289CF29.90504@redhat.com> Konstantin Ryabitsev wrote: > On 5/16/05, Ryo Dairiki wrote: > I've reviewed the specfile, and there are several improvement > suggestions I have. See > http://phy.duke.edu/~icon/misc/fedora-extras/scim.spec.patch for the > patch. Notably: Thanks. :) > 1. PreReq is not required, as everything listed there is assumed to > exist on the core system. Actually I think update-gtk-immodules needs to be included though. And at least for Core, requires (prereq) for alternatives is needed - it doesn't seem to do any harm to keep it. > 2. gtk2-devel will pull in everything else via dependencies. desktop-file-utils should be added however I think. > 4. rm ${RPM_BUILD_ROOT}/%{_libdir}/scim-1.0/*/*/*.{a,la} wasn't > finding all the .a files, so I replaced it with a more general find > statement. Is it official FE policy to exclude all static libraries, and .la files too? Can't libtool make use of the .la files when linking shared libs? (I'm actually planning to propose for FC5 to move (all) static libs to -static subpackages in order to make -devel packages lighter.) > 5. ${RPM_BUILD_ROOT}/ : no {} required Personally I find with {} easier to read, but agree one should fix on one or the other. > 6. I've tried to make the specfile conform to the 80-character width > limit for readability, wherever possible. I think that is a matter of taste - surely 80 columns is only necessary for changelog entries? Personally I generally find unbroken lines in spec files much easier to read. Thanks for your help, Jens -------------- next part -------------- A non-text attachment was scrubbed... Name: scim.spec-changes2.patch Type: text/x-patch Size: 1781 bytes Desc: not available URL: From a.kurtz at hardsun.net Tue May 17 11:19:39 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Tue, 17 May 2005 04:19:39 -0700 Subject: Request for review: netselect In-Reply-To: <20050516091151.GA22153@lisas.de> References: <20050513160118.GA17721@lisas.de> <1116006752.4707.15.camel@rydia.hardsun.net> <20050516091151.GA22153@lisas.de> Message-ID: <1116328779.22682.48.camel@rydia.hardsun.net> On Mon, 2005-05-16 at 11:11 +0200, Adrian Reber wrote: > On Fri, May 13, 2005 at 10:52:32AM -0700, Aaron Kurtz wrote: > > - Considering this is Fedora Extras, an entirely separate -yum package > > is a bit unnecessary. Just roll it in. > > I would rather like to leave it as two packages. Why? It's just one file in the -yum package. > > - This needs to run as root all the time? Some mention of this would be > > good. > > ? The script can be run as non-root if netselect is suid, else it > complains. Where should it be mentioned? %description Suid just for pinging? I try to minimize suid use. %description seems a good place to me. I'm thinking of this more for the netselect binary than the script, as it's understandable for something that rewrites mirror choices to need root. But if the mirror script's the important part, why not one package? > > = DistTags. http://fedoraproject.org/wiki/DistTag > > Ahh... not yet. If it becomes necessary. Never a bad time to start good habits. I wonder why it's not mandatory. > > = Perhaps rather than hitting all the mirrors, netselect-yum could hit > > just a region? Ideally this could be taken from /etc/sysconfig/clock's > > ZONE= setting. > > Good idea, but I would rather like to do such things in a later version > once the first version has been published. Perfectly understandable. And considering it's just pinging, this isn't as necessary as for apt-spy's tests. -- Aaron Kurtz References: <20050513160118.GA17721@lisas.de> <1116006752.4707.15.camel@rydia.hardsun.net> <20050516091151.GA22153@lisas.de> <1116328779.22682.48.camel@rydia.hardsun.net> Message-ID: <20050517112244.GA31836@ryoko.camperquake.de> On Tue, May 17, 2005 at 04:19:39AM -0700, Aaron Kurtz wrote: > Suid just for pinging? Just in case you are not aware of it: [sun at ryoko ~ :) 1]$ ls -l /bin/ping -rwsr-xr-x 1 root root 33272 Feb 21 23:43 /bin/ping From a.kurtz at hardsun.net Tue May 17 11:30:46 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Tue, 17 May 2005 04:30:46 -0700 Subject: Request for review: netselect In-Reply-To: <20050517112244.GA31836@ryoko.camperquake.de> References: <20050513160118.GA17721@lisas.de> <1116006752.4707.15.camel@rydia.hardsun.net> <20050516091151.GA22153@lisas.de> <1116328779.22682.48.camel@rydia.hardsun.net> <20050517112244.GA31836@ryoko.camperquake.de> Message-ID: <1116329446.22682.51.camel@rydia.hardsun.net> On Tue, 2005-05-17 at 13:22 +0200, Ralf Ertzinger wrote: > On Tue, May 17, 2005 at 04:19:39AM -0700, Aaron Kurtz wrote: > > > Suid just for pinging? > > Just in case you are not aware of it: > [sun at ryoko ~ :) 1]$ ls -l /bin/ping > -rwsr-xr-x 1 root root 33272 Feb 21 23:43 /bin/ping ... Open mouth, insert foot. Uh, I mean, well, why not have the netselect package install it suid then? -- Aaron Kurtz References: <20050513160118.GA17721@lisas.de> <1116006752.4707.15.camel@rydia.hardsun.net> <20050516091151.GA22153@lisas.de> <1116328779.22682.48.camel@rydia.hardsun.net> <20050517112244.GA31836@ryoko.camperquake.de> <1116329446.22682.51.camel@rydia.hardsun.net> Message-ID: <20050517113329.GB31836@ryoko.camperquake.de> On Tue, May 17, 2005 at 04:30:46AM -0700, Aaron Kurtz wrote: > Open mouth, insert foot. > Uh, I mean, well, why not have the netselect package install it suid > then? You have a point, of course. SUID is evil, and ping mainly gets away with it because it's code has been checked again and again. From paul at city-fan.org Tue May 17 13:49:08 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 17 May 2005 14:49:08 +0100 Subject: New Package: kyum In-Reply-To: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> References: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> Message-ID: <4289F654.7090907@city-fan.org> Jochen Schmitt wrote: > Hello, > > I want to introduced kyum to Fedora Extras. > > Kyum is a GUI for yum for the KDE. > > A source RPM can download from: > > http://www.herr-schmitt.de/pub/kyum/kyum-0.6.3-0.src.rpm Preliminary comments: Why hardcode /usr in "%configure --prefix=/usr"? Please be consistent about use of %{buildroot} and $RPM_BUILD_ROOT; choose one and then use it everywhere. Why rename the desktop file ("mv -f fedora-%{name}.desktop %{name}.desktop")? I don't normally use a GUI for yum but this is definitely better than gyum. Paul. From bugs.michael at gmx.net Tue May 17 13:56:27 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 17 May 2005 15:56:27 +0200 Subject: Build system status? In-Reply-To: <200505161832.j4GIWaGa015870@cvs-int.fedora.redhat.com> References: <200505161832.j4GIWaGa015870@cvs-int.fedora.redhat.com> Message-ID: <20050517155627.7e207bf8.bugs.michael@gmx.net> On Mon, 16 May 2005 14:32:36 -0400, G__rard Milmeister wrote: > Log Message: > request build of rpms/unison/FC-3 unison-2_10_2-4 for FC3 > gijs rpms/python-cherrytemplate/FC-3 python-cherrytemplate-1_0_0-2_fc3 fc3 > gijs rpms/python-cherrytemplate/devel python-cherrytemplate-1_0_0-2_fc4 devel > otaylor rpms/fontforge/devel fontforge-0_0-2_20050502_fc4 devel > +gemi rpms/unison/FC-3 unison-2_10_2-4 FC3 Trying to track down the status of this build request, but find myself unable to do so at http://extras64.linux.duke.edu/ How do I interpret the stuff in the "active" directory? What is the build system busy with right now? Or in case it's idle, where is unison-2_10_2-4? From kaboom at oobleck.net Tue May 17 15:37:40 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 17 May 2005 11:37:40 -0400 (EDT) Subject: request for review: hobbit In-Reply-To: <1115846794.3251.17.camel@laptop.mpeters.local> References: <1115846794.3251.17.camel@laptop.mpeters.local> Message-ID: On Wed, 11 May 2005, Michael A. Peters wrote: > On Wed, 2005-05-11 at 15:47 -0400, Chris Ricker wrote: > > Anyone interested in reviewing hobbit? > > > > > > > > hobbit's a GPL'ed replacement for the server component of Big Brother. It > > works with the Big Brother client (non-free), or with the free > > hobbit clients which are under development, to monitor server / > > application / network / etc. status > > Just a note - a company I used to work for had a webapp server that we > wanted to call Gandalf, but the lawyers wouldn't let us because > apparently the Tolkein family was legal happy or something. I don't know > if hobbit would have the same issue, were hobbits something Tolkein took > from lore, or is the name his invention? The name has been used elsewhere (ie, the Hobbit Sinclair derivative computer which was developed in the Soviet Union and sold for a time in the UK without action from the Tolkien estate), including in usage which pre-dates Tolkien; see for some discussion about this. It does appear that "hobbit" is trademarked, though. Whether the trademark would extend to an acronym name for a computer program, I don't know. IANAL, etc. Thoughts? thanks, chris From Jochen at herr-schmitt.de Tue May 17 15:42:01 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 17 May 2005 17:42:01 +0200 Subject: New Package: kyum In-Reply-To: <4289F654.7090907@city-fan.org> References: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> <4289F654.7090907@city-fan.org> Message-ID: <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> On Tue, 17 May 2005 14:49:08 +0100, you wrote: >Why hardcode /usr in "%configure --prefix=/usr"? > >Please be consistent about use of %{buildroot} and $RPM_BUILD_ROOT; >choose one and then use it everywhere. > >Why rename the desktop file ("mv -f fedora-%{name}.desktop >%{name}.desktop")? Thank you for your comments. I have uploaded a modified version of the source RPM to: http://www.herr-schmitt.de/pub/kyum/kyum-0.6.3-1.src.rpm It will be nice if you can sponsor it, so I can import it to the CVS. Best Regards: Jochen Schmitt From daniel-wittenberg at starken.com Tue May 17 16:01:36 2005 From: daniel-wittenberg at starken.com (Dan Wittenberg) Date: Tue, 17 May 2005 11:01:36 -0500 Subject: Epoch + snort sponser In-Reply-To: <1116314498.4628.94.camel@laurel.intra.city-fan.org> References: <1115701804.25390.7.camel@plasma.starken.com> <80d7e409050510164830c08c2a@mail.gmail.com> <1115772905.5219.0.camel@localhost.localdomain> <80d7e409050511094976e46cb2@mail.gmail.com> <1116016810.16434.11.camel@plasma.starken.com> <1116017467.4628.64.camel@laurel.intra.city-fan.org> <1116306942.5189.5.camel@localhost.localdomain> <1116314498.4628.94.camel@laurel.intra.city-fan.org> Message-ID: <1116345696.2174.1.camel@tux.its.uiowa.edu> Yeah, I was thinking the opposite though, do something special ONLY if we are fedora, but I guess it's just a matter of 1/0's so it would work the other way too. I'll look at adding that in. So is that the consensus then that if build snort on fedora it should always build all the RPM's? I'm not sure I like that myself, but we'll go with the consensus... Dan On Tue, 2005-05-17 at 02:21, Paul Howarth wrote: > On Tue, 2005-05-17 at 00:15 -0500, Daniel Wittenberg wrote: > > Well, RHEL is only one...there are other RPM-based systems these are > > built on, so it would have to be something that says something like: > > > > %if 0%{?fedora} <- I don't understand this one > > %define flexresp 1 > > %define mysql 1 > > %define postgresql 1 > > %endif > > The comment (above this snippet) didn't match the code. It should have > said: > > # Do something special if we're not built for Fedora. > %if !0%{?fedora} > Vendor: blah > Packager: blah > %endif > > For RHEL it would have been "%if !0{?rhel}" > > Paul. -- ======================= Daniel Wittenberg RHCE President/CTO The Starken Group Ltd. http://www.starken.com From ville.skytta at iki.fi Tue May 17 16:18:13 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 17 May 2005 19:18:13 +0300 Subject: Static libs (was: Re: Approval needed again: SCIM) In-Reply-To: <4289CF29.90504@redhat.com> References: <4288869E.7060306@mbm.nifty.com> <4289CF29.90504@redhat.com> Message-ID: <1116346693.2084.154.camel@bobcat.mine.nu> On Tue, 2005-05-17 at 20:02 +0900, Jens Petersen wrote: > (I'm actually planning to propose for FC5 to move (all) static > libs to -static subpackages in order to make -devel packages lighter.) FWIW, you have my +1 on that. Additionally in the vast majority of cases, static libs wouldn't even be needed in the first place... but suggesting dropping them or disabling the -static subpackages by default, guarded by "--with static" or somesuch rpmbuild flag might be too controversial... or would it, WDYT? From notting at redhat.com Tue May 17 16:23:30 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 17 May 2005 12:23:30 -0400 Subject: Static libs (was: Re: Approval needed again: SCIM) In-Reply-To: <1116346693.2084.154.camel@bobcat.mine.nu> References: <4288869E.7060306@mbm.nifty.com> <4289CF29.90504@redhat.com> <1116346693.2084.154.camel@bobcat.mine.nu> Message-ID: <20050517162330.GB18434@nostromo.devel.redhat.com> Ville Skytt? (ville.skytta at iki.fi) said: > On Tue, 2005-05-17 at 20:02 +0900, Jens Petersen wrote: > > > (I'm actually planning to propose for FC5 to move (all) static > > libs to -static subpackages in order to make -devel packages lighter.) > > FWIW, you have my +1 on that. Additionally in the vast majority of > cases, static libs wouldn't even be needed in the first place... but > suggesting dropping them or disabling the -static subpackages by > default, guarded by "--with static" or somesuch rpmbuild flag might be > too controversial... or would it, WDYT? Most -static stuff can just go away, yes. For example, we ship a static libgnome, but no static gtk2. Which doesn't really make sense... Bill From paul at city-fan.org Tue May 17 16:41:02 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 17 May 2005 17:41:02 +0100 Subject: New Package: kyum In-Reply-To: <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> References: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> <4289F654.7090907@city-fan.org> <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> Message-ID: <428A1E9E.2040707@city-fan.org> Jochen Schmitt wrote: > On Tue, 17 May 2005 14:49:08 +0100, you wrote: > > >>Why hardcode /usr in "%configure --prefix=/usr"? >> >>Please be consistent about use of %{buildroot} and $RPM_BUILD_ROOT; >>choose one and then use it everywhere. >> >>Why rename the desktop file ("mv -f fedora-%{name}.desktop >>%{name}.desktop")? > > > Thank you for your comments. > > I have uploaded a modified version of the source RPM to: > > http://www.herr-schmitt.de/pub/kyum/kyum-0.6.3-1.src.rpm > > It will be nice if you can sponsor it, so I can import it to the > CVS. I believe you need to be sponsored by someone in the "Trusted Contributors" list at: http://fedoraproject.org/wiki/Extras_2fContributors I'm nowhere near familiar enough with Fedora Extras processes to be on that list yet. Paul. From kaboom at oobleck.net Tue May 17 16:53:44 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 17 May 2005 12:53:44 -0400 (EDT) Subject: Static libs (was: Re: Approval needed again: SCIM) In-Reply-To: <20050517162330.GB18434@nostromo.devel.redhat.com> References: <4288869E.7060306@mbm.nifty.com> <4289CF29.90504@redhat.com> <1116346693.2084.154.camel@bobcat.mine.nu> <20050517162330.GB18434@nostromo.devel.redhat.com> Message-ID: On Tue, 17 May 2005, Bill Nottingham wrote: > Ville Skytt? (ville.skytta at iki.fi) said: > > FWIW, you have my +1 on that. Additionally in the vast majority of > > cases, static libs wouldn't even be needed in the first place... but > > suggesting dropping them or disabling the -static subpackages by > > default, guarded by "--with static" or somesuch rpmbuild flag might be > > too controversial... or would it, WDYT? > > Most -static stuff can just go away, yes. > > For example, we ship a static libgnome, but no static gtk2. Which > doesn't really make sense... For comparison, no static system libraries are available on Solaris 10 and prior releases only shipped 32-bit static system libs.... Going that far seems a little drastic to me, though -- static linking is sometimes useful, such as for chroot simplicity later, chris From qspencer at ieee.org Tue May 17 17:20:24 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Tue, 17 May 2005 12:20:24 -0500 Subject: x86_64 status (was Re: Errors on x86_64 (broken c++ headers?)) In-Reply-To: <1115923168.13475.22.camel@cutter> References: <428354A9.5040501@ieee.org> <4283702D.7060208@ieee.org> <1115912711.8237.416.camel@mccallum.corsepiu.local> <42837DFB.9030304@ieee.org> <1115920551.29062.22.camel@weasel.laiskiainen.org> <1115921494.29062.28.camel@weasel.laiskiainen.org> <4283A0E0.2030203@ieee.org> <1115923168.13475.22.camel@cutter> Message-ID: <428A27D8.7020207@ieee.org> On May 12, seth vidal wrote: >... > > > >no it means we have to fix the buildroot creation so for x86_64 there >are no i386/i686/etc packages allowed. > >I'm working on making that easier now. bear with me. > > Any update on this yet? -Quentin From Jochen at herr-schmitt.de Tue May 17 17:25:14 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 17 May 2005 19:25:14 +0200 Subject: New Package: kyum In-Reply-To: <428A1E9E.2040707@city-fan.org> References: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> <4289F654.7090907@city-fan.org> <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> <428A1E9E.2040707@city-fan.org> Message-ID: <0MKwh2-1DY5oi2lrU-0002KH@mrelayeu.kundenserver.de> On Tue, 17 May 2005 17:41:02 +0100, you wrote: >I believe you need to be sponsored by someone in the "Trusted >Contributors" list at: > >http://fedoraproject.org/wiki/Extras_2fContributors > >I'm nowhere near familiar enough with Fedora Extras processes to be on >that list yet. The NewPackageProcess document explain, that I need another Fedora Extra Contributor or RH engineer who is willing to approve the package. So It will be nice, if soneone can review and approve my package. For a second question: Which person have the right to take the role of a 'Fedora Extras Contributor'? Best Regards: Jochen Schmitt From ivazquez at ivazquez.net Tue May 17 17:29:36 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 17 May 2005 13:29:36 -0400 Subject: New Package: kyum In-Reply-To: <0MKwh2-1DY5oi2lrU-0002KH@mrelayeu.kundenserver.de> References: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> <4289F654.7090907@city-fan.org> <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> <428A1E9E.2040707@city-fan.org> <0MKwh2-1DY5oi2lrU-0002KH@mrelayeu.kundenserver.de> Message-ID: <1116350976.7161.17.camel@ignacio.ignacio.lan> On Tue, 2005-05-17 at 19:25 +0200, Jochen Schmitt wrote: > For a second question: Which person have the right to take the > role of a 'Fedora Extras Contributor'? If you have CVS access then you're definitely a contributor. But I think you just need to send in your CLA and find someone to sponsor you, then you're a contributor. I still wouldn't recommend approving other peoples packages though until you have a few of your own under your belt. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Jochen at herr-schmitt.de Tue May 17 17:36:59 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 17 May 2005 19:36:59 +0200 Subject: New Package: kyum In-Reply-To: <1116350976.7161.17.camel@ignacio.ignacio.lan> References: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> <4289F654.7090907@city-fan.org> <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> <428A1E9E.2040707@city-fan.org> <0MKwh2-1DY5oi2lrU-0002KH@mrelayeu.kundenserver.de> <1116350976.7161.17.camel@ignacio.ignacio.lan> Message-ID: <0MKxQS-1DY60527zg-0007eC@mrelayeu.kundenserver.de> On Tue, 17 May 2005 13:29:36 -0400, you wrote: >If you have CVS access then you're definitely a contributor. But I think >you just need to send in your CLA and find someone to sponsor you, then >you're a contributor. Thank you for your answer. Becouse you have to send in a CLA and find a sponsor to get CVS access, you can say: Eeverybody who have CVS access are a Fedora Extras Contributor. >I still wouldn't recommend approving other peoples packages though until >you have a few of your own under your belt. I agree with your mind. I think it will be helpful to get a feeling and experience for the packaging guidlines and so one, before you approve other peoples packages. Best Regards: From bugs.michael at gmx.net Tue May 17 17:54:01 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 17 May 2005 19:54:01 +0200 Subject: New Package: kyum In-Reply-To: <428A1E9E.2040707@city-fan.org> References: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> <4289F654.7090907@city-fan.org> <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> <428A1E9E.2040707@city-fan.org> Message-ID: <20050517195401.750fd97e.bugs.michael@gmx.net> On Tue, 17 May 2005 17:41:02 +0100, Paul Howarth wrote: > > http://www.herr-schmitt.de/pub/kyum/kyum-0.6.3-1.src.rpm > > > > It will be nice if you can sponsor it, so I can import it to the > > CVS. > > I believe you need to be sponsored by someone in the "Trusted > Contributors" list at: > > http://fedoraproject.org/wiki/Extras_2fContributors > > I'm nowhere near familiar enough with Fedora Extras processes to be on > that list yet. No problem if we would just get the terminology right, please. ;) Packages are not sponsored, but _reviewed_ and _approved_ by another contributor. On the contrary, people and their CVS accounts are sponsored. Conclusively, Jochen is in search for somebody to review and approve kyum. He has CVS access already. From a.kurtz at hardsun.net Tue May 17 18:01:32 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Tue, 17 May 2005 11:01:32 -0700 Subject: New package: denyhosts In-Reply-To: References: Message-ID: <1116352893.4324.8.camel@rydia.hardsun.net> On Fri, 2005-05-13 at 15:12 -0500, Jason L Tibbitts III wrote: > Denyhosts is a little bit of Python called out of cron that looks > through /var/log/secure, picks out hosts doing those annoying mass SSH > login attempts and stuffs them in /etc/hosts.deny. It lives at > http://denyhosts.sf.net > > I'm relatively new at this, but I needed to make a package for > denyhosts to deploy on my externally-facing login boxes and figured > I'd try to do it the right way. There aren't many packages that would > be simpler. RPM (not signed) and .spec are in > http://www.math.uh.edu/~tibbs/denyhosts Dist Tag? http://fedoraproject.org/wiki/DistTag If you change Source0 to http://dl.sourceforge.net/denyhosts/DenyHosts-%{version}.tar.gz one can download new versions with just "spectool -g denyhost.spec". Also, where are the other Sources and Patch available? No srpm that I can find, and so I'm unable to rebuild this. -- Aaron Kurtz References: <1114632432.426ff0f0f40d4@pah.cert.ucr.edu> <1114639548.5061.14.camel@ignacio.ignacio.lan> Message-ID: <428A37E4.4030905@cert.ucr.edu> Ignacio Vazquez-Abrams wrote: > On Wed, 2005-04-27 at 13:07 -0700, glen at mail.cert.ucr.edu wrote: > >>Hi there, >> >>So I put together a little app for configuring an NIS server, and I was hoping >>to get it into Fedora extras. You can check it out here by the way: >>http://pah.cert.ucr.edu/~glen/system-config-nis.tar.bz2 >> >>In looking at the extras site it looks like I'll need someone to sponser me >>before I can get my junk added to extras, and so I was hoping someone could >>sponser me, or at least let me know what else I need to do at this point to get >>my package accepted. > > > http://www.fedoraproject.org/wiki/NewPackageProcess > > The first step would be to actually create a package, and not just have > a tarball for it. Well, if you open the tarball up, you'll see that I've tried to do just that. I have a spec file and all. But I'm still having trouble getting xgettext to work on my python code so I can do the internationalization junk. And I really don't get it, the same command seems to work just fine on the python code from redhat-config-rootpassword, but on my code it doesn't spit out anything. So maybe someone could lend a hand here? Oh, and I reorginized my web stuff a little, so you can grab the thing here now: http://pah.cert.ucr.edu/~glen/config_tools/system-config-nis.tar.bz2 From tibbs at math.uh.edu Tue May 17 18:32:50 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 17 May 2005 13:32:50 -0500 Subject: New package: denyhosts In-Reply-To: <1116352893.4324.8.camel@rydia.hardsun.net> (Aaron Kurtz's message of "Tue, 17 May 2005 11:01:32 -0700") References: <1116352893.4324.8.camel@rydia.hardsun.net> Message-ID: >>>>> "AK" == Aaron Kurtz writes: AK> Dist Tag? http://fedoraproject.org/wiki/DistTag I'm not sure what purpose it would serve. The package is pretty much independent of the distro version. AK> If you change Source0 to AK> http://dl.sourceforge.net/denyhosts/DenyHosts-%{version}.tar.gz AK> one can download new versions with just "spectool -g AK> denyhost.spec". I didn't realize that. I'll fix it with my next set of edits. AK> Also, where are the other Sources and Patch available? No srpm AK> that I can find, and so I'm unable to rebuild this. I've copied the SRPM into http://www.math.uh.edu/~tibbs/denyhosts BTW, I've found that after making this package that unfortunately DenyHosts doesn't really fit my requirements because it doesn't age out entries. So a user unlucky enough to mistype his passwords five times in total from the same IP gets blocked, regardless of the frequency of the mistakes. Crap. So I have to decide whether to improve my Python by hacking on DenyHosts, to take the easy road and rewrite it in Perl. Or, hey, I've been meaning to learn Ruby. - J< From fedora at camperquake.de Tue May 17 18:39:24 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 17 May 2005 20:39:24 +0200 Subject: Request for approval: enemies-of-carlotta Message-ID: <20050517203924.28b84825@nausicaa.camperquake.de> Hi. I'd like to request a review and approval of enemies-of-carlotta. I have imported this package into CVS some time ago (and some review work was done back then), but it has never been formally approved. The package is very simple, so a review should not take long. Thanks. -- "Falling in love is like catching knives. In time, you can learn to do it without hurting yourself every time. It's still a dangerous proposition, though." -- russ From kaboom at oobleck.net Tue May 17 18:39:39 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 17 May 2005 14:39:39 -0400 (EDT) Subject: request for review: autossh Message-ID: If anyone else finds autossh useful, I've put a package of it up: autossh is a utility to start and monitor an ssh tunnel. If the tunnel dies or stops passing traffic, autossh will automatically restart it. later, chris From mattdm at mattdm.org Tue May 17 18:42:09 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 17 May 2005 14:42:09 -0400 Subject: New package: denyhosts In-Reply-To: References: <1116352893.4324.8.camel@rydia.hardsun.net> Message-ID: <20050517184209.GA20378@jadzia.bu.edu> On Tue, May 17, 2005 at 01:32:50PM -0500, Jason L Tibbitts III wrote: > AK> Dist Tag? http://fedoraproject.org/wiki/DistTag > I'm not sure what purpose it would serve. The package is pretty much > independent of the distro version. Right -- that's the purpose it serves. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 76 degrees Fahrenheit. From skvidal at phy.duke.edu Tue May 17 19:52:06 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 17 May 2005 15:52:06 -0400 Subject: x86_64 status (was Re: Errors on x86_64 (broken c++ headers?)) In-Reply-To: <428A27D8.7020207@ieee.org> References: <428354A9.5040501@ieee.org> <4283702D.7060208@ieee.org> <1115912711.8237.416.camel@mccallum.corsepiu.local> <42837DFB.9030304@ieee.org> <1115920551.29062.22.camel@weasel.laiskiainen.org> <1115921494.29062.28.camel@weasel.laiskiainen.org> <4283A0E0.2030203@ieee.org> <1115923168.13475.22.camel@cutter> <428A27D8.7020207@ieee.org> Message-ID: <1116359526.20274.75.camel@cutter> On Tue, 2005-05-17 at 12:20 -0500, Quentin Spencer wrote: > On May 12, seth vidal wrote: > > >... > > > > > > > >no it means we have to fix the buildroot creation so for x86_64 there > >are no i386/i686/etc packages allowed. > > > >I'm working on making that easier now. bear with me. > > > > > > Any update on this yet? > http://blog.sethdot.org/index.cgi/226.html -sv From a.kurtz at hardsun.net Tue May 17 20:06:13 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Tue, 17 May 2005 13:06:13 -0700 Subject: New package: denyhosts In-Reply-To: References: <1116352893.4324.8.camel@rydia.hardsun.net> Message-ID: <1116360373.4324.36.camel@rydia.hardsun.net> On Tue, 2005-05-17 at 13:32 -0500, Jason L Tibbitts III wrote: > >>>>> "AK" == Aaron Kurtz writes: > > AK> Dist Tag? http://fedoraproject.org/wiki/DistTag > > I'm not sure what purpose it would serve. The package is pretty much > independent of the distro version. I thought packages were required to have a higher version for later FC releases, and Dist Tag is the best way to do that if you have the same version for multiple releases. > BTW, I've found that after making this package that unfortunately > DenyHosts doesn't really fit my requirements because it doesn't age > out entries. So a user unlucky enough to mistype his passwords five > times in total from the same IP gets blocked, regardless of the > frequency of the mistakes. Crap. So I have to decide whether to > improve my Python by hacking on DenyHosts, to take the easy road and > rewrite it in Perl. Or, hey, I've been meaning to learn Ruby. There is whitelisting by ip. But not by domain name. Hmm. This is not as fine-grained as I hoped. The default before blocking should probably be turned up a bit. Oh, and the whitelisting creates allowed-warned-hosts, which should be added to the spec. Should this really be turned on in post? The way it is, this runs a high risk of cutting off SSH users, and it's only turned on for the runlevel running when it's installed. I'd rather see it turned on manually. As for the various rpmlint errors, rpmlint -i gives more context about them. >From the SRPM, W: denyhosts strange-permission denyhosts.init 0755 Just a warning, but if you really wanted it to be quiet, just change the permission in the SRPM, since it gets installed with the proper bits set anyways. The other rpmlints errors are either not that important or dealt with in the diff. -- Aaron Kurtz From a.kurtz at hardsun.net Tue May 17 20:16:33 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Tue, 17 May 2005 13:16:33 -0700 Subject: New package: denyhosts In-Reply-To: <1116360373.4324.36.camel@rydia.hardsun.net> References: <1116352893.4324.8.camel@rydia.hardsun.net> <1116360373.4324.36.camel@rydia.hardsun.net> Message-ID: <1116360993.4324.38.camel@rydia.hardsun.net> On Tue, 2005-05-17 at 13:06 -0700, Aaron Kurtz wrote: > The other rpmlints errors are either not that important or dealt with in > the diff. Try this one actually. -- Aaron Kurtz From tcallawa at redhat.com Tue May 17 20:28:46 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 17 May 2005 15:28:46 -0500 Subject: New package: denyhosts In-Reply-To: <1116360373.4324.36.camel@rydia.hardsun.net> References: <1116352893.4324.8.camel@rydia.hardsun.net> <1116360373.4324.36.camel@rydia.hardsun.net> Message-ID: <1116361726.3502.10.camel@localhost.localdomain> On Tue, 2005-05-17 at 13:06 -0700, Aaron Kurtz wrote: > On Tue, 2005-05-17 at 13:32 -0500, Jason L Tibbitts III wrote: > > >>>>> "AK" == Aaron Kurtz writes: > > > > AK> Dist Tag? http://fedoraproject.org/wiki/DistTag > > > > I'm not sure what purpose it would serve. The package is pretty much > > independent of the distro version. > > I thought packages were required to have a higher version for later FC > releases, and Dist Tag is the best way to do that if you have the same > version for multiple releases. This statement is accurate. :) ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From bugs.michael at gmx.net Tue May 17 20:35:20 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 17 May 2005 22:35:20 +0200 Subject: New Package: kyum In-Reply-To: <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> References: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> <4289F654.7090907@city-fan.org> <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> Message-ID: <20050517223520.4de6bc8f.bugs.michael@gmx.net> On Tue, 17 May 2005 17:42:01 +0200, Jochen Schmitt wrote: > I have uploaded a modified version of the source RPM to: > > http://www.herr-schmitt.de/pub/kyum/kyum-0.6.3-1.src.rpm * It failed to build here, not finding Qt headers. You need to set $QTDIR at the beginning of %build with something like this: [ -n "$QTDIR" ] || . %{_sysconfdir}/profile.d/qt.sh * Package description says: "Note that you must be root to run this program!" This is not good. Make it that it's executed via kdesu [or consolehelper-gtk (aka usermode-gtk), and a PAM config file]. In the desktop file, it _is_ executed via kdesu, so the description is misleading. It should not encourage anybody to run KDE as root. * Due to using kdesu, a dependency on kdebase is missing. Dependency on kdelibs is automatic. * Desktop icon is stored in a path not found with GNOME. > kyum-0.6.3.tar.gz Tarball contains duplicate source code. One version in directory "kyum", the other in "kyum-0.6.3". Explains why it's twice its real size. > mkdir -p $RPM_BUILD_ROOT%{_datadir}/applnk/Utilities > desktop-file-install --delete-original \ > --vendor fedora \ > --dir $RPM_BUILD_ROOT%{_datadir}/applications/kde \ > --mode 0644 \ > --add-category X-Fedora \ > --add-category Application \ > --add-category SystemSetup \ > $RPM_BUILD_ROOT%{_datadir}/app*/*/%{name}.desktop > cd $RPM_BUILD_ROOT%{_datadir}/applications/kde First and last line of this block doesn't serve any purpose. > %{_docdir}/HTML/en/kyum/*.png > %{_docdir}/HTML/en/kyum/index* %_docdir/HTML/en/kyum directory is not included. No other documentation is included. No licence, no changelog. > /usr/share/apps/kyum/icons/hicolor/22x22/actions/abort.png %_datadir/apps/kyum directory and all its sub-directories are not included in the package either. > /usr/bin/kyum_sysinfo.py Script is -x. Its default command interpreter /bin/python does not exist on FC4. Such non-executable scripts are better stored in a data directory IMO. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1305_FC4 loadavg: 2.35 2.26 2.11 From tibbs at math.uh.edu Tue May 17 20:37:08 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 17 May 2005 15:37:08 -0500 Subject: New package: denyhosts In-Reply-To: <20050517184209.GA20378@jadzia.bu.edu> (Matthew Miller's message of "Tue, 17 May 2005 14:42:09 -0400") References: <1116352893.4324.8.camel@rydia.hardsun.net> <20050517184209.GA20378@jadzia.bu.edu> Message-ID: >>>>> "MM" == Matthew Miller writes: MM> Right -- that's the purpose it serves. Now I'm really confused. The same package works fine on FC1, 2, 3 and in all likelihood 4. So what's the purpose of using a disttag? The package would have exactly the same content. - J< From tcallawa at redhat.com Tue May 17 20:42:41 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 17 May 2005 15:42:41 -0500 Subject: New Package: kyum In-Reply-To: <20050517195401.750fd97e.bugs.michael@gmx.net> References: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> <4289F654.7090907@city-fan.org> <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> <428A1E9E.2040707@city-fan.org> <20050517195401.750fd97e.bugs.michael@gmx.net> Message-ID: <1116362561.3502.20.camel@localhost.localdomain> On Tue, 2005-05-17 at 19:54 +0200, Michael Schwendt wrote: > No problem if we would just get the terminology right, please. ;) Packages > are not sponsored, but _reviewed_ and _approved_ by another contributor. > On the contrary, people and their CVS accounts are sponsored. Conclusively, > Jochen is in search for somebody to review and approve kyum. He has CVS > access already. Review of kyum: Rpmlint checks: kyum-0.6.3-1.src.rpm E: kyum no-signature W: kyum strange-permission kyum-0.6.3.tar.gz 0400 kyum-0.6.3-1.i386.rpm W: kyum non-executable-in-bin /usr/bin/kyum_sysinfo.py 0644 E: kyum no-signature You might want to make /usr/bin/kyum_sysinfo.py executable if its sitting in /usr/bin, although it does not seem fatal to kyum functionality. All other errors are safe to ignore. Generic checks: Good: - source matches upstream - License is OK (GPL) - Meets package naming guidelines - Meets PackagingGuidelines (except for two exceptions in bad) Bad: - source is messy. It unpacks into kyum/ and kyum-0.6.3/, of which, only the latter is actually used. The upstream source should be fixed to remove the kyum directory (all the files in that dir are duplicated in kyum-0.6.3). This will also get the SRPM file size down a bit. - GPL requires that COPYING be included in binary distribution, refer to: http://www.gnu.org/licenses/gpl-faq.html#WhyMustIInclude . Easy enough to add %doc COPYING to the %files. Resolve the bad items and the rpmlint error I highlighted, and I will approve kyum. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From kaboom at oobleck.net Tue May 17 20:39:58 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 17 May 2005 16:39:58 -0400 (EDT) Subject: New package: denyhosts In-Reply-To: References: <1116352893.4324.8.camel@rydia.hardsun.net> <20050517184209.GA20378@jadzia.bu.edu> Message-ID: On Tue, 17 May 2005, Jason L Tibbitts III wrote: > >>>>> "MM" == Matthew Miller writes: > > MM> Right -- that's the purpose it serves. > > Now I'm really confused. The same package works fine on FC1, 2, 3 and > in all likelihood 4. So what's the purpose of using a disttag? The > package would have exactly the same content. That's the problem. package foo-1.0-1.arch.rpm built on FC3 is NOT the same package as foo-1.0-1.arch.rpm built on FC4, even if both are built from the identical foo.spec file. Dependencies may be different, paths may be different, etc. using %{?dist} just ensures that the release field reflects that they're different packages later, chris From tcallawa at redhat.com Tue May 17 20:45:44 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 17 May 2005 15:45:44 -0500 Subject: New Package: kyum In-Reply-To: <1116362561.3502.20.camel@localhost.localdomain> References: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> <4289F654.7090907@city-fan.org> <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> <428A1E9E.2040707@city-fan.org> <20050517195401.750fd97e.bugs.michael@gmx.net> <1116362561.3502.20.camel@localhost.localdomain> Message-ID: <1116362744.3502.24.camel@localhost.localdomain> On Tue, 2005-05-17 at 15:42 -0500, Tom 'spot' Callaway wrote: > Resolve the bad items and the rpmlint error I highlighted, and I will > approve kyum. ... and the other things that Michael found. He's a lot better at this than I am. :/ But I'm learning! ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Tue May 17 21:06:23 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 17 May 2005 16:06:23 -0500 Subject: Request for approval: enemies-of-carlotta In-Reply-To: <20050517203924.28b84825@nausicaa.camperquake.de> References: <20050517203924.28b84825@nausicaa.camperquake.de> Message-ID: <1116363983.3502.37.camel@localhost.localdomain> On Tue, 2005-05-17 at 20:39 +0200, Ralf Ertzinger wrote: > Hi. > > I'd like to request a review and approval of enemies-of-carlotta. I have > imported this package into CVS some time ago (and some review work was > done back then), but it has never been formally approved. The package is > very simple, so a review should not take long. Review of enemies-of-carlotta: Rpmlint checks: enemies-of-carlotta-1.0.3-2.src.rpm E: enemies-of-carlotta no-signature enemies-of-carlotta-1.0.3-2.i386.rpm E: enemies-of-carlotta no-binary E: enemies-of-carlotta no-signature The no-binary thing is notable. This package doesn't contain a single binary, its just a set of python scripts. For that reason, this package is probably best suited as noarch. I added "BuildArch: noarch", rebuilt, installed the package on one of my Aurora SPARC machines and it seems to function in my minimal tests. Summary: Good: - source matches upstream - License is OK (GPL), COPYING is included in package. - Meets package naming guidelines - Meets PackagingGuidelines - Documentation is included - Rpmlint checks passed (except for no-binary note) Bad: - Package should be noarch Thanks, ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From i at stingr.net Tue May 17 21:14:17 2005 From: i at stingr.net (Paul P Komkoff Jr) Date: Wed, 18 May 2005 01:14:17 +0400 Subject: request for review: rzip Message-ID: <20050517211417.GB13724@stingr.stingr.net> Thanks sopwith sponsored my cvsextras membership, so I've uploaded rzip to it. Any objections for it be present in extras for all branches ? -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From tibbs at math.uh.edu Tue May 17 21:34:15 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 17 May 2005 16:34:15 -0500 Subject: New package: denyhosts In-Reply-To: <1116360373.4324.36.camel@rydia.hardsun.net> (Aaron Kurtz's message of "Tue, 17 May 2005 13:06:13 -0700") References: <1116352893.4324.8.camel@rydia.hardsun.net> <1116360373.4324.36.camel@rydia.hardsun.net> Message-ID: >>>>> "AK" == Aaron Kurtz writes: AK> I thought packages were required to have a higher version for AK> later FC releases, and Dist Tag is the best way to do that if you AK> have the same version for multiple releases. I get the idea from the discussion that the Wiki page should be modified; it says it's completely optional and to me the language subtly discourages its use. However, it should be obvious from the discussion here that it's pretty much mandatory. AK> Should this really be turned on in post? I just copied yum: it chkconfigs itself on but doesn't start itself. It's possible for yum to nuke your system during your nightly update if your repositories are messed up, yet it enables itself in %post. It doesn't matter much to me, but I figured that copying an established package was the best way to get things right. - J< From perbj at stanford.edu Tue May 17 21:52:14 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Tue, 17 May 2005 14:52:14 -0700 Subject: New package: denyhosts In-Reply-To: References: <1116352893.4324.8.camel@rydia.hardsun.net> <1116360373.4324.36.camel@rydia.hardsun.net> Message-ID: <1116366734.4870.29.camel@localhost.localdomain> On Tue, 2005-05-17 at 16:34 -0500, Jason L Tibbitts III wrote: > >>>>> "AK" == Aaron Kurtz writes: > AK> Should this really be turned on in post? > > I just copied yum: it chkconfigs itself on but doesn't start itself. > It's possible for yum to nuke your system during your nightly update > if your repositories are messed up, yet it enables itself in %post. > It doesn't matter much to me, but I figured that copying an > established package was the best way to get things right. Yours (from the spec file you pointed to): ---- %post /sbin/chkconfig --add denyhosts /sbin/chkconfig denyhosts on /sbin/service denyhosts condrestart >> /dev/null exit 0 ---- >From yum.spec (as pulled from Fedora CVS): ---- %post /sbin/chkconfig --add yum /sbin/service yum condrestart >> /dev/null exit 0 ---- Note the difference: the "chkconfig on" line isn't there in yum.spec. That doesn't turn it on, it just registers it. The package should definitely register its initscript using chkconfig; turning it on is another story, especially for things that interact with network access. (Of course, in many cases this might not be as bad as, say, a telnet server auto-enabling itself, but still...) /Per From giallu at gmail.com Tue May 17 22:55:32 2005 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 18 May 2005 00:55:32 +0200 Subject: Extras contribution: sensors applet Message-ID: Hi all, I packaged a small gnome applet that shows, when available through lm_semsors, various data on the hardware like fan speeds, cpu and NB temperatures, voltages and so on. Of course, it would be really cute to have it as an official Extras package, so I am posting here hoping someone will "adopt" it; my SRPM is avaliable from: http://giallu.interfree.it/gnome-applet-sensors-0.7.3-0.1.src.rpm while the home page of the project is: http://sensors-applet.sourceforge.net thanks Gianluca From byte at aeon.com.my Tue May 17 23:02:51 2005 From: byte at aeon.com.my (Colin Charles) Date: Wed, 18 May 2005 09:02:51 +1000 Subject: Deprecated packages In-Reply-To: References: Message-ID: <1116370971.4564.351.camel@arena.soho.bytebot.net> On Mon, 2005-05-02 at 10:26 +0200, Aurelien Bompard wrote: > What should we do with packages of closed projects ? For example, elmo (a > text-based mail client) fails to build on PPC today, and the project is > closed since January (http://elmo.sf.net). It builds on PPC just fine; verified yesterday https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156491 Please request a build, thanks > Maybe this build failure can be fixed this time, but how should we > depreciate packages in general ? Is there some flag to add, some list where > it should be appended, or should we just remove the directory from CVS ? Well, if you're still interested in maintaining it, you now become the default maintainer for the software in Fedora world. Same thing happens with Debian... If you're however not interested in maintaining it, mention that its become an orphan, and is dead upstream and see if someone else wants to take over it But how we should deprecate packages in general is a good thing to discuss... -- Colin Charles, http://www.bytebot.net/ From kevin-fedora-extras at scrye.com Wed May 18 02:48:53 2005 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Tue, 17 May 2005 20:48:53 -0600 Subject: make new-sources issue Message-ID: <20050518024856.580753481F3@ningauble.scrye.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings. Xfce 4.2.2 was released today, so I want to get at least the devel rpms all updated. I have updated all the specs, regenerated some patches and confirmed everything builds and seems to work on my i386 devel box. I'm having a odd issue with the 'make new-sources' target however. Here's what I see: % make new-sources FILES="libxfce4util-4.2.2.tar.gz" Checking : libxfce4util-4.2.2.tar.gz on http://cvs.fedora.redhat.com/repo/extras/upload.cgi... ERROR: could not check remote file status make: *** [new-sources] Error 255 I do have the ssl cert in ~/.fedora.cert I have made sure that my ../../common/ area is all updated. Any ideas what I am doing wrong? Thanks for any pointers. kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 iD8DBQFCiq0X3imCezTjY0ERAo2AAJ9P7BMM++pwUG5Tm86/FQGi017AqwCfXgxg 1XPI7ZixeLE3t9TVsmfQ5Wk= =gUzc -----END PGP SIGNATURE----- From dwmw2 at infradead.org Wed May 18 08:44:51 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 18 May 2005 09:44:51 +0100 Subject: PPC FC4 machine available to maintainers. Message-ID: <1116405891.23972.135.camel@hades.cambridge.redhat.com> I've upgraded peach.infradead.org, which was previously building FC3 Extras, to rawhide. This means firstly that there will be no more FC3 PPC packages built, and secondly that there's a machine available for maintainers to debug problems which only occur on PPC. Contact me if you need access to it. -- dwmw2 From fedora at camperquake.de Wed May 18 09:06:36 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 18 May 2005 11:06:36 +0200 Subject: Request for approval: enemies-of-carlotta In-Reply-To: <1116363983.3502.37.camel@localhost.localdomain> References: <20050517203924.28b84825@nausicaa.camperquake.de> <1116363983.3502.37.camel@localhost.localdomain> Message-ID: <20050518090635.GA15791@ryoko.camperquake.de> On Tue, May 17, 2005 at 04:06:23PM -0500, Tom 'spot' Callaway wrote: > The no-binary thing is notable. This package doesn't contain a single > binary, its just a set of python scripts. For that reason, this package > is probably best suited as noarch. I made the package arch-specific because it precompiles the .py files and includes the .pyc file in the package. Is this format arch-independent (and while we are at it: what is the difference between pyc and pyo?) From a.kurtz at hardsun.net Wed May 18 09:19:15 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Wed, 18 May 2005 02:19:15 -0700 Subject: Request for approval: enemies-of-carlotta In-Reply-To: <20050518090635.GA15791@ryoko.camperquake.de> References: <20050517203924.28b84825@nausicaa.camperquake.de> <1116363983.3502.37.camel@localhost.localdomain> <20050518090635.GA15791@ryoko.camperquake.de> Message-ID: <1116407955.4324.61.camel@rydia.hardsun.net> On Wed, 2005-05-18 at 11:06 +0200, Ralf Ertzinger wrote: > On Tue, May 17, 2005 at 04:06:23PM -0500, Tom 'spot' Callaway wrote: > > > The no-binary thing is notable. This package doesn't contain a single > > binary, its just a set of python scripts. For that reason, this package > > is probably best suited as noarch. > > I made the package arch-specific because it precompiles the .py files > and includes the .pyc file in the package. Is this format arch-independent > (and while we are at it: what is the difference between pyc and pyo?) Python bytecord or .pyc is arch-independent. .pyo is optimized bytecode. http://www.network-theory.co.uk/docs/pytut/tut_48.html It is also guaranteed to work between say 2.4 and 2.4.1, but not 2.3 and 2.4. -- Aaron Kurtz References: <20050517203924.28b84825@nausicaa.camperquake.de> <1116363983.3502.37.camel@localhost.localdomain> <20050518090635.GA15791@ryoko.camperquake.de> <1116407955.4324.61.camel@rydia.hardsun.net> Message-ID: <20050518092416.GB15791@ryoko.camperquake.de> On Wed, May 18, 2005 at 02:19:15AM -0700, Aaron Kurtz wrote: > Python bytecord or .pyc is arch-independent. .pyo is optimized bytecode. > http://www.network-theory.co.uk/docs/pytut/tut_48.html > It is also guaranteed to work between say 2.4 and 2.4.1, but not 2.3 and > 2.4. Ah, I see. Thanks. From a.kurtz at hardsun.net Wed May 18 09:26:51 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Wed, 18 May 2005 02:26:51 -0700 Subject: Extras contribution: sensors applet In-Reply-To: References: Message-ID: <1116408411.4324.66.camel@rydia.hardsun.net> On Wed, 2005-05-18 at 00:55 +0200, Gianluca Sforna wrote: > Hi all, > I packaged a small gnome applet that shows, when available through > lm_semsors, various data on the hardware like fan speeds, cpu and NB > temperatures, voltages and so on. > Of course, it would be really cute to have it as an official Extras > package, so I am posting here hoping someone will "adopt" it; my SRPM > is avaliable from: I've offered to maintain this. Slightly updated files at: http://hardsun.net/fedora/gnome-applet-sensors.spec http://hardsun.net/fedora/gnome-applet-sensors-0.7.3-1.src.rpm Reviews and approval would be appreciated. -- Aaron Kurtz (Jason L. Tibbitts, III's message of "Tue, 17 May 2005 13:32:50 -0500") References: <1116352893.4324.8.camel@rydia.hardsun.net> Message-ID: >>>>> "JT" == Jason L Tibbitts writes: [...] JT> BTW, I've found that after making this package that unfortunately JT> DenyHosts doesn't really fit my requirements because it doesn't JT> age out entries. So a user unlucky enough to mistype his JT> passwords five times in total from the same IP gets blocked, JT> regardless of the frequency of the mistakes. Crap. Yes, that's a drawback I agree, but I think this is true only if the user makes the erroneous password within the lifetime of current log file: /var/log/secure, i.e. before it is rolled over, right? In other words if the logs are rolled over once a month, this means that the IP will be blocked only if there is five erroneous logins within that month. It doesn't scan back through all the old logs /var/log/secure.1 etc..., does it? I agree, however, that it should be "density-dependent", i.e. it should block IPs that make many logins over a short (on order of minutes) of activity, that's the usual pattern of ssh attacks, and it should be more trigger-happy when blocking usernames that don't exist. JT> So I have to decide whether to improve my Python by hacking on JT> DenyHosts, to take the easy road and rewrite it in Perl. Or, hey, JT> I've been meaning to learn Ruby. Please stick with Python, if you can... ;-) I'll be happy to look over any Python patches. What about the upstream author, is he actively maintaining it? I see some activity on the SourceForge mailing list. Cheers, Alex From Jochen at herr-schmitt.de Wed May 18 14:05:46 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 18 May 2005 16:05:46 +0200 Subject: New Package: kyum In-Reply-To: <20050517223520.4de6bc8f.bugs.michael@gmx.net> References: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> <4289F654.7090907@city-fan.org> <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> <20050517223520.4de6bc8f.bugs.michael@gmx.net> Message-ID: <0ML29c-1DYPBD0VSS-0008Pp@mrelayeu.kundenserver.de> On Tue, 17 May 2005 22:35:20 +0200, you wrote: >* Desktop icon is stored in a path not found with GNOME. I not understand your comment. Where should the icons stored, so they may be find from GNOME? Best Regards: Jochen Schmitt From Jochen at herr-schmitt.de Wed May 18 14:11:29 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 18 May 2005 16:11:29 +0200 Subject: New Package: kyum In-Reply-To: <20050517223520.4de6bc8f.bugs.michael@gmx.net> References: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> <4289F654.7090907@city-fan.org> <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> <20050517223520.4de6bc8f.bugs.michael@gmx.net> Message-ID: <0MKxQS-1DYPGk2YMk-00055U@mrelayeu.kundenserver.de> On Tue, 17 May 2005 22:35:20 +0200, you wrote: >> kyum-0.6.3.tar.gz > >Tarball contains duplicate source code. One version in directory "kyum", >the other in "kyum-0.6.3". Explains why it's twice its real size. Thank you for your comment. I have doublechecked it and it seems, that this is a upstream problem. I will contact the upstream author to solve this problem. Best Regards: Jochen schmitt From fedora at camperquake.de Wed May 18 15:38:14 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 18 May 2005 17:38:14 +0200 Subject: Request for approval: enemies-of-carlotta In-Reply-To: <1116363983.3502.37.camel@localhost.localdomain> References: <20050517203924.28b84825@nausicaa.camperquake.de> <1116363983.3502.37.camel@localhost.localdomain> Message-ID: <20050518173814.306a3e0a@nausicaa.camperquake.de> Hi. "Tom 'spot' Callaway" wrote: > Bad: > - Package should be noarch The package is noarch now, and I added a %{dist} to the release. -- "No, I'm not going to explain it. If you can't figure it out, you didn't want to know anyways..." -- Larry Wall From qspencer at ieee.org Wed May 18 15:38:45 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Wed, 18 May 2005 10:38:45 -0500 Subject: Approval needed: cln, GiNaC Message-ID: <428B6185.6090005@ieee.org> These two packages are in CVS and need final approval. The cln library is used by GiNaC. The best way to test these two packages is to build them both and then run ginsh from the GiNaC-utils package. cln (Class Library for Numbers): A collection of C++ math classes and functions, which are designed for memory and speed efficiency, and enable type safety and algebraic syntax. GiNaC GiNaC (which stands for "GiNaC is Not a CAS (Computer Algebra System)") is an open framework for symbolic computation within the C++ programming language. This package includes ginsh ("GiNaC interactive shell") which provides a simple and easy-to-use CAS-like interface to GiNaC for non-programmers, and the tool "viewgar" which displays the contents of GiNaC archives. From tcallawa at redhat.com Wed May 18 15:50:00 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 18 May 2005 10:50:00 -0500 Subject: Request for approval: enemies-of-carlotta In-Reply-To: <20050518173814.306a3e0a@nausicaa.camperquake.de> References: <20050517203924.28b84825@nausicaa.camperquake.de> <1116363983.3502.37.camel@localhost.localdomain> <20050518173814.306a3e0a@nausicaa.camperquake.de> Message-ID: <1116431400.3502.73.camel@localhost.localdomain> On Wed, 2005-05-18 at 17:38 +0200, Ralf Ertzinger wrote: > Hi. > > "Tom 'spot' Callaway" wrote: > > > Bad: > > - Package should be noarch > > The package is noarch now, and I added a %{dist} to the release. Approved. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From nhorman at redhat.com Wed May 18 16:06:12 2005 From: nhorman at redhat.com (Neil Horman) Date: Wed, 18 May 2005 12:06:12 -0400 Subject: New package: cogito Message-ID: <20050518160612.GJ5638@hmsendeavour.rdu.redhat.com> Hello all- Package Name: cogito Version: 0.10 Release: 1 Description: cogito is an scm frontend to git, the database plumbing used for revision control on the upstream Linux source tree. As the version number indicates, its still in pre-release, but its actively used to manage both its own upstream project, and the Linux tree, so as such I think it would be a good idea if we had it pre-packaged for easy install. Its GPL'ed, and the package passes rpmlint with no errors or warnings. As this is a request for a new package I'd appreciate an initial review/approval. the SRPM can be found at: http://people.redhat.com/nhorman/cogito-0.10-1.src.rpm and the spec file is at: http://people.redhat.com/nhorman/cogito.spec md5sums: b8075fdabe946436bbc6ebb26c96cfbe cogito-0.10-1.src.rpm 9f497edc5dadb9a389ff33ddce3254b3 cogito.spec Thanks and Regards Neil -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman at redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Wed May 18 16:30:28 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 18 May 2005 11:30:28 -0500 Subject: New package: cogito In-Reply-To: <20050518160612.GJ5638@hmsendeavour.rdu.redhat.com> References: <20050518160612.GJ5638@hmsendeavour.rdu.redhat.com> Message-ID: <1116433828.3502.77.camel@localhost.localdomain> On Wed, 2005-05-18 at 12:06 -0400, Neil Horman wrote: > Hello all- > > Package Name: cogito On May 3, Chris Wright posted a cogito package for review, which Dave Jones suggested that it was too early, that it should "sit things out a bit longer before its added, even to extras, until its got a few more battle-scars." Thread here: https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00039.html You guys should all work together on this, since there seems to be a lot of people interested in this code, and decide when its ready for review. Thanks, ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From nhorman at redhat.com Wed May 18 16:58:11 2005 From: nhorman at redhat.com (Neil Horman) Date: Wed, 18 May 2005 12:58:11 -0400 Subject: New package: cogito In-Reply-To: <1116433828.3502.77.camel@localhost.localdomain> References: <20050518160612.GJ5638@hmsendeavour.rdu.redhat.com> <1116433828.3502.77.camel@localhost.localdomain> Message-ID: <20050518165811.GL5638@hmsendeavour.rdu.redhat.com> On Wed, May 18, 2005 at 11:30:28AM -0500, Tom 'spot' Callaway wrote: > On Wed, 2005-05-18 at 12:06 -0400, Neil Horman wrote: > > Hello all- > > > > Package Name: cogito > > On May 3, Chris Wright posted a cogito package for review, which Dave > Jones suggested that it was too early, that it should "sit things out a > bit longer before its added, even to extras, until its got a few more > battle-scars." > > Thread here: > https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00039.html > > You guys should all work together on this, since there seems to be a lot > of people interested in this code, and decide when its ready for review. > > Thanks, > > ~spot I just read the thread, and I understand Daves point, but given that there is clearly interest in having this pre-packaged (for the obvious reason that it makes working with upstream that much easier), I think that may outweigh the concern that people would begin to rely on it for other projects prematurely. Perhaps it would be sufficient to add a patch to the cg-init source such that it placed a disclaimer banner up on the console whenever a new repository was created, warning the user of the potential for future incompatibilities? That would give us the convienience that I'm sure we're all looking for, and ward off the people who don't understand quite how young cogito/git are. Regards Neil > -- > Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 > Fedora Extras Steering Committee Member (RPM Standards and Practices) > Aurora Linux Project Leader: http://auroralinux.org > Lemurs, llamas, and sparcs, oh my! > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman at redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Jochen at herr-schmitt.de Wed May 18 17:09:07 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 18 May 2005 19:09:07 +0200 Subject: New Package: kyum In-Reply-To: <20050517223520.4de6bc8f.bugs.michael@gmx.net> References: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> <4289F654.7090907@city-fan.org> <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> <20050517223520.4de6bc8f.bugs.michael@gmx.net> Message-ID: <0MKwpI-1DYS2e3SIz-0002kY@mrelayeu.kundenserver.de> On Tue, 17 May 2005 22:35:20 +0200, you wrote: >* Desktop icon is stored in a path not found with GNOME. The path /usr/share/icons/*/*/apps/ should be correct for the icons? I have make a test with GNOME, and I could say the KYUM icon. >> %{_docdir}/HTML/en/kyum/*.png >> %{_docdir}/HTML/en/kyum/index* Thsi should avoid the inclussion of the common part and so on. I have double checked it, and it seems, that no impoert file will be gone lost. Best Regards: Jochen Schmitt From nhorman at redhat.com Wed May 18 17:11:29 2005 From: nhorman at redhat.com (Neil Horman) Date: Wed, 18 May 2005 13:11:29 -0400 Subject: New package: cogito In-Reply-To: <20050518165811.GL5638@hmsendeavour.rdu.redhat.com> References: <20050518160612.GJ5638@hmsendeavour.rdu.redhat.com> <1116433828.3502.77.camel@localhost.localdomain> <20050518165811.GL5638@hmsendeavour.rdu.redhat.com> Message-ID: <20050518171129.GM5638@hmsendeavour.rdu.redhat.com> On Wed, May 18, 2005 at 12:58:11PM -0400, Neil Horman wrote: > On Wed, May 18, 2005 at 11:30:28AM -0500, Tom 'spot' Callaway wrote: > > On Wed, 2005-05-18 at 12:06 -0400, Neil Horman wrote: > > > Hello all- > > > > > > Package Name: cogito > > > > On May 3, Chris Wright posted a cogito package for review, which Dave > > Jones suggested that it was too early, that it should "sit things out a > > bit longer before its added, even to extras, until its got a few more > > battle-scars." > > > > Thread here: > > https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00039.html > > > > You guys should all work together on this, since there seems to be a lot > > of people interested in this code, and decide when its ready for review. > > > > Thanks, > > > > ~spot > > I just read the thread, and I understand Daves point, but given that there is > clearly interest in having this pre-packaged (for the obvious reason that it > makes working with upstream that much easier), I think that may outweigh the > concern that people would begin to rely on it for other projects prematurely. > Perhaps it would be sufficient to add a patch to the cg-init source such that it > placed a disclaimer banner up on the console whenever a new repository was > created, warning the user of the potential for future incompatibilities? > > That would give us the convienience that I'm sure we're all looking for, and > ward off the people who don't understand quite how young cogito/git are. > > Regards > Neil > I just uploaded a new srpm and spec to the same location as below which adds just such a disclaimer to the cg-init script, if anyone is interested in taking a look. md5sums: 11698a05b84448245f22ea9a3897d890 cogito-0.10-1.src.rpm ed407d65fd9b220d46764821f9f4b62d cogito.spec > > -- > > Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 > > Fedora Extras Steering Committee Member (RPM Standards and Practices) > > Aurora Linux Project Leader: http://auroralinux.org > > Lemurs, llamas, and sparcs, oh my! > > > > -- > > fedora-extras-list mailing list > > fedora-extras-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-extras-list > > -- > /*************************************************** > *Neil Horman > *Software Engineer > *Red Hat, Inc. > *nhorman at redhat.com > *gpg keyid: 1024D / 0x92A74FA1 > *http://pgp.mit.edu > ***************************************************/ > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman at redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Wed May 18 17:28:26 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 18 May 2005 12:28:26 -0500 Subject: Review/Approval needed: mfstools Message-ID: <1116437306.3502.83.camel@localhost.localdomain> This package is in CVS and needs review and approval. Its quite small. MFS Tools is a set of utilities for TiVo drive upgrades. This includes MFS specific backup and restore, as well as MFS volume expansion and shrinking. No libraries, one binary, and a few symlinks. :) Please review, thanks. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From bugs.michael at gmx.net Wed May 18 18:06:33 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 18 May 2005 20:06:33 +0200 Subject: New Package: kyum In-Reply-To: <0ML29c-1DYPBD0VSS-0008Pp@mrelayeu.kundenserver.de> References: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> <4289F654.7090907@city-fan.org> <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> <20050517223520.4de6bc8f.bugs.michael@gmx.net> <0ML29c-1DYPBD0VSS-0008Pp@mrelayeu.kundenserver.de> Message-ID: <20050518200633.6d653ab2.bugs.michael@gmx.net> On Wed, 18 May 2005 16:05:46 +0200, Jochen Schmitt wrote: > On Tue, 17 May 2005 22:35:20 +0200, you wrote: > > >* Desktop icon is stored in a path not found with GNOME. > > I not understand your comment. Where should the icons stored, so > they may be find from GNOME? %{_datadir}/pixmaps is common. From bugs.michael at gmx.net Wed May 18 18:06:36 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 18 May 2005 20:06:36 +0200 Subject: New Package: kyum In-Reply-To: <0MKwpI-1DYS2e3SIz-0002kY@mrelayeu.kundenserver.de> References: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> <4289F654.7090907@city-fan.org> <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> <20050517223520.4de6bc8f.bugs.michael@gmx.net> <0MKwpI-1DYS2e3SIz-0002kY@mrelayeu.kundenserver.de> Message-ID: <20050518200636.020b57d3.bugs.michael@gmx.net> On Wed, 18 May 2005 19:09:07 +0200, Jochen Schmitt wrote: > On Tue, 17 May 2005 22:35:20 +0200, you wrote: > > >* Desktop icon is stored in a path not found with GNOME. > > The path /usr/share/icons/*/*/apps/ should be correct for the > icons? > > I have make a test with GNOME, and I could say the KYUM icon. Well, here it not visible: Desktop > System Settings > More System Settings > KYum > >> %{_docdir}/HTML/en/kyum/*.png > >> %{_docdir}/HTML/en/kyum/index* > > Thsi should avoid the inclussion of the common part and so on. > > I have double checked it, and it seems, that no impoert file will > be gone lost. Please take a look at the output of: rpm -q kyum --qf '[%-11{filemodes:perms} %{filenames}\n]' Do you see what I pointed out in the review? And yes, I did not use rpm -qlv deliberately. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1305_FC4 loadavg: 2.33 2.49 1.74 From tcallawa at redhat.com Wed May 18 19:25:54 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 18 May 2005 14:25:54 -0500 Subject: Approval needed: cln, GiNaC In-Reply-To: <428B6185.6090005@ieee.org> References: <428B6185.6090005@ieee.org> Message-ID: <1116444354.3502.123.camel@localhost.localdomain> On Wed, 2005-05-18 at 10:38 -0500, Quentin Spencer wrote: > These two packages are in CVS and need final approval. The cln library > is used by GiNaC. The best way to test these two packages is to build > them both and then run ginsh from the GiNaC-utils package. > > cln (Class Library for Numbers): > A collection of C++ math classes and functions, which are designed for > memory and speed efficiency, and enable type safety and algebraic syntax. Review of cln: Rpmlint tests: cln-1.1.9-1.i386.rpm: E: cln no-signature cln-devel-1.1.9-1.i386.rpm: E: cln-devel requires-on-release cln 1.1.9-1 W: cln-devel no-major-in-name cln-devel E: cln-devel no-signature cln-1.1.9-1.src.rpm: E: cln no-signature All rpmlint errors can be ignored. Good: - Source matches upstream - License OK (GPL), COPYING included in main package - Libraries have ldconfig in %post/%postun - Meets PackageNamingGuidelines - Meets PackagingGuidelines Approved. > GiNaC > GiNaC (which stands for "GiNaC is Not a CAS (Computer Algebra System)") > is an open framework for symbolic computation within the C++ programming > language. This package includes ginsh ("GiNaC interactive shell") which > provides a simple and easy-to-use CAS-like interface to GiNaC for > non-programmers, and the tool "viewgar" which displays the contents of > GiNaC archives. Review of GiNaC: Rpmlint tests: GiNaC-1.3.1-1.i386.rpm: E: GiNaC no-signature GiNaC-devel-1.3.1-1.i386.rpm: E: GiNaC-devel requires-on-release GiNaC 1.3.1-1 W: GiNaC-devel no-major-in-name GiNaC-devel E: GiNaC-devel no-signature GiNaC-utils-1.3.1-1.i386.rpm: E: GiNaC-utils requires-on-release GiNaC 1.3.1-1 E: GiNaC-utils no-signature GiNaC-1.3.1-1.src.rpm: E: GiNaC no-signature All rpmlint errors can be ignored. Good: - License OK (GPL), COPYING included in main package - Libraries have ldconfig in %post/%postun - Scriptlets look sane - Meets PackageNamingGuidelines - Meets PackagingGuidelines Bad: - Source does NOT match upstream: 096d076e58103149f05da0a8ecd03d67 GiNaC-1.3.0.tar.bz2 (upstream) 46bb82c40f3e00f8e7fe03708dfec2c9 GiNaC-1.3.0.tar.gz (cvs) - Spec refers to .tar.gz which does not exist on upstream server, only .tar.bz2 exists. - Refuses to build properly without: BuildRequires: readline-devel, tetex-latex, tetex-dvips - Probably want to make sure that doxygen is present: BuildRequires: doxygen - GiNaC 1.3.0 doesn't actually build in rawhide. The good news is that GiNaC 1.3.1 does. You should move to that version. You'll need to fix these blockers before I can approve. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From qspencer at ieee.org Wed May 18 19:45:48 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Wed, 18 May 2005 14:45:48 -0500 Subject: Approval needed: cln, GiNaC In-Reply-To: <1116444354.3502.123.camel@localhost.localdomain> References: <428B6185.6090005@ieee.org> <1116444354.3502.123.camel@localhost.localdomain> Message-ID: <428B9B6C.8050009@ieee.org> Tom 'spot' Callaway wrote: >On Wed, 2005-05-18 at 10:38 -0500, Quentin Spencer wrote: > > >>These two packages are in CVS and need final approval. The cln library >>is used by GiNaC. The best way to test these two packages is to build >>them both and then run ginsh from the GiNaC-utils package. >> >> >... >Review of GiNaC: > >... > >Bad: > >- Source does NOT match upstream: >096d076e58103149f05da0a8ecd03d67 GiNaC-1.3.0.tar.bz2 (upstream) >46bb82c40f3e00f8e7fe03708dfec2c9 GiNaC-1.3.0.tar.gz (cvs) >- Spec refers to .tar.gz which does not exist on upstream server, >only .tar.bz2 exists. > > Fixed. I had originally adapted the spec file from one provided by the upstream maintainer, which continues to point to a file that doesn't exist his server! >- Refuses to build properly without: > BuildRequires: readline-devel, tetex-latex, tetex-dvips >- Probably want to make sure that doxygen is present: > BuildRequires: doxygen > > Added all of the above to BuildRequires. >- GiNaC 1.3.0 doesn't actually build in rawhide. The good news is that >GiNaC 1.3.1 does. You should move to that version. > > > Upgraded. >You'll need to fix these blockers before I can approve. > > All of these should now be fixed. regards, Quentin From tcallawa at redhat.com Wed May 18 20:41:54 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 18 May 2005 15:41:54 -0500 Subject: Approval needed: cln, GiNaC In-Reply-To: <428B9B6C.8050009@ieee.org> References: <428B6185.6090005@ieee.org> <1116444354.3502.123.camel@localhost.localdomain> <428B9B6C.8050009@ieee.org> Message-ID: <1116448914.3502.166.camel@localhost.localdomain> On Wed, 2005-05-18 at 14:45 -0500, Quentin Spencer wrote: > All of these should now be fixed. Review of GiNaC: Rpmlint tests: GiNaC-1.3.1-1.i386.rpm: E: GiNaC no-signature GiNaC-devel-1.3.1-1.i386.rpm: E: GiNaC-devel requires-on-release GiNaC 1.3.1-1 W: GiNaC-devel no-major-in-name GiNaC-devel E: GiNaC-devel no-signature GiNaC-utils-1.3.1-1.i386.rpm: E: GiNaC-utils requires-on-release GiNaC 1.3.1-1 E: GiNaC-utils no-signature GiNaC-1.3.1-1.src.rpm: E: GiNaC no-signature All rpmlint errors can be ignored. Good: - Source matches upstream - License OK (GPL), COPYING included in main package - Libraries have ldconfig in %post/%postun - Scriptlets look sane - Meets PackageNamingGuidelines - Meets PackagingGuidelines - No missing BuildRequires Approved. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Wed May 18 21:03:22 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 18 May 2005 16:03:22 -0500 Subject: request for review: rzip In-Reply-To: <20050517211417.GB13724@stingr.stingr.net> References: <20050517211417.GB13724@stingr.stingr.net> Message-ID: <1116450203.3502.179.camel@localhost.localdomain> On Wed, 2005-05-18 at 01:14 +0400, Paul P Komkoff Jr wrote: > Thanks sopwith sponsored my cvsextras membership, so I've uploaded > rzip to it. Any objections for it be present in extras for all > branches ? Review of rzip: Rpmlint tests: rzip-2.0-1.i386.rpm: E: rzip no-signature rzip-2.0-1.src.rpm: E: rzip no-signature All rpmlint errors can be ignored. Good: - Source matches upstream - License OK (GPL), COPYING in package - Meets PackageNamingGuidelines - Meets PackagingGuidelines - No missing BuildRequires Bad: - Grammar/Spelling in %description is a little off. Suggestion: rzip is a compression program, similar in functionality to gzip or bzip2, but able to take advantage of long distance redundancies in files, which can sometimes allow rzip to produce much better compression ratios than other programs. Fix the one blocker and I'll approve it. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From i at stingr.net Wed May 18 21:39:07 2005 From: i at stingr.net (Paul P Komkoff Jr) Date: Thu, 19 May 2005 01:39:07 +0400 Subject: request for review: rzip In-Reply-To: <1116450203.3502.179.camel@localhost.localdomain> References: <20050517211417.GB13724@stingr.stingr.net> <1116450203.3502.179.camel@localhost.localdomain> Message-ID: <20050518213907.GE13724@stingr.stingr.net> Replying to Tom 'spot' Callaway: > - Grammar/Spelling in %description is a little off. Suggestion: > > rzip is a compression program, similar in functionality to gzip or > bzip2, but able to take advantage of long distance redundancies in > files, which can sometimes allow rzip to produce much better > compression ratios than other programs. > > Fix the one blocker and I'll approve it. Done in local copy, also added %{?dist} to release, but: is it necessary to increase release number and make a new changelog entry in such cases - package exists only in devel, build never requested ? (I see cvs-import.sh explicitly tagged it, but...) -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From kevin-fedora-extras at scrye.com Wed May 18 22:19:28 2005 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Wed, 18 May 2005 16:19:28 -0600 Subject: make new-sources issue References: <20050518024856.580753481F3@ningauble.scrye.com> Message-ID: <20050518221931.BB6CB3610E4@ningauble.scrye.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Kevin" == Kevin Fenzi writes: Kevin> Greetings. Kevin> Xfce 4.2.2 was released today, so I want to get at least the Kevin> devel rpms all updated. I have updated all the specs, Kevin> regenerated some patches and confirmed everything builds and Kevin> seems to work on my i386 devel box. Kevin> I'm having a odd issue with the 'make new-sources' target Kevin> however. Here's what I see: Kevin> % make new-sources FILES="libxfce4util-4.2.2.tar.gz" Kevin> Checking : libxfce4util-4.2.2.tar.gz on Kevin> http://cvs.fedora.redhat.com/repo/extras/upload.cgi... ERROR: Kevin> could not check remote file status make: *** [new-sources] Kevin> Error 255 Kevin> I do have the ssl cert in ~/.fedora.cert I have made sure that Kevin> my ../../common/ area is all updated. Kevin> Any ideas what I am doing wrong? Thanks for any pointers. As predicted, I was doing something dumb. :) The problem is that the ../../common/ directory was up to date, but the ../common/ directory was not. Just in case anyone runs into something similar, it's a good idea to make sure any common directory in your tree is up to date before doing updates/checkins. kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 iD8DBQFCi79z3imCezTjY0ERAjAEAJ0ZrDSkaKHBPJifLqtItKnFqnt9uQCbBjdq 4bctmbvZM+p8Cxq7Dr/ro1w= =Nqld -----END PGP SIGNATURE----- From tcallawa at redhat.com Wed May 18 22:32:01 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 18 May 2005 17:32:01 -0500 Subject: request for review: rzip In-Reply-To: <20050518213907.GE13724@stingr.stingr.net> References: <20050517211417.GB13724@stingr.stingr.net> <1116450203.3502.179.camel@localhost.localdomain> <20050518213907.GE13724@stingr.stingr.net> Message-ID: <1116455521.3502.189.camel@localhost.localdomain> On Thu, 2005-05-19 at 01:39 +0400, Paul P Komkoff Jr wrote: > Replying to Tom 'spot' Callaway: > > - Grammar/Spelling in %description is a little off. Suggestion: > > > > rzip is a compression program, similar in functionality to gzip or > > bzip2, but able to take advantage of long distance redundancies in > > files, which can sometimes allow rzip to produce much better > > compression ratios than other programs. > > > > Fix the one blocker and I'll approve it. > > Done in local copy, also added %{?dist} to release, but: > is it necessary to increase release number and make a new changelog > entry in such cases - package exists only in devel, build never > requested ? If you don't need to, I won't make you. Lemme know when its fixed in cvs and I'll throw the approval over. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ivazquez at ivazquez.net Wed May 18 22:35:45 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 18 May 2005 18:35:45 -0400 Subject: Review/sponsor needed: sqlite2 In-Reply-To: <20050424114913.1c723503.bugs.michael@gmx.net> References: <1114241243.7784.17.camel@ignacio.ignacio.lan> <20050423212059.11deb9da.bugs.michael@gmx.net> <1114291713.7784.22.camel@ignacio.ignacio.lan> <20050424114913.1c723503.bugs.michael@gmx.net> Message-ID: <1116455745.7161.35.camel@ignacio.ignacio.lan> On Sun, 2005-04-24 at 11:49 +0200, Michael Schwendt wrote: > On Sat, 23 Apr 2005 17:28:33 -0400, Ignacio Vazquez-Abrams wrote: > > Shall I go ahead and import sqlite2 then? > > Fine with me in "devel" tree, but I don't maintain the three packages > mentioned above. So, to demonstrate that coordination among packagers > works, how about the package owners give their explicit "okay" at this > point? Okay, this has dragged out long enough. There has been *plenty* of time for the maintainers to speak up, and so far only one has, giving his assent. If no one can think of a reason to *not* import the sqlite2 package then I will proceed to do so this weekend. -- 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 kevin-fedora-extras at scrye.com Wed May 18 23:16:01 2005 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Wed, 18 May 2005 17:16:01 -0600 Subject: 'make build' and CVS oddness Message-ID: <20050518231604.859ED3610E4@ningauble.scrye.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It looks like sometimes when I run a 'make build' it works. Sometimes it doesn't. Working: make build For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs **** Access allowed: kevin is in ACL for common. Checking in tobuild; /cvs/extras/common/tobuild,v <-- tobuild new revision: 1.527; previous revision: 1.526 done Running syncmail... Mailing cvsextras at fedora.redhat.com... ...syncmail done. Not working: make build For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs (ie, prints the first more info message and returns) So, looking at the two package/common/ areas: File: tobuild Status: Up-to-date Working revision: 1.530 Repository revision: 1.530 /cvs/extras/common/tobuild,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) File: tobuild Status: Up-to-date Working revision: 1.530 Repository revision: 1.530 /cvs/extras/common/tobuild,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Both show up-to-date and the same version. However: tail -2 tobuild kevin rpms/xfce4-session/devel xfce4-session-4_2_2-1_fc4 devel kevin rpms/dbh/devel dbh-1_0_24-1_fc4 devel tail -2 tobuild kevin rpms/dbh/devel dbh-1_0_24-1_fc4 devel kevin rpms/gtk-xfce-engine/devel gtk-xfce-engine-2_2_7-1_fc4 devel Anyone have any ideas why this is occuring? kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 iD8DBQFCi8y03imCezTjY0ERAuUiAJ0cro2kzVT2E7ZqdxdXQADLlzkdYQCfe2pN Jx0pOsPsEWmrHn0kbjsOcPI= =ILVJ -----END PGP SIGNATURE----- From ivazquez at ivazquez.net Wed May 18 23:28:55 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 18 May 2005 19:28:55 -0400 Subject: 'make build' and CVS oddness In-Reply-To: <20050518231604.859ED3610E4@ningauble.scrye.com> References: <20050518231604.859ED3610E4@ningauble.scrye.com> Message-ID: <1116458935.7161.39.camel@ignacio.ignacio.lan> On Wed, 2005-05-18 at 17:16 -0600, Kevin Fenzi wrote: > Anyone have any ideas why this is occuring? Looks like tobuild isn't getting committed for some reason part of the time. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Wed May 18 23:46:38 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 19 May 2005 01:46:38 +0200 Subject: 'make build' and CVS oddness In-Reply-To: <20050518231604.859ED3610E4@ningauble.scrye.com> References: <20050518231604.859ED3610E4@ningauble.scrye.com> Message-ID: <20050519014638.5ee6b6c7.bugs.michael@gmx.net> On Wed, 18 May 2005 17:16:01 -0600, Kevin Fenzi wrote: > It looks like sometimes when I run a 'make build' it works. > Sometimes it doesn't. > Anyone have any ideas why this is occuring? Commit of modified tobuild file failed. If you run "make build" again, it should work. From ndbecker2 at gmail.com Thu May 19 02:01:33 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 18 May 2005 22:01:33 -0400 Subject: tetex-xcolor (required for tetex-beamer) conflicts Message-ID: Conflict between extras-development and development: *** file /usr/share/texmf/tex/latex/xcolor/xcolor.sty from install of tetex-xcolor-2.02-3.fc4 conflicts with file from package tetex-latex-3.0-4 From jpo at di.uminho.pt Thu May 19 02:53:24 2005 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Thu, 19 May 2005 03:53:24 +0100 (WEST) Subject: tetex-xcolor (required for tetex-beamer) conflicts In-Reply-To: References: Message-ID: <1123.213.13.91.140.1116471204.squirrel@webmail.lsd.di.uminho.pt> > Conflict between extras-development and development: > > *** file /usr/share/texmf/tex/latex/xcolor/xcolor.sty from install of > tetex-xcolor-2.02-3.fc4 conflicts with file from package tetex-latex-3.0-4 Please report this via bugzilla. Ir appears that xcolor, pgf, and beamer are tetex 3.0 core packages. Will look into it tomorrow. TIA, 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 mfleming at enlartenment.com Thu May 19 03:51:57 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Thu, 19 May 2005 13:51:57 +1000 Subject: Approval sought: mlmmj & mod_security. Message-ID: <20050519035157.GB6565@enlartenment.com> Hi, I've had mlmmj (ezmlm-like mailing list manager) in CVS for a few weeks now with some comments regarding the spec and structure, but no reports of failures / blockers etc. It is still pending an approval (prior to my requesting a build) I've also imported my mod_security package (http://www.modsecurity.org, an Apache security / semi-IDS system) into CVS as of this morning my time. rpmlint seems to find no problems and the package as it is appears to work OK - I'm using it myself. Both packages are also available from http://www.enlartenment.com/extras/ for convenience. Would someone like to give them a final review? While the standard tools seem to find no fatal errors I'm interested in any issues that may stop approval or result in build failures (on any arch). Cheers, Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From petersen at redhat.com Thu May 19 07:10:36 2005 From: petersen at redhat.com (Jens Petersen) Date: Thu, 19 May 2005 16:10:36 +0900 Subject: Approval needed: ghc Message-ID: <428C3BEC.1000902@redhat.com> * GHC, the Glasgow Haskell Compiler , is the standard compiler for the functional programming language Haskell. A seed package for the buildsystem for i386, ppc and x86_64 is at: http://people.redhat.com/petersen/extras/ghc-6.4-1.src.rpm (67MB) http://people.redhat.com/petersen/extras/ghc.spec and ghc standard source package is in extras cvs under ghc/FC-3 and ghc/devel already. Can someone please review the package for approval? :) Also I didn't get a clear final answer yet whether ghc can be built with compat-gcc-32 for devel/fc4? Otherwise it has to be FC-3 only for now. Thanks, Jens From i at stingr.net Thu May 19 07:12:04 2005 From: i at stingr.net (Paul P Komkoff Jr) Date: Thu, 19 May 2005 11:12:04 +0400 Subject: request for review: rzip In-Reply-To: <1116455521.3502.189.camel@localhost.localdomain> References: <20050517211417.GB13724@stingr.stingr.net> <1116450203.3502.179.camel@localhost.localdomain> <20050518213907.GE13724@stingr.stingr.net> <1116455521.3502.189.camel@localhost.localdomain> Message-ID: <20050519071204.GF13724@stingr.stingr.net> Replying to Tom 'spot' Callaway: > If you don't need to, I won't make you. Lemme know when its fixed in cvs > and I'll throw the approval over. done. -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From wtogami at redhat.com Thu May 19 07:20:59 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 18 May 2005 21:20:59 -1000 Subject: Approval needed: ghc In-Reply-To: <428C3BEC.1000902@redhat.com> References: <428C3BEC.1000902@redhat.com> Message-ID: <428C3E5B.4050804@redhat.com> Jens Petersen wrote: > * GHC, the Glasgow Haskell Compiler , is > the standard compiler for the functional programming language Haskell. > > A seed package for the buildsystem for i386, ppc and x86_64 is at: > > http://people.redhat.com/petersen/extras/ghc-6.4-1.src.rpm (67MB) > http://people.redhat.com/petersen/extras/ghc.spec > > and ghc standard source package is in extras cvs under ghc/FC-3 > and ghc/devel already. > > Can someone please review the package for approval? :) > > Also I didn't get a clear final answer yet whether ghc can be built > with compat-gcc-32 for devel/fc4? Otherwise it has to be FC-3 only > for now. > Good enough, and go ahead with compat-gcc-32. Don't forget to add the BuildRequires. I'll post the APPROVED message now. That'll disappear on the second build since ghc builds ghc? Warren Togami wtogami at redhat.com From petersen at redhat.com Thu May 19 07:42:28 2005 From: petersen at redhat.com (Jens Petersen) Date: Thu, 19 May 2005 16:42:28 +0900 Subject: Approval needed: ghc In-Reply-To: <428C3E5B.4050804@redhat.com> References: <428C3BEC.1000902@redhat.com> <428C3E5B.4050804@redhat.com> Message-ID: <428C4364.8010105@redhat.com> Warren Togami wrote: > Jens Petersen wrote: >> A seed package for the buildsystem for i386, ppc and x86_64 is at: >> http://people.redhat.com/petersen/extras/ghc-6.4-1.src.rpm (67MB) >> http://people.redhat.com/petersen/extras/ghc.spec >> and ghc standard source package is in extras cvs under ghc/FC-3 >> and ghc/devel already. > Good enough, and go ahead with compat-gcc-32. Don't forget to add the > BuildRequires. I'll post the APPROVED message now. Thanks. Should I import the above seed package into cvs too? :) > That'll disappear on the second build since ghc builds ghc? Actually no, since some of the low-level arch-dependent parts of ghc are written in C. (I'm not sure exactly how much work is involved but the next stable release ghc-6.4.1 will probably build ok with gcc4.) Jens From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu May 19 09:30:41 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 19 May 2005 11:30:41 +0200 Subject: Some xmms stuff Message-ID: <20050519113041.33cd172b@python2> Hi, Just to point out that : - I've requested ownership of the xmms, xmms-arts and xmms-skins components since no one stepped up since I've cleaned them up and imported them. I don't really mind, but if anyone badly wants ownership, be my guest :-) - I've imported a new xmms-flac package. See this bug for more details : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157796 I just realized that the source rpm I've imported on the devel branch didn't include the double free patch attached to that bug, I'll fix that right away. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.27_FC3 Load : 1.66 1.52 1.31 From qspencer at ieee.org Thu May 19 10:28:16 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 19 May 2005 05:28:16 -0500 Subject: Build problems on x86_64 Message-ID: <428C6A40.3060109@ieee.org> I'm having more problems building packages on x86_64. In this case the package cln had already build successfully on PPC, but about 2/3 of the way through the build on x86_64 I get the following error: g++ -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona -I../include -I../include -I./integer -I./base/digitseq -I./base/digit -Ibase -I./base -c ./integer/conv/cl_I_mul10plus.cc -fPIC -DPIC -o .libs/cl_I_mul10plus.o {standard input}: Assembler messages: {standard input}:154: Error: suffix or operands invalid for `mul' I've never seen an error like this before. Is there any possible explanation other than a bug in gcc? -Quentin From petersen at redhat.com Thu May 19 10:34:35 2005 From: petersen at redhat.com (Jens Petersen) Date: Thu, 19 May 2005 19:34:35 +0900 Subject: Approval needed again: SCIM In-Reply-To: <4288869E.7060306@mbm.nifty.com> References: <4288869E.7060306@mbm.nifty.com> Message-ID: <428C6BBB.80600@redhat.com> Ryo Dairiki wrote: > http://briefcase.yahoo.co.jp/bc/ryo_dairiki/ Ok, I imported the final version above of the package that incorporates all of Konstantin's and my changes into extras cvs. :) Thanks for your work on this, Dairiki san. The package is approved. Jens From rc040203 at freenet.de Thu May 19 10:39:21 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 19 May 2005 12:39:21 +0200 Subject: Build problems on x86_64 In-Reply-To: <428C6A40.3060109@ieee.org> References: <428C6A40.3060109@ieee.org> Message-ID: <1116499162.27813.7.camel@mccallum.corsepiu.local> On Thu, 2005-05-19 at 05:28 -0500, Quentin Spencer wrote: > I'm having more problems building packages on x86_64. In this case the > package cln had already build successfully on PPC, but about 2/3 of the > way through the build on x86_64 I get the following error: > > g++ -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 > -mtune=nocona -I../include -I../include -I./integer -I./base/digitseq > -I./base/digit -Ibase -I./base -c ./integer/conv/cl_I_mul10plus.cc > -fPIC -DPIC -o .libs/cl_I_mul10plus.o > {standard input}: Assembler messages: > {standard input}:154: Error: suffix or operands invalid for `mul' > > I've never seen an error like this before. This is the assembler ("as") complaining about the code being passed to it containing invalid assembly code. > Is there any possible > explanation other than a bug in gcc? Yes, broken inline asm, bug in as, bug in g++, bug in libstdc++ (templates can contain inline asm), invalid source code, etc. You will want to have a look into the preprocessed sources (gcc -save-temps) and check for the origin of this complaint. Ralf From petersen at redhat.com Thu May 19 10:42:18 2005 From: petersen at redhat.com (Jens Petersen) Date: Thu, 19 May 2005 19:42:18 +0900 Subject: Approval needed: ghc In-Reply-To: <428C4364.8010105@redhat.com> References: <428C3BEC.1000902@redhat.com> <428C3E5B.4050804@redhat.com> <428C4364.8010105@redhat.com> Message-ID: <428C6D8A.20503@redhat.com> Jens Petersen wrote: > Warren Togami wrote: > >> Jens Petersen wrote: >>> A seed package for the buildsystem for i386, ppc and x86_64 is at: >>> http://people.redhat.com/petersen/extras/ghc-6.4-1.src.rpm (67MB) > Should I import the above seed package into cvs too? :) Or is it better to avoid importing the 67MB into the repository, just building the seed packages by hand in the buildroots and then proceeding to building the real source package with the seed packages? Jens From qspencer at ieee.org Thu May 19 10:58:01 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 19 May 2005 05:58:01 -0500 Subject: Build problems on x86_64 In-Reply-To: <1116499162.27813.7.camel@mccallum.corsepiu.local> References: <428C6A40.3060109@ieee.org> <1116499162.27813.7.camel@mccallum.corsepiu.local> Message-ID: <428C7139.6060102@ieee.org> Ralf Corsepius wrote: >On Thu, 2005-05-19 at 05:28 -0500, Quentin Spencer wrote: > > >> Is there any possible >>explanation other than a bug in gcc? >> >> >Yes, broken inline asm, bug in as, bug in g++, bug in libstdc++ >(templates can contain inline asm), invalid source code, etc. > > Shouldn't g++ catch invalid source code? If it builds on another arch (completed on ppc, and builds on my i386), doesn't that exclude invalid source code as a possible cause here? >You will want to have a look into the preprocessed sources >(gcc -save-temps) and check for the origin of this complaint. > > Since I don't have access to x86_64 hardware, I really don't know how to proceed. Before filing a bug against g++, I would like to isolate the problem a little more. Suggestions? -Quentin From ivazquez at ivazquez.net Thu May 19 11:07:52 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 19 May 2005 07:07:52 -0400 Subject: Build problems on x86_64 In-Reply-To: <428C7139.6060102@ieee.org> References: <428C6A40.3060109@ieee.org> <1116499162.27813.7.camel@mccallum.corsepiu.local> <428C7139.6060102@ieee.org> Message-ID: <1116500872.7161.60.camel@ignacio.ignacio.lan> On Thu, 2005-05-19 at 05:58 -0500, Quentin Spencer wrote: > Ralf Corsepius wrote: > > >On Thu, 2005-05-19 at 05:28 -0500, Quentin Spencer wrote: > > > > > >> Is there any possible > >>explanation other than a bug in gcc? > >> > >> > >Yes, broken inline asm, bug in as, bug in g++, bug in libstdc++ > >(templates can contain inline asm), invalid source code, etc. > > > > > Shouldn't g++ catch invalid source code? If it builds on another arch > (completed on ppc, and builds on my i386), doesn't that exclude invalid > source code as a possible cause here? Yes (but no) and no. g++ can catch invalid C++ code, but it's not responsible for converting the C++ into native code. It converts it into assembly via libstdc++, then gas converts that into native code. Also, GCC makes architecture- specific native code, and different architectures have different libraries used to create native code. Some of the different architecture's libraries may be fine, others not. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Christian.Iseli at licr.org Thu May 19 11:54:14 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 19 May 2005 13:54:14 +0200 Subject: Build problems on x86_64 In-Reply-To: Your message of "Thu, 19 May 2005 05:28:16 CDT." <428C6A40.3060109@ieee.org> Message-ID: <200505191154.j4JBsEnm005402@localhost.localdomain> Hi Quentin, qspencer at ieee.org said: > Is there any possible explanation other than a bug in gcc? There might be a bug in the source code, providing improper inline assembly for an x86_64 machine. I grabbed the cln-1.1.9-1.src.rpm file and tried to build it on a nocona machine I have here, however it dies in a different way: g++ -O2 -Wall -I../include -I../include -I./float/lfloat -I./float -I./base/digitseq -I./base/digit -Ibase -I./base -I./float/lfloat/elem -I./integer -c ./float/lfloat/misc/cl_LF_decode.cc -fPIC -DPIC -o .libs/cl_LF_decode.o In file included from float/lfloat/cl_LF_impl.h:10, from float/lfloat/misc/cl_LF_decode.cc:13: base/digitseq/cl_DS.h:7:26: cl_gmpconfig.h: No such file or directory In file included from base/digitseq/cl_DS.h:9, from float/lfloat/cl_LF_impl.h:10, from float/lfloat/misc/cl_LF_decode.cc:13: base/digitseq/cl_DS_endian.h:6:26: cl_gmpconfig.h: No such file or directory Maybe this is a red herring, because my nocona runs RH-AS3... Or maybe a BuildReq is missing... I'd try passing the NO_ASM flag to the compiler, to disable all inline assembly in cln, and see if that builds. If yes, then the problem likely is in the cln source code. If not, you might have found a bug in g++/libstdc++. Cheers, Christian From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu May 19 11:58:11 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 19 May 2005 13:58:11 +0200 Subject: Review/Approval needed: mfstools In-Reply-To: <1116437306.3502.83.camel@localhost.localdomain> References: <1116437306.3502.83.camel@localhost.localdomain> Message-ID: <20050519135811.7abbca35@python2> Tom 'spot' Callaway wrote : > This package is in CVS and needs review and approval. Its quite small. > > MFS Tools is a set of utilities for TiVo drive upgrades. This includes > MFS specific backup and restore, as well as MFS volume expansion and > shrinking. > > No libraries, one binary, and a few symlinks. :) > > Please review, thanks. Eek! Simple points : - Missing zlib-devel, which doesn't bother configure but makes the build fail miserably :-/ - You mix spaces and tabs in your spec file headers -> Readability issues when using 4 spaces vs. 8 for tabs or vice versa. - The release fields seems weird, why two 1s in different places? Now the nasty one : The package contains files with names way too generic! And the /usr/share/doc/howto.html file should not be there, copy it to the pwd and include it as %doc instead of installing it to _docdir. /usr/bin/backup /usr/bin/restore These files definitely need to have their name changed... not sure what it'll break, though. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.27_FC3 Load : 0.50 0.48 0.38 From oliver at linux-kernel.at Thu May 19 12:36:07 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 19 May 2005 14:36:07 +0200 Subject: New package: libstatgrab Message-ID: <200505191235.j4JCZ7Fv016399@mail.linux-kernel.at> Hi! I'd like to get approval for the following package: libstatgrab. src.rpm as well as the specfile can be retrieved from/reviewed at: http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPRO VAL/libstatgrab Package description says the following (for those who are to lazy to follow the above link): Libstatgrab is a library that provides cross platform access to statistics about the system on which it's run. It's written in C and presents a selection of useful interfaces which can be used to access key system statistics. The current list of statistics includes CPU usage, memory utilisation, disk usage, process counts, network traffic, disk I/O, and more. I do also have another package in my pipe (bwm-ng) which uses libstatgrab. Best, Oliver PS: BuildRequires might be cleaned!? - Oliver Falk UNIX/Linux Systems Administrator Autonomy Information Engineer Die Information in dieser Nachricht ist vertraulich und ausschlie?lich f?r den Adressaten bestimmt. Der Empf?nger dieser Nachricht, der nicht der Adressat, einer seiner Mitarbeiter oder sein Empfangsbevollm?chtigter ist, wird hiermit davon in Kenntnis gesetzt, dass er deren Inhalt nicht verwenden, weitergeben oder reproduzieren darf. Sollten Sie diese Nachricht irrt?mlich erhalten haben, benachrichtigen Sie uns bitte unverz?glich per Telefon und retournieren Sie uns die Nachricht per E-Mail/Fax. The information contained in this e-mail is privileged and confidential and is for the exclusive use of the addressee. The person who receives this e-mail and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof. If you have received this communication by mistake, please let us know by telephone without delay and send it back to us by e-mail/fax.'fedora-extras-list at redhat.com.' From mricon at gmail.com Thu May 19 12:43:32 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Thu, 19 May 2005 08:43:32 -0400 Subject: Approval needed again: SCIM In-Reply-To: <428C6BBB.80600@redhat.com> References: <4288869E.7060306@mbm.nifty.com> <428C6BBB.80600@redhat.com> Message-ID: On 5/19/05, Jens Petersen wrote: > Ryo Dairiki wrote: > > http://briefcase.yahoo.co.jp/bc/ryo_dairiki/ > > Ok, I imported the final version above of the package that > incorporates all of Konstantin's and my changes into extras > cvs. :) > > Thanks for your work on this, Dairiki san. The package > is approved. What about tables? SCIM is useless without tables. -- Konstantin Ryabitsev Zlotniks, INC "? ????? ???? ?? ??? ???? ?????????????." --???? From oliver at linux-kernel.at Thu May 19 12:49:57 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 19 May 2005 14:49:57 +0200 Subject: New package: syck In-Reply-To: Message-ID: <200505191248.j4JCmv38023753@mail.linux-kernel.at> Hi! I'd like to get approval for the following package: syck. src.rpm as well as the specfile can be retrieved from/reviewed at: http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPRO VAL/syck Package description says the following (for those who are to lazy to follow the above link): Syck is an extension for reading and writing YAML swiftly in popular scripting languages. As Syck loads the YAML, it stores the data directly in your language's symbol table. This means speed. This means power. This means Do not disturb Syck because it is so focused on the task at hand that it will slay you mortally if you get in its way. I have another package in my pipe that uses syck (at least for compilation): perl-YAML-Parser-Syck. Best, Oliver - Oliver Falk UNIX/Linux Systems Administrator Autonomy Information Engineer Die Information in dieser Nachricht ist vertraulich und ausschlie?lich f?r den Adressaten bestimmt. Der Empf?nger dieser Nachricht, der nicht der Adressat, einer seiner Mitarbeiter oder sein Empfangsbevollm?chtigter ist, wird hiermit davon in Kenntnis gesetzt, dass er deren Inhalt nicht verwenden, weitergeben oder reproduzieren darf. Sollten Sie diese Nachricht irrt?mlich erhalten haben, benachrichtigen Sie uns bitte unverz?glich per Telefon und retournieren Sie uns die Nachricht per E-Mail/Fax. The information contained in this e-mail is privileged and confidential and is for the exclusive use of the addressee. The person who receives this e-mail and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof. If you have received this communication by mistake, please let us know by telephone without delay and send it back to us by e-mail/fax. From oliver at linux-kernel.at Thu May 19 12:57:23 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 19 May 2005 14:57:23 +0200 Subject: New package: rblcheck In-Reply-To: Message-ID: <200505191256.j4JCuOLk026407@mail.linux-kernel.at> Hi! I'd like to get approval for the following package: rblcheck. src.rpm as well as the specfile can be retrieved from/reviewed at: http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPRO VAL/rblcheck Package description says the following (for those who are to lazy to follow the above link): rblcheck is a very basic interface to RBL-style DNS listings such as those operated by the MAPS (http://www.maps.org/) and ORBL (http://www.orbl.org/) projects. Yes, it's a very simple/basic package, but it's a fine tool to have at hand if you are a mailserver administrator and need to check if some IP is blacklisted... Best, Oliver - Oliver Falk UNIX/Linux Systems Administrator Autonomy Information Engineer Die Information in dieser Nachricht ist vertraulich und ausschlie?lich f?r den Adressaten bestimmt. Der Empf?nger dieser Nachricht, der nicht der Adressat, einer seiner Mitarbeiter oder sein Empfangsbevollm?chtigter ist, wird hiermit davon in Kenntnis gesetzt, dass er deren Inhalt nicht verwenden, weitergeben oder reproduzieren darf. Sollten Sie diese Nachricht irrt?mlich erhalten haben, benachrichtigen Sie uns bitte unverz?glich per Telefon und retournieren Sie uns die Nachricht per E-Mail/Fax. The information contained in this e-mail is privileged and confidential and is for the exclusive use of the addressee. The person who receives this e-mail and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof. If you have received this communication by mistake, please let us know by telephone without delay and send it back to us by e-mail/fax. From paul at city-fan.org Thu May 19 13:03:29 2005 From: paul at city-fan.org (Paul Howarth) Date: Thu, 19 May 2005 14:03:29 +0100 Subject: New package: rblcheck In-Reply-To: <200505191256.j4JCuOLk026407@mail.linux-kernel.at> References: <200505191256.j4JCuOLk026407@mail.linux-kernel.at> Message-ID: <428C8EA1.2010704@city-fan.org> Oliver Falk wrote: > Hi! > > I'd like to get approval for the following package: rblcheck. > > src.rpm as well as the specfile can be retrieved from/reviewed at: > http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPRO > VAL/rblcheck > > Package description says the following (for those who are to lazy to follow > the above link): > > rblcheck is a very basic interface to RBL-style DNS listings such as those > operated by the MAPS (http://www.maps.org/) and ORBL (http://www.orbl.org/) > projects. > > Yes, it's a very simple/basic package, but it's a fine tool to have at hand > if you are a mailserver administrator and need to check if some IP is > blacklisted... I have my own package of rblcheck, which incorporates a few useful patches. One of the patches adds my own local lists as default lists to check, so you'll want to edit those out, but the rest may be useful to you: http://www.city-fan.org/ftp/contrib/mail/rblcheck-1.5-14.src.rpm Paul. From oliver at linux-kernel.at Thu May 19 13:09:29 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 19 May 2005 15:09:29 +0200 Subject: New package: rblcheck In-Reply-To: <428C8EA1.2010704@city-fan.org> Message-ID: <200505191308.j4JD8Uhd031620@mail.linux-kernel.at> Hi Paul! [ ... ] > > rblcheck is a very basic interface to RBL-style DNS > > listings such as those operated by the MAPS > > (http://www.maps.org/) and ORBL (http://www.orbl.org/) projects. [ ... ] > > I have my own package of rblcheck, which incorporates a few > useful patches. One of the patches adds my own local lists as > default lists to check, so you'll want to edit those out, but > the rest may be useful to you: > > http://www.city-fan.org/ftp/contrib/mail/rblcheck-1.5-14.src.rpm Thanks, I'll have a look at it and integrate usefull changes! Best, Oliver From oliver at linux-kernel.at Thu May 19 13:26:18 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 19 May 2005 15:26:18 +0200 Subject: New package: rblcheck In-Reply-To: <428C8EA1.2010704@city-fan.org> Message-ID: <200505191325.j4JDPJSo003334@mail.linux-kernel.at> Hi Paul! > I have my own package of rblcheck, which incorporates a few > useful patches. One of the patches adds my own local lists as > default lists to check, so you'll want to edit those out, but > the rest may be useful to you: > > http://www.city-fan.org/ftp/contrib/mail/rblcheck-1.5-14.src.rpm Do you have an origin for the patches? Or are they made by you? If so, can you provide me with URLs where I can point the Patch-tags in the specfile to!? Best, Oliver From paul at city-fan.org Thu May 19 13:42:54 2005 From: paul at city-fan.org (Paul Howarth) Date: Thu, 19 May 2005 14:42:54 +0100 Subject: New package: rblcheck In-Reply-To: <200505191325.j4JDPJSo003334@mail.linux-kernel.at> References: <200505191325.j4JDPJSo003334@mail.linux-kernel.at> Message-ID: <428C97DE.6000804@city-fan.org> Oliver Falk wrote: > Hi Paul! > > >>I have my own package of rblcheck, which incorporates a few >>useful patches. One of the patches adds my own local lists as >>default lists to check, so you'll want to edit those out, but >>the rest may be useful to you: >> >>http://www.city-fan.org/ftp/contrib/mail/rblcheck-1.5-14.src.rpm > > > Do you have an origin for the patches? Or are they made by you? If so, can > you provide me with URLs where I can point the Patch-tags in the specfile > to!? No specific URLs I'm afraid. rblcheck-zones.patch: I made this myself and it's responsible for most of the changelog entries, as I add and remove lists as and when they appear and disappear. I changed the text "RBL filtered by" to "listed by" because (a) it's more accurate, and (b) "RBL" is a trademark of MAPS LLC. rblcheck-names.patch Comes from a post to the rblcheck-users mailing list. See: http://sourceforge.net/mailarchive/forum.php?thread_id=1371771&forum_id=4256 rblcheck-txt.patch I made this to fix the broken code for looking up TXT records, and the code is borrowed from Ian Gulliver's "firedns" library (GPL), which can be found at: http://firestuff.org/ Paul. From tcallawa at redhat.com Thu May 19 14:01:40 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 19 May 2005 09:01:40 -0500 Subject: request for review: rzip In-Reply-To: <20050519071204.GF13724@stingr.stingr.net> References: <20050517211417.GB13724@stingr.stingr.net> <1116450203.3502.179.camel@localhost.localdomain> <20050518213907.GE13724@stingr.stingr.net> <1116455521.3502.189.camel@localhost.localdomain> <20050519071204.GF13724@stingr.stingr.net> Message-ID: <1116511300.3502.213.camel@localhost.localdomain> On Thu, 2005-05-19 at 11:12 +0400, Paul P Komkoff Jr wrote: > Replying to Tom 'spot' Callaway: > > If you don't need to, I won't make you. Lemme know when its fixed in cvs > > and I'll throw the approval over. > > done. And its approved. :) ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Thu May 19 14:30:14 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 19 May 2005 09:30:14 -0500 Subject: Review/Approval needed: mfstools In-Reply-To: <20050519135811.7abbca35@python2> References: <1116437306.3502.83.camel@localhost.localdomain> <20050519135811.7abbca35@python2> Message-ID: <1116513014.3502.223.camel@localhost.localdomain> On Thu, 2005-05-19 at 13:58 +0200, Matthias Saou wrote: > Tom 'spot' Callaway wrote : > > > This package is in CVS and needs review and approval. Its quite small. > > > > MFS Tools is a set of utilities for TiVo drive upgrades. This includes > > MFS specific backup and restore, as well as MFS volume expansion and > > shrinking. > > > > No libraries, one binary, and a few symlinks. :) > > > > Please review, thanks. > > Eek! > > Simple points : > - Missing zlib-devel, which doesn't bother configure but makes the build > fail miserably :-/ Fixed. > - You mix spaces and tabs in your spec file headers -> Readability issues > when using 4 spaces vs. 8 for tabs or vice versa. Yeah, dunno how I did that. :/ Fixed. > - The release fields seems weird, why two 1s in different places? OK, so here's the logic. First 1 marks it as a "post" release from 2.0. The middle is the snapshot revision, and the last digit is the build number. In these fixes, I'll increment the last digit. > Now the nasty one : The package contains files with names way too generic! > And the /usr/share/doc/howto.html file should not be there, copy it to the > pwd and include it as %doc instead of installing it to _docdir. > > /usr/bin/backup > /usr/bin/restore > > These files definitely need to have their name changed... not sure what > it'll break, though. Well, the only thing its likely to break is the documentation. Those are symlinks to mfstool. (/usr/bin/backup == /usr/bin/mfstool backup) And even then, the docs seem to refer to /usr/bin/mfstool backup instead. Renamed in the spec, should be fixed. Changes commited to CVS, take two? :) ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From oliver at linux-kernel.at Thu May 19 14:32:29 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 19 May 2005 16:32:29 +0200 Subject: New package: rblcheck In-Reply-To: <428C97DE.6000804@city-fan.org> Message-ID: <200505191431.j4JEVURv024943@mail.linux-kernel.at> Hi Paul! [ ... ] > No specific URLs I'm afraid. > > rblcheck-zones.patch: > I made this myself and it's responsible for most of the > changelog entries, as I add and remove lists as and when they > appear and disappear. I changed the text "RBL filtered by" to > "listed by" because > (a) it's more accurate, and (b) "RBL" is a trademark of MAPS LLC. OK. This moved to rblcheck-texttweak.patch and for the default lists I created a %{_sysconfdir}/rblcheckrc. This is - of course - easier to maintain than patchin' around. :-) > rblcheck-names.patch > Comes from a post to the rblcheck-users mailing list. See: > http://sourceforge.net/mailarchive/forum.php?thread_id=1371771&forum_id=4256 OK, added a comment to the specfile. > rblcheck-txt.patch > I made this to fix the broken code for looking up TXT > records, and the code is borrowed from Ian Gulliver's > "firedns" library (GPL), which can be found at: http://firestuff.org/ For this too, added a comment. So running rbl will check %{_sysconfdir}/rblcheckrc (where the default lists you patched in) reside now and afterwards read in ~/.rblcheckrc (as usual). So, Paul, I would be pleased to see you updating the rblcheckrc if I get an approval for the rblcheck package :-) And for the folks who had a look at the package allready/will have a look at the package to approve it. Please note, that I just updated it at: http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPRO VAL/rblcheck Best, Oliver From paul at city-fan.org Thu May 19 15:00:59 2005 From: paul at city-fan.org (Paul Howarth) Date: Thu, 19 May 2005 16:00:59 +0100 Subject: New package: rblcheck In-Reply-To: <200505191431.j4JEVURv024943@mail.linux-kernel.at> References: <200505191431.j4JEVURv024943@mail.linux-kernel.at> Message-ID: <428CAA2B.7010605@city-fan.org> Oliver Falk wrote: >>rblcheck-zones.patch: >>I made this myself and it's responsible for most of the >>changelog entries, as I add and remove lists as and when they >>appear and disappear. I changed the text "RBL filtered by" to >>"listed by" because >>(a) it's more accurate, and (b) "RBL" is a trademark of MAPS LLC. > > > OK. This moved to rblcheck-texttweak.patch and for the default lists I > created a %{_sysconfdir}/rblcheckrc. This is - of course - easier to > maintain than patchin' around. :-) Of course, it would be still nicer if rblcheck read %{_sysconfdir}/rblcheckrc and ~/.rblcheckrc itself rather than using a wrapper script, but that would a fair bit of work. > So running rbl will check %{_sysconfdir}/rblcheckrc (where the > default lists you patched in) reside now and afterwards read in > ~/.rblcheckrc (as usual). The monkeys.com lists are all defunct. Ron has stopped maintaining them. I believe the same applies to dev.null.dk. And *.dorkslayers.com. Maybe some of the others too; I'd check them out. Don't just check that the DNS servers return results; check out the websites. These lists come and go quite regularly. The following lists are specified multiple times: -s bl.spamcop.net -s dnsbl.njabl.org -s list.dsbl.org -s multihop.dsbl.org -s opm.blitzed.org -s relays.ordb.org -s unconfirmed.dsbl.org Please don't include my private lists - it might cripple my DSL link: -s dialups.city-fan.org -s relays.city-fan.org -s spammers.city-fan.org Should be added: -s xbl.spamhaus.org > So, Paul, I would be pleased to see you updating the rblcheckrc if I get an > approval for the rblcheck package :-) I'll bear that in mind :-) > And for the folks who had a look at the package allready/will have a look at > the package to approve it. Please note, that I just updated it at: > http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPROVAL/rblcheck More notes: Description: - URL for MAPS should be http://www.mail-abuse.com/ not http://www.maps.org/ - ORBL appears to be defunct. BuildRequires: - docbook-utils is needed for the docs directory. Files: - INSTALL file is generic and not of any use to an end user. Paul. From kaboom at oobleck.net Thu May 19 16:09:01 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 19 May 2005 12:09:01 -0400 (EDT) Subject: kismet and svn builds? Message-ID: I was making a package of kismet for work, and had some questions regarding that: 1. Is anyone else interested in having it in FE? 2. I only have ipw2100 and ipw2200 cards in my laptops. The 2100 should work with kismet on current FC kernels, and the 2200 will work with the kernel coming through the build system (BZ #158073). Do any other wireless drivers in the FC kernel tree support rfmon? 3. kismet support for ipw2200 cards requires a build from the kismet development svn tree. How does one package a cvs / svn / etc. checkout for FE? Or is the answer just "don't do that" :-) FWIW, my current package is at . What I did for it was check out the devel tree from svn, tar it up, and put the svn release in the version field. Not sure if there's a better / more appropriate way though, such as doing a diff between the last release, current devel snapshot, and having Source0 be the last release and Patch0 be the diff to bring to devel. Thoughts? later, chris From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu May 19 16:22:03 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 19 May 2005 18:22:03 +0200 Subject: Review/Approval needed: mfstools In-Reply-To: <1116513014.3502.223.camel@localhost.localdomain> References: <1116437306.3502.83.camel@localhost.localdomain> <20050519135811.7abbca35@python2> <1116513014.3502.223.camel@localhost.localdomain> Message-ID: <20050519182203.67a8adaf@python2> Tom 'spot' Callaway wrote : > > /usr/bin/backup > > /usr/bin/restore > > > > These files definitely need to have their name changed... not sure what > > it'll break, though. > > Well, the only thing its likely to break is the documentation. Those are > symlinks to mfstool. (/usr/bin/backup == /usr/bin/mfstool backup) > > And even then, the docs seem to refer to /usr/bin/mfstool backup > instead. Renamed in the spec, should be fixed. > > Changes commited to CVS, take two? :) Weird, with rpm -qplv I didn't see any symlinks in the package, and all files in _bindir seemed to be real binaries to me... I'll have another look now ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.27_FC3 Load : 0.23 0.38 0.40 From tcallawa at redhat.com Thu May 19 16:52:26 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 19 May 2005 11:52:26 -0500 Subject: kismet and svn builds? In-Reply-To: References: Message-ID: <1116521546.3502.251.camel@localhost.localdomain> On Thu, 2005-05-19 at 12:09 -0400, Chris Ricker wrote: > 3. kismet support for ipw2200 cards requires a build from the kismet > development svn tree. How does one package a cvs / svn / etc. checkout > for FE? Or is the answer just "don't do that" :-) We're still trying to figure that out. Right now, I think this is the wording I've got so far. Please point out flaws in this. Non-numeric versioned "pre-release" and "post-release" packages can be problematic so they must be treated with care. These are cases where the upstream "pre-release" version has letters rather than simple numbers in their version. Often they have tags like alpha, beta, cvs, svn, rc, or letters like a and b denoting that it is a version before the "final" number. Unfortunately, we cannot simply put these letters into the version tag, so we'll use the Release field for this. Release Tag for Pre-Release Packages: 0.%{X}.%{alphatag} Release Tag for Post-Release Packages: %{LastMajorRelease}.%{X}.%{alphatag} Where %{LastMajorRelease} is the build number from any previous "stable" package builds (if none, use 1), %{X} is the release number increment, and %{alphatag} is the string that came from the version. In this case, the period '.' should be used as the delimiter between the release number increment, and the non-numeric version string. No other extra characters should appear in the Release field. This is to prevent Release values such as "3jpp_2fc.42-spotwashere". When using CVS/SVN checkouts, use an alphatag of the format: YYYYMMDDcvs Where YYYY is the digits for the year, MM is the zero-padded digits for the month, DD is the zero-padded digits for the day, and "cvs" is the type of checkout. The date in reference is the date that the checkout was taken. In the post-release case, Example (pre-release): mozilla-1.4a.tar.gz (this is a pre-release, version 1.4a of mozilla) mozilla-1.4.tar.gz (this is what the 1.4 release will actually look like) mozilla-1.4-0.1.a (so, this is the acceptable Fedora %{name}-%{version}-%{release}) mozilla-1.4-1 (and this is what the 1.4 release Fedora %{name}-%{version}-%{release} should be) Example (pre-release svn): kismet-0.1.20040110svn (this is a pre-release, svn checkout of kismet) kismet-0.2.20040110svn (this is a bugfix to the previous package) kismet-0.3.20040204svn (this is a new svn checkout, note the increment of %{X}) kismet-1.0-1 (this is the formal release of kismet 1.0) Example (post-release cvs): kismet-1.0-1 (this is the formal release of kismet 1.0) kismet-1.0-2 (this is a bugfix build to the 1.0 release) kismet-1.0-2.1.20050515cvs (move to a post-release cvs checkout) kismet-1.0-2.2.20050515cvs (bugfix to the post-release cvs checkout) kismet-1.0-2.3.20050517cvs (new cvs checkout, note the increment of %{X}) ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From bugs.michael at gmx.net Thu May 19 17:04:04 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 19 May 2005 19:04:04 +0200 Subject: kismet and svn builds? In-Reply-To: References: Message-ID: <20050519190404.2cfda044.bugs.michael@gmx.net> On Thu, 19 May 2005 12:09:01 -0400 (EDT), Chris Ricker wrote: > I was making a package of kismet for work, and had some questions > regarding that: > > 1. Is anyone else interested in having it in FE? Andreas Bierfert (andreas.bierfert AT lowlatency.de) and Ian Alexander (ialexander44 AT gmail.com) have shown interest a month ago. From fedora at camperquake.de Thu May 19 17:08:59 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 19 May 2005 19:08:59 +0200 Subject: kismet and svn builds? In-Reply-To: References: Message-ID: <20050519190859.11aee115@nausicaa.camperquake.de> Hi. Chris Ricker wrote: > 1. Is anyone else interested in having it in FE? Well, better than compiling my own :) Dag Wieers has a package which you may want to look at. From enrico.scholz at informatik.tu-chemnitz.de Thu May 19 17:25:02 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 19 May 2005 19:25:02 +0200 Subject: RFE: dietlibc review Message-ID: <87oeb7i0wh.fsf@kosh.bigo.ensc.de> Hello, it would be nice when somebody could review the devel/ branch of dietlibc in CVS. It blocks other packages so it would be nice to have it in the repo. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From skvidal at phy.duke.edu Thu May 19 18:09:45 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 19 May 2005 14:09:45 -0400 Subject: RFE: dietlibc review In-Reply-To: <87oeb7i0wh.fsf@kosh.bigo.ensc.de> References: <87oeb7i0wh.fsf@kosh.bigo.ensc.de> Message-ID: <1116526185.13979.27.camel@cutter> On Thu, 2005-05-19 at 19:25 +0200, Enrico Scholz wrote: > Hello, > > it would be nice when somebody could review the devel/ branch of dietlibc > in CVS. It blocks other packages so it would be nice to have it in the > repo. > what does it block? -sv From kaboom at oobleck.net Thu May 19 18:40:35 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 19 May 2005 14:40:35 -0400 (EDT) Subject: kismet and svn builds? In-Reply-To: <1116521546.3502.251.camel@localhost.localdomain> References: <1116521546.3502.251.camel@localhost.localdomain> Message-ID: On Thu, 19 May 2005, Tom 'spot' Callaway wrote: > On Thu, 2005-05-19 at 12:09 -0400, Chris Ricker wrote: > > > 3. kismet support for ipw2200 cards requires a build from the kismet > > development svn tree. How does one package a cvs / svn / etc. checkout > > for FE? Or is the answer just "don't do that" :-) > > We're still trying to figure that out. > > Right now, I think this is the wording I've got so far. Please point out > flaws in this. Thanks, that helped To complicate things, kismet started out with the more-or-less traditional major #.minor #.tiny # versioning scheme. After it hit 3.1.0, the author switched to a year-month-release# scheme (which, just to be extra-confusing, he describes in the documentation as a month-year-release# scheme ;-). So, releases now look like 2005-01-R1 2005-04-R1 Based on that, I thought the %{version} for the latest stable release should be 0.2005.04.1 (0 just so I don't need an Epoch if the naming scheme ever goes back) So, I'd do something like kismet-0.2005.04.1-1 for the initial package of the release code, then kismet-0.2005.04.1-2.1.20050518svn kismet-0.2005.04.1-2.2.20050519svn for subsequent builds from the development checkout. One thing that's not clear: when would I ever change the first field of %{release} once going to the post-release SVN checkout format? Meaning, after I've done: kismet-0.2005.04.1-2.1.20050518svn kismet-0.2005.04.1-2.2.20050519svn when would I ever do kismet-0.2005.04.1-3.whatever ? It kinda seems like that first field in %{release} is superfluous? later, chris From tibbs at math.uh.edu Thu May 19 18:49:39 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 19 May 2005 13:49:39 -0500 Subject: New package: denyhosts In-Reply-To: (Jason L. Tibbitts, III's message of "Fri, 13 May 2005 15:12:29 -0500") References: Message-ID: My thanks to those who responded; I have made various requested fixes. The new spec and rebuilt packages are at http://www.math.uh.edu/~tibbs/denyhosts/ The changelog entry: * Thu May 19 2005 Jason L Tibbitts III - 0.5.5-2 - Use dist tag - Don't automatically enable at install time - Include %ghost'ed allowed-warned-hosts file - Use %ghost instead of including zero length files. - Source is at dl.sourceforge.net I'm still looking into aging out hosts. Hopefully the author will have some ideas in this direction. - J< From enrico.scholz at informatik.tu-chemnitz.de Thu May 19 18:22:52 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 19 May 2005 20:22:52 +0200 Subject: RFE: dietlibc review In-Reply-To: <1116526185.13979.27.camel@cutter> (seth vidal's message of "Thu, 19 May 2005 14:09:45 -0400") References: <87oeb7i0wh.fsf@kosh.bigo.ensc.de> <1116526185.13979.27.camel@cutter> Message-ID: <87k6lvhy83.fsf@kosh.bigo.ensc.de> skvidal at phy.duke.edu (seth vidal) writes: >> it would be nice when somebody could review the devel/ branch of dietlibc >> in CVS. It blocks other packages so it would be nice to have it in the >> repo. >> > > what does it block? ip-sentinel, dhcp-forwarder, util-vserver Enrico From notting at redhat.com Thu May 19 19:13:24 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 19 May 2005 15:13:24 -0400 Subject: RFE: dietlibc review In-Reply-To: <87k6lvhy83.fsf@kosh.bigo.ensc.de> References: <87oeb7i0wh.fsf@kosh.bigo.ensc.de> <1116526185.13979.27.camel@cutter> <87k6lvhy83.fsf@kosh.bigo.ensc.de> Message-ID: <20050519191324.GA6672@nostromo.devel.redhat.com> Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: > >> it would be nice when somebody could review the devel/ branch of dietlibc > >> in CVS. It blocks other packages so it would be nice to have it in the > >> repo. > > > > what does it block? > > ip-sentinel, dhcp-forwarder, util-vserver Odd, nothing about these requires dietlibc, AFAICT. Bill From kaboom at oobleck.net Thu May 19 19:18:25 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 19 May 2005 15:18:25 -0400 (EDT) Subject: RFE: dietlibc review In-Reply-To: <87oeb7i0wh.fsf@kosh.bigo.ensc.de> References: <87oeb7i0wh.fsf@kosh.bigo.ensc.de> Message-ID: On Thu, 19 May 2005, Enrico Scholz wrote: > Hello, > > it would be nice when somebody could review the devel/ branch of dietlibc > in CVS. It blocks other packages so it would be nice to have it in the > repo. You should add: %doc README.security SECURITY Also, change Source0 to: Source0: http://www.kernel.org/pub/linux/libs/dietlibc/dietlibc-0.28.tar.bz2 or a parameterized variant thereof -- the current Source0 URL at fefe.de just 404s. Other than that, rpmlint complains about the includes being in the main package (instead of -devel) but you can probably ignore that -- I don't think that it would make much sense to have a separate -devel package for this BuildRoot is non-"standard" for FE, but I don't know that that's a blocker? later, chris From enrico.scholz at informatik.tu-chemnitz.de Thu May 19 19:25:32 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 19 May 2005 21:25:32 +0200 Subject: RFE: dietlibc review In-Reply-To: <20050519191324.GA6672@nostromo.devel.redhat.com> (Bill Nottingham's message of "Thu, 19 May 2005 15:13:24 -0400") References: <87oeb7i0wh.fsf@kosh.bigo.ensc.de> <1116526185.13979.27.camel@cutter> <87k6lvhy83.fsf@kosh.bigo.ensc.de> <20050519191324.GA6672@nostromo.devel.redhat.com> Message-ID: <87fywjhvbn.fsf@kosh.bigo.ensc.de> notting at redhat.com (Bill Nottingham) writes: >> >> it would be nice when somebody could review the devel/ branch of dietlibc >> >> in CVS. It blocks other packages so it would be nice to have it in the >> >> repo. >> > >> > what does it block? >> >> ip-sentinel, dhcp-forwarder, util-vserver > > Odd, nothing about these requires dietlibc, AFAICT. All of them contain something like | %{!?_without_dietlibc:BuildRequires: dietlibc} Nitpicking between 'recommended' and 'required' does not make sense in the rpm-world ;) Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From denis at poolshark.org Thu May 19 19:31:10 2005 From: denis at poolshark.org (Denis Leroy) Date: Thu, 19 May 2005 12:31:10 -0700 Subject: [OT] Re: RFE: dietlibc review In-Reply-To: <87fywjhvbn.fsf@kosh.bigo.ensc.de> References: <87oeb7i0wh.fsf@kosh.bigo.ensc.de> <1116526185.13979.27.camel@cutter> <87k6lvhy83.fsf@kosh.bigo.ensc.de> <20050519191324.GA6672@nostromo.devel.redhat.com> <87fywjhvbn.fsf@kosh.bigo.ensc.de> Message-ID: <428CE97E.6010308@poolshark.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Enrico Scholz wrote: | notting at redhat.com (Bill Nottingham) writes: | | |>>>>it would be nice when somebody could review the devel/ branch of dietlibc |>>>>in CVS. It blocks other packages so it would be nice to have it in the |>>>>repo. |>>> |>>>what does it block? |>> |>>ip-sentinel, dhcp-forwarder, util-vserver |> |>Odd, nothing about these requires dietlibc, AFAICT. | | | All of them contain something like | | | %{!?_without_dietlibc:BuildRequires: dietlibc} | | Nitpicking between 'recommended' and 'required' does not make sense in | the rpm-world ;) | | Enrico FYI Enrico, I can't verify your email signatures. Thunderbird complains about an "unknown digest algorithm"... - -denis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCjOl9N21V2B2op6oRAtrTAKCrSCRdaK0fSAmJxN8K2PNFxitW0ACfXwpt cpMEWpGirU9e376uNQax2RQ= =Y5lZ -----END PGP SIGNATURE----- From ivazquez at ivazquez.net Thu May 19 19:43:14 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 19 May 2005 15:43:14 -0400 Subject: [OT] Re: RFE: dietlibc review In-Reply-To: <428CE97E.6010308@poolshark.org> References: <87oeb7i0wh.fsf@kosh.bigo.ensc.de> <1116526185.13979.27.camel@cutter> <87k6lvhy83.fsf@kosh.bigo.ensc.de> <20050519191324.GA6672@nostromo.devel.redhat.com> <87fywjhvbn.fsf@kosh.bigo.ensc.de> <428CE97E.6010308@poolshark.org> Message-ID: <1116531794.7161.69.camel@ignacio.ignacio.lan> On Thu, 2005-05-19 at 12:31 -0700, Denis Leroy wrote: > FYI Enrico, I can't verify your email signatures. Thunderbird complains about > an "unknown digest algorithm"... Same here. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFCjOl9N21V2B2op6oRAtrTAKCrSCRdaK0fSAmJxN8K2PNFxitW0ACfXwpt > cpMEWpGirU9e376uNQax2RQ= > =Y5lZ > -----END PGP SIGNATURE----- Also, Denis, Evolution can't see yours at all since it's inline and not an attachment. -- 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 enrico.scholz at informatik.tu-chemnitz.de Thu May 19 20:17:43 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 19 May 2005 22:17:43 +0200 Subject: [OT] Re: RFE: dietlibc review In-Reply-To: <428CE97E.6010308@poolshark.org> (Denis Leroy's message of "Thu, 19 May 2005 12:31:10 -0700") References: <87oeb7i0wh.fsf@kosh.bigo.ensc.de> <1116526185.13979.27.camel@cutter> <87k6lvhy83.fsf@kosh.bigo.ensc.de> <20050519191324.GA6672@nostromo.devel.redhat.com> <87fywjhvbn.fsf@kosh.bigo.ensc.de> <428CE97E.6010308@poolshark.org> Message-ID: <877jhvhswo.fsf@kosh.bigo.ensc.de> denis at poolshark.org (Denis Leroy) writes: > FYI Enrico, I can't verify your email signatures. Thunderbird complains about > an "unknown digest algorithm"... mmh... I have two theories: * you imported my key from the wrong keyserver. E.g. pgp.mit.edu is known to be broken for modern GPG subkeys. * your gnupg does not support SHA512 digests; I am using gpg-1.4.1 here and can verify my signature; dunno when this algorithm was added. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From kaboom at oobleck.net Thu May 19 20:17:38 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 19 May 2005 16:17:38 -0400 (EDT) Subject: rpms/dietlibc/devel dietlibc.spec,1.11,1.12 In-Reply-To: <200505192011.j4JKBCvw013940@cvs-int.fedora.redhat.com> References: <200505192011.j4JKBCvw013940@cvs-int.fedora.redhat.com> Message-ID: On Thu, 19 May 2005, Enrico Scholz wrote: > -Source0: http://www.fefe.de/dietlibc/%NAME-%version.tar.bz2 > -Source1: http://www.fefe.de/dietlibc/%NAME-%version.tar.bz2.sig > +Source0: http://www.kernel.org/pub/linux/libs/dietlibc/%NAME-%version.tar.bz2 > +Source1: http://www.kernel.org/pub/linux/libs/dietlibc/%NAME-%version.tar.bz2.sig Actually, Source1 didn't need changing. For Source1: http://www.fefe.de/dietlibc/dietlibc-0.28.tar.bz2.sig is the pgp signature from the author (probably what you want) http://www.kernel.org/pub/linux/libs/dietlibc/dietlibc-0.28.tar.bz2.sign is the autogenerated stuff that kernel.org does http://www.kernel.org/pub/linux/libs/dietlibc/dietlibc-0.28.tar.bz2.sig is 404 later, chris From enrico.scholz at informatik.tu-chemnitz.de Thu May 19 20:15:12 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 19 May 2005 22:15:12 +0200 Subject: RFE: dietlibc review In-Reply-To: (Chris Ricker's message of "Thu, 19 May 2005 15:18:25 -0400 (EDT)") References: <87oeb7i0wh.fsf@kosh.bigo.ensc.de> Message-ID: <87br77ht0v.fsf@kosh.bigo.ensc.de> kaboom at oobleck.net (Chris Ricker) writes: >> it would be nice when somebody could review the devel/ branch of dietlibc >> in CVS. It blocks other packages so it would be nice to have it in the >> repo. > > You should add: > > %doc README.security SECURITY > > Also, change Source0 to: > > Source0: > http://www.kernel.org/pub/linux/libs/dietlibc/dietlibc-0.28.tar.bz2 > > or a parameterized variant thereof -- the current Source0 URL at > fefe.de just 404s. thx; done. > Other than that, rpmlint complains about the includes being in the main > package (instead of -devel) but you can probably ignore that -- I don't > think that it would make much sense to have a separate -devel package for > this yes; I am not sure if I shall 'Provides: dietlibc-devel' but currently, dietlibc is for pure developing. > BuildRoot is non-"standard" for FE, but I don't know that that's a > blocker? thx; added an %release. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From nhorman at redhat.com Thu May 19 20:24:18 2005 From: nhorman at redhat.com (Neil Horman) Date: Thu, 19 May 2005 16:24:18 -0400 Subject: New package: iozone Message-ID: <20050519202418.GH14451@hmsendeavour.rdu.redhat.com> Hey all- Package Name: iozone Description: iozone is a filesystem benchmarking tool, that allows one to record various performance metrics on a filesystem, and graph the results. Iozone is reasonably mature, and listed by the maintainer as freeware. Its got a number of options for fine tuning the metrics you collect, and the format they are output in. Location: http://people.redhat.com/nhorman/iozone-3-1.src.rpm http://people.redhat.com/nhorman/iozone.spec md5sums: 57b6989afbc52bea93e4bba7392e683f iozone.spec 4c5ee5e7f0169f2d68bd17ceedd6a5cd iozone-3-1.src.rpm srpm passes rpmlint with no concerning errors/warnings. Looking for an initial review and acceptance. Thanks and Regards Neil -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman at redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ From kaboom at oobleck.net Thu May 19 20:26:00 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 19 May 2005 16:26:00 -0400 (EDT) Subject: request for review: qgo Message-ID: I'm learning to play go, and find that I like this board better than cgoban qGo is a graphical Go client in which you can play Go against another player, connect to Go servers on the Internet, or connect with local Go programs such as Gnu Go. qGo is also a full-featured SGF editor. In addition, qGo supports loading MGT and Jago XML format Go games. Anyone want to review it? later, chris From notting at redhat.com Thu May 19 20:27:47 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 19 May 2005 16:27:47 -0400 Subject: RFE: dietlibc review In-Reply-To: <87fywjhvbn.fsf@kosh.bigo.ensc.de> References: <87oeb7i0wh.fsf@kosh.bigo.ensc.de> <1116526185.13979.27.camel@cutter> <87k6lvhy83.fsf@kosh.bigo.ensc.de> <20050519191324.GA6672@nostromo.devel.redhat.com> <87fywjhvbn.fsf@kosh.bigo.ensc.de> Message-ID: <20050519202747.GA12080@nostromo.devel.redhat.com> Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: > >> ip-sentinel, dhcp-forwarder, util-vserver > > > > Odd, nothing about these requires dietlibc, AFAICT. > > All of them contain something like > > | %{!?_without_dietlibc:BuildRequires: dietlibc} > > Nitpicking between 'recommended' and 'required' does not make sense in > the rpm-world ;) Wasn't looking at the specs, actually; just the source; it certainly doesn't require dietlibc in that sense. Bill From a.kurtz at hardsun.net Thu May 19 20:32:58 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Thu, 19 May 2005 13:32:58 -0700 Subject: New package: denyhosts In-Reply-To: References: Message-ID: <1116534778.462.6.camel@rydia.hardsun.net> On Thu, 2005-05-19 at 13:49 -0500, Jason L Tibbitts III wrote: > My thanks to those who responded; I have made various requested > fixes. The new spec and rebuilt packages are at > http://www.math.uh.edu/~tibbs/denyhosts/ Looks fine to me. I'll approve this package. Do you have CVS access, or would you like me to import it? > I'm still looking into aging out hosts. Hopefully the author will > have some ideas in this direction. I asked the author, and he said he's working on, but has not yet released a version with: > 1. hostname lookups for IP address > 2. The ability to suppress "suspicious login" attempts from valid > hosts. > 3. timestamp bug fix on email reports. Personally I'd like a way to block hosts the second time they use a non-existent user. -- Aaron Kurtz (Chris Ricker's message of "Thu, 19 May 2005 16:17:38 -0400 (EDT)") References: <200505192011.j4JKBCvw013940@cvs-int.fedora.redhat.com> Message-ID: <873bsjhs46.fsf@kosh.bigo.ensc.de> kaboom at oobleck.net (Chris Ricker) writes: > On Thu, 19 May 2005, Enrico Scholz wrote: > >> -Source0: http://www.fefe.de/dietlibc/%NAME-%version.tar.bz2 >> -Source1: http://www.fefe.de/dietlibc/%NAME-%version.tar.bz2.sig >> +Source0: http://www.kernel.org/pub/linux/libs/dietlibc/%NAME-%version.tar.bz2 >> +Source1: http://www.kernel.org/pub/linux/libs/dietlibc/%NAME-%version.tar.bz2.sig > > Actually, Source1 didn't need changing. > > For Source1: > > http://www.fefe.de/dietlibc/dietlibc-0.28.tar.bz2.sig > > is the pgp signature from the author (probably what you want) ok; thx again. I hope I got it right this time ;) Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Thu May 19 20:49:36 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 19 May 2005 22:49:36 +0200 Subject: RFE: dietlibc review In-Reply-To: <20050519202747.GA12080@nostromo.devel.redhat.com> (Bill Nottingham's message of "Thu, 19 May 2005 16:27:47 -0400") References: <87oeb7i0wh.fsf@kosh.bigo.ensc.de> <1116526185.13979.27.camel@cutter> <87k6lvhy83.fsf@kosh.bigo.ensc.de> <20050519191324.GA6672@nostromo.devel.redhat.com> <87fywjhvbn.fsf@kosh.bigo.ensc.de> <20050519202747.GA12080@nostromo.devel.redhat.com> Message-ID: <87y8abgcv3.fsf@kosh.bigo.ensc.de> notting at redhat.com (Bill Nottingham) writes: >> >> ip-sentinel, dhcp-forwarder, util-vserver >> > >> > Odd, nothing about these requires dietlibc, AFAICT. > ... > Wasn't looking at the specs, actually; just the source; it certainly > doesn't require dietlibc in that sense. As said, rpm does not know something like 'recommends'. For ip-sentinel and dhcp-forwarder it should not make much difference (except different resource usage at runtime) whether they are compiled/linked against dietlibc or glibc. But dietlibc is recommended for them. But for util-vserver, I hope that I made the warnings big and fat enough when the tools will be built against glibc. ;) Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From notting at redhat.com Thu May 19 21:03:25 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 19 May 2005 17:03:25 -0400 Subject: RFE: dietlibc review In-Reply-To: <87y8abgcv3.fsf@kosh.bigo.ensc.de> References: <87oeb7i0wh.fsf@kosh.bigo.ensc.de> <1116526185.13979.27.camel@cutter> <87k6lvhy83.fsf@kosh.bigo.ensc.de> <20050519191324.GA6672@nostromo.devel.redhat.com> <87fywjhvbn.fsf@kosh.bigo.ensc.de> <20050519202747.GA12080@nostromo.devel.redhat.com> <87y8abgcv3.fsf@kosh.bigo.ensc.de> Message-ID: <20050519210325.GA12387@nostromo.devel.redhat.com> Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: > > Wasn't looking at the specs, actually; just the source; it certainly > > doesn't require dietlibc in that sense. > > As said, rpm does not know something like 'recommends'. For ip-sentinel > and dhcp-forwarder it should not make much difference (except different > resource usage at runtime) whether they are compiled/linked against > dietlibc or glibc. But dietlibc is recommended for them. > > But for util-vserver, I hope that I made the warnings big and fat enough > when the tools will be built against glibc. ;) I suppose; it just seems to me that building against an alternate libc exposes you to many of the same problems that building with an alternate compiler does; it's more likely to experience odd bugs that other things don't, it limits you from various features that are in the standard libc (including some of the memory protection ones), etc. Bill From ivazquez at ivazquez.net Thu May 19 21:25:47 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 19 May 2005 17:25:47 -0400 Subject: New package: kanatest - Approval needed In-Reply-To: <1115919017.19974.4.camel@tprobert.intranet.promca.com> References: <1115597334.20177.21.camel@localhost.localdomain> <1115640329.21984.22.camel@ignacio.ignacio.lan> <1115653760.11898.6.camel@tprobert.intranet.promca.com> <1115654009.20150.2.camel@localhost.localdomain> <1115656573.17797.2.camel@tprobert.intranet.promca.com> <1115919017.19974.4.camel@tprobert.intranet.promca.com> Message-ID: <1116537947.7161.75.camel@ignacio.ignacio.lan> On Thu, 2005-05-12 at 13:30 -0400, Robert Marcano wrote: > On Mon, 2005-05-09 at 12:36 -0400, Robert Marcano wrote: > > ... > > Updated and uploaded > > > > http://www.marcanoonline.com/downloads/fedora/package_submissions/kanatest/kanatest-0.3.6-2.src.rpm > > http://www.marcanoonline.com/downloads/fedora/package_submissions/kanatest/kanatest.spec > > > > I have updated the SPEC file following the recommendations given on this > list. The next step is Sponsorship?... Anyone can help? + URL and source are good + File ownership is good + Builds as non-root - Missing d-f-u in BR Fix that one last problem and I'll approve it. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From robert at marcanoonline.com Thu May 19 21:31:55 2005 From: robert at marcanoonline.com (Robert Marcano) Date: Thu, 19 May 2005 17:31:55 -0400 Subject: New package: kanatest - Approval needed In-Reply-To: <1116537947.7161.75.camel@ignacio.ignacio.lan> References: <1115597334.20177.21.camel@localhost.localdomain> <1115640329.21984.22.camel@ignacio.ignacio.lan> <1115653760.11898.6.camel@tprobert.intranet.promca.com> <1115654009.20150.2.camel@localhost.localdomain> <1115656573.17797.2.camel@tprobert.intranet.promca.com> <1115919017.19974.4.camel@tprobert.intranet.promca.com> <1116537947.7161.75.camel@ignacio.ignacio.lan> Message-ID: <1116538315.21626.3.camel@tprobert.intranet.promca.com> On Thu, 2005-05-19 at 17:25 -0400, Ignacio Vazquez-Abrams wrote: .... > > list. The next step is Sponsorship?... Anyone can help? > > + URL and source are good > + File ownership is good > + Builds as non-root > > - Missing d-f-u in BR > > Fix that one last problem and I'll approve it. > cool? I feel like learning another language, what means "d-f-u in BR"? :$ d-f-i = desktop-file-install d-f-u != desktop file-uninstall (jejeje i do not find it) > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list ________________________________________ Robert Marcano web: http://www.marcanoonline.com/ gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD From ivazquez at ivazquez.net Thu May 19 21:38:00 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 19 May 2005 17:38:00 -0400 Subject: New package: kanatest - Approval needed In-Reply-To: <1116538315.21626.3.camel@tprobert.intranet.promca.com> References: <1115597334.20177.21.camel@localhost.localdomain> <1115640329.21984.22.camel@ignacio.ignacio.lan> <1115653760.11898.6.camel@tprobert.intranet.promca.com> <1115654009.20150.2.camel@localhost.localdomain> <1115656573.17797.2.camel@tprobert.intranet.promca.com> <1115919017.19974.4.camel@tprobert.intranet.promca.com> <1116537947.7161.75.camel@ignacio.ignacio.lan> <1116538315.21626.3.camel@tprobert.intranet.promca.com> Message-ID: <1116538680.7161.82.camel@ignacio.ignacio.lan> On Thu, 2005-05-19 at 17:31 -0400, Robert Marcano wrote: > On Thu, 2005-05-19 at 17:25 -0400, Ignacio Vazquez-Abrams wrote: > > .... > > > > list. The next step is Sponsorship?... Anyone can help? > > > > + URL and source are good > > + File ownership is good > > + Builds as non-root > > > > - Missing d-f-u in BR > > > > Fix that one last problem and I'll approve it. > > > > cool? > > I feel like learning another language, what means "d-f-u in BR"? :$ desktop-file-utils -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazquez at ivazquez.net Thu May 19 21:38:49 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 19 May 2005 17:38:49 -0400 Subject: New package: GCfilms In-Reply-To: <20050516004934.234bfba2@tianbox> References: <20050516004934.234bfba2@tianbox> Message-ID: <1116538729.7161.85.camel@ignacio.ignacio.lan> On Mon, 2005-05-16 at 00:49 +0200, Christian Jodar wrote: > http://download.gna.org/gcfilms/fedora/3/gcfilms-5.0-3.noarch.rpm + URL and source are good + File ownership is good > %setup -c RPM - This should be "%setup -n gcfilms". Then you won't have to use gcfilms/ everywhere. > %dir %{_defaultdocdir}/%{name}-%{version} > %doc %{_defaultdocdir}/%{name}-%{version}/CHANGELOG > %doc %{_defaultdocdir}/%{name}-%{version}/README - Once you make the change above you can reduce this to "%doc CHANGELOG README" and get rid of the lines to copy the files. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazquez at ivazquez.net Thu May 19 21:47:53 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 19 May 2005 17:47:53 -0400 Subject: Extras contribution: sensors applet In-Reply-To: <1116408411.4324.66.camel@rydia.hardsun.net> References: <1116408411.4324.66.camel@rydia.hardsun.net> Message-ID: <1116539273.7161.91.camel@ignacio.ignacio.lan> On Wed, 2005-05-18 at 02:26 -0700, Aaron Kurtz wrote: > http://hardsun.net/fedora/gnome-applet-sensors-0.7.3-1.src.rpm + URL and source are good + File ownership is good + Builds as non-root Approved. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Thu May 19 22:17:53 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 20 May 2005 00:17:53 +0200 Subject: New package: iozone In-Reply-To: <20050519202418.GH14451@hmsendeavour.rdu.redhat.com> References: <20050519202418.GH14451@hmsendeavour.rdu.redhat.com> Message-ID: <20050520001753.78bcdea8.bugs.michael@gmx.net> On Thu, 19 May 2005 16:24:18 -0400, Neil Horman wrote: > Hey all- > > Package Name: iozone > > Description: iozone is a filesystem benchmarking tool, that allows one to record > various performance metrics on a filesystem, and graph the results. Iozone is > reasonably mature, and listed by the maintainer as freeware. Its got a number > of options for fine tuning the metrics you collect, and the format they are > output in. > > Location: > > http://people.redhat.com/nhorman/iozone-3-1.src.rpm > http://people.redhat.com/nhorman/iozone.spec > > md5sums: > 57b6989afbc52bea93e4bba7392e683f iozone.spec > 4c5ee5e7f0169f2d68bd17ceedd6a5cd iozone-3-1.src.rpm > > srpm passes rpmlint with no concerning errors/warnings. Looking for an initial > review and acceptance. Lots of small issues: * Package contains the files from "debuginfo" package, because you include everything below %{_libdir}. However, no file in %_libdir belongs into the package at all. * Package builds with non-standard compiler optimisations, such as the not so tested (and hence not recommended or even dangerous) -O3. * %defattr statement missing at beginning of %files section. * At beginning of %install, you don't empty $RPM_BUILD_ROOT. * Sometimes you use /usr/bin, sometimes %_bindir. Prefer %_bindir everywhere. (On the contrary, keep /usr/share instead of %_datadir, because you hardcode /usr/share in your patch.) * At beginning of %install, you are inside $RPM_BUILD_DIR/iozone3_239 already, so you could use relative paths during installation and avoid the hardcoded iozone3_239 directory name everywhere. * "mkdir -p $RPM_BUILD_ROOT/usr/docs" is superfluous. You don't use the created directory. * Prefer "install -p" or "cp -p" to preserve timestamps of copied files (end-users can easily see the age of files, such as old documentation, for instance). * Mentioning the program's name in package "Summary" is considered bad taste. * At the topic of "bad taste", is the documentation really needed in three different formats (MS Office .doc, PDF and compressed PostScript)? I would suggest dropping the .doc and .ps.gz. * Executable text files: Gnuplot.txt in %doc and /usr/share/iozone/gnu3d.dem And a hint: %dir /usr/share/iozone /usr/share/iozone/* is the same as /usr/share/iozone/ Likewise: %dir %{_docdir}/iozone %{_docdir}/iozone/* is the same as %{_docdir}/iozone/ The one-line version includes the directory and the entire tree in it. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1305_FC4 loadavg: 1.14 1.15 1.25 From enrico.scholz at informatik.tu-chemnitz.de Thu May 19 21:50:58 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 19 May 2005 23:50:58 +0200 Subject: RFE: dietlibc review In-Reply-To: <20050519210325.GA12387@nostromo.devel.redhat.com> (Bill Nottingham's message of "Thu, 19 May 2005 17:03:25 -0400") References: <87oeb7i0wh.fsf@kosh.bigo.ensc.de> <1116526185.13979.27.camel@cutter> <87k6lvhy83.fsf@kosh.bigo.ensc.de> <20050519191324.GA6672@nostromo.devel.redhat.com> <87fywjhvbn.fsf@kosh.bigo.ensc.de> <20050519202747.GA12080@nostromo.devel.redhat.com> <87y8abgcv3.fsf@kosh.bigo.ensc.de> <20050519210325.GA12387@nostromo.devel.redhat.com> Message-ID: <87u0kyhol9.fsf@kosh.bigo.ensc.de> notting at redhat.com (Bill Nottingham) writes: >> > Wasn't looking at the specs, actually; just the source; it certainly >> > doesn't require dietlibc in that sense. >> ... >> But for util-vserver, I hope that I made the warnings big and fat enough >> when the tools will be built against glibc. ;) > > I suppose; it just seems to me that building against an alternate > libc exposes you to many of the same problems that building with an > alternate compiler does; All the mentioned programs were developed with dietlibc in mind. But afaik, X11 or gcc can be built with dietlibc also. > it's more likely to experience odd bugs that other things don't, indeed; dietlibc with non-mainstream archs (not x86) is problematic :( I hope that I got it right that at least the mentioned programs can be compiled on the supported platforms. > it limits you from various features that are in the standard libc glibc has mechanisms like dynamic loading of libnss libraries. This makes it completely unusable for chroot operations (both for security and functional aspects); e.g. you will see odd errors with 'rpm --root' and LDAP nss-switching in the host. Static linking against dietlibc removes this problem completely. Beside that... dietlibc is much more efficiently than glibc; e.g. a simple 'int main() {}' (this is all what is needed for /bin/true) will need more resources with glibc than a complex program linked against dietlibc. It is sick what 'strace /bin/true' gives out... ;) > (including some of the memory protection ones), etc. dietlibc has stack-randomization also. And in the age of vsyscalls return-to-libc attacks are possible with random dynamic library loading. And... it is better to program in a secure manner instead of hoping that some magic memory protection (which can be circumvented in most cases) protects you against exploits. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From mfleming at enlartenment.com Thu May 19 22:42:10 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Fri, 20 May 2005 08:42:10 +1000 Subject: New package: iozone In-Reply-To: <20050519202418.GH14451@hmsendeavour.rdu.redhat.com> References: <20050519202418.GH14451@hmsendeavour.rdu.redhat.com> Message-ID: <20050520084210.5cd153da.mfleming@enlartenment.com> On Thu, 19 May 2005 16:24:18 -0400. Neil Horman waffled thusly: > Hey all- > > Package Name: iozone > > Description: iozone is a filesystem benchmarking tool, that allows one to > record various performance metrics on a filesystem, and graph the > results. Iozone is reasonably mature, and listed by the maintainer as > freeware. Its got a number of options for fine tuning the metrics you > collect, and the format they are output in. > > Location: > > http://people.redhat.com/nhorman/iozone-3-1.src.rpm > http://people.redhat.com/nhorman/iozone.spec > > md5sums: > 57b6989afbc52bea93e4bba7392e683f iozone.spec > 4c5ee5e7f0169f2d68bd17ceedd6a5cd iozone-3-1.src.rpm > > srpm passes rpmlint with no concerning errors/warnings. Looking for an > initial review and acceptance. - Build from your SRPM failed for me - you have a reference to %{_libdir}/* in % files but nothing actually in there ;-) - RPMLint claims file ownership is nonstandard. Therefore you need a % defattr (-,root,root,-) just after %files. - Swapping "cp $RPM_BUILD_DIR/iozone3_239/src/current" for plain old "install -p src/current" looks (to me) to be cleaner and simpler to follow - always a good thing in a .sW: iozone no-version-in-last-changelog - I would leave the files your spec puts in /usr/share/doc/iozone/ in %doc, rather than use %{_docdir} and friends explicitly. - Clear the buildroot before install (no clutter/crap can sneak in from previous rebuild attempts this way) - Generate_Graphs needs a #!/bin/sh shebang line (trivial patch, upstream fix or both) - Requires: gnuplot for the above? RPMlint output with my own basic changes: W: iozone unstripped-binary-or-object /usr/bin/iozone E: iozone script-without-shellbang /usr/bin/Generate_Graphs E: iozone wrong-script-end-of-line-encoding /usr/share/doc/iozone/ Gnuplot.txt E: iozone no-signature Diff attached :-) > Thanks and Regards > Neil > Cheers, Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" -------------- next part -------------- A non-text attachment was scrubbed... Name: iozone.spec.diff Type: application/octet-stream Size: 2038 bytes Desc: not available URL: From paul at all-the-johnsons.co.uk Thu May 19 22:57:17 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 19 May 2005 23:57:17 +0100 Subject: Icecast Message-ID: <1116543437.4695.15.camel@localhost> Hi, Any chance of bringing icecast/shoutcast into extras? TTFN Paul -- "Space", it says, "is big. Really big. You just won't believe how vastly, hugely, mind-bogglingly big space really is. I mean, you may think it's a long way down the road to the chemists, but that's just *peanuts* compared to space, listen" - Hitch Hikers Guide to the Galaxy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mfleming at enlartenment.com Thu May 19 23:03:49 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Fri, 20 May 2005 09:03:49 +1000 Subject: Icecast In-Reply-To: <1116543437.4695.15.camel@localhost> References: <1116543437.4695.15.camel@localhost> Message-ID: <20050520090349.39c4e8b8.mfleming@enlartenment.com> On Thu, 19 May 2005 23:57:17 +0100. Paul waffled thusly: > Hi, > > Any chance of bringing icecast/shoutcast into extras? > I've got a package of it. (http://www.enlartenment.com/packages.php) I'll clean it up and import it if someone wishes to review it and approve it. > TTFN > > Paul Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From mfleming at enlartenment.com Thu May 19 23:18:38 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Fri, 20 May 2005 09:18:38 +1000 Subject: Icecast In-Reply-To: <20050520090349.39c4e8b8.mfleming@enlartenment.com> References: <1116543437.4695.15.camel@localhost> <20050520090349.39c4e8b8.mfleming@enlartenment.com> Message-ID: <20050520091838.6ec4bba3.mfleming@enlartenment.com> On Fri, 20 May 2005 09:03:49 +1000. Michael Fleming waffled thusly: > On Thu, 19 May 2005 23:57:17 +0100. Paul waffled thusly: > > > Hi, > > > > Any chance of bringing icecast/shoutcast into extras? > > > > I've got a package of it. (http://www.enlartenment.com/packages.php) I'll > clean it up and import it if someone wishes to review it and approve it. Here you go. Pick it to pieces :-) One note - I think for FC4 it may be able to use libtheora (the version packaged with FC3 is too old). I could put that into future updates if desired. SPEC: http://www.enlartenment.com/extras/icecast.spec SRPM: http://www.enlartenment.com/extras/icecast-2.2.0-1.src.rpm Cheers, Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From tibbs at math.uh.edu Fri May 20 00:40:31 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 19 May 2005 19:40:31 -0500 Subject: New package: denyhosts In-Reply-To: <1116534778.462.6.camel@rydia.hardsun.net> (Aaron Kurtz's message of "Thu, 19 May 2005 13:32:58 -0700") References: <1116534778.462.6.camel@rydia.hardsun.net> Message-ID: >>>>> "AK" == Aaron Kurtz writes: AK> Looks fine to me. I'll approve this package. Do you have CVS AK> access, or would you like me to import it? I applied for access and have progressed to the "needs a sponsor" phase. Feel free to import it. AK> Personally I'd like a way to block hosts the second time they use AK> a non-existent user. That's reasonable. The script is pretty simple so I'm just going to have a go and see what I can cook up. - J< From tcallawa at redhat.com Fri May 20 00:53:57 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 19 May 2005 19:53:57 -0500 Subject: Request for review: scrub Message-ID: <1116550437.22593.13.camel@localhost.localdomain> Scrub: A little disk scrubbing program, checked into CVS. Scrub writes patterns on special files (i.e. raw disk devices) or regular files to reduce the possibility of someone retrieving the data. There are up to six passes, each of which fills the disk with a particular pattern. Again, a really small package. One binary, a man page, and some docs. Please review for approval. Thanks, ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From kaboom at oobleck.net Fri May 20 01:32:48 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 19 May 2005 21:32:48 -0400 (EDT) Subject: rpms/dietlibc/devel dietlibc.spec,1.11,1.12 In-Reply-To: <873bsjhs46.fsf@kosh.bigo.ensc.de> References: <200505192011.j4JKBCvw013940@cvs-int.fedora.redhat.com> <873bsjhs46.fsf@kosh.bigo.ensc.de> Message-ID: On Thu, 19 May 2005, Enrico Scholz wrote: > > http://www.fefe.de/dietlibc/dietlibc-0.28.tar.bz2.sig > > > > is the pgp signature from the author (probably what you want) > > ok; thx again. I hope I got it right this time ;) Looks good - approved later, chris From kaboom at oobleck.net Fri May 20 01:34:31 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 19 May 2005 21:34:31 -0400 (EDT) Subject: Icecast In-Reply-To: <1116543437.4695.15.camel@localhost> References: <1116543437.4695.15.camel@localhost> Message-ID: On Thu, 19 May 2005, Paul wrote: > Hi, > > Any chance of bringing icecast/shoutcast into extras? It might be something better added to livna, just because an extras version would have to be ogg-only later, chris From kaboom at oobleck.net Fri May 20 01:52:49 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 19 May 2005 21:52:49 -0400 (EDT) Subject: request for review: qgo In-Reply-To: References: Message-ID: On Thu, 19 May 2005, Chris Ricker wrote: > New rev for review at Updated to fix a directory not being owned by the rpm later, chris From mpeters at mac.com Fri May 20 02:04:47 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 19 May 2005 19:04:47 -0700 Subject: Icecast In-Reply-To: References: <1116543437.4695.15.camel@localhost> Message-ID: <1116554687.25346.4.camel@laptop.mpeters.local> On Thu, 2005-05-19 at 21:34 -0400, Chris Ricker wrote: > On Thu, 19 May 2005, Paul wrote: > > > Hi, > > > > Any chance of bringing icecast/shoutcast into extras? > > It might be something better added to livna, just because an extras > version would have to be ogg-only There's a gstreamer streaming server that could be brought into extras - since gstreamer uses plugins, that mp3 thing isn't an issue. I forget what its called - but when I tried it, it seemed to work well. I believe it starts with an a - should be on the gstreamer page. From ivazquez at ivazquez.net Fri May 20 02:14:28 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 19 May 2005 22:14:28 -0400 Subject: Icecast In-Reply-To: References: <1116543437.4695.15.camel@localhost> Message-ID: <1116555268.7161.96.camel@ignacio.ignacio.lan> On Thu, 2005-05-19 at 21:34 -0400, Chris Ricker wrote: > On Thu, 19 May 2005, Paul wrote: > > > Hi, > > > > Any chance of bringing icecast/shoutcast into extras? > > It might be something better added to livna, just because an extras > version would have to be ogg-only I thought icecast was format-agnostic and it depended on ices for actually creating the stream (which my repo happens to have the Vorbis version for). -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazquez at ivazquez.net Fri May 20 02:15:18 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 19 May 2005 22:15:18 -0400 Subject: Icecast In-Reply-To: <1116554687.25346.4.camel@laptop.mpeters.local> References: <1116543437.4695.15.camel@localhost> <1116554687.25346.4.camel@laptop.mpeters.local> Message-ID: <1116555318.7161.98.camel@ignacio.ignacio.lan> On Thu, 2005-05-19 at 19:04 -0700, Michael A. Peters wrote: > I forget what its called - but when I tried it, it seemed to work well. > I believe it starts with an a - should be on the gstreamer page. Flumotion. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazquez at ivazquez.net Fri May 20 02:17:23 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 19 May 2005 22:17:23 -0400 Subject: Icecast In-Reply-To: <1116555318.7161.98.camel@ignacio.ignacio.lan> References: <1116543437.4695.15.camel@localhost> <1116554687.25346.4.camel@laptop.mpeters.local> <1116555318.7161.98.camel@ignacio.ignacio.lan> Message-ID: <1116555443.7161.100.camel@ignacio.ignacio.lan> On Thu, 2005-05-19 at 22:15 -0400, Ignacio Vazquez-Abrams wrote: > On Thu, 2005-05-19 at 19:04 -0700, Michael A. Peters wrote: > > I forget what its called - but when I tried it, it seemed to work well. > > I believe it starts with an a - should be on the gstreamer page. > > Flumotion. No, my bad, acast. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mfleming at enlartenment.com Fri May 20 02:17:16 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Fri, 20 May 2005 12:17:16 +1000 Subject: Icecast In-Reply-To: <1116554687.25346.4.camel@laptop.mpeters.local> References: <1116543437.4695.15.camel@localhost> <1116554687.25346.4.camel@laptop.mpeters.local> Message-ID: <20050520121716.04558a5c.mfleming@enlartenment.com> On Thu, 19 May 2005 19:04:47 -0700. Michael A. Peters waffled thusly: > On Thu, 2005-05-19 at 21:34 -0400, Chris Ricker wrote: > > On Thu, 19 May 2005, Paul wrote: > > > > > Hi, > > > > > > Any chance of bringing icecast/shoutcast into extras? > > > > It might be something better added to livna, just because an extras > > version would have to be ogg-only > > There's a gstreamer streaming server that could be brought into extras - > since gstreamer uses plugins, that mp3 thing isn't an issue. > > I forget what its called - but when I tried it, it seemed to work well. > I believe it starts with an a - should be on the gstreamer page. My first thought was "flumotion" which has a similar purpose, but I think the one you're thinking of is "acast" (http://zaheer.merali.org/mediawiki/index.php/Acast) Point taken on icecast - I'm not sure exactly how to easily dike out the MP3 support (which would effectively neuter it, oh well..). I'll keep packaging it myself if anyone wants it. :-) Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From petersen at redhat.com Fri May 20 02:37:21 2005 From: petersen at redhat.com (Jens Petersen) Date: Fri, 20 May 2005 11:37:21 +0900 Subject: Approval needed again: SCIM In-Reply-To: References: <4288869E.7060306@mbm.nifty.com> <428C6BBB.80600@redhat.com> Message-ID: <428D4D61.1070405@redhat.com> Konstantin Ryabitsev wrote: > On 5/19/05, Jens Petersen wrote: > >>Thanks for your work on this, Dairiki san. The package >>is approved. > > What about tables? SCIM is useless without tables. Yep, this is just the beginning we need lots more scim packages.... :) I'd like to see scim-{anthy,canna,skk} for Japanese for example. Hopefully skim too? :) Jens From kaboom at oobleck.net Fri May 20 03:23:03 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 19 May 2005 23:23:03 -0400 (EDT) Subject: Icecast In-Reply-To: <1116555268.7161.96.camel@ignacio.ignacio.lan> References: <1116543437.4695.15.camel@localhost> <1116555268.7161.96.camel@ignacio.ignacio.lan> Message-ID: On Thu, 19 May 2005, Ignacio Vazquez-Abrams wrote: > > It might be something better added to livna, just because an extras > > version would have to be ogg-only > > I thought icecast was format-agnostic and it depended on ices for > actually creating the stream (which my repo happens to have the Vorbis > version for). ices (or other clients) creates the streams, but icecast reads them and writes them. It has various sorta-plugin handlers which understand the various formats it supports to allow it to do that. See src/format_{mp3,ogg,theora,vorbis}.{c,h}. It's not really clear to me if what format_mp3.c does would be infringing, or if it's more along the lines of, say, all the id3-tag stuff that's already in FC / FE later, chris From kaboom at oobleck.net Fri May 20 03:52:06 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 19 May 2005 23:52:06 -0400 (EDT) Subject: Approval sought: mlmmj & mod_security. In-Reply-To: <20050519035157.GB6565@enlartenment.com> References: <20050519035157.GB6565@enlartenment.com> Message-ID: On Thu, 19 May 2005, Michael Fleming wrote: > Hi, > > I've had mlmmj (ezmlm-like mailing list manager) in CVS for a few weeks > now with some comments regarding the spec and structure, but no reports > of failures / blockers etc. It is still pending an approval (prior to my > requesting a build) - Remove LICENSE from the %doc - it's exactly the same as COPYING - You might want to change %dir %{_datadir}/mlmmj/ %{_datadir}/mlmmj/* to %{_datadir}/mlmmj (does the same thing, but is simpler) Other than those two, I don't see any blockers -- source matches upstream, spec looks fine and meets all the guidelines, and rpmlint is happy. Change the above and it's approved later, chris From a.kurtz at hardsun.net Fri May 20 05:07:11 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Thu, 19 May 2005 22:07:11 -0700 Subject: New package: denyhosts In-Reply-To: References: <1116534778.462.6.camel@rydia.hardsun.net> Message-ID: <1116565631.8777.5.camel@rydia.hardsun.net> On Thu, 2005-05-19 at 19:40 -0500, Jason L Tibbitts III wrote: > >>>>> "AK" == Aaron Kurtz writes: > > AK> Looks fine to me. I'll approve this package. Do you have CVS > AK> access, or would you like me to import it? > > I applied for access and have progressed to the "needs a sponsor" > phase. Feel free to import it. Approved email sent, imported, branch requested, please take care of the Bugzilla component request. -- Aaron Kurtz eet: A library designed to write an arbitrary set of chunks of data to a file EET is a tiny library designed to write an arbitary set of chunks of data to a file and optionally compress each chunk (very much like a zip file) and allow fast random-access reading of the file later on. http://fedora.ivazquez.net/files/eet-0.9.10.007-1.fc3.src.rpm This is another component of the EFL (Enlightenment Foundation Libraries). Whereas edb is used to store tabular data, eet is intended to store freeform data. -- 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 Fri May 20 06:31:36 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 20 May 2005 09:31:36 +0300 Subject: Request for review: replacing cdiff with colordiff Message-ID: <1116570696.22482.58.camel@bobcat.mine.nu> I intend to replace the current Extras cdiff package with colordiff, http://colordiff.sf.net/ for FC4 and later. I ported the functionality of the current cdiff script so that it uses colordiff as the colorizer backend and I've been using this for almost a year now as a replacement for cdiff, works for me. This cdiff port is also part of the upstream package nowadays. I think this is a trivial one, but nevertheless it's kind of a new package in Extras, so reviews welcome. SRPM at http://cachalot.mine.nu/3/SRPMS.extras/colordiff-1.0.5-0.1.src.rpm ("0." will be removed from the Release tag at import time.) From petersen at redhat.com Fri May 20 06:51:26 2005 From: petersen at redhat.com (Jens Petersen) Date: Fri, 20 May 2005 15:51:26 +0900 Subject: x86_64 status (was Re: Errors on x86_64 (broken c++ headers?)) In-Reply-To: <1116359526.20274.75.camel@cutter> References: <428354A9.5040501@ieee.org> <4283702D.7060208@ieee.org> <1115912711.8237.416.camel@mccallum.corsepiu.local> <42837DFB.9030304@ieee.org> <1115920551.29062.22.camel@weasel.laiskiainen.org> <1115921494.29062.28.camel@weasel.laiskiainen.org> <4283A0E0.2030203@ieee.org> <1115923168.13475.22.camel@cutter> <428A27D8.7020207@ieee.org> <1116359526.20274.75.camel@cutter> Message-ID: <428D88EE.5050302@redhat.com> seth vidal wrote: > On Tue, 2005-05-17 at 12:20 -0500, Quentin Spencer wrote: > http://blog.sethdot.org/index.cgi/226.html http://linux.duke.edu/~skvidal/mock/ Thanks. I tried it and got to: $ mock -r fedora-3-i386-core mock-0.1-1.src.rpm Starting Prep Preparing Root making /dev devices making misc files of use making yum.conf yum: command /usr/sbin/mock-helper yum --installroot /var/lib/mock//fedora-3-i386-core/root groupinstall build Creating user for builds Closed Non-zero return value 127 on executing /usr/sbin/mock-helper chroot /var/lib/mock//fedora-3-i386-core/root /sbin/runuser - root -c "/usr/sbin/useradd -u 500 -d /builddir mockbuild" (Missing /sbin/runuser... What is the deal with coreutils? :) Jens From skvidal at phy.duke.edu Fri May 20 07:11:48 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 20 May 2005 03:11:48 -0400 Subject: x86_64 status (was Re: Errors on x86_64 (broken c++ headers?)) In-Reply-To: <428D88EE.5050302@redhat.com> References: <428354A9.5040501@ieee.org> <4283702D.7060208@ieee.org> <1115912711.8237.416.camel@mccallum.corsepiu.local> <42837DFB.9030304@ieee.org> <1115920551.29062.22.camel@weasel.laiskiainen.org> <1115921494.29062.28.camel@weasel.laiskiainen.org> <4283A0E0.2030203@ieee.org> <1115923168.13475.22.camel@cutter> <428A27D8.7020207@ieee.org> <1116359526.20274.75.camel@cutter> <428D88EE.5050302@redhat.com> Message-ID: <1116573108.17831.7.camel@cutter> On Fri, 2005-05-20 at 15:51 +0900, Jens Petersen wrote: > seth vidal wrote: > > On Tue, 2005-05-17 at 12:20 -0500, Quentin Spencer wrote: > > http://blog.sethdot.org/index.cgi/226.html > > http://linux.duke.edu/~skvidal/mock/ > > Thanks. I tried it and got to: > > $ mock -r fedora-3-i386-core mock-0.1-1.src.rpm > Starting Prep > Preparing Root > making /dev devices > making misc files of use > making yum.conf > yum: command /usr/sbin/mock-helper yum --installroot > /var/lib/mock//fedora-3-i386-core/root groupinstall build > Creating user for builds > Closed > Non-zero return value 127 on executing /usr/sbin/mock-helper chroot > /var/lib/mock//fedora-3-i386-core/root /sbin/runuser - root -c > "/usr/sbin/useradd -u 500 -d /builddir mockbuild" > > (Missing /sbin/runuser... What is the deal with coreutils? :) > can you send me your root.log file? -sv From oliver at linux-kernel.at Fri May 20 07:26:23 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 20 May 2005 09:26:23 +0200 Subject: Request for discussion: Package installation problem with running nscd Message-ID: <200505200725.j4K7PNjg027829@mail.linux-kernel.at> Hi! I came along this problem a few times now and think it's a good idea to throw it on the list for discussion. I have a fcdev system running at my site that runs with ldap/nscd. The problem I'm running into - some times - is: * nscd is running and caches groups/passwd * I try to install a package * package does the usual groupadd -r >/dev/null 2>&1 or useradd ... * package' file list lists %attr(-, , ) or something like that. But as nscd caches the passwd/group it thinks that or doesn't exist and rpm tell's me: warning: group does not exist - using root Arg. rpm -e ; service nscd stop; rpm -Uvh ; service nscd start; Cannot be the correct solution. :-) I cannot ask all package maintainers to do a nscd -i passwd; nscd -i group after adding a user/group - of course I could, but I don't want to even think what kind of email's I'll receive then. :-) What do you think? Should adduser/addgroup check if nscd is running and if so, run the nscd -i passwd or nscd -i group? Best, Oliver - Oliver Falk UNIX/Linux Systems Administrator Autonomy Information Engineer Die Information in dieser Nachricht ist vertraulich und ausschlie?lich f?r den Adressaten bestimmt. Der Empf?nger dieser Nachricht, der nicht der Adressat, einer seiner Mitarbeiter oder sein Empfangsbevollm?chtigter ist, wird hiermit davon in Kenntnis gesetzt, dass er deren Inhalt nicht verwenden, weitergeben oder reproduzieren darf. Sollten Sie diese Nachricht irrt?mlich erhalten haben, benachrichtigen Sie uns bitte unverz?glich per Telefon und retournieren Sie uns die Nachricht per E-Mail/Fax. The information contained in this e-mail is privileged and confidential and is for the exclusive use of the addressee. The person who receives this e-mail and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof. If you have received this communication by mistake, please let us know by telephone without delay and send it back to us by e-mail/fax. From oliver at linux-kernel.at Fri May 20 07:45:12 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 20 May 2005 09:45:12 +0200 Subject: New package: rblcheck In-Reply-To: <428CAA2B.7010605@city-fan.org> Message-ID: <200505200744.j4K7iCWf032437@mail.linux-kernel.at> Hi Paul! [ ... ] > > OK. This moved to rblcheck-texttweak.patch and for the > > default lists I > > created a %{_sysconfdir}/rblcheckrc. This is - of course - easier to > > maintain than patchin' around. :-) > > Of course, it would be still nicer if rblcheck read > %{_sysconfdir}/rblcheckrc and ~/.rblcheckrc itself rather > than using a > wrapper script, but that would a fair bit of work. Of course it would be nicer this way. I may try to mail the author and ask for that... [ ... ] > The monkeys.com lists are all defunct. Ron has stopped > maintaining them. > I believe the same applies to dev.null.dk. > And *.dorkslayers.com. OK. Removed this lists. > Maybe some of the others too; I'd check them out. Don't just > check that > the DNS servers return results; check out the websites. These > lists come and go quite regularly. OK. I guess the best would be to have a list that doesn't change very often. Else we have to update those lists to regulary. :-) > The following lists are specified multiple times: > -s bl.spamcop.net > -s dnsbl.njabl.org > -s list.dsbl.org > -s multihop.dsbl.org > -s opm.blitzed.org > -s relays.ordb.org > -s unconfirmed.dsbl.org Uff thanks for pointin'. The usual copy/paste problem :-/ > Please don't include my private lists - it might cripple my DSL link: > -s dialups.city-fan.org > -s relays.city-fan.org > -s spammers.city-fan.org OK. Removed. > Should be added: > -s xbl.spamhaus.org OK. Added. > > So, Paul, I would be pleased to see you updating the > > rblcheckrc if I get an > > approval for the rblcheck package :-) > > I'll bear that in mind :-) Please do so. As I'm not sure that I'll check the lists in a regulary interval... > > And for the folks who had a look at the package > > allready/will have a look at > > the package to approve it. Please note, that I just updated it at: > > > > http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPRO VAL/rblcheck And once again updated. Release 6. > More notes: > > Description: > > - URL for MAPS should be http://www.mail-abuse.com/ not > http://www.maps.org/ > > - ORBL appears to be defunct. > > BuildRequires: > > - docbook-utils is needed for the docs directory. > > Files: > > - INSTALL file is generic and not of any use to an end user. Integrated/Changed this as well. Have a look... Hopefully Warren and/or Matthias have time and take a look to approve it. :-) Best, Oliver From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri May 20 09:37:01 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 20 May 2005 11:37:01 +0200 Subject: Request for review: replacing cdiff with colordiff In-Reply-To: <1116570696.22482.58.camel@bobcat.mine.nu> References: <1116570696.22482.58.camel@bobcat.mine.nu> Message-ID: <20050520113701.4774c66f@python2> Ville Skytt? wrote : > I intend to replace the current Extras cdiff package with colordiff, > http://colordiff.sf.net/ for FC4 and later. Looks good to me, your spec files are always a pleasure to review :-) Two things : - It says it's a wrapper to diff, but you don't require diffutils, is that normal? - The obsoletes should contain the last known version or version-release of cdiff, especially since you provide cdiff. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.27_FC3 Load : 0.17 0.97 1.25 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri May 20 09:54:56 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 20 May 2005 11:54:56 +0200 Subject: Request for review: scrub In-Reply-To: <1116550437.22593.13.camel@localhost.localdomain> References: <1116550437.22593.13.camel@localhost.localdomain> Message-ID: <20050520115456.438eb21a@python2> Tom 'spot' Callaway wrote : > Again, a really small package. One binary, a man page, and some docs. > > Please review for approval. Things to fix : - Don't strip the binary, or debuginfo package will be useless - Don't manually gzip the man page, rpm magic does that for you Things that could be improved : - Patch for CFLAGS isn't needed, you can just override at make time - You can use -D with install to have the directory tree created Attached is a quick patch to change all this ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.27_FC3 Load : 0.72 1.01 1.20 -------------- next part -------------- A non-text attachment was scrubbed... Name: scrub.spec.patch Type: application/octet-stream Size: 1441 bytes Desc: not available URL: From bugs.michael at gmx.net Fri May 20 10:03:39 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 20 May 2005 12:03:39 +0200 Subject: Icecast In-Reply-To: References: <1116543437.4695.15.camel@localhost> <1116555268.7161.96.camel@ignacio.ignacio.lan> Message-ID: <20050520120339.7b83437f.bugs.michael@gmx.net> On Thu, 19 May 2005 23:23:03 -0400 (EDT), Chris Ricker wrote: > On Thu, 19 May 2005, Ignacio Vazquez-Abrams wrote: > > > > It might be something better added to livna, just because an extras > > > version would have to be ogg-only > > > > I thought icecast was format-agnostic and it depended on ices for > > actually creating the stream (which my repo happens to have the Vorbis > > version for). > > ices (or other clients) creates the streams, but icecast reads them and > writes them. It has various sorta-plugin handlers which understand the > various formats it supports to allow it to do that. See > src/format_{mp3,ogg,theora,vorbis}.{c,h}. > > It's not really clear to me if what format_mp3.c does would be infringing, > or if it's more along the lines of, say, all the id3-tag stuff that's > already in FC / FE There is no mp3 codec implemented in there, just plugin infrastructure and icy-metadata stuff. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1305_FC4 loadavg: 1.00 1.04 0.80 From bugs.michael at gmx.net Fri May 20 10:14:48 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 20 May 2005 12:14:48 +0200 Subject: Request for review: scrub In-Reply-To: <1116550437.22593.13.camel@localhost.localdomain> References: <1116550437.22593.13.camel@localhost.localdomain> Message-ID: <20050520121448.18e8778f.bugs.michael@gmx.net> On Thu, 19 May 2005 19:53:57 -0500, Tom 'spot' Callaway wrote: > Scrub: > A little disk scrubbing program, checked into CVS. > > Scrub writes patterns on special files (i.e. raw disk devices) or > regular files to reduce the possibility of someone retrieving the > data. There are up to six passes, each of which fills the disk > with a particular pattern. > > Again, a really small package. One binary, a man page, and some docs. > > Please review for approval. --- scrub.spec.~1.2.~ 2005-05-20 02:51:08.000000000 +0200 +++ scrub.spec 2005-05-20 12:09:28.000000000 +0200 @@ -26,9 +26,8 @@ rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT%{_bindir} mkdir -p $RPM_BUILD_ROOT%{_mandir}/man1 -install -s -m 755 scrub $RPM_BUILD_ROOT%{_bindir} -gzip scrub.1 -install -m 644 scrub.1.gz $RPM_BUILD_ROOT%{_mandir}/man1 +install -m 755 scrub $RPM_BUILD_ROOT%{_bindir} +install -m 644 scrub.1 $RPM_BUILD_ROOT%{_mandir}/man1 %clean rm -rf $RPM_BUILD_ROOT How does it compare to "shred"? $ rpm -qf $(which shred) coreutils-5.2.1-45 -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1305_FC4 loadavg: 2.97 2.82 1.92 From tcallawa at redhat.com Fri May 20 11:42:38 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 20 May 2005 06:42:38 -0500 Subject: Request for review: scrub In-Reply-To: <20050520121448.18e8778f.bugs.michael@gmx.net> References: <1116550437.22593.13.camel@localhost.localdomain> <20050520121448.18e8778f.bugs.michael@gmx.net> Message-ID: <1116589359.22593.15.camel@localhost.localdomain> On Fri, 2005-05-20 at 12:14 +0200, Michael Schwendt wrote: > "shred"? As far as I can tell, they're similar, but scrub has a randomized pass (optional), and looks like it might be a bit more thorough. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri May 20 11:54:48 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 20 May 2005 13:54:48 +0200 Subject: Changes about php-sqlite Message-ID: <20050520135448.613852ae@python2> Hi, As of PHP5, sqlite v2 support is included in the main PHP sources, but after checking, the FC PHP5 packages are compiled with "--without-sqlite" explicitly, so SQLite support isn't present in Core. In the Extras FC-3 branch, there is still the php-pecl-sqlite extension : http://pecl.php.net/package/sqlite But it fails to rebuild on FC Development, and is considered pretty much obsolete since : 1) SQLite support is included in the main PHP sources 2) The author started working on a PDO SQLite module instead More info about this newer module here : http://pecl.php.net/package/PDO_SQLITE I've got packages ready for php-pecl-pdo and php-pecl-pdo-sqlite already, but as it is an SQLite extension for v3 databases and isn't compatible with v2 databases, it can't really be considered a drop-in replacement for the older php-pecl-sqlite package. Well, in terms of functionality, I guess it can. Two options : 1) Try to build a newer php-sqlite from the main PHP5 tarball 2) Build the PDO SQLite v3 module and move forward (me, not impartial ;-) In both cases, the module should obsolete php-pecl-sqlite <= 1.0.3 for smooth upgrades (rpm-wise). I personally prefer the SQLite v3 approach since that's what'll be in FC4 Core, so people will have the compatible tools to manipulate the databases... but it will mean breakage for people using the existing SQLite v2 module upon upgrade. Thoughts? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.27_FC3 Load : 0.21 0.28 0.41 From oliver at linux-kernel.at Fri May 20 12:19:32 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 20 May 2005 14:19:32 +0200 Subject: Changes about php-sqlite In-Reply-To: <20050520135448.613852ae@python2> Message-ID: <200505201218.j4KCIWnK025516@mail.linux-kernel.at> Hi Matthias! > As of PHP5, sqlite v2 support is included in the main PHP > sources, but after checking, the FC PHP5 packages are > compiled with "--without-sqlite" > explicitly, so SQLite support isn't present in Core. > > In the Extras FC-3 branch, there is still the php-pecl-sqlite > extension : > http://pecl.php.net/package/sqlite > > But it fails to rebuild on FC Development, and is considered > pretty much obsolete since : 1) SQLite support is included in > the main PHP sources > 2) The author started working on a PDO SQLite module instead > > More info about this newer module here : > http://pecl.php.net/package/PDO_SQLITE > > I've got packages ready for php-pecl-pdo and > php-pecl-pdo-sqlite already, but as it is an SQLite extension > for v3 databases and isn't compatible with v2 databases, it > can't really be considered a drop-in replacement for the > older php-pecl-sqlite package. Well, in terms of > functionality, I guess it can. > > Two options : > 1) Try to build a newer php-sqlite from the main PHP5 tarball > 2) Build the PDO SQLite v3 module and move forward (me, not > impartial ;-) > > In both cases, the module should obsolete php-pecl-sqlite <= > 1.0.3 for smooth upgrades (rpm-wise). I personally prefer the > SQLite v3 approach since that's what'll be in FC4 Core, so > people will have the compatible tools to manipulate the > databases... but it will mean breakage for people using the > existing SQLite v2 module upon upgrade. > > Thoughts? It's half of-topic, sorry for that, but I believe it must be mentioned. I'm a 'perl-guy' as you might know, and I allready have the problem with FCDevel, that only sqlite3 is provided and no eg. compat-sqlite. There is - AFAIK - No DBD::SQLite3 available and so I had to build my own sqlite2 package (for the mentioned compatibility) and build DBD::SQLite2 against that. However, I guess I'm not the only person in the world who encountered this problem... So my thoughts on this are: * Make a compat-sqlite package within FC Extras (it's your decision if you only want to include sqlite2 or also want sqlite1 in this package) * Make a php-pecl-pdo-sqlite3 package * Compile php with sqlite v2 support This would make it possible for users to migrate from sqlite2 to sqlite3 (if they can). And all scripts that users might have running (php, perl, shell, python) should work fine. It's like the problems with db4. The only way to work around it was to provide a compat-db (and fix one package after the other to work with the latest db4). I guess without providing a compat-sqlite, we run into the same problem again, as soon as sqlite4 is out... My 2 cent... Best, Oliver From mattdm at mattdm.org Fri May 20 12:23:19 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 20 May 2005 08:23:19 -0400 Subject: Request for review: replacing cdiff with colordiff In-Reply-To: <1116570696.22482.58.camel@bobcat.mine.nu> References: <1116570696.22482.58.camel@bobcat.mine.nu> Message-ID: <20050520122319.GA13750@jadzia.bu.edu> On Fri, May 20, 2005 at 09:31:36AM +0300, Ville Skytt? wrote: > I intend to replace the current Extras cdiff package with colordiff, > http://colordiff.sf.net/ for FC4 and later. What are the advantages? Other than the perl dependency and the way it makes you pipe to less -R instead of doing that internally, I mean? :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 74 degrees Fahrenheit. From bugs.michael at gmx.net Fri May 20 12:34:26 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 20 May 2005 14:34:26 +0200 Subject: Request for review: scrub In-Reply-To: <1116589359.22593.15.camel@localhost.localdomain> References: <1116550437.22593.13.camel@localhost.localdomain> <20050520121448.18e8778f.bugs.michael@gmx.net> <1116589359.22593.15.camel@localhost.localdomain> Message-ID: <20050520143426.7c2fa5aa.bugs.michael@gmx.net> On Fri, 20 May 2005 06:42:38 -0500, Tom 'spot' Callaway wrote: > On Fri, 2005-05-20 at 12:14 +0200, Michael Schwendt wrote: > > "shred"? > > As far as I can tell, they're similar, but scrub has a randomized pass > (optional), and looks like it might be a bit more thorough. Included TODO file also mentions shred. Anyway, with the fixes suggested earlier, consider it approved. From mattdm at mattdm.org Fri May 20 12:37:55 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 20 May 2005 08:37:55 -0400 Subject: Request for review: replacing cdiff with colordiff In-Reply-To: <20050520113701.4774c66f@python2> References: <1116570696.22482.58.camel@bobcat.mine.nu> <20050520113701.4774c66f@python2> Message-ID: <20050520123755.GB13750@jadzia.bu.edu> On Fri, May 20, 2005 at 11:37:01AM +0200, Matthias Saou wrote: > - It says it's a wrapper to diff, but you don't require diffutils, is that > normal? It's not really a wrapper exactly -- it's just filter that adds colors. You could use it on patch files directly. This might be somewhat confusing, though -- it might not *hurt* to add this dependency. > - The obsoletes should contain the last known version or version-release of > cdiff, especially since you provide cdiff. Oh, I see that Ville has actually added a cdiff wrapper that acts exactly like cdiff, thus removing my earlier complaint. So in that case, it looks pretty good. I'm not so sure about the "plain=black" in the config file -- looks pretty ugly in my grey-on-black gnome terminal. Also, like the original cdiff, it doesn't handle wrapped lines properly in 'less -R' -- this might be a less bug, I'm not sure. Or maybe even a gnome-terminal one. Anyway, I suggest making that less -RS. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 74 degrees Fahrenheit. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri May 20 13:39:16 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 20 May 2005 15:39:16 +0200 Subject: Review/sponsor needed: sqlite2 In-Reply-To: <1116455745.7161.35.camel@ignacio.ignacio.lan> References: <1114241243.7784.17.camel@ignacio.ignacio.lan> <20050423212059.11deb9da.bugs.michael@gmx.net> <1114291713.7784.22.camel@ignacio.ignacio.lan> <20050424114913.1c723503.bugs.michael@gmx.net> <1116455745.7161.35.camel@ignacio.ignacio.lan> Message-ID: <20050520153916.1eee4da2@python2> Ignacio Vazquez-Abrams wrote : > Okay, this has dragged out long enough. There has been *plenty* of time > for the maintainers to speak up, and so far only one has, giving his > assent. If no one can think of a reason to *not* import the sqlite2 > package then I will proceed to do so this weekend. Yeah, just go ahead, it is a package that already was included :-) Please consider making the cosmetic changes from the attached patch, though, just for consistency's sake :-D I need that sqlite2 before I can rebuild kannel... so for me, the sooner, the better. Anyway, you can consider this a review and APPROVED message since I've gone though the spec quickly, rebuilt the package, and tested a successful rebuild of kannel against it. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.27_FC3 Load : 2.23 1.07 0.62 -------------- next part -------------- A non-text attachment was scrubbed... Name: sqlite2.spec.patch Type: application/octet-stream Size: 1196 bytes Desc: not available URL: From kaboom at oobleck.net Fri May 20 13:39:20 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Fri, 20 May 2005 09:39:20 -0400 (EDT) Subject: Request for review: scrub In-Reply-To: <1116589359.22593.15.camel@localhost.localdomain> References: <1116550437.22593.13.camel@localhost.localdomain> <20050520121448.18e8778f.bugs.michael@gmx.net> <1116589359.22593.15.camel@localhost.localdomain> Message-ID: On Fri, 20 May 2005, Tom 'spot' Callaway wrote: > On Fri, 2005-05-20 at 12:14 +0200, Michael Schwendt wrote: > > "shred"? > > As far as I can tell, they're similar, but scrub has a randomized pass > (optional), and looks like it might be a bit more thorough. The scrub TODO suggests that shred is more thorough.... I'm not sure that shred works on raw devices though? later, chris From tibbs at math.uh.edu Fri May 20 14:00:29 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 20 May 2005 09:00:29 -0500 Subject: Request for discussion: Package installation problem with running nscd In-Reply-To: <200505200725.j4K7PNjg027829@mail.linux-kernel.at> (Oliver Falk's message of "Fri, 20 May 2005 09:26:23 +0200") References: <200505200725.j4K7PNjg027829@mail.linux-kernel.at> Message-ID: >>>>> "OF" == Oliver Falk writes: OF> What do you think? Should adduser/addgroup check if nscd is OF> running and if so, run the nscd -i passwd or nscd -i group? Isn't nscd supposed to watch the source files and automatically flush if they change? Run nscd -g and see if it includes lines like: check /etc/passwd for changes check /etc/group for changes check /etc/hosts for changes This is supposedly governed by the check-files statement in /etc/nscd.conf. Of course this only works if you're keeping system accounts in the files and are only storing user accounts in LDAP. If you're storing everything in LDAP, I'm not sure how the system would boot. - J< From paul at city-fan.org Fri May 20 14:02:30 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 20 May 2005 15:02:30 +0100 Subject: New package: rblcheck In-Reply-To: <200505200744.j4K7iCWf032437@mail.linux-kernel.at> References: <200505200744.j4K7iCWf032437@mail.linux-kernel.at> Message-ID: <428DEDF6.30207@city-fan.org> Oliver Falk wrote: >>> Should be added: >>> -s xbl.spamhaus.org > > > OK. Added. Unfortunately the comment in the changelog says you added xml.spamhaus.org rather than xbl.spamhaus.org (actual rblcheckrc is OK). Running the standard test lookup of 127.0.0.2, I got: $ rbl 127.0.0.2 127.0.0.2 listed by sbl.spamhaus.org: http://www.spamhaus.org/SBL/sbl.lasso?query=SBL233 127.0.0.2 listed by xbl.spamhaus.org: http://www.spamhaus.org/query/bl?ip=127.0.0.2 127.0.0.2 listed by dnsbl.njabl.org: open relay -- 1008601823 127.0.0.2 listed by unconfirmed.dsbl.org: http://dsbl.org/listing?127.0.0.2 127.0.0.2 listed by multihop.dsbl.org: http://dsbl.org/listing?127.0.0.2 127.0.0.2 listed by list.dsbl.org: http://dsbl.org/listing?127.0.0.2 127.0.0.2 listed by opm.blitzed.org: Open proxy - see http://opm.blitzed.org/127.0.0.2 127.0.0.2 listed by relays.ordb.org: Listed by ORDB - for testing purposes only 127.0.0.2 listed by dul.dnsbl.sorbs.net: Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?127.0.0.2 127.0.0.2 listed by spam.dnsbl.sorbs.net: Spam Received See: http://www.dnsbl.sorbs.net/lookup.shtml?127.0.0.2 127.0.0.2 listed by cbl.abuseat.org: Blocked - see http://cbl.abuseat.org/lookup.cgi?ip=127.0.0.2 - OK 127.0.0.2 not listed by relay.ordb.org - relay.ordb.org is a typo for relays.ordb.org (already included) 127.0.0.2 not listed by blackhole.compu.net - blackhole.compu.net is a non-existent domain 127.0.0.2 not listed by blackholes.brainerd.net - no standard test entry but http://blackholes.brainerd.net/ appears to be alive 127.0.0.2 listed by blackholes.five-ten-sg.com 127.0.0.2 listed by blackholes.intersil.net: .spam test entry - direct spam source - OK 127.0.0.2 not listed by blackholes.wirehub.net - blackholes.wirehub.net is a non-existent domain 127.0.0.2 listed by block.blars.org - OK 127.0.0.2 not listed by bl.reynolds.net.au - please see http://bl.reynolds.net.au/ - you probably want to replace this with lists from http://dnsbl.net.au/types/ 127.0.0.2 listed by bl.spamcop.net: Blocked - see http://www.spamcop.net/bl.shtml?127.0.0.2 - OK 127.0.0.2 not listed by dynablock.wirehub.net - dynablock.wirehub.net is a non-existent domain 127.0.0.2 listed by flowgoaway.com: Keep away from sunlight, pets and small children. - OK 127.0.0.2 not listed by http.opm.blitzed.org - http.opm.blitzed.org is a non-existent domain 127.0.0.2 listed by korea.services.net: Blocked due to spam, see http://korea.services.net/blocked.phtml?addr=127.0.0.2 - OK 127.0.0.2 not listed by pm0-no-more.compu.net - pm0-no-more.compu.net is a non-existent domain 127.0.0.2 not listed by relays.visi.com - relays.visi.com is a non-existent domain 127.0.0.2 not listed by socks.opm.blitzed.org - socks.opm.blitzed.org is a non-existent domain 127.0.0.2 listed by spamguard.leadmon.net: Dial-Up/Cable/DSL IP Range - Use your providers SMTP Gateway 127.0.0.2 listed by spamsources.fabel.dk: Blocked. Contact spam at netcetera.dk Include this in the subject: 127.0.0.2 127.0.0.2 listed by work.drbl.croco.net 127.0.0.2 listed by relays.linux-kernel.at: Listed_at:dsbl,lkernAT,abuseat - OK >>>And for the folks who had a look at the package >>>allready/will have a look at >>>the package to approve it. Please note, that I just updated it at: > > http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPROVAL/rblcheck > > And once again updated. Release 6. You might want to add a DistTag to the release id - see: http://fedoraproject.org/wiki/DistTag BuildRoot: isn't the standard one advocated in the packaging guidelines (http://fedoraproject.org/wiki/PackagingGuidelines): %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Package builds OK as non-root user. rpmlint errors: rpmlint -iv rblcheck-1.5-6* I: rblcheck checking E: rblcheck description-line-too-long operated by the MAPS (http://www.mail-abuse.org/) and ORBL (http://www.orbl.org/) Your description lines must no exceed 80 characters. If a line is exceeding this number, cut it to fit in two lines. E: rblcheck non-standard-dir-perm /usr/share/doc/rblcheck-1.5/html/rblcheck 02755 A standard directory should have permission set to 0755. If you get this message, that means that you have a wrong directory permission in your package. E: rblcheck non-standard-dir-perm /usr/share/doc/rblcheck-1.5/html 02755 A standard directory should have permission set to 0755. If you get this message, that means that you have a wrong directory permission in your package. E: rblcheck non-standard-dir-perm /usr/share/doc/rblcheck-1.5/html/rblcheck/stylesheet-images 02755 A standard directory should have permission set to 0755. If you get this message, that means that you have a wrong directory permission in your package. The directory permission errors are probably due to my user account being in a SGID directory, and the installer copying the directory permissions. You can fix this by adding: %{_bindir}/find . -type d -exec chmod 755 {} \; after: %setup -q Paul. From oliver at linux-kernel.at Fri May 20 14:10:15 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 20 May 2005 16:10:15 +0200 Subject: Request for discussion: Package installation problem with running nscd In-Reply-To: Message-ID: <200505201409.j4KE9FSZ018626@mail.linux-kernel.at> Jason L Tibbitts III wrote: > >>>>> "OF" == Oliver Falk writes: > > OF> What do you think? Should adduser/addgroup check if nscd > is running > OF> and if so, run the nscd -i passwd or nscd -i group? > > Isn't nscd supposed to watch the source files and > automatically flush if they change? Run nscd -g and see if > it includes lines like: > > check /etc/passwd for changes > check /etc/group for changes > check /etc/hosts for changes That's what nscd -g | grep check shows, but it seems it doesn't work. Note, it doesn't always happen - but sometimes... > This is supposedly governed by the check-files statement in > /etc/nscd.conf. It's there: grep check-files /etc/nscd.conf | grep -v ^# check-files passwd yes check-files group yes check-files hosts yes > Of course this only works if you're keeping system accounts > in the files and are only storing user accounts in LDAP. That's the way my system is designed. All user accounts are in LDAP, but not the system users. Means user apache is - of course - not in LDAP, but in /etc/{passwd,group,shadow}. > If you're storing everything in LDAP, I'm not sure how the > system would boot. I'm not goin' to try that. :-) Best, Oliver From tibbs at math.uh.edu Fri May 20 14:12:26 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 20 May 2005 09:12:26 -0500 Subject: Wiki access for JasonTibbitts Message-ID: Could someone set me (JasonTibbitts) up with write access to http://www.fedoraproject.org/wiki/Extras_2fBugzillaAdmin ? Thanks, - J< From rc040203 at freenet.de Fri May 20 14:17:02 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 20 May 2005 16:17:02 +0200 Subject: Request for discussion: Package installation problem with running nscd In-Reply-To: <200505200725.j4K7PNjg027829@mail.linux-kernel.at> References: <200505200725.j4K7PNjg027829@mail.linux-kernel.at> Message-ID: <1116598622.27813.95.camel@mccallum.corsepiu.local> On Fri, 2005-05-20 at 09:26 +0200, Oliver Falk wrote: > Hi! > > I came along this problem a few times now and think it's a good idea to > throw it on the list for discussion. > > I have a fcdev system running at my site that runs with ldap/nscd. > > The problem I'm running into - some times - is: > * nscd is running and caches groups/passwd > * I try to install a package > * package does the usual groupadd -r >/dev/null 2>&1 or useradd > ... > * package' file list lists %attr(-, , ) or something > like that. > > But as nscd caches the passwd/group it thinks that or > doesn't exist and rpm tell's me: > > warning: group does not exist - using root Can you give an example for a package whose installation triggers this error message? Ralf From skvidal at phy.duke.edu Fri May 20 14:19:03 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 20 May 2005 10:19:03 -0400 Subject: Request for discussion: Package installation problem with running nscd In-Reply-To: <1116598622.27813.95.camel@mccallum.corsepiu.local> References: <200505200725.j4K7PNjg027829@mail.linux-kernel.at> <1116598622.27813.95.camel@mccallum.corsepiu.local> Message-ID: <1116598743.21227.5.camel@cutter> On Fri, 2005-05-20 at 16:17 +0200, Ralf Corsepius wrote: > On Fri, 2005-05-20 at 09:26 +0200, Oliver Falk wrote: > > Hi! > > > > I came along this problem a few times now and think it's a good idea to > > throw it on the list for discussion. > > > > I have a fcdev system running at my site that runs with ldap/nscd. > > > > The problem I'm running into - some times - is: > > * nscd is running and caches groups/passwd > > * I try to install a package > > * package does the usual groupadd -r >/dev/null 2>&1 or useradd > > ... > > * package' file list lists %attr(-, , ) or something > > like that. > > > > But as nscd caches the passwd/group it thinks that or > > doesn't exist and rpm tell's me: > > > > warning: group does not exist - using root > Can you give an example for a package whose installation triggers this > error message? > srpms report it all the time, of course. -sv From tibbs at math.uh.edu Fri May 20 14:25:41 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 20 May 2005 09:25:41 -0500 Subject: Request for discussion: Package installation problem with running nscd In-Reply-To: <200505201409.j4KE9FSZ018626@mail.linux-kernel.at> (Oliver Falk's message of "Fri, 20 May 2005 16:10:15 +0200") References: <200505201409.j4KE9FSZ018626@mail.linux-kernel.at> Message-ID: >>>>> "OF" == Oliver Falk writes: OF> That's what nscd -g | grep check shows, but it seems it doesn't OF> work. Note, it doesn't always happen - but sometimes... Bugzilla 134323? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134323 Seems to have stalled out; maybe you can add some more info. - J< From rc040203 at freenet.de Fri May 20 14:55:24 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 20 May 2005 16:55:24 +0200 Subject: Request for discussion: Package installation problem with running nscd In-Reply-To: <1116598743.21227.5.camel@cutter> References: <200505200725.j4K7PNjg027829@mail.linux-kernel.at> <1116598622.27813.95.camel@mccallum.corsepiu.local> <1116598743.21227.5.camel@cutter> Message-ID: <1116600924.27813.100.camel@mccallum.corsepiu.local> On Fri, 2005-05-20 at 10:19 -0400, seth vidal wrote: > On Fri, 2005-05-20 at 16:17 +0200, Ralf Corsepius wrote: > > On Fri, 2005-05-20 at 09:26 +0200, Oliver Falk wrote: > > > Hi! > > > > > > I came along this problem a few times now and think it's a good idea to > > > throw it on the list for discussion. > > > > > > I have a fcdev system running at my site that runs with ldap/nscd. > > > > > > The problem I'm running into - some times - is: > > > * nscd is running and caches groups/passwd > > > * I try to install a package > > > * package does the usual groupadd -r >/dev/null 2>&1 or useradd > > > ... > > > * package' file list lists %attr(-, , ) or something > > > like that. > > > > > > But as nscd caches the passwd/group it thinks that or > > > doesn't exist and rpm tell's me: > > > > > > warning: group does not exist - using root > > Can you give an example for a package whose installation triggers this > > error message? > > > > srpms report it all the time, of course. <*g*> Of cause, that's not what I meant :-) [1] Ralf [1] IMHO, that's a bug in rpm. From ville.skytta at iki.fi Fri May 20 15:01:57 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 20 May 2005 18:01:57 +0300 Subject: Request for discussion: Package installation problem with running nscd In-Reply-To: <200505200725.j4K7PNjg027829@mail.linux-kernel.at> References: <200505200725.j4K7PNjg027829@mail.linux-kernel.at> Message-ID: <1116601317.29220.12.camel@bobcat.mine.nu> On Fri, 2005-05-20 at 09:26 +0200, Oliver Falk wrote: > I have a fcdev system running at my site that runs with ldap/nscd. > > The problem I'm running into - some times - is: > * nscd is running and caches groups/passwd > * I try to install a package > * package does the usual groupadd -r >/dev/null 2>&1 or useradd > ... > * package' file list lists %attr(-, , ) or something > like that. > > But as nscd caches the passwd/group it thinks that or > doesn't exist and rpm tell's me: > > warning: group does not exist - using root Things should Just Work(tm). nscd in FC has been patched to prune the password, group and hosts caches when it receives a SIGHUP, and shadow-utils has been patched to HUP nscd on relevant operations. http://cvs.fedora.redhat.com/viewcvs/devel/glibc/glibc-fedora.patch?rev=.&view=auto http://cvs.fedora.redhat.com/viewcvs/devel/shadow-utils/shadow-4.0.3-nscd.patch?rev=.&view=auto There was a bug at FC2'ish time where the nscd pid file had moved so that the HUP never happened. But that was fixed last year... https://bugzilla.redhat.com/125421 From jfontain at free.fr Fri May 20 15:30:55 2005 From: jfontain at free.fr (jfontain at free.fr) Date: Fri, 20 May 2005 17:30:55 +0200 Subject: Review/sponsor needed: sqlite2 In-Reply-To: <20050520153916.1eee4da2@python2> References: <1114241243.7784.17.camel@ignacio.ignacio.lan> <20050423212059.11deb9da.bugs.michael@gmx.net> <1114291713.7784.22.camel@ignacio.ignacio.lan> <20050424114913.1c723503.bugs.michael@gmx.net> <1116455745.7161.35.camel@ignacio.ignacio.lan> <20050520153916.1eee4da2@python2> Message-ID: <1116603055.428e02af33099@imp4-q.free.fr> Quoting Matthias Saou : > Ignacio Vazquez-Abrams wrote : > > > Okay, this has dragged out long enough. There has been *plenty* of time > > for the maintainers to speak up, and so far only one has, giving his > > assent. If no one can think of a reason to *not* import the sqlite2 > > package then I will proceed to do so this weekend. > > Yeah, just go ahead, it is a package that already was included :-) > > Please consider making the cosmetic changes from the attached patch, > though, just for consistency's sake :-D > > I need that sqlite2 before I can rebuild kannel... so for me, the sooner, > the better. > > Anyway, you can consider this a review and APPROVED message since I've > gone though the spec quickly, rebuilt the package, and tested a successful > rebuild of kannel against it. Great! Thanks both. I think I'll use it ;-). -- Jean-Luc From ville.skytta at iki.fi Fri May 20 17:03:48 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 20 May 2005 20:03:48 +0300 Subject: Request for review: replacing cdiff with colordiff In-Reply-To: <20050520123755.GB13750@jadzia.bu.edu> References: <1116570696.22482.58.camel@bobcat.mine.nu> <20050520113701.4774c66f@python2> <20050520123755.GB13750@jadzia.bu.edu> Message-ID: <1116608628.29220.33.camel@bobcat.mine.nu> On Fri, 2005-05-20 at 08:37 -0400, Matthew Miller wrote: > On Fri, May 20, 2005 at 11:37:01AM +0200, Matthias Saou wrote: > > - It says it's a wrapper to diff, but you don't require diffutils, is that > > normal? > > It's not really a wrapper exactly -- it's just filter that adds colors. You > could use it on patch files directly. This might be somewhat confusing, > though -- it might not *hurt* to add this dependency. Ok, added. > > - The obsoletes should contain the last known version or version-release of > > cdiff, especially since you provide cdiff. > > Oh, I see that Ville has actually added a cdiff wrapper that acts exactly > like cdiff, thus removing my earlier complaint. Yes, that was mentioned in my initial message to this thread :) > So in that case, it looks pretty good. I'm not so sure about the > "plain=black" in the config file -- looks pretty ugly in my grey-on-black > gnome terminal. The most important thing about the config file is that default settings in it doesn't make things _invisible_ with the most "usual" color schemes. (Non-)ugliness is secondary, and because the default color scheme is black-on-white in Fedora, the default is geared towards such setups. See also the samples in the package's doc dir (there's one for dark backgrounds), and note that one can configure the colors exactly like one pleases in ~/.colordiffrc But if you come up with a better compromise than plain=black for the default config, I'm open to suggestions... > Also, like the original cdiff, it doesn't handle wrapped lines properly in > 'less -R' -- this might be a less bug, I'm not sure. Or maybe even a > gnome-terminal one. Anyway, I suggest making that less -RS. I think chopping lines with -S would be very much unexpected behaviour. Although colorization doesn't always work for wrapped lines, it _usually_ does just fine here (using Konsole, FWIW). Chopping the lines would avoid the colorization issue, but it would certainly _always_ hide parts of the information when long lines are present and cause the need to hit the right arrow which will certainly screw up the colorization. Revised package with the versioned obsoletes and added diffutils dep: http://cachalot.mine.nu/3/SRPMS.extras/colordiff-1.0.5-0.3.src.rpm Good enough for inclusion now? From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri May 20 17:20:42 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 20 May 2005 19:20:42 +0200 Subject: Request for review: replacing cdiff with colordiff In-Reply-To: <1116608628.29220.33.camel@bobcat.mine.nu> References: <1116570696.22482.58.camel@bobcat.mine.nu> <20050520113701.4774c66f@python2> <20050520123755.GB13750@jadzia.bu.edu> <1116608628.29220.33.camel@bobcat.mine.nu> Message-ID: <20050520192042.297d0edb@python2> Ville Skytt? wrote : > Revised package with the versioned obsoletes and added diffutils dep: > http://cachalot.mine.nu/3/SRPMS.extras/colordiff-1.0.5-0.3.src.rpm > Good enough for inclusion now? Approved by me, alright! Go for it :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.27_FC3 Load : 1.50 2.60 2.45 From buildsys at fedoraproject.org Fri May 20 17:26:38 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 20 May 2005 13:26:38 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050520172638.C93817F76@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 30 Coin2-2.4.1-1 Coin2-2.4.1-1.fc3 OpenEXR-1.2.2-3 OpenEXR-1.2.2-3.fc3 SoQt-1.2.0-6 SoQt-1.2.0-6.fc3 bittorrent-4.0.1-1 bittorrent-4.0.1-1.fc3 cfs-1.4.1-6 cfs-1.4.1-6.fc3 clamav-0.85.1-4 clamav-0.85.1-4.fc3 cvs2cl-2.59-1 fyre-1.0.0-7 fyre-1.0.0-7.fc3 graveman-0.3.12-1 hunt-1.5-4 hunt-1.5-4.fc3 kphone-4.1.1-1 kphone-4.1.1-1.fc3 leafpad-0.8.1-1.fc3 milter-greylist-1.6-3 milter-greylist-1.6-3.fc3 openct-0.6.5-1 perl-Net-Netmask-1.9012-1 python-cherrytemplate-1.0.0-2 python-cherrytemplate-1.0.0-2.fc3 rrdtool-1.0.49-4 rrdtool-1.0.49-4.fc3 unison-2.10.2-4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri May 20 18:02:50 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 20 May 2005 14:02:50 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050520180250.0321A7F76@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 87 Coin2-2.4.1-1 Coin2-2.4.1-1.fc4 OpenEXR-1.2.2-3 OpenEXR-1.2.2-3.fc4 SoQt-1.2.0-6 SoQt-1.2.0-6.fc4 bittorrent-4.0.1-1 bittorrent-4.0.1-1.fc4 bmp-0.9.7-7 cfs-1.4.1-6 cfs-1.4.1-6.fc4 clamav-0.85.1-4 clamav-0.85.1-4.fc4 cvs2cl-2.59-2 dbh-1.0.24-1.fc4 fontforge-0.0-2.20050502.fc4 fyre-1.0.0-8 fyre-1.0.0-8.fc4 gkrellm-hddtemp-0.2-0.4.beta gmime-2.1.9-5 gnome-applet-sensors-0.7.3-1 gnome-applet-sensors-0.7.3-1.fc4 gstreamer-python-0.8.1-6 gtk-xfce-engine-2.2.7-1.fc4 hunt-1.5-4 hunt-1.5-4.fc4 jikes-1.22-3 kid3-0.5-4 kphone-4.1.1-1 kphone-4.1.1-1.fc4 ksensors-0.7.3-3 leafpad-0.8.1-1.fc4 lft-2.31-2 libid3tag-0.15.1-3.b libosip2-2.2.0-3 libxfce4mcs-4.2.2-1.fc4 libxfce4util-4.2.2-1.fc4 libxfcegui4-4.2.2-1.fc4 liferea-0.9.2-1 mail-notification-1.1-3 milter-greylist-1.6-3 milter-greylist-1.6-3.fc4 nethack-falconseye-1.9.4-6.a netmask-2.3.7-4 openct-0.6.5-2 opensc-0.9.6-2 pam_mysql-0.50-6 pcsc-lite-1.2.0-12 pcsc-perl-1.3.1-6 perl-Config-General-2.28-2 perl-Net-Netmask-1.9012-2 perl-Razor-Agent-2.67-2 pptp-1.6.0-4 pptp-1.6.0-4.fc4 python-cherrytemplate-1.0.0-2 python-cherrytemplate-1.0.0-2.fc4 qtparted-0.4.4-3 rrdtool-1.0.49-5 rrdtool-1.0.49-5.fc4 rzip-2.0-1 rzip-2.0-1.fc4 sabayon-0.18-1 sqlite2-2.8.16-1 tpb-0.6.3-4 ucl-1.03-3 uim-0.4.6-3 upx-1.25-4 vpnc-0.3.3-1 xfcalendar-4.2.2-1.fc4 xfce-mcs-manager-4.2.2-1.fc4 xfce-mcs-plugins-4.2.2-1.fc4 xfce-utils-4.2.2-1.fc4 xfce4-appfinder-4.2.2-1.fc4 xfce4-icon-theme-4.2.2-1.fc4 xfce4-iconbox-4.2.2-1.fc4 xfce4-mixer-4.2.2-1.fc4 xfce4-panel-4.2.2-1.fc4 xfce4-session-4.2.2-1.fc4 xfce4-systray-4.2.2-1.fc4 xfce4-toys-4.2.2-2.fc4 xfce4-trigger-launcher-4.2.2-2.fc4 xfdesktop-4.2.2-1.fc4 xffm-4.2.2-1.fc4 xfprint-4.2.2-1.fc4 xfwm4-4.2.2-1.fc4 xfwm4-themes-4.2.2-1.fc4 xmms-modplug-2.05-3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From joost at cnoc.nl Fri May 20 18:02:00 2005 From: joost at cnoc.nl (Joost van der Sluis) Date: Fri, 20 May 2005 20:02:00 +0200 Subject: Questions for new package: Freepascal Message-ID: <1116612120.19118.13.camel@joost> Hi all, I'm willing to try to add Freepascal (www.freepascal.org). That's a pascal compiler, which is written in pascal - to compile it you need a binary version of the compiler already. So you always have to provide a binary executable, with which the compiler could be build. I'm don't know what your policies are around such things. (Are there any?) I could include the compiler-binaries in a second 'source-file' into the RPM. That should work. But I dont know if you guys would appreciate that. Any thoughts on this? Second - simple question: The compiler is GPL-2, the libraries (rtl,fcl) are modified LGPL. Can i put them into one RPM? Or should that be two RPM's? (If you download the source from www.freepascal.org, it's in one tar-file) Joost van der Sluis. From mattdm at mattdm.org Fri May 20 18:06:15 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 20 May 2005 14:06:15 -0400 Subject: Request for review: replacing cdiff with colordiff In-Reply-To: <1116608628.29220.33.camel@bobcat.mine.nu> References: <1116570696.22482.58.camel@bobcat.mine.nu> <20050520113701.4774c66f@python2> <20050520123755.GB13750@jadzia.bu.edu> <1116608628.29220.33.camel@bobcat.mine.nu> Message-ID: <20050520180615.GA28303@jadzia.bu.edu> On Fri, May 20, 2005 at 08:03:48PM +0300, Ville Skytt? wrote: > > Oh, I see that Ville has actually added a cdiff wrapper that acts exactly > > like cdiff, thus removing my earlier complaint. > Yes, that was mentioned in my initial message to this thread :) Yeah, I just misunderstood before I actually saw it. :) > The most important thing about the config file is that default settings > in it doesn't make things _invisible_ with the most "usual" color > schemes. (Non-)ugliness is secondary, and because the default color > scheme is black-on-white in Fedora, the default is geared towards such > setups. See also the samples in the package's doc dir (there's one for > dark backgrounds), and note that one can configure the colors exactly > like one pleases in ~/.colordiffrc I'll play around and see if I can come up with something more clever. It's too bad there's no way to automatically detect the background and switch on the fly. > I think chopping lines with -S would be very much unexpected behaviour. [...] > Although colorization doesn't always work for wrapped lines, it > _usually_ does just fine here (using Konsole, FWIW). Chopping the lines > would avoid the colorization issue, but it would certainly _always_ hide > parts of the information when long lines are present and cause the need > to hit the right arrow which will certainly screw up the colorization. Hmmm, yeah, the left and right scrolling with -S sure is br0ke. Okay, never mind then. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From skvidal at phy.duke.edu Fri May 20 18:08:41 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 20 May 2005 14:08:41 -0400 Subject: Fedora Extras development Package Build Report In-Reply-To: <20050520180250.0321A7F76@extras64.linux.duke.edu> References: <20050520180250.0321A7F76@extras64.linux.duke.edu> Message-ID: <1116612521.21227.24.camel@cutter> On Fri, 2005-05-20 at 14:02 -0400, buildsys at fedoraproject.org wrote: > Packages built and released for Fedora Extras development: 87 > > Coin2-2.4.1-1 > Coin2-2.4.1-1.fc4 I found out what's causing this and its ultimately non-harmful -but annoying. the srpm that is generated by the initial prep does not have the dist tag. The srpm generated by the build does. I'll be purging the first in the future. -sv From bugs.michael at gmx.net Fri May 20 18:18:50 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 20 May 2005 20:18:50 +0200 Subject: Wiki access for JasonTibbitts In-Reply-To: References: Message-ID: <20050520201850.37de7253.bugs.michael@gmx.net> On Fri, 20 May 2005 09:12:26 -0500, Jason L Tibbitts III wrote: > Could someone set me (JasonTibbitts) up with write access to > http://www.fedoraproject.org/wiki/Extras_2fBugzillaAdmin ? You're in EditGroup now, which is not limited to editing above page. Request like this preferably are GPG signed. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1319_FC4 loadavg: 1.82 2.07 1.16 From ivazquez at ivazquez.net Fri May 20 18:22:30 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 20 May 2005 14:22:30 -0400 Subject: Questions for new package: Freepascal In-Reply-To: <1116612120.19118.13.camel@joost> References: <1116612120.19118.13.camel@joost> Message-ID: <1116613350.7161.115.camel@ignacio.ignacio.lan> On Fri, 2005-05-20 at 20:02 +0200, Joost van der Sluis wrote: > I'm willing to try to add Freepascal (www.freepascal.org). That's a > pascal compiler, which is written in pascal - to compile it you need a > binary version of the compiler already. > > So you always have to provide a binary executable, with which the > compiler could be build. > > I'm don't know what your policies are around such things. (Are there > any?) > > I could include the compiler-binaries in a second 'source-file' into the > RPM. That should work. But I dont know if you guys would appreciate > that. > > Any thoughts on this? Ew. Maybe the binary can be included for the first iteration and then removed for the second. The various platforms are likely going to be an issue though. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From joost at cnoc.nl Fri May 20 18:29:40 2005 From: joost at cnoc.nl (Joost van der Sluis) Date: Fri, 20 May 2005 20:29:40 +0200 Subject: Questions for new package: Freepascal In-Reply-To: <1116613350.7161.115.camel@ignacio.ignacio.lan> References: <1116612120.19118.13.camel@joost> <1116613350.7161.115.camel@ignacio.ignacio.lan> Message-ID: <1116613780.19118.20.camel@joost> On Fri, 2005-05-20 at 14:22 -0400, Ignacio Vazquez-Abrams wrote: > On Fri, 2005-05-20 at 20:02 +0200, Joost van der Sluis wrote: > > I'm willing to try to add Freepascal (www.freepascal.org). That's a > > pascal compiler, which is written in pascal - to compile it you need a > > binary version of the compiler already. > > > > So you always have to provide a binary executable, with which the > > compiler could be build. > > > > I'm don't know what your policies are around such things. (Are there > > any?) > > > > I could include the compiler-binaries in a second 'source-file' into the > > RPM. That should work. But I dont know if you guys would appreciate > > that. > > > > Any thoughts on this? > > Ew. Maybe the binary can be included for the first iteration and then > removed for the second. The various platforms are likely going to be an > issue though. Do I really have to delete it? The makefiles are designed in such a way that you can specify a 'startcompiler'. So the first iteration is with the startcompiler, second and third iterations with the last compiled compiler. Binaries are available for i386, amd64/x86 64, powerpc and sparc. Detecting which binary should be used is easy. On which platforms must it be available? Joost van der Sluis. From ivazquez at ivazquez.net Fri May 20 18:40:03 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 20 May 2005 14:40:03 -0400 Subject: Questions for new package: Freepascal In-Reply-To: <1116613780.19118.20.camel@joost> References: <1116612120.19118.13.camel@joost> <1116613350.7161.115.camel@ignacio.ignacio.lan> <1116613780.19118.20.camel@joost> Message-ID: <1116614403.7161.119.camel@ignacio.ignacio.lan> On Fri, 2005-05-20 at 20:29 +0200, Joost van der Sluis wrote: > > Ew. Maybe the binary can be included for the first iteration and then > > removed for the second. The various platforms are likely going to be an > > issue though. > > [snip] > > Binaries are available for i386, amd64/x86 64, powerpc and sparc. > Detecting which binary should be used is easy. > > On which platforms must it be available? FC3 supports i386 and x86_64, whereas Rawhide/FC4 supports i386, x86_64, and ppc. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From paul at city-fan.org Fri May 20 18:49:12 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 20 May 2005 19:49:12 +0100 Subject: Questions for new package: Freepascal In-Reply-To: <1116612120.19118.13.camel@joost> References: <1116612120.19118.13.camel@joost> Message-ID: <1116614953.4628.179.camel@laurel.intra.city-fan.org> On Fri, 2005-05-20 at 20:02 +0200, Joost van der Sluis wrote: > Hi all, > > I'm willing to try to add Freepascal (www.freepascal.org). That's a > pascal compiler, which is written in pascal - to compile it you need a > binary version of the compiler already. > > So you always have to provide a binary executable, with which the > compiler could be build. > > I'm don't know what your policies are around such things. (Are there > any?) > > I could include the compiler-binaries in a second 'source-file' into the > RPM. That should work. But I dont know if you guys would appreciate > that. > > Any thoughts on this? You might want to look at the discussion of a similar issue for the ghc Haskell compiler discussed earlier: https://www.redhat.com/archives/fedora-extras-list/2005- May/msg00450.html Paul. -- Paul Howarth From pawsa at theochem.kth.se Fri May 20 18:55:45 2005 From: pawsa at theochem.kth.se (Pawel Salek) Date: Fri, 20 May 2005 18:55:45 +0000 Subject: New package: balsa Message-ID: <1116615345l.5333l.0l@salek.zapto.org> Package Name: balsa Description: Balsa is an GNOME e-mail reader. It supports local mailboxes, POP3, filters, encryption, signing and and makes an excellent, resource and bandwidth-friendly online IMAP client as well. Location: http://balsa.gnome.org/balsa-2.3.2-1.src.rpm http://balsa.gnome.org/balsa.spec md5sums: 69fabd2ade533b01bd964e78f7107a69 balsa-2.3.2-1.src.rpm 9dddaa597a1567067f5f2091cffbb064 balsa.spec srpm passes rpmlint test with on only one insignificant message related to gmime. The balsa package is basically the same as used to be included in Fedora Core 3, apart from the version upgrade. I would appreciate explicit approval anyway. I have already got a Fedora Extras CVS access. No legal or licencing issues are known. Thanks, Pawel -- Pawel Salek http://www.theochem.kth.se/~pawsa/ gpg keyid: 1024D/32718718 From nhorman at redhat.com Fri May 20 18:55:56 2005 From: nhorman at redhat.com (Neil Horman) Date: Fri, 20 May 2005 14:55:56 -0400 Subject: New package: iozone In-Reply-To: <20050520084210.5cd153da.mfleming@enlartenment.com> References: <20050519202418.GH14451@hmsendeavour.rdu.redhat.com> <20050520084210.5cd153da.mfleming@enlartenment.com> Message-ID: <20050520185556.GK19229@hmsendeavour.rdu.redhat.com> On Fri, May 20, 2005 at 08:42:10AM +1000, Michael Fleming wrote: Thanks for your detailed feeback Guys! I've incorporated all your changes into a new version of the package (with the exception of the Michael F.'s docdir comment, as it seems convention (at least on my fedora system) that docs go in /usr/share/doc/). New packages available at: http://people.redhat.com/nhorman/iozone-3-1.src.rpm http://people.redhat.com/nhorman/iozone.spec md5sums: 87db2c0a463454aa8bcc961ea3847074 iozone-3-1.src.rpm 0a310a4048521f958c10a824162e8cb2 iozone.spec Thanks! Neil -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman at redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mricon at gmail.com Fri May 20 19:05:12 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Fri, 20 May 2005 15:05:12 -0400 Subject: Audacity in Devel Message-ID: Hello, all: Audacity in devel doesn't work at all, since version 1.2.3 requires wxGTK to be built without gtk2 support (http://audacityteam.org/wiki/index.pl?BugsBugsBugs). I think we should disable audacity in devel until there are releases known to work with wxGTK2. Currently, anyone running it will see this wonderful screen: http://phy.duke.edu/~icon/sshots/Screenshot-Audacity.png Regards, -- Konstantin Ryabitsev Zlotniks, INC "? ????? ???? ?? ??? ???? ?????????????." --???? From tibbs at math.uh.edu Fri May 20 19:10:05 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 20 May 2005 14:10:05 -0500 Subject: Wiki access for JasonTibbitts In-Reply-To: <20050520201850.37de7253.bugs.michael@gmx.net> (Michael Schwendt's message of "Fri, 20 May 2005 20:18:50 +0200") References: <20050520201850.37de7253.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> Request like this preferably are GPG signed. Sorry; I went back through the last 1000 messages from this list to find the proper procedure for requesting access and the two requests I found were both unsigned. Now off to figure out how to make signing work under Gnus. - J< From robert at marcanoonline.com Fri May 20 19:22:09 2005 From: robert at marcanoonline.com (Robert Marcano) Date: Fri, 20 May 2005 15:22:09 -0400 Subject: New package: kanatest - Approval needed In-Reply-To: <1116538680.7161.82.camel@ignacio.ignacio.lan> References: <1115597334.20177.21.camel@localhost.localdomain> <1115640329.21984.22.camel@ignacio.ignacio.lan> <1115653760.11898.6.camel@tprobert.intranet.promca.com> <1115654009.20150.2.camel@localhost.localdomain> <1115656573.17797.2.camel@tprobert.intranet.promca.com> <1115919017.19974.4.camel@tprobert.intranet.promca.com> <1116537947.7161.75.camel@ignacio.ignacio.lan> <1116538315.21626.3.camel@tprobert.intranet.promca.com> <1116538680.7161.82.camel@ignacio.ignacio.lan> Message-ID: <1116616929.5128.2.camel@tprobert.intranet.promca.com> On Thu, 2005-05-19 at 17:38 -0400, Ignacio Vazquez-Abrams wrote: > On Thu, 2005-05-19 at 17:31 -0400, Robert Marcano wrote: ... > > > + URL and source are good > > > + File ownership is good > > > + Builds as non-root > > > > > > - Missing d-f-u in BR > > > > > > Fix that one last problem and I'll approve it. > > > Changed http://www.marcanoonline.com/downloads/fedora/package_submissions/kanatest/kanatest-0.3.6-3.src.rpm http://www.marcanoonline.com/downloads/fedora/package_submissions/kanatest/kanatest.spec I added "BuildRequires: desktop-file-utils >= 0.9" with a version check because I do not know if previous versions has all the tools needed. Is that ok? ________________________________________ Robert Marcano web: http://www.marcanoonline.com/ gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD From ivazquez at ivazquez.net Fri May 20 19:27:05 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 20 May 2005 15:27:05 -0400 Subject: New package: kanatest - Approval needed In-Reply-To: <1116616929.5128.2.camel@tprobert.intranet.promca.com> References: <1115597334.20177.21.camel@localhost.localdomain> <1115640329.21984.22.camel@ignacio.ignacio.lan> <1115653760.11898.6.camel@tprobert.intranet.promca.com> <1115654009.20150.2.camel@localhost.localdomain> <1115656573.17797.2.camel@tprobert.intranet.promca.com> <1115919017.19974.4.camel@tprobert.intranet.promca.com> <1116537947.7161.75.camel@ignacio.ignacio.lan> <1116538315.21626.3.camel@tprobert.intranet.promca.com> <1116538680.7161.82.camel@ignacio.ignacio.lan> <1116616929.5128.2.camel@tprobert.intranet.promca.com> Message-ID: <1116617225.7161.123.camel@ignacio.ignacio.lan> On Fri, 2005-05-20 at 15:22 -0400, Robert Marcano wrote: > On Thu, 2005-05-19 at 17:38 -0400, Ignacio Vazquez-Abrams wrote: > > On Thu, 2005-05-19 at 17:31 -0400, Robert Marcano wrote: > > ... > > > > > + URL and source are good > > > > + File ownership is good > > > > + Builds as non-root > > > > > > > > - Missing d-f-u in BR > > > > > > > > Fix that one last problem and I'll approve it. > > > > > > Changed > > http://www.marcanoonline.com/downloads/fedora/package_submissions/kanatest/kanatest-0.3.6-3.src.rpm > http://www.marcanoonline.com/downloads/fedora/package_submissions/kanatest/kanatest.spec > > I added "BuildRequires: desktop-file-utils >= 0.9" with a version check > because I do not know if previous versions has all the tools needed. Is > that ok? Works for me. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Fri May 20 19:34:38 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 20 May 2005 22:34:38 +0300 Subject: Audacity in Devel In-Reply-To: References: Message-ID: <1116617678.32359.0.camel@bobcat.mine.nu> On Fri, 2005-05-20 at 15:05 -0400, Konstantin Ryabitsev wrote: > Hello, all: > > Audacity in devel doesn't work at all, since version 1.2.3 requires > wxGTK to be built without gtk2 support > (http://audacityteam.org/wiki/index.pl?BugsBugsBugs). I think we > should disable audacity in devel until there are releases known to > work with wxGTK2. Why not just stick with the GTK1 version until then? See attachment. -------------- next part -------------- A non-text attachment was scrubbed... Name: audacity-gtk1.patch Type: text/x-patch Size: 636 bytes Desc: not available URL: From mattdm at mattdm.org Fri May 20 19:45:06 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 20 May 2005 15:45:06 -0400 Subject: Audacity in Devel In-Reply-To: References: Message-ID: <20050520194506.GA346@jadzia.bu.edu> On Fri, May 20, 2005 at 03:05:12PM -0400, Konstantin Ryabitsev wrote: > Audacity in devel doesn't work at all, since version 1.2.3 requires > wxGTK to be built without gtk2 support > (http://audacityteam.org/wiki/index.pl?BugsBugsBugs). I think we > should disable audacity in devel until there are releases known to > work with wxGTK2. FWIW, current cvs works with wxGTK2. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From bugs.michael at gmx.net Fri May 20 20:27:40 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 20 May 2005 22:27:40 +0200 Subject: New package: iozone In-Reply-To: <20050520185556.GK19229@hmsendeavour.rdu.redhat.com> References: <20050519202418.GH14451@hmsendeavour.rdu.redhat.com> <20050520084210.5cd153da.mfleming@enlartenment.com> <20050520185556.GK19229@hmsendeavour.rdu.redhat.com> Message-ID: <20050520222740.131f01f3.bugs.michael@gmx.net> On Fri, 20 May 2005 14:55:56 -0400, Neil Horman wrote: > On Fri, May 20, 2005 at 08:42:10AM +1000, Michael Fleming wrote: > > Thanks for your detailed feeback Guys! I've incorporated all your changes into a > new version of the package (with the exception of the Michael F.'s docdir > comment, as it seems convention (at least on my fedora system) that docs go in > /usr/share/doc/). Well, %_docdir/%name-%version to be precise, and files marked with %doc go into that directory. With regard to that, Michael's comment would make the spec a bit cleaner. But it's not a blocker criterion. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1319_FC4 loadavg: 1.23 1.15 1.18 From bugs.michael at gmx.net Fri May 20 20:45:53 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 20 May 2005 22:45:53 +0200 Subject: Audacity in Devel In-Reply-To: References: Message-ID: <20050520224553.64cb0c45.bugs.michael@gmx.net> On Fri, 20 May 2005 15:05:12 -0400, Konstantin Ryabitsev wrote: > Hello, all: > > Audacity in devel doesn't work at all, since version 1.2.3 requires > wxGTK to be built without gtk2 support > (http://audacityteam.org/wiki/index.pl?BugsBugsBugs). I think we > should disable audacity in devel until there are releases known to > work with wxGTK2. > > Currently, anyone running it will see this wonderful screen: > http://phy.duke.edu/~icon/sshots/Screenshot-Audacity.png That's something new and was not reproducible some weeks ago. May be even specific to FC4 Development or GCC4. When an older version of Audacity entered fedora.us, there were crashes with wxGTK2. But v1.2.3 built flawlessly with wxGTK2 some weeks ago. The version of wxGTK2 is still the same. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1319_FC4 loadavg: 1.16 1.23 1.19 From bugs.michael at gmx.net Fri May 20 20:49:52 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 20 May 2005 22:49:52 +0200 Subject: Audacity in Devel In-Reply-To: <20050520224553.64cb0c45.bugs.michael@gmx.net> References: <20050520224553.64cb0c45.bugs.michael@gmx.net> Message-ID: <20050520224952.19b9867f.bugs.michael@gmx.net> On Fri, 20 May 2005 22:45:53 +0200, Michael Schwendt wrote: > On Fri, 20 May 2005 15:05:12 -0400, Konstantin Ryabitsev wrote: > > > Hello, all: > > > > Audacity in devel doesn't work at all, since version 1.2.3 requires > > wxGTK to be built without gtk2 support > > (http://audacityteam.org/wiki/index.pl?BugsBugsBugs). I think we > > should disable audacity in devel until there are releases known to > > work with wxGTK2. > > > > Currently, anyone running it will see this wonderful screen: > > http://phy.duke.edu/~icon/sshots/Screenshot-Audacity.png > > That's something new and was not reproducible some weeks ago. May be > even specific to FC4 Development or GCC4. > > When an older version of Audacity entered fedora.us, there were crashes > with wxGTK2. But v1.2.3 built flawlessly with wxGTK2 some weeks ago. > The version of wxGTK2 is still the same. Actually, this is when I found myself persuaded that wxGTK2 works: %changelog * Sun Jan 30 2005 Michael Schwendt - 0:1.2.3-1.lvn.1 - Build with mp3 and wxGTK2 by default, - Make the libmp3lame perl substitution in %%prep more robust. - s/Fedora/Livna/ in desktop file. It's a surprise that it doesn't work with FC4 and the same wxGTK2. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1319_FC4 loadavg: 1.12 1.18 1.17 From mricon at gmail.com Fri May 20 21:18:15 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Fri, 20 May 2005 17:18:15 -0400 Subject: Audacity in Devel In-Reply-To: <20050520224553.64cb0c45.bugs.michael@gmx.net> References: <20050520224553.64cb0c45.bugs.michael@gmx.net> Message-ID: On 5/20/05, Michael Schwendt wrote: > That's something new and was not reproducible some weeks ago. May be > even specific to FC4 Development or GCC4. > > When an older version of Audacity entered fedora.us, there were crashes > with wxGTK2. But v1.2.3 built flawlessly with wxGTK2 some weeks ago. Did it actually run? Since it's a known issue that it doesn't run when wx is built with gtk2, it makes me wonder. -- Konstantin Ryabitsev Zlotniks, INC "? ????? ???? ?? ??? ???? ?????????????." --???? From bugs.michael at gmx.net Fri May 20 21:30:15 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 20 May 2005 23:30:15 +0200 Subject: New package: balsa In-Reply-To: <1116615345l.5333l.0l@salek.zapto.org> References: <1116615345l.5333l.0l@salek.zapto.org> Message-ID: <20050520233015.36af683d.bugs.michael@gmx.net> On Fri, 20 May 2005 18:55:45 +0000, Pawel Salek wrote: > Package Name: balsa > > Description: Balsa is an GNOME e-mail reader. It supports local > mailboxes, POP3, filters, encryption, signing and and makes an > excellent, resource and bandwidth-friendly online IMAP client as well. > > Location: > http://balsa.gnome.org/balsa-2.3.2-1.src.rpm > http://balsa.gnome.org/balsa.spec > > md5sums: > 69fabd2ade533b01bd964e78f7107a69 balsa-2.3.2-1.src.rpm > 9dddaa597a1567067f5f2091cffbb064 balsa.spec > > srpm passes rpmlint test with on only one insignificant message related > to gmime. The balsa package is basically the same as used to be > included in Fedora Core 3, apart from the version upgrade. ...and a ~7 KiB unified diff against the last version from Rawhide. ;) Haven't examined all those changes yet. > I would > appreciate explicit approval anyway. > > I have already got a Fedora Extras CVS access. > > No legal or licencing issues are known. Simple rpmbuild --rebuild failed here. Build requirements may be missing. At least: checking for glib-2.0 gtk+-2.0 >= 2.4 gmime-2.0 >= 2.1.9 libgnome-2.0 libgnomeui-2.0 gnome-vfs-2.0 gnome-vfs-module-2.0 libbonobo-2.0 libgnomeprint-2.2 >= 2.1.4 libgnomeprintui-2.2 >= 2.1.4 ... Package libgnomeprint-2.2 was not found in the pkg-config search path. Perhaps you should add the directory containing `libgnomeprint-2.2.pc' to the PKG_CONFIG_PATH environment variable No package 'libgnomeprint-2.2' found From bugs.michael at gmx.net Fri May 20 21:58:42 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 20 May 2005 23:58:42 +0200 Subject: Audacity in Devel In-Reply-To: References: <20050520224553.64cb0c45.bugs.michael@gmx.net> Message-ID: <20050520235842.136ace10.bugs.michael@gmx.net> On Fri, 20 May 2005 17:18:15 -0400, Konstantin Ryabitsev wrote: > > That's something new and was not reproducible some weeks ago. May be > > even specific to FC4 Development or GCC4. > > > > When an older version of Audacity entered fedora.us, there were crashes > > with wxGTK2. But v1.2.3 built flawlessly with wxGTK2 some weeks ago. > > Did it actually run? Since it's a known issue that it doesn't run when > wx is built with gtk2, it makes me wonder. Yes, of course, it did run (and the version I have installed in my FC3 account is built against wxGTK2 unlike the Fedora Extras FC3 release). Where do you see the information that "it doesn't run"? The Bugs page, which you've linked, only guesses that a reported crash might be caused by an unstable (!) wxGTK2 version. Anyway, the behaviour on FC4 is completely different and unexpected. Back to 1.2.3-2 (the last wxGTK1 based version from April 7th), no doubt about that. A wxGTK2 build with such symptoms is clearly a show-stopper. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1319_FC4 loadavg: 1.00 1.03 1.07 From tian at c-sait.net Fri May 20 22:29:41 2005 From: tian at c-sait.net (Christian Jodar) Date: Sat, 21 May 2005 00:29:41 +0200 Subject: New package: GCfilms In-Reply-To: <1116538729.7161.85.camel@ignacio.ignacio.lan> References: <20050516004934.234bfba2@tianbox> <1116538729.7161.85.camel@ignacio.ignacio.lan> Message-ID: <20050521002941.56d66167@tianbox> Thank you for your comments Ignacio. I changed everything as you suggested. Here are the links for new versions: .src.rpm can be found here: http://download.gna.org/gcfilms/fedora/3/gcfilms-5.0-4.src.rpm Spec file is here: http://cvs.gna.org/viewcvs/gcfilms/gcfilms/packages/fedora/gcfilms.spec?rev=HEAD&content-type=text/vnd.viewcvs-markup Generated RPM is there: http://download.gna.org/gcfilms/fedora/3/gcfilms-5.0-4.noarch.rpm Best regards, Christian Jodar. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From petersen at redhat.com Fri May 20 22:34:21 2005 From: petersen at redhat.com (Jens Petersen) Date: Sat, 21 May 2005 07:34:21 +0900 Subject: mach/mock and selinux In-Reply-To: <1116573108.17831.7.camel@cutter> References: <428354A9.5040501@ieee.org> <4283702D.7060208@ieee.org> <1115912711.8237.416.camel@mccallum.corsepiu.local> <42837DFB.9030304@ieee.org> <1115920551.29062.22.camel@weasel.laiskiainen.org> <1115921494.29062.28.camel@weasel.laiskiainen.org> <4283A0E0.2030203@ieee.org> <1115923168.13475.22.camel@cutter> <428A27D8.7020207@ieee.org> <1116359526.20274.75.camel@cutter> <428D88EE.5050302@redhat.com> <1116573108.17831.7.camel@cutter> Message-ID: <428E65ED.3070707@redhat.com> > On Fri, 2005-05-20 at 15:51 +0900, Jens Petersen wrote: >> >>http://linux.duke.edu/~skvidal/mock/ >> >>Thanks. I tried it and got to: >> >>$ mock -r fedora-3-i386-core mock-0.1-1.src.rpm :: >>Non-zero return value 127 on executing /usr/sbin/mock-helper chroot >>/var/lib/mock//fedora-3-i386-core/root /sbin/runuser - root -c >>"/usr/sbin/useradd -u 500 -d /builddir mockbuild" Ok I haven't tested, but apparently this is caused by using selinux, which presumably also explains the problem I was seeing earlier with mach. (Still with selinux being on by default since fc3, this really needs some attention.) Jens From ivazquez at ivazquez.net Fri May 20 22:51:09 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 20 May 2005 18:51:09 -0400 Subject: New package: GCfilms In-Reply-To: <20050521002941.56d66167@tianbox> References: <20050516004934.234bfba2@tianbox> <1116538729.7161.85.camel@ignacio.ignacio.lan> <20050521002941.56d66167@tianbox> Message-ID: <1116629469.7161.128.camel@ignacio.ignacio.lan> On Sat, 2005-05-21 at 00:29 +0200, Christian Jodar wrote: > Spec file is here: > > http://cvs.gna.org/viewcvs/gcfilms/gcfilms/packages/fedora/gcfilms.spec?rev=HEAD&content-type=text/vnd.viewcvs-markup > %{__install} -d %{buildroot}%{_defaultdocdir}/%{name}-%{version} > %{__install} README %{buildroot}%{_defaultdocdir}/%{name}-%{version} > %{__install} CHANGELOG %{buildroot}%{_defaultdocdir}/%{name}-%{version} You forgot to remove those 3 lines, which are now obsolete due to the changes you made wrt %doc. -- 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 tian at c-sait.net Fri May 20 23:18:44 2005 From: tian at c-sait.net (Christian Jodar) Date: Sat, 21 May 2005 01:18:44 +0200 Subject: New package: GCfilms In-Reply-To: <1116629469.7161.128.camel@ignacio.ignacio.lan> References: <20050516004934.234bfba2@tianbox> <1116538729.7161.85.camel@ignacio.ignacio.lan> <20050521002941.56d66167@tianbox> <1116629469.7161.128.camel@ignacio.ignacio.lan> Message-ID: <20050521011844.401fd74b@tianbox> > You forgot to remove those 3 lines, which are now obsolete due to the > changes you made wrt %doc. Oops, sorry about that. I fixed this problem. Thanks. New links: http://download.gna.org/gcfilms/fedora/3/gcfilms-5.0-5.src.rpm http://cvs.gna.org/viewcvs/gcfilms/gcfilms/packages/fedora/gcfilms.spec?rev=HEAD&content-type=text/vnd.viewcvs-markup http://download.gna.org/gcfilms/fedora/3/gcfilms-5.0-5.noarch.rpm Christian Jodar. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mfleming at enlartenment.com Fri May 20 23:38:48 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Sat, 21 May 2005 09:38:48 +1000 Subject: Approval sought: mlmmj & mod_security. In-Reply-To: References: <20050519035157.GB6565@enlartenment.com> Message-ID: <20050521093848.4bfe0f08.mfleming@enlartenment.com> On Thu, 19 May 2005 23:52:06 -0400 (EDT). Chris Ricker waffled thusly: > On Thu, 19 May 2005, Michael Fleming wrote: > > > Hi, > > > > I've had mlmmj (ezmlm-like mailing list manager) in CVS for a few weeks > > now with some comments regarding the spec and structure, but no reports > > of failures / blockers etc. It is still pending an approval (prior to my > > requesting a build) > > - Remove LICENSE from the %doc - it's exactly the same as COPYING Done - I might pass this comment upstream to Mads, it seems redundant to have two copies of the license in the tarball :-) > - You might want to change > > %dir %{_datadir}/mlmmj/ > %{_datadir}/mlmmj/* > > to > > %{_datadir}/mlmmj > > (does the same thing, but is simpler) Agreed. I probably did that when I first started packaging it to ensure the directory and it's contents are both owned by the package. The single entry is cleaner, mind you so changed it is. :-) > Other than those two, I don't see any blockers -- source matches > upstream, spec looks fine and meets all the guidelines, and rpmlint is > happy. Change the above and it's approved Done and checked into CVS. Thanks Chris. Cheers, Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From dwmw2 at infradead.org Sat May 21 00:11:19 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 21 May 2005 01:11:19 +0100 Subject: Audacity in Devel In-Reply-To: References: Message-ID: <1116634280.29037.94.camel@localhost.localdomain> On Fri, 2005-05-20 at 15:05 -0400, Konstantin Ryabitsev wrote: > Audacity in devel doesn't work at all, since version 1.2.3 requires > wxGTK to be built without gtk2 support > (http://audacityteam.org/wiki/index.pl?BugsBugsBugs). I think we > should disable audacity in devel until there are releases known to > work with wxGTK2. > > Currently, anyone running it will see this wonderful screen: > http://phy.duke.edu/~icon/sshots/Screenshot-Audacity.png I built it locally earlier, and it seems to work fine. http://david.woodhou.se/audacity.jpeg It also seems to have built in the build system OK: http://extras64.linux.duke.edu/failed/development/audacity/1.2.3-4/ppc/ The failure on x86_64 was just a spurious build system problem, so I just submitted another build. I don't think I've seen a result of the rebuild yet though. -- dwmw2 From skvidal at phy.duke.edu Sat May 21 00:44:16 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 20 May 2005 20:44:16 -0400 Subject: mach/mock and selinux In-Reply-To: <428E65ED.3070707@redhat.com> References: <428354A9.5040501@ieee.org> <4283702D.7060208@ieee.org> <1115912711.8237.416.camel@mccallum.corsepiu.local> <42837DFB.9030304@ieee.org> <1115920551.29062.22.camel@weasel.laiskiainen.org> <1115921494.29062.28.camel@weasel.laiskiainen.org> <4283A0E0.2030203@ieee.org> <1115923168.13475.22.camel@cutter> <428A27D8.7020207@ieee.org> <1116359526.20274.75.camel@cutter> <428D88EE.5050302@redhat.com> <1116573108.17831.7.camel@cutter> <428E65ED.3070707@redhat.com> Message-ID: <1116636256.24555.7.camel@cutter> On Sat, 2005-05-21 at 07:34 +0900, Jens Petersen wrote: > > On Fri, 2005-05-20 at 15:51 +0900, Jens Petersen wrote: > >> > >>http://linux.duke.edu/~skvidal/mock/ > >> > >>Thanks. I tried it and got to: > >> > >>$ mock -r fedora-3-i386-core mock-0.1-1.src.rpm > :: > >>Non-zero return value 127 on executing /usr/sbin/mock-helper chroot > >>/var/lib/mock//fedora-3-i386-core/root /sbin/runuser - root -c > >>"/usr/sbin/useradd -u 500 -d /builddir mockbuild" > > Ok I haven't tested, but apparently this is caused by using selinux, > which presumably also explains the problem I was seeing > earlier with mach. > > (Still with selinux being on by default since fc3, this really > needs some attention.) > I could make the first command mock runs be 'setenforce 0' :) but I think that would be wrong. essentially we need unlimited write access to the /var/lib/mock I'm betting all I need to do is figure out how to use the selinux extensions/parts that are there from mach-helper. just not this weekend! -sv From ivazquez at ivazquez.net Sat May 21 00:46:35 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 20 May 2005 20:46:35 -0400 Subject: New package: GCfilms In-Reply-To: <20050521011844.401fd74b@tianbox> References: <20050516004934.234bfba2@tianbox> <1116538729.7161.85.camel@ignacio.ignacio.lan> <20050521002941.56d66167@tianbox> <1116629469.7161.128.camel@ignacio.ignacio.lan> <20050521011844.401fd74b@tianbox> Message-ID: <1116636395.7161.136.camel@ignacio.ignacio.lan> On Sat, 2005-05-21 at 01:18 +0200, Christian Jodar wrote: > New links: > > http://download.gna.org/gcfilms/fedora/3/gcfilms-5.0-5.src.rpm > http://cvs.gna.org/viewcvs/gcfilms/gcfilms/packages/fedora/gcfilms.spec?rev=HEAD&content-type=text/vnd.viewcvs-markup > http://download.gna.org/gcfilms/fedora/3/gcfilms-5.0-5.noarch.rpm Looks fine to me. I'll go ahead and import it, and you go ahead and apply for CVS access. Don't forget to submit your CLA if you haven't already. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Sat May 21 03:33:55 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 21 May 2005 05:33:55 +0200 Subject: New package: SIMVoleon Message-ID: <1116646435.27282.6.camel@mccallum.corsepiu.local> Package: SIMVoleon Homepage: http://www.coin3d.org Description: SIM Voleon is a software development system, in the form of an add-on library to Coin3D. SIM Voleon complements Coin's capabilities for polygon-based rendering with visualization of volumetric data sets, by providing so-called "volume rendering" technology (http://dev.sim.no/SIM_Voleon) It is an add-on package to Coin2, which already is in FE. Location: ftp://packman.iu-bremen.de/fedora/SRPMS/SIMVoleon.spec ftp://packman.iu-bremen.de/fedora/SRPMS/SIMVoleon-2.0.1-1.fc3.src.rpm A predecessor of this package had passed fedora.us's QA (http://bugzilla.fedora.us/show_bug.cgi?id=1926), but I had withdrawn it. Ralf From pmatilai at laiskiainen.org Sat May 21 06:03:32 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 21 May 2005 09:03:32 +0300 (EEST) Subject: Audacity in Devel In-Reply-To: <20050520224553.64cb0c45.bugs.michael@gmx.net> References: <20050520224553.64cb0c45.bugs.michael@gmx.net> Message-ID: <1969.82.181.85.250.1116655412.squirrel@webmail.laiskiainen.org> Michael Schwendt said: > On Fri, 20 May 2005 15:05:12 -0400, Konstantin Ryabitsev wrote: > >> Hello, all: >> >> Audacity in devel doesn't work at all, since version 1.2.3 requires >> wxGTK to be built without gtk2 support >> (http://audacityteam.org/wiki/index.pl?BugsBugsBugs). I think we >> should disable audacity in devel until there are releases known to >> work with wxGTK2. >> >> Currently, anyone running it will see this wonderful screen: >> http://phy.duke.edu/~icon/sshots/Screenshot-Audacity.png > > That's something new and was not reproducible some weeks ago. May be > even specific to FC4 Development or GCC4. > > When an older version of Audacity entered fedora.us, there were crashes > with wxGTK2. But v1.2.3 built flawlessly with wxGTK2 some weeks ago. > The version of wxGTK2 is still the same. Yeah, I've been using local builds of Audacity 1.2.3 with mp3 and wxGTK2 support for a long time (on FC2 and FC3). It does occasionally crash after heavy use but so does GTK1 version under the same stress. Haven't tried on FC4-test, will try when I'm back to my box after the weekend. - Panu - From oliver at linux-kernel.at Sat May 21 07:28:09 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Sat, 21 May 2005 09:28:09 +0200 Subject: Request for discussion: Package installation problem withrunning nscd In-Reply-To: <1116598622.27813.95.camel@mccallum.corsepiu.local> Message-ID: <200505210727.j4L7Rg01029372@mail.linux-kernel.at> > On Fri, 2005-05-20 at 09:26 +0200, Oliver Falk wrote: > > Hi! > > > > I came along this problem a few times now and think it's a > > good idea > > to throw it on the list for discussion. > > > > I have a fcdev system running at my site that runs with ldap/nscd. > > > > The problem I'm running into - some times - is: > > * nscd is running and caches groups/passwd > > * I try to install a package > > * package does the usual groupadd -r >/dev/null 2>&1 or > > useradd ... > > * package' file list lists %attr(-, , ) or > > something like that. > > > > But as nscd caches the passwd/group it thinks that or > > doesn't exist and rpm tell's me: > > > > warning: group does not exist - using root > Can you give an example for a package whose installation > triggers this error message? PostgreSQL did, mach did, and a few others... Best, Oliver From oliver at linux-kernel.at Sat May 21 07:31:04 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Sat, 21 May 2005 09:31:04 +0200 Subject: Request for discussion: Package installation problem with running nscd In-Reply-To: Message-ID: <200505210730.j4L7Ua31029927@mail.linux-kernel.at> > >>>>> "OF" == Oliver Falk writes: > > OF> That's what nscd -g | grep check shows, but it seems it doesn't > OF> work. Note, it doesn't always happen - but sometimes... > > Bugzilla 134323? > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134323 > > Seems to have stalled out; maybe you can add some more info. Thanks for your investigation. It seems this is my bug. :-) I should have search it for myself. :-/ Best, Oliver From oliver at linux-kernel.at Sat May 21 07:42:57 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Sat, 21 May 2005 09:42:57 +0200 Subject: Request for discussion: Package installation problem withrunning nscd In-Reply-To: <1116601317.29220.12.camel@bobcat.mine.nu> Message-ID: <200505210742.j4L7gWLA032220@mail.linux-kernel.at> > > I have a fcdev system running at my site that runs with ldap/nscd. > > > > The problem I'm running into - some times - is: > > * nscd is running and caches groups/passwd > > * I try to install a package > > * package does the usual groupadd -r >/dev/null 2>&1 or > > useradd ... > > * package' file list lists %attr(-, , ) or > > something like that. > > > > But as nscd caches the passwd/group it thinks that or > > doesn't exist and rpm tell's me: > > > > warning: group does not exist - using root > > Things should Just Work(tm). > > nscd in FC has been patched to prune the password, group and > hosts caches when it receives a SIGHUP, and shadow-utils has > been patched to HUP nscd on relevant operations. > http://cvs.fedora.redhat.com/viewcvs/devel/glibc/glibc-fedora. > patch?rev=.&view=auto > http://cvs.fedora.redhat.com/viewcvs/devel/shadow-utils/shadow > -4.0.3-nscd.patch?rev=.&view=auto > > There was a bug at FC2'ish time where the nscd pid file had > moved so that the HUP never happened. But that was fixed last year... > https://bugzilla.redhat.com/125421 Hmmm. But why does it still happen? :-/// My versions: glibc-2.3.5-6 nscd-2.3.5-6 shadow-utils-4.0.7-7 Example: rpm -Uvh test-0.1-1.i386.rpm Preparing... ########################################### [100%] 1:test warning: group test does not exist - using root3%) ########################################### [100%] warning: group test does not exist - using root rpm -qp --scripts test-0.1-1.i386.rpm preinstall scriptlet (using /bin/sh): groupadd -r test >/dev/null 2>&1 postuninstall scriptlet (using /bin/sh): groupdel test >/dev/null 2>&1 I'm posting this to the above mentioned bugs as well... Thanks a lot, Oliver From oliver at linux-kernel.at Sat May 21 08:00:27 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Sat, 21 May 2005 10:00:27 +0200 Subject: New package: rblcheck In-Reply-To: <428DEDF6.30207@city-fan.org> Message-ID: <200505210800.j4L7xxGa003130@mail.linux-kernel.at> Paul Howarth wrote: [ ... ] > Unfortunately the comment in the changelog says you added > xml.spamhaus.org rather than xbl.spamhaus.org (actual > rblcheckrc is OK). Fixed. [ ... ] > 127.0.0.2 not listed by relay.ordb.org > > - relay.ordb.org is a typo for relays.ordb.org (already included) > > 127.0.0.2 not listed by blackhole.compu.net > > - blackhole.compu.net is a non-existent domain Removed. [ ... ] > 127.0.0.2 not listed by blackholes.wirehub.net > > - blackholes.wirehub.net is a non-existent domain Removed. [ ... ] > 127.0.0.2 not listed by bl.reynolds.net.au > > - please see http://bl.reynolds.net.au/ > - you probably want to replace this with lists from > http://dnsbl.net.au/types/ Removed. Added. t{1,2,3}.dnsbl.net.au [ ... ] > 127.0.0.2 not listed by dynablock.wirehub.net > > - dynablock.wirehub.net is a non-existent domain Removed. [ ... ] > 127.0.0.2 not listed by http.opm.blitzed.org > > - http.opm.blitzed.org is a non-existent domain Removed. [ ... ] > 127.0.0.2 not listed by pm0-no-more.compu.net > > - pm0-no-more.compu.net is a non-existent domain Removed. > 127.0.0.2 not listed by relays.visi.com > > - relays.visi.com is a non-existent domain > > 127.0.0.2 not listed by socks.opm.blitzed.org > > - socks.opm.blitzed.org is a non-existent domain Removed. [ ... ] [ ... ] > http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPRO VAL/rblcheck > > > > And once again updated. Release 6. http://t.linux-kernel.at/s.pl?4a (shortlink) Next run: Rel 7. > You might want to add a DistTag to the release id - see: > http://fedoraproject.org/wiki/DistTag I wanted to add it as soon as it has been approven, but OK I added it now. > BuildRoot: isn't the standard one advocated in the packaging > guidelines > (http://fedoraproject.org/wiki/PackagingGuidelines): > %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Fixed. > Package builds OK as non-root user. > > rpmlint errors: > > rpmlint -iv rblcheck-1.5-6* [ ... ] > The directory permission errors are probably due to my user > account being in a SGID directory, and the installer copying > the directory permissions. You can fix this by adding: > > %{_bindir}/find . -type d -exec chmod 755 {} \; [ ... ] Didn't add this as my linting doesn't mention directory permission problems. [oliver at wasser rblcheck]$ make lint Wrote: /home/oliver/cvs/rpms/rblcheck/rblcheck-1.5-7.src.rpm rpmlint rblcheck-1.5-7.src.rpm E: rblcheck no-signature You may have a look at it again... Best, Oliver From nicolas.mailhot at laposte.net Sat May 21 09:00:13 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 21 May 2005 11:00:13 +0200 Subject: arc & gcc4 -> please review build fix Message-ID: <428EF89D.4090605@laposte.net> Hi, Anyone with more curent C knowledge than me care to review the arc gcc4 fix in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156225 ? Basically pristine source build fails with : marc.c:309: error: incompatible implicit declaration of function 'makefnam' marc.c:51: error: previous implicit declaration of 'makefnam' was here and we fix the build with : diff -uNr arc-5.21j.orig/marc.c arc-5.21j/marc.c --- arc-5.21j.orig/marc.c 2003-10-31 03:22:36.000000000 +0100 +++ arc-5.21j/marc.c 2005-05-21 10:40:22.000000000 +0200 @@ -48,7 +48,6 @@ int nargs; /* number of arguments */ char *arg[]; /* pointers to arguments */ { - char *makefnam(); /* filename fixup routine */ char *envfind(); #if !_MTS char *arctemp2, *mktemp(); /* temp file stuff */ (build fix only - runtime not tested) Since arc was originally imported in fedora.us for amavisd-new, and amavis can use nomarch instead, we can just dump arc and only keep nomarch. nomarch is already in extras and builds as-is with gcc4. Anyway if the fix is right we can keep arc a little longer - someone may care about it. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From bugs.michael at gmx.net Sat May 21 10:02:00 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 21 May 2005 12:02:00 +0200 Subject: arc & gcc4 -> please review build fix In-Reply-To: <428EF89D.4090605@laposte.net> References: <428EF89D.4090605@laposte.net> Message-ID: <20050521120200.3d095691.bugs.michael@gmx.net> On Sat, 21 May 2005 11:00:13 +0200, Nicolas Mailhot wrote: > Hi, > > Anyone with more curent C knowledge than me care to review the arc gcc4 > fix in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156225 ? > > Basically pristine source build fails with : > > marc.c:309: error: incompatible implicit declaration of > function 'makefnam' > marc.c:51: error: previous implicit declaration of > 'makefnam' was here > > and we fix the build with : > > diff -uNr arc-5.21j.orig/marc.c arc-5.21j/marc.c > --- arc-5.21j.orig/marc.c 2003-10-31 03:22:36.000000000 +0100 > +++ arc-5.21j/marc.c 2005-05-21 10:40:22.000000000 +0200 > @@ -48,7 +48,6 @@ > int nargs; /* number of arguments */ > char *arg[]; /* pointers to arguments */ > { > - char *makefnam(); /* filename fixup routine */ > char *envfind(); > #if !_MTS > char *arctemp2, *mktemp(); /* temp file stuff */ > > (build fix only - runtime not tested) Yes, it is right to drop all those declarations, in particular as makefnam takes arguments of (char*,char*,char*). It's defined in arcmisc.c. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1323_FC4 loadavg: 1.15 1.18 1.05 From nicolas.mailhot at laposte.net Sat May 21 10:15:23 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 21 May 2005 12:15:23 +0200 Subject: arc & gcc4 -> please review build fix In-Reply-To: <20050521120200.3d095691.bugs.michael@gmx.net> References: <428EF89D.4090605@laposte.net> <20050521120200.3d095691.bugs.michael@gmx.net> Message-ID: <428F0A3B.2070003@laposte.net> Michael Schwendt a ?crit : > Yes, it is right to drop all those declarations, in particular as > makefnam takes arguments of (char*,char*,char*). It's defined in > arcmisc.c. Ok, now I have only to figure how to push this in the CVS I guess -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From nicolas.mailhot at laposte.net Sat May 21 10:59:07 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 21 May 2005 12:59:07 +0200 Subject: Updated package : perl-Convert-UUlib-1.051 Message-ID: <428F147B.7000708@laposte.net> This is an update (mainly version bump) of the perl-Convert-UUlib I contributed to fedora.us. No big spec changes. I'm listed as the perl-Convert-UUlib owner in bugzilla but since I'v only just completed the https://admin.fedora.redhat.com/accounts/ I haven't got the faintest idea of what's still required before this can hit the Extras CVS (reviews, sponsors, etc) Source: http://mapage.noos.fr/nmailhot/fedora/perl-Convert-UUlib-1.051-1.src.rpm Packages (built on Fedora Devel): http://mapage.noos.fr/nmailhot/fedora/perl-Convert-UUlib-1.051-1.i386.rpm http://mapage.noos.fr/nmailhot/fedora/perl-Convert-UUlib-debuginfo-1.051-1.i386.rpm Sums: http://mapage.noos.fr/nmailhot/fedora/perl-Convert-UUlib-md5sums.asc http://mapage.noos.fr/nmailhot/fedora/perl-Convert-UUlib-sha1sums.asc Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From enrico.scholz at informatik.tu-chemnitz.de Sat May 21 07:41:35 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 21 May 2005 09:41:35 +0200 Subject: mach/mock and selinux In-Reply-To: <428E65ED.3070707@redhat.com> (Jens Petersen's message of "Sat, 21 May 2005 07:34:21 +0900") References: <428354A9.5040501@ieee.org> <4283702D.7060208@ieee.org> <1115912711.8237.416.camel@mccallum.corsepiu.local> <42837DFB.9030304@ieee.org> <1115920551.29062.22.camel@weasel.laiskiainen.org> <1115921494.29062.28.camel@weasel.laiskiainen.org> <4283A0E0.2030203@ieee.org> <1115923168.13475.22.camel@cutter> <428A27D8.7020207@ieee.org> <1116359526.20274.75.camel@cutter> <428D88EE.5050302@redhat.com> <1116573108.17831.7.camel@cutter> <428E65ED.3070707@redhat.com> Message-ID: <87is1dgh5c.fsf@kosh.bigo.ensc.de> petersen at redhat.com (Jens Petersen) writes: >>>Thanks. I tried it and got to: >>> >>>$ mock -r fedora-3-i386-core mock-0.1-1.src.rpm > :: >>> Non-zero return value 127 on executing /usr/sbin/mock-helper chroot >>> /var/lib/mock//fedora-3-i386-core/root /sbin/runuser - root -c >>>"/usr/sbin/useradd -u 500 -d /builddir mockbuild" > > Ok I haven't tested, but apparently this is caused by using selinux, > which presumably also explains the problem I was seeing earlier with > mach. SELinux was never designed to work with or in chroot environments, and unless somebody implements another kernel API, this will not change. So best would be, to disable SELinux completely at system start. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Sat May 21 11:11:55 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 21 May 2005 13:11:55 +0200 Subject: Updated package : arc-5.21j (gcc4 fix) Message-ID: <428F177B.2080409@laposte.net> This is a gcc4 build update of the arc package I contributed to fedora.us. No big spec changes. I'm listed as the arc package owner in bugzilla but since I've only just completed the https://admin.fedora.redhat.com/accounts/ I haven't got the faintest idea of what's still required before this can hit the Extras CVS (reviews, sponsors, etc) Also I've no longuer any need for arc - nomarch (already in extras) has the same purpose, and its codebase seems nicer. I wouldn't vouch for the security of arc - it's old and the sf.net patch queue shows one buffer overflow fix no one ever bothered to review. Source: http://mapage.noos.fr/nmailhot/fedora/arc-5.21j-3.src.rpm Packages (built on Fedora Devel): http://mapage.noos.fr/nmailhot/fedora/arc-5.21j-3.i386.rpm http://mapage.noos.fr/nmailhot/fedora/arc-debuginfo-5.21j-3.i386.rpm Sums: http://mapage.noos.fr/nmailhot/fedora/arc-md5sums.asc http://mapage.noos.fr/nmailhot/fedora/arc-sha1sums.asc Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From oliver at linux-kernel.at Sat May 21 11:45:26 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Sat, 21 May 2005 13:45:26 +0200 Subject: mach/mock and selinux In-Reply-To: <87is1dgh5c.fsf@kosh.bigo.ensc.de> Message-ID: <200505211145.j4LBj4x7012712@mail.linux-kernel.at> > petersen at redhat.com (Jens Petersen) writes: > > >>>Thanks. I tried it and got to: > >>> > >>>$ mock -r fedora-3-i386-core mock-0.1-1.src.rpm > > :: > >>> Non-zero return value 127 on executing > >>>/usr/sbin/mock-helper chroot > >>>/var/lib/mock//fedora-3-i386-core/root /sbin/runuser - root -c > >>>"/usr/sbin/useradd -u 500 -d /builddir mockbuild" > > > > Ok I haven't tested, but apparently this is caused by using > > selinux, > > which presumably also explains the problem I was seeing > > earlier with mach. > > SELinux was never designed to work with or in chroot > environments, and unless somebody implements another kernel > API, this will not change. So best would be, to disable > SELinux completely at system start. Correct, Enrico, but wouldn't make sense to give user mock all (selinux) permission for /var/lib/mock!? Just in case someone wants to have selinux enabled, but also wants to use mock :-) Hmmm. Or is this caused by useradd that want's to write /var/lib/mock/*/*/etc/{passwd,group,shadow}? If so it might be harder to find a good solution. I don't think that allowing useradd to write to /var/lib/mock/*/* is a good idea... However, just my 2 cent. As I'm not a selinux-fan and have it disabled on my dev-boxes, I don't mind. :-) Best, Oliver From dwmw2 at infradead.org Sat May 21 11:49:39 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 21 May 2005 12:49:39 +0100 Subject: Audacity in Devel In-Reply-To: <1116634280.29037.94.camel@localhost.localdomain> References: <1116634280.29037.94.camel@localhost.localdomain> Message-ID: <1116676180.29037.117.camel@localhost.localdomain> On Sat, 2005-05-21 at 01:11 +0100, David Woodhouse wrote: > The failure on x86_64 was just a spurious build system problem, so I > just submitted another build. I don't think I've seen a result of the > rebuild yet though. Hm. The build system was ignoring the second and subsequent requests for the same release, even though the original build had failed. That's different to the internal build system, and it's not really an improvement. Seth -- in your copious spare time (tm) is there any chance you could change it to disallow repeated builds only after the given n-v-r has _succeeded_? -- dwmw2 From mfleming at enlartenment.com Sat May 21 12:21:48 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Sat, 21 May 2005 22:21:48 +1000 Subject: Approval sought: mlmmj & mod_security. In-Reply-To: <20050521093848.4bfe0f08.mfleming@enlartenment.com> References: <20050519035157.GB6565@enlartenment.com> <20050521093848.4bfe0f08.mfleming@enlartenment.com> Message-ID: <20050521222148.6b90cb1d.mfleming@enlartenment.com> On Sat, 21 May 2005 09:38:48 +1000. Michael Fleming waffled thusly: > On Thu, 19 May 2005 23:52:06 -0400 (EDT). Chris Ricker waffled thusly: > > > On Thu, 19 May 2005, Michael Fleming wrote: > > > > > Hi, > > > > > > I've had mlmmj (ezmlm-like mailing list manager) in CVS for a few > > > weeks now with some comments regarding the spec and structure, but no > > > reports of failures / blockers etc. It is still pending an approval > > > (prior to my requesting a build) > Agreed. I probably did that when I first started packaging it to ensure > the directory and it's contents are both owned by the package. The single > entry is cleaner, mind you so changed it is. :-) > > > Other than those two, I don't see any blockers -- source matches > > upstream, spec looks fine and meets all the guidelines, and rpmlint is > > happy. Change the above and it's approved > > Done and checked into CVS. Thanks Chris. Now that Chris has been kind enough to approve the package (Chris, do you send the approve or shall I?) I'm going to need Wiki edit access to the following (user MichaelFleming): http://www.fedoraproject.org/wiki/Extras_2fCVSSyncNeeded (I'd like to offer an FC-3 branch/build) http://www.fedoraproject.org/wiki/Extras_2fBugzillaAdmin (The bug reports have got to go somewhere ;-)) > Cheers, > Michael. Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From nhorman at redhat.com Sat May 21 13:15:12 2005 From: nhorman at redhat.com (Neil Horman) Date: Sat, 21 May 2005 09:15:12 -0400 Subject: New package: iozone In-Reply-To: <20050520222740.131f01f3.bugs.michael@gmx.net> References: <20050519202418.GH14451@hmsendeavour.rdu.redhat.com> <20050520084210.5cd153da.mfleming@enlartenment.com> <20050520185556.GK19229@hmsendeavour.rdu.redhat.com> <20050520222740.131f01f3.bugs.michael@gmx.net> Message-ID: <20050521131512.GB22489@hmsendeavour.rdu.redhat.com> On Fri, May 20, 2005 at 10:27:40PM +0200, Michael Schwendt wrote: > On Fri, 20 May 2005 14:55:56 -0400, Neil Horman wrote: > > > On Fri, May 20, 2005 at 08:42:10AM +1000, Michael Fleming wrote: > > > > Thanks for your detailed feeback Guys! I've incorporated all your changes into a > > new version of the package (with the exception of the Michael F.'s docdir > > comment, as it seems convention (at least on my fedora system) that docs go in > > /usr/share/doc/). > > Well, %_docdir/%name-%version to be precise, and files marked with %doc go > into that directory. With regard to that, Michael's comment would make the > spec a bit cleaner. But it's not a blocker criterion. > Good point. I missed that. I'll fix that up and repost. Thanks! Neil > -- > Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1319_FC4 > loadavg: 1.23 1.15 1.18 > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman at redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ From enrico.scholz at informatik.tu-chemnitz.de Sat May 21 14:31:55 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 21 May 2005 16:31:55 +0200 Subject: mach/mock and selinux In-Reply-To: <200505211145.j4LBj4x7012712@mail.linux-kernel.at> (Oliver Falk's message of "Sat, 21 May 2005 13:45:26 +0200") References: <87is1dgh5c.fsf@kosh.bigo.ensc.de> <200505211145.j4LBj4x7012712@mail.linux-kernel.at> Message-ID: <87ekc0hcpw.fsf@kosh.bigo.ensc.de> oliver at linux-kernel.at ("Oliver Falk") writes: >> >>>$ mock -r fedora-3-i386-core mock-0.1-1.src.rpm >> > :: >> >>> Non-zero return value 127 on executing >> >>>/usr/sbin/mock-helper chroot >> >>>/var/lib/mock//fedora-3-i386-core/root /sbin/runuser - root -c >> >>>"/usr/sbin/useradd -u 500 -d /builddir mockbuild" >> > >> > Ok I haven't tested, but apparently this is caused by using selinux, >> > which presumably also explains the problem I was seeing earlier with >> > mach. >> >> SELinux was never designed to work with or in chroot environments, >> and unless somebody implements another kernel API, this will not >> change. So best would be, to disable SELinux completely at system >> start. > > Correct, Enrico, but wouldn't make sense to give user mock all (selinux) > permission for /var/lib/mock!? Probably not. SELinux requires the /proc and /selinux filesystems to communicate with the kernel; it does not use the common syscall interface. This makes e.g. the 'rpm --root' commands nearly impossible: script execution would require complicated actions in the selinux lib (getting fd of /proc/self/attr/... before the chroot(2) (perhaps of files in /selinux/... also) and using it after the chroot(2)). But the SELinux lib was not designed for it; most functions are doing 'fopen("/proc/...")' themself and can not used cached fd's or other SELinux information. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145770 also. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Sat May 21 16:20:45 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 21 May 2005 18:20:45 +0200 Subject: New package : dejavu-fonts-1.9 Message-ID: <428F5FDD.1080308@laposte.net> The DejaVu fonts are derivatives of the well-known Bitstream Vera fonts. The Bitstream license forbids making modifications to Vera and keep the Vera name, so all the Vera forks changed it. This one seems the most active/open. It's main purpose is to complete the original Vera with new glyphs, and it's been actively merging smaller forks for some time. The spec is straightforward - it's basically the FC Vera spec with minimal twists and little automation. Review and sponsor needed. Source: http://mapage.noos.fr/nmailhot/fedora/dejavu-fonts-1.9-2.src.rpm Packages (built on Fedora Devel): http://mapage.noos.fr/nmailhot/fedora/dejavu-fonts-1.9-2.noarch.rpm Sums: http://mapage.noos.fr/nmailhot/fedora/dejavu-fonts-md5sums.asc http://mapage.noos.fr/nmailhot/fedora/dejavu-fonts-sha1sums.asc Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From toshio at tiki-lounge.com Sat May 21 16:30:37 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sat, 21 May 2005 09:30:37 -0700 Subject: Extras Rebuild? Message-ID: <20050521093037.A12984@tiki-lounge.com> Any news on when a mass rebuild of Extras packages might be expected? I've just installed a new machine and found that some of the packages are straight imports from the FC3 tree (on x86_64). Sooner is better than later so people can start looking at why these things are failing. -Toshio PS: Thought for FC5 -- Could we have automated rebuilds for Extras after each test release? For community members to contribute to fixing packages we need to be able to generate lists of packages which are failing. Since development means people are using eats-my-babies rawhide it would make more sense to have the development packages be auto-built so breakage can be discovered in the development stage. From tian at c-sait.net Sat May 21 17:10:25 2005 From: tian at c-sait.net (Christian Jodar) Date: Sat, 21 May 2005 19:10:25 +0200 Subject: New package: GCfilms In-Reply-To: <1116636395.7161.136.camel@ignacio.ignacio.lan> References: <20050516004934.234bfba2@tianbox> <1116538729.7161.85.camel@ignacio.ignacio.lan> <20050521002941.56d66167@tianbox> <1116629469.7161.128.camel@ignacio.ignacio.lan> <20050521011844.401fd74b@tianbox> <1116636395.7161.136.camel@ignacio.ignacio.lan> Message-ID: <20050521191025.62de2e9e@tianbox> > Looks fine to me. I'll go ahead and import it Thanks a lot. > and you go ahead and apply for CVS access. It seems that someone already did that. Status shown is "In progress". > Don't forget to submit your CLA if you haven't > already. Already done (I am member of cla_done group). Do I need to do something else for the moment? I will read all of the documentation that is on the Wiki in the meantime. Christian Jodar. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Sat May 21 17:13:13 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 21 May 2005 20:13:13 +0300 Subject: Extras Rebuild? In-Reply-To: <20050521093037.A12984@tiki-lounge.com> References: <20050521093037.A12984@tiki-lounge.com> Message-ID: <1116695593.32359.68.camel@bobcat.mine.nu> On Sat, 2005-05-21 at 09:30 -0700, Toshio Kuratomi wrote: > Any news on when a mass rebuild of Extras packages might be expected? AFAICT, there's not going to be one, packagers are supposed to take care of rebuilds themselves by requesting them as needed. > I've > just installed a new machine and found that some of the packages are > straight imports from the FC3 tree (on x86_64). --> bugzilla.redhat.com at least for all affected non-noarch packages. From bugs.michael at gmx.net Sat May 21 17:36:40 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 21 May 2005 19:36:40 +0200 Subject: Updated package : arc-5.21j (gcc4 fix) In-Reply-To: <428F177B.2080409@laposte.net> References: <428F177B.2080409@laposte.net> Message-ID: <20050521193640.5e46b1e3.bugs.michael@gmx.net> On Sat, 21 May 2005 13:11:55 +0200, Nicolas Mailhot wrote: > This is a gcc4 build update of the arc package I contributed to > fedora.us. No big spec changes. > > I'm listed as the arc package owner in bugzilla but since I've only just > completed the https://admin.fedora.redhat.com/accounts/ I haven't got > the faintest idea of what's still required before this can hit the > Extras CVS (reviews, sponsors, etc) For the CVS account you need a sponsor. Sponsors are informed about new account requests. For the update in CVS, you need no review. Surely somebody could import your changes before your get CVS access. But you can as well wait and use these updates for trying out the Fedora Extras CVS framework yourself. > Also I've no longuer any need for arc - nomarch (already in extras) has > the same purpose, and its codebase seems nicer. I wouldn't vouch for the > security of arc - it's old and the sf.net patch queue shows one buffer > overflow fix no one ever bothered to review. Yeah, we should really start collecting such packages somewhere, too, and declare them "deprecated", so they could be removed in the future. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1323_FC4 loadavg: 1.11 1.03 1.01 From bugs.michael at gmx.net Sat May 21 17:36:44 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 21 May 2005 19:36:44 +0200 Subject: Extras Rebuild? In-Reply-To: <20050521093037.A12984@tiki-lounge.com> References: <20050521093037.A12984@tiki-lounge.com> Message-ID: <20050521193644.48e8d555.bugs.michael@gmx.net> On Sat, 21 May 2005 09:30:37 -0700, Toshio Kuratomi wrote: > Any news on when a mass rebuild of Extras packages might be expected? I've > just installed a new machine and found that some of the packages are > straight imports from the FC3 tree (on x86_64). Sooner is better than later > so people can start looking at why these things are failing. We need better organisation than arbitrary mass rebuilds. By now we should be pretty much complete with regard to every package having an owner with CVS access (except for a very few individuals, who are missing, and one or two, who can't sign up yet). For the last rebuild of ~400 packages on April 7th, the situation was different. Pre-Extras, builds for specific archs, packagers waiting for CVS access, FC4Test releases being out already, GCC 4 rebuilds happening in Rawhide after the wait for the compiler being considered good enough; many factors resulted in the Extras Development repository being out-of-sync with either CVS or with the Extras-for-FC3 repository. Nowadays, we need a roadmap. A schedule according to which packagers prepare their Extras packages, so when FC4 is released, FE4 is available, too, and doesn't make us look bad. Bill Nottingham some days ago posted a list of Extras packages to maintainers-list, which need a rebuild, because of version mismatches on the three archs we build for. We should assume that package maintainers have noticed that list. In addition to that, the FE4Target tracker contains a list of broken packages, which failed to rebuild for FC4 or which fail due to serious defects. These are issues a mass rebuild is unlikely to fix. As some of us have attached patches to some of the bugs, how long do we wait for a reaction from the package owner? Package owners can decide better whether to rebuild a package or whether to apply upstream updates first. Either we do have package maintainers or we don't. Concerning GCC4, is there a specific release of the gcc package, after which all packages in Extras should have been rebuilt [in order to benefit from compiler fixes]? > -Toshio > > PS: Thought for FC5 -- Could we have automated rebuilds for Extras after > each test release? For community members to contribute to fixing packages we > need to be able to generate lists of packages which are failing. Since > development means people are using eats-my-babies rawhide it would make more > sense to have the development packages be auto-built so breakage can be > discovered in the development stage. We seriously need to develop a feeling for the dependencies of each of our packages. As soon as the next Fedora Core Development starts and the FC-4 branch has been created, rebuilds from within FE "devel" could be requested by the package maintainers. Same as above here. We do need a roadmap and a development model. If somebody depends on packages, which have not been rebuilt, does he wait or does he request rebuilds himself or by contacting the package owner first? Unattended mass rebuilding all (!) of Extras would give a false impression of what is maintained and what is not. E.g. after the April 7th rebuild, some packagers did version upgrades almost immediately. The point of rebuilding the old package versions was what? Community contributors spending time on fixing broken rebuild attempts for a FC test release is wasted time if the package owner just waits and applies an upstream update a few weeks later. I consider mass rebuilds a bottom-up "brute force" approach to try fixing something where no top-down approach is available. More helpful in my opinion would be, at least, to try coming up with a roadmap for Fedora Extras and then find out where we encounter any difficulties. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1323_FC4 loadavg: 1.01 1.02 1.07 From bugs.michael at gmx.net Sat May 21 18:04:01 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 21 May 2005 20:04:01 +0200 Subject: New package: GCfilms In-Reply-To: <20050521191025.62de2e9e@tianbox> References: <20050516004934.234bfba2@tianbox> <1116538729.7161.85.camel@ignacio.ignacio.lan> <20050521002941.56d66167@tianbox> <1116629469.7161.128.camel@ignacio.ignacio.lan> <20050521011844.401fd74b@tianbox> <1116636395.7161.136.camel@ignacio.ignacio.lan> <20050521191025.62de2e9e@tianbox> Message-ID: <20050521200401.13d8550d.bugs.michael@gmx.net> On Sat, 21 May 2005 19:10:25 +0200, Christian Jodar wrote: > > Looks fine to me. I'll go ahead and import it > > Thanks a lot. > > > and you go ahead and apply for CVS access. > > It seems that someone already did that. Status shown > is "In progress". That "someone" must have been you. I doubt somebody else has signed up for you. > > Don't forget to submit your CLA if you haven't > > already. > > Already done (I am member of cla_done group). > > Do I need to do something else for the moment? I will > read all of the documentation that is on the Wiki in the > meantime. Until the sponsorship situation clears up, you may need to push any package update into CVS using Ignacio as your proxy. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1323_FC4 loadavg: 1.70 2.23 1.85 From tian at c-sait.net Sat May 21 18:31:57 2005 From: tian at c-sait.net (Christian Jodar) Date: Sat, 21 May 2005 20:31:57 +0200 Subject: New package: GCfilms In-Reply-To: <20050521200401.13d8550d.bugs.michael@gmx.net> References: <20050516004934.234bfba2@tianbox> <1116538729.7161.85.camel@ignacio.ignacio.lan> <20050521002941.56d66167@tianbox> <1116629469.7161.128.camel@ignacio.ignacio.lan> <20050521011844.401fd74b@tianbox> <1116636395.7161.136.camel@ignacio.ignacio.lan> <20050521191025.62de2e9e@tianbox> <20050521200401.13d8550d.bugs.michael@gmx.net> Message-ID: <20050521203157.2534911b@tianbox> > > It seems that someone already did that. Status shown > > is "In progress". > > That "someone" must have been you. I doubt somebody else has signed up > for you. Actually, I did that on the beginning. But it has been rejected because I made it too early: https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00375.html Maybe Elliot put me back as requester. Christian Jodar. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at camperquake.de Sat May 21 18:34:56 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 21 May 2005 20:34:56 +0200 Subject: Breaking "make tag" Message-ID: <20050521203456.68cc48b7@nausicaa.camperquake.de> Hi. I think I broke the "make tag" system a bit. Here's the gist: 1) Check out a tree, change the spec file, updating v-r 2) forget to commit the change and run "make tag" 3) make does something and returns complaining that you have locally modified files (which is right, the spec file) 4) commit the changes 5) run "make tag" again 6) make does something and returns complaining that the tag already exists. 7) *headscratching* *shrug* 8) run "make build" 9) recieve a mail from the build system complaining that the tag that could not be created in step 6 because it already exists does not exist. 10) *more headscratching* So, I admit that I made a mistake by not committing the change as the first step, but does the tag exist or not? (the tag in question is bmp-0_9_7-8_fc4) -- "The last good thing written in C was Franz Schubert's Symphony number 9." -- Erwin Dieterich From bugs.michael at gmx.net Sat May 21 18:55:27 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 21 May 2005 20:55:27 +0200 Subject: Breaking "make tag" In-Reply-To: <20050521203456.68cc48b7@nausicaa.camperquake.de> References: <20050521203456.68cc48b7@nausicaa.camperquake.de> Message-ID: <20050521205527.2582b894.bugs.michael@gmx.net> On Sat, 21 May 2005 20:34:56 +0200, Ralf Ertzinger wrote: > Hi. > > I think I broke the "make tag" system a bit. Here's the gist: > > 1) Check out a tree, change the spec file, updating v-r > 2) forget to commit the change and run "make tag" > 3) make does something and returns complaining that you have locally > modified files (which is right, the spec file) > 4) commit the changes > 5) run "make tag" again > 6) make does something and returns complaining that the tag already > exists. > 7) *headscratching* *shrug* > 8) run "make build" > 9) recieve a mail from the build system complaining that the tag that > could not be created in step 6 because it already exists does not > exist. > 10) *more headscratching* > > So, I admit that I made a mistake by not committing the change as > the first step, but does the tag exist or not? > > (the tag in question is bmp-0_9_7-8_fc4) The tag did not exist on the actual files after a clean check-out here. But now it does. It's possible to move such tags. Carefully though. Step 6) is because cvs tag -c is used to make sure the local working copy is unmodified. From fedora at camperquake.de Sat May 21 18:59:57 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 21 May 2005 20:59:57 +0200 Subject: Breaking "make tag" In-Reply-To: <20050521205527.2582b894.bugs.michael@gmx.net> References: <20050521203456.68cc48b7@nausicaa.camperquake.de> <20050521205527.2582b894.bugs.michael@gmx.net> Message-ID: <20050521205957.64c5870d@nausicaa.camperquake.de> Hi. Michael Schwendt wrote: > The tag did not exist on the actual files after a clean check-out here. > But now it does. It's possible to move such tags. Carefully though. Does it exist because you made it, or did it appear from wherever it is that tags live? > Step 6) is because cvs tag -c is used to make sure the local working > copy is unmodified. Is there a way to avoid this problem in the makefile? From pawsa at theochem.kth.se Sat May 21 19:20:16 2005 From: pawsa at theochem.kth.se (Pawel Salek) Date: Sat, 21 May 2005 19:20:16 +0000 Subject: New package: balsa In-Reply-To: <20050520233015.36af683d.bugs.michael@gmx.net> (from bugs.michael@gmx.net on Fri May 20 23:30:15 2005) References: <1116615345l.5333l.0l@salek.zapto.org> <20050520233015.36af683d.bugs.michael@gmx.net> Message-ID: <1116703221l.24429l.1l@salek.zapto.org> On 05/20/2005 11:30:15 PM, Michael Schwendt wrote: > On Fri, 20 May 2005 18:55:45 +0000, Pawel Salek wrote: > [snip] > > srpm passes rpmlint test with on only one insignificant message > related > > to gmime. The balsa package is basically the same as used to be > > included in Fedora Core 3, apart from the version upgrade. > > ...and a ~7 KiB unified diff against the last version from Rawhide. > ;) > Haven't examined all those changes yet. Changes can be divided into four groups: - reorder the headers to match the fedora spec template from fedora-rpmdevtools-1.0-1 and smp-specific macros. - remove some alpha-architecture and autoconf.sh related dead wood (we now always distribute configure script with the tarball). - upgrade-related, eg: add gtk-update-icon-cache to %post. - spec file contains the changelog as managed by balsa project - but I guess I can cut it out to make it fair :). > [snip] > Simple rpmbuild --rebuild failed here. Build requirements may be > missing. > At least: > > checking for > glib-2.0 > gtk+-2.0 >= 2.4 > gmime-2.0 >= 2.1.9 > libgnome-2.0 libgnomeui-2.0 > gnome-vfs-2.0 gnome-vfs-module-2.0 libbonobo-2.0 > libgnomeprint-2.2 >= 2.1.4 libgnomeprintui-2.2 >= 2.1.4 > ... Package libgnomeprint-2.2 was not found in the pkg-config search > path. > Perhaps you should add the directory containing > `libgnomeprint-2.2.pc' > to the PKG_CONFIG_PATH environment variable > No package 'libgnomeprint-2.2' found Thanks for finding it - this part is actually same as in FC3 spec file :). I guess I should go through the entire procedure of finding the dependencies... For now, I replace the balsa.spec file http://balsa.gnome.org/balsa.spec has the checksum: 1afe5cecb6cd66f3316f61e79588f2fe balsa.spec Pawel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Sat May 21 19:35:56 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 21 May 2005 21:35:56 +0200 Subject: Breaking "make tag" In-Reply-To: <20050521205957.64c5870d@nausicaa.camperquake.de> References: <20050521203456.68cc48b7@nausicaa.camperquake.de> <20050521205527.2582b894.bugs.michael@gmx.net> <20050521205957.64c5870d@nausicaa.camperquake.de> Message-ID: <20050521213556.6807597b.bugs.michael@gmx.net> On Sat, 21 May 2005 20:59:57 +0200, Ralf Ertzinger wrote: > Hi. > > Michael Schwendt wrote: > > > The tag did not exist on the actual files after a clean check-out here. > > But now it does. It's possible to move such tags. Carefully though. > > Does it exist because you made it, or did it appear from wherever it > is that tags live? The former. > > Step 6) is because cvs tag -c is used to make sure the local working > > copy is unmodified. > > Is there a way to avoid this problem in the makefile? Well, one could attempt at adding a safety check, e.g. analysing "cvs status" or "cvs status -v", so that all files are reported as Up-to-date. But somebody who commits into CVS can introduce other mistakes. -- Fedora Core release 3 (Heidelberg) - Linux 2.6.11-1.14_FC3 loadavg: 1.26 1.29 1.01 From oliver at linux-kernel.at Sat May 21 19:44:01 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Sat, 21 May 2005 21:44:01 +0200 Subject: mach/mock and selinux In-Reply-To: <87ekc0hcpw.fsf@kosh.bigo.ensc.de> Message-ID: <200505211943.j4LJhsxj004476@mail.linux-kernel.at> [ ... ] > >> >>>$ mock -r fedora-3-i386-core mock-0.1-1.src.rpm > >> > :: > >> >>> Non-zero return value 127 on executing /usr/sbin/mock-helper > >> >>>chroot /var/lib/mock//fedora-3-i386-core/root > /sbin/runuser - root > >> >>>-c "/usr/sbin/useradd -u 500 -d /builddir mockbuild" > >> > > >> > Ok I haven't tested, but apparently this is caused by using > >> > selinux, which presumably also explains the problem I was seeing > >> > earlier with mach. > >> > >> SELinux was never designed to work with or in chroot environments, > >> and unless somebody implements another kernel API, this will not > >> change. So best would be, to disable SELinux completely at system > >> start. > > > > Correct, Enrico, but wouldn't make sense to give user mock all > > (selinux) permission for /var/lib/mock!? > > Probably not. SELinux requires the /proc and /selinux > filesystems to communicate with the kernel; it does not use > the common syscall interface. > > This makes e.g. the 'rpm --root' commands nearly impossible: > script execution would require complicated actions in the > selinux lib (getting fd of /proc/self/attr/... before the > chroot(2) (perhaps of files in /selinux/... also) and using > it after the chroot(2)). But the SELinux lib was not designed > for it; most functions are doing 'fopen("/proc/...")' > themself and can not used cached fd's or other SELinux information. > > See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145770 also. Argh... You are correct, you was thinkin' the other way round... Simply forget it... :-) Best, Oliver From toni at willberg.fi Sat May 21 21:17:06 2005 From: toni at willberg.fi (Toni Willberg) Date: Sun, 22 May 2005 00:17:06 +0300 Subject: New package: bitlbee-0.92 Message-ID: <1116710226.3422.9.camel@ihaa.home.willberg.fi> "Bitlbee is an IRC to other chat networks gateway. bitlbee can be used as an IRC server which forwards everything you say to people on other chat networks like MSN/ICQ/Jabber." The package is taken from Dag's repository. Only changed the dependency for xinetd and turned on the service by default. Review for the package needed. I've got the CVS account. SRPM, md5sum and the specfile: http://toniw.iki.fi/temp/bitlbee-0.92-2.src.rpm http://toniw.iki.fi/temp/bitlbee-0.92-2.src.rpm.md5sum.asc http://toniw.iki.fi/temp/bitlbee.spec Upstream: http://www.bitlbee.org/ Tested on fedora-release-3.91-1 / x86_64 system. - Toni -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazquez at ivazquez.net Sun May 22 01:39:40 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 21 May 2005 21:39:40 -0400 Subject: sqlite2 redux Message-ID: <1116725980.7161.147.camel@ignacio.ignacio.lan> So now there's a way to install kannel, moodss, et al on FC4, which is good. However, these packages will still interfere with upgrading from FC3 to FC4, which is bad. What I propose is that sqlite2 gets a FC-3 branch, and that the FE3 packages that depend on it get modified at the same time for a seamless update. I'm willing to take on all the work for modifying the packages, but I would like the current maintainers' permission. Just to recap, the packages that are dependent on it are kannel, moodss, and python-sqlite, correct? Also, we should try and get a note into the release notes wrt python- sqlite and FE3/FC4 explaining the sqlite version difference. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From toshio at tiki-lounge.com Sun May 22 01:42:40 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sat, 21 May 2005 18:42:40 -0700 Subject: Extras Rebuild? In-Reply-To: <20050521193644.48e8d555.bugs.michael@gmx.net>; from bugs.michael@gmx.net on Sat, May 21, 2005 at 07:36:44PM +0200 References: <20050521093037.A12984@tiki-lounge.com> <20050521193644.48e8d555.bugs.michael@gmx.net> Message-ID: <20050521184240.A22335@tiki-lounge.com> On Sat, May 21, 2005 at 07:36:44PM +0200, Michael Schwendt wrote: > On Sat, 21 May 2005 09:30:37 -0700, Toshio Kuratomi wrote: > > > Any news on when a mass rebuild of Extras packages might be expected? I've > > just installed a new machine and found that some of the packages are > > straight imports from the FC3 tree (on x86_64). Sooner is better than later > > so people can start looking at why these things are failing. > > We need better organisation than arbitrary mass rebuilds. By now we should > be pretty much complete with regard to every package having an owner with > CVS access (except for a very few individuals, who are missing, and one or > two, who can't sign up yet). > Right. But we have a bunch of broken packages in the devel repository that need dealing with some way before FC4 is released. And we have a bunch of packages in unknown state because they haven't been rebuilt since FC3. > For the last rebuild of ~400 packages on April 7th, the situation was > different. Pre-Extras, builds for specific archs, packagers waiting for > CVS access, FC4Test releases being out already, GCC 4 rebuilds happening > in Rawhide after the wait for the compiler being considered good enough; > many factors resulted in the Extras Development repository being > out-of-sync with either CVS or with the Extras-for-FC3 repository. > The major problem in my mind being that previous rebuilds didn't result in bugzilla bugs being filed. The packages that are currently out of sync, imported to the devel tree but not rebuilt, etc aren't all being tracked so it takes effort for a non-maintainer (or maintainer of many (too many?) packages to figure out what stll needs fixing. With the new buildsys and policies this will be easier to assess in FC5. But right now it's a hodgepodge and we need to sort it out someway before FE packages can be released. > Nowadays, we need a roadmap. A schedule according to which packagers > prepare their Extras packages, so when FC4 is released, FE4 is available, > too, and doesn't make us look bad. > To prevent FE4 from looking bad, we need to be sure nonworking packages in the devel repository don't go into the FE4 repository. Things that haven't been rebuilt, that are not building on all platforms, are known to crash on one of the supported architectures, etc have to remain in devel. This can be achieved either through package maintainers or through community members. If it's community members who are merging fixes, then something that would help me, as a community member, to figure out which packages that I care about are in need of work, would be a complete record of what packages have failed rebuild. This info isn't in bugzilla. It isn't in the build logs. It *is* in the repository but isn't easy to extract: Is the package available on all architectures and has been rebuilt at a sufficiently recent date that all its buildrequirements had been updated to a final enough version. > Bill Nottingham some days ago posted a list of Extras packages to > maintainers-list, which need a rebuild, because of version mismatches on > the three archs we build for. We should assume that package maintainers > have noticed that list. > But it wasn't. Or maintainers don't all have enough time to work on them. We need to have these filed in bugzilla and become a dependency of the FE4Tracker bug so the community can take a look at these problems. My problem with the way FE4 stands is that we haven't recorded the status of our packages. So where do we currently stand? Which packages from Bill's list are still a problem? Which packages pulled down from the yum repository will work and which will not? Which packages have been compiled against a sufficiently new version of FC4 and which have been built with older versions that A) will evoke bugs when run on FC4 or B) won't rebuild against FC4. > In addition to that, the FE4Target tracker contains a list of broken > packages, which failed to rebuild for FC4 or which fail due to serious > defects. These are issues a mass rebuild is unlikely to fix. As some of us > have attached patches to some of the bugs, how long do we wait for a > reaction from the package owner? > Email the owner. Try to get one other person to review the change. Eventually merge yourself. We need to evolve some policy here. To be useful for FC4, though, we need to come up with something sane quickly as we need to merge those fixes and test them. Side note: Although I've been browsing the FETracker bugs to find things to fix, it strikes me as the wrong way to address FE (as we have it setup.) If individual maintainers are responsible for bringing the packages to readiness, then the packages will make it into the FE4 repository when they're ready rather than the FE4 repository will be released when the FE4 packages are ready. This is in contrast to the FC4 Trackers which, in theory, describe all the changes that must occur before FC4 can ship. For Extras in its present incarnation, it makes more sense to have per-package trackers. If a package has remaining issues, it doesn't make it into the FEx repository. > Package owners can decide better whether to rebuild a package or whether > to apply upstream updates first. Either we do have package maintainers or > we don't. > All issues should be tracked in bugzilla. Then the maintainer can mark them as UPSTREAM if they'll be done on an update rather than fixed locally. Among other things, this means build failures should go in bugzilla (perhaps the buildsystem can do this just as it emails out failures. The problem is a bit harder than email as we probably want to update older build failures rather than create new ones and close out old ones when the build succeeds. Perhaps an approach such as having a buildsystem bugzilla account be the submitter or a BUILDFAIL keyword.) The bugzilla tickets can be used to track the current status of a package. > Concerning GCC4, is there a specific release of the gcc package, after > which all packages in Extras should have been rebuilt [in order to > benefit from compiler fixes]? > I also wish I knew the answer to this. More than compiler fixes, though, we also have to make sure the extras packages utilize the latest versions of the toolchain as a whole. Otherwise bugs can occur in FE that stem from FC updates. One way to resolve this would be to not push things into the FE4 repository until an FC4 repository (for the buildsystem) was available. Mantainers that want their packages in FC4 need to make a request to the buildsystem after this is available. (In some future incarnation, the buildsystem could queue FCn+1 requests and start building when the FCn+1 repository opened.) > > PS: Thought for FC5 -- Could we have automated rebuilds for Extras after > > each test release? For community members to contribute to fixing packages we > > need to be able to generate lists of packages which are failing. Since > > development means people are using eats-my-babies rawhide it would make more > > sense to have the development packages be auto-built so breakage can be > > discovered in the development stage. > > We seriously need to develop a feeling for the dependencies of each of our > packages. As soon as the next Fedora Core Development starts and the FC-4 > branch has been created, rebuilds from within FE "devel" could be > requested by the package maintainers. > > Same as above here. We do need a roadmap and a development model. If > somebody depends on packages, which have not been rebuilt, does he wait or > does he request rebuilds himself or by contacting the package owner first? > Unattended mass rebuilding all (!) of Extras would give a false impression > of what is maintained and what is not. I think automated rebuilds help the community see problems. An automated rebuild can lead to a build failure which can lead to a commnity member sending patches which leads to the realization that a particular maintainer is overworked. An overworked maintainer that doesn't request rebuilds and doesn't request help will lead to a package that silently disappears from the FE repository in future versions of FC. OTOH, there are definitely better ways to achieve this than automated reuilding so I'll drop my suggestion to do it for FC5 if we can put together a better mechanism. > E.g. after the April 7th rebuild, > some packagers did version upgrades almost immediately. The point of > rebuilding the old package versions was what? Community contributors > spending time on fixing broken rebuild attempts for a FC test release is > wasted time if the package owner just waits and applies an upstream update > a few weeks later. > Very true. We need to track a packages status and future direction. Bugzilla. > I consider mass rebuilds a bottom-up "brute force" approach to try fixing > something where no top-down approach is available. More helpful in my > opinion would be, at least, to try coming up with a roadmap for Fedora > Extras and then find out where we encounter any difficulties. > I agree. Do we have a top-down approach tha will allow us to get FE4 out when FC4 hits the streets or do we have nothing better than the brute force approach at this point? I agree with your assessment (pretty much your entire message) of where we want to be. My question is can we get there in time for FC4 or do we need a stop gap for FC4 and something that is designed to work well for FC5-devel? -Toshio From buildsys at fedoraproject.org Sun May 22 03:48:00 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 21 May 2005 23:48:00 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050522034800.A39967FF4@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 5 opensc-0.9.6-1 scrub-1.6-2 scrub-1.6-2.fc3 xca-0.5.1-3 xca-0.5.1-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 Sun May 22 03:58:29 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 21 May 2005 23:58:29 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050522035829.687807FF4@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 10 audacity-1.2.3-5 bazaar-1.3.2-5 bazaar-1.3.2-5.fc4 colordiff-1.0.5-1 doctorj-4.0.2-7 flumotion-0.1.8-1 jlint-1.21-4 xca-0.5.1-3 xca-0.5.1-3.fc4 xosd-2.2.14-3 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 Sun May 22 04:04:45 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Sat, 21 May 2005 22:04:45 -0600 Subject: Fedora Extras 3 Package Build Report In-Reply-To: <20050520172638.C93817F76@extras64.linux.duke.edu> References: <20050520172638.C93817F76@extras64.linux.duke.edu> Message-ID: <80d7e40905052121045e7a3669@mail.gmail.com> On 5/20/05, buildsys at fedoraproject.org wrote: > > Packages built and released for Fedora Extras 3: 30 > > clamav-0.85.1-4 > clamav-0.85.1-4.fc3 THANKYOU!!! My attempts at trying to get this done keep getting put behind :( > openct-0.6.5-1 This does not seem to be working correctly. When trying to install gpa, I get an error that libopenct isnt available (I think) -- Stephen J Smoogen. CSIRT/Linux System Administrator From skvidal at phy.duke.edu Sun May 22 04:07:29 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 22 May 2005 00:07:29 -0400 Subject: Fedora Extras 3 Package Build Report In-Reply-To: <80d7e40905052121045e7a3669@mail.gmail.com> References: <20050520172638.C93817F76@extras64.linux.duke.edu> <80d7e40905052121045e7a3669@mail.gmail.com> Message-ID: <1116734849.3275.15.camel@cutter> On Sat, 2005-05-21 at 22:04 -0600, Stephen J. Smoogen wrote: > On 5/20/05, buildsys at fedoraproject.org wrote: > > > > Packages built and released for Fedora Extras 3: 30 > > > > > clamav-0.85.1-4 > > clamav-0.85.1-4.fc3 > > THANKYOU!!! My attempts at trying to get this done keep getting put behind :( > > > > openct-0.6.5-1 > > This does not seem to be working correctly. When trying to install > gpa, I get an error that libopenct isnt available (I think) it _just_ got pushed. it's probably not hit the mirror yet. -sv From smooge at gmail.com Sun May 22 04:13:28 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Sat, 21 May 2005 22:13:28 -0600 Subject: Fedora Extras 3 Package Build Report In-Reply-To: <1116734849.3275.15.camel@cutter> References: <20050520172638.C93817F76@extras64.linux.duke.edu> <80d7e40905052121045e7a3669@mail.gmail.com> <1116734849.3275.15.camel@cutter> Message-ID: <80d7e4090505212113fe4ad1b@mail.gmail.com> On 5/21/05, seth vidal wrote: > On Sat, 2005-05-21 at 22:04 -0600, Stephen J. Smoogen wrote: > > On 5/20/05, buildsys at fedoraproject.org wrote: > > > > > > Packages built and released for Fedora Extras 3: 30 > > > > > > > > clamav-0.85.1-4 > > > clamav-0.85.1-4.fc3 > > > > THANKYOU!!! My attempts at trying to get this done keep getting put behind :( > > > > > > > openct-0.6.5-1 > > > > This does not seem to be working correctly. When trying to install > > gpa, I get an error that libopenct isnt available (I think) > > it _just_ got pushed. > Oh.. sorry I just re-built my home machine (bad disk drive) so I was getting various packages on the box. Now to complete my CVS stuff before the big bad moving truck takes me away. > > it's probably not hit the mirror yet. > -- Stephen J Smoogen. CSIRT/Linux System Administrator From ville.skytta at iki.fi Sun May 22 09:32:24 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 22 May 2005 12:32:24 +0300 Subject: Fedora Extras 3 Package Build Report In-Reply-To: <1116734849.3275.15.camel@cutter> References: <20050520172638.C93817F76@extras64.linux.duke.edu> <80d7e40905052121045e7a3669@mail.gmail.com> <1116734849.3275.15.camel@cutter> Message-ID: <1116754344.32359.92.camel@bobcat.mine.nu> On Sun, 2005-05-22 at 00:07 -0400, seth vidal wrote: > On Sat, 2005-05-21 at 22:04 -0600, Stephen J. Smoogen wrote: > > On 5/20/05, buildsys at fedoraproject.org wrote: > > > > > > openct-0.6.5-1 > > > > This does not seem to be working correctly. When trying to install > > gpa, I get an error that libopenct isnt available (I think) > > it _just_ got pushed. Yep, assuming you're referring to a missing opensc (not openct) FC3 build: my bad, should be fixed now https://bugzilla.redhat.com/158403 From ville.skytta at iki.fi Sun May 22 10:13:57 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 22 May 2005 13:13:57 +0300 Subject: uqm update - RFC for uqm-content* Message-ID: <1116756837.32359.125.camel@bobcat.mine.nu> uqm has been updated to 0.4.0 upstream, and I'm planning to update it real soon now in Extras (FC4/devel only). Unfortunately but as sort of expected, the base uqm-content (which is required, about 10MB) and uqm-content-voice (which is optional and huge, about 110MB) packages have changed, and need updating too. uqm-content-3domusic would not need updating from 0.3, it has not changed, but it is a subpackage of the uqm-content SRPM and has already been updated in the Apr 7 mass rebuild so that FC3->FC4 upgraders will receive a new version of the same ~18MB zip blob anyway. If anyone has comments regarding the packaging of the uqm-content* stuff, now before the update would be a good time to voice them. We're talking about 4 * 140MB stuff (3 archs + one SRPM [1]) hitting the repo soon. Some random thoughts that have crossed my mind are dropping the optional 3domusic and voice content subpackages altogether and/or content->data rename, but unless there is a strong consensus how/if things should be changed, I'm going to leave things as is and just do a straightforward update. I don't really have a big problem with the way things currently are, but I thought I'd ask if someone does before proceeding. [1] Cases like this make me wonder whether it would be a possible to host all noarch stuff in a noarch repository shared between i386, x86_64 and ppc instead of having copies of all of this in each. Or maybe not not _all_ noarch, but a "data" repository for cases where size matters. In addition to uqm-content*, torcs-data* and various other noarchs at the top of the listing at http://fedoraproject.org/extras/3/i386/?C=S;O=D would be good candidates. From bugs.michael at gmx.net Sun May 22 12:05:25 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 22 May 2005 14:05:25 +0200 Subject: Extras Rebuild? In-Reply-To: <20050521184240.A22335@tiki-lounge.com> References: <20050521093037.A12984@tiki-lounge.com> <20050521193644.48e8d555.bugs.michael@gmx.net> <20050521184240.A22335@tiki-lounge.com> Message-ID: <20050522140525.303df651.bugs.michael@gmx.net> On Sat, 21 May 2005 18:42:40 -0700, Toshio Kuratomi wrote: > [...] But we have a bunch of broken packages in the devel repository that > need dealing with some way before FC4 is released. And we have a bunch of > packages in unknown state because they haven't been rebuilt since FC3. I believe it's the same set of packages: whatever failed to rebuild on April 7th exists in the repository as a copied FC3 binary. Is this a wrong assumption? > The major problem in my mind being that previous rebuilds didn't result in > bugzilla bugs being filed. Right. But notice that we imported Seth's build failure report into the Wiki for tracking purposes, and later on I filed a bug report about every package on that list. The FE4Target tracker depends on all those bugs plus other issues, such as crashes. > The packages that are currently out of sync, > imported to the devel tree but not rebuilt, etc aren't all being tracked so > it takes effort for a non-maintainer (or maintainer of many (too many?) > packages to figure out what stll needs fixing. That's why we need a roadmap. It's the maintainer's responsibility to (re)build packages in preparation for FE4. Basically, for each package in the devel repo, which is out-of-sync with devel CVS, somebody would need to make sure that it is really the right version that shall be built and released. It's the packager who would tag that version and request a build. I mean, we don't want to build something without the "okay" from the package owner and possibly create a situation where a released binary must be pulled from the repo because it was a premature version upgrade that wasn't meant to be built. > If it's community members who are merging fixes, then something that would > help me, as a community member, to figure out which packages that I care > about are in need of work, would be a complete record of what packages have > failed rebuild. This info isn't in bugzilla. It is. Or let me ask a question: what other packages should be added to bug 157183? > It isn't in the build logs. > It *is* in the repository but isn't easy to extract: > Is the package available on all architectures and has been rebuilt at a > sufficiently recent date that all its buildrequirements had been updated > to a final enough version. That assumes that [minor] version upgrades introduced ABI/API incompatibility without the package owner paying attention to it. Can you provide any examples? > > Bill Nottingham some days ago posted a list of Extras packages to > > maintainers-list, which need a rebuild, because of version mismatches on > > the three archs we build for. We should assume that package maintainers > > have noticed that list. > > > But it wasn't. Or maintainers don't all have enough time to work on them. "Bump release, make tag, make build" is all that would be needed. > We need to have these filed in bugzilla and become a dependency of the > FE4Tracker bug so the community can take a look at these problems. Are these due to "problems"? I still think most of the version mismatches are due to missing powerpc build support earlier on. For the noarch cases, packages have been copied over. A series of other packages has been rebuilt for all archs meanwhile. > My problem with the way FE4 stands is that we haven't recorded the status of > our packages. So where do we currently stand? Which packages from Bill's > list are still a problem? A re-run of the script, which created that list, should tell. > Which packages pulled down from the yum > repository will work and which will not? Again, we do have package maintainers, don't we? Also, there are fine community people reporting broken packages in bugzilla. We should not disappoint users, who use our packages actually. > Which packages have been > compiled against a sufficiently new version of FC4 and which have been built > with older versions that A) will evoke bugs when run on FC4 or B) won't > rebuild against FC4. Same here as above. Unattended mass rebuilds should not be expected to fix broken packages magically. They are unlikely to create good builds for packages, which simply miscompile in some way. It really needs a package developer to take care of a package (and e.g. verify whether version checks done by a configure script still give good results with FCn+1). > > In addition to that, the FE4Target tracker contains a list of broken > > packages, which failed to rebuild for FC4 or which fail due to serious > > defects. These are issues a mass rebuild is unlikely to fix. As some of us > > have attached patches to some of the bugs, how long do we wait for a > > reaction from the package owner? > > > Email the owner. Try to get one other person to review the change. > Eventually merge yourself. We need to evolve some policy here. To be > useful for FC4, though, we need to come up with something sane quickly > as we need to merge those fixes and test them. The thing here is, bugzilla tickets are _assigned to_ the package owner and _mailed to_ the package owner. So, that is a way already to address the package owner. Assume that package owners do see your bug report and your attachments (if any) and could add a comment like "go ahead with the fix" or set status to ASSIGNED to give you some feedback. > Side note: Although I've been browsing the FETracker bugs to find things to > fix, it strikes me as the wrong way to address FE (as we have it setup.) If > individual maintainers are responsible for bringing the packages to > readiness, then the packages will make it into the FE4 repository when > they're ready rather than the FE4 repository will be released when the FE4 > packages are ready. This is in contrast to the FC4 Trackers which, in > theory, describe all the changes that must occur before FC4 can ship. This tracker is called FE4Target with good reason. It's not called FE4Blocker, as we don't have a release date, because Fedora Extras has been a rolling release so far. It _could_ influence when to make available the current devel repository in an "extras/4" channel. That would not be fair, though, since some contributors make sure their packages are ready, and other packagers perhaps depend on upstream projects catching up with API changes. > For Extras in its present incarnation, it makes more sense to have > per-package trackers. If a package has remaining issues, it doesn't > make it into the FEx repository. That is the reason why I didn't like it when the public repository was filled with copies of FC3 binaries without a guide for the packagers when to rebuild their packages. We should have built Fedora Extras Development from scratch, since the only thing we depend on is Fedora Core (well, except for future programming language packages which need bootstrapping). > Among other things, this means build failures should go in bugzilla (perhaps > the buildsystem can do this just as it emails out failures. The problem is > a bit harder than email as we probably want to update older build failures > rather than create new ones and close out old ones when the build succeeds. > Perhaps an approach such as having a buildsystem bugzilla account be the > submitter or a BUILDFAIL keyword.) The bugzilla tickets can be used to > track the current status of a package. Here once more: if Fedora Extras wants to scale, every package should have at least one person taking care of it. Build requests are done by human beings. Build status reports are mailed back to human beings. It is assumed that the person, who requests a build, does something useful with a build failure log and e.g. decides whether it should be tracked in bugzilla, because it might take some time until it is fixed. > > I consider mass rebuilds a bottom-up "brute force" approach to try fixing > > something where no top-down approach is available. More helpful in my > > opinion would be, at least, to try coming up with a roadmap for Fedora > > Extras and then find out where we encounter any difficulties. > > > I agree. > > Do we have a top-down approach tha will allow us to get FE4 out > when FC4 hits the streets or do we have nothing better than the brute force > approach at this point? > > I agree with your assessment (pretty much your entire message) of where we > want to be. My question is can we get there in time for FC4 or do we need a > stop gap for FC4 and something that is designed to work well for FC5-devel? You mentioned "overworked packagers". If you think you know what you are doing and a packager seems overworked, I doubt he minds if you applied a patch yourself to fix a package. For bigger changes, such as version upgrades, an explicit "okay" from the package owner should be asked for. If such a question is not answered after several weeks, with FC4 being very close, that could be an indication that the packager is occupied with other stuff and that the package might benefit from another person taking care of it. We should not complicate matters too much. If the most simple communication fails, we have bigger problems than just temporarily failed builds of some packages. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1323_FC4 loadavg: 1.10 1.43 1.75 From bugs.michael at gmx.net Sun May 22 12:07:59 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 22 May 2005 14:07:59 +0200 Subject: Fedora Extras development Package Build Report In-Reply-To: <20050522035829.687807FF4@extras64.linux.duke.edu> References: <20050522035829.687807FF4@extras64.linux.duke.edu> Message-ID: <20050522140759.3dd12fa0.bugs.michael@gmx.net> On Sat, 21 May 2005 23:58:29 -0400 (EDT), buildsys at fedoraproject.org wrote: > > Packages built and released for Fedora Extras development: 10 > > audacity-1.2.3-5 This build no longer suffers from the problems mentioned recently. Maybe the first build of it with wxGTK2 (audacity-1.2.3-3) suffered from temporary problems in gcc4? From bugs.michael at gmx.net Sun May 22 12:09:17 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 22 May 2005 14:09:17 +0200 Subject: sqlite2 redux In-Reply-To: <1116725980.7161.147.camel@ignacio.ignacio.lan> References: <1116725980.7161.147.camel@ignacio.ignacio.lan> Message-ID: <20050522140917.03c97ef1.bugs.michael@gmx.net> On Sat, 21 May 2005 21:39:40 -0400, Ignacio Vazquez-Abrams wrote: > So now there's a way to install kannel, moodss, et al on FC4, which is > good. However, these packages will still interfere with upgrading from > FC3 to FC4, which is bad. How do they interfere? From paul at city-fan.org Sun May 22 14:23:38 2005 From: paul at city-fan.org (Paul Howarth) Date: Sun, 22 May 2005 15:23:38 +0100 Subject: New package: bitlbee-0.92 In-Reply-To: <1116710226.3422.9.camel@ihaa.home.willberg.fi> References: <1116710226.3422.9.camel@ihaa.home.willberg.fi> Message-ID: <1116771818.4628.201.camel@laurel.intra.city-fan.org> On Sun, 2005-05-22 at 00:17 +0300, Toni Willberg wrote: > "Bitlbee is an IRC to other chat networks gateway. bitlbee can be used > as an IRC server which forwards everything you say to people on other > chat networks like MSN/ICQ/Jabber." > > The package is taken from Dag's repository. Only changed the dependency > for xinetd and turned on the service by default. I thought turning on network-listening services by default was frowned upon? Paul. -- Paul Howarth From mattdm at mattdm.org Sun May 22 14:55:40 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 22 May 2005 10:55:40 -0400 Subject: New package: bitlbee-0.92 In-Reply-To: <1116771818.4628.201.camel@laurel.intra.city-fan.org> References: <1116710226.3422.9.camel@ihaa.home.willberg.fi> <1116771818.4628.201.camel@laurel.intra.city-fan.org> Message-ID: <20050522145540.GA20817@jadzia.bu.edu> On Sun, May 22, 2005 at 03:23:38PM +0100, Paul Howarth wrote: > > "Bitlbee is an IRC to other chat networks gateway. bitlbee can be used > > as an IRC server which forwards everything you say to people on other > > chat networks like MSN/ICQ/Jabber." > > The package is taken from Dag's repository. Only changed the dependency > > for xinetd and turned on the service by default. > I thought turning on network-listening services by default was frowned > upon? Yes it sure is. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 73 degrees Fahrenheit. From paul at city-fan.org Sun May 22 15:22:38 2005 From: paul at city-fan.org (Paul Howarth) Date: Sun, 22 May 2005 16:22:38 +0100 Subject: New package: rblcheck In-Reply-To: <200505210800.j4L7xxGa003130@mail.linux-kernel.at> References: <200505210800.j4L7xxGa003130@mail.linux-kernel.at> Message-ID: <1116775358.4628.215.camel@laurel.intra.city-fan.org> On Sat, 2005-05-21 at 10:00 +0200, Oliver Falk wrote: > > rpmlint errors: > > > > rpmlint -iv rblcheck-1.5-6* > [ ... ] > > The directory permission errors are probably due to my user > > account being in a SGID directory, and the installer copying > > the directory permissions. You can fix this by adding: > > > > %{_bindir}/find . -type d -exec chmod 755 {} \; > [ ... ] > Didn't add this as my linting doesn't mention directory permission problems. You wouldn't, but anyone else with a setgid build directory will see this problem. Fortunately there's a better way of fixing it. Change: %defattr(-,root,root) to: %defattr(-,root,root,0755) > [oliver at wasser rblcheck]$ make lint > Wrote: /home/oliver/cvs/rpms/rblcheck/rblcheck-1.5-7.src.rpm > rpmlint rblcheck-1.5-7.src.rpm > E: rblcheck no-signature > > You may have a look at it again... Looks OK now. Paul. -- Paul Howarth From ivazquez at ivazquez.net Sun May 22 15:33:10 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 22 May 2005 11:33:10 -0400 Subject: sqlite2 redux In-Reply-To: <20050522140917.03c97ef1.bugs.michael@gmx.net> References: <1116725980.7161.147.camel@ignacio.ignacio.lan> <20050522140917.03c97ef1.bugs.michael@gmx.net> Message-ID: <1116775990.31705.7.camel@ignacio.ignacio.lan> On Sun, 2005-05-22 at 14:09 +0200, Michael Schwendt wrote: > On Sat, 21 May 2005 21:39:40 -0400, Ignacio Vazquez-Abrams wrote: > > > So now there's a way to install kannel, moodss, et al on FC4, which is > > good. However, these packages will still interfere with upgrading from > > FC3 to FC4, which is bad. > > How do they interfere? Through implicit requires kannel requires, e.g., libsqlite2.so.0. When you upgrade from FC3 to FC4 it tries to replace the sqlite package, removing this file and replacing it with, e.g., libsqlite3.so.0. Obviously it *can't* remove the original package, so it can't install the new one. This then cascades up through python-sqlite and then to yum. While yes, it will be solved by the first 'yum update' that happens (assuming the maintainers get themselves in gear and switch to sqlite2...), if this situation is avoidable with 10 minutes of work then why even have the user encounter it at all? -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From toni at willberg.fi Sun May 22 15:49:46 2005 From: toni at willberg.fi (Toni Willberg) Date: Sun, 22 May 2005 18:49:46 +0300 Subject: New package: bitlbee-0.92 In-Reply-To: <20050522145540.GA20817@jadzia.bu.edu> References: <1116710226.3422.9.camel@ihaa.home.willberg.fi> <1116771818.4628.201.camel@laurel.intra.city-fan.org> <20050522145540.GA20817@jadzia.bu.edu> Message-ID: <1116776986.3422.16.camel@ihaa.home.willberg.fi> On Sun, 2005-05-22 at 10:55 -0400, Matthew Miller wrote: > On Sun, May 22, 2005 at 03:23:38PM +0100, Paul Howarth wrote: > > > "Bitlbee is an IRC to other chat networks gateway. bitlbee can be > used > > > as an IRC server which forwards everything you say to people on > other > > > chat networks like MSN/ICQ/Jabber." > > > The package is taken from Dag's repository. Only changed the > dependency > > > for xinetd and turned on the service by default. > > I thought turning on network-listening services by default was > frowned > > upon? > > Yes it sure is. So you suggest turning it (back) off by default? Even if it binds only to localhost? - Toni From tian at c-sait.net Sun May 22 15:49:54 2005 From: tian at c-sait.net (Christian Jodar) Date: Sun, 22 May 2005 17:49:54 +0200 Subject: Sponsor needed: Christian Jodar Message-ID: <20050522174954.023c1b6e@tianbox> Hello, I will be the maintainer for GCfilms. It has been approved by Ignacio Vazquez-Abrams: https://www.redhat.com/archives/fedora-extras-commits/2005-May/msg01444.html He also imported first version to CVS. If I understand everything, I will now need a CVS access for future versions but also to require a build (which is the final step before repository inclusion). Is that correct? I also have a question about Bugzilla component creation. Do I need to explicitly require Wiki write access to create the request? I did the CLA step and also applied for cvsextras membership with user name Tian. Now I need a sponsor. I already sent a self introduction on the list: https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00037.html But if other details are needed, do not hesitate to let me know about them. > gpg --fingerprint BF2FB628 pub 1024D/BF2FB628 2005-05-02 Christian Jodar (Tian) Key fingerprint = 113D 3265 D3C6 94A1 2E7D CC14 7A57 B9F0 BF2F B628 sub 1024g/B1AF1AF4 2005-05-02 Christian Jodar. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Sun May 22 16:07:23 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 22 May 2005 12:07:23 -0400 Subject: New package: bitlbee-0.92 In-Reply-To: <1116776986.3422.16.camel@ihaa.home.willberg.fi> References: <1116710226.3422.9.camel@ihaa.home.willberg.fi> <1116771818.4628.201.camel@laurel.intra.city-fan.org> <20050522145540.GA20817@jadzia.bu.edu> <1116776986.3422.16.camel@ihaa.home.willberg.fi> Message-ID: <20050522160723.GA22941@jadzia.bu.edu> On Sun, May 22, 2005 at 06:49:46PM +0300, Toni Willberg wrote: > > Yes it sure is. > So you suggest turning it (back) off by default? Even if it binds only > to localhost? Yeah. Instruct people on how to turn it on. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 72 degrees Fahrenheit. From bugs.michael at gmx.net Sun May 22 16:19:51 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 22 May 2005 18:19:51 +0200 Subject: sqlite2 redux In-Reply-To: <1116775990.31705.7.camel@ignacio.ignacio.lan> References: <1116725980.7161.147.camel@ignacio.ignacio.lan> <20050522140917.03c97ef1.bugs.michael@gmx.net> <1116775990.31705.7.camel@ignacio.ignacio.lan> Message-ID: <20050522181951.6e576085.bugs.michael@gmx.net> On Sun, 22 May 2005 11:33:10 -0400, Ignacio Vazquez-Abrams wrote: > > > So now there's a way to install kannel, moodss, et al on FC4, which is > > > good. However, these packages will still interfere with upgrading from > > > FC3 to FC4, which is bad. > > > > How do they interfere? > > Through implicit requires kannel requires, e.g., libsqlite2.so.0. When > you upgrade from FC3 to FC4 it tries to replace the sqlite package, > removing this file and replacing it with, e.g., libsqlite3.so.0. > Obviously it *can't* remove the original package, so it can't install > the new one. This then cascades up through python-sqlite and then to > yum. Ah, as long as Fedora Extras are not upgraded during firstboot, extra packages can get out-of-sync [*]. Yes. However, the first "yum update" should fix that and cause yum to see the SONAME requirement for libsqlite2.so.0 and add sqlite2-2.8.x (from FE4) into the transaction set. [*] The entire range of side-effects this can result in, is not known yet. There are services in Fedora Extras, too, which can be started at reboot and can fail until they are upgraded. > While yes, it will be solved by the first 'yum update' that happens > (assuming the maintainers get themselves in gear and switch to > sqlite2...), if this situation is avoidable with 10 minutes of work then > why even have the user encounter it at all? Can't follow you here, sorry. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1329_FC4 loadavg: 1.36 1.53 1.18 From ivazquez at ivazquez.net Sun May 22 16:25:03 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 22 May 2005 12:25:03 -0400 Subject: sqlite2 redux In-Reply-To: <20050522181951.6e576085.bugs.michael@gmx.net> References: <1116725980.7161.147.camel@ignacio.ignacio.lan> <20050522140917.03c97ef1.bugs.michael@gmx.net> <1116775990.31705.7.camel@ignacio.ignacio.lan> <20050522181951.6e576085.bugs.michael@gmx.net> Message-ID: <1116779103.31705.11.camel@ignacio.ignacio.lan> On Sun, 2005-05-22 at 18:19 +0200, Michael Schwendt wrote: > On Sun, 22 May 2005 11:33:10 -0400, Ignacio Vazquez-Abrams wrote: > > While yes, it will be solved by the first 'yum update' that happens > > (assuming the maintainers get themselves in gear and switch to > > sqlite2...), if this situation is avoidable with 10 minutes of work then > > why even have the user encounter it at all? > > Can't follow you here, sorry. This would involve creating a FC-3 branch for sqlite2 (which I can deal with, mostly) as well as having the FC-3 branches of all dependent packages switching to use sqlite2 instead of sqlite. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Sun May 22 16:40:34 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 22 May 2005 18:40:34 +0200 Subject: sqlite2 redux In-Reply-To: <1116779103.31705.11.camel@ignacio.ignacio.lan> References: <1116725980.7161.147.camel@ignacio.ignacio.lan> <20050522140917.03c97ef1.bugs.michael@gmx.net> <1116775990.31705.7.camel@ignacio.ignacio.lan> <20050522181951.6e576085.bugs.michael@gmx.net> <1116779103.31705.11.camel@ignacio.ignacio.lan> Message-ID: <20050522184034.2b0240e0.bugs.michael@gmx.net> On Sun, 22 May 2005 12:25:03 -0400, Ignacio Vazquez-Abrams wrote: > On Sun, 2005-05-22 at 18:19 +0200, Michael Schwendt wrote: > > On Sun, 22 May 2005 11:33:10 -0400, Ignacio Vazquez-Abrams wrote: > > > While yes, it will be solved by the first 'yum update' that happens > > > (assuming the maintainers get themselves in gear and switch to > > > sqlite2...), if this situation is avoidable with 10 minutes of work then > > > why even have the user encounter it at all? > > > > Can't follow you here, sorry. > > This would involve creating a FC-3 branch for sqlite2 (which I can deal > with, mostly) as well as having the FC-3 branches of all dependent > packages switching to use sqlite2 instead of sqlite. Aha! Renaming the package and the BuildRequires should be trivial. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1329_FC4 loadavg: 1.13 1.23 1.18 From ivazquez at ivazquez.net Sun May 22 16:44:17 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 22 May 2005 12:44:17 -0400 Subject: sqlite2 redux In-Reply-To: <20050522184034.2b0240e0.bugs.michael@gmx.net> References: <1116725980.7161.147.camel@ignacio.ignacio.lan> <20050522140917.03c97ef1.bugs.michael@gmx.net> <1116775990.31705.7.camel@ignacio.ignacio.lan> <20050522181951.6e576085.bugs.michael@gmx.net> <1116779103.31705.11.camel@ignacio.ignacio.lan> <20050522184034.2b0240e0.bugs.michael@gmx.net> Message-ID: <1116780257.31705.13.camel@ignacio.ignacio.lan> On Sun, 2005-05-22 at 18:40 +0200, Michael Schwendt wrote: > On Sun, 22 May 2005 12:25:03 -0400, Ignacio Vazquez-Abrams wrote: > > > On Sun, 2005-05-22 at 18:19 +0200, Michael Schwendt wrote: > > > On Sun, 22 May 2005 11:33:10 -0400, Ignacio Vazquez-Abrams wrote: > > > > While yes, it will be solved by the first 'yum update' that happens > > > > (assuming the maintainers get themselves in gear and switch to > > > > sqlite2...), if this situation is avoidable with 10 minutes of work then > > > > why even have the user encounter it at all? > > > > > > Can't follow you here, sorry. > > > > This would involve creating a FC-3 branch for sqlite2 (which I can deal > > with, mostly) as well as having the FC-3 branches of all dependent > > packages switching to use sqlite2 instead of sqlite. > > Aha! Renaming the package and the BuildRequires should be trivial. My point exactly. Shall I request creation of the FC-3 branch? -- 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 jfontain at free.fr Sun May 22 16:51:07 2005 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Sun, 22 May 2005 18:51:07 +0200 Subject: sqlite2 redux In-Reply-To: <1116725980.7161.147.camel@ignacio.ignacio.lan> References: <1116725980.7161.147.camel@ignacio.ignacio.lan> Message-ID: <4290B87B.60002@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ignacio Vazquez-Abrams wrote: >So now there's a way to install kannel, moodss, et al on FC4, which is >good. However, these packages will still interfere with upgrading from >FC3 to FC4, which is bad. > >What I propose is that sqlite2 gets a FC-3 branch, and that the FE3 >packages that depend on it get modified at the same time for a seamless >update. I'm willing to take on all the work for modifying the packages, >but I would like the current maintainers' permission. > >Just to recap, the packages that are dependent on it are kannel, moodss, >and python-sqlite, correct? moodss only requires sqlite-tcl via explicit requirement and is compatible with both SQLite 2 and 3 versions. moodss-20.0-fc3 no longer requires sqlite-tcl as it is disabled in the sqlite 3 update for FC-3 (according to Ville), although now that I checked only sqlite 2 is in FC3 extras. Thoughts? moodss-20.0-fc4 will require sqlite2-tcl when available, as sqlite-tcl (version 3) is no longer available. Let me know what you think, thanks. - -- Jean-Luc Fontaine http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCkLh6kG/MMvcT1qQRAgfNAJsFfEcKL6LoBA+kY0wwX2AK8KBF6gCglnod DGTvaTxdMwqkis9zzrZdQ70= =qpT3 -----END PGP SIGNATURE----- From bugs.michael at gmx.net Sun May 22 17:08:01 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 22 May 2005 19:08:01 +0200 Subject: sqlite2 redux In-Reply-To: <4290B87B.60002@free.fr> References: <1116725980.7161.147.camel@ignacio.ignacio.lan> <4290B87B.60002@free.fr> Message-ID: <20050522190801.001e2ea6.bugs.michael@gmx.net> On Sun, 22 May 2005 18:51:07 +0200, Jean-Luc Fontaine wrote: > moodss only requires sqlite-tcl via explicit requirement and is > compatible with both SQLite 2 and 3 versions. > moodss-20.0-fc3 no longer requires sqlite-tcl as it is disabled in the > sqlite 3 update for FC-3 (according to Ville), although now that I > checked only sqlite 2 is in FC3 extras. Thoughts? There is no SQLite v3 update for FC3 Extras. The src.rpm imported into CVS was a mistake. Unless somebody really wants to backport FC4's sqlite into FE3, such a release should not be done just for fun. My willingness to go through this "sqlite v2 vs. sqlite v3" once more is not immense. I've examined the dependencies before in an older message to this list. E.g. "kannel" has not been built for FE3. Let Ignacio rename sqlite-2.8.16 to sqlite2-2.8.16 and adjust the existing BuildRequirements accordingly. Whether to build "kannel" for FC3 for the first time, should be left to Matthias. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1329_FC4 loadavg: 1.13 1.21 1.16 From toni at willberg.fi Sun May 22 17:13:03 2005 From: toni at willberg.fi (Toni Willberg) Date: Sun, 22 May 2005 20:13:03 +0300 Subject: New package: libmatchbox-1.7 Message-ID: <1116781983.3422.26.camel@ihaa.home.willberg.fi> "All font and image operations are provided to other Matchbox packages via libmatchbox." I started to package the Matchbox window manager and related packages, this is the common dependency for all Matchbox packages. More to follow after this is cleared. SRPM, md5sum and the specfile: http://toniw.iki.fi/temp/libmatchbox-1.7-1.src.rpm http://toniw.iki.fi/temp/libmatchbox-1.7-1.src.rpm.md5sum.asc http://toniw.iki.fi/temp/libmatchbox.spec upstream: http://projects.o-hand.com/matchbox/ Tested on fedora-release-3.91-1 / x86_64 system. - Toni -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jfontain at free.fr Sun May 22 17:25:05 2005 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Sun, 22 May 2005 19:25:05 +0200 Subject: sqlite2 redux In-Reply-To: <20050522190801.001e2ea6.bugs.michael@gmx.net> References: <1116725980.7161.147.camel@ignacio.ignacio.lan> <4290B87B.60002@free.fr> <20050522190801.001e2ea6.bugs.michael@gmx.net> Message-ID: <4290C071.9070002@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > On Sun, 22 May 2005 18:51:07 +0200, Jean-Luc Fontaine wrote: > >> moodss only requires sqlite-tcl via explicit requirement and is >> compatible with both SQLite 2 and 3 versions. moodss-20.0-fc3 no >> longer requires sqlite-tcl as it is disabled in the sqlite 3 >> update for FC-3 (according to Ville), although now that I checked >> only sqlite 2 is in FC3 extras. Thoughts? > > > There is no SQLite v3 update for FC3 Extras. The src.rpm imported > into CVS was a mistake. Unless somebody really wants to backport > FC4's sqlite into FE3, such a release should not be done just for > fun. > > My willingness to go through this "sqlite v2 vs. sqlite v3" once > more is not immense. I've examined the dependencies before in an > older message to this list. E.g. "kannel" has not been built for > FE3. > > Let Ignacio rename sqlite-2.8.16 to sqlite2-2.8.16 and adjust the > existing BuildRequirements accordingly. Whether to build "kannel" > for FC3 for the first time, should be left to Matthias. Very good. Both moodss-fc3 and moodss-fc4 will require sqlite2-tcl, when available. That will work, right? Many thanks for your help! - -- Jean-Luc Fontaine http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCkMBwkG/MMvcT1qQRAhq6AKCXmAFuz1C4zgHKFXbsaViGDsMRgwCgiXCK YoCh+k1km5s5kpZAhoj8MRQ= =9D7b -----END PGP SIGNATURE----- From toni at willberg.fi Sun May 22 17:59:15 2005 From: toni at willberg.fi (Toni Willberg) Date: Sun, 22 May 2005 20:59:15 +0300 Subject: New package: bitlbee-0.92-3 In-Reply-To: <1116710226.3422.9.camel@ihaa.home.willberg.fi> References: <1116710226.3422.9.camel@ihaa.home.willberg.fi> Message-ID: <1116784755.3422.30.camel@ihaa.home.willberg.fi> ok, new package with suggested modifications: http://toniw.iki.fi/temp/bitlbee-0.92-3.src.rpm http://toniw.iki.fi/temp/bitlbee-0.92-3.src.rpm.md5sum.asc http://toniw.iki.fi/temp/bitlbee.spec - Toni From toni at willberg.fi Sun May 22 19:18:23 2005 From: toni at willberg.fi (Toni Willberg) Date: Sun, 22 May 2005 22:18:23 +0300 Subject: New package: matchbox-window-manager-0.9.4-1 In-Reply-To: <1116781983.3422.26.camel@ihaa.home.willberg.fi> References: <1116781983.3422.26.camel@ihaa.home.willberg.fi> Message-ID: <1116789503.3422.34.camel@ihaa.home.willberg.fi> > I started to package the Matchbox window manager and related packages, > this is the common dependency for all Matchbox packages. More to follow > after this is cleared. And here's the actual window manager package. Depends on libmatchbox. "A window manager with a classic PDA style management policy. Application windows are stacked in a deck, and sized to fill all available screen space. Other window types such as dialogs, panels or input method windows also receive special attention by the window manager to improve usability on physically limited platforms." http://toniw.iki.fi/temp/matchbox-window-manager.spec http://toniw.iki.fi/temp/matchbox-window-manager-0.9.4-1.src.rpm http://toniw.iki.fi/temp/matchbox-window-manager-0.9.4-1.src.rpm.md5sum.asc - Toni -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Jochen at herr-schmitt.de Sun May 22 19:43:31 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Sun, 22 May 2005 21:43:31 +0200 Subject: New Package: kyum In-Reply-To: <20050518200636.020b57d3.bugs.michael@gmx.net> References: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> <4289F654.7090907@city-fan.org> <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> <20050517223520.4de6bc8f.bugs.michael@gmx.net> <0MKwpI-1DYS2e3SIz-0002kY@mrelayeu.kundenserver.de> <20050518200636.020b57d3.bugs.michael@gmx.net> Message-ID: <0MKxQS-1DZwMf0AiV-0004pm@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 18 May 2005 20:06:36 +0200, you wrote: >> I have make a test with GNOME, and I could say the KYUM icon. > >Well, here it not visible: Becouse, I have no idea, why the icon is not shown on your desktop, it will be nice, if you can give me the following information: Screen resolution. Colour depth. Any setting in GNOME, which may effect the size of the displayed icons in the gnome panel. I have compare the kile package with the kyum package. So I have find out, that in the kile package are more icons with different sizes as in the kyum package. I assume, that may be the reason of the icon problem reported by Michael. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.0 (Build 2001) iQA/AwUBQpDg/U9gByurcX4MEQJl8QCffna9Mesfyz+cyfg5WK/3kkpeS7sAoIzd c43I/QjGGMpGEFne/cofg4SS =QluU -----END PGP SIGNATURE----- From bugs.michael at gmx.net Sun May 22 20:28:11 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 22 May 2005 22:28:11 +0200 Subject: New Package: kyum In-Reply-To: <0MKxQS-1DZwMf0AiV-0004pm@mrelayeu.kundenserver.de> References: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> <4289F654.7090907@city-fan.org> <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> <20050517223520.4de6bc8f.bugs.michael@gmx.net> <0MKwpI-1DYS2e3SIz-0002kY@mrelayeu.kundenserver.de> <20050518200636.020b57d3.bugs.michael@gmx.net> <0MKxQS-1DZwMf0AiV-0004pm@mrelayeu.kundenserver.de> Message-ID: <20050522222811.07231021.bugs.michael@gmx.net> On Sun, 22 May 2005 21:43:31 +0200, Jochen Schmitt wrote: > >> I have make a test with GNOME, and I could say the KYUM icon. > > > >Well, here it not visible: > > Becouse, I have no idea, why the icon is not shown on your > desktop, it will be nice, if you can give me the following > information: Can't reproduce it anymore after the updates in Rawhide over the past days. Menu icon is visible now. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1329_FC4 loadavg: 0.89 1.63 0.80 From joost at cnoc.nl Sun May 22 21:00:03 2005 From: joost at cnoc.nl (Joost van der Sluis) Date: Sun, 22 May 2005 23:00:03 +0200 (MEST) Subject: Questions for new package: Freepascal In-Reply-To: <1116614953.4628.179.camel@laurel.intra.city-fan.org> Message-ID: > > So you always have to provide a binary executable, with which the > > compiler could be build. > > > > I could include the compiler-binaries in a second 'source-file' into the > > RPM. That should work. But I dont know if you guys would appreciate > > that. > > You might want to look at the discussion of a similar issue for the ghc > Haskell compiler discussed earlier: > > https://www.redhat.com/archives/fedora-extras-list/2005- > May/msg00450.html Large difference here is that bootstrapping is easy. It's the only way to build Freepascal (fpc) so it has to be done anyway. I see a few options: - The manual compilation into the buildsystem. But in the thread that you mentioned they find that a bad idea. (This is how Debian did it 5 years ago, now each version is bootstrapped from the last version) - Making a seed package with the binary tar's. I personally don't like that option really much. - Make a source package, with the start-conpiler binary from where the bootstrapping can start. (This could be the previous version of the compiler, or the version of the package itself. With that last compiler you don't put 'strange' binary into the system so I would prefer that, while it's not the official bootstrap-mechanism) (This is how Gentoo handles fpc) - Freepascal can compile into a clear assembly file which you can feed to AS. So instead of the binary in the previous option, use the assembly-version. I should choose for the third option. The fourth is also possible. Then you don't put a binary into the system, 'officially'. you But that's more symbolic... Joost van der Sluis. From nicolas.mailhot at laposte.net Sun May 22 22:15:47 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 23 May 2005 00:15:47 +0200 Subject: Updated new package : dejavu-fonts-1.10 In-Reply-To: <428F5FDD.1080308@laposte.net> References: <428F5FDD.1080308@laposte.net> Message-ID: <42910493.3030605@laposte.net> Source: http://mapage.noos.fr/nmailhot/fedora/dejavu-fonts-1.10-1.src.rpm Packages http://mapage.noos.fr/nmailhot/fedora/dejavu-fonts-1.10-1.noarch.rpm Sums: http://mapage.noos.fr/nmailhot/fedora/dejavu-fonts-md5sums.asc http://mapage.noos.fr/nmailhot/fedora/dejavu-fonts-sha1sums.asc Nicolas Mailhot a ?crit : > The DejaVu fonts are derivatives of the well-known Bitstream Vera fonts. > The Bitstream license forbids making modifications to Vera and keep the > Vera name, so all the Vera forks changed it. > > This one seems the most active/open. It's main purpose is to complete > the original Vera with new glyphs, and it's been actively merging > smaller forks for some time. > > The spec is straightforward - it's basically the FC Vera spec with > minimal twists and little automation. > > Review and sponsor needed. > > Source: > http://mapage.noos.fr/nmailhot/fedora/dejavu-fonts-1.9-2.src.rpm > > Packages (built on Fedora Devel): > > http://mapage.noos.fr/nmailhot/fedora/dejavu-fonts-1.9-2.noarch.rpm > > Sums: > > http://mapage.noos.fr/nmailhot/fedora/dejavu-fonts-md5sums.asc > http://mapage.noos.fr/nmailhot/fedora/dejavu-fonts-sha1sums.asc Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From toshio at tiki-lounge.com Sun May 22 23:57:58 2005 From: toshio at tiki-lounge.com (Toshio) Date: Sun, 22 May 2005 19:57:58 -0400 Subject: Extras Rebuild? In-Reply-To: <20050522140525.303df651.bugs.michael@gmx.net> References: <20050521093037.A12984@tiki-lounge.com> <20050521193644.48e8d555.bugs.michael@gmx.net> <20050521184240.A22335@tiki-lounge.com> <20050522140525.303df651.bugs.michael@gmx.net> Message-ID: <1116806283.16198.194.camel@Madison.badger.com> On Sun, 2005-05-22 at 14:05 +0200, Michael Schwendt wrote: > On Sat, 21 May 2005 18:42:40 -0700, Toshio Kuratomi wrote: [Note -- heavy snippage/some rearranging. If I left anything out, or changed the meaning, please be sure to bring it up.] My goal is to know what packages have problems and what the level of problem is. A package that has been imported into the repository from FC3 and not rebuilt could be fine, fine once rebuilt, or broken once rebuilt. But we don't know which of these states a package is in right now. The reason I asked if we were going to have an automated rebuild is so we could determine this WRT packages whose current FE-devel version is broken (presumably because it's last build was too far in the past) and who have no bugzilla entry to tell us what's going on:: > [...] whatever failed to rebuild on April 7th exists in the repository as a > copied FC3 binary. Based on this, I should be able to write a script that tells if a package is in an unknown state: 1) Compare date of packages. If April 7th or older, then check if there's a bugzilla entry for build failure. If not, open a bugzilla ticket that says not-built for FC4 devel. Can you confirm that this criteria will catch not-compiled with gcc4, not synced packages, and anything else that could cause problems when the package is built on FC4? Would it be most productive to target rebuilds at these pre-April 7th packages or does filing in bugzilla for the package maintainer to take care of them make more sense? > > The major problem in my mind being that previous rebuilds didn't > > result in bugzilla bugs being filed. > > Right. But notice that we imported Seth's build failure report into the > Wiki for tracking purposes, and later on I filed a bug report about every > package on that list. The FE4Target tracker depends on all those bugs > plus other issues, such as crashes. > [...] > Or let me ask a question: what other packages should be added to > bug 157183? > scorched3d is my only example ATM. It has no bugzilla entry. It was reported on Bill's list of mismatched packages. It appears to be one of the "copied from FC3" packages. That's two empty bugzilla searches (check tracker, check for scorched3d targetted bugs), one email search, and a perusal of download.fedora.redhat.com later. And I still haven't looked for the (possibly non-existent) build logs. Maybe the imported from FC3 packages are the only places where bugzilla was not filled in? > > Is the package available on all architectures and has been rebuilt at a > > sufficiently recent date that all its buildrequirements had been updated > > to a final enough version. > > That assumes that [minor] version upgrades introduced ABI/API > incompatibility without the package owner paying attention to it. Can you > provide any examples? > Nope. But it has been known to happen that a bugfix causes other, unforeseen problems. To make sure that this hasn't happened we need to be sure we've compiled against recent enough versions of the tools. Note: I'm speaking less of libraries (which can usu. be replaced with bugfixed ones later) as the compiler, linker, and other tools that compile source into the binaries that go into the rpm. > > > Bill Nottingham some days ago posted a list of Extras packages to > > > maintainers-list, which need a rebuild, because of version mismatches on > > > the three archs we build for. We should assume that package maintainers > > > have noticed that list. > > > > > But it wasn't. Or maintainers don't all have enough time to work on them. > > "Bump release, make tag, make build" is all that would be needed. > This is more an empirical observation: either the list hasn't been noticed or there is some constraint preventing some of these packages from being fixed. But it's not bugzilla'd so there's no easy way to tell. Also, how is "bump,tag,build" superior to a targeted automated rebuild that dropped build failures into bugzilla? Isn't your argument against automated rebuilds that a maintainer needs to check buildrequires against the new FC and run tests to see if there's any change in runtime behaviour? In other words, do things above and beyond, bump, tag, build? > > We need to have these filed in bugzilla and become a dependency of the > > FE4Tracker bug so the community can take a look at these problems. > > Are these due to "problems"? I still think most of the version mismatches > are due to missing powerpc build support earlier on. > > For the noarch cases, packages have been copied over. A series of > other packages has been rebuilt for all archs meanwhile. > They're symptoms of a problem: If the package has not been rebuilt recently enough to be rebuilt for all the arches, then it may suffer from other problems as well. In scorched3d's case, I started a rebuild and found that it additionally needs fixing on 64bit platforms b/c gcc4 throws errors instead of warnings on some broken code. The lack of rebuild masked compile-time issues. Seeing the package in the not- sync'd list points out that this possibility has not been checked. > > > In addition to that, the FE4Target tracker contains a list of broken > > > packages, which failed to rebuild for FC4 or which fail due to serious > > > defects. These are issues a mass rebuild is unlikely to fix. As some of us > > > have attached patches to some of the bugs, how long do we wait for a > > > reaction from the package owner? > > > > > Email the owner. Try to get one other person to review the change. > > Eventually merge yourself. We need to evolve some policy here. To be > > useful for FC4, though, we need to come up with something sane quickly > > as we need to merge those fixes and test them. > > The thing here is, bugzilla tickets are _assigned to_ the package owner > and _mailed to_ the package owner. So, that is a way already to address > the package owner. Assume that package owners do see your bug report and > your attachments (if any) and could add a comment like "go ahead with > the fix" or set status to ASSIGNED to give you some feedback. > And when the package maintainer does not respond to bugzilla mail a direct email that explains the patch and asks for permission to apply will often get a response. Perhaps we need to change our culture to promote rapid responses to bugzilla mail and slower responses to personal mail :-) I completely missed the main thrust of your statement, though -- that an automated rebuild wouldn't pull these packages out of bugzilla and merge them. That's entirely correct. I'm in favor of a targetted rebuild of packages which don't have failure information in bugzilla. I mentioned an automated mass rebuild in my initial message because I remembered a thread mentioning that was going to happen and people were debating when. I must have missed the end of the thread where the idea was nixed. > It [FE4Tracker] _could_ influence when to make available the current devel > repository in an "extras/4" channel. That would not be fair, though, since > some contributors make sure their packages are ready, and other packagers > perhaps depend on upstream projects catching up with API changes. > I don't think making the devel repository into extras/4 is a good idea. It'll compound the fact that we copied packages from the FE3 tree in with things built early in the FC4 cycle not running on FE4-final. Maintainers should request their packages be built for the FE4 repository explicitly. > > For Extras in its present incarnation, it makes more sense to have > > per-package trackers. If a package has remaining issues, it doesn't > > make it into the FEx repository. > > That is the reason why I didn't like it when the public repository was > filled with copies of FC3 binaries without a guide for the packagers when > to rebuild their packages. We should have built Fedora Extras Development > from scratch, since the only thing we depend on is Fedora Core (well, > except for future programming language packages which need bootstrapping). > I agree 100%. I'd agree 200% if there were two of me. I think ghc is the only present package in FE that needs bootstrapping. Everything else is rooted in Core. So going forward, we should keep a list of such packages and only push those to the next version's repository:: http://www.fedoraproject.org/wiki/Extras/PackagesNeedingBootstrap > > Among other things, this means build failures should go in bugzilla (perhaps > > the buildsystem can do this just as it emails out failures. The problem is > > a bit harder than email as we probably want to update older build failures > > rather than create new ones and close out old ones when the build succeeds. > > Perhaps an approach such as having a buildsystem bugzilla account be the > > submitter or a BUILDFAIL keyword.) The bugzilla tickets can be used to > > track the current status of a package. > > Here once more: if Fedora Extras wants to scale, every package should have > at least one person taking care of it. Build requests are done by human > beings. Build status reports are mailed back to human beings. It is > assumed that the person, who requests a build, does something useful with > a build failure log and e.g. decides whether it should be tracked in > bugzilla, because it might take some time until it is fixed. > I'm not arguing with the mainainer >= 1 concept. I'm asking for public and centralized information. And I'm asking that this availability of information be as automated as possible to avoid human fallibility (think absent release announcements for FC updates). The reason I'm asking for this is to make it easier on the community members who will end up assisting the package maintainers. The "if you have an itch, scratch it" people. We should make it easy to find out a package's current state and what direction a maintainer is taking to fix it. Having the buildsystem open, update, and close bugs on build failure/success means we can free up mschwendt to do more important things than copy build-log URLs into a bunch of very similar bugzilla tickets :-) > > The packages that are currently out of sync, > > imported to the devel tree but not rebuilt, etc aren't all being tracked so > > it takes effort for a non-maintainer (or maintainer of many (too many?) > > packages to figure out what stll needs fixing. > > That's why we need a roadmap. It's the maintainer's responsibility to > (re)build packages in preparation for FE4. > > Basically, for each package in the devel repo, which is out-of-sync with > devel CVS, somebody would need to make sure that it is really the right > version that shall be built and released. It's the packager who would tag > that version and request a build. I mean, we don't want to build something > without the "okay" from the package owner and possibly create a situation > where a released binary must be pulled from the repo because it was a > premature version upgrade that wasn't meant to be built. > Okay. Here's my proposal. Tear it apart: FE4 repository will open after FC4 repository is available to the build system. Package maintainers or their designates are responsible for requesting package builds so the built packages can be imported into the FE4 repository. Package maintainers whose packages haven't been rebuilt since April 7th or under the new buildsystem will probably want to submit their packages to be built ASAP so there aren't too many surprises when the new repository opens. Packages failing builds or with runtime issues should be placed into bugzilla and added to the FE4Tracker if you want other community members to help you fix things. -Toshio -- toshio \ Questions for the Would Morticia wear it? @tiki- \ 21st Century! Would it look better on me? lounge.com=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Mon May 23 00:38:00 2005 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 22 May 2005 20:38:00 -0400 Subject: Extras Rebuild? In-Reply-To: <1116806283.16198.194.camel@Madison.badger.com> References: <20050521093037.A12984@tiki-lounge.com> <20050521193644.48e8d555.bugs.michael@gmx.net> <20050521184240.A22335@tiki-lounge.com> <20050522140525.303df651.bugs.michael@gmx.net> <1116806283.16198.194.camel@Madison.badger.com> Message-ID: <1116808680.4292.15.camel@bree.local.net> FYI -- I took a pass through what's currently in the Extras development tree to find things which are either a) missing on an arch b) different versions between arches. I've then bumped releases and kicked off a lot of builds to try to help fix this. Once the builds are all done, I'll send mail and file bugs for all that fail and then hopefully we'll be able to get a better handle on things. Jeremy From ivazquez at ivazquez.net Mon May 23 04:00:14 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 23 May 2005 00:00:14 -0400 Subject: sqlite2 redux In-Reply-To: <20050522190801.001e2ea6.bugs.michael@gmx.net> References: <1116725980.7161.147.camel@ignacio.ignacio.lan> <4290B87B.60002@free.fr> <20050522190801.001e2ea6.bugs.michael@gmx.net> Message-ID: <1116820814.3090.4.camel@ignacio.ignacio.lan> On Sun, 2005-05-22 at 19:08 +0200, Michael Schwendt wrote: > On Sun, 22 May 2005 18:51:07 +0200, Jean-Luc Fontaine wrote: > > > moodss only requires sqlite-tcl via explicit requirement and is > > compatible with both SQLite 2 and 3 versions. > > moodss-20.0-fc3 no longer requires sqlite-tcl as it is disabled in the > > sqlite 3 update for FC-3 (according to Ville), although now that I > > checked only sqlite 2 is in FC3 extras. Thoughts? > > There is no SQLite v3 update for FC3 Extras. The src.rpm imported into CVS > was a mistake. Unless somebody really wants to backport FC4's sqlite into > FE3, such a release should not be done just for fun. I fully acknowledge that importing the sqlite 3 package was a hasty action, and am not currently interested in building it for FC3. > My willingness to go through this "sqlite v2 vs. sqlite v3" once more > is not immense. I've examined the dependencies before in an older > message to this list. E.g. "kannel" has not been built for FE3. > > Let Ignacio rename sqlite-2.8.16 to sqlite2-2.8.16 and adjust the existing > BuildRequirements accordingly. Whether to build "kannel" for FC3 for the > first time, should be left to Matthias. In that case I will request a FC-3 branch for sqlite2 and the other maintainers can do as they please. -- 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 oliver at linux-kernel.at Mon May 23 07:22:10 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 23 May 2005 09:22:10 +0200 Subject: New package: rblcheck In-Reply-To: <1116775358.4628.215.camel@laurel.intra.city-fan.org> Message-ID: <200505230721.j4N7LJ2k002351@mail.linux-kernel.at> Paul Howarth wrote: > On Sat, 2005-05-21 at 10:00 +0200, Oliver Falk wrote: > > > rpmlint errors: > > > > > > rpmlint -iv rblcheck-1.5-6* > > [ ... ] > > > The directory permission errors are probably due to my > > > user account > > > being in a SGID directory, and the installer copying the > > > directory > > > permissions. You can fix this by adding: > > > > > > %{_bindir}/find . -type d -exec chmod 755 {} \; > > [ ... ] > > Didn't add this as my linting doesn't mention directory > > permission problems. > > You wouldn't, but anyone else with a setgid build directory > will see this problem. Fortunately there's a better way of > fixing it. Change: > > %defattr(-,root,root) > > to: > > %defattr(-,root,root,0755) > > > [oliver at wasser rblcheck]$ make lint > > Wrote: /home/oliver/cvs/rpms/rblcheck/rblcheck-1.5-7.src.rpm > > rpmlint rblcheck-1.5-7.src.rpm > > E: rblcheck no-signature > > > > You may have a look at it again... > > Looks OK now. OK. Release 8 is uploaded. With the defattr fix. (http://t.linux-kernel.at/s.pl?4a) Best, Oliver From bugs.michael at gmx.net Mon May 23 10:29:33 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 23 May 2005 12:29:33 +0200 Subject: Extras Rebuild? In-Reply-To: <1116806283.16198.194.camel@Madison.badger.com> References: <20050521093037.A12984@tiki-lounge.com> <20050521193644.48e8d555.bugs.michael@gmx.net> <20050521184240.A22335@tiki-lounge.com> <20050522140525.303df651.bugs.michael@gmx.net> <1116806283.16198.194.camel@Madison.badger.com> Message-ID: <20050523122933.4838e0c4.bugs.michael@gmx.net> On Sun, 22 May 2005 19:57:58 -0400, Toshio wrote: > > [...] whatever failed to rebuild on April 7th exists in the repository as a > > copied FC3 binary. > > Based on this, I should be able to write a script that tells if a > package is in an unknown state: > 1) Compare date of packages. If April 7th or older, then check if > there's a bugzilla entry for build failure. If not, open a bugzilla > ticket that says not-built for FC4 devel. That would not be entirely correct. A package may have been built one or two weeks earlier or is noarch and doesn't need another rebuild. > > Right. But notice that we imported Seth's build failure report into the > > Wiki for tracking purposes, and later on I filed a bug report about every > > package on that list. The FE4Target tracker depends on all those bugs > > plus other issues, such as crashes. > > [...] > > Or let me ask a question: what other packages should be added to > > bug 157183? > > > scorched3d is my only example ATM. It has no bugzilla entry. It was rebuilt on April 11th for i386, but the x86_64 binary is still from Jan 25th, the ppc binary is non-existant. It was not reported as failing for those two archs, so some information was lost. See list archives, April 11th, subject "Fedora Extras Development Package Report". > Also, how is "bump,tag,build" superior to a targeted automated rebuild > that dropped build failures into bugzilla? * maintainer is the one to decide whether to rebuild or whether to apply an upstream update and/or other fixes first * maintainer gets notified whether the build was successful * maintainer can take action and fix reported build failures without the overhead of opening/closing bugzilla tickets > Isn't your argument against > automated rebuilds that a maintainer needs to check buildrequires > against the new FC and run tests to see if there's any change in runtime > behaviour? In other words, do things above and beyond, bump, tag, > build? It's rather pointless, so close to FC4, to keep rebuilding and using existing Extras src.rpms in an automated way only to get a version upgrade from the package owner after FC4 is released. An early mass rebuild, e.g. to fill a publicly accessible repository or to make a C++ ABI jump, is something different. It can make sense as a quickstart. Later on during a development cycle, package maintainers would do further preparations. Well, that's my point of view. YMMV. > > The thing here is, bugzilla tickets are _assigned to_ the package owner > > and _mailed to_ the package owner. So, that is a way already to address > > the package owner. Assume that package owners do see your bug report and > > your attachments (if any) and could add a comment like "go ahead with > > the fix" or set status to ASSIGNED to give you some feedback. > > > And when the package maintainer does not respond to bugzilla mail a > direct email that explains the patch and asks for permission to apply > will often get a response. Perhaps we need to change our culture to > promote rapid responses to bugzilla mail and slower responses to > personal mail :-) Well, communication in bugzilla should just work. Imagine a ticket is marked "security" or "blocker". Every packager would want to not miss bugzilla e-mail, whereas private mail may be subject to accidental spam filtering. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1329_FC4 loadavg: 1.40 1.25 0.89 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon May 23 11:21:47 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 23 May 2005 13:21:47 +0200 Subject: uqm update - RFC for uqm-content* In-Reply-To: <1116756837.32359.125.camel@bobcat.mine.nu> References: <1116756837.32359.125.camel@bobcat.mine.nu> Message-ID: <20050523132147.71db0a37@python2> Ville Skytt? wrote : > [1] Cases like this make me wonder whether it would be a possible to > host all noarch stuff in a noarch repository shared between i386, x86_64 > and ppc instead of having copies of all of this in each. Or maybe not > not _all_ noarch, but a "data" repository for cases where size matters. > In addition to uqm-content*, torcs-data* and various other noarchs at > the top of the listing at > http://fedoraproject.org/extras/3/i386/?C=S;O=D would be good > candidates. Aren't all .noarch packages hardlinked already between the different trees? Isn't that enough in order to save disk space? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.27_FC3 Load : 0.90 0.70 0.53 From radekvokal at gmail.com Mon May 23 11:23:34 2005 From: radekvokal at gmail.com (Radek =?ISO-8859-1?Q?Vok=E1l?=) Date: Mon, 23 May 2005 13:23:34 +0200 Subject: New package: scli Message-ID: <1116847414.3253.13.camel@garfield.redhat.usu> Package: scli Homepage: http://www.ibr.cs.tu-bs.de/projects/scli/ Description: The scli package was written as simple tool for monitoring and configuring network devices and host systems. The scli package is based on the SNMP management protocol. Generic SNMP tools such as MIB browsers or simple command line tools (e.g. snmpwalk) are hard to use since they expose too many protocol details. And in most cases, they fail to present the information in a format that is easy to read and understand. The scli package was designed to be extensible. Additional modes that extend the capabilities of the tools can easily be added. The smidump MIB compiler hides all the SNMP protocol details so that every C programmer can implement new modes. In fact, we like to encourage users to write and contribute new modes so that the package becomes more and more valuable. Location: http://people.redhat.com/rvokal/scli/ Radek -- Radek Vok?l From tcallawa at redhat.com Mon May 23 14:32:32 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 23 May 2005 09:32:32 -0500 Subject: request for review: qgo In-Reply-To: References: Message-ID: <1116858752.29938.28.camel@localhost.localdomain> On Thu, 2005-05-19 at 21:52 -0400, Chris Ricker wrote: > On Thu, 19 May 2005, Chris Ricker wrote: > > > > > New rev for review at > > > > Updated to fix a directory not being owned by the rpm Review of qgo: Rpmlint tests: qgo-1.0.1-2.src.rpm: E: qgo no-signature qgo-1.0.1-2.i386.rpm: E: qgo no-signature All rpmlint errors can be safely ignored. Good: - Source matches upstream - License OK (GPL), COPYING included in package - Meets PackageNamingGuidelines - No missing BuildRequires - Desktop file properly installed Approved. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Mon May 23 14:34:31 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 23 May 2005 09:34:31 -0500 Subject: Icecast In-Reply-To: <20050520120339.7b83437f.bugs.michael@gmx.net> References: <1116543437.4695.15.camel@localhost> <1116555268.7161.96.camel@ignacio.ignacio.lan> <20050520120339.7b83437f.bugs.michael@gmx.net> Message-ID: <1116858871.29938.29.camel@localhost.localdomain> On Fri, 2005-05-20 at 12:03 +0200, Michael Schwendt wrote: > On Thu, 19 May 2005 23:23:03 -0400 (EDT), Chris Ricker wrote: > > > On Thu, 19 May 2005, Ignacio Vazquez-Abrams wrote: > > > > > > It might be something better added to livna, just because an extras > > > > version would have to be ogg-only > > > > > > I thought icecast was format-agnostic and it depended on ices for > > > actually creating the stream (which my repo happens to have the Vorbis > > > version for). > > > > ices (or other clients) creates the streams, but icecast reads them and > > writes them. It has various sorta-plugin handlers which understand the > > various formats it supports to allow it to do that. See > > src/format_{mp3,ogg,theora,vorbis}.{c,h}. > > > > It's not really clear to me if what format_mp3.c does would be infringing, > > or if it's more along the lines of, say, all the id3-tag stuff that's > > already in FC / FE > > There is no mp3 codec implemented in there, just plugin infrastructure > and icy-metadata stuff. If icecast isn't encoding or decoding mp3 files, then it isn't touching on the patents, and should be fine for FE. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Mon May 23 14:46:51 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 23 May 2005 09:46:51 -0500 Subject: New package: eet In-Reply-To: <1116566243.7161.106.camel@ignacio.ignacio.lan> References: <1116566243.7161.106.camel@ignacio.ignacio.lan> Message-ID: <1116859612.29938.40.camel@localhost.localdomain> On Fri, 2005-05-20 at 01:17 -0400, Ignacio Vazquez-Abrams wrote: > eet: A library designed to write an arbitrary set of chunks of data to a > file > > EET is a tiny library designed to write an arbitary set of chunks of > data to a file and optionally compress each chunk (very much like a zip > file) and allow fast random-access reading of the file later on. > > http://fedora.ivazquez.net/files/eet-0.9.10.007-1.fc3.src.rpm Review of eet: Rpmlint tests: eet-0.9.10.007-1.src.rpm: E: eet no-signature eet-0.9.10.007-1.i386.rpm: E: eet executable-in-library-package /usr/bin/eet E: eet zero-length /usr/share/doc/eet-0.9.10.007/ChangeLog E: eet zero-length /usr/share/doc/eet-0.9.10.007/NEWS E: eet no-signature eet-devel-0.9.10.007-1.i386.rpm E: eet-devel requires-on-release eet 0.9.10.007-1 W: eet-devel no-major-in-name eet-devel W: eet-devel no-documentation E: eet-devel no-signature No need to include zero-length ChangeLog and NEWS files. All other rpmlint errors can be ignored. Good: - Source matches upstream - License OK (MIT), COPYING included in package - Libraries have ldconfig in %post/%postun - Meets PackageNamingGuidelines - Meets PackagingGuidelines - *.la files removed - No missing BuildRequires (glibc-headers brought in by gcc) Bad: - Zero-length ChangeLog and NEWS files in main package. Fix the really minor blocker, and its approved. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Mon May 23 15:15:28 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 23 May 2005 10:15:28 -0500 Subject: Updated new package : dejavu-fonts-1.10 In-Reply-To: <42910493.3030605@laposte.net> References: <428F5FDD.1080308@laposte.net> <42910493.3030605@laposte.net> Message-ID: <1116861329.29938.52.camel@localhost.localdomain> On Mon, 2005-05-23 at 00:15 +0200, Nicolas Mailhot wrote: > Source: > http://mapage.noos.fr/nmailhot/fedora/dejavu-fonts-1.10-1.src.rpm Review of dejavu-fonts: Rpmlint checks: dejavu-fonts-1.10-1.src.rpm: W: dejavu-fonts invalid-license Redistributable, with restrictions E: dejavu-fonts no-signature W: dejavu-fonts strange-permission dejavu-fonts.spec 0600 W: dejavu-fonts strange-permission dejavu-ttf-1.10.tar.gz 0600 dejavu-fonts-1.10-1.noarch.rpm: W: dejavu-fonts invalid-license Redistributable, with restrictions E: dejavu-fonts no-signature All rpmlint errors can be safely ignored. Good: - Source matches upstream - License is ok (Redistributable, with restrictions). This is basically a BSD license with a naming restriction, but since bitstream-vera-fonts is in FC, this license is ok. LICENSE included in package. - scriptlets look ok. - Meets PackageNamingGuidelines - Meets PackagingGuidelines Bad: - Missing Requires: fontconfig (is there ever a scenario where we don't want fc-cache to run on %post?) ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From paul at all-the-johnsons.co.uk Mon May 23 15:18:41 2005 From: paul at all-the-johnsons.co.uk (Paul Johnson) Date: Mon, 23 May 2005 16:18:41 +0100 Subject: Addling in linux-wlan-ng to extras Message-ID: <1116861521.4600.39.camel@localhost.localdomain> Hi, >From what I can see, there shouldn't be a problem adding linux-wlan-ng into extras and it would certainly be useful. The only problem I can see is that due to the configuration options, plx, usb, pcmcia and pci builds are able to be made (or indeed, any combination of them) which may mean different rpms for each driver and the configuration script may be problematic. Any thoughts on this? TTFN Paul -- "He's not the Messiah, he's a very naughty boy" - Life of Brian, Monty Python From Jochen at herr-schmitt.de Mon May 23 15:28:28 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 23 May 2005 17:28:28 +0200 Subject: New Package: kyum In-Reply-To: <20050522222811.07231021.bugs.michael@gmx.net> References: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> <4289F654.7090907@city-fan.org> <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> <20050517223520.4de6bc8f.bugs.michael@gmx.net> <0MKwpI-1DYS2e3SIz-0002kY@mrelayeu.kundenserver.de> <20050518200636.020b57d3.bugs.michael@gmx.net> <0MKxQS-1DZwMf0AiV-0004pm@mrelayeu.kundenserver.de> <20050522222811.07231021.bugs.michael@gmx.net> Message-ID: <0MKwh2-1DaErA2CsL-0002gs@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 22 May 2005 22:28:11 +0200, you wrote: >Can't reproduce it anymore after the updates in Rawhide over the past >days. Menu icon is visible now. Thank you for the good news. I have built a new source RPM and have uploaded it to: http://www.herr-schmitt.de/pub/kyum/kyum-0.6.3-3.src.rpm The only known issue which shouldl be stay in the package is the fact, that the upstream package contains the source tree twice. I have forwarded this issue to the upstream author. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.0 (Build 2001) iQA/AwUBQpH2qk9gByurcX4MEQKEtgCeIgAF/BmB8Wywlnyaq4RLXi53s40AoILY L4CG3qZOgBKIUEEX6EDJiP6c =5ihU -----END PGP SIGNATURE----- From fedora at camperquake.de Mon May 23 15:29:25 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 23 May 2005 17:29:25 +0200 Subject: Addling in linux-wlan-ng to extras In-Reply-To: <1116861521.4600.39.camel@localhost.localdomain> References: <1116861521.4600.39.camel@localhost.localdomain> Message-ID: <20050523152925.GA7792@ryoko.camperquake.de> On Mon, May 23, 2005 at 04:18:41PM +0100, Paul Johnson wrote: > Any thoughts on this? I have never understood why two different approaches to wlan exist in Linux. Why can not all drivers be in the kernel and be managed by iwconfig and friends? From paul at all-the-johnsons.co.uk Mon May 23 15:35:47 2005 From: paul at all-the-johnsons.co.uk (Paul Johnson) Date: Mon, 23 May 2005 16:35:47 +0100 Subject: Addling in linux-wlan-ng to extras In-Reply-To: <20050523152925.GA7792@ryoko.camperquake.de> References: <1116861521.4600.39.camel@localhost.localdomain> <20050523152925.GA7792@ryoko.camperquake.de> Message-ID: <1116862547.4600.41.camel@localhost.localdomain> Hi, > > Any thoughts on this? > > I have never understood why two different approaches to wlan exist > in Linux. Why can not all drivers be in the kernel and be managed > by iwconfig and friends? No idea. It is a pain in the backside though! TTFN Paul -- "He's not the Messiah, he's a very naughty boy" - Life of Brian, Monty Python From ivazquez at ivazquez.net Mon May 23 15:36:59 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 23 May 2005 11:36:59 -0400 Subject: Addling in linux-wlan-ng to extras In-Reply-To: <1116861521.4600.39.camel@localhost.localdomain> References: <1116861521.4600.39.camel@localhost.localdomain> Message-ID: <1116862619.3090.17.camel@ignacio.ignacio.lan> On Mon, 2005-05-23 at 16:18 +0100, Paul Johnson wrote: > Hi, > > >From what I can see, there shouldn't be a problem adding linux-wlan-ng > into extras and it would certainly be useful. The only problem I can see > is that due to the configuration options, plx, usb, pcmcia and pci > builds are able to be made (or indeed, any combination of them) which > may mean different rpms for each driver and the configuration script may > be problematic. > > Any thoughts on this? Unfortunately no concrete mechanism has been decided on for providing modules in Extras, but I have my own format/specification if anyone wants to look. It uses a chroot install of the kernel-devel packages (which needs some massaging unfortunately due to build being an absolute link). -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- %{!?kernelroot: %define kernelroot "" } %{!?kernelversion: %define kernelversion %(uname -r) } Name: kernel-module-qla4xxx Version: 5.00.02 Release: 2 Summary: Driver for QLogic QLA4xxx iSCSI cards Group: System Environment/Base License: GPL URL: http://www.qlogic.com/ Source0: http://download.qlogic.com/drivers/27588/qla4xxx-5.00.02.tar.gz Patch: qla4xxx-5.00.02-inline.patch Patch1: qla4xxx-5.00.02-build.patch BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) ExclusiveArch: i586 i686 x86_64 %description This package contains the driver for QLogic's QLA4xxx series of iSCSI cards. %package %{kernelversion} Summary: Driver for QLogic QLA4xxx iSCSI cards Group: System Environment/Base Provides: %{name} = %{version} %description %{kernelversion} This package contains the driver for QLogic's QLA4xxx series of iSCSI cards for kernel %{kernelversion} for the %{_target_cpu} architecture. %prep %setup -q -n 5.00.02 chmod u+x extras %patch -p1 -b .inline %patch1 -p1 -b .build %build K_LIBS=%{kernelroot}/lib/modules/%{kernelversion} extras/build.sh %install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT/lib/modules/%{kernelversion}/kernel/drivers/scsi/qla4xxx install -m 0644 qla4xxx.ko $RPM_BUILD_ROOT/lib/modules/%{kernelversion}/kernel/drivers/scsi/qla4xxx %clean rm -rf $RPM_BUILD_ROOT %post %{kernelversion} depmod -ae %postun %{kernelversion} if [ $1 -eq 0 ]; then depmod -aq fi %files %{kernelversion} %defattr(-,root,root,-) %doc ../release.txt revision.notes /lib/modules/%{kernelversion}/kernel/drivers/scsi/qla4xxx/qla4xxx.ko %changelog * Sun May 22 2005 Ignacio Vazquez-Abrams 5.00.02-2 - Fixed small %%build error - Fixed typos * Fri May 20 2005 Ignacio Vazquez-Abrams 5.00.02-1 - Initial RPM release -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mike at flyn.org Mon May 23 15:39:41 2005 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 23 May 2005 10:39:41 -0500 (CDT) Subject: Addling in linux-wlan-ng to extras In-Reply-To: <20050523152925.GA7792@ryoko.camperquake.de> References: <1116861521.4600.39.camel@localhost.localdomain> <20050523152925.GA7792@ryoko.camperquake.de> Message-ID: <3688.66.151.13.180.1116862781.squirrel@zero.voxel.net> >> Any thoughts on this? > I have never understood why two different approaches to wlan exist > in Linux. Why can not all drivers be in the kernel and be managed > by iwconfig and friends? I agree. The iwconfig-type drivers seem to be the way to go. But the fact is a lot of us are stuck with these chipsets and no one is ready to reimplement them. It would be nice to see the linux-wlan-ng drivers in Fedora Extras. See also: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146610 -- Mike From fedora at leemhuis.info Mon May 23 16:09:42 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 23 May 2005 18:09:42 +0200 Subject: Addling in linux-wlan-ng to extras In-Reply-To: <1116861521.4600.39.camel@localhost.localdomain> References: <1116861521.4600.39.camel@localhost.localdomain> Message-ID: <1116864582.5441.8.camel@notebook.thl.home> Am Montag, den 23.05.2005, 16:18 +0100 schrieb Paul Johnson: > From what I can see, there shouldn't be a problem adding linux-wlan-ng > into extras and it would certainly be useful. The only problem I can see > is that due to the configuration options, plx, usb, pcmcia and pci > builds are able to be made (or indeed, any combination of them) which > may mean different rpms for each driver and the configuration script may > be problematic. > > Any thoughts on this? IMHO we should not provide kernel modules like this in Fedora Extras at all. Fedora Core kernel/davej rejects drivers like this afaik with "get it applied upstream" -- imho in 99% of the cases that's correct. So imho we should not undermine this decision. On the other hand: People need this drivers. So we should do our best to prepare them so they can install them easily. Maybe livna would be a better place for this type of drivers, even if they are "free". ndiswrapper, ipw2[12]00-firmware (and maybe madwifi) should hit it soon also so all these wlan-stuff would be in one place. Just my 2 cent -- Thorsten Leemhuis From tcallawa at redhat.com Mon May 23 16:25:49 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 23 May 2005 11:25:49 -0500 Subject: Addling in linux-wlan-ng to extras In-Reply-To: <1116862619.3090.17.camel@ignacio.ignacio.lan> References: <1116861521.4600.39.camel@localhost.localdomain> <1116862619.3090.17.camel@ignacio.ignacio.lan> Message-ID: <1116865550.29938.69.camel@localhost.localdomain> On Mon, 2005-05-23 at 11:36 -0400, Ignacio Vazquez-Abrams wrote: > On Mon, 2005-05-23 at 16:18 +0100, Paul Johnson wrote: > > Hi, > > > > >From what I can see, there shouldn't be a problem adding linux-wlan-ng > > into extras and it would certainly be useful. The only problem I can see > > is that due to the configuration options, plx, usb, pcmcia and pci > > builds are able to be made (or indeed, any combination of them) which > > may mean different rpms for each driver and the configuration script may > > be problematic. > > > > Any thoughts on this? > > Unfortunately no concrete mechanism has been decided on for providing > modules in Extras, The primary blocker for kernel-module-* packages is that yum does not currently supports handling of kernel-module-* packages. Basically, there is no way to safely upgrade a kernel-module package that is built for the same kernel version. If that gets fixed, I think we can beat out the remainder of the issues. Ville did a lot of them already. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From toni at willberg.fi Mon May 23 16:36:55 2005 From: toni at willberg.fi (Toni Willberg) Date: Mon, 23 May 2005 19:36:55 +0300 Subject: New package: matchbox-panel-0.9.2-1 In-Reply-To: <1116781983.3422.26.camel@ihaa.home.willberg.fi> References: <1116781983.3422.26.camel@ihaa.home.willberg.fi> Message-ID: <1116866215.3346.5.camel@ihaa.home.willberg.fi> "matchbox-panel" is the panel for the Matchbox window manager. Package depends on libmatchbox, please review it first. http://toniw.iki.fi/temp/matchbox-panel.spec http://toniw.iki.fi/temp/matchbox-panel-0.9.2-1.src.rpm http://toniw.iki.fi/temp/matchbox-panel-0.9.2-1.src.rpm.md5sum.asc Yours, Toni -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazquez at ivazquez.net Mon May 23 16:48:24 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 23 May 2005 12:48:24 -0400 Subject: New package: eet In-Reply-To: <1116859612.29938.40.camel@localhost.localdomain> References: <1116566243.7161.106.camel@ignacio.ignacio.lan> <1116859612.29938.40.camel@localhost.localdomain> Message-ID: <1116866904.3090.19.camel@ignacio.ignacio.lan> On Mon, 2005-05-23 at 09:46 -0500, Tom 'spot' Callaway wrote: > On Fri, 2005-05-20 at 01:17 -0400, Ignacio Vazquez-Abrams wrote: > > eet: A library designed to write an arbitrary set of chunks of data to a > > file > > > > EET is a tiny library designed to write an arbitary set of chunks of > > data to a file and optionally compress each chunk (very much like a zip > > file) and allow fast random-access reading of the file later on. > > Review of eet: > Bad: > > - Zero-length ChangeLog and NEWS files in main package. > > Fix the really minor blocker, and its approved. Updated. http://fedora.ivazquez.net/files/eet-0.9.10.007-2.fc3.src.rpm -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Mon May 23 16:56:20 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 23 May 2005 11:56:20 -0500 Subject: New package: eet In-Reply-To: <1116866904.3090.19.camel@ignacio.ignacio.lan> References: <1116566243.7161.106.camel@ignacio.ignacio.lan> <1116859612.29938.40.camel@localhost.localdomain> <1116866904.3090.19.camel@ignacio.ignacio.lan> Message-ID: <1116867380.29938.74.camel@localhost.localdomain> On Mon, 2005-05-23 at 12:48 -0400, Ignacio Vazquez-Abrams wrote: > On Mon, 2005-05-23 at 09:46 -0500, Tom 'spot' Callaway wrote: > > On Fri, 2005-05-20 at 01:17 -0400, Ignacio Vazquez-Abrams wrote: > > > eet: A library designed to write an arbitrary set of chunks of data to a > > > file > > > > > > EET is a tiny library designed to write an arbitary set of chunks of > > > data to a file and optionally compress each chunk (very much like a zip > > > file) and allow fast random-access reading of the file later on. > > > > Review of eet: > > > Bad: > > > > - Zero-length ChangeLog and NEWS files in main package. > > > > Fix the really minor blocker, and its approved. > > Updated. > > http://fedora.ivazquez.net/files/eet-0.9.10.007-2.fc3.src.rpm Approved. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ville.skytta at iki.fi Mon May 23 17:10:34 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 23 May 2005 20:10:34 +0300 Subject: uqm update - RFC for uqm-content* In-Reply-To: <20050523132147.71db0a37@python2> References: <1116756837.32359.125.camel@bobcat.mine.nu> <20050523132147.71db0a37@python2> Message-ID: <1116868234.4882.7.camel@bobcat.mine.nu> On Mon, 2005-05-23 at 13:21 +0200, Matthias Saou wrote: > Ville Skytt? wrote : > > > [1] Cases like this make me wonder whether it would be a possible to > > host all noarch stuff in a noarch repository shared between i386, x86_64 > > and ppc instead of having copies of all of this in each. Or maybe not > > not _all_ noarch, but a "data" repository for cases where size matters. > > In addition to uqm-content*, torcs-data* and various other noarchs at > > the top of the listing at > > http://fedoraproject.org/extras/3/i386/?C=S;O=D would be good > > candidates. > > Aren't all .noarch packages hardlinked already between the different > trees? Isn't that enough in order to save disk space? On all mirrors? From tcallawa at redhat.com Mon May 23 17:18:37 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 23 May 2005 12:18:37 -0500 Subject: kismet and svn builds? In-Reply-To: References: <1116521546.3502.251.camel@localhost.localdomain> Message-ID: <1116868717.29938.82.camel@localhost.localdomain> On Thu, 2005-05-19 at 14:40 -0400, Chris Ricker wrote: > ? It kinda seems like that first field in %{release} is superfluous? It is, and I've corrected that in the addition to PackageNamingGuidelines. The new section on "snapshot packages" is here: http://www.fedoraproject.org/wiki/PackageNamingGuidelines?action=show#head-51302723abcb576f65f85a61f6cdf2e0f69f6b18 Thanks, ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From joost at cnoc.nl Mon May 23 17:17:21 2005 From: joost at cnoc.nl (Joost van der Sluis) Date: Mon, 23 May 2005 19:17:21 +0200 Subject: Self-Introduction: Joost van der Sluis (Loesje) Message-ID: <1116868641.23375.20.camel@joost> Hello, before I'll come with my first new package, I want to introduce myself. My full name is Joost van der Sluis, while i almost always use the nickname Loesje. I'm from Delft in the Netherlands. That's between Rotterdam and Den Haag. Last year I've got my Master-title in Applied Physics. ATM i'm working for a small IT-company which I own together with a friend of mine, who is still studying. We started the company 5 year ago, and now I'm working there full-time. We create information-systems for small buisnesses. Most Delphi-related, together with large or smaller databases like Oracle, Firebird and PostgreSQL. (MSSQL) I'm not a good C-coder, but I can do with Pascal whatever I want. Since almost a year I'm involved in the Freepascal (fpc) project, now as the maintainer of the database-support. I want to add fpc to Extras, and if that succeeds maybe also some programs written in fpc, like Lazarus - a Delphi clone. If I see some interesting new packages come by (fpc-based?), I also maybe want to help with QA. GPG details: pub 1024D/673FB8B8 2005-05-23 Joost van der Sluis Key fingerprint = 79A7 29D0 FAC9 BED5 AF88 EFF9 0A5B C368 673F B8B8 sub 1024g/7090B49F 2005-05-23 Cheers, Joost. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From programacionxp at hotmail.com Mon May 23 18:02:37 2005 From: programacionxp at hotmail.com (jnizama jnizama) Date: Mon, 23 May 2005 18:02:37 +0000 Subject: (no subject) Message-ID: An HTML attachment was scrubbed... URL: From joost at cnoc.nl Mon May 23 19:31:57 2005 From: joost at cnoc.nl (Joost van der Sluis) Date: Mon, 23 May 2005 21:31:57 +0200 Subject: New package: fpc-2.0.0 Message-ID: <1116876717.23375.28.camel@joost> "This is a Turbo Pascal 7.0 and Delphi compatible 32/64bit Pascal Compiler. It comes with fully TP 7.0 and almost fully Delphi compatible run-time library. Some extensions are added to the language, like function overloading. Shared libraries can be linked. This package contains commandline compiler and utils. Provided units are the runtime library (RTL), free component library (FCL) and bindings for among others gtk1, gtk2, ncurses, zlib, mysql, postgres and ibase." This package has a startcompiler-binary included and performs a full bootstrap of the compiler. Reviews and sponsor needed. Source: http://www.cnoc.nl/fpc/fpc-2.0.0-0.1.src.rpm Package: http://www.cnoc.nl/fpc/fpc-2.0.0-0.1.i386.rpm Spec: http://www.cnoc.nl/fpc/fpc.spec Sums: http://www.cnoc.nl/fpc/MD5SUM Regards, Joost van der Sluis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Mon May 23 19:40:07 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 23 May 2005 14:40:07 -0500 Subject: Review/Approval needed: mfstools In-Reply-To: <20050519182203.67a8adaf@python2> References: <1116437306.3502.83.camel@localhost.localdomain> <20050519135811.7abbca35@python2> <1116513014.3502.223.camel@localhost.localdomain> <20050519182203.67a8adaf@python2> Message-ID: <1116877208.29938.99.camel@localhost.localdomain> On Thu, 2005-05-19 at 18:22 +0200, Matthias Saou wrote: > Weird, with rpm -qplv I didn't see any symlinks in the package, and all > files in _bindir seemed to be real binaries to me... I'll have another > look now ;-) Whoops, looks like they're binaries. Oh well, I renamed the two in question anyway. I also fixed the versioning to conform with my own naming guidelines. Please rereview. :) ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From nicolas.mailhot at laposte.net Mon May 23 19:48:39 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 23 May 2005 21:48:39 +0200 Subject: Updated new package : dejavu-fonts-1.10 In-Reply-To: <1116861329.29938.52.camel@localhost.localdomain> References: <428F5FDD.1080308@laposte.net> <42910493.3030605@laposte.net> <1116861329.29938.52.camel@localhost.localdomain> Message-ID: <42923397.4010900@laposte.net> Tom 'spot' Callaway a ?crit : > On Mon, 2005-05-23 at 00:15 +0200, Nicolas Mailhot wrote: > >>Source: >>http://mapage.noos.fr/nmailhot/fedora/dejavu-fonts-1.10-1.src.rpm > > > Review of dejavu-fonts: ... > Good: Lots of things ;) > Bad: > > - Missing Requires: fontconfig (is there ever a scenario where we don't > want fc-cache to run on %post?) This part is 100% the same as the Vera package in FC. Since Vera was reviewed extensively when proposed in fedora.us and then pulled in Raw Hide, I'd rather not touch it. The Red Hat maintainers obviously prefer it this way, and who am I to judge ? If you want to read about the pros and cons of this setup, I invite you to read the old fedora.us Vera inclusion bug ;) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From Nicolas.Mailhot at laPoste.net Mon May 23 20:16:20 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 23 May 2005 22:16:20 +0200 Subject: Updated new package : dejavu-fonts-1.10 In-Reply-To: <42923397.4010900@laposte.net> References: <428F5FDD.1080308@laposte.net> <42910493.3030605@laposte.net> <1116861329.29938.52.camel@localhost.localdomain> <42923397.4010900@laposte.net> Message-ID: <1116879407.30341.1.camel@rousalka.dyndns.org> Le lundi 23 mai 2005 ? 21:48 +0200, Nicolas Mailhot a ?crit : > Tom 'spot' Callaway a ?crit : > > Bad: > > > > - Missing Requires: fontconfig (is there ever a scenario where we don't > > want fc-cache to run on %post?) > > This part is 100% the same as the Vera package in FC. > Since Vera was reviewed extensively when proposed in fedora.us and then > pulled in Raw Hide, I'd rather not touch it. The Red Hat maintainers > obviously prefer it this way, and who am I to judge ? > > If you want to read about the pros and cons of this setup, I invite you > to read the old fedora.us Vera inclusion bug ;) Or better, ask Owen directly :) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Mon May 23 20:24:26 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 23 May 2005 15:24:26 -0500 Subject: Updated new package : dejavu-fonts-1.10 In-Reply-To: <42923397.4010900@laposte.net> References: <428F5FDD.1080308@laposte.net> <42910493.3030605@laposte.net> <1116861329.29938.52.camel@localhost.localdomain> <42923397.4010900@laposte.net> Message-ID: <1116879866.29938.121.camel@localhost.localdomain> On Mon, 2005-05-23 at 21:48 +0200, Nicolas Mailhot wrote: > Tom 'spot' Callaway a ?crit : > > On Mon, 2005-05-23 at 00:15 +0200, Nicolas Mailhot wrote: > > > >>Source: > >>http://mapage.noos.fr/nmailhot/fedora/dejavu-fonts-1.10-1.src.rpm > > > > > > Review of dejavu-fonts: > > ... > > > Good: > > Lots of things ;) > > > Bad: > > > > - Missing Requires: fontconfig (is there ever a scenario where we don't > > want fc-cache to run on %post?) > > This part is 100% the same as the Vera package in FC. Then, the Vera package in FC is probably broken. If we want to run fc-cache, then we need fontconfig to be installed, and thats the only way to be sure of it. Now, if you can provide a case where we would not want to run fc-cache on %post, then perhaps this isn't a blocker. :) ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ville.skytta at iki.fi Mon May 23 20:43:56 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 23 May 2005 23:43:56 +0300 Subject: rpmlint default config improvements Message-ID: <1116881036.4882.81.camel@bobcat.mine.nu> Any objections to the attached changes to the default rpmlint config? Other improvements welcome too, I intend to push an update this week. -------------- next part -------------- A non-text attachment was scrubbed... Name: rpmlint-config.patch Type: text/x-patch Size: 721 bytes Desc: not available URL: From Nicolas.Mailhot at laPoste.net Mon May 23 20:42:24 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 23 May 2005 22:42:24 +0200 Subject: Updated new package : dejavu-fonts-1.10 In-Reply-To: <1116879866.29938.121.camel@localhost.localdomain> References: <428F5FDD.1080308@laposte.net> <42910493.3030605@laposte.net> <1116861329.29938.52.camel@localhost.localdomain> <42923397.4010900@laposte.net> <1116879866.29938.121.camel@localhost.localdomain> Message-ID: <1116880959.30341.12.camel@rousalka.dyndns.org> Le lundi 23 mai 2005 ? 15:24 -0500, Tom 'spot' Callaway a ?crit : > On Mon, 2005-05-23 at 21:48 +0200, Nicolas Mailhot wrote: > > Tom 'spot' Callaway a ?crit : > > > Bad: > > > > > > - Missing Requires: fontconfig (is there ever a scenario where we don't > > > want fc-cache to run on %post?) > > > > This part is 100% the same as the Vera package in FC. > > Then, the Vera package in FC is probably broken. If we want to run > fc-cache, then we need fontconfig to be installed, and thats the only > way to be sure of it. > > Now, if you can provide a case where we would not want to run fc-cache > on %post, then perhaps this isn't a blocker. :) Well, from memory (you should really read the archives or ask Owen to get the full explanation) : We use "opportunistic" scriptlets here - they'll use fc-cache if it's present on system, but do not require it. This means you can install fonts on a system without fontconfig (think application server that has its own font processing lib...). However, if you have a single app on-system that uses fontconfig, its own requires will have it installed and fc-cache will be run (either at fontconfig install time or at font install time) This IMHO is the right model. Font are ressources so they should not require apps or libs that may use them. The dependency goes the other way: the gimp can require a tile package to use in its filters, but the tile package should not require the gimp. Of course since in this particular case you have a 95% chance of having fontconfig on-system regardless of what you put in this particular spec, the debate is largely academic nowadays. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Mon May 23 20:47:36 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 May 2005 16:47:36 -0400 Subject: New package: Maelstrom Message-ID: <20050523204736.GA7933@nostromo.devel.redhat.com> Just an import of the old FC package ATM. Please review - thanks! Bill From tcallawa at redhat.com Mon May 23 20:51:09 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 23 May 2005 15:51:09 -0500 Subject: Updated new package : dejavu-fonts-1.10 In-Reply-To: <1116880959.30341.12.camel@rousalka.dyndns.org> References: <428F5FDD.1080308@laposte.net> <42910493.3030605@laposte.net> <1116861329.29938.52.camel@localhost.localdomain> <42923397.4010900@laposte.net> <1116879866.29938.121.camel@localhost.localdomain> <1116880959.30341.12.camel@rousalka.dyndns.org> Message-ID: <1116881469.29938.123.camel@localhost.localdomain> On Mon, 2005-05-23 at 22:42 +0200, Nicolas Mailhot wrote: > Le lundi 23 mai 2005 ? 15:24 -0500, Tom 'spot' Callaway a ?crit : > > On Mon, 2005-05-23 at 21:48 +0200, Nicolas Mailhot wrote: > > > Tom 'spot' Callaway a ?crit : > > > > > Bad: > > > > > > > > - Missing Requires: fontconfig (is there ever a scenario where we don't > > > > want fc-cache to run on %post?) > > > > > > This part is 100% the same as the Vera package in FC. > > > > Then, the Vera package in FC is probably broken. If we want to run > > fc-cache, then we need fontconfig to be installed, and thats the only > > way to be sure of it. > > > > Now, if you can provide a case where we would not want to run fc-cache > > on %post, then perhaps this isn't a blocker. :) > > Well, from memory (you should really read the archives or ask Owen to > get the full explanation) : > > We use "opportunistic" scriptlets here - they'll use fc-cache if it's > present on system, but do not require it. This means you can install > fonts on a system without fontconfig (think application server that has > its own font processing lib...). However, if you have a single app > on-system that uses fontconfig, its own requires will have it installed > and fc-cache will be run (either at fontconfig install time or at font > install time) Ah, ok. Seems reasonable enough. I withdraw my objection and approve dejavu-fonts. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon May 23 21:33:09 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 23 May 2005 23:33:09 +0200 Subject: Review/Approval needed: mfstools In-Reply-To: <1116877208.29938.99.camel@localhost.localdomain> References: <1116437306.3502.83.camel@localhost.localdomain> <20050519135811.7abbca35@python2> <1116513014.3502.223.camel@localhost.localdomain> <20050519182203.67a8adaf@python2> <1116877208.29938.99.camel@localhost.localdomain> Message-ID: <20050523233309.03d84522@python2> Tom 'spot' Callaway wrote : > On Thu, 2005-05-19 at 18:22 +0200, Matthias Saou wrote: > > > Weird, with rpm -qplv I didn't see any symlinks in the package, and all > > files in _bindir seemed to be real binaries to me... I'll have another > > look now ;-) > > Whoops, looks like they're binaries. Oh well, I renamed the two in > question anyway. I also fixed the versioning to conform with my own > naming guidelines. Please rereview. :) With these changes, I approve the package. I simply trust you on the fact that it was tested regarding its functionality, since I can't do that as there are no TiVos here ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.27_FC3 Load : 1.15 0.61 0.43 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon May 23 21:37:27 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 23 May 2005 23:37:27 +0200 Subject: uqm update - RFC for uqm-content* In-Reply-To: <1116868234.4882.7.camel@bobcat.mine.nu> References: <1116756837.32359.125.camel@bobcat.mine.nu> <20050523132147.71db0a37@python2> <1116868234.4882.7.camel@bobcat.mine.nu> Message-ID: <20050523233727.72b8884a@python2> Ville Skytt? wrote : > > Aren't all .noarch packages hardlinked already between the different > > trees? Isn't that enough in order to save disk space? > > On all mirrors? Any mirror who carries more than just i386 should be mirroring with the -H rsync option (preserve hard links, which saves a lot for the RH/FC trees), or if it can't, at least run hardlink or hardlink++ on its trees every once in a while if there are any disk space constraints (and AFAIK, pretty much every mirror has, since free space is just asking for more content to be mirrored ;-)). Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.27_FC3 Load : 0.38 0.57 0.45 From tcallawa at redhat.com Mon May 23 21:48:05 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 23 May 2005 16:48:05 -0500 Subject: Review/Approval needed: mfstools In-Reply-To: <20050523233309.03d84522@python2> References: <1116437306.3502.83.camel@localhost.localdomain> <20050519135811.7abbca35@python2> <1116513014.3502.223.camel@localhost.localdomain> <20050519182203.67a8adaf@python2> <1116877208.29938.99.camel@localhost.localdomain> <20050523233309.03d84522@python2> Message-ID: <1116884885.29938.128.camel@localhost.localdomain> On Mon, 2005-05-23 at 23:33 +0200, Matthias Saou wrote: > Tom 'spot' Callaway wrote : > > > On Thu, 2005-05-19 at 18:22 +0200, Matthias Saou wrote: > > > > > Weird, with rpm -qplv I didn't see any symlinks in the package, and all > > > files in _bindir seemed to be real binaries to me... I'll have another > > > look now ;-) > > > > Whoops, looks like they're binaries. Oh well, I renamed the two in > > question anyway. I also fixed the versioning to conform with my own > > naming guidelines. Please rereview. :) > > With these changes, I approve the package. > I simply trust you on the fact that it was tested regarding its > functionality, since I can't do that as there are no TiVos here ;-) I used these tools to add the second drive to my TiVo. :) ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From wtogami at redhat.com Mon May 23 23:07:31 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 23 May 2005 13:07:31 -1000 Subject: bootchart packager? Message-ID: <42926233.5060803@redhat.com> http://www.bootchart.org/ Anybody interested in packaging this for Extras? I think FC4's gcj should be able to do it without Sun java. http://www.bootchart.org/samples.html Wicked cool examples of bootcharts. Having bootchart easily installable from Extras will allow us to more quickly analyze and optimize booting in the future. Warren Togami wtogami at redhat.com From ivazquez at ivazquez.net Mon May 23 23:27:03 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 23 May 2005 19:27:03 -0400 Subject: bootchart packager? In-Reply-To: <42926233.5060803@redhat.com> References: <42926233.5060803@redhat.com> Message-ID: <1116890823.25038.1.camel@ignacio.ignacio.lan> On Mon, 2005-05-23 at 13:07 -1000, Warren Togami wrote: > http://www.bootchart.org/ > Anybody interested in packaging this for Extras? I think FC4's gcj > should be able to do it without Sun java. I'll take it. It'll be good practice for when I eventually import FreeWRL. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Tue May 24 02:29:09 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 May 2005 22:29:09 -0400 Subject: bootchart packager? In-Reply-To: <42926233.5060803@redhat.com> References: <42926233.5060803@redhat.com> Message-ID: <20050524022909.GA11843@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > http://www.bootchart.org/ > Anybody interested in packaging this for Extras? I think FC4's gcj > should be able to do it without Sun java. It requires jakarta-commons-somethingorother to build, which isn't in Core or Extras ATM. Bill From ivazquez at ivazquez.net Tue May 24 02:39:19 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 23 May 2005 22:39:19 -0400 Subject: bootchart packager? In-Reply-To: <20050524022909.GA11843@nostromo.devel.redhat.com> References: <42926233.5060803@redhat.com> <20050524022909.GA11843@nostromo.devel.redhat.com> Message-ID: <1116902360.25038.4.camel@ignacio.ignacio.lan> On Mon, 2005-05-23 at 22:29 -0400, Bill Nottingham wrote: > Warren Togami (wtogami at redhat.com) said: > > http://www.bootchart.org/ > > Anybody interested in packaging this for Extras? I think FC4's gcj > > should be able to do it without Sun java. > > It requires jakarta-commons-somethingorother to build, Really? While I did see some "extension missing" errors from ant and a buttload of warnings when compiling it I did get a jar at the end of compiling it. Now I need to figure out what to put in %install... -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Tue May 24 02:44:48 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 May 2005 22:44:48 -0400 Subject: bootchart packager? In-Reply-To: <1116902360.25038.4.camel@ignacio.ignacio.lan> References: <42926233.5060803@redhat.com> <20050524022909.GA11843@nostromo.devel.redhat.com> <1116902360.25038.4.camel@ignacio.ignacio.lan> Message-ID: <20050524024448.GA12074@nostromo.devel.redhat.com> Ignacio Vazquez-Abrams (ivazquez at ivazquez.net) said: > > It requires jakarta-commons-somethingorother to build, > > Really? While I did see some "extension missing" errors from ant and a > buttload of warnings when compiling it I did get a jar at the end of > compiling it. Now I need to figure out what to put in %install... Rebuilding 0.8 I got: [javac] 2. ERROR in /var/tmp/rpm-tmp/build/bootchart-0.8/src/org/bootchart/Main.java [javac] (at line 40) [javac] import org.apache.commons.cli.CommandLineParser; [javac] ^^^^^^^^^^^^^^^^^^^^^^ [javac] The import org.apache.commons.cli cannot be resolved Installing jakarta-commons-cli fixed it. Bill From jwboyer at jdub.homelinux.org Tue May 24 03:15:43 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 23 May 2005 22:15:43 -0500 Subject: New package: meanwhile Message-ID: <1116904543.18458.23.camel@yoda.jdub.homelinux.org> meanwhile: Lotus Sametime Community Client library Meanwhile provides the basic Lotus Sametime session functionality along with the core services; Presence Awareness, Instant Messaging, Multi- user Conferencing, Preferences Storage, Identity Resolution, and File Transfer. Project URL: http://meanwhile.sourceforge.net SRPM URL: http://jdub.homelinux.org/files/meanwhile/ Meanwhile just provides the core Sametime functionality. The actual client interface is done via a plugin, called gaim-meanwhile. This will be packaged in a separate RPM and will be available for review shortly. thx, josh From petersen at redhat.com Tue May 24 04:22:32 2005 From: petersen at redhat.com (Jens Petersen) Date: Tue, 24 May 2005 13:22:32 +0900 Subject: New package: fpc-2.0.0 In-Reply-To: <1116876717.23375.28.camel@joost> References: <1116876717.23375.28.camel@joost> Message-ID: <4292AC08.5000503@redhat.com> Hi, Thanks for your submission. Joost van der Sluis wrote: > Source: > http://www.cnoc.nl/fpc/fpc-2.0.0-0.1.src.rpm It doesn't seem to build completely on x86_64, since the libs are installed in /usr/lib and not /usr/lib64. Processing files: fpc-2.0.0-0.1 Error: File not found: /var/tmp/fpc-2.0.0-0.2-root-petersen/usr/lib64/fpc/2.0.0 This needs fixing. Overall the spec file looks ok, I attach a patch with some initial cleanup. Further comments: - usually %clean just removes the installed files, so I don't think you need to "make clean" everything there. - "examples/" seems to be too big to include in the main package: I recommend either excluding it or at least moving it to a -doc subpackage - If more html documentation available, it could also go into -doc. I see there is a -docs subpackage on the upstream download page. - the software is GPL/LGPL :), but are there any legal issues with highlighting TP and Delphi compatibility? - (It would be nice if upstream could simplify building and installing without the setup.sh script?:) - can fpc be built with debugging info? Would it be useful? Currently no debuginfo is generated afaict. Jens -------------- next part -------------- A non-text attachment was scrubbed... Name: fpc.spec-0.1.patch Type: text/x-patch Size: 5246 bytes Desc: not available URL: From kaboom at oobleck.net Tue May 24 04:55:05 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 24 May 2005 00:55:05 -0400 (EDT) Subject: gnuchess added Message-ID: I've imported an SRPM for GNU chess based on the last one in the Fedora Core development CVS. Technically no approval's needed since it was in FC 3, but I'll wait a couple of days to build it in case anyone wants to review the changes I made.... Once that's in I'll add xboard as well if no one else wants to maintain it later, chris From oliver at linux-kernel.at Tue May 24 05:14:43 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 24 May 2005 07:14:43 +0200 Subject: rpmlint default config improvements In-Reply-To: <1116881036.4882.81.camel@bobcat.mine.nu> Message-ID: <200505240514.j4O5ECrG005960@mail.linux-kernel.at> Ville Skytt? [ville.skytta at iki.fi] wrote: > Any objections to the attached changes to the default rpmlint config? > Other improvements welcome too, I intend to push an update this week. This makes sense to me (tm). :-) Best, Oliver From elprodigio at gmail.com Tue May 24 09:01:14 2005 From: elprodigio at gmail.com (Didier Casse) Date: Tue, 24 May 2005 17:01:14 +0800 Subject: Sponsor needed: Enlightenment DR17/E17+EFL Message-ID: <513a3b30505240201267f52da@mail.gmail.com> Hi Everybody, Let me first introduce myself in a nutshell: My name is Didier F.B. Casse. For a living I'm a PhD candidate in Physics at the National University of Singapore. Other than the above which nobody cares about, I'm in the Enlightenment (www.enlightenment.org) Team porting and packaging team. What I do is that I package the Enlightenment Windows Manager/ Desktop Shell into rpms for Fedora Core users or rpm-based distro users to enjoy. I maintain an apt/yum repository at http://sps.nus.edu.sg/~didierbe for convenience to the FC users. For those who are not aware of the Enlightenment project (founded by Carsten Haitzler) or the Enlightenment Foundation Libraries (EFL), please refer to: http://www.enlightenment.org/ http://www.enlightenment.org/index.php?id=5&select=ePortal You might also want to view videos of DR 17 which would probably tell more about the whole thing: http://www.rasterman.com/files/e17_movie-00.avi http://www.rasterman.com/files/e17_movie-01.avi http://www.rasterman.com/files/e17_movie-02.avi http://www.rasterman.com/files/e17_movie-03.avi Now we can talk. Right now DR17 exists in snapshot releases located at http://enlightenment.freedesktop.org and in CVS. The reason why it's in this form, it's because it's still in development. Although many might frown with the statement I just made, I (and many others) have been running DR17 as our full-time window manager for several months and I assure you that it's fully usable, robust and super eye-candy. And I never got any problems with it. What do I do exactly? My hobby is to pull cvs E/EFL or snapshots, compile them, make rpms and ensure that the snapshot is ready for regular users. If I judge that the current snapshot is ready, it is then that I place it in my yum repo. I have become the de facto repo for E17/EFL rpms. So far there have been only success stories and each work I receive about 10 thank-you emails for that. I can safely say there are thousands of FC users who want and really enjoy Enlightenment 17. I was encouraged by Rahul Sundaram and Mark McLoughlin to push this work into extras so that users of Fedora do not need to hunt the repo down. Gentoo, Debian already have something like that.. DR17 is being integrated soon into Mandriva. Why not Fedora Core? ;-) It might be that you guys do not want anymore WMs in Fedora, but it's about giving the community a choice. I chose Linux over MS. And in Fedora Linux, some people might want to choose E over GNOME or XFCE over KDE. Do you want your users to freely customize their FC distro to their heart's desire? This is to say that I need a sponsor to make this possible. -- with kind regards, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. From jwboyer at jdub.homelinux.org Tue May 24 11:24:56 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 24 May 2005 06:24:56 -0500 Subject: New package: gaim-meanwhile Message-ID: <1116933896.18458.33.camel@yoda.jdub.homelinux.org> gaim-meanwhile: Lotus Sametime Community Client plugin for Gaim This is a Gaim plugin that uses the meanwhile library to allow users to connect to a Sametime server with Gaim. Project URL: http://meanwhile.sourceforge.net SRPM URL: http://jdub.homelinux.org/files/gaim-meanwhile/ gaim-meanwhile requires the meanwhile package which was posted for review earlier. thx, josh From ryo-dairiki at mbm.nifty.com Tue May 24 11:22:46 2005 From: ryo-dairiki at mbm.nifty.com (Ryo Dairiki) Date: Tue, 24 May 2005 20:22:46 +0900 Subject: Write access permission is needed Message-ID: <42930E86.308@mbm.nifty.com> I'm thinking of adding SCIM to bugzilla. For this reason, I need write access permission of the following page: http://www.fedoraproject.org/wiki/Extras_2fBugzillaAdmin Please give me a write permission of the page. My wiki account: ryo ID: 1114695854.86.39675 Name: RyoDairiki Regards, Ryo Dairiki From triad at df.lth.se Tue May 24 12:31:18 2005 From: triad at df.lth.se (Linus Walleij) Date: Tue, 24 May 2005 14:31:18 +0200 (CEST) Subject: New package: libnjb Message-ID: Libnjb is a library for accessing digital audio players based on Creative Technology hardware. This includes the Creative Jukebox, Creative Jukebox 2, 3, Zen, Zen USB 2.0, NX, Xtra, Touch and Micro plus the OEM manufactured Dell Devices: Dell DJ, Dell DJ 2nd generation and Dell Pocket DJ. The library is built on top of libusb. libnjb is under the BSD license. We have had a maintainer for Debian for some time, and are now looking into including the library with the Fedora extras. I have been rolling Fedora / Red Hat packages on the project page for some time. A package reviewer and a sponsor is humbly requested. Project URL: http://libnjb.sourceforge.net/ SRPM URL: http://sourceforge.net/project/showfiles.php?group_id=32528 Yours, Linus Walleij From nhorman at redhat.com Tue May 24 13:15:23 2005 From: nhorman at redhat.com (Neil Horman) Date: Tue, 24 May 2005 09:15:23 -0400 Subject: New package: iozone In-Reply-To: <20050521131512.GB22489@hmsendeavour.rdu.redhat.com> References: <20050519202418.GH14451@hmsendeavour.rdu.redhat.com> <20050520084210.5cd153da.mfleming@enlartenment.com> <20050520185556.GK19229@hmsendeavour.rdu.redhat.com> <20050520222740.131f01f3.bugs.michael@gmx.net> <20050521131512.GB22489@hmsendeavour.rdu.redhat.com> Message-ID: <20050524131523.GB17607@hmsendeavour.rdu.redhat.com> On Sat, May 21, 2005 at 09:15:12AM -0400, Neil Horman wrote: > On Fri, May 20, 2005 at 10:27:40PM +0200, Michael Schwendt wrote: > > On Fri, 20 May 2005 14:55:56 -0400, Neil Horman wrote: > > > > > On Fri, May 20, 2005 at 08:42:10AM +1000, Michael Fleming wrote: > > > > > > Thanks for your detailed feeback Guys! I've incorporated all your changes into a > > > new version of the package (with the exception of the Michael F.'s docdir > > > comment, as it seems convention (at least on my fedora system) that docs go in > > > /usr/share/doc/). > > > > Well, %_docdir/%name-%version to be precise, and files marked with %doc go > > into that directory. With regard to that, Michael's comment would make the > > spec a bit cleaner. But it's not a blocker criterion. > > > Good point. I missed that. I'll fix that up and repost. Thanks! > Neil New Packages uploaded, fixing the above. Location: http://people.redhat.com/nhorman/iozone.spec http://people.redhat.com/nhorman/iozone-3-1.src.rpm md5sums: deedd349c0c51da6563fd5c2c02d4718 iozone.spec da64ba6cca5320675996983b7fb23463 iozone-3-1.src.rpm Looking for initial approval. Thanks and Regards Neil -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman at redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From symbiont at berlios.de Tue May 24 13:38:57 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Tue, 24 May 2005 21:38:57 +0800 Subject: Sponsor needed: Enlightenment DR17/E17+EFL In-Reply-To: <513a3b30505240201267f52da@mail.gmail.com> References: <513a3b30505240201267f52da@mail.gmail.com> Message-ID: <200505242138.57943.symbiont@berlios.de> On Tuesday 24 May 2005 17:01, Didier Casse wrote: > I maintain an apt/yum repository at > http://sps.nus.edu.sg/~didierbe > for convenience to the FC users. Prior to getting sponsored, some quick feedback: enlightenment should not Requires: gettext-devel. BuildRequires is fine. -- -jeff From tcallawa at redhat.com Tue May 24 13:43:06 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 24 May 2005 08:43:06 -0500 Subject: Sponsor needed: Enlightenment DR17/E17+EFL In-Reply-To: <513a3b30505240201267f52da@mail.gmail.com> References: <513a3b30505240201267f52da@mail.gmail.com> Message-ID: <1116942187.29938.149.camel@localhost.localdomain> On Tue, 2005-05-24 at 17:01 +0800, Didier Casse wrote: > It might be that you guys do not want anymore WMs in Fedora, but it's > about giving the community a choice. I chose Linux over MS. And in > Fedora Linux, some people might want to choose E over GNOME or XFCE > over KDE. Do you want your users to freely customize their FC distro > to their heart's desire? > > This is to say that I need a sponsor to make this possible. Sponsored. (You still need to run your packages through the formal review process) ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Tue May 24 14:19:28 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 24 May 2005 09:19:28 -0500 Subject: New package: meanwhile In-Reply-To: <1116904543.18458.23.camel@yoda.jdub.homelinux.org> References: <1116904543.18458.23.camel@yoda.jdub.homelinux.org> Message-ID: <1116944369.29938.163.camel@localhost.localdomain> On Mon, 2005-05-23 at 22:15 -0500, Josh Boyer wrote: > meanwhile: Lotus Sametime Community Client library > > Meanwhile provides the basic Lotus Sametime session functionality along > with the core services; Presence Awareness, Instant Messaging, Multi- > user Conferencing, Preferences Storage, Identity Resolution, and File > Transfer. > > Project URL: http://meanwhile.sourceforge.net > > SRPM URL: http://jdub.homelinux.org/files/meanwhile/ > > Meanwhile just provides the core Sametime functionality. The actual > client interface is done via a plugin, called gaim-meanwhile. This will > be packaged in a separate RPM and will be available for review shortly. Review of meanwhile: rpmlint checks: meanwhile-0.4.1-1.src.rpm: E: meanwhile description-line-too-long The heart of the Meanwhile Project is the Meanwhile library, providing the basic E: meanwhile description-line-too-long integration of future service handlers such as the user directory and whiteboard E: meanwhile no-signature W: meanwhile strange-permission meanwhile.spec 0600 meanwhile-0.4.1-1.i386.rpm: E: meanwhile description-line-too-long The heart of the Meanwhile Project is the Meanwhile library, providing the basic E: meanwhile description-line-too-long integration of future service handlers such as the user directory and whiteboard E: meanwhile zero-length /usr/share/doc/meanwhile-0.4.1/NEWS E: meanwhile no-signature meanwhile-devel-0.4.1-1.i386.rpm: E: meanwhile-devel requires-on-release meanwhile 0.4.1-1 W: meanwhile-devel no-major-in-name meanwhile-devel W: meanwhile-devel no-documentation E: meanwhile-devel no-signature No need to have that zero-length NEWS in there. All other rpmlint errors can be ignored. Good: - License OK (LGPL), COPYING included in package - Source matches upstream - ldconfig in %post, %postun - .la files excluded Bad: - Zero-length NEWS file included in package - Generic INSTALL file included, no need to waste space with it These are minor blockers, no need for a full re-review. Just make these two changes and I'll approve this package. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From symbiont at berlios.de Tue May 24 14:31:47 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Tue, 24 May 2005 22:31:47 +0800 Subject: Sponsor needed: Enlightenment DR17/E17+EFL In-Reply-To: <200505242138.57943.symbiont@berlios.de> References: <513a3b30505240201267f52da@mail.gmail.com> <200505242138.57943.symbiont@berlios.de> Message-ID: <200505242231.47501.symbiont@berlios.de> On Tuesday 24 May 2005 21:38, Jeff Pitman wrote: > On Tuesday 24 May 2005 17:01, Didier Casse wrote: > > I maintain an apt/yum repository at > > http://sps.nus.edu.sg/~didierbe > > for convenience to the FC users. > > Prior to getting sponsored, some quick feedback: enlightenment should > not Requires: gettext-devel. BuildRequires is fine. More feedback. The "engage" package shouldn't Requires: xine-lib-devel. Just the BuildRequires. You should Requires: xine-lib, though. Also, I cannot get engage setup by default: $ engage -e gl GL: create info... GL: setup info... GL: gl window setup done. Esmart_Trans Error: Could not read root window pixmap property! Esmart_Trans Error: Cannot create transparency pixmap: no valid wallpaper and no background color set. GL EXT supported: GL_SGIS_generate_mipmap = ffffffff GL EXT supported: GL_NV_texture_rectangle = ffffffff am a system tray :) :) Also, I recommend that Keyboard shortcuts and Default Window behavior are synchronized with what GNOME and KDE provide. For example, Alt-Tab. It might disgust the E! power user, but I think it's necessary for those that will be switching between desktops. (GNOME and KDE finally have come together in common on this thanks to efforts by Redhat, et al.) take care, -- -jeff From bugs.michael at gmx.net Tue May 24 14:34:49 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 24 May 2005 16:34:49 +0200 Subject: New package: meanwhile In-Reply-To: <1116944369.29938.163.camel@localhost.localdomain> References: <1116904543.18458.23.camel@yoda.jdub.homelinux.org> <1116944369.29938.163.camel@localhost.localdomain> Message-ID: <20050524163449.1cec3f18.bugs.michael@gmx.net> On Tue, 24 May 2005 09:19:28 -0500, Tom 'spot' Callaway wrote: > On Mon, 2005-05-23 at 22:15 -0500, Josh Boyer wrote: > > meanwhile: Lotus Sametime Community Client library > > > > Meanwhile provides the basic Lotus Sametime session functionality along > > with the core services; Presence Awareness, Instant Messaging, Multi- > > user Conferencing, Preferences Storage, Identity Resolution, and File > > Transfer. > > > > Project URL: http://meanwhile.sourceforge.net > > > > SRPM URL: http://jdub.homelinux.org/files/meanwhile/ > > > > Meanwhile just provides the core Sametime functionality. The actual > > client interface is done via a plugin, called gaim-meanwhile. This will > > be packaged in a separate RPM and will be available for review shortly. > > Review of meanwhile: > > rpmlint checks: > > meanwhile-0.4.1-1.src.rpm: > E: meanwhile description-line-too-long The heart of the Meanwhile > Project is the Meanwhile library, providing the basic > E: meanwhile description-line-too-long integration of future service > handlers such as the user directory and whiteboard > E: meanwhile no-signature > W: meanwhile strange-permission meanwhile.spec 0600 > > meanwhile-0.4.1-1.i386.rpm: > E: meanwhile description-line-too-long The heart of the Meanwhile > Project is the Meanwhile library, providing the basic > E: meanwhile description-line-too-long integration of future service > handlers such as the user directory and whiteboard > E: meanwhile zero-length /usr/share/doc/meanwhile-0.4.1/NEWS > E: meanwhile no-signature > > meanwhile-devel-0.4.1-1.i386.rpm: > E: meanwhile-devel requires-on-release meanwhile 0.4.1-1 > W: meanwhile-devel no-major-in-name meanwhile-devel > W: meanwhile-devel no-documentation > E: meanwhile-devel no-signature > > No need to have that zero-length NEWS in there. All other rpmlint errors > can be ignored. * The "description-line-too-long" ought to be corrected. Keep the lines under 80 columns. That avoids ugly staircase effects if no assumption about maximum length of lines or auto-wrapping (block-text) is made. * pkg-config file in meanwhile-devel has dependencies, a test like $ pkg-config --exists meanwhile && echo "yes" fails. * Header files also include glib headers. * minimum glib2-devel version is sufficient since at least FC1 * explicit dependency on glib2 is not needed * %post/%postun scriptlets miss dependency on /sbin/ldconfig, change them to -p /sbin/ldconfig (as in patch below) to get an automatic dependency --- meanwhile.spec.orig 2005-05-24 05:15:02.000000000 +0200 +++ meanwhile.spec 2005-05-24 16:27:38.000000000 +0200 @@ -11,22 +11,22 @@ Source: http://dl.sf.net/meanwhile/meanwhile-%{version}.tar.gz URL: http://meanwhile.sourceforge.net BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) -BuildRequires: glib2-devel >= 2.2 -Requires: glib2 >= 2.2 +BuildRequires: glib2-devel %description -The heart of the Meanwhile Project is the Meanwhile library, providing the basic -Lotus Sametime session functionality along with the core services; Presence -Awareness, Instant Messaging, Multi-user Conferencing, Preferences Storage, -Identity Resolution, and File Transfer. This extensible client interface allows -additional services to be added to a session at runtime, allowing for simple -integration of future service handlers such as the user directory and whiteboard -and screen-sharing. +The heart of the Meanwhile Project is the Meanwhile library, providing the +basic Lotus Sametime session functionality along with the core services; +Presence Awareness, Instant Messaging, Multi-user Conferencing, +Preferences Storage, Identity Resolution, and File Transfer. This +extensible client interface allows additional services to be added to a +session at runtime, allowing for simple integration of future service +handlers such as the user directory and whiteboard and screen-sharing. %package devel Summary: Header files, libraries and development documentation for %{name} Group: Development/Libraries Requires: %{name} = %{version}-%{release} +Requires: glib2-devel %description devel This package contains the header files, static libraries and development @@ -47,11 +47,9 @@ %clean rm -rf $RPM_BUILD_ROOT -%post -/sbin/ldconfig 2> /dev/null +%post -p /sbin/ldconfig -%postun -/sbin/ldconfig 2> /dev/null +%postun -p /sbin/ldconfig %files %defattr(-, root, root) From tcallawa at redhat.com Tue May 24 14:36:45 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 24 May 2005 09:36:45 -0500 Subject: New package: gaim-meanwhile In-Reply-To: <1116933896.18458.33.camel@yoda.jdub.homelinux.org> References: <1116933896.18458.33.camel@yoda.jdub.homelinux.org> Message-ID: <1116945405.29938.172.camel@localhost.localdomain> On Tue, 2005-05-24 at 06:24 -0500, Josh Boyer wrote: > gaim-meanwhile: Lotus Sametime Community Client plugin for Gaim > > This is a Gaim plugin that uses the meanwhile library to allow users to > connect to a Sametime server with Gaim. > > Project URL: http://meanwhile.sourceforge.net > > SRPM URL: http://jdub.homelinux.org/files/gaim-meanwhile/ > > gaim-meanwhile requires the meanwhile package which was posted for > review earlier. Review of gaim-meanwhile: Rpmlint checks: gaim-meanwhile-1.2.2-1.src.rpm: E: gaim-meanwhile no-signature W: gaim-meanwhile strange-permission gaim-meanwhile.spec 0600 gaim-meanwhile-1.2.2-1.i386.rpm: E: gaim-meanwhile zero-length /usr/share/doc/gaim-meanwhile-1.2.2/NEWS E: gaim-meanwhile no-signature Zero-length NEWS is here too (how unexpected!), but all other rpmlint errors can be ignored. Good: - License OK (GPL), COPYING included in package - Source matches upstream - .la files excluded - No missing BuildRequires - client module loads in gaim (can't really test, because I don't have a Sametime server) Bad: - Zero-length NEWS file doesn't need to be packaged. - Generic INSTALL file doesn't need to be packaged. - Package grabbed dependencies on libglib-2.0.so.0, libmeanwhile.so.0, but not gaim. You probably want to add Requires: gaim >= 1.2.1. Again, relatively minor blockers here. Fix and I'll approve. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Tue May 24 14:42:16 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 24 May 2005 09:42:16 -0500 Subject: New package: meanwhile In-Reply-To: <20050524163449.1cec3f18.bugs.michael@gmx.net> References: <1116904543.18458.23.camel@yoda.jdub.homelinux.org> <1116944369.29938.163.camel@localhost.localdomain> <20050524163449.1cec3f18.bugs.michael@gmx.net> Message-ID: <1116945737.29938.178.camel@localhost.localdomain> On Tue, 2005-05-24 at 16:34 +0200, Michael Schwendt wrote: > * The "description-line-too-long" ought to be corrected. Keep > the lines under 80 columns. That avoids ugly staircase effects > if no assumption about maximum length of lines or auto-wrapping > (block-text) is made. I saw that error, but I went and checked the line length in the % description, and while they were right at 80, none were longer. I checked -qip on the package and it didn't stairstep, so I ignored it. > * %post/%postun scriptlets miss dependency on /sbin/ldconfig, > change them to -p /sbin/ldconfig (as in patch below) to get > an automatic dependency /sbin/ldconfig is in glibc. How exactly will a running system not have glibc? Simply by compiling this, it will pull in glibc as a Requires. There isn't any need to -p /sbin/ldconfig to achieve the same thing. (I agree with Michael's other points) ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From bugs.michael at gmx.net Tue May 24 14:58:12 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 24 May 2005 16:58:12 +0200 Subject: New package: meanwhile In-Reply-To: <1116945737.29938.178.camel@localhost.localdomain> References: <1116904543.18458.23.camel@yoda.jdub.homelinux.org> <1116944369.29938.163.camel@localhost.localdomain> <20050524163449.1cec3f18.bugs.michael@gmx.net> <1116945737.29938.178.camel@localhost.localdomain> Message-ID: <20050524165812.7d9db030.bugs.michael@gmx.net> On Tue, 24 May 2005 09:42:16 -0500, Tom 'spot' Callaway wrote: > On Tue, 2005-05-24 at 16:34 +0200, Michael Schwendt wrote: > > > * The "description-line-too-long" ought to be corrected. Keep > > the lines under 80 columns. That avoids ugly staircase effects > > if no assumption about maximum length of lines or auto-wrapping > > (block-text) is made. > > I saw that error, but I went and checked the line length in the % > description, and while they were right at 80, none were longer. I > checked -qip on the package and it didn't stairstep, so I ignored it. "right at 80" is not "under 80". ;) It's one character too much. For ordinary terminals (or graphical widgets with a similar behaviour), cursor would wrap into the next line where the linefeed would create an empty line. > > * %post/%postun scriptlets miss dependency on /sbin/ldconfig, > > change them to -p /sbin/ldconfig (as in patch below) to get > > an automatic dependency > > /sbin/ldconfig is in glibc. How exactly will a running system not have > glibc? Simply by compiling this, it will pull in glibc as a Requires. > There isn't any need to -p /sbin/ldconfig to achieve the same thing. I don't consider it a blocker criterion either. It would just be more correct, as the call of /sbin/ldconfig is explicit, and it's an assumption that the implicit dependency on glibc also adds /sbin/ldconfig right in time. Experts on RPM installation ordering might have more info. From tcallawa at redhat.com Tue May 24 15:05:16 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 24 May 2005 10:05:16 -0500 Subject: New package: meanwhile In-Reply-To: <20050524163449.1cec3f18.bugs.michael@gmx.net> References: <1116904543.18458.23.camel@yoda.jdub.homelinux.org> <1116944369.29938.163.camel@localhost.localdomain> <20050524163449.1cec3f18.bugs.michael@gmx.net> Message-ID: <1116947116.29938.179.camel@localhost.localdomain> On Tue, 2005-05-24 at 16:34 +0200, Michael Schwendt wrote: > * pkg-config file in meanwhile-devel has dependencies, a test like > > $ pkg-config --exists meanwhile && echo "yes" > > fails. Are you sure about that? [spot at swoop ~]$ pkg-config --print-requires meanwhile glib-2.0 >= 2.0.0 ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From notting at redhat.com Tue May 24 15:39:28 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 24 May 2005 11:39:28 -0400 Subject: Sponsor needed: Enlightenment DR17/E17+EFL In-Reply-To: <200505242231.47501.symbiont@berlios.de> References: <513a3b30505240201267f52da@mail.gmail.com> <200505242138.57943.symbiont@berlios.de> <200505242231.47501.symbiont@berlios.de> Message-ID: <20050524153928.GB18925@nostromo.devel.redhat.com> Jeff Pitman (symbiont at berlios.de) said: > On Tuesday 24 May 2005 21:38, Jeff Pitman wrote: > > On Tuesday 24 May 2005 17:01, Didier Casse wrote: > > > I maintain an apt/yum repository at > > > http://sps.nus.edu.sg/~didierbe > > > for convenience to the FC users. > > > > Prior to getting sponsored, some quick feedback: enlightenment should > > not Requires: gettext-devel. BuildRequires is fine. > > More feedback. > > The "engage" package shouldn't Requires: xine-lib-devel. Just the > BuildRequires. You should Requires: xine-lib, though. ... and if you're requiring xine-lib, you really can't built it in Extras. Bill From mattdm at mattdm.org Tue May 24 15:45:58 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 24 May 2005 11:45:58 -0400 Subject: Sponsor needed: Enlightenment DR17/E17+EFL In-Reply-To: <20050524153928.GB18925@nostromo.devel.redhat.com> References: <513a3b30505240201267f52da@mail.gmail.com> <200505242138.57943.symbiont@berlios.de> <200505242231.47501.symbiont@berlios.de> <20050524153928.GB18925@nostromo.devel.redhat.com> Message-ID: <20050524154558.GA10220@jadzia.bu.edu> On Tue, May 24, 2005 at 11:39:28AM -0400, Bill Nottingham wrote: > > The "engage" package shouldn't Requires: xine-lib-devel. Just the > > BuildRequires. You should Requires: xine-lib, though. > ... and if you're requiring xine-lib, you really can't built it in Extras. And even if you could, is there any reason to say "Requires: xine-lib" instead of just letting RPM's auto-deps pick it up? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 73 degrees Fahrenheit. From ziga.mahkovec at klika.si Tue May 24 15:59:02 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Tue, 24 May 2005 17:59:02 +0200 Subject: bootchart packager? In-Reply-To: <1116902360.25038.4.camel@ignacio.ignacio.lan> References: <42926233.5060803@redhat.com> <20050524022909.GA11843@nostromo.devel.redhat.com> <1116902360.25038.4.camel@ignacio.ignacio.lan> Message-ID: <1116950343.5131.6.camel@localhost> On Mon, 2005-05-23 at 22:39 -0400, Ignacio Vazquez-Abrams wrote: > On Mon, 2005-05-23 at 22:29 -0400, Bill Nottingham wrote: > > It requires jakarta-commons-somethingorother to build, > > Really? While I did see some "extension missing" errors from ant and a > buttload of warnings when compiling it I did get a jar at the end of > compiling it. Now I need to figure out what to put in %install... Did you start from the SRPM that's available at the download page? It's jpackage compliant, so it shouldn't require many changes. Bill is right about the jakarta-commons-cli requirement though. The library sources are bundled, but they are removed prior to %build (and I forgot to add the necessary BuildRequires). So unless jakarta-commons- cli is imported from jpackage, the following change is needed in the spec file: ===== @@ -48,9 +48,7 @@ %setup -q %build -# Remove the bundled commons-cli -rm -rf lib/org/apache/commons/cli lib/org/apache/commons/lang -CLASSPATH=%{_javadir}/commons-cli.jar ant +ant %install rm -rf $RPM_BUILD_ROOT ===== I'll see what I can do about the warnings -- ecj is very noisy by default. -- Ziga From symbiont at berlios.de Tue May 24 15:59:36 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Tue, 24 May 2005 23:59:36 +0800 Subject: Sponsor needed: Enlightenment DR17/E17+EFL In-Reply-To: <20050524154558.GA10220@jadzia.bu.edu> References: <513a3b30505240201267f52da@mail.gmail.com> <20050524153928.GB18925@nostromo.devel.redhat.com> <20050524154558.GA10220@jadzia.bu.edu> Message-ID: <200505242359.37057.symbiont@berlios.de> On Tuesday 24 May 2005 23:45, Matthew Miller wrote: > On Tue, May 24, 2005 at 11:39:28AM -0400, Bill Nottingham wrote: > > > The "engage" package shouldn't Requires: xine-lib-devel. ?Just > > > the BuildRequires. ?You should Requires: xine-lib, though. > > > > ... and if you're requiring xine-lib, you really can't built it in > > Extras. > > And even if you could, is there any reason to say "Requires: > xine-lib" instead of just letting RPM's auto-deps pick it up? Probably. Anyway, in general, there's a lot of Requires: .*-devel in this repo. So, that needs to be fixed by just using BuildRequires for all of them. Also, *.a and *.la libs are in the non-devel packages. So, these need to be filtered out into separate -devel packages. Another one to look at is /usr/local shouldn't be used for these packages. So, some configure fun needs to be engaged in for each of the packages that use this directory. -- -jeff From Jochen at herr-schmitt.de Tue May 24 15:59:58 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 24 May 2005 17:59:58 +0200 Subject: New package: fpc-2.0.0 In-Reply-To: <1116876717.23375.28.camel@joost> References: <1116876717.23375.28.camel@joost> Message-ID: <0ML29c-1DabpM1DaD-000452@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 23 May 2005 21:31:57 +0200, you wrote: > >Spec: >http://www.cnoc.nl/fpc/fpc.spec You should use either $RPM_BUILD_ROOT or %{buildroot} in the SPEC file. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.0 (Build 2001) iQA/AwUBQpNPlE9gByurcX4MEQIz4wCeLFizjZ3Nzo5oCiSbbydM4dSR8pYAoMLT VMG1OsGPoMuAGhbFHePzYz8B =9uky -----END PGP SIGNATURE----- From Jochen at herr-schmitt.de Tue May 24 16:00:20 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 24 May 2005 18:00:20 +0200 Subject: New package: fpc-2.0.0 In-Reply-To: <4292AC08.5000503@redhat.com> References: <1116876717.23375.28.camel@joost> <4292AC08.5000503@redhat.com> Message-ID: <0ML29c-1DabpM41FV-000452@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 24 May 2005 13:22:32 +0900, you wrote: >- can fpc be built with debugging info? Would it be useful? Currently > no debuginfo is generated afaict. I think, it make no sense, becouse the compiler is written in PASCAL. I asume there is not gdb support for fpc. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.0 (Build 2001) iQA/AwUBQpNPlU9gByurcX4MEQLV/wCfdrzL/p3YKrAfykDRRx0Hxg3R0GsAnjRj nHOqLYSSpOYxvmGv0n0qk0FE =YB06 -----END PGP SIGNATURE----- From katzj at redhat.com Tue May 24 16:03:06 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 24 May 2005 12:03:06 -0400 Subject: Packages failing rebuild for FE4 Message-ID: <1116950586.3439.93.camel@bree.local.net> I kicked off a number of Extras builds to try to sync up versions between architectures. A lot have succeeded, but some have failed. If you see a package you own in the list, if you could investigate the failure, it would be much appreciated. I've done some preliminary looking at the failures and tried to categorize them somewhat. I also started out looking at the existing bugs to see if there were patches that looked reasonable, but kind of gave up halfway through :) If you don't own any of the failed packages, feel free to pitch in and help out by attaching a patch to the bug and adding the Patch keyword.[1] If you need help with fixing any of them, join #fedora-devel and ask. People are around who have some experience in fixing problems of this sort. * csmash (http://extras64.linux.duke.edu/failed/development/csmash) Fails on x86_64, looks like a simple 64bit-ism. #156205 has a patch which looks like it should fix it * liboil (http://extras64.linux.duke.edu/failed/development/liboil/) Fails on i386 with broken asm. Filed as #158641 * cook (http://extras64.linux.duke.edu/failed/development/cook/) Fails on all arches due to broken code, #156203 has an indicator of how to fix * metakit (http://extras64.linux.duke.edu/failed/development/metakit/) Fails on x86_64, usual int/pointer confusion. #158460 * unison (http://extras64.linux.duke.edu/failed/development/unison/) Failed on ppc for no apparent reason. #158645 * scorched3d (http://extras64.linux.duke.edu/failed/development/scorched3d/) Failed on x86_64, usual int/pointer confusion. #158646 * viruskiller (http://extras64.linux.duke.edu/failed/development/viruskiller/) Failed on ppc for no apparent reason. #158647 * allegro (http://extras64.linux.duke.edu/failed/development/allegro/) Fails on all arches with invalid lvalues #158648 * arc (http://extras64.linux.duke.edu/failed/development/arc) Bad code, has a patch in #156225 * lincvs Missing buildrequires #156234 * libebml Fails on x86_64, int/pointer problems, #158649 * lablgtk Fails with invalid lvalue cast, #156230 has some patches * freedroidrpg Fails with invalid lvalue cast, #152498 has possible fix * qcad Fails on x86_64, int/pointer problem, #158650 * inkscape Fails on x86_64, int/pointer problem, #156228 has a possible fix * global Fails on all arches due to incorrect static function declartion, #156212 * gurlchecker Fails due to invalid lvalue cast, #156217 * screem Looks like it needs updating for the newer dbus, #153224 * libmatroska Fails on x86_64, int/pointer problem, #158651 * skencil Tries to build against python 2.3 instead of 2.4, #156245 * camstream Fails on ppc, #158652 * php-pecl-sqlite Looks like it needs to use sqlite2, not sqlite3, #156240. Maybe obsolete and should just be dropped? * netdiag Another of the random ppc failures, #158653 * seahorse And another, #156244 * amarok Needs to source qt.sh, #158654 * tla ppc again, #158655 * centericq Fails on x86_64, int/pointer #156202 * powermanga Fails on x86_64, int/pointer #158464 * celestica Fails on x86_64, int/pointer #158443 * Hermes Fails on i386 with mmx stuff, #156222 * psi Fails on x86_64, int/pointer, #158466 * gconfmm20 Fails on x86_64, int/pointer, #158448 Jeremy [1] Nominal arch maintainers can feel free to just fix the package and queue it for a build. From ivazquez at ivazquez.net Tue May 24 16:07:49 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 24 May 2005 12:07:49 -0400 Subject: bootchart packager? In-Reply-To: <1116950343.5131.6.camel@localhost> References: <42926233.5060803@redhat.com> <20050524022909.GA11843@nostromo.devel.redhat.com> <1116902360.25038.4.camel@ignacio.ignacio.lan> <1116950343.5131.6.camel@localhost> Message-ID: <1116950869.25038.6.camel@ignacio.ignacio.lan> On Tue, 2005-05-24 at 17:59 +0200, Ziga Mahkovec wrote: > On Mon, 2005-05-23 at 22:39 -0400, Ignacio Vazquez-Abrams wrote: > > On Mon, 2005-05-23 at 22:29 -0400, Bill Nottingham wrote: > > > It requires jakarta-commons-somethingorother to build, > > > > Really? While I did see some "extension missing" errors from ant and a > > buttload of warnings when compiling it I did get a jar at the end of > > compiling it. Now I need to figure out what to put in %install... > > Did you start from the SRPM that's available at the download page? No, I actually built a new spec file from scratch. I suppose that's why I didn't see that error. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazquez at ivazquez.net Tue May 24 16:17:03 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 24 May 2005 12:17:03 -0400 Subject: Sponsor needed: Enlightenment DR17/E17+EFL In-Reply-To: <513a3b30505240201267f52da@mail.gmail.com> References: <513a3b30505240201267f52da@mail.gmail.com> Message-ID: <1116951423.25038.9.camel@ignacio.ignacio.lan> On Tue, 2005-05-24 at 17:01 +0800, Didier Casse wrote: > I was encouraged by Rahul Sundaram and Mark McLoughlin to push this > work into extras so that users of Fedora do not need to hunt the repo > down. I've been pulling the snapshots into Extras little by little. So far only edb and eet are in due to the fact that there are only 24 hours in a day, and 7 days in a week, but I do intend on pulling more in. Perhaps we should coordinate. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Tue May 24 16:31:06 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 24 May 2005 11:31:06 -0500 Subject: New package: meanwhile In-Reply-To: <1116947116.29938.179.camel@localhost.localdomain> References: <1116904543.18458.23.camel@yoda.jdub.homelinux.org> <1116944369.29938.163.camel@localhost.localdomain> <20050524163449.1cec3f18.bugs.michael@gmx.net> <1116947116.29938.179.camel@localhost.localdomain> Message-ID: <1116952266.2145.2.camel@yoda.jdub.homelinux.org> On Tue, 2005-05-24 at 10:05 -0500, Tom 'spot' Callaway wrote: > On Tue, 2005-05-24 at 16:34 +0200, Michael Schwendt wrote: > > > * pkg-config file in meanwhile-devel has dependencies, a test like > > > > $ pkg-config --exists meanwhile && echo "yes" > > > > fails. > > Are you sure about that? > > [spot at swoop ~]$ pkg-config --print-requires meanwhile > glib-2.0 >= 2.0.0 I also don't have this problem... [jwboyer at yoda ~]$ pkg-config --exists meanwhile && echo "yes" yes [jwboyer at yoda ~]$ Other than this (which I don't think is an issue ATM), I've updated the package based on all the comments from both of you. The updated SRPM has been pushed out to the same location. Just waiting to post my approved message now :). thx, josh From jwboyer at jdub.homelinux.org Tue May 24 16:34:10 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 24 May 2005 11:34:10 -0500 Subject: New package: gaim-meanwhile In-Reply-To: <1116945405.29938.172.camel@localhost.localdomain> References: <1116933896.18458.33.camel@yoda.jdub.homelinux.org> <1116945405.29938.172.camel@localhost.localdomain> Message-ID: <1116952450.2145.6.camel@yoda.jdub.homelinux.org> On Tue, 2005-05-24 at 09:36 -0500, Tom 'spot' Callaway wrote: > > Bad: > > - Zero-length NEWS file doesn't need to be packaged. > - Generic INSTALL file doesn't need to be packaged. > - Package grabbed dependencies on libglib-2.0.so.0, libmeanwhile.so.0, > but not gaim. You probably want to add Requires: gaim >= 1.2.1. > > Again, relatively minor blockers here. Fix and I'll approve. Fixed. Updated packages pushed out to the same location. I'll wait to post the approved message until the meanwhile package is approved since there is a dependency here. thx, josh From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 24 17:05:36 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 24 May 2005 19:05:36 +0200 Subject: Packages failing rebuild for FE4 In-Reply-To: <1116950586.3439.93.camel@bree.local.net> References: <1116950586.3439.93.camel@bree.local.net> Message-ID: <20050524190536.2baeb89f@python2> Jeremy Katz wrote : > * csmash (http://extras64.linux.duke.edu/failed/development/csmash) > Fails on x86_64, looks like a simple 64bit-ism. #156205 has a patch > which looks like it should fix it I'll try that one right now. My x86_64 machine is down at the moment, so I've been postponing my testing for some days now... I hope to get it up and running again within at most a couple of days. > * liboil (http://extras64.linux.duke.edu/failed/development/liboil/) > Fails on i386 with broken asm. Filed as #158641 This one should be updated to 0.3.1, but it fails to rebuild too. Thomasvs told me that the author got it to build fine with gcc4, so maybe it's because FC4 gcc4 is more recent than the last release. > * metakit (http://extras64.linux.duke.edu/failed/development/metakit/) > Fails on x86_64, usual int/pointer confusion. #158460 I'd appreciate help on this one. Anyone want to submit a quick patch? :-) > * viruskiller (http://extras64.linux.duke.edu/failed/development/viruskiller/) > Failed on ppc for no apparent reason. #158647 Interesting :-/ Can someone test a "manual" ppc build? > * libebml > Fails on x86_64, int/pointer problems, #158649 > * libmatroska > Fails on x86_64, int/pointer problem, #158651 There are new releases of those, maybe those problems got fixed already upstream. > * php-pecl-sqlite > Looks like it needs to use sqlite2, not sqlite3, #156240. Maybe > obsolete and should just be dropped? No one commented on my "plan of action", so I'll go for its removal for FC4 and import the newer sqlite3 based php-pecl-pdo-sqlite to provide the same functionality. > * powermanga > Fails on x86_64, int/pointer #158464 Same as metakit, a quick patch would be very welcome! Thanks for your work Jeremy. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.27_FC3 Load : 0.25 0.82 0.74 From byte at aeon.com.my Tue May 24 17:04:32 2005 From: byte at aeon.com.my (Colin Charles) Date: Wed, 25 May 2005 03:04:32 +1000 Subject: Write access permission is needed In-Reply-To: <42930E86.308@mbm.nifty.com> References: <42930E86.308@mbm.nifty.com> Message-ID: <1116954273.2773.79.camel@arena.soho.bytebot.net> On Tue, 2005-05-24 at 20:22 +0900, Ryo Dairiki wrote: > My wiki account: ryo > ID: 1114695854.86.39675 > Name: RyoDairiki Added to the wiki EditGroup. If you haven't already gotten a cvs sponsor, time to do that as well -- Colin Charles, http://www.bytebot.net/ From tcallawa at redhat.com Tue May 24 17:13:22 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 24 May 2005 12:13:22 -0500 Subject: Packages failing rebuild for FE4 In-Reply-To: <20050524190536.2baeb89f@python2> References: <1116950586.3439.93.camel@bree.local.net> <20050524190536.2baeb89f@python2> Message-ID: <1116954803.29938.185.camel@localhost.localdomain> On Tue, 2005-05-24 at 19:05 +0200, Matthias Saou wrote: > > * liboil (http://extras64.linux.duke.edu/failed/development/liboil/) > > Fails on i386 with broken asm. Filed as #158641 > > This one should be updated to 0.3.1, but it fails to rebuild too. Thomasvs > told me that the author got it to build fine with gcc4, so maybe it's > because FC4 gcc4 is more recent than the last release. It builds properly with gcc-4.0.0-2. Updating my x86 FC4 box now. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From mitr at volny.cz Tue May 24 17:54:29 2005 From: mitr at volny.cz (Miloslav Trmac) Date: Tue, 24 May 2005 19:54:29 +0200 Subject: New package: meanwhile In-Reply-To: <1116945737.29938.178.camel@localhost.localdomain> References: <1116904543.18458.23.camel@yoda.jdub.homelinux.org> <1116944369.29938.163.camel@localhost.localdomain> <20050524163449.1cec3f18.bugs.michael@gmx.net> <1116945737.29938.178.camel@localhost.localdomain> Message-ID: <20050524175424.GA4945@chrys.ms.mff.cuni.cz> On Tue, May 24, 2005 at 09:42:16AM -0500, Tom 'spot' Callaway wrote: > > * %post/%postun scriptlets miss dependency on /sbin/ldconfig, > > change them to -p /sbin/ldconfig (as in patch below) to get > > an automatic dependency > > /sbin/ldconfig is in glibc. How exactly will a running system not have > glibc? Simply by compiling this, it will pull in glibc as a Requires. > There isn't any need to -p /sbin/ldconfig to achieve the same thing. There is a different reason why %post -p /sbin/ldconfig is a good idea: rpm recognizes this usage and it can optimize some of the ldconfig runs away if you are installing multiple packages. Mirek From tcallawa at redhat.com Tue May 24 18:02:21 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 24 May 2005 13:02:21 -0500 Subject: New package: meanwhile In-Reply-To: <20050524175424.GA4945@chrys.ms.mff.cuni.cz> References: <1116904543.18458.23.camel@yoda.jdub.homelinux.org> <1116944369.29938.163.camel@localhost.localdomain> <20050524163449.1cec3f18.bugs.michael@gmx.net> <1116945737.29938.178.camel@localhost.localdomain> <20050524175424.GA4945@chrys.ms.mff.cuni.cz> Message-ID: <1116957742.29938.190.camel@localhost.localdomain> On Tue, 2005-05-24 at 19:54 +0200, Miloslav Trmac wrote: > On Tue, May 24, 2005 at 09:42:16AM -0500, Tom 'spot' Callaway wrote: > > > * %post/%postun scriptlets miss dependency on /sbin/ldconfig, > > > change them to -p /sbin/ldconfig (as in patch below) to get > > > an automatic dependency > > > > /sbin/ldconfig is in glibc. How exactly will a running system not have > > glibc? Simply by compiling this, it will pull in glibc as a Requires. > > There isn't any need to -p /sbin/ldconfig to achieve the same thing. > There is a different reason why %post -p /sbin/ldconfig is a good idea: > rpm recognizes this usage and it can optimize some of the ldconfig > runs away if you are installing multiple packages. OK, now thats a better reason. :) ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From bugs.michael at gmx.net Tue May 24 18:02:24 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 24 May 2005 20:02:24 +0200 Subject: New package: meanwhile In-Reply-To: <1116952266.2145.2.camel@yoda.jdub.homelinux.org> References: <1116904543.18458.23.camel@yoda.jdub.homelinux.org> <1116944369.29938.163.camel@localhost.localdomain> <20050524163449.1cec3f18.bugs.michael@gmx.net> <1116947116.29938.179.camel@localhost.localdomain> <1116952266.2145.2.camel@yoda.jdub.homelinux.org> Message-ID: <20050524200224.6f8a0b16.bugs.michael@gmx.net> On Tue, 24 May 2005 11:31:06 -0500, Josh Boyer wrote: > On Tue, 2005-05-24 at 10:05 -0500, Tom 'spot' Callaway wrote: > > On Tue, 2005-05-24 at 16:34 +0200, Michael Schwendt wrote: > > > > > * pkg-config file in meanwhile-devel has dependencies, a test like > > > > > > $ pkg-config --exists meanwhile && echo "yes" > > > > > > fails. > > > > Are you sure about that? Yes. > > [spot at swoop ~]$ pkg-config --print-requires meanwhile > > glib-2.0 >= 2.0.0 > > I also don't have this problem... You do, you do. > [jwboyer at yoda ~]$ pkg-config --exists meanwhile && echo "yes" > yes rpm -e glib2-devel ; then try again From tian at c-sait.net Tue May 24 18:50:38 2005 From: tian at c-sait.net (Christian Jodar) Date: Tue, 24 May 2005 20:50:38 +0200 Subject: Wiki write access needed Message-ID: <20050524205038.6b9696f6@tianbox> Hello, I did this request in the same email where I told I was looking for a sponsor, but it seems it is better to make it separately. I need write access to this page: http://www.fedoraproject.org/wiki/Extras_2fBugzillaAdmin So I will be able to add a request for GCfilms components creation. This application has been approved and already imported to CVS. Thanks, Christian Jodar. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ivazquez at ivazquez.net Tue May 24 18:57:16 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 24 May 2005 14:57:16 -0400 Subject: Packages failing rebuild for FE4 In-Reply-To: <20050524190536.2baeb89f@python2> References: <1116950586.3439.93.camel@bree.local.net> <20050524190536.2baeb89f@python2> Message-ID: <1116961037.14947.8.camel@ignacio.ignacio.lan> On Tue, 2005-05-24 at 19:05 +0200, Matthias Saou wrote: > Jeremy Katz wrote : > > * viruskiller (http://extras64.linux.duke.edu/failed/development/viruskiller/) > > Failed on ppc for no apparent reason. #158647 > > Interesting :-/ Can someone test a "manual" ppc build? One of its BuildReqs (zziplib) isn't available. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Tue May 24 19:16:48 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 24 May 2005 14:16:48 -0500 Subject: New package: meanwhile In-Reply-To: <20050524200224.6f8a0b16.bugs.michael@gmx.net> References: <1116904543.18458.23.camel@yoda.jdub.homelinux.org> <1116944369.29938.163.camel@localhost.localdomain> <20050524163449.1cec3f18.bugs.michael@gmx.net> <1116947116.29938.179.camel@localhost.localdomain> <1116952266.2145.2.camel@yoda.jdub.homelinux.org> <20050524200224.6f8a0b16.bugs.michael@gmx.net> Message-ID: <1116962208.2272.2.camel@yoda.jdub.homelinux.org> On Tue, 2005-05-24 at 20:02 +0200, Michael Schwendt wrote: > On Tue, 24 May 2005 11:31:06 -0500, Josh Boyer wrote: > > > On Tue, 2005-05-24 at 10:05 -0500, Tom 'spot' Callaway wrote: > > > On Tue, 2005-05-24 at 16:34 +0200, Michael Schwendt wrote: > > > > > > > * pkg-config file in meanwhile-devel has dependencies, a test like > > > > > > > > $ pkg-config --exists meanwhile && echo "yes" > > > > > > > > fails. > > > > > > Are you sure about that? > > Yes. > > > > [spot at swoop ~]$ pkg-config --print-requires meanwhile > > > glib-2.0 >= 2.0.0 > > > > I also don't have this problem... > > You do, you do. > > > [jwboyer at yoda ~]$ pkg-config --exists meanwhile && echo "yes" > > yes > > rpm -e glib2-devel ; then try again Ah, yes I see your point. My latest spec fixes that. Mostly because it was in your patch :). Thanks again for the review comments. josh From denis at poolshark.org Tue May 24 19:49:50 2005 From: denis at poolshark.org (Denis Leroy) Date: Tue, 24 May 2005 12:49:50 -0700 Subject: Removal of gtkmm20 (was Re: Packages failing rebuild for FE4) In-Reply-To: <1116950586.3439.93.camel@bree.local.net> References: <1116950586.3439.93.camel@bree.local.net> Message-ID: <4293855E.2080407@poolshark.org> Jeremy Katz wrote: int/pointer, #158466 > * gconfmm20 > Fails on x86_64, int/pointer, #158448 I'd like to request comments on the proposal of removing all the gtkmm 2.0 API packages from FC4 Extras : gtkmm20 gconfmm20 libgnomecanvasmm20 libglademm20 libgnomemm20 libgnomeuimm20 There currently aren't any dependencies to those packages in Extras, and all active gtkmm-based projects that i could find have long moved to the 2.4 API (already in Extras). I'm looking at the list of semi-dormant or dead projects still using the 2.0 API but i can't see anything mature enough for inclusion, and should a specific request come up, my take is it will be easier to create a patch for the 2.4 port and submit it upstream... (see http://gtkmm.sourceforge.net/extra.shtml) Also, the 2.0 branch is not under development any more and its build is likely to fail every time we bump up the version of gcc/g++. -denis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From tian at c-sait.net Tue May 24 20:26:40 2005 From: tian at c-sait.net (Christian Jodar) Date: Tue, 24 May 2005 22:26:40 +0200 Subject: Wiki write access needed In-Reply-To: <20050524205038.6b9696f6@tianbox> References: <20050524205038.6b9696f6@tianbox> Message-ID: <20050524222640.5b66220a@tianbox> Oops, I forgot to mention account details: ID: 1116960052.28.50180 Name: JodarChristian -------------- 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 Tue May 24 20:29:24 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 24 May 2005 16:29:24 -0400 Subject: Removal of gtkmm20 (was Re: Packages failing rebuild for FE4) In-Reply-To: <4293855E.2080407@poolshark.org> References: <1116950586.3439.93.camel@bree.local.net> <4293855E.2080407@poolshark.org> Message-ID: <1116966564.3439.146.camel@bree.local.net> On Tue, 2005-05-24 at 12:49 -0700, Denis Leroy wrote: > Jeremy Katz wrote: > int/pointer, #158466 > > * gconfmm20 > > Fails on x86_64, int/pointer, #158448 > > I'd like to request comments on the proposal of removing all the gtkmm 2.0 API > packages from FC4 Extras : This seems reasonable to me.[1] If someone wishes to add an application later that requires one of these libraries, then they can go back to the packages we last had which worked and resurrect them. Place a request at http://fedoraproject.org/wiki/Extras_2fFC4Status and we'll make it happen. Jeremy [1] It does bring up that we should probably have a slightly more documented process on how to deprecate/remove packages. For now, I say we stick to "mail the list, see if anyone objects horribly" From lemenkov at newmail.ru Tue May 24 21:04:51 2005 From: lemenkov at newmail.ru (Peter Lemenkov) Date: Wed, 25 May 2005 01:04:51 +0400 Subject: GDAL, GDAL-GRASS and GEOS-related questions. Message-ID: Hello, All! Let's return to the GIS-related stuff: the problem was (is?) that GDAL needs GRASS to be built with most features enabled, and GRASS needs (in its turn) GDAL. Where is the solution: * to build GDAL --with-grass=no, * to build GRASS, * to build gdal-grass-plugin after all They says, that folks from Debian-GIS-group already resolved this circular dependency succesively with this technique. http://bugzilla.fedora.us/show_bug.cgi?id=1964#c46 Maybe we can test this method in FE and close this bug? What needs to be done? Links: http://www.gdal.org/dl/gdal-1.2.6.tar.gz http://www.gdal.org/dl/gdal-grass-1.2.3.tar.gz http://pkg-grass.alioth.debian.org/debian-gis/pool/libg/libgdal-grass/libgdal-grass_1.2.5-0.dgis.unstable.2.tar.gz Another one annoying thing is the status of GEOS, which needs maintainer (the one and only trouble with GEOS, am I right?) - I need this package, so could I (if no one will be) be maintainer? We haven't problems with shapelib and PROJ (only absense of maintainer, - the same thing with GEOS) right now, so if everything with GDAL and GDAL-GRASS will be ok, we will be ready for preparing for inclusion QuantumGIS and GRASS to FE. From jspaleta at gmail.com Tue May 24 22:04:36 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 24 May 2005 18:04:36 -0400 Subject: Removal of gtkmm20 (was Re: Packages failing rebuild for FE4) In-Reply-To: <1116966564.3439.146.camel@bree.local.net> References: <1116950586.3439.93.camel@bree.local.net> <4293855E.2080407@poolshark.org> <1116966564.3439.146.camel@bree.local.net> Message-ID: <604aa7910505241504302647e3@mail.gmail.com> On 5/24/05, Jeremy Katz wrote: > [1] It does bring up that we should probably have a slightly more > documented process on how to deprecate/remove packages. For now, I say > we stick to "mail the list, see if anyone objects horribly" And on a related note, how to notify users of extras that these packages have been dropped. Extras is somewhere between a rolling release and a point release model. I'm not sure a 'release notes' document like Core has/had detailing what has been removed since 'last release' makes sense as the primary notification tool for Extras. I doubt it's valid to assume that all package expirations from Extras will come at the opening of a new branch. Appropriate notification of package expiration is a tough nut. Ideally, it would be great if there was a way to inform all users relying on expired Extras packages that there will no longer be updates from this repository, through the same mechanisms as they get updates. But I don't see a way to do that within the current technical limitations of rpms without adding an additional peice of information at the repository level that kept a list of expired packagenames with timestamps for that repository. Package update tools could then parse that additional list of expired packages to notify users of expiration events. -jef From dwmw2 at infradead.org Tue May 24 22:32:31 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 24 May 2005 23:32:31 +0100 Subject: Packages failing rebuild for FE4 In-Reply-To: <20050524190536.2baeb89f@python2> References: <1116950586.3439.93.camel@bree.local.net> <20050524190536.2baeb89f@python2> Message-ID: <1116973952.10919.140.camel@localhost.localdomain> On Tue, 2005-05-24 at 19:05 +0200, Matthias Saou wrote: > > * viruskiller (http://extras64.linux.duke.edu/failed/development/viruskiller/) > > Failed on ppc for no apparent reason. #158647 > > Interesting :-/ Can someone test a "manual" ppc build? You can if you mail me a SSH key and request an account on peach.infradead.org. viruskiller needs zziplib-devel, which doesn't seem to be available. It does build fine though, and after it's built and installed, viruskiller also builds OK. -- dwmw2 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 24 22:39:18 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 25 May 2005 00:39:18 +0200 Subject: Packages failing rebuild for FE4 In-Reply-To: <1116973952.10919.140.camel@localhost.localdomain> References: <1116950586.3439.93.camel@bree.local.net> <20050524190536.2baeb89f@python2> <1116973952.10919.140.camel@localhost.localdomain> Message-ID: <20050525003918.63ed16d4@python2> David Woodhouse wrote : > On Tue, 2005-05-24 at 19:05 +0200, Matthias Saou wrote: > > > * viruskiller (http://extras64.linux.duke.edu/failed/development/viruskiller/) > > > Failed on ppc for no apparent reason. #158647 > > > > Interesting :-/ Can someone test a "manual" ppc build? > > You can if you mail me a SSH key and request an account on > peach.infradead.org. > > viruskiller needs zziplib-devel, which doesn't seem to be available. > > It does build fine though, and after it's built and installed, > viruskiller also builds OK. zziplib's rebuild got requested... but the build systems seems to be either lagging a bit, or stuck... I'll start by waiting, and setting up my x86_64 test machine in the meantime. Thanks to Ignacio and spot for the gcc4 patches too! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.27_FC3 Load : 0.57 0.49 0.37 From justin.conover at gmail.com Wed May 25 00:27:25 2005 From: justin.conover at gmail.com (Justin Conover) Date: Tue, 24 May 2005 19:27:25 -0500 Subject: grip exploding Message-ID: I've had grip close out on me now on my x86_64 and i386 box, (both rawhide). Anyone else? From mfleming at enlartenment.com Wed May 25 00:22:24 2005 From: mfleming at enlartenment.com (mfleming at enlartenment.com) Date: Wed, 25 May 2005 10:22:24 +1000 Subject: Wiki edit access required (CVSSync & BugzilaAdmin) Message-ID: <200505250121.j4P1LT4e029206@mx1.redhat.com> Hi, I need Wiki edit access for the above pages (at least) in order to request a bugzilla component and FC3 branch for mlmmj I think my previous request got lost amongst the traffic, plus I neglected to add the ID as well as my username to the request. My fault :-P ID: 1113041659.58.58802 Wiki username: MichaelFleming Cheers, Michael. -- Michael Fleming From jspaleta at gmail.com Wed May 25 01:34:02 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 24 May 2005 21:34:02 -0400 Subject: grip exploding In-Reply-To: References: Message-ID: <604aa79105052418341805c83d@mail.gmail.com> On 5/24/05, Justin Conover wrote: > I've had grip close out on me now on my x86_64 and i386 box, (both rawhide). > > Anyone else? i'm not sure what you mean exactly. I've ripped about 30 gigs wortth of flacs using grip on a rawhide box in the past 3 or 4 days. I've only had a weird problem, but i think it was kernel related associated with i/o problem writing to the usb harddrive. -jef From elprodigio at gmail.com Wed May 25 01:55:18 2005 From: elprodigio at gmail.com (Didier Casse) Date: Wed, 25 May 2005 09:55:18 +0800 Subject: Sponsor needed: Enlightenment DR17/E17+EFL In-Reply-To: <1116942187.29938.149.camel@localhost.localdomain> References: <513a3b30505240201267f52da@mail.gmail.com> <1116942187.29938.149.camel@localhost.localdomain> Message-ID: <513a3b30505241855188c81ce@mail.gmail.com> Dear Tom, Thank you very much. The Enlightenment community and especially the Fedora-Enlightenment one will be delighted by this. Of course getting packages in Fedora Extras implies naturally a peer review of packages. ;-) This is why I intend to clean up my specs and remove my own preferences and adhere strictly to the Fedora packaging guidelines. I will produce some "new" rpms for the formal review process. Again many thanks. -- Cheers, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. On 5/24/05, Tom 'spot' Callaway wrote: > On Tue, 2005-05-24 at 17:01 +0800, Didier Casse wrote: > > > It might be that you guys do not want anymore WMs in Fedora, but it's > > about giving the community a choice. I chose Linux over MS. And in > > Fedora Linux, some people might want to choose E over GNOME or XFCE > > over KDE. Do you want your users to freely customize their FC distro > > to their heart's desire? > > > > This is to say that I need a sponsor to make this possible. > > Sponsored. (You still need to run your packages through the formal > review process) > > ~spot > -- > Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 > Fedora Extras Steering Committee Member (RPM Standards and Practices) > Aurora Linux Project Leader: http://auroralinux.org > Lemurs, llamas, and sparcs, oh my! > > From elprodigio at gmail.com Wed May 25 02:08:19 2005 From: elprodigio at gmail.com (Didier Casse) Date: Wed, 25 May 2005 10:08:19 +0800 Subject: Sponsor needed: Enlightenment DR17/E17+EFL In-Reply-To: <200505242231.47501.symbiont@berlios.de> References: <513a3b30505240201267f52da@mail.gmail.com> <200505242138.57943.symbiont@berlios.de> <200505242231.47501.symbiont@berlios.de> Message-ID: <513a3b30505241908366ef723@mail.gmail.com> On 5/24/05, Jeff Pitman wrote: > On Tuesday 24 May 2005 21:38, Jeff Pitman wrote: > > On Tuesday 24 May 2005 17:01, Didier Casse wrote: > > > I maintain an apt/yum repository at > > > http://sps.nus.edu.sg/~didierbe > > > for convenience to the FC users. > > > > Prior to getting sponsored, some quick feedback: enlightenment should > > not Requires: gettext-devel. BuildRequires is fine. Thanks Jeff for the feedback. This is being noted. > > More feedback. > > The "engage" package shouldn't Requires: xine-lib-devel. Just the > BuildRequires. You should Requires: xine-lib, though. It doesn't... Engage spec: BuildRequires: libjpeg-devel Requires: esmart, imlib2, imlib2-devel, edje, ecore, evas, ewl > Also, I cannot get engage setup by default: > > $ engage -e gl > GL: create info... > GL: setup info... > GL: gl window setup done. > Esmart_Trans Error: Could not read root window pixmap property! > Esmart_Trans Error: Cannot create transparency pixmap: no valid > wallpaper and no background color set. > GL EXT supported: GL_SGIS_generate_mipmap = ffffffff > GL EXT supported: GL_NV_texture_rectangle = ffffffff > am a system tray :) :) > I guess you're not using the engage module of E17. The stand-alone engage can only be used in E16. It's possible to use the stand-alone version in E17 but it's a little but unclean. >From FAQ: E17 doesn't support fake transparency. Real transparency is used by E17 modules instead. It is possible to force fake transparency usage by setting a root window background with Esetroot (included with Eterm) or e17setroot (included with e_utils, needs Esetroot to be able to force fake transparency). Note that the background you set with Esetroot will now show up in E17, only the applications that use fake transparency will see it. Note that this is a pretty ugly workaround - some apps may not work correctly even if you force fake transparency with Esetroot/e17setroot. To load the engage module in E17, perform: enlightenment_remote -module-load engage This documentation will explain to you the difference between standalone engage and engage module: http://get-e.org/User_Guide/English_pages/4.2.html > Also, I recommend that Keyboard shortcuts and Default Window behavior > are synchronized with what GNOME and KDE provide. For example, > Alt-Tab. It might disgust the E! power user, but I think it's > necessary for those that will be switching between desktops. (GNOME > and KDE finally have come together in common on this thanks to efforts > by Redhat, et al.) Well for this request, I'm afraid this is beyond my control. This is the decision of the lead developer if he wants to do that. I will feedback this to the developers list and Cc to you. We can thus see what they think of it. -- Cheers, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. From justin.conover at gmail.com Wed May 25 02:10:31 2005 From: justin.conover at gmail.com (Justin Conover) Date: Tue, 24 May 2005 21:10:31 -0500 Subject: grip exploding In-Reply-To: <604aa79105052418341805c83d@mail.gmail.com> References: <604aa79105052418341805c83d@mail.gmail.com> Message-ID: On 5/24/05, Jeff Spaleta wrote: > On 5/24/05, Justin Conover wrote: > > I've had grip close out on me now on my x86_64 and i386 box, (both rawhide). > > > > Anyone else? > > i'm not sure what you mean exactly. > I've ripped about 30 gigs wortth of flacs using grip on a rawhide box > in the past 3 or 4 days. I've only had a weird problem, but i think it > was kernel related associated with i/o problem writing to the usb > harddrive. > > -jef > BAH! I give up, well no, but for around 30x, it just stopped and said report to the dev's. Just unexpected. my i386 box is now ripping a cd and my x86_64 kept doing it until I removed the .extras package and installed dags from fc3-64 seems to be working now. From elprodigio at gmail.com Wed May 25 02:16:42 2005 From: elprodigio at gmail.com (Didier Casse) Date: Wed, 25 May 2005 10:16:42 +0800 Subject: Sponsor needed: Enlightenment DR17/E17+EFL In-Reply-To: <200505242359.37057.symbiont@berlios.de> References: <513a3b30505240201267f52da@mail.gmail.com> <20050524153928.GB18925@nostromo.devel.redhat.com> <20050524154558.GA10220@jadzia.bu.edu> <200505242359.37057.symbiont@berlios.de> Message-ID: <513a3b305052419163cbdf25@mail.gmail.com> That's what I meant by a clean up of specs, which I already intended to do. ;-) In the beginning I did certain things for convenience. Now that it's going for the FC extras, I will adhere strictly to standards. I'll submit the clean packages for peer review in the next 2-3 days. But thanks for the comments. -- Cheers, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. On 5/24/05, Jeff Pitman wrote: > On Tuesday 24 May 2005 23:45, Matthew Miller wrote: > > On Tue, May 24, 2005 at 11:39:28AM -0400, Bill Nottingham wrote: > > > > The "engage" package shouldn't Requires: xine-lib-devel. Just > > > > the BuildRequires. You should Requires: xine-lib, though. > > > > > > ... and if you're requiring xine-lib, you really can't built it in > > > Extras. > > > > And even if you could, is there any reason to say "Requires: > > xine-lib" instead of just letting RPM's auto-deps pick it up? > > Probably. Anyway, in general, there's a lot of Requires: .*-devel in > this repo. So, that needs to be fixed by just using BuildRequires for > all of them. > > Also, *.a and *.la libs are in the non-devel packages. So, these need > to be filtered out into separate -devel packages. > > Another one to look at is /usr/local shouldn't be used for these > packages. So, some configure fun needs to be engaged in for each of > the packages that use this directory. > > -- > -jeff > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From elprodigio at gmail.com Wed May 25 02:25:21 2005 From: elprodigio at gmail.com (Didier Casse) Date: Wed, 25 May 2005 10:25:21 +0800 Subject: Sponsor needed: Enlightenment DR17/E17+EFL In-Reply-To: <1116951423.25038.9.camel@ignacio.ignacio.lan> References: <513a3b30505240201267f52da@mail.gmail.com> <1116951423.25038.9.camel@ignacio.ignacio.lan> Message-ID: <513a3b3050524192529825d24@mail.gmail.com> On 5/25/05, Ignacio Vazquez-Abrams wrote: > On Tue, 2005-05-24 at 17:01 +0800, Didier Casse wrote: > > I was encouraged by Rahul Sundaram and Mark McLoughlin to push this > > work into extras so that users of Fedora do not need to hunt the repo > > down. > > I've been pulling the snapshots into Extras little by little. So far > only edb and eet are in due to the fact that there are only 24 hours in > a day, and 7 days in a week, but I do intend on pulling more in. Perhaps > we should coordinate. Dear Ignacio, Of course we could work together. ;-) Just let me know how you want to proceed or how you want this to be done. -- Cheers, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. From mccann0011 at hotmail.com Wed May 25 03:47:44 2005 From: mccann0011 at hotmail.com (Shawn McCann) Date: Tue, 24 May 2005 20:47:44 -0700 Subject: Volunteering to maintain proj and shapelib packages Message-ID: Hi, I'm looking to get involved in the Fedora project and was drawn to the list of packages needing a maintainer. As I've used proj and shapelib before, volunteering to maintain them seems a good place to start. I'm located in Vancouver, Canada and started working with UNIX and C about 15 years ago. Since then I evolved into C++, then Java and finally J2EE based web systems. I first used Linux many years ago when I installed Red Hat 2.1 on my home computer. I got back into it again with Red Hat 8 and am now running FC3 on my laptop and home server. The company I work for builds systems around the world in various domains, especially for remote sensing from satellites. I've recently been working with on projects to deploy Linux (RHEL) and GIS systems in developing countries, hence my renewed interest in the discussions on adding GRASS to Fedora Extras. I haven't applied for CVS access yet but will do so as soon someone indicates that this would be worthwhile. Regards Shawn From lemenkov at newmail.ru Wed May 25 04:56:17 2005 From: lemenkov at newmail.ru (Peter Lemenkov) Date: Wed, 25 May 2005 08:56:17 +0400 Subject: Volunteering to maintain proj and shapelib packages In-Reply-To: References: Message-ID: Shawn McCann ?????: > I'm looking to get involved in the Fedora project and was drawn to the > list of packages needing a maintainer. As I've used proj and shapelib > before, volunteering to maintain them seems a good place to start. It would be great! We got another GIS-related package w/o maintainer - GEOS, which blocks inclusion of QuantumGIS to FE. > The company I work for builds systems around the world in various > domains, especially for remote sensing from satellites. I've recently > been working with on projects to deploy Linux (RHEL) and GIS systems in > developing countries, hence my renewed interest in the discussions on > adding GRASS to Fedora Extras. GRASS needs another problem to be solved - GDAL and GDAL-GRASS plugin. FYI we also got AutoTrace, a good free, opensource vectorizer, w/o maintainer. From byte at aeon.com.my Wed May 25 10:47:59 2005 From: byte at aeon.com.my (Colin Charles) Date: Wed, 25 May 2005 20:47:59 +1000 Subject: Packages failing rebuild for FE4 In-Reply-To: <20050525003918.63ed16d4@python2> References: <1116950586.3439.93.camel@bree.local.net> <20050524190536.2baeb89f@python2> <1116973952.10919.140.camel@localhost.localdomain> <20050525003918.63ed16d4@python2> Message-ID: <1117018079.2773.125.camel@arena.soho.bytebot.net> On Wed, 2005-05-25 at 00:39 +0200, Matthias Saou wrote: > > viruskiller needs zziplib-devel, which doesn't seem to be available. > > > > It does build fine though, and after it's built and installed, > > viruskiller also builds OK. > > zziplib's rebuild got requested... but the build systems seems to be > either lagging a bit, or stuck... I'll start by waiting, and setting > up my > x86_64 test machine in the meantime. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158647 It works fine, and zziplib works fine too. Just get the buildsys to go and all will be well -- Colin Charles, http://www.bytebot.net/ From byte at aeon.com.my Wed May 25 10:53:43 2005 From: byte at aeon.com.my (Colin Charles) Date: Wed, 25 May 2005 20:53:43 +1000 Subject: Wiki write access needed In-Reply-To: <20050524222640.5b66220a@tianbox> References: <20050524205038.6b9696f6@tianbox> <20050524222640.5b66220a@tianbox> Message-ID: <1117018423.2773.127.camel@arena.soho.bytebot.net> On Tue, 2005-05-24 at 22:26 +0200, Christian Jodar wrote: > Name: JodarChristian Done. -- Colin Charles, http://www.bytebot.net/ From joost at cnoc.nl Wed May 25 11:07:28 2005 From: joost at cnoc.nl (Joost van der Sluis) Date: Wed, 25 May 2005 13:07:28 +0200 Subject: New package: fpc-2.0.0 In-Reply-To: <4292AC08.5000503@redhat.com> References: <1116876717.23375.28.camel@joost> <4292AC08.5000503@redhat.com> Message-ID: <1117019248.16169.45.camel@joost> On Tue, 2005-05-24 at 13:22 +0900, Jens Petersen wrote: > It doesn't seem to build completely on x86_64, since > the libs are installed in /usr/lib and not /usr/lib64. I've tried to fix that. Coudn't test it though, I don't have regular access to a x86_64 machine. Could someone also test it on ppc? > Overall the spec file looks ok, I attach a patch with > some initial cleanup. Further comments: Applied to the spec-file. > - "examples/" seems to be too big to include in the main package: > I recommend either excluding it or at least moving it to a -doc > subpackage I removed the examples and will make a -doc subpackage. Only thing is that that package must contain the full fpc-sources since the examples are spread throughout the sources. Is that ok? > - If more html documentation available, it could also go into -doc. > I see there is a -docs subpackage on the upstream download page. The documentation can be generated as .pdf or .html. (Both has some problems in the 2.0.0 release, but there are patches for that) > - the software is GPL/LGPL :), but are there any legal issues with > highlighting TP and Delphi compatibility? You mean problems with the 'TP and Delphi compatibility' statement? I won't know why. > - (It would be nice if upstream could simplify building and installing > without the setup.sh script?:) Which script do you mean? > - can fpc be built with debugging info? Would it be useful? Currently > no debuginfo is generated afaict. fpc Can be build with debuginfo. But that's only usefull for debugging the compiler, and ppl who do that, won't use this RPM. Maybe the RTL and FCL (Freepascal Compiler Libraries) can be build with debuginfo, but that is removed on purpose. If the debuginfo is included, developers who try to debug their own code will get exceptions in RTL or FCL code, instead of in their own code. That's only usefull for the FPC-developers themselves, and again: they won't use this RPM. In general: for releases the debuginfo is kept out of fpc. But with the debuginfo included gdb can be used to debug fpc-generated code. The new spec-file and source rpm can be found here: (I also fixed Jochen Schhmitt's comment) http://www.cnoc.nl/fpc/fpc.spec http://www.cnoc.nl/fpc/fpc-2.0.0-0.2.src.rpm http://www.cnoc.nl/fpc/MD5SUM Regards, Joost van der Sluis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From byte at aeon.com.my Wed May 25 11:52:41 2005 From: byte at aeon.com.my (Colin Charles) Date: Wed, 25 May 2005 21:52:41 +1000 Subject: Wiki edit access required (CVSSync & BugzilaAdmin) In-Reply-To: <200505250121.j4P1LT4e029206@mx1.redhat.com> References: <200505250121.j4P1LT4e029206@mx1.redhat.com> Message-ID: <1117021961.2773.137.camel@arena.soho.bytebot.net> On Wed, 2005-05-25 at 10:22 +1000, mfleming at enlartenment.com wrote: > I think my previous request got lost amongst the traffic, plus I > neglected > to add the ID as well as my username to the request. My fault :-P > > ID: 1113041659.58.58802 > Wiki username: MichaelFleming Done. -- Colin Charles, http://www.bytebot.net/ From tian at c-sait.net Wed May 25 12:21:48 2005 From: tian at c-sait.net (Tian) Date: Wed, 25 May 2005 14:21:48 +0200 (CEST) Subject: Wiki write access needed In-Reply-To: <1117018423.2773.127.camel@arena.soho.bytebot.net> References: <20050524205038.6b9696f6@tianbox> <20050524222640.5b66220a@tianbox> <1117018423.2773.127.camel@arena.soho.bytebot.net> Message-ID: <42108.62.210.124.226.1117023708.squirrel@62.210.124.226> > Done. Thanks. I updated the page. From toshio at tiki-lounge.com Wed May 25 13:47:07 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 25 May 2005 06:47:07 -0700 Subject: [buildsys@fedoraproject.org: Build Result: ocaml on development] Message-ID: <20050525064707.B7991@tiki-lounge.com> ----- Forwarded message from buildsys at fedoraproject.org ----- Build of ocaml on development failed to complete on one or more archs. Please see logs at: http://extras64.linux.duke.edu/failed/development/ocaml ----- End forwarded message ----- Build logs seem to indicate a problem pulling packages down from the mirrors. Is this a known problem? -Toshio From skvidal at phy.duke.edu Wed May 25 13:56:01 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 25 May 2005 09:56:01 -0400 Subject: [buildsys@fedoraproject.org: Build Result: ocaml on development] In-Reply-To: <20050525064707.B7991@tiki-lounge.com> References: <20050525064707.B7991@tiki-lounge.com> Message-ID: <1117029361.13904.0.camel@cutter> On Wed, 2005-05-25 at 06:47 -0700, Toshio Kuratomi wrote: > ----- Forwarded message from buildsys at fedoraproject.org ----- > > Build of ocaml on development failed to complete on one or more archs. Please see logs at: > http://extras64.linux.duke.edu/failed/development/ocaml > > ----- End forwarded message ----- > > Build logs seem to indicate a problem pulling packages down from the > mirrors. Is this a known problem? > rawhide mirrors are sometimes out of sync exactly when a package is being built? Yah, that can happen. -sv From toshio at tiki-lounge.com Wed May 25 13:53:50 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 25 May 2005 06:53:50 -0700 Subject: [buildsys@fedoraproject.org: Build Result: ocaml on development] In-Reply-To: <1117029361.13904.0.camel@cutter>; from skvidal@phy.duke.edu on Wed, May 25, 2005 at 09:56:01AM -0400 References: <20050525064707.B7991@tiki-lounge.com> <1117029361.13904.0.camel@cutter> Message-ID: <20050525065350.C7991@tiki-lounge.com> On Wed, May 25, 2005 at 09:56:01AM -0400, seth vidal wrote: > On Wed, 2005-05-25 at 06:47 -0700, Toshio Kuratomi wrote: > > [ocaml package] > > Build logs seem to indicate a problem pulling packages down from the > > mirrors. Is this a known problem? > > > > rawhide mirrors are sometimes out of sync exactly when a package is > being built? Yah, that can happen. > > -sv > Thanks. I'll just resubmit then. -Toshio From katzj at redhat.com Wed May 25 15:37:45 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 25 May 2005 11:37:45 -0400 Subject: Packages failing rebuild for FE4 In-Reply-To: <20050525003918.63ed16d4@python2> References: <1116950586.3439.93.camel@bree.local.net> <20050524190536.2baeb89f@python2> <1116973952.10919.140.camel@localhost.localdomain> <20050525003918.63ed16d4@python2> Message-ID: <1117035465.9191.3.camel@bree.local.net> On Wed, 2005-05-25 at 00:39 +0200, Matthias Saou wrote: > David Woodhouse wrote : > > On Tue, 2005-05-24 at 19:05 +0200, Matthias Saou wrote: > > > > * viruskiller (http://extras64.linux.duke.edu/failed/development/viruskiller/) > > > > Failed on ppc for no apparent reason. #158647 > > > > > > Interesting :-/ Can someone test a "manual" ppc build? > > > > You can if you mail me a SSH key and request an account on > > peach.infradead.org. > > > > viruskiller needs zziplib-devel, which doesn't seem to be available. > > > > It does build fine though, and after it's built and installed, > > viruskiller also builds OK. > > zziplib's rebuild got requested... but the build systems seems to be > either lagging a bit, or stuck... I'll start by waiting, and setting up my > x86_64 test machine in the meantime. I didn't do much in the way of ordering, so this is probably due to that. zziplib has definitely now succeeded, so I queued up viruskiller for another crack at it :-) Jeremy From katzj at redhat.com Wed May 25 20:48:58 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 25 May 2005 16:48:58 -0400 Subject: Packages failing rebuild for FE4 In-Reply-To: <20050524190536.2baeb89f@python2> References: <1116950586.3439.93.camel@bree.local.net> <20050524190536.2baeb89f@python2> Message-ID: <1117054138.9191.19.camel@bree.local.net> On Tue, 2005-05-24 at 19:05 +0200, Matthias Saou wrote: > > * metakit (http://extras64.linux.duke.edu/failed/development/metakit/) > > Fails on x86_64, usual int/pointer confusion. #158460 > > I'd appreciate help on this one. Anyone want to submit a quick patch? :-) Ignacio's patch got things most of the way there, I finished it and kicked off a build. > > * libebml > > Fails on x86_64, int/pointer problems, #158649 > > * libmatroska > > Fails on x86_64, int/pointer problem, #158651 > > There are new releases of those, maybe those problems got fixed already > upstream. In fact, they did. Updated and queued. > > * php-pecl-sqlite > > Looks like it needs to use sqlite2, not sqlite3, #156240. Maybe > > obsolete and should just be dropped? > > No one commented on my "plan of action", so I'll go for its removal for > FC4 and import the newer sqlite3 based php-pecl-pdo-sqlite to provide the > same functionality. Sounds good. > > * powermanga > > Fails on x86_64, int/pointer #158464 > > Same as metakit, a quick patch would be very welcome! Ignacio's patch gets it building and running here, so committed and queued. Jeremy From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed May 25 21:17:28 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 25 May 2005 23:17:28 +0200 Subject: Packages failing rebuild for FE4 In-Reply-To: <1117054138.9191.19.camel@bree.local.net> References: <1116950586.3439.93.camel@bree.local.net> <20050524190536.2baeb89f@python2> <1117054138.9191.19.camel@bree.local.net> Message-ID: <20050525231728.06bb2718@python2> Jeremy Katz wrote : > > > * libebml > > > Fails on x86_64, int/pointer problems, #158649 > > > * libmatroska > > > Fails on x86_64, int/pointer problem, #158651 > > > > There are new releases of those, maybe those problems got fixed already > > upstream. > > In fact, they did. Updated and queued. Hmmm... I also noted that upstream now makes the build produce the shared libs by default, which means : 1) The packages will need further changes to be split main/devel at last. 2) Projects that use them and can link dynamically could fancy a rebuild. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.27_FC3 Load : 0.79 0.74 0.32 From ryo-dairiki at mbm.nifty.com Wed May 25 23:35:09 2005 From: ryo-dairiki at mbm.nifty.com (Ryo Dairiki) Date: Thu, 26 May 2005 08:35:09 +0900 Subject: Re2: Write access permission is needed Message-ID: <42950BAD.3020907@mbm.nifty.com> > > > On Tue, 2005-05-24 at 20:22 +0900, Ryo Dairiki wrote: > >>> My wiki account: ryo >>> ID: 1114695854.86.39675 >>> Name: RyoDairiki >> >> > >Added to the wiki EditGroup. If you haven't already gotten a cvs >sponsor, time to do that as well > -- Colin Charles, http://www.bytebot.net/ > Thank you. Now I can registrate scim as a bugzilla component. I have cvs access, thank you. Ryo Dairiki From ivazquez at ivazquez.net Thu May 26 01:22:25 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 25 May 2005 21:22:25 -0400 Subject: Kernel module standards Message-ID: <1117070545.30966.44.camel@ignacio.ignacio.lan> I was asked by Warren to post the standards that I use for building kernel modules, so here they are. > %{!?kernelroot: %define kernelroot "" } When building a kernel for multiple archs it's handy to have the kernel/kernel-devel package for the archs all installed at the same time. While UP/SMP/hugemem/Xen kernels can be installed on the same root, two UP kernels for different archs cannot. The way I get around this is to install the kernel in /$arch, then pass '--define "kernelroot /$arch"' to rpmbuild. In this way I can build the module for all archs in one go instead of having to deal with switching kernels in and out, *PLUS* it still builds properly if someone just does 'rpmbuild -bb kernel-module-foo.spec' provided they have the kernel-devel package for the kernel they're running. > %{!?kernelversion: %define kernelversion %(uname -r) } Like above, except this is used for selecting between parallel-installed kernel versions. > %package %{kernelversion} Yes, it's ugly, but it does allow multiple copies of a module to be installed, one per kernel version. > Provides: %{name} = %{version} I'm sure this will come in handy one day... The attached script is how I invoke rpmbuild to build it on FC3/i386. It's easy enough to modify it for other archs/distros, I just haven't needed to as of yet. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- %{!?kernelroot: %define kernelroot "" } %{!?kernelversion: %define kernelversion %(uname -r) } Name: kernel-module-qla4xxx Version: 5.00.02 Release: 0.iva.1 Summary: Driver for QLogic QLA4xxx iSCSI cards Group: System Environment/Base License: GPL URL: http://www.qlogic.com/ Source0: http://download.qlogic.com/drivers/27588/qla4xxx-5.00.02.tar.gz Patch: qla4xxx-5.00.02-inline.patch Patch1: qla4xxx-5.00.02-build.patch BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) ExclusiveArch: i586 i686 x86_64 %description This package contains the driver for QLogic's QLA4xxx series of iSCSI cards. %package %{kernelversion} Summary: Driver for QLogic QLA4xxx iSCSI cards Group: System Environment/Base Provides: %{name} = %{version} %description %{kernelversion} This package contains the driver for QLogic's QLA4xxx series of iSCSI cards for kernel %{kernelversion} for the %{_target_cpu} architecture. %prep %setup -q -n 5.00.02 chmod u+x extras %patch -p1 -b .inline %patch1 -p1 -b .build %build K_LIBS=%{kernelroot}/lib/modules/%{kernelversion} extras/build.sh %install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT/lib/modules/%{kernelversion}/kernel/drivers/scsi/qla4xxx install -m 0644 qla4xxx.ko $RPM_BUILD_ROOT/lib/modules/%{kernelversion}/kernel/drivers/scsi/qla4xxx %clean rm -rf $RPM_BUILD_ROOT %post %{kernelversion} depmod -ae %postun %{kernelversion} if [ $1 -eq 0 ]; then depmod -aq fi %files %{kernelversion} %defattr(-,root,root,-) %doc ../release.txt revision.notes /lib/modules/%{kernelversion}/kernel/drivers/scsi/qla4xxx/qla4xxx.ko %changelog * Wed May 25 2005 Ignacio Vazquez-Abrams 5.00.02-0.iva.1 - Initial RPM release -------------- next part -------------- A non-text attachment was scrubbed... Name: ivazquez-buildkernelmodule Type: application/x-shellscript Size: 1005 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jpo at di.uminho.pt Thu May 26 01:39:22 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Thu, 26 May 2005 02:39:22 +0100 Subject: Review request 2: syslog-ng (syslog replacement daemon) Message-ID: <429528CA.3050506@di.uminho.pt> Summary: Syslog replacement daemon http://www.balabit.com/products/syslog_ng/ Description: syslog-ng, as the name shows, is a syslogd replacement, but with new functionality for the new generation. The original syslogd allows messages only to be sorted based on priority/facility pairs; syslog-ng adds the possibility to filter based on message contents using regular expressions. The new configuration scheme is intuitive and powerful. Forwarding logs over TCP and remembering all forwarding hops makes it ideal for firewalled environments. Specfile changelog: * Thu May 26 2005 Jose Pedro Oliveira - 1.6.7-3 - Shipping the sysklogd logrotate file and using the same pidfile as suggested by Jeremy Katz. - Patching the init script: no default runlevels. - Removed the triggers to handle the logrotate file (no longer needed). - The SELinux use_syslogng boolean has been dropped (rules enabled). Note: Right now the SELinux has only been dropped from the FC4 policy (backport to FC3 and RHEL4 also expected) jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From buildsys at fedoraproject.org Thu May 26 05:24:37 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 26 May 2005 01:24:37 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050526052437.F04898040@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 16 amarok-1.2.4-1 amarok-1.2.4-1.fc3 eet-0.9.10.007-3 eet-0.9.10.007-3.fc3 gnome-applet-sensors-0.7.3-1 gnome-applet-sensors-0.7.3-1.fc3 meanwhile-0.4.1-2 meanwhile-0.4.1-2.fc3 mhonarc-2.6.11-1 mhonarc-2.6.11-1.fc3 perl-Test-Memory-Cycle-1.02-1 perl-Test-Memory-Cycle-1.02-1.fc3 qgo-1.0.1-3 qgo-1.0.1-3.fc3 sqlite2-2.8.16-1 sqlite2-2.8.16-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From paul at city-fan.org Thu May 26 08:48:19 2005 From: paul at city-fan.org (Paul Howarth) Date: Thu, 26 May 2005 09:48:19 +0100 Subject: Kernel module standards In-Reply-To: <1117070545.30966.44.camel@ignacio.ignacio.lan> References: <1117070545.30966.44.camel@ignacio.ignacio.lan> Message-ID: <42958D53.3030901@city-fan.org> Ignacio Vazquez-Abrams wrote: > I was asked by Warren to post the standards that I use for building > kernel modules, so here they are. Perhaps a template spec file could be added to fedora-rpmdevtools, as per the perl and python template spec files? Paul. From fedora at leemhuis.info Thu May 26 09:17:44 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 26 May 2005 11:17:44 +0200 Subject: Kernel module standards In-Reply-To: <42958D53.3030901@city-fan.org> References: <1117070545.30966.44.camel@ignacio.ignacio.lan> <42958D53.3030901@city-fan.org> Message-ID: <1117099064.28694.31.camel@thl.ct.heise.de> Am Donnerstag, den 26.05.2005, 09:48 +0100 schrieb Paul Howarth: > Ignacio Vazquez-Abrams wrote: > > I was asked by Warren to post the standards that I use for building > > kernel modules, so here they are. > > Perhaps a template spec file could be added to fedora-rpmdevtools, as > per the perl and python template spec files? We need a longer discussion how to package kernel-modules first. Then a concept. Support for the result in yum&co. A bit of testing if everything works as expected. I suppose after that we need small adjustments to the concept and/or yum&co again. Several concepts already exists that describe how kernel-modules can be packaged: Fedora.us had one, livna uses a slightly modified version of it these days. Then there is the one from Ignacio, Atrpms also has one iirc and even in FC4 there are kernel-modules in own rpm packages. But afaics there is no concept currently that works completely without drawbacks. Spot initiated a discussion on kernel-module packaging some months ago. But it ended without results because it a hard task afaics :-( I'm willing to help here (I maintain some kernel-module packages) -- but imho that should be done after FC4 is out and extras for FC4 is in a better shape. Just my 2 cent. CU thl From ndbecker2 at gmail.com Thu May 26 10:47:35 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 26 May 2005 06:47:35 -0400 Subject: openvpn anyone? Message-ID: Is anyone packaging openvpn? I will volunteer if nobody else is doing this. From buildsys at fedoraproject.org Thu May 26 13:05:34 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 26 May 2005 09:05:34 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050526130534.02FE380EE@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 145 Inventor-2.1.5-11 Inventor-2.1.5-11.fc4 aiksaurus-1.2.1-7 allegro-4.0.3-13 arc-5.21j-4 bittorrent-4.0.2-1 bittorrent-4.0.2-1.fc4 bluefish-1.0-4 brightside-1.4.0-7 camstream-0.26.3-8 cln-1.1.9-2 cln-1.1.9-2.fc4 cook-2.25-4 csmash-0.6.6-9 eet-0.9.10.007-3 eet-0.9.10.007-3.fc4 elmo-1.2.0-4 fftw-2.1.5-8 fwbuilder-2.0.6-3 gaim-meanwhile-1.2.2-2 gaim-meanwhile-1.2.2-2.fc4 global-4.8.4-4 gnome-blog-0.8-9 gnome-blog-0.8-9.fc4 gramps-2.0.0-1 graphviz-2.2.1-2 grisbi-0.5.5-4.fc4 gurlchecker-0.6.3-5 hercules-3.02-3 john-1.6-4 kannel-1.4.0-5 kickpim-0.5.3-7 kile-1.7.1-5 kile-i18n-1.7-5 kover-2.9.6-3 ktrack-0.3.0-11.rc1.fc4 lablgl-1.01-5 ladspa-1.12-5 lcms-1.14-3 leafnode-1.9.53-3 lib3ds-1.2.0-5 libcddb-1.0.2-2 libdaemon-0.6-6 libebml-0.7.5-1 libfac-2.0.5-3 libfwbuilder-2.0.6-3 libglademm20-2.2.0-3 libgnomecanvasmm20-2.0.1-3 libgnomemm20-2.0.1-3 libgnomeuimm20-2.0.0-3 libkexif-0.2.1-3 libmatroska-0.7.7-1 libnet10-1.0.2a-7 liboil-0.3.0-4 librsync-0.9.7-4 libsafe-2.0-17c libsafe-2.0-17c.fc4 libshout-1.0.9-4 libsigsegv-2.1-4 libtar-1.2.11-5 libtasn1-0.2.6-3 libuninameslist-0.0-4.040707 libzvt-2.0.1-7 lighttpd-1.3.13-5 lincvs-1.4.1-1 linux_logo-4.12-2 lmarbles-1.0.7-3 lua-5.0.2-4 lyx-1.3.5-5 lzo-1.08-4 lzop-1.01-3 meanwhile-0.4.1-2 meanwhile-0.4.1-2.fc4 metakit-2.4.9.3-7 mhonarc-2.6.11-1 mhonarc-2.6.11-1.fc4 mpc-0.11.2-3 neXtaw-0.15.1-3 neverball-1.4.0-4 nget-0.27.1-4 nomarch-1.3-3 ocaml-3.08.3-5 oidentd-2.0.7-7 openal-0.0-0.4.20040726 opencdk-0.5.5-3 openslp-1.2.0-6 p0f-2.0.5-3 parchive-1.1-4 pcsc-perl-1.3.1-7 perl-Class-MethodMaker-2.06-3 perl-Test-Memory-Cycle-1.02-1 perl-Test-Memory-Cycle-1.02-1.fc4 perl-Text-Autoformat-1.13-1 perl-Text-Autoformat-1.13-1.fc4 pgadmin3-1.0.2-5 pl-5.4.6-9 plib-1.8.3-7 portaudio-18.1-5 powermanga-0.79-5 proj-4.4.8-6 python-imaging-1.1.4-9 qca-1.0-5 qca-tls-1.0-4 qcad-2.0.4.0-5.fc4 qgo-1.0.1-4 qgo-1.0.1-4.fc4 qhull-2003.1-4 qiv-2.0-3 rxvt-2.7.10-7 scribus-1.2.1-5 sirius-0.8.0-5 skencil-0.6.16-5 sqlite2-2.8.16-1 sqlite2-2.8.16-1.fc4 starfighter-1.1-5 supertux-0.1.2-3 t1lib-5.0.2-3 t1utils-1.32-3 tdl-1.5.2-3 tetex-lgrind-3.67-6 thttpd-2.25b-7 tidy-0.99.0-4.20041214 tin-1.6.2-4 treecc-0.3.4-4 ttf2pt1-3.4.4-4 tuxpaint-0.9.13-3 tuxtype2-1.5.2-3 ufraw-0.4-2 unrtf-0.19.3-4 uqm-0.4.0-1 uqm-content-0.4.0-1 vnstat-1.4-5 wbxml2-0.9.0-4 xcin-2.5.3.pre3-27 xforms-1.0-4 xlhtml-0.5-4 xmms-acme-0.4.2-4 xmms-cdread-0.14-6.a xmms-lirc-1.4-6 xmms-sid-0.7.4-6 xplanet-1.0.1-7 xtide-2.8-4 xvattr-1.3-7 yasm-0.4.0-4 zziplib-0.13.38-2 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From joost at cnoc.nl Thu May 26 14:14:02 2005 From: joost at cnoc.nl (Joost van der Sluis) Date: Thu, 26 May 2005 16:14:02 +0200 Subject: New package: fpc-2.0.0 In-Reply-To: <1117019248.16169.45.camel@joost> References: <1116876717.23375.28.camel@joost> <4292AC08.5000503@redhat.com> <1117019248.16169.45.camel@joost> Message-ID: <1117116843.15189.9.camel@joost> > The new spec-file and source rpm can be found here: (I also fixed Jochen > Schhmitt's comment) I've made a new version which fixed a problem with a direct link to 'lib' and a typo: http://www.cnoc.nl/fpc/fpc.spec http://www.cnoc.nl/fpc/fpc-2.0.0-0.3.src.rpm http://www.cnoc.nl/fpc/MD5SUM Regards, Joost. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Thu May 26 15:11:00 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 26 May 2005 18:11:00 +0300 Subject: openvpn anyone? In-Reply-To: References: Message-ID: <1117120260.22702.2.camel@bobcat.mine.nu> On Thu, 2005-05-26 at 06:47 -0400, Neal Becker wrote: > Is anyone packaging openvpn? I will volunteer if nobody else is doing this. http://bugzilla.fedora.us/show_bug.cgi?id=1531 From hutnick at gmail.com Thu May 26 15:26:58 2005 From: hutnick at gmail.com (Peter Hutnick) Date: Thu, 26 May 2005 09:26:58 -0600 Subject: LIRC with Streamzap Message-ID: <63a3625b05052608262f5a96fa@mail.gmail.com> Hello, The Fedora Extras LIRC 0.7.1 RPM is missing Streamzap support for some reason. Support for this device is in the LIRC 0.7.1 source tarball. Any chance of getting the RPM rebuilt with this support? Thanks! -Peter From lfarkas at bppiac.hu Thu May 26 15:30:15 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Thu, 26 May 2005 17:30:15 +0200 Subject: openvpn anyone? In-Reply-To: <1117120260.22702.2.camel@bobcat.mine.nu> References: <1117120260.22702.2.camel@bobcat.mine.nu> Message-ID: <4295EB87.6000802@bppiac.hu> Ville Skytt? wrote: > On Thu, 2005-05-26 at 06:47 -0400, Neal Becker wrote: > >>Is anyone packaging openvpn? I will volunteer if nobody else is doing this. > > > http://bugzilla.fedora.us/show_bug.cgi?id=1531 dag repository also contains the latest. -- Levente "Si vis pacem para bellum!" From katzj at redhat.com Thu May 26 16:07:50 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 26 May 2005 12:07:50 -0400 Subject: a few more rebuild failures Message-ID: <1117123670.22921.33.camel@bree.local.net> * TeXmacs Fails to build on x86_64. (#158886) * gwenview Fails to build on x86_64 (unable to find qtdir) (#158887) * amaya Fails to build on x86_64 (pointer/int) (#158888) * bochs Fails to build on x86_64 (pointer/int) (#158889) Later this afternoon, I'm going to run my script again to see what's out of sync just to make sure nothing has been missed. Jeremy From ville.skytta at iki.fi Thu May 26 16:59:07 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 26 May 2005 19:59:07 +0300 Subject: LIRC with Streamzap In-Reply-To: <63a3625b05052608262f5a96fa@mail.gmail.com> References: <63a3625b05052608262f5a96fa@mail.gmail.com> Message-ID: <1117126747.22702.26.camel@bobcat.mine.nu> On Thu, 2005-05-26 at 09:26 -0600, Peter Hutnick wrote: > The Fedora Extras LIRC 0.7.1 RPM is missing Streamzap support for some > reason. Support for this device is in the LIRC 0.7.1 source tarball. > > Any chance of getting the RPM rebuilt with this support? streamzap seems to be implemented as a kernel module, and we haven't agreed how to package kernel modules yet in Extras, that's why. If you're running FC3, you can grab the kernel-module-devel package for your kernel from rpm.livna.org and try rebuilding the Extras source rpm with "rpmbuild --with kmod --target i686" (if you've a i686 kernel). It used to work at some point, but I haven't checked lately. Oh, and you may need to add streamzap to "drivers" at the top of the specfile before rebuilding. I'll look into at least updating the kernel module build in the lirc specfile soon as well as adjusting it for FC4 kernel-devel packages to make rebuilders' lives easier, but hopefully we can ship kernel module packages from Extras soon. From hutnick at gmail.com Thu May 26 18:00:48 2005 From: hutnick at gmail.com (Peter Hutnick) Date: Thu, 26 May 2005 12:00:48 -0600 Subject: LIRC with Streamzap In-Reply-To: <1117126747.22702.26.camel@bobcat.mine.nu> References: <63a3625b05052608262f5a96fa@mail.gmail.com> <1117126747.22702.26.camel@bobcat.mine.nu> Message-ID: <63a3625b0505261100655d0270@mail.gmail.com> On 5/26/05, Ville Skytt? wrote: > On Thu, 2005-05-26 at 09:26 -0600, Peter Hutnick wrote: > > > The Fedora Extras LIRC 0.7.1 RPM is missing Streamzap support for some > > reason. Support for this device is in the LIRC 0.7.1 source tarball. > > > > Any chance of getting the RPM rebuilt with this support? > > streamzap seems to be implemented as a kernel module, and we haven't > agreed how to package kernel modules yet in Extras, that's why. Okay. It's good to know there's a reason :-) > If you're running FC3, you can grab the kernel-module-devel package for > your kernel from rpm.livna.org and try rebuilding the Extras source rpm > with "rpmbuild --with kmod --target i686" (if you've a i686 kernel). It > used to work at some point, but I haven't checked lately. Oh, and you > may need to add streamzap to "drivers" at the top of the specfile before > rebuilding. I'll give that a shot, but since I can't build from the source tarball, I'm skeptical I'll be able to make your suggestion work :-( To complicate things, I don't have internet access at home. I've downloaded http://rpm.livna.org/fedora/3/i386/RPMS.testing/kernel-module-devel-2.6.11-1.27_FC3-0.8-0.lvn.1.3.i386.rpm, and http://download.fedora.redhat.com/pub/fedora/linux/extras/3/SRPMS/lirc-0.7.1-1.src.rpm and I'll try the command you mention above. Wish me luck! -Peter From j.w.r.degoede at hhs.nl Thu May 26 18:12:22 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 26 May 2005 20:12:22 +0200 Subject: Fedora Extras development Package Build Report In-Reply-To: <20050526130534.02FE380EE@extras64.linux.duke.edu> References: <20050526130534.02FE380EE@extras64.linux.duke.edu> Message-ID: <42961186.30003@hhs.nl> Hmm, Thats a long list, it looks like verything has been rebuild, but I miss a package of mine should I up the release and request a rebuild myself? Regards, Hans From bugs.michael at gmx.net Thu May 26 18:42:15 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 26 May 2005 20:42:15 +0200 Subject: Fedora Extras development Package Build Report In-Reply-To: <42961186.30003@hhs.nl> References: <20050526130534.02FE380EE@extras64.linux.duke.edu> <42961186.30003@hhs.nl> Message-ID: <20050526204215.4a960626.bugs.michael@gmx.net> On Thu, 26 May 2005 20:12:22 +0200, Hans de Goede wrote: > Hmm, > > Thats a long list, it looks like verything has been rebuild, but I miss > a package of mine should I up the release and request a rebuild myself? Sure. From bugs.michael at gmx.net Thu May 26 18:56:46 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 26 May 2005 20:56:46 +0200 Subject: GDAL, GDAL-GRASS and GEOS-related questions. In-Reply-To: References: Message-ID: <20050526205646.25c188bd.bugs.michael@gmx.net> On Wed, 25 May 2005 01:04:51 +0400, Peter Lemenkov wrote: > Hello, All! > > Let's return to the GIS-related stuff: the problem was (is?) that GDAL > needs GRASS to be built with most features enabled, and GRASS needs (in > its turn) GDAL. > > Where is the solution: > > * to build GDAL --with-grass=no, > * to build GRASS, > * to build gdal-grass-plugin after all > > They says, that folks from Debian-GIS-group already resolved this > circular dependency succesively with this technique. > > http://bugzilla.fedora.us/show_bug.cgi?id=1964#c46 Btw, I replied to comment 46 (2005-04-09) on the same day in private. > Maybe we can test this method in FE and close this bug? Yes. When it became known that the Debian people started to work on that plugin, it seemed reasonable to wait for the solution. The temporary work-around to build GDAL without GRASS support was not picked up. > What needs to be done? To create packages for GDAL, GRASS and the plugin. > Another one annoying thing is the status of GEOS, which needs maintainer > (the one and only trouble with GEOS, am I right?) - I need this package, > so could I (if no one will be) be maintainer? Yes. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1340_FC4 loadavg: 1.27 1.14 1.11 From bugs.michael at gmx.net Thu May 26 19:05:40 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 26 May 2005 21:05:40 +0200 Subject: Fedora Extras development Package Build Report In-Reply-To: <20050526204215.4a960626.bugs.michael@gmx.net> References: <20050526130534.02FE380EE@extras64.linux.duke.edu> <42961186.30003@hhs.nl> <20050526204215.4a960626.bugs.michael@gmx.net> Message-ID: <20050526210540.29abb69c.bugs.michael@gmx.net> On Thu, 26 May 2005 20:42:15 +0200, Michael Schwendt wrote: > On Thu, 26 May 2005 20:12:22 +0200, Hans de Goede wrote: > > > Hmm, > > > > Thats a long list, it looks like verything has been rebuild, but I miss > > a package of mine should I up the release and request a rebuild myself? > > Sure. Unless your package doesn't need a rebuild. Your message is not clear enough as what you mean with "I miss a package". -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1340_FC4 loadavg: 1.16 1.19 1.13 From ville.skytta at iki.fi Thu May 26 19:08:45 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 26 May 2005 22:08:45 +0300 Subject: LIRC with Streamzap In-Reply-To: <63a3625b0505261100655d0270@mail.gmail.com> References: <63a3625b05052608262f5a96fa@mail.gmail.com> <1117126747.22702.26.camel@bobcat.mine.nu> <63a3625b0505261100655d0270@mail.gmail.com> Message-ID: <1117134525.25731.6.camel@bobcat.mine.nu> On Thu, 2005-05-26 at 12:00 -0600, Peter Hutnick wrote: > Wish me luck! Actually, having looked at it; it'll take more than luck. The specfile was more outdated than I thought, and would probably have worked only on FC2 and earlier. I'll commit a revised package to the development repository tonight, adjusted for (re)building on FC4; it should make things somewhat easier, but only on FC4. There will probably still be breakage as I have no hardware to test the modules with, but hey, at least they compile and install... and from _there_ onwards I wish you luck :) If things don't work, let me know in https://bugzilla.redhat.com/ From kaboom at oobleck.net Thu May 26 19:08:18 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 26 May 2005 15:08:18 -0400 (EDT) Subject: rpms/gwenview/devel gwenview.spec,1.8,1.9 In-Reply-To: <200505261851.j4QIp1B6023970@cvs-int.fedora.redhat.com> References: <200505261851.j4QIp1B6023970@cvs-int.fedora.redhat.com> Message-ID: On Thu, 26 May 2005, Jeremy Katz wrote: > -[ -n "$QTDIR" ] || . %{_sysconfdir}/profile.d/qt.sh > -%configure --disable-rpath \ > +unset QTDIR && . %{_sysconfdir}/profile.d/qt.sh > +%configure --disable-rpath --disable-libsuffix \ This has me curious. Is there any advantage to doing the above (which I've noticed some of the other qt-linked apps also doing), versus just doing something like: %configure --with-qt-dir=%{_libdir}/qt-3.3 ? later, chris From bugs.michael at gmx.net Thu May 26 19:29:34 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 26 May 2005 21:29:34 +0200 Subject: rpms/gwenview/devel gwenview.spec,1.8,1.9 In-Reply-To: References: <200505261851.j4QIp1B6023970@cvs-int.fedora.redhat.com> Message-ID: <20050526212934.373f8405.bugs.michael@gmx.net> On Thu, 26 May 2005 15:08:18 -0400 (EDT), Chris Ricker wrote: > On Thu, 26 May 2005, Jeremy Katz wrote: > > > -[ -n "$QTDIR" ] || . %{_sysconfdir}/profile.d/qt.sh > > -%configure --disable-rpath \ > > +unset QTDIR && . %{_sysconfdir}/profile.d/qt.sh > > +%configure --disable-rpath --disable-libsuffix \ > > This has me curious. Is there any advantage to doing the above (which I've > noticed some of the other qt-linked apps also doing), versus just doing > something like: > > %configure --with-qt-dir=%{_libdir}/qt-3.3 > > ? Setting $QTDIR is a standard method for pointing many configure checks to Qt's location. Your solution works for some programs which understand a --with-qt-dir switch, but it hardcodes the Qt version, which creates a need to keep it in sync with the main Qt packages. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1340_FC4 loadavg: 1.28 1.34 1.27 From hutnick at gmail.com Thu May 26 20:04:52 2005 From: hutnick at gmail.com (Peter Hutnick) Date: Thu, 26 May 2005 14:04:52 -0600 Subject: LIRC with Streamzap In-Reply-To: <1117134525.25731.6.camel@bobcat.mine.nu> References: <63a3625b05052608262f5a96fa@mail.gmail.com> <1117126747.22702.26.camel@bobcat.mine.nu> <63a3625b0505261100655d0270@mail.gmail.com> <1117134525.25731.6.camel@bobcat.mine.nu> Message-ID: <63a3625b05052613042418e05b@mail.gmail.com> On 5/26/05, Ville Skytt? wrote: > On Thu, 2005-05-26 at 12:00 -0600, Peter Hutnick wrote: > I'll commit a revised package to the development repository tonight, > adjusted for (re)building on FC4; it should make things somewhat easier, > but only on FC4. There will probably still be breakage as I have no > hardware to test the modules with, but hey, at least they compile and > install... and from _there_ onwards I wish you luck :) If things don't > work, let me know in https://bugzilla.redhat.com/ Given that I don't have an FC4 system I expect it won't go well :-( -Peter From kaboom at oobleck.net Thu May 26 21:23:03 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 26 May 2005 17:23:03 -0400 (EDT) Subject: xboard added; needs ppc check In-Reply-To: References: Message-ID: Now that GNU chess is making its way through the build system, I've imported xboard based on the last version that was in Fedora Core development. In case anyone wants to double-check the cleanups I did, I'll wait a couple of days to request a build The xboard spec in Fedora Core CVS has: ExcludeArch: ppc64 ppc There's nothing in the %changelog or in Bugzilla about why it's there, and I don't have Linux on any of my PPC boxes to check if it builds there or not. I've left the ExcludeArch for now, but it'd be great if someone with PowerPC wants to check if it's justified.... later, chris From qspencer at ieee.org Thu May 26 21:31:25 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 26 May 2005 16:31:25 -0500 Subject: Build Failure Message-ID: <4296402D.7040808@ieee.org> GiNaC has been failing to build on the build system. The failure appears to happen during the configure stage when it's looking for cln. cln was recently built and released (version 1.1.9), and cln-devel is required for the build. However, the following error is encountered in configure: checking for cln-config... /usr/bin/cln-config checking for CLN - version >= 1.1.0... no *** Could not run CLN test program, checking why... *** The test program failed to compile or link. See the file config.log for the *** exact error that occured. This usually means CLN was incorrectly installed *** or that you have moved CLN since it was installed. In the latter case, you *** may want to edit the cln-config script: /usr/bin/cln-config. configure is correctly finding the presence of /usr/bin/cln-config, which is in cln-devel, but for some reason there's a failure. I can't duplicate this on my i386 system. Any ideas on why this might happen? Is there any way to get at the config.log file mentioned in the error message? -Quentin From skvidal at phy.duke.edu Thu May 26 21:41:04 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 26 May 2005 17:41:04 -0400 Subject: Build Failure In-Reply-To: <4296402D.7040808@ieee.org> References: <4296402D.7040808@ieee.org> Message-ID: <1117143664.6676.16.camel@cutter> On Thu, 2005-05-26 at 16:31 -0500, Quentin Spencer wrote: > GiNaC has been failing to build on the build system. The failure appears > to happen during the configure stage when it's looking for cln. cln was > recently built and released (version 1.1.9), and cln-devel is required > for the build. However, the following error is encountered in configure: > > checking for cln-config... /usr/bin/cln-config > checking for CLN - version >= 1.1.0... no > *** Could not run CLN test program, checking why... > *** The test program failed to compile or link. See the file config.log > for the > *** exact error that occured. This usually means CLN was incorrectly > installed > *** or that you have moved CLN since it was installed. In the latter > case, you > *** may want to edit the cln-config script: /usr/bin/cln-config. > > configure is correctly finding the presence of /usr/bin/cln-config, > which is in cln-devel, but for some reason there's a failure. I can't > duplicate this on my i386 system. Any ideas on why this might happen? Is > there any way to get at the config.log file mentioned in the error message? > is the build failure report coming from the i386 chroot? -sv From qspencer at ieee.org Thu May 26 21:45:44 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 26 May 2005 16:45:44 -0500 Subject: Build Failure In-Reply-To: <1117143664.6676.16.camel@cutter> References: <4296402D.7040808@ieee.org> <1117143664.6676.16.camel@cutter> Message-ID: <42964388.3090003@ieee.org> seth vidal wrote: >On Thu, 2005-05-26 at 16:31 -0500, Quentin Spencer wrote: > > >>GiNaC has been failing to build on the build system. The failure appears >>to happen during the configure stage when it's looking for cln. cln was >>recently built and released (version 1.1.9), and cln-devel is required >>for the build. However, the following error is encountered in configure: >> >>checking for cln-config... /usr/bin/cln-config >>checking for CLN - version >= 1.1.0... no >>*** Could not run CLN test program, checking why... >>*** The test program failed to compile or link. See the file config.log >>for the >>*** exact error that occured. This usually means CLN was incorrectly >>installed >>*** or that you have moved CLN since it was installed. In the latter >>case, you >>*** may want to edit the cln-config script: /usr/bin/cln-config. >> >>configure is correctly finding the presence of /usr/bin/cln-config, >>which is in cln-devel, but for some reason there's a failure. I can't >>duplicate this on my i386 system. Any ideas on why this might happen? Is >>there any way to get at the config.log file mentioned in the error message? >> >> >is the build failure report coming from the i386 chroot? > > Yes, it is. Actually, I'm getting the same error on i386 and x86_64, and on ppc I get "something went wrong rebuilding the .src.rpm". -Quentin From dwmw2 at infradead.org Thu May 26 22:00:35 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 26 May 2005 23:00:35 +0100 Subject: xboard added; needs ppc check In-Reply-To: References: Message-ID: <1117144835.2247.32.camel@baythorne.infradead.org> On Thu, 2005-05-26 at 17:23 -0400, Chris Ricker wrote: > There's nothing in the %changelog or in Bugzilla about why it's there, and > I don't have Linux on any of my PPC boxes to check if it builds there or > not. I've left the ExcludeArch for now, but it'd be great if someone with > PowerPC wants to check if it's justified.... It isn't; xboard appears to work fine as long as I build and install a vaguely recent gnuchess. I've re-enabled PPC and put in a build request for xboard; will check why current gnuchess isn't available via yum. Thanks for checking. -- dwmw2 From katzj at redhat.com Thu May 26 22:01:56 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 26 May 2005 18:01:56 -0400 Subject: xboard added; needs ppc check In-Reply-To: References: Message-ID: <1117144916.22921.55.camel@bree.local.net> On Thu, 2005-05-26 at 17:23 -0400, Chris Ricker wrote: > The xboard spec in Fedora Core CVS has: > > ExcludeArch: ppc64 ppc > > There's nothing in the %changelog or in Bugzilla about why it's there, and > I don't have Linux on any of my PPC boxes to check if it builds there or > not. I've left the ExcludeArch for now, but it'd be great if someone with > PowerPC wants to check if it's justified.... Since rpmbuild segfaults when building the package, it seems to be justified. I've got Paul taking a look at it (and I filed it as #158927) Jeremy From dwmw2 at infradead.org Thu May 26 22:12:52 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 26 May 2005 23:12:52 +0100 Subject: xboard added; needs ppc check In-Reply-To: <1117144916.22921.55.camel@bree.local.net> References: <1117144916.22921.55.camel@bree.local.net> Message-ID: <1117145572.2247.36.camel@baythorne.infradead.org> On Thu, 2005-05-26 at 18:01 -0400, Jeremy Katz wrote: > Since rpmbuild segfaults when building the package, it seems to be > justified. I've got Paul taking a look at it (and I filed it as > #158927) Hm. It built for me. > -- dwmw2 From kaboom at oobleck.net Thu May 26 22:15:12 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 26 May 2005 18:15:12 -0400 (EDT) Subject: xboard added; needs ppc check In-Reply-To: <1117144835.2247.32.camel@baythorne.infradead.org> References: <1117144835.2247.32.camel@baythorne.infradead.org> Message-ID: On Thu, 26 May 2005, David Woodhouse wrote: > It isn't; xboard appears to work fine as long as I build and install a > vaguely recent gnuchess. Great, thanks. > I've re-enabled PPC and put in a build request for xboard; will check > why current gnuchess isn't available via yum. It's not available because it hasn't built yet. I just put it into extras from core and the first build today failed because of minor GCC 4 issues. The second build attempt's requested but hasn't completed yet. I was waiting for that to succeed before building xboard.... later, chris From kaboom at oobleck.net Thu May 26 22:19:47 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 26 May 2005 18:19:47 -0400 (EDT) Subject: xboard added; needs ppc check In-Reply-To: <1117144916.22921.55.camel@bree.local.net> References: <1117144916.22921.55.camel@bree.local.net> Message-ID: On Thu, 26 May 2005, Jeremy Katz wrote: > On Thu, 2005-05-26 at 17:23 -0400, Chris Ricker wrote: > > not. I've left the ExcludeArch for now, but it'd be great if someone with > > PowerPC wants to check if it's justified.... > > Since rpmbuild segfaults when building the package, it seems to be > justified. I've got Paul taking a look at it (and I filed it as > #158927) Interesting. I guess we'll just leave it enabled and see if it builds on the buildfarm ppc box, since it builds on David's ppc.... later, chris From dwmw2 at infradead.org Thu May 26 22:23:06 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 26 May 2005 23:23:06 +0100 Subject: xboard added; needs ppc check In-Reply-To: References: <1117144916.22921.55.camel@bree.local.net> Message-ID: <1117146186.2247.37.camel@baythorne.infradead.org> On Thu, 2005-05-26 at 18:19 -0400, Chris Ricker wrote: > Interesting. I guess we'll just leave it enabled and see if it builds > on the buildfarm ppc box, since it builds on David's ppc.... Mail me a SSH public key if you want an account on that, btw. -- dwmw2 From bugs.michael at gmx.net Thu May 26 22:25:56 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 27 May 2005 00:25:56 +0200 Subject: Build Failure In-Reply-To: <4296402D.7040808@ieee.org> References: <4296402D.7040808@ieee.org> Message-ID: <20050527002556.2f2462f9.bugs.michael@gmx.net> On Thu, 26 May 2005 16:31:25 -0500, Quentin Spencer wrote: > GiNaC has been failing to build on the build system. The failure appears > to happen during the configure stage when it's looking for cln. cln was > recently built and released (version 1.1.9), and cln-devel is required > for the build. However, the following error is encountered in configure: > > checking for cln-config... /usr/bin/cln-config > checking for CLN - version >= 1.1.0... no > *** Could not run CLN test program, checking why... > *** The test program failed to compile or link. See the file config.log > for the > *** exact error that occured. This usually means CLN was incorrectly > installed > *** or that you have moved CLN since it was installed. In the latter > case, you > *** may want to edit the cln-config script: /usr/bin/cln-config. > > configure is correctly finding the presence of /usr/bin/cln-config, > which is in cln-devel, but for some reason there's a failure. I can't > duplicate this on my i386 system. Any ideas on why this might happen? Is > there any way to get at the config.log file mentioned in the error message? $ cln-config --libs -L/usr/lib -lcln -lgmp $ rpm -qR cln-devel /bin/sh /bin/sh /bin/sh cln = 1.1.9-2.fc4 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Looks like it's missing "Requires: gmp-devel" in cln-devel at least. From mpeters at mac.com Fri May 27 01:15:50 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 26 May 2005 18:15:50 -0700 Subject: Request for Review: libvisual-plugins In-Reply-To: References: <1114670959.11644.61.camel@fc4t2.mpeters.local> <1114684377.11644.80.camel@fc4t2.mpeters.local> <1114692761.24385.213.camel@mccallum.corsepiu.local> <1115498447.18558.31.camel@laptop.mpeters.local> Message-ID: <1117156551.19228.107.camel@laptop.mpeters.local> On Sat, 2005-05-07 at 23:03 +0200, Aurelien Bompard wrote: > Michael A. Peters wrote: > > Can it be co-sponsored now so it can be imported into CVS? > > Yep, you've got my approval. Please let me test it some more in mach before > requesting a build. > > Aur?lien Now that finals over - I can spend a little more time on this. It no longer builds on x86. It does build on ppc, which I had not tried to build it on before. The error in x86 is an asm error - I disabled the plugin it occurred and it happened in the next as well. I sent an e-mail to upstream, and see if they have any suggestions. I don't know if it is a new bug introduced by a dev tool update or not, I'm still investigating. From nhorman at redhat.com Fri May 27 01:20:40 2005 From: nhorman at redhat.com (Neil Horman) Date: Thu, 26 May 2005 21:20:40 -0400 Subject: New package: iozone In-Reply-To: <20050524131523.GB17607@hmsendeavour.rdu.redhat.com> References: <20050519202418.GH14451@hmsendeavour.rdu.redhat.com> <20050520084210.5cd153da.mfleming@enlartenment.com> <20050520185556.GK19229@hmsendeavour.rdu.redhat.com> <20050520222740.131f01f3.bugs.michael@gmx.net> <20050521131512.GB22489@hmsendeavour.rdu.redhat.com> <20050524131523.GB17607@hmsendeavour.rdu.redhat.com> Message-ID: <20050527012040.GB10698@hmsendeavour.rdu.redhat.com> Still looking for approval/sponsorship here, please. Thanks! Neil > Location: > http://people.redhat.com/nhorman/iozone.spec > http://people.redhat.com/nhorman/iozone-3-1.src.rpm > > md5sums: > deedd349c0c51da6563fd5c2c02d4718 iozone.spec > da64ba6cca5320675996983b7fb23463 iozone-3-1.src.rpm > > Looking for initial approval. > > Thanks and Regards > Neil > > -- > /*************************************************** > *Neil Horman > *Software Engineer > *Red Hat, Inc. > *nhorman at redhat.com > *gpg keyid: 1024D / 0x92A74FA1 > *http://pgp.mit.edu > ***************************************************/ > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman at redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ From buildsys at fedoraproject.org Fri May 27 02:39:10 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 26 May 2005 22:39:10 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050527023910.2CABE8040@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 7 bittorrent-4.0.2-1 bittorrent-4.0.2-1.fc3 gaim-meanwhile-1.2.2-2 gaim-meanwhile-1.2.2-2.fc3 mlmmj-1.2.7-4 mlmmj-1.2.7-4.fc3 rpmlint-0.69-1.1 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 Fri May 27 02:43:54 2005 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Thu, 26 May 2005 20:43:54 -0600 Subject: Request for Review: exo and Terminal Message-ID: <20050527024355.DBF35381116@ningauble.scrye.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings. I have two new packages for review. libexo is a extension library for Xfce and Terminal is an application that uses it. Terminal has a very similar feature set to gnome-terminal and konsole, but without the overhead of those systems. libexo - Extension library for Xfce, targeted at application development. Terminal - This is the Terminal emulator application. Terminal is a lightweight and easy to use terminal emulator for the X windowing system, with some new ideas and features that make it unique among X terminal emulators. src.rpm's at: http://www.scrye.com/~kevin/fedora-extras/exo-0.3.0-1.src.rpm http://www.scrye.com/~kevin/fedora-extras/Terminal-0.2.4-1.src.rpm Comments and approvals welcome. :) kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 iD8DBQFClolr3imCezTjY0ERAgDDAJ9oeIF8J1TypU7KhpxgoOICZtZq6ACfTG0t RuWa+mqGdgvoBF11P/k1X4o= =hSAj -----END PGP SIGNATURE----- From buildsys at fedoraproject.org Fri May 27 02:51:44 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 26 May 2005 22:51:44 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050527025144.154248040@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 20 Maelstrom-3.0.6-8 SDL_net-1.2.5-4 advancecomp-1.14-4 dietlibc-0.29-2 dietlibc-0.29-2.fc4 factory-2.0.5-6 gnuchess-5.07-7 lablgl-1.01-6 lablgtk-2.4.0-5 lirc-0.7.1-3 metakit-2.4.9.3-8 mlmmj-1.2.7-4 mlmmj-1.2.7-4.fc4 netdiag-2.4-7 plib16-1.6.0-3 rpmlint-0.69-3 seahorse-0.7.7-3 skencil-0.6.16-6 torcs-1.2.3-4 wesnoth-0.8-5 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 Fri May 27 03:11:17 2005 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Thu, 26 May 2005 21:11:17 -0600 Subject: Review requested: fwrestart Message-ID: <20050527031120.5D533381116@ningauble.scrye.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here's another (very small) package I would like to submit for review. It's fwrestart: This program can automatically detect when changes to the firewall block the administrative shell session, and to take corrective action fwrestart uses terminal auto-response codes to safely re-start firewall rules over a remote shell session. It sends a request to your terminal (xterm, for example), which responds back automatically. When that response is received, ensuring that fwrestart can communicate with the terminal, fwrestart then issues a command to restart the firewall. It then tries another request to the terminal, and if that is not received within 5 seconds, a command is run to clear the firewall and an appropriate error is generated. src.rpm available at: http://www.scrye.com/~kevin/fedora-extras/fwrestart-1.01-2.src.rpm Comments welcome. kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 iD8DBQFClo/Y3imCezTjY0ERAnI0AJoCjbEhSveTBCOduDIpmjZQ1SqZvwCfbcd7 DtE0k1NnVt+pGXiipl66IJ0= =c6p/ -----END PGP SIGNATURE----- From ivazquez at ivazquez.net Fri May 27 04:12:41 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 27 May 2005 00:12:41 -0400 Subject: New package: jakarta-commons-cli Message-ID: <1117167161.30966.52.camel@ignacio.ignacio.lan> jakarta-commons-cli: A simple API for working with the command line The CLI library provides a simple and easy to use API for working with the command line arguments and options. http://fedora.ivazquez.net/files/jakarta-commons-cli-1.0-1.src.rpm -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.kurtz at hardsun.net Fri May 27 04:16:01 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Thu, 26 May 2005 21:16:01 -0700 Subject: New package review: nautilus-share Message-ID: <1117167361.4334.18.camel@rydia.hardsun.net> Hi, Just finished packaging up nautilus-share for Fedora, and was wondering if anyone could review it. Upstream URL is http://gentoo.ovibes.net/nautilus-share/ and spec file is found at http://hardsun.net/fedora/nautilus-share.spec . The (currently) add-on init file is also there, so "spectool -A -g". Basically, it's a Nautilus extension that allows users to easily share folders over Samba, somewhat like a certain other OS some have heard of. No root is required once it's setup. FC4test only, due to a Nautilus 2.10 requirement. Anyone who wants to test the actual program, make sure to start smb, smbshared and restart "nautilus -q". -- Aaron Kurtz Message-ID: >From: Peter Lemenkov >Reply-To: Discussion related to Fedora Extras > >To: fedora-extras-list at redhat.com >Subject: Re: Volunteering to maintain proj and shapelib packages >Date: Wed, 25 May 2005 08:56:17 +0400 > >Shawn McCann ??????????: > >>I'm looking to get involved in the Fedora project and was drawn to the >>list of packages needing a maintainer. As I've used proj and shapelib >>before, volunteering to maintain them seems a good place to start. > >It would be great! >We got another GIS-related package w/o maintainer - GEOS, which blocks >inclusion of QuantumGIS to FE. > Yes, GEOS is currently maintained by another local company. I can likely take this on as well once I get up to speed on proj and shapelib. From what I can see FC3 has proj-4.4.8 and proj-4.4.9 is now available. For shapelib, FC3 has the latest version already. >>The company I work for builds systems around the world in various domains, >>especially for remote sensing from satellites. I've recently been working >>with on projects to deploy Linux (RHEL) and GIS systems in developing >>countries, hence my renewed interest in the discussions on adding GRASS to >>Fedora Extras. > >GRASS needs another problem to be solved - GDAL and GDAL-GRASS plugin. > I setup mapserver and grass last year and ran across some of these issues. Should be solvable with a little effort. >FYI we also got AutoTrace, a good free, opensource vectorizer, w/o >maintainer. Haven't used it yet, but it sounds interesting. > >-- >fedora-extras-list mailing list >fedora-extras-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-extras-list From ville.skytta at iki.fi Fri May 27 05:49:25 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 27 May 2005 08:49:25 +0300 Subject: New package: jakarta-commons-cli In-Reply-To: <1117167161.30966.52.camel@ignacio.ignacio.lan> References: <1117167161.30966.52.camel@ignacio.ignacio.lan> Message-ID: <1117172965.25731.18.camel@bobcat.mine.nu> On Fri, 2005-05-27 at 00:12 -0400, Ignacio Vazquez-Abrams wrote: > jakarta-commons-cli: A simple API for working with the command line > > The CLI library provides a simple and easy to use API for working with > the command line arguments and options. > > http://fedora.ivazquez.net/files/jakarta-commons-cli-1.0-1.src.rpm Unlike almost all of the stuff in Core, that doesn't play well with the same package from JPackage. In particular, javadocs are bundled with the main package which is unusual and bloat IMO, and will cause conflicts with the JPackage version. There seem to be some missing install time deps too, like jakarta-commons-lang and jakarta-commons- logging based on peeking into the JPackage specfile. I'd suggest grabbing the JPackage SRPM and just slapping a _Xfc to the release tag instead of rewriting from scratch. The java-javadoc build dep (in the JPackage version) will have to be removed from the FE version, I think. http://www.jpackage.org/rpm.php?id=1013 From ivazquez at ivazquez.net Fri May 27 05:56:39 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 27 May 2005 01:56:39 -0400 Subject: New package: libmatchbox-1.7 In-Reply-To: <1116781983.3422.26.camel@ihaa.home.willberg.fi> References: <1116781983.3422.26.camel@ihaa.home.willberg.fi> Message-ID: <1117173399.30966.55.camel@ignacio.ignacio.lan> On Sun, 2005-05-22 at 20:13 +0300, Toni Willberg wrote: > http://toniw.iki.fi/temp/libmatchbox.spec - Drop 0 Epoch - Source0 should have full URL - Drop .la file from -devel - Use %{_includedir}/libmb instead of doing dir and headers separately -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazquez at ivazquez.net Fri May 27 05:59:12 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 27 May 2005 01:59:12 -0400 Subject: New package: matchbox-window-manager-0.9.4-1 In-Reply-To: <1116789503.3422.34.camel@ihaa.home.willberg.fi> References: <1116781983.3422.26.camel@ihaa.home.willberg.fi> <1116789503.3422.34.camel@ihaa.home.willberg.fi> Message-ID: <1117173552.30966.58.camel@ignacio.ignacio.lan> On Sun, 2005-05-22 at 22:18 +0300, Toni Willberg wrote: > http://toniw.iki.fi/temp/matchbox-window-manager.spec - Drop explicit Requires - Line-break %description at column 79 - %{_datadir}/matchbox -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazquez at ivazquez.net Fri May 27 06:00:34 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 27 May 2005 02:00:34 -0400 Subject: New package: matchbox-panel-0.9.2-1 In-Reply-To: <1116866215.3346.5.camel@ihaa.home.willberg.fi> References: <1116781983.3422.26.camel@ihaa.home.willberg.fi> <1116866215.3346.5.camel@ihaa.home.willberg.fi> Message-ID: <1117173634.30966.60.camel@ignacio.ignacio.lan> On Mon, 2005-05-23 at 19:36 +0300, Toni Willberg wrote: > http://toniw.iki.fi/temp/matchbox-panel.spec - Source0 needs complete URL - Drop explicit Requires -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazquez at ivazquez.net Fri May 27 06:14:26 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 27 May 2005 02:14:26 -0400 Subject: New package: iozone In-Reply-To: <20050527012040.GB10698@hmsendeavour.rdu.redhat.com> References: <20050519202418.GH14451@hmsendeavour.rdu.redhat.com> <20050520084210.5cd153da.mfleming@enlartenment.com> <20050520185556.GK19229@hmsendeavour.rdu.redhat.com> <20050520222740.131f01f3.bugs.michael@gmx.net> <20050521131512.GB22489@hmsendeavour.rdu.redhat.com> <20050524131523.GB17607@hmsendeavour.rdu.redhat.com> <20050527012040.GB10698@hmsendeavour.rdu.redhat.com> Message-ID: <1117174466.30966.67.camel@ignacio.ignacio.lan> On Thu, 2005-05-26 at 21:20 -0400, Neil Horman wrote: > http://people.redhat.com/nhorman/iozone-3-1.src.rpm + URL and Source are good + Builds as non-root + Permissions and ownership are good - Missed %{_datadir} in %install and %files - Use %doc instead of %{_docdir} ? Don't need those comment blocks before each section -- 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 dwmw2 at infradead.org Fri May 27 07:50:12 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 27 May 2005 08:50:12 +0100 Subject: xboard added; needs ppc check In-Reply-To: References: Message-ID: <1117180212.21715.5.camel@baythorne.infradead.org> On Thu, 2005-05-26 at 17:23 -0400, Chris Ricker wrote: > There's nothing in the %changelog or in Bugzilla about why it's there, and > I don't have Linux on any of my PPC boxes to check if it builds there or > not. I've left the ExcludeArch for now, but it'd be great if someone with > PowerPC wants to check if it's justified.... Thanks for providing an excellent example of why arch exclusions should always be accompanied by a bugzilla number, btw. -- dwmw2 From bugs.michael at gmx.net Fri May 27 09:34:42 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 27 May 2005 11:34:42 +0200 Subject: New package: iozone In-Reply-To: <20050527012040.GB10698@hmsendeavour.rdu.redhat.com> References: <20050519202418.GH14451@hmsendeavour.rdu.redhat.com> <20050520084210.5cd153da.mfleming@enlartenment.com> <20050520185556.GK19229@hmsendeavour.rdu.redhat.com> <20050520222740.131f01f3.bugs.michael@gmx.net> <20050521131512.GB22489@hmsendeavour.rdu.redhat.com> <20050524131523.GB17607@hmsendeavour.rdu.redhat.com> <20050527012040.GB10698@hmsendeavour.rdu.redhat.com> Message-ID: <20050527113442.3ada5ed3.bugs.michael@gmx.net> On Thu, 26 May 2005 21:20:40 -0400, Neil Horman wrote: > Still looking for approval/sponsorship here, please. Yeah, feel free to import the package into CVS for the remaining fixes: - make it use $(RPM_OPT_FLAGS) inside the Makefile - files *.doc, *.pdf and manual page are executable now Please fix these, then I will approve. From bugs.michael at gmx.net Fri May 27 09:39:59 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 27 May 2005 11:39:59 +0200 Subject: New package: SIMVoleon In-Reply-To: <1116646435.27282.6.camel@mccallum.corsepiu.local> References: <1116646435.27282.6.camel@mccallum.corsepiu.local> Message-ID: <20050527113959.6d2b97f9.bugs.michael@gmx.net> On Sat, 21 May 2005 05:33:55 +0200, Ralf Corsepius wrote: > Package: SIMVoleon > > Homepage: http://www.coin3d.org > > > Description: > SIM Voleon is a software development system, in the form of an add-on library to > Coin3D. SIM Voleon complements Coin's capabilities for polygon-based rendering > with visualization of volumetric data sets, by providing so-called "volume > rendering" technology (http://dev.sim.no/SIM_Voleon) > > It is an add-on package to Coin2, which already is in FE. > > Location: > ftp://packman.iu-bremen.de/fedora/SRPMS/SIMVoleon.spec > ftp://packman.iu-bremen.de/fedora/SRPMS/SIMVoleon-2.0.1-1.fc3.src.rpm > > A predecessor of this package had passed fedora.us's QA > (http://bugzilla.fedora.us/show_bug.cgi?id=1926), but I had withdrawn it. Approved. Packaging looks good. One nitpick only: * Directory %_datadir/Coin/conf/ is already owned by Coin2-devel --- SIMVoleon.spec~ 2005-05-21 05:10:29.000000000 +0200 +++ SIMVoleon.spec 2005-05-27 11:39:10.000000000 +0200 @@ -90,7 +90,7 @@ %{_libdir}/libSimVoleon.*a %{_libdir}/libSimVoleon*.so %{_datadir}/aclocal/simvoleon.m4 -%{_datadir}/Coin/conf +%{_datadir}/Coin/conf/* %doc %{coin_htmldir}/* %changelog From qspencer at ieee.org Fri May 27 10:00:07 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Fri, 27 May 2005 05:00:07 -0500 Subject: Build Failure In-Reply-To: <20050527002556.2f2462f9.bugs.michael@gmx.net> References: <4296402D.7040808@ieee.org> <20050527002556.2f2462f9.bugs.michael@gmx.net> Message-ID: <4296EFA7.8020302@ieee.org> Michael Schwendt wrote: >On Thu, 26 May 2005 16:31:25 -0500, Quentin Spencer wrote: > > > >>GiNaC has been failing to build on the build system. The failure appears >>to happen during the configure stage when it's looking for cln. cln was >>recently built and released (version 1.1.9), and cln-devel is required >>for the build. However, the following error is encountered in configure: >> >>checking for cln-config... /usr/bin/cln-config >>checking for CLN - version >= 1.1.0... no >>*** Could not run CLN test program, checking why... >>*** The test program failed to compile or link. See the file config.log >>for the >>*** exact error that occured. This usually means CLN was incorrectly >>installed >>*** or that you have moved CLN since it was installed. In the latter >>case, you >>*** may want to edit the cln-config script: /usr/bin/cln-config. >> >>configure is correctly finding the presence of /usr/bin/cln-config, >>which is in cln-devel, but for some reason there's a failure. I can't >>duplicate this on my i386 system. Any ideas on why this might happen? Is >>there any way to get at the config.log file mentioned in the error message? >> >> > >$ cln-config --libs >-L/usr/lib -lcln -lgmp > >$ rpm -qR cln-devel >/bin/sh >/bin/sh >/bin/sh >cln = 1.1.9-2.fc4 >rpmlib(CompressedFileNames) <= 3.0.4-1 >rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > >Looks like it's missing "Requires: gmp-devel" in cln-devel at least. > > You were right. The configure script doesn't explicitly check for gmp-devel anywhere, but the CLN check fails if it's not present. Thanks for the insight. -Quentin From ed at eh3.com Fri May 27 10:06:48 2005 From: ed at eh3.com (Ed Hill) Date: Fri, 27 May 2005 06:06:48 -0400 Subject: Request for Review: exo and Terminal In-Reply-To: <20050527024355.DBF35381116@ningauble.scrye.com> References: <20050527024355.DBF35381116@ningauble.scrye.com> Message-ID: <1117188408.5620.216.camel@ernie> On Thu, 2005-05-26 at 20:43 -0600, Kevin Fenzi wrote: > http://www.scrye.com/~kevin/fedora-extras/exo-0.3.0-1.src.rpm Good: * source matches upstream * builds, installs, & works-for-me w/ FC3 Bad: * no signature Non-blocker nits: * Can the *.la files be removed? * redundant "/" in %{_datadir}//pygtk/2.0/defs/exo-0.3/exo.defs > http://www.scrye.com/~kevin/fedora-extras/Terminal-0.2.4-1.src.rpm Good: * source matches upstream * builds, installs, & works-for-me w/ FC3 Bad: * no signature E: Terminal zero-length /usr/share/doc/Terminal-0.2.4/TODO Not sure: W: Terminal non-standard-group Applications/X11 W: Terminal non-standard-dir-in-usr libexec I looked all over the Wiki for instructions concerning the package group names and didn't find them. I thought that there was an official list of package group names but perhaps I'm just insufficiently caffeinated to find it this morning... Can someone please point it out? Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From bugs.michael at gmx.net Fri May 27 10:50:14 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 27 May 2005 12:50:14 +0200 Subject: Build Failure In-Reply-To: <4296EFA7.8020302@ieee.org> References: <4296402D.7040808@ieee.org> <20050527002556.2f2462f9.bugs.michael@gmx.net> <4296EFA7.8020302@ieee.org> Message-ID: <20050527125014.02dc1304.bugs.michael@gmx.net> On Fri, 27 May 2005 05:00:07 -0500, Quentin Spencer wrote: > >>configure is correctly finding the presence of /usr/bin/cln-config, > >>which is in cln-devel, but for some reason there's a failure. I can't > >>duplicate this on my i386 system. Any ideas on why this might happen? Is > >>there any way to get at the config.log file mentioned in the error message? > >> > >> > > > >$ cln-config --libs > >-L/usr/lib -lcln -lgmp > > > >$ rpm -qR cln-devel > >/bin/sh > >/bin/sh > >/bin/sh > >cln = 1.1.9-2.fc4 > >rpmlib(CompressedFileNames) <= 3.0.4-1 > >rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > > > >Looks like it's missing "Requires: gmp-devel" in cln-devel at least. > > > > > You were right. The configure script doesn't explicitly check for > gmp-devel anywhere, but the CLN check fails if it's not present. Thanks > for the insight. Your fix ought to be different. As pointed out above, package "cln-devel" needs "Requires: gmp-devel". Adding "Buildrequires: gmp-devel" to GiNaC.spec is only a work-around. It doesn't fix cln-devel. From qspencer at ieee.org Fri May 27 11:32:22 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Fri, 27 May 2005 06:32:22 -0500 Subject: Build Failure In-Reply-To: <20050527125014.02dc1304.bugs.michael@gmx.net> References: <4296402D.7040808@ieee.org> <20050527002556.2f2462f9.bugs.michael@gmx.net> <4296EFA7.8020302@ieee.org> <20050527125014.02dc1304.bugs.michael@gmx.net> Message-ID: <42970546.8080608@ieee.org> Michael Schwendt wrote: >On Fri, 27 May 2005 05:00:07 -0500, Quentin Spencer wrote: > > > >>>>configure is correctly finding the presence of /usr/bin/cln-config, >>>>which is in cln-devel, but for some reason there's a failure. I can't >>>>duplicate this on my i386 system. Any ideas on why this might happen? Is >>>>there any way to get at the config.log file mentioned in the error message? >>>> >>>> >>>> >>>> >>>$ cln-config --libs >>>-L/usr/lib -lcln -lgmp >>> >>>$ rpm -qR cln-devel >>>/bin/sh >>>/bin/sh >>>/bin/sh >>>cln = 1.1.9-2.fc4 >>>rpmlib(CompressedFileNames) <= 3.0.4-1 >>>rpmlib(PayloadFilesHavePrefix) <= 4.0-1 >>> >>>Looks like it's missing "Requires: gmp-devel" in cln-devel at least. >>> >>> >>> >>> >>You were right. The configure script doesn't explicitly check for >>gmp-devel anywhere, but the CLN check fails if it's not present. Thanks >>for the insight. >> >> > >Your fix ought to be different. As pointed out above, package "cln-devel" >needs "Requires: gmp-devel". Adding "Buildrequires: gmp-devel" to >GiNaC.spec is only a work-around. It doesn't fix cln-devel. > > > I see now. I've fixed this and requested a rebuild. Thanks. -Quentin From tcallawa at redhat.com Fri May 27 12:33:56 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 27 May 2005 07:33:56 -0500 Subject: Request for Review: exo and Terminal In-Reply-To: <1117188408.5620.216.camel@ernie> References: <20050527024355.DBF35381116@ningauble.scrye.com> <1117188408.5620.216.camel@ernie> Message-ID: <1117197236.3555.17.camel@localhost.localdomain> On Fri, 2005-05-27 at 06:06 -0400, Ed Hill wrote: > I looked all over the Wiki for instructions concerning the package group > names and didn't find them. I thought that there was an official list > of package group names but perhaps I'm just insufficiently caffeinated > to find it this morning... Can someone please point it out? http://fedoraproject.org/wiki/RPMGroups However, thats not a requirement, really. There are lots of packages that don't fit very well into those groups. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From mattdm at mattdm.org Fri May 27 12:36:39 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 27 May 2005 08:36:39 -0400 Subject: Request for Review: exo and Terminal In-Reply-To: <1117197236.3555.17.camel@localhost.localdomain> References: <20050527024355.DBF35381116@ningauble.scrye.com> <1117188408.5620.216.camel@ernie> <1117197236.3555.17.camel@localhost.localdomain> Message-ID: <20050527123639.GA4282@jadzia.bu.edu> On Fri, May 27, 2005 at 07:33:56AM -0500, Tom 'spot' Callaway wrote: > > I looked all over the Wiki for instructions concerning the package group > > names and didn't find them. I thought that there was an official list > > of package group names but perhaps I'm just insufficiently caffeinated > > to find it this morning... Can someone please point it out? > http://fedoraproject.org/wiki/RPMGroups > However, thats not a requirement, really. There are lots of packages > that don't fit very well into those groups. Oooh, but *please* keep using them until we have a better list. If it's not a requirement, at least consider it a very strong recommendation. I know the current list isn't very good, but applications which use it become really ugly if everyone is making up arbitrary groups. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 73 degrees Fahrenheit. From kaboom at oobleck.net Fri May 27 12:37:48 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Fri, 27 May 2005 08:37:48 -0400 (EDT) Subject: Request for Review: exo and Terminal In-Reply-To: <1117188408.5620.216.camel@ernie> References: <20050527024355.DBF35381116@ningauble.scrye.com> <1117188408.5620.216.camel@ernie> Message-ID: On Fri, 27 May 2005, Ed Hill wrote: > I looked all over the Wiki for instructions concerning the package group > names and didn't find them. I thought that there was an official list > of package group names but perhaps I'm just insufficiently caffeinated > to find it this morning... Can someone please point it out? /usr/share/doc/rpm-%{version}/GROUPS User Interface/X is what xterm uses, fwiw. For most apps none really fit, though, so just pick the least-sucky one ;-) later, chris From qspencer at ieee.org Fri May 27 16:17:06 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Fri, 27 May 2005 11:17:06 -0500 Subject: Errors found by rpmlint Message-ID: <42974802.6070506@ieee.org> I'm preparing octave-forge for final review, and I would like some input on the errors that rpmlint is finding: 1. wrong-script-end-of-line-encoding There are more than 10 of these errors. They are caused by scripts that were created for octave by Windows users. Octave will still read and run the scripts just fine. Most users will never actually see the files. They could be fixed using something like dos2unix, but this seems like a tradeoff between cluttering the spec file vs. cluttering the output of rpmlint--so which is worse? I have cvs access to upstream and can fix these there, but I don't know soon a new release is planned. 2. devel-file-in-non-devel-package This error is created by two header files that are included for the benefit of users trying to port C code written to interface with Matlab to work with octave. Is it worth creating a devel package for this? I believe the Debian package keeps these in octave-forge. 3. non-standard-dir-in-usr libexec Several pre-compiled functions are placed in octave's path for these files, which is in /usr/libexec. This is non-standard? There sure is a lot of stuff from other packages in /usr/libexec . . . . I also find it odd that rpmlint thinks this is non-standard given there exists a %{_libexecdir} RPM macro. I appreciate any input on these. -Quentin From nhorman at redhat.com Fri May 27 17:09:24 2005 From: nhorman at redhat.com (Neil Horman) Date: Fri, 27 May 2005 13:09:24 -0400 Subject: New package: iozone In-Reply-To: <20050527113442.3ada5ed3.bugs.michael@gmx.net> References: <20050519202418.GH14451@hmsendeavour.rdu.redhat.com> <20050520084210.5cd153da.mfleming@enlartenment.com> <20050520185556.GK19229@hmsendeavour.rdu.redhat.com> <20050520222740.131f01f3.bugs.michael@gmx.net> <20050521131512.GB22489@hmsendeavour.rdu.redhat.com> <20050524131523.GB17607@hmsendeavour.rdu.redhat.com> <20050527012040.GB10698@hmsendeavour.rdu.redhat.com> <20050527113442.3ada5ed3.bugs.michael@gmx.net> Message-ID: <20050527170924.GC12957@hmsendeavour.rdu.redhat.com> On Fri, May 27, 2005 at 11:34:42AM +0200, Michael Schwendt wrote: > On Thu, 26 May 2005 21:20:40 -0400, Neil Horman wrote: > > > Still looking for approval/sponsorship here, please. > > Yeah, feel free to import the package into CVS for the remaining fixes: > > - make it use $(RPM_OPT_FLAGS) inside the Makefile > - files *.doc, *.pdf and manual page are executable now > > Please fix these, then I will approve. > Fixes applied, and its been imported into the Extras CVS tree. Thanks and Regards Neil -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman at redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ From ville.skytta at iki.fi Fri May 27 19:09:47 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 27 May 2005 22:09:47 +0300 Subject: Errors found by rpmlint In-Reply-To: <42974802.6070506@ieee.org> References: <42974802.6070506@ieee.org> Message-ID: <1117220987.25731.63.camel@bobcat.mine.nu> On Fri, 2005-05-27 at 11:17 -0500, Quentin Spencer wrote: > 1. wrong-script-end-of-line-encoding > There are more than 10 of these errors. They are caused by scripts that > were created for octave by Windows users. Octave will still read and run > the scripts just fine. If they work properly and are not meant to be modified after installed, and you're not annoyed by the "wrong" line endings, just ignore rpmlint on this. If present, the shebang line in scripts needs to end in a Unix linefeed to work properly though. > 2. devel-file-in-non-devel-package > This error is created by two header files that are included for the > benefit of users trying to port C code written to interface with Matlab > to work with octave. Is it worth creating a devel package for this? I > believe the Debian package keeps these in octave-forge. If it's only two header files, not worth the split. Perhaps just ignore rpmlint here too, but maybe also provide -devel in the package containing the headers in order to prepare for a future split if more -devel like files appear? > 3. non-standard-dir-in-usr libexec > Several pre-compiled functions are placed in octave's path for these > files, which is in /usr/libexec. This is non-standard? Non-standard as in "not defined in FHS", yes. > There sure is a > lot of stuff from other packages in /usr/libexec . . . . I also find it > odd that rpmlint thinks this is non-standard given there exists a > %{_libexecdir} RPM macro. This macro exists because all "configure" scripts created by autoconf have a --libexecdir option. It's not the macro rpmlint is complaining about, and the existence of a macro does not make any difference wrt. the stadards compliance of the thing it's defined to anyway. But like you noted, a lot of packages do install stuff into /usr/libexec, and the purpose of that dir is at least somewhat well understood (although many claim that it doesn't really have a purpose), so it's certainly not the end of the world if your package uses it too. Personally, I use %{_libdir}/$package (and sometimes a "bin" subdir below that if there's other stuff in %{_libdir}/$package) instead of /usr/libexec because of the latter not being a standard one as defined by FHS. There was a thread containing more opinions on fedora-devel a couple of weeks ago, start of thread here: https://www.redhat.com/archives/fedora-devel-list/2005-May/msg00240.html From a.kurtz at hardsun.net Fri May 27 19:29:19 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Fri, 27 May 2005 12:29:19 -0700 Subject: New package review: nautilus-share In-Reply-To: <1117167361.4334.18.camel@rydia.hardsun.net> References: <1117167361.4334.18.camel@rydia.hardsun.net> Message-ID: <1117222159.4334.29.camel@rydia.hardsun.net> On Thu, 2005-05-26 at 21:16 -0700, Aaron Kurtz wrote: > Hi, > Just finished packaging up nautilus-share for Fedora, and was wondering > if anyone could review it. Upstream URL is > http://gentoo.ovibes.net/nautilus-share/ and spec file is found at > http://hardsun.net/fedora/nautilus-share.spec . The (currently) add-on > init file is also there, so "spectool -A -g". > > Basically, it's a Nautilus extension that allows users to easily share > folders over Samba, somewhat like a certain other OS some have heard of. > No root is required once it's setup. FC4test only, due to a Nautilus > 2.10 requirement. Anyone who wants to test the actual program, make sure > to start smb, smbshared and restart "nautilus -q". Updated .spec for the new 0.6 release, also updated missing dependencies, so if you're the person in Singapore who downloaded that first version, please try again. -- Aaron Kurtz References: <429528CA.3050506@di.uminho.pt> Message-ID: <42977BCA.6030601@di.uminho.pt> CVS devel branch updated to syslog-ng 1.6.8 -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From qspencer at ieee.org Fri May 27 20:22:07 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Fri, 27 May 2005 15:22:07 -0500 Subject: Request for review: octave-forge Message-ID: <4297816F.40804@ieee.org> The following package is in CVS and is ready for final review and approval: octave-forge: Contributed functions for octave Summary: Octave-forge is a community project for collaborative development of octave extensions. The extensions in this package include additional data types such as sparse matrices, and functions for a variety of different applications including signal and image processing, communications, control, optimization, statistics, geometry, and symbolic math. To build this package, you will need octave, which is not yet released because of problems with the build system on x86_84. You will also need cln and GiNaC, which are awaiting release. Binaries for i386 for all of these can be found at: http://extras64.linux.duke.edu/failed/development/octave/2.1.71-2/i386/ http://extras64.linux.duke.edu/needsign/development/cln/1.1.9-3/i386/ http://extras64.linux.duke.edu/needsign/development/GiNaC/1.3.1-5/i386/ Note that the octave-forge RPM will produce a list of rpmlint errors, which I believe can all be safely ignored (see "Errors found by rpmlint" thread from earlier today). -Quentin From pawsa at theochem.kth.se Fri May 27 20:56:02 2005 From: pawsa at theochem.kth.se (Pawel Salek) Date: Fri, 27 May 2005 20:56:02 +0000 Subject: Review request: balsa (email client) Message-ID: <1117227367l.20746l.0l@salek.zapto.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Summary: Balsa E-mail Client Description: Balsa is an e-mail reader. This client is part of the GNOME desktop environment. It supports local mailboxes, POP3 and IMAP. Specfile changelog: * Fri May 20 2005 Pawel Salek - 2.3.2-1 - - bump version to 2.3.2 - - adapt to Fedora Extras template. Pawel - -- http://balsa.gnome.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCl4lnuYCgNzJxhxgRAjg5AKCZZpdj1HdJ2WfxY6/JJy8FJynmLQCfTwPr rCoGOAgYPaxJaUcQnFa3JZs= =uM/p -----END PGP SIGNATURE----- From kevin-fedora-extras at scrye.com Sat May 28 02:41:51 2005 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Fri, 27 May 2005 20:41:51 -0600 Subject: Request for Review: exo and Terminal References: <20050527024355.DBF35381116@ningauble.scrye.com> <1117188408.5620.216.camel@ernie> Message-ID: <20050528024155.1C85345429F@ningauble.scrye.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Ed" == Ed Hill writes: Ed> On Thu, 2005-05-26 at 20:43 -0600, Kevin Fenzi wrote: >> http://www.scrye.com/~kevin/fedora-extras/exo-0.3.0-1.src.rpm Ed> Good: * source matches upstream * builds, installs, & works-for-me Ed> w/ FC3 Ed> Bad: * no signature Ed> Non-blocker nits: * Can the *.la files be removed? Fixed. Removed them. Ed> * redundant "/" in %{_datadir}//pygtk/2.0/defs/exo-0.3/exo.defs Done. Removed. new src.rpm up at: http://www.scrye.com/~kevin/fedora-extras/exo-0.3.0-1.src.rpm >> http://www.scrye.com/~kevin/fedora-extras/Terminal-0.2.4-1.src.rpm Ed> Good: * source matches upstream * builds, installs, & works-for-me Ed> w/ FC3 Ed> Bad: * no signature E: Terminal zero-length Ed> /usr/share/doc/Terminal-0.2.4/TODO Removed it from the spec. Ed> Not sure: W: Terminal non-standard-group Applications/X11 W: Ed> Terminal non-standard-dir-in-usr libexec Ed> I looked all over the Wiki for instructions concerning the package Ed> group names and didn't find them. I thought that there was an Ed> official list of package group names but perhaps I'm just Ed> insufficiently caffeinated to find it this morning... Can someone Ed> please point it out? After reading the other responses in the thread I guess: User Interface/X Is the least sucky choice. :) I have changed it to that... new src.rpm at: http://www.scrye.com/~kevin/fedora-extras/Terminal-0.2.4-1.src.rpm Ed> Ed kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 iD8DBQFCl9py3imCezTjY0ERAlbhAJ4nWqOos49OaopR9xXkSszb30aaKwCgip0z JN91/Z/vkMCSXtkk5ogLSCU= =t24g -----END PGP SIGNATURE----- From byte at aeon.com.my Sat May 28 03:17:21 2005 From: byte at aeon.com.my (Colin Charles) Date: Sat, 28 May 2005 13:17:21 +1000 Subject: New package: MagicPoint Message-ID: <1117250241.3559.12.camel@arena.soho.bytebot.net> Hi, I'd like to maintain MagicPoint in Fedora Extras. Any objection with just importing it from cvs dist, devel tree? It was in Core before... Thanks -- Colin Charles, http://www.bytebot.net/ From buildsys at fedoraproject.org Sat May 28 04:28:41 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 28 May 2005 00:28:41 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050528042841.D4E80810D@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 15 Inventor-2.1.5-11 Inventor-2.1.5-11.fc3 SIMVoleon-2.0.1-1 SIMVoleon-2.0.1-1.fc3 cvsps-2.1-1 galeon-1.3.21-2 galeon-1.3.21-2.fc3 gpredict-0.5.1-1 iozone-3-1 perl-Text-Autoformat-1.13-1 perl-Text-Autoformat-1.13-1.fc3 pptp-1.6.0-5 pptp-1.6.0-5.fc3 scim-1.2.3-1 scim-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 Sat May 28 04:42:52 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 28 May 2005 00:42:52 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050528044252.E92B1810D@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 25 GiNaC-1.3.1-4 GiNaC-1.3.1-4.fc4 GiNaC-1.3.1-5 GiNaC-1.3.1-5.fc4 Macaulay2-0.9.2-17 Macaulay2-0.9.2-17.fc4 SDL_image-1.2.3-9 SDL_mixer-1.2.5-7 SIMVoleon-2.0.1-1 SIMVoleon-2.0.1-1.fc4 advancecomp-1.14-5 cln-1.1.9-3 cln-1.1.9-3.fc4 cvsps-2.1-2 gossip-0.8-5 gossip-0.8-5.fc4 iozone-3-1 libtabe-0.2.6-14 pptp-1.6.0-5 pptp-1.6.0-5.fc4 recode-3.6-17 scim-1.2.3-1 scim-1.2.3-1.fc4 unison-2.10.2-7 xboard-4.2.7-9 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sat May 28 10:43:52 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sat, 28 May 2005 12:43:52 +0200 Subject: New package: MagicPoint In-Reply-To: <1117250241.3559.12.camel@arena.soho.bytebot.net> References: <1117250241.3559.12.camel@arena.soho.bytebot.net> Message-ID: <20050528124352.31ef34c5@python2> Colin Charles wrote : > I'd like to maintain MagicPoint in Fedora Extras. Any objection with > just importing it from cvs dist, devel tree? It was in Core before... If I've understood correctly, just importing the last known build from Core doesn't need approval, so you can just go ahead. Politely asking as you just did is a good thing, though ;-) Not sure about the bugzilla owners for such packages, though. Someone should probably step up... you? :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.27_FC3 Load : 0.17 0.28 0.20 From rkutai at streamyx.com Sat May 28 12:42:59 2005 From: rkutai at streamyx.com (Raymond Steven Kutai) Date: Sat, 28 May 2005 20:42:59 +0800 Subject: Fedora Extras 3 Package Build Report In-Reply-To: <20050528042841.D4E80810D@extras64.linux.duke.edu> References: <20050528042841.D4E80810D@extras64.linux.duke.edu> Message-ID: <20050528124259.GB9822@lupin.rkutai.net> On Sat, May 28, 2005 at 12:28:41AM -0400, buildsys at fedoraproject.org wrote: > > Packages built and released for Fedora Extras 3: 15 > > Inventor-2.1.5-11 > Inventor-2.1.5-11.fc3 err... why are there 2 of em? are they the same? ok just managed to download em both spec files are the same though. looks like a waste of HDD space to me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Sat May 28 13:01:27 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 28 May 2005 15:01:27 +0200 Subject: Fedora Extras 3 Package Build Report In-Reply-To: <20050528124259.GB9822@lupin.rkutai.net> References: <20050528042841.D4E80810D@extras64.linux.duke.edu> <20050528124259.GB9822@lupin.rkutai.net> Message-ID: <20050528150127.5ef47d4c.bugs.michael@gmx.net> On Sat, 28 May 2005 20:42:59 +0800, Raymond Steven Kutai wrote: > On Sat, May 28, 2005 at 12:28:41AM -0400, buildsys at fedoraproject.org wrote: > > > > Packages built and released for Fedora Extras 3: 15 > > > > Inventor-2.1.5-11 > > Inventor-2.1.5-11.fc3 > > err... why are there 2 of em? are they the same? > ok just managed to download em both spec files are the same though. > looks like a waste of HDD space to me. Known build system mistake. It builds the src.rpm without dist tag one time. Has been explained before in an older build report. From skvidal at phy.duke.edu Sat May 28 13:59:51 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 28 May 2005 09:59:51 -0400 Subject: Fedora Extras 3 Package Build Report In-Reply-To: <20050528124259.GB9822@lupin.rkutai.net> References: <20050528042841.D4E80810D@extras64.linux.duke.edu> <20050528124259.GB9822@lupin.rkutai.net> Message-ID: <1117288791.19135.41.camel@cutter> On Sat, 2005-05-28 at 20:42 +0800, Raymond Steven Kutai wrote: > On Sat, May 28, 2005 at 12:28:41AM -0400, buildsys at fedoraproject.org wrote: > > > > Packages built and released for Fedora Extras 3: 15 > > > > Inventor-2.1.5-11 > > Inventor-2.1.5-11.fc3 > > err... why are there 2 of em? are they the same? > ok just managed to download em both spec files are the same though. > looks like a waste of HDD space to me. and I'll run repomanage on the development repo before long to kick it out. Might do that on the srpms of fc3, too. -sv From bm at metshold.com Sat May 28 21:42:28 2005 From: bm at metshold.com (B. Mets) Date: Sat, 28 May 2005 23:42:28 +0200 Subject: (no subject) Message-ID: <111731596101@mail.leaseweb.nl> Hallo fedora-extras-list, Pls unsubscribe Met vriendelijke groet, B. Mets -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfontain at free.fr Sun May 29 11:34:54 2005 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Sun, 29 May 2005 13:34:54 +0200 Subject: when do packages become available in the repository? Message-ID: <4299A8DE.2020209@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For moodss 20.1, a few days ago, I made tag, then build and got no error message, yet it is not available in http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/ Maybe I missed something? Thanks for your help, - -- Jean-Luc Fontaine http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCmajekG/MMvcT1qQRAjpbAKCTJWUDdQCobMnmtbRQlzRGEGJAwgCfejiU jVaMOWKjlWhr4Pi5Iw6mbfc= =cIFH -----END PGP SIGNATURE----- From skvidal at phy.duke.edu Sun May 29 14:05:10 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 29 May 2005 10:05:10 -0400 Subject: when do packages become available in the repository? In-Reply-To: <4299A8DE.2020209@free.fr> References: <4299A8DE.2020209@free.fr> Message-ID: <1117375510.2499.46.camel@cutter> On Sun, 2005-05-29 at 13:34 +0200, Jean-Luc Fontaine wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > For moodss 20.1, a few days ago, I made tag, then build and got no > error message, yet it is not available in > http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/ > Maybe I missed something? > > Thanks for your help, > ppc build got hung up on xmms and the nfs mount. I had to clear out the mounts on the ppc box but that's what's going on. moodss will get built soonish -sv From adrian at lisas.de Sun May 29 14:44:36 2005 From: adrian at lisas.de (Adrian Reber) Date: Sun, 29 May 2005 16:44:36 +0200 Subject: Request for review: netselect In-Reply-To: <1116328779.22682.48.camel@rydia.hardsun.net> References: <20050513160118.GA17721@lisas.de> <1116006752.4707.15.camel@rydia.hardsun.net> <20050516091151.GA22153@lisas.de> <1116328779.22682.48.camel@rydia.hardsun.net> Message-ID: <20050529144436.GA25071@lisas.de> On Tue, May 17, 2005 at 04:19:39AM -0700, Aaron Kurtz wrote: > > > - Considering this is Fedora Extras, an entirely separate -yum package > > > is a bit unnecessary. Just roll it in. > > > > I would rather like to leave it as two packages. > > Why? It's just one file in the -yum package. Okay, I have added it back to the netselect package. > > > = DistTags. http://fedoraproject.org/wiki/DistTag > > > > Ahh... not yet. If it becomes necessary. > > Never a bad time to start good habits. I wonder why it's not mandatory. dist tag has been added. http://lisas.de/~adrian/rpm/netselect-0.3-1.src.rpm Adrian -- Adrian Reber http://lisas.de/~adrian/ travel, n.: Something that makes you feel like you're getting somewhere. From elprodigio at gmail.com Sun May 29 16:43:35 2005 From: elprodigio at gmail.com (Didier Casse) Date: Mon, 30 May 2005 00:43:35 +0800 Subject: Request for review: Enlightenment DR17 + EFL Message-ID: <513a3b305052909433f8d4ec9@mail.gmail.com> Hi all, I would like to have a review on the Enlightenment DR17 package + the accompanying Enlightenment Foundation Library packages (EFL). The spec files are here: http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/eet.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/edb.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/imlib2.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/embryo.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/evas.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/ecore.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/edje.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/epeg.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/epsilon.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/etox.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/esmart.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/emotion.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/ewl.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/iconbar.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/entice.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/entrance.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/examine.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/elicit.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/erss.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/eclair.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/enlightenment.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/engage.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/engrave.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/e_utils.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/e_modules.spec http://sps.nus.edu.sg/~didierbe/fedora/extras/specs/e17genmenu.spec The corresponding src rpms are here: http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/eet-0.9.10.007-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/edb-1.0.5.003-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/imlib2-1.2.0.007-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/embryo-0.9.1.007-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/evas-0.9.9.007-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/ecore-0.9.9.007-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/edje-0.5.0.007-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/epeg-0.9.0.003-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/epsilon-0.3.0.003-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/etox-0.9.0.003-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/esmart-0.9.0.003-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/emotion-0.0.1.003-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/ewl-0.0.4.003-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/iconbar-0.9.1-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/entice-0.9.3.003-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/entrance-0.9.0.003-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/examine-0.0.1-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/elicit-0.9.0-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/erss-0.0.2-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/eclair-0.0.1-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/enlightenment-0.16.999.007-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/engage-0.0.9-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/engrave-0.1.0-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/e_utils-0.0.1-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/e_modules-0.0.1-1.20050529.e17.fc3.src.rpm http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/e17genmenu-0.1.7-1.e17.fc3.src.rpm For those who want to test/install DR17/E17 or any EFLs with yum, you can place this in your /etc/yum.conf: ================================================= [Didier] name=Didier's yum repository for DR17/E17 FC Extras baseurl=http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386 enabled=1 ================================================= Import of my public key: rpm --import http://sps.nus.edu.sg/~didierbe/RPM-GPG-KEY.didier.txt A one-line description of the packages can be found at: http://sps.nus.edu.sg/~didierbe/ [Bottom of the page !]. For a detailed description, please refer to http://www.enlightenment.org Thanks for any comments and feedback. ;-) -- With kind regards, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. From ellson at research.att.com Sun May 29 18:13:56 2005 From: ellson at research.att.com (John Ellson) Date: Sun, 29 May 2005 14:13:56 -0400 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <513a3b305052909433f8d4ec9@mail.gmail.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> Message-ID: <429A0664.3010505@research.att.com> Didier Casse wrote: >Hi all, > I would like to have a review on the Enlightenment DR17 package >+ the accompanying Enlightenment Foundation Library packages (EFL). > > > Didier, Thanks for doing this work. I'm looking forward to trying E again. I tried to rpmbuild -ba imlib2.spec on an x64_64 machine and I needed to add --libdir=%{_libdir} to the./autogen.sh line to get the libraries to install in /usr/lib64/ properly. Once I added this it built OK. I looked at a couple of other .spec files and I think they all have the same problem. Also, isn't it more conventional to just use ./configure instead of ./autogen.sh in the spec file? John From fedora at camperquake.de Sun May 29 18:51:27 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 29 May 2005 20:51:27 +0200 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <429A0664.3010505@research.att.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> Message-ID: <20050529185127.GC26225@ryoko.camperquake.de> On Sun, May 29, 2005 at 02:13:56PM -0400, John Ellson wrote: > Also, isn't it more conventional to just use ./configure instead of > ./autogen.sh > in the spec file? Older CVS dumps had the "configure" call hardcoded in the autogen.sh file. Newer versions use an environment variable (NOCONFIGURE I think) to disable this. So (without having looked at the spec files), I'd recommend to use NOCONFIGURE=1 ./autogen.sh %configure in the spec file, so all the magic parameters appear. From ville.skytta at iki.fi Sun May 29 19:23:14 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 29 May 2005 22:23:14 +0300 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <429A0664.3010505@research.att.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> Message-ID: <1117394594.4633.12.camel@bobcat.mine.nu> On Sun, 2005-05-29 at 14:13 -0400, John Ellson wrote: > Didier Casse wrote: > > >Hi all, > > I would like to have a review on the Enlightenment DR17 package > >+ the accompanying Enlightenment Foundation Library packages (EFL). > > Didier, > > Thanks for doing this work. I'm looking forward to trying E again. > > I tried to rpmbuild -ba imlib2.spec on an x64_64 machine and I > needed to add --libdir=%{_libdir} to the./autogen.sh line [...] FYI: imlib2 is already in Extras. From ellson at research.att.com Sun May 29 19:23:11 2005 From: ellson at research.att.com (John Ellson) Date: Sun, 29 May 2005 15:23:11 -0400 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <20050529185127.GC26225@ryoko.camperquake.de> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050529185127.GC26225@ryoko.camperquake.de> Message-ID: <429A169F.7070403@research.att.com> Ralf Ertzinger wrote: >On Sun, May 29, 2005 at 02:13:56PM -0400, John Ellson wrote: > > > >>Also, isn't it more conventional to just use ./configure instead of >>./autogen.sh >>in the spec file? >> >> > >Older CVS dumps had the "configure" call hardcoded in the autogen.sh >file. Newer versions use an environment variable (NOCONFIGURE I think) >to disable this. > >So (without having looked at the spec files), I'd recommend to use > >NOCONFIGURE=1 ./autogen.sh >%configure > >in the spec file, so all the magic parameters appear. > > The issue is that all the files generated by autogen.sh (without configure) should all be included in the tar.gz and that there should be no need to rerun it on the build system. My understanding is that autogen.sh is for running things like libtoolize, autoconf, and automake that need to be run after CVS checkout but before "make dist". The autogen.sh is not normally included in the tar.gz (or in the src.rpm) and building from a tar.gz (or running rpmbuild) should not depend on libtoolize, autoconf, or automake on the build system. Perhaps I'm being too pedantic.... it does work OK if you don't mind the dependencies. John From fedora at camperquake.de Sun May 29 19:27:46 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 29 May 2005 21:27:46 +0200 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <429A169F.7070403@research.att.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050529185127.GC26225@ryoko.camperquake.de> <429A169F.7070403@research.att.com> Message-ID: <20050529192746.GD26225@ryoko.camperquake.de> On Sun, May 29, 2005 at 03:23:11PM -0400, John Ellson wrote: > The issue is that all the files generated by autogen.sh (without > configure) should all be included in the > tar.gz and that there should be no need to rerun it on the build system. There are no .tar files. The only way to get E17 is to use CVS checkouts. From ellson at research.att.com Sun May 29 19:36:03 2005 From: ellson at research.att.com (John Ellson) Date: Sun, 29 May 2005 15:36:03 -0400 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <20050529192746.GD26225@ryoko.camperquake.de> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050529185127.GC26225@ryoko.camperquake.de> <429A169F.7070403@research.att.com> <20050529192746.GD26225@ryoko.camperquake.de> Message-ID: <429A19A3.40604@research.att.com> Ralf Ertzinger wrote: >On Sun, May 29, 2005 at 03:23:11PM -0400, John Ellson wrote: > > > >>The issue is that all the files generated by autogen.sh (without >>configure) should all be included in the >>tar.gz and that there should be no need to rerun it on the build system. >> >> > >There are no .tar files. The only way to get E17 is to use CVS checkouts. > > Excuse me, but yes there are .tar.gz files. They are in the src.rpm from: http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/ which you can install with rpm -U *.src.rpm and then see in rpmbuild/SOURCES/ They were presumably generated with "make dist". John From ellson at research.att.com Sun May 29 19:44:57 2005 From: ellson at research.att.com (John Ellson) Date: Sun, 29 May 2005 15:44:57 -0400 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <1117394594.4633.12.camel@bobcat.mine.nu> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <1117394594.4633.12.camel@bobcat.mine.nu> Message-ID: <429A1BB9.3080605@research.att.com> Ville Skytt? wrote: >On Sun, 2005-05-29 at 14:13 -0400, John Ellson wrote: > > >>Didier Casse wrote: >> >> >> >>>Hi all, >>> I would like to have a review on the Enlightenment DR17 package >>>+ the accompanying Enlightenment Foundation Library packages (EFL). >>> >>> >>Didier, >> >>Thanks for doing this work. I'm looking forward to trying E again. >> >>I tried to rpmbuild -ba imlib2.spec on an x64_64 machine and I >>needed to add --libdir=%{_libdir} to the./autogen.sh line [...] >> >> > >FYI: imlib2 is already in Extras. > > Hmm. So are: edb, eet, taglib, and gettext is in Core. From ellson at research.att.com Sun May 29 19:55:09 2005 From: ellson at research.att.com (John Ellson) Date: Sun, 29 May 2005 15:55:09 -0400 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <513a3b305052909433f8d4ec9@mail.gmail.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> Message-ID: <429A1E1D.1070806@research.att.com> Didier Casse wrote: >Hi all, > I would like to have a review on the Enlightenment DR17 package >+ the accompanying Enlightenment Foundation Library packages (EFL). > > evas fails to build on x86_64 with gcc-4.0.0 /usr/bin/gcc -DHAVE_CONFIG_H -I. -I. -I../../../.. -I/usr/include/freetype2 -mp referred-stack-boundary=2 -I/usr/include/valgrind -I/usr/include/valgrind/x86 -I /usr/include/valgrind/linux -I/usr/include/valgrind/x86-linux -I. -I../../../../ src/lib -I../../../../src/lib/include -g -O2 -MT evas_blend_alpha_color_pixel.lo -MD -MP -MF .deps/evas_blend_alpha_color_pixel.Tpo -c evas_blend_alpha_color_pixel.c -fPIC -DPIC -o .libs/evas_blend_alpha_color_pixel.o evas_blend_alpha_color_pixel.c:1: error: -mpreferred-stack-boundary=2 is not between 4 and 12 make[5]: *** [evas_blend_alpha_color_pixel.lo] Error 1 make[5]: Leaving directory `/home/ellson/rpmbuild/BUILD/evas-0.9.9.007/src/lib/engines/common' From buildsys at fedoraproject.org Sun May 29 20:36:59 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 29 May 2005 16:36:59 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050529203659.9F94780F8@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 5 cvsweb-3.0.5-1 linphone-1.0.1-3 linphone-1.0.1-3.fc3 perl-Net-IP-1.22-1 sylpheed-claws-1.0.4a-1 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun May 29 20:48:17 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 29 May 2005 16:48:17 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050529204817.051F080F8@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 7 cvsweb-3.0.5-2 hddtemp-0.3-0.4.beta13 linphone-1.0.1-3 linphone-1.0.1-3.fc4 perl-Net-IP-1.22-2 xemacs-sumo-20050505-3 xmms-flac-1.1.2-24 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From ivazquez at ivazquez.net Sun May 29 22:49:43 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 29 May 2005 18:49:43 -0400 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <20050529192746.GD26225@ryoko.camperquake.de> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050529185127.GC26225@ryoko.camperquake.de> <429A169F.7070403@research.att.com> <20050529192746.GD26225@ryoko.camperquake.de> Message-ID: <1117406983.25393.0.camel@ignacio.ignacio.lan> On Sun, 2005-05-29 at 21:27 +0200, Ralf Ertzinger wrote: > There are no .tar files. The only way to get E17 is to use CVS checkouts. Uh, no... http://enlightenment.freedesktop.org/ -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mpeters at mac.com Mon May 30 00:56:16 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 29 May 2005 17:56:16 -0700 Subject: Request for review: latex-prosper Message-ID: <1117414576.6112.52.camel@laptop.mpeters.local> http://mpeters.us/fc_extras/latex-prosper.spec http://mpeters.us/fc_extras/latex-prosper-1.00.4-0.1.src.rpm This is the prosper class for latex It allows you to export latex to pretty pdf slides that work well in acroread I'm packaging this because in my math class, our group project - I did the graphs in the gnuplot, I did our document in LyX/LaTeX, I did the spreadsheet work in Gnumeric - it was a great opportunity to showcase to the other students what free software could do (especially our group took the cake), but it bothered me that there wasn't a satisfactory way I knew of creating the presentation in Linux. ended up using latex2html and then cut and paste into powerpoint - worked, but bothered and also wasn't terribly elegant way to do it. After searching around - this looked like the most promising solution for math presentations, and indeed - it works incredibly well. Too late for the presentation, but not too late for next time ... ;) -=- Not sure I have the group right. rpmlint complains about the license I'm calling it latex-prosper rather than prosper because prosper seemed too generic, and might possibly be used by another unrelated project (like a banking app or something). From elprodigio at gmail.com Mon May 30 02:10:27 2005 From: elprodigio at gmail.com (Didier Casse) Date: Mon, 30 May 2005 10:10:27 +0800 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <429A19A3.40604@research.att.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050529185127.GC26225@ryoko.camperquake.de> <429A169F.7070403@research.att.com> <20050529192746.GD26225@ryoko.camperquake.de> <429A19A3.40604@research.att.com> Message-ID: <513a3b305052919103e75b08f@mail.gmail.com> On 5/30/05, John Ellson wrote: > Ralf Ertzinger wrote: > > >On Sun, May 29, 2005 at 03:23:11PM -0400, John Ellson wrote: > > > > > > > >>The issue is that all the files generated by autogen.sh (without > >>configure) should all be included in the > >>tar.gz and that there should be no need to rerun it on the build system. > >> > >> > > > >There are no .tar files. The only way to get E17 is to use CVS checkouts. > > > > > > Excuse me, but yes there are .tar.gz files. > They are in the src.rpm from: > http://sps.nus.edu.sg/~didierbe/fedora/extras/3/en/i386/SRPMS.e17/ > which you can install with rpm -U *.src.rpm and then see in > rpmbuild/SOURCES/ > > They were presumably generated with "make dist". > Hi John, First thanks for the comments. Actually I build from CVS. For CVS checkouts, rasterman recommended to use ./autogen.sh instead of ./configure! There's also some tarballs/snapshot releases which exist on http://enlightenment.freedesktop.org which are pretty recent. The reason why they exist now is that many people complained that they were no releases from the Enlightenment development team and that was annoying. For the ones on the above website, ./configure should be used. What we use is pretty much dictated by the lead developers. I use CVS checkouts because they are more up-to-date. Of course I ensure that everything's working correctly before I make rpm releases. And I also have some testers at hand. ;-) The snapshots on the website mentionned are only released once a month and if you want to do some development work with the EFL, well you would be pretty much behind! When I used the snapshot releases, I got lots of emails from people telling me to upgrade since they couldn't try the latest xxx EFL apps on E. So I decided to be more on the cutting edge. -- With kind regards, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. From bugs.michael at gmx.net Mon May 30 02:21:33 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 30 May 2005 04:21:33 +0200 Subject: Imlib2 (was: Re: Request for review: Enlightenment DR17 + EFL) In-Reply-To: <429A0664.3010505@research.att.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> Message-ID: <20050530042133.7e41e0c3.bugs.michael@gmx.net> On Sun, 29 May 2005 14:13:56 -0400, John Ellson wrote: > I tried to rpmbuild -ba imlib2.spec on an x64_64 machine and I > needed to add --libdir=%{_libdir} to the./autogen.sh line to get > the libraries to install in /usr/lib64/ properly. Once I added this > it built OK. > I looked at a couple of other .spec files and I think they all have the > same problem. There is imlib2 in Fedora Extras already. To split Imlib2 into 15 (!) packages is very unusual sub-package inflation IMO. Directories %{_libdir}/imlib2/, %{_libdir}/imlib2/filters/ and %{_libdir}/imlib2/loaders are not included, btw. -- From elprodigio at gmail.com Mon May 30 02:31:05 2005 From: elprodigio at gmail.com (Didier Casse) Date: Mon, 30 May 2005 10:31:05 +0800 Subject: Imlib2 (was: Re: Request for review: Enlightenment DR17 + EFL) In-Reply-To: <20050530042133.7e41e0c3.bugs.michael@gmx.net> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050530042133.7e41e0c3.bugs.michael@gmx.net> Message-ID: <513a3b305052919312e5998e0@mail.gmail.com> On 5/30/05, Michael Schwendt wrote: > On Sun, 29 May 2005 14:13:56 -0400, John Ellson wrote: > > > I tried to rpmbuild -ba imlib2.spec on an x64_64 machine and I > > needed to add --libdir=%{_libdir} to the./autogen.sh line to get > > the libraries to install in /usr/lib64/ properly. Once I added this > > it built OK. > > I looked at a couple of other .spec files and I think they all have the > > same problem. > > There is imlib2 in Fedora Extras already. > > To split Imlib2 into 15 (!) packages is very unusual sub-package > inflation IMO. Directories %{_libdir}/imlib2/, %{_libdir}/imlib2/filters/ > and %{_libdir}/imlib2/loaders are not included, btw. > Dear Michael, Well we differentiate between the different imlib_loaders. ;-) If you prefer to package them as imlib2_loaders-xxx.rpm. This can also be done. But remember that a normal user needs only the 3 basic loaders (jpeg, png argb) to run DR17. The principle of splitting is not to download the whole thing. What do you propose as an alternative? -- Cheers, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. From elprodigio at gmail.com Mon May 30 02:39:35 2005 From: elprodigio at gmail.com (Didier Casse) Date: Mon, 30 May 2005 10:39:35 +0800 Subject: Request for review: latex-prosper In-Reply-To: <1117414576.6112.52.camel@laptop.mpeters.local> References: <1117414576.6112.52.camel@laptop.mpeters.local> Message-ID: <513a3b30505291939dc0cd89@mail.gmail.com> On 5/30/05, Michael A. Peters wrote: > http://mpeters.us/fc_extras/latex-prosper.spec > http://mpeters.us/fc_extras/latex-prosper-1.00.4-0.1.src.rpm > > This is the prosper class for latex Dear Michael, This is a nice tool. ;-) I think for your Source0, it's better to write: http://umn.dl.sourceforge.net/sourceforge/prosper/prosper-%{name}-%{version}.tar.gz -- Cheers, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. From bugs.michael at gmx.net Mon May 30 03:32:58 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 30 May 2005 05:32:58 +0200 Subject: Imlib2 (was: Re: Request for review: Enlightenment DR17 + EFL) In-Reply-To: <513a3b305052919312e5998e0@mail.gmail.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050530042133.7e41e0c3.bugs.michael@gmx.net> <513a3b305052919312e5998e0@mail.gmail.com> Message-ID: <20050530053258.1df99559.bugs.michael@gmx.net> On Mon, 30 May 2005 10:31:05 +0800, Didier Casse wrote: > On 5/30/05, Michael Schwendt wrote: > > On Sun, 29 May 2005 14:13:56 -0400, John Ellson wrote: > > > > > I tried to rpmbuild -ba imlib2.spec on an x64_64 machine and I > > > needed to add --libdir=%{_libdir} to the./autogen.sh line to get > > > the libraries to install in /usr/lib64/ properly. Once I added this > > > it built OK. > > > I looked at a couple of other .spec files and I think they all have the > > > same problem. > > > > There is imlib2 in Fedora Extras already. > > > > To split Imlib2 into 15 (!) packages is very unusual sub-package > > inflation IMO. Directories %{_libdir}/imlib2/, %{_libdir}/imlib2/filters/ > > and %{_libdir}/imlib2/loaders are not included, btw. > > > > Dear Michael, > > Well we differentiate between the different imlib_loaders. ;-) > > If you prefer to package them as imlib2_loaders-xxx.rpm. This can also > be done. But remember that a normal user needs only the 3 basic > loaders (jpeg, png argb) to run DR17. Via explicit package dependencies in every package which needs Imlib2? This is ugly. > The principle of splitting is not to download the whole thing. What do > you propose as an alternative? From mpeters at mac.com Mon May 30 03:32:20 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 29 May 2005 20:32:20 -0700 Subject: Request for review: latex-prosper In-Reply-To: <513a3b30505291939dc0cd89@mail.gmail.com> References: <1117414576.6112.52.camel@laptop.mpeters.local> <513a3b30505291939dc0cd89@mail.gmail.com> Message-ID: <1117423940.6112.61.camel@laptop.mpeters.local> On Mon, 2005-05-30 at 10:39 +0800, Didier Casse wrote: > On 5/30/05, Michael A. Peters wrote: > > http://mpeters.us/fc_extras/latex-prosper.spec > > http://mpeters.us/fc_extras/latex-prosper-1.00.4-0.1.src.rpm > > > > This is the prosper class for latex > > Dear Michael, > This is a nice tool. ;-) > > I think for your Source0, it's better to write: > > http://umn.dl.sourceforge.net/sourceforge/prosper/prosper-%{name}-%{version}.tar.gz > I agree - but it easier for testers to get the source to md5sum check with upstream if macros aren't used in the source tag (IE they can cut and paste into a wget) From elprodigio at gmail.com Mon May 30 03:56:02 2005 From: elprodigio at gmail.com (Didier Casse) Date: Mon, 30 May 2005 11:56:02 +0800 Subject: Imlib2 (was: Re: Request for review: Enlightenment DR17 + EFL) In-Reply-To: <20050530053258.1df99559.bugs.michael@gmx.net> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050530042133.7e41e0c3.bugs.michael@gmx.net> <513a3b305052919312e5998e0@mail.gmail.com> <20050530053258.1df99559.bugs.michael@gmx.net> Message-ID: <513a3b3050529205672ba67@mail.gmail.com> On 5/30/05, Michael Schwendt wrote: > On Mon, 30 May 2005 10:31:05 +0800, Didier Casse wrote: > > > On 5/30/05, Michael Schwendt wrote: > > > On Sun, 29 May 2005 14:13:56 -0400, John Ellson wrote: > > > > > > > I tried to rpmbuild -ba imlib2.spec on an x64_64 machine and I > > > > needed to add --libdir=%{_libdir} to the./autogen.sh line to get > > > > the libraries to install in /usr/lib64/ properly. Once I added this > > > > it built OK. > > > > I looked at a couple of other .spec files and I think they all have the > > > > same problem. > > > > > > There is imlib2 in Fedora Extras already. > > > > > > To split Imlib2 into 15 (!) packages is very unusual sub-package > > > inflation IMO. Directories %{_libdir}/imlib2/, %{_libdir}/imlib2/filters/ > > > and %{_libdir}/imlib2/loaders are not included, btw. > > > > > > > Dear Michael, > > > > Well we differentiate between the different imlib_loaders. ;-) > > > > If you prefer to package them as imlib2_loaders-xxx.rpm. This can also > > be done. But remember that a normal user needs only the 3 basic > > loaders (jpeg, png argb) to run DR17. > > Via explicit package dependencies in every package which needs Imlib2? > This is ugly. > Hi Michael, I just peeked at imlib2.spec in extras. Well you decided to link the loaders to the main lib. This packing is fine with me. ;-) -- Cheers, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. From ellson at research.att.com Mon May 30 04:06:40 2005 From: ellson at research.att.com (John Ellson) Date: Mon, 30 May 2005 00:06:40 -0400 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <513a3b305052919103e75b08f@mail.gmail.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050529185127.GC26225@ryoko.camperquake.de> <429A169F.7070403@research.att.com> <20050529192746.GD26225@ryoko.camperquake.de> <429A19A3.40604@research.att.com> <513a3b305052919103e75b08f@mail.gmail.com> Message-ID: <429A9150.1060101@research.att.com> Didier Casse wrote: > <> Actually I build from CVS. > For CVS checkouts, rasterman recommended to use ./autogen.sh instead > of ./configure! <>Didier, I agree that one would use ./autogen.sh for direct CVS checkouts. There are additional toolchain requirements on the user in that case. My point was that, from .spec files, you should be using ./configure since the src.rpm recipient is then building from the contained .tar.gz instead of directly from CVS. By using ./autogen.sh in the .spec files you are requiring that the src.rpm recipient have autoconf, automake and libtool installed. This should not be necessary. John From elprodigio at gmail.com Mon May 30 04:23:58 2005 From: elprodigio at gmail.com (Didier Casse) Date: Mon, 30 May 2005 12:23:58 +0800 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <429A9150.1060101@research.att.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050529185127.GC26225@ryoko.camperquake.de> <429A169F.7070403@research.att.com> <20050529192746.GD26225@ryoko.camperquake.de> <429A19A3.40604@research.att.com> <513a3b305052919103e75b08f@mail.gmail.com> <429A9150.1060101@research.att.com> Message-ID: <513a3b305052921232303ca22@mail.gmail.com> On 5/30/05, John Ellson wrote: > Didier Casse wrote: > > > <> Actually I build from CVS. > > For CVS checkouts, rasterman recommended to use ./autogen.sh instead > > of ./configure! > > <>Didier, > > I agree that one would use ./autogen.sh for direct CVS checkouts. There > are additional toolchain requirements on the user in that case. > > My point was that, from .spec files, you should be using ./configure > since the src.rpm recipient is then building from the contained .tar.gz > instead of directly from CVS. > > By using ./autogen.sh in the .spec files you are requiring that the > src.rpm recipient have autoconf, automake and libtool installed. This > should not be necessary. Hi John, I get your point. CVS checkout shoud therefore be followed by a "make dist" to get a tarball that doesn't place the above requirements on the user. Understood. Thanks. ;-) Btw what happens when you disable mmx and sse for evas? Does it compile on your architecture? -- Cheers, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. From ellson at research.att.com Mon May 30 04:44:22 2005 From: ellson at research.att.com (John Ellson) Date: Mon, 30 May 2005 00:44:22 -0400 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050529185127.GC26225@ryoko.camperquake.de> <429A169F.7070403@research.att.com> <20050529192746.GD26225@ryoko.camperquake.de> <429A19A3.40604@research.att.com> <513a3b305052919103e75b08f@mail.gmail.com> <429A9150.1060101@research.att.com> Message-ID: <429A9A26.8000602@research.att.com> Didier Casse wrote: > >Btw what happens when you disable mmx and sse for evas? Does it >compile on your architecture? > > > Didn't fix it. Carsten Haitzler (The Rasterman) wrote: >have u checked the CFLAGS? actually READ the error output? evas does NOT set >CFLAGs - it inherits from the build environment. gcc is complaining the >-mpreferred-stack-boundary=2 is a bad value. it cannot compile the code with it >at 2. it must be at 4 to 12. you must fix your CFLAGS > > OK. The -mpreferred-stack-boundary=2 came from /usr/lib/pkgconfig/valgrind.pc which I picked up because I had /usr/lib/pkgconfig in my PKG_CONFIG_PATH and there is no 64 bit version of valgrind in the fedora-devel distribution. I fixed it locally by using only /usr/lib64/pkgconfig in my PKG_CONFIG_PATH. My fault I guess. "rpmbuild -ba evas.spec" is now working for me on x86_64. John From ed at eh3.com Mon May 30 03:34:27 2005 From: ed at eh3.com (Ed Hill) Date: Sun, 29 May 2005 23:34:27 -0400 Subject: Request for review: latex-prosper In-Reply-To: <1117414576.6112.52.camel@laptop.mpeters.local> References: <1117414576.6112.52.camel@laptop.mpeters.local> Message-ID: <1117424067.28429.62.camel@ernie> On Sun, 2005-05-29 at 17:56 -0700, Michael A. Peters wrote: > http://mpeters.us/fc_extras/latex-prosper.spec > http://mpeters.us/fc_extras/latex-prosper-1.00.4-0.1.src.rpm Hi Michael, This is not a full review (sorry, not enough time tonight!) but I did notice one item that confused me. The prosper license says "LPPL" but I looked through the docs and could only find the following (see below) which appears to be very BSD-like (which is fine). So should the license be listed as "BSD" instead of "LPPL" ? Ed === from: prosper/doc/prosper-doc.pdf === 9 Copyright information Copyright (c) 2000 by Frederic Goualard, all rights reserved. Permission is hereby granted, without written agreement and without license or royalty fees, to use, copy, modify, and distribute this software and its documentation for any purpose, provided that the above copyright notice and the following two paragraphs appear in all copies of this software. IN NO EVENT SHALL THE AUTHOR BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE AUTHOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. THE AUTHOR SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE AUTHOR HAS NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. -- 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 ellson at research.att.com Mon May 30 05:21:06 2005 From: ellson at research.att.com (John Ellson) Date: Mon, 30 May 2005 01:21:06 -0400 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <513a3b305052909433f8d4ec9@mail.gmail.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> Message-ID: <429AA2C2.60300@research.att.com> Didier Casse wrote: >Hi all, > I would like to have a review on the Enlightenment DR17 package >+ the accompanying Enlightenment Foundation Library packages (EFL). > > Dependency problem: $ rpmbuild -ba emotion.spec error: Failed build dependencies: xine-lib-devel is needed by emotion-0.0.1.003-1.20050530.e17.fc3.x86_64 xine-lib-devel is not provided by Fedora-Core or Fedora-Extras. John From jpo at di.uminho.pt Mon May 30 04:29:09 2005 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Mon, 30 May 2005 05:29:09 +0100 (WEST) Subject: Request for review: latex-prosper In-Reply-To: <1117414576.6112.52.camel@laptop.mpeters.local> References: <1117414576.6112.52.camel@laptop.mpeters.local> Message-ID: <1082.213.13.91.114.1117427349.squirrel@webmail.lsd.di.uminho.pt> Michael Peters, > http://mpeters.us/fc_extras/latex-prosper.spec > http://mpeters.us/fc_extras/latex-prosper-1.00.4-0.1.src.rpm The namespace for LaTeX packages in Fedora is tetex. Please rename the package to tetex-prosper. > This is the prosper class for latex > It allows you to export latex to pretty pdf slides that work well in > acroread > > I'm packaging this because in my math class, our group project - I did > the graphs in the gnuplot, I did our document in LyX/LaTeX, I did the > spreadsheet work in Gnumeric - it was a great opportunity to showcase to > the other students what free software could do (especially our group > took the cake), but it bothered me that there wasn't a satisfactory way > I knew of creating the presentation in Linux. > > ended up using latex2html and then cut and paste into powerpoint - > worked, but bothered and also wasn't terribly elegant way to do it. > > After searching around - this looked like the most promising solution > for math presentations, and indeed - it works incredibly well. Too late > for the presentation, but not too late for next time ... ;) I consider the Beamer package superior to Prosper. Check some of the examples in http://latex-beamer.sourceforge.net/. The Beamer package is now included in tetex 3 and is also available for FC3 as tetex-beamer (in the Extras repo). > -=- > Not sure I have the group right. > rpmlint complains about the license Rpmlint doesn't complain about the license if you use the full text. Check the tetex-{xcolor,pgf,beamer,bytefield} specfiles in Extras. > I'm calling it latex-prosper rather than prosper because prosper seemed > too generic, and might possibly be used by another unrelated project > (like a banking app or something). Regards, jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * From elprodigio at gmail.com Mon May 30 05:35:14 2005 From: elprodigio at gmail.com (Didier Casse) Date: Mon, 30 May 2005 13:35:14 +0800 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <429A9A26.8000602@research.att.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050529185127.GC26225@ryoko.camperquake.de> <429A169F.7070403@research.att.com> <20050529192746.GD26225@ryoko.camperquake.de> <429A19A3.40604@research.att.com> <513a3b305052919103e75b08f@mail.gmail.com> <429A9150.1060101@research.att.com> <429A9A26.8000602@research.att.com> Message-ID: <513a3b3050529223560951b82@mail.gmail.com> The solution, as discussed with Carsten, to avoid this in the future would be to set: CFLAGS="-O2 -fomit-frame-pointer" export CFLAGS in the spec file for a generic binary. -- Cheers, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. On 5/30/05, John Ellson wrote: > Didier Casse wrote: > > > > >Btw what happens when you disable mmx and sse for evas? Does it > >compile on your architecture? > > > > > > > Didn't fix it. > > Carsten Haitzler (The Rasterman) wrote: > > >have u checked the CFLAGS? actually READ the error output? evas does NOT set > >CFLAGs - it inherits from the build environment. gcc is complaining the > >-mpreferred-stack-boundary=2 is a bad value. it cannot compile the code with it > >at 2. it must be at 4 to 12. you must fix your CFLAGS > > > > > > OK. The -mpreferred-stack-boundary=2 came from > /usr/lib/pkgconfig/valgrind.pc > which I picked up because I had /usr/lib/pkgconfig in my PKG_CONFIG_PATH and > there is no 64 bit version of valgrind in the fedora-devel distribution. > > I fixed it locally by using only /usr/lib64/pkgconfig in my PKG_CONFIG_PATH. > > My fault I guess. "rpmbuild -ba evas.spec" is now working for me on > x86_64. > > John > From mpeters at mac.com Mon May 30 05:39:19 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 29 May 2005 22:39:19 -0700 Subject: Request for review: latex-prosper In-Reply-To: <1117424067.28429.62.camel@ernie> References: <1117414576.6112.52.camel@laptop.mpeters.local> <1117424067.28429.62.camel@ernie> Message-ID: <1117431559.6112.68.camel@laptop.mpeters.local> On Sun, 2005-05-29 at 23:34 -0400, Ed Hill wrote: > On Sun, 2005-05-29 at 17:56 -0700, Michael A. Peters wrote: > > http://mpeters.us/fc_extras/latex-prosper.spec > > http://mpeters.us/fc_extras/latex-prosper-1.00.4-0.1.src.rpm > > > Hi Michael, > > This is not a full review (sorry, not enough time tonight!) but I did > notice one item that confused me. The prosper license says "LPPL" but I > looked through the docs and could only find the following (see below) > which appears to be very BSD-like (which is fine). I thought it was Latex Project Public License - I've been looking at a lot of little latex addons - must've got confused. Good catch. From mpeters at mac.com Mon May 30 05:45:49 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 29 May 2005 22:45:49 -0700 Subject: Request for review: latex-prosper In-Reply-To: <1082.213.13.91.114.1117427349.squirrel@webmail.lsd.di.uminho.pt> References: <1117414576.6112.52.camel@laptop.mpeters.local> <1082.213.13.91.114.1117427349.squirrel@webmail.lsd.di.uminho.pt> Message-ID: <1117431949.6112.71.camel@laptop.mpeters.local> On Mon, 2005-05-30 at 05:29 +0100, Jose Pedro Oliveira wrote: > Michael Peters, > > > http://mpeters.us/fc_extras/latex-prosper.spec > > http://mpeters.us/fc_extras/latex-prosper-1.00.4-0.1.src.rpm > > The namespace for LaTeX packages in Fedora is tetex. Please > rename the package to tetex-prosper. done http://mpeters.us/fc_extras/tetex-prosper.spec http://mpeters.us/fc_extras/tetex-prosper-1.00.4-0.1.src.rpm fixed License tag as well From ellson at research.att.com Mon May 30 05:48:22 2005 From: ellson at research.att.com (John Ellson) Date: Mon, 30 May 2005 01:48:22 -0400 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <513a3b305052909433f8d4ec9@mail.gmail.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> Message-ID: <429AA926.4060601@research.att.com> Didier Casse wrote: >Hi all, > I would like to have a review on the Enlightenment DR17 package >+ the accompanying Enlightenment Foundation Library packages (EFL). > > Entrance fails to find -lX11 on x86_64. Should be -L/usr/X11R6/lib64 I think the problem is that @X_LIBS@ is not being used from AC_PATH_XTRA in configure.in /usr/bin/gcc -g -O2 -Wall -o entranced auth.o ipc.o md5.o spawner.o util.o -L/usr/X11R6/lib -lX11 -lXext -lXau -L/usr/lib64 -lecore -lecore_job -lecore_x -lecore_evas -lecore_con -lecore_ipc -lecore_txt -lecore_fb -lecore_config -lecore_file -L/usr/lib64 -leet -lz -ljpeg -lm -L/usr/lib64 -ledb -lz -lpam -lcrypt /usr/bin/ld: cannot find -lX11 John From elprodigio at gmail.com Mon May 30 05:52:59 2005 From: elprodigio at gmail.com (Didier Casse) Date: Mon, 30 May 2005 13:52:59 +0800 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <429AA2C2.60300@research.att.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429AA2C2.60300@research.att.com> Message-ID: <513a3b305052922525e6b7416@mail.gmail.com> On 5/30/05, John Ellson wrote: > Didier Casse wrote: > > >Hi all, > > I would like to have a review on the Enlightenment DR17 package > >+ the accompanying Enlightenment Foundation Library packages (EFL). > > > > > > Dependency problem: > > $ rpmbuild -ba emotion.spec > error: Failed build dependencies: > xine-lib-devel is needed by > emotion-0.0.1.003-1.20050530.e17.fc3.x86_64 > > xine-lib-devel is not provided by Fedora-Core or Fedora-Extras. arrgggh :-( This is not a problem if you want to install enlightenment. It doesn't really need emotion. But goodies like eclair --- EFL powered media player engage --- Cool docker that resembles OSX in some ways e_utils --- Utilities: e17setroot/emblem/entangle/e_util_app_edit (Well these ones can be a necessity!) and things like ewl --- Widget library examine--- config interface cannot be installed. Is there a possibility that somebody maintains xine in FC extras? -- Cheers, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. From byte at aeon.com.my Mon May 30 06:03:07 2005 From: byte at aeon.com.my (Colin Charles) Date: Mon, 30 May 2005 16:03:07 +1000 Subject: when do packages become available in the repository? In-Reply-To: <1117375510.2499.46.camel@cutter> References: <4299A8DE.2020209@free.fr> <1117375510.2499.46.camel@cutter> Message-ID: <1117432988.3559.128.camel@arena.soho.bytebot.net> On Sun, 2005-05-29 at 10:05 -0400, seth vidal wrote: > ppc build got hung up on xmms and the nfs mount. I had to clear out > the > mounts on the ppc box but that's what's going on. Was this an exposed bug in the handling of nfs on ppc, or building xmms over nfs, on ppc? I'm willing to try and reproduce -- Colin Charles, http://www.bytebot.net/ From petersen at redhat.com Mon May 30 07:37:17 2005 From: petersen at redhat.com (Jens Petersen) Date: Mon, 30 May 2005 16:37:17 +0900 Subject: flim imported into devel Message-ID: <429AC2AD.9050409@redhat.com> flim: Emacs library for handling email messages flim was removed from Fedora Core after FC3, and since some other removed Emacs packages depend on it I just imported it into extras devel cvs. Jens From nicolas.mailhot at laposte.net Mon May 30 07:43:22 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 30 May 2005 09:43:22 +0200 (CEST) Subject: Imlib2 (was: Re: Request for review: Enlightenment DR17 + EFL) In-Reply-To: <20050530053258.1df99559.bugs.michael@gmx.net> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050530042133.7e41e0c3.bugs.michael@gmx.net> <513a3b305052919312e5998e0@mail.gmail.com> <20050530053258.1df99559.bugs.michael@gmx.net> Message-ID: <48348.192.54.193.37.1117439002.squirrel@rousalka.dyndns.org> On Lun 30 mai 2005 5:32, Michael Schwendt a ?crit : > On Mon, 30 May 2005 10:31:05 +0800, Didier Casse wrote: >> The principle of splitting is not to download the whole thing. What do >> you propose as an alternative? Have a package with the core loaders and one or several for rarely used loaders. Add a virtual per loader and use it in other specs. Move loaders from optional to core as the actual use changes. Regards, -- Nicolas Mailhot From elprodigio at gmail.com Mon May 30 08:43:37 2005 From: elprodigio at gmail.com (Didier Casse) Date: Mon, 30 May 2005 16:43:37 +0800 Subject: Imlib2 (was: Re: Request for review: Enlightenment DR17 + EFL) In-Reply-To: <48348.192.54.193.37.1117439002.squirrel@rousalka.dyndns.org> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050530042133.7e41e0c3.bugs.michael@gmx.net> <513a3b305052919312e5998e0@mail.gmail.com> <20050530053258.1df99559.bugs.michael@gmx.net> <48348.192.54.193.37.1117439002.squirrel@rousalka.dyndns.org> Message-ID: <513a3b3050530014349ea8c7c@mail.gmail.com> Cher Nicolas, Merci. J'avais compris cela en jettant un petit coup d'oeil au spec de Michael Schwendt. -- Cheers, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. On 5/30/05, Nicolas Mailhot wrote: > > On Lun 30 mai 2005 5:32, Michael Schwendt a ?crit : > > On Mon, 30 May 2005 10:31:05 +0800, Didier Casse wrote: > > >> The principle of splitting is not to download the whole thing. What do > >> you propose as an alternative? > > Have a package with the core loaders and one or several for rarely used > loaders. Add a virtual per loader and use it in other specs. Move loaders > from optional to core as the actual use changes. > > Regards, > > -- > Nicolas Mailhot > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From elprodigio at gmail.com Mon May 30 08:46:46 2005 From: elprodigio at gmail.com (Didier Casse) Date: Mon, 30 May 2005 16:46:46 +0800 Subject: Imlib2 (was: Re: Request for review: Enlightenment DR17 + EFL) In-Reply-To: <513a3b3050530014349ea8c7c@mail.gmail.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050530042133.7e41e0c3.bugs.michael@gmx.net> <513a3b305052919312e5998e0@mail.gmail.com> <20050530053258.1df99559.bugs.michael@gmx.net> <48348.192.54.193.37.1117439002.squirrel@rousalka.dyndns.org> <513a3b3050530014349ea8c7c@mail.gmail.com> Message-ID: <513a3b3050530014652b2dbb6@mail.gmail.com> Sorry for the French mail... It was meant for Nicolas. Wrong recipient! I just said: Thank you. I understood this by peeking at the spec file of Michael Schwendt -- Cheers, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. On 5/30/05, Didier Casse wrote: > Cher Nicolas, > Merci. J'avais compris cela en jettant un petit coup > d'oeil au spec de Michael Schwendt. > > -- > Cheers, > Didier. . > > > On 5/30/05, Nicolas Mailhot wrote: > > > > On Lun 30 mai 2005 5:32, Michael Schwendt a ?crit : > > > On Mon, 30 May 2005 10:31:05 +0800, Didier Casse wrote: > > > > >> The principle of splitting is not to download the whole thing. What do > > >> you propose as an alternative? > > > > Have a package with the core loaders and one or several for rarely used > > loaders. Add a virtual per loader and use it in other specs. Move loaders > > from optional to core as the actual use changes. > > > > Regards, > > > > -- > > Nicolas Mailhot > > > > -- > > fedora-extras-list mailing list > > fedora-extras-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-extras-list > > > From bugs.michael at gmx.net Mon May 30 09:21:07 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 30 May 2005 11:21:07 +0200 Subject: Imlib2 (was: Re: Request for review: Enlightenment DR17 + EFL) In-Reply-To: <48348.192.54.193.37.1117439002.squirrel@rousalka.dyndns.org> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050530042133.7e41e0c3.bugs.michael@gmx.net> <513a3b305052919312e5998e0@mail.gmail.com> <20050530053258.1df99559.bugs.michael@gmx.net> <48348.192.54.193.37.1117439002.squirrel@rousalka.dyndns.org> Message-ID: <20050530112107.7d3e3078.bugs.michael@gmx.net> On Mon, 30 May 2005 09:43:22 +0200 (CEST), Nicolas Mailhot wrote: > > On Mon, 30 May 2005 10:31:05 +0800, Didier Casse wrote: > > >> The principle of splitting is not to download the whole thing. What do > >> you propose as an alternative? > > Have a package with the core loaders and one or several for rarely used > loaders. Add a virtual per loader and use it in other specs. Move loaders > from optional to core as the actual use changes. Would that be worthwhile? Effectively, you would need to revisit all dependencies regularly, as whether they add/remove usage of more loaders or filters, and then flip the virtual dependencies accordingly. From bugs.michael at gmx.net Mon May 30 09:22:34 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 30 May 2005 11:22:34 +0200 Subject: Imlib2 (was: Re: Request for review: Enlightenment DR17 + EFL) In-Reply-To: <513a3b3050529205672ba67@mail.gmail.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050530042133.7e41e0c3.bugs.michael@gmx.net> <513a3b305052919312e5998e0@mail.gmail.com> <20050530053258.1df99559.bugs.michael@gmx.net> <513a3b3050529205672ba67@mail.gmail.com> Message-ID: <20050530112234.4b28a11d.bugs.michael@gmx.net> On Mon, 30 May 2005 11:56:02 +0800, Didier Casse wrote: > > > Well we differentiate between the different imlib_loaders. ;-) > > > > > > If you prefer to package them as imlib2_loaders-xxx.rpm. This can also > > > be done. But remember that a normal user needs only the 3 basic > > > loaders (jpeg, png argb) to run DR17. > > > > Via explicit package dependencies in every package which needs Imlib2? > > This is ugly. > > > Hi Michael, > > I just peeked at imlib2.spec in extras. Well you decided to link the > loaders to the main lib. This packing is fine with me. ;-) Are you sure you understood that correctly? (see %changelog) That is just an unrelated bug-fix. The individual loaders are still available. From elprodigio at gmail.com Mon May 30 09:33:07 2005 From: elprodigio at gmail.com (Didier Casse) Date: Mon, 30 May 2005 17:33:07 +0800 Subject: Imlib2 (was: Re: Request for review: Enlightenment DR17 + EFL) In-Reply-To: <20050530112234.4b28a11d.bugs.michael@gmx.net> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050530042133.7e41e0c3.bugs.michael@gmx.net> <513a3b305052919312e5998e0@mail.gmail.com> <20050530053258.1df99559.bugs.michael@gmx.net> <513a3b3050529205672ba67@mail.gmail.com> <20050530112234.4b28a11d.bugs.michael@gmx.net> Message-ID: <513a3b305053002336d939ae1@mail.gmail.com> On 5/30/05, Michael Schwendt wrote: > On Mon, 30 May 2005 11:56:02 +0800, Didier Casse wrote: > > > > > Well we differentiate between the different imlib_loaders. ;-) > > > > > > > > If you prefer to package them as imlib2_loaders-xxx.rpm. This can also > > > > be done. But remember that a normal user needs only the 3 basic > > > > loaders (jpeg, png argb) to run DR17. > > > > > > Via explicit package dependencies in every package which needs Imlib2? > > > This is ugly. > > > > > Hi Michael, > > > > I just peeked at imlib2.spec in extras. Well you decided to link the > > loaders to the main lib. This packing is fine with me. ;-) > > Are you sure you understood that correctly? (see %changelog) > That is just an unrelated bug-fix. The individual loaders are still available. > Perhaps I expressed myself wrongly... I did understand what you did: You have all the stuff (loaders, filters, etc...) in imlib2 and your imlib2-devel only contains: /usr/bin/imlib2-config /usr/include/Imlib2.h /usr/lib/libImlib2.a /usr/lib/libImlib2.la /usr/lib/libImlib2.so /usr/lib/pkgconfig/imlib2.pc which I repeat is fine with me. Don't tell me I got that wrong! -- Cheers, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. From elprodigio at gmail.com Mon May 30 09:37:07 2005 From: elprodigio at gmail.com (Didier Casse) Date: Mon, 30 May 2005 17:37:07 +0800 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <429AA926.4060601@research.att.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429AA926.4060601@research.att.com> Message-ID: <513a3b305053002374eb23441@mail.gmail.com> On 5/30/05, John Ellson wrote: > Didier Casse wrote: > > >Hi all, > > I would like to have a review on the Enlightenment DR17 package > >+ the accompanying Enlightenment Foundation Library packages (EFL). > > > > > > Entrance fails to find -lX11 on x86_64. Should be -L/usr/X11R6/lib64 > I think the problem is that @X_LIBS@ is not being used from > AC_PATH_XTRA in configure.in > > /usr/bin/gcc -g -O2 -Wall -o entranced auth.o ipc.o md5.o spawner.o > util.o -L/usr/X11R6/lib -lX11 -lXext -lXau -L/usr/lib64 -lecore > -lecore_job -lecore_x -lecore_evas -lecore_con -lecore_ipc -lecore_txt > -lecore_fb -lecore_config -lecore_file -L/usr/lib64 -leet -lz -ljpeg -lm > -L/usr/lib64 -ledb -lz -lpam -lcrypt > /usr/bin/ld: cannot find -lX11 --x-libraries={_prefix}/X11R6/{_lib} should be able to fix this. ;-) -- Cheers, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. From bugs.michael at gmx.net Mon May 30 09:57:51 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 30 May 2005 11:57:51 +0200 Subject: Imlib2 (was: Re: Request for review: Enlightenment DR17 + EFL) In-Reply-To: <513a3b305053002336d939ae1@mail.gmail.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050530042133.7e41e0c3.bugs.michael@gmx.net> <513a3b305052919312e5998e0@mail.gmail.com> <20050530053258.1df99559.bugs.michael@gmx.net> <513a3b3050529205672ba67@mail.gmail.com> <20050530112234.4b28a11d.bugs.michael@gmx.net> <513a3b305053002336d939ae1@mail.gmail.com> Message-ID: <20050530115751.4b92ce49.bugs.michael@gmx.net> On Mon, 30 May 2005 17:33:07 +0800, Didier Casse wrote: > > > I just peeked at imlib2.spec in extras. Well you decided to link the > > > loaders to the main lib. This packing is fine with me. ;-) > > > > Are you sure you understood that correctly? (see %changelog) > > That is just an unrelated bug-fix. The individual loaders are still available. > > > Perhaps I expressed myself wrongly... I did understand what you did: > > You have all the stuff (loaders, filters, etc...) in imlib2 Aha. With "link the loaders to the main lib" I thought you referred to Ville's comment in %prep and %changelog. :) From bugs.michael at gmx.net Mon May 30 11:35:08 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 30 May 2005 13:35:08 +0200 Subject: Fedora Extras: missing bugzilla components Message-ID: <20050530133508.6f569b5e.bugs.michael@gmx.net> An increasing number of packages do not have a component entry in bugzilla! What do you need to do? See if your package is on this list and if it is approved, request addition of a bugzilla component entry on this Wiki page: http://fedoraproject.org/wiki/Extras/BugzillaAdmin Offer: reply off-list and state package name(s) and bugzilla account e-mail address, and I request creation of the bugzilla component(s). GiNaC Maelstrom SIMVoleon balsa cdlabelgen cln cvsup enchant enemies-of-carlotta exim-doc exim flumotion fping freenx gnuchess hula kile-i18n lapack milter-greylist mod_security moin nabi nx octave-forge ots rzip syslog-ng tdl util-vserver w3m-el xdaliclock From skvidal at phy.duke.edu Mon May 30 12:35:45 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 30 May 2005 08:35:45 -0400 Subject: when do packages become available in the repository? In-Reply-To: <1117432988.3559.128.camel@arena.soho.bytebot.net> References: <4299A8DE.2020209@free.fr> <1117375510.2499.46.camel@cutter> <1117432988.3559.128.camel@arena.soho.bytebot.net> Message-ID: <1117456545.2499.73.camel@cutter> On Mon, 2005-05-30 at 16:03 +1000, Colin Charles wrote: > On Sun, 2005-05-29 at 10:05 -0400, seth vidal wrote: > > ppc build got hung up on xmms and the nfs mount. I had to clear out > > the > > mounts on the ppc box but that's what's going on. > > Was this an exposed bug in the handling of nfs on ppc, or building xmms > over nfs, on ppc? I'm willing to try and reproduce no, it was an exposed bug in the iptables rules I put in place that I accidentally blocked a port that mountd started using :) -sv From fedora at camperquake.de Mon May 30 12:58:31 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 30 May 2005 14:58:31 +0200 Subject: Question about supported mime-types in /usr/share/applications Message-ID: <20050530145831.42291377@nausicaa.camperquake.de> Hi. Since the bmp version we ship for extras has it's mp3-decoder removed, should the MIME-entries for audio/mp3 and friends be removed from /u/s/a, too? If yes, can external packages that re-add mp3 decoding somehow reregister those MIME-types for BMP? Thanks. From fedora at camperquake.de Mon May 30 13:35:15 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 30 May 2005 15:35:15 +0200 Subject: Fedora Extras: missing bugzilla components In-Reply-To: <20050530133508.6f569b5e.bugs.michael@gmx.net> References: <20050530133508.6f569b5e.bugs.michael@gmx.net> Message-ID: <20050530153515.48f1e6e2@nausicaa.camperquake.de> Hi. Michael Schwendt wrote: > What do you need to do? See if your package is on this list and if it is > approved, request addition of a bugzilla component entry on this Wiki > page: http://fedoraproject.org/wiki/Extras/BugzillaAdmin I will need edit rights for that page. ID: 1110551931.36.46387 Name: RalfErtzinger -- Failure is not an option. It comes bundled with your Microsoft product. -- Ferenc Mantfeld From ellson at research.att.com Mon May 30 13:40:12 2005 From: ellson at research.att.com (John Ellson) Date: Mon, 30 May 2005 09:40:12 -0400 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <513a3b305053002374eb23441@mail.gmail.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429AA926.4060601@research.att.com> <513a3b305053002374eb23441@mail.gmail.com> Message-ID: <429B17BC.8010803@research.att.com> Didier Casse wrote: >On 5/30/05, John Ellson wrote: > > >>Didier Casse wrote: >> >> >> >>>Hi all, >>> I would like to have a review on the Enlightenment DR17 package >>>+ the accompanying Enlightenment Foundation Library packages (EFL). >>> >>> >>> >>> >>Entrance fails to find -lX11 on x86_64. Should be -L/usr/X11R6/lib64 >>I think the problem is that @X_LIBS@ is not being used from >>AC_PATH_XTRA in configure.in >> >>/usr/bin/gcc -g -O2 -Wall -o entranced auth.o ipc.o md5.o spawner.o >>util.o -L/usr/X11R6/lib -lX11 -lXext -lXau -L/usr/lib64 -lecore >>-lecore_job -lecore_x -lecore_evas -lecore_con -lecore_ipc -lecore_txt >>-lecore_fb -lecore_config -lecore_file -L/usr/lib64 -leet -lz -ljpeg -lm >>-L/usr/lib64 -ledb -lz -lpam -lcrypt >>/usr/bin/ld: cannot find -lX11 >> >> > >--x-libraries={_prefix}/X11R6/{_lib} should be able to fix this. ;-) > > > No, that didn't work. I think the following two changes are needed: --- configure.in.old 2005-05-07 02:01:12.000000000 -0400 +++ configure.in 2005-05-30 09:25:36.000000000 -0400 @@ -199,10 +199,7 @@ AC_DEFINE_UNQUOTED(ENTRANCE_XSESSION, "$xsession", [Xsession script]) AC_SUBST(xsession) -x_cflags="-I/usr/X11R6/include" -x_libs="-L/usr/X11R6/lib -lX11 -lXext" -AC_SUBST(x_cflags) -AC_SUBST(x_libs) +AC_PATH_XTRA EDJE_DEF="" AC_SUBST(EDJE_DEF) --- src/daemon/Makefile.am.old 2005-05-30 09:26:39.000000000 -0400 +++ src/daemon/Makefile.am 2005-05-30 09:20:37.000000000 -0400 @@ -1,6 +1,6 @@ ## Process this file with automake to produce Makefile.in -INCLUDES = @x_cflags@ @ecore_cflags@ @edb_cflags@ +INCLUDES = @X_CFLAGS@ @ecore_cflags@ @edb_cflags@ sbin_PROGRAMS = entranced bin_SCRIPTS = entrance_wrapper @@ -8,4 +8,4 @@ entranced_SOURCES = \ auth.c auth.h Entranced.h ipc.c ipc.h md5.c md5.h spawner.c util.c util.h -entranced_LDADD = @x_libs@ -lXau @ecore_libs@ @edb_libs@ +entranced_LDADD = @X_LIBS@ -lX11 -lXext -lXau @ecore_libs@ @edb_libs@ From bugs.michael at gmx.net Mon May 30 14:13:33 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 30 May 2005 16:13:33 +0200 Subject: Fedora Extras: missing bugzilla components In-Reply-To: <20050530153515.48f1e6e2@nausicaa.camperquake.de> References: <20050530133508.6f569b5e.bugs.michael@gmx.net> <20050530153515.48f1e6e2@nausicaa.camperquake.de> Message-ID: <20050530161333.075e29ad.bugs.michael@gmx.net> On Mon, 30 May 2005 15:35:15 +0200, Ralf Ertzinger wrote: > > What do you need to do? See if your package is on this list and if it is > > approved, request addition of a bugzilla component entry on this Wiki > > page: http://fedoraproject.org/wiki/Extras/BugzillaAdmin > > I will need edit rights for that page. > > ID: 1110551931.36.46387 > Name: RalfErtzinger Done. Note that there is no need to state the ID. Just the Wiki account name. From ellson at research.att.com Mon May 30 14:41:31 2005 From: ellson at research.att.com (John Ellson) Date: Mon, 30 May 2005 10:41:31 -0400 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <513a3b305052909433f8d4ec9@mail.gmail.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> Message-ID: <429B261B.6040805@research.att.com> Didier Casse wrote: >Hi all, > I would like to have a review on the Enlightenment DR17 package >+ the accompanying Enlightenment Foundation Library packages (EFL). > > Engage fails to rpmbuild on x86_64 Architure dependency in engage.spec: **************************************************************** --- engage.spec.old 2005-05-29 05:32:34.000000000 -0400 +++ engage.spec 2005-05-30 10:35:01.000000000 -0400 @@ -44,7 +44,7 @@ %defattr(-,root,root) %{_bindir}/engage %{_libdir}/engage* -%{_libdir}/enlightenment/modules_extra/engage/linux-gnu-i686/* +%{_libdir}/enlightenment/modules_extra/engage/ %{_datadir}/engage* %doc AUTHORS ChangeLog COPYING README **************************************************************** Improper setting of $libdir in configure.in: **************************************************************** --- engage-0.0.9/configure.in.old 2005-05-30 10:19:31.000000000 -0400 +++ engage-0.0.9/configure.in 2005-05-30 10:20:57.000000000 -0400 @@ -39,6 +39,7 @@ fi fi +if test "x{libdir}" = "xNONE"; then if test "x${exec_prefix}" = "xNONE"; then if test "x${prefix}" = "xNONE"; then libdir="${ac_default_prefix}/lib"; @@ -52,6 +53,7 @@ libdir="${prefix}/lib"; fi fi +fi dnl Set PACKAGE_DATA_DIR in config.h. if test "x${datadir}" = 'x${prefix}/share'; then **************************************************************** From ellson at research.att.com Mon May 30 14:50:51 2005 From: ellson at research.att.com (John Ellson) Date: Mon, 30 May 2005 10:50:51 -0400 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <513a3b305052922525e6b7416@mail.gmail.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429AA2C2.60300@research.att.com> <513a3b305052922525e6b7416@mail.gmail.com> Message-ID: <429B284B.7000700@research.att.com> Didier Casse wrote: >On 5/30/05, John Ellson wrote: > > >>Didier Casse wrote: >> >> >> >>>Hi all, >>> I would like to have a review on the Enlightenment DR17 package >>>+ the accompanying Enlightenment Foundation Library packages (EFL). >>> >>> >>> >>> >>Dependency problem: >> >> $ rpmbuild -ba emotion.spec >> error: Failed build dependencies: >> xine-lib-devel is needed by >>emotion-0.0.1.003-1.20050530.e17.fc3.x86_64 >> >>xine-lib-devel is not provided by Fedora-Core or Fedora-Extras. >> >> > >arrgggh :-( > >This is not a problem if you want to install enlightenment. It doesn't >really need emotion. But goodies like > >eclair --- EFL powered media player >engage --- Cool docker that resembles OSX in some ways >e_utils --- Utilities: e17setroot/emblem/entangle/e_util_app_edit >(Well these ones can be a necessity!) > >and things like > >ewl --- Widget library >examine--- config interface > >cannot be installed. Is there a possibility that somebody maintains >xine in FC extras? > > > > There are additional depencies as well, but xine itself isn't required. I was able to continue testing E by installing the following from DAG's repository: aalib-1.4.0-5.dag.src.rpm libfame-0.9.1-6.rf.src.rpm xine-lib-1.0.1-2.rf.src.rpm John From Jochen at herr-schmitt.de Mon May 30 14:56:46 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 30 May 2005 16:56:46 +0200 Subject: Approval Require for kyum [was Re: New Package: kyum] In-Reply-To: <0MKwh2-1DaErA2CsL-0002gs@mrelayeu.kundenserver.de> References: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> <4289F654.7090907@city-fan.org> <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> <20050517223520.4de6bc8f.bugs.michael@gmx.net> <0MKwpI-1DYS2e3SIz-0002kY@mrelayeu.kundenserver.de> <20050518200636.020b57d3.bugs.michael@gmx.net> <0MKxQS-1DZwMf0AiV-0004pm@mrelayeu.kundenserver.de> <20050522222811.07231021.bugs.michael@gmx.net> <0MKwh2-1DaErA2CsL-0002gs@mrelayeu.kundenserver.de> Message-ID: <0MKwh2-1DclhL0s6t-0004SA@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 23 May 2005 17:28:28 +0200, you wrote: >* PGP Signed: 05/23/05 at 17:28:42 > >On Sun, 22 May 2005 22:28:11 +0200, you wrote: > >>Can't reproduce it anymore after the updates in Rawhide over the past >>days. Menu icon is visible now. > >Thank you for the good news. > >I have built a new source RPM and have uploaded it to: > >http://www.herr-schmitt.de/pub/kyum/kyum-0.6.3-3.src.rpm > >The only known issue which shouldl be stay in the package is the >fact, that the upstream package contains the source tree twice. > >I have forwarded this issue to the upstream author. I resent this message with a change subject, becous I didn't get any respone for it. It will be nice, if anyone - aspecialy Michael Schwendt - can approval my package. Best Regrads: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.0 (Build 2001) iQA/AwUBQpspuk9gByurcX4MEQK9BgCgriAYiDp3GiCx5PTFOv61jYR+uBMAnjkF 4Ozqo77HKwHdhmdr9OYmOB1n =HnmH -----END PGP SIGNATURE----- From ellson at research.att.com Mon May 30 16:02:16 2005 From: ellson at research.att.com (John Ellson) Date: Mon, 30 May 2005 12:02:16 -0400 Subject: Success! (Re: Request for review: Enlightenment DR17 + EFL) In-Reply-To: <513a3b305052909433f8d4ec9@mail.gmail.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> Message-ID: <429B3908.8060307@research.att.com> Didier Casse wrote: >Hi all, > I would like to have a review on the Enlightenment DR17 package >+ the accompanying Enlightenment Foundation Library packages (EFL). > > Success! I'm now running E from src.rpms on x64_64. John From elprodigio at gmail.com Mon May 30 16:13:41 2005 From: elprodigio at gmail.com (Didier Casse) Date: Tue, 31 May 2005 00:13:41 +0800 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <429B17BC.8010803@research.att.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429AA926.4060601@research.att.com> <513a3b305053002374eb23441@mail.gmail.com> <429B17BC.8010803@research.att.com> Message-ID: <513a3b30505300913617c6a53@mail.gmail.com> Hi John, Thanks for the patches. I will forward them to the enlightenment-devel list. We would benefit from somebody like you who has a x86_64 plus on top of that experience in these things. You could probably join the e-devel list and contribute to patches (if you do not want to join the e-dev team!) which would help fixing problems in the x86_64 regime. -- Cheers, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. On 5/30/05, John Ellson wrote: > Didier Casse wrote: > > >On 5/30/05, John Ellson wrote: > > > > > >>Didier Casse wrote: > >> > >> > >> > >>>Hi all, > >>> I would like to have a review on the Enlightenment DR17 package > >>>+ the accompanying Enlightenment Foundation Library packages (EFL). > >>> > >>> > >>> > >>> > >>Entrance fails to find -lX11 on x86_64. Should be -L/usr/X11R6/lib64 > >>I think the problem is that @X_LIBS@ is not being used from > >>AC_PATH_XTRA in configure.in > >> > >>/usr/bin/gcc -g -O2 -Wall -o entranced auth.o ipc.o md5.o spawner.o > >>util.o -L/usr/X11R6/lib -lX11 -lXext -lXau -L/usr/lib64 -lecore > >>-lecore_job -lecore_x -lecore_evas -lecore_con -lecore_ipc -lecore_txt > >>-lecore_fb -lecore_config -lecore_file -L/usr/lib64 -leet -lz -ljpeg -lm > >>-L/usr/lib64 -ledb -lz -lpam -lcrypt > >>/usr/bin/ld: cannot find -lX11 > >> > >> > > > >--x-libraries={_prefix}/X11R6/{_lib} should be able to fix this. ;-) > > > > > > > No, that didn't work. > > I think the following two changes are needed: > > > --- configure.in.old 2005-05-07 02:01:12.000000000 -0400 > +++ configure.in 2005-05-30 09:25:36.000000000 -0400 > @@ -199,10 +199,7 @@ > AC_DEFINE_UNQUOTED(ENTRANCE_XSESSION, "$xsession", [Xsession script]) > AC_SUBST(xsession) > > -x_cflags="-I/usr/X11R6/include" > -x_libs="-L/usr/X11R6/lib -lX11 -lXext" > -AC_SUBST(x_cflags) > -AC_SUBST(x_libs) > +AC_PATH_XTRA > > EDJE_DEF="" > AC_SUBST(EDJE_DEF) > > > --- src/daemon/Makefile.am.old 2005-05-30 09:26:39.000000000 -0400 > +++ src/daemon/Makefile.am 2005-05-30 09:20:37.000000000 -0400 > @@ -1,6 +1,6 @@ > ## Process this file with automake to produce Makefile.in > > -INCLUDES = @x_cflags@ @ecore_cflags@ @edb_cflags@ > +INCLUDES = @X_CFLAGS@ @ecore_cflags@ @edb_cflags@ > > sbin_PROGRAMS = entranced > bin_SCRIPTS = entrance_wrapper > @@ -8,4 +8,4 @@ > entranced_SOURCES = \ > auth.c auth.h Entranced.h ipc.c ipc.h md5.c md5.h spawner.c > util.c util.h > > -entranced_LDADD = @x_libs@ -lXau @ecore_libs@ @edb_libs@ > +entranced_LDADD = @X_LIBS@ -lX11 -lXext -lXau @ecore_libs@ @edb_libs@ > > From elprodigio at gmail.com Mon May 30 16:19:01 2005 From: elprodigio at gmail.com (Didier Casse) Date: Tue, 31 May 2005 00:19:01 +0800 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <429B284B.7000700@research.att.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429AA2C2.60300@research.att.com> <513a3b305052922525e6b7416@mail.gmail.com> <429B284B.7000700@research.att.com> Message-ID: <513a3b305053009194bcefa01@mail.gmail.com> On 5/30/05, John Ellson wrote: > Didier Casse wrote: > > >On 5/30/05, John Ellson wrote: > > > > > >>Didier Casse wrote: > >> > >> > >> > >>>Hi all, > >>> I would like to have a review on the Enlightenment DR17 package > >>>+ the accompanying Enlightenment Foundation Library packages (EFL). > >>> > >>> > >>> > >>> > >>Dependency problem: > >> > >> $ rpmbuild -ba emotion.spec > >> error: Failed build dependencies: > >> xine-lib-devel is needed by > >>emotion-0.0.1.003-1.20050530.e17.fc3.x86_64 > >> > >>xine-lib-devel is not provided by Fedora-Core or Fedora-Extras. > >> > >> > > > >arrgggh :-( > > > >This is not a problem if you want to install enlightenment. It doesn't > >really need emotion. But goodies like > > > >eclair --- EFL powered media player > >engage --- Cool docker that resembles OSX in some ways > >e_utils --- Utilities: e17setroot/emblem/entangle/e_util_app_edit > >(Well these ones can be a necessity!) > > > >and things like > > > >ewl --- Widget library > >examine--- config interface > > > >cannot be installed. Is there a possibility that somebody maintains > >xine in FC extras? > > > > > > > > > There are additional depencies as well, but xine itself isn't required. > I was able to continue testing E by installing the following from DAG's > repository: > > aalib-1.4.0-5.dag.src.rpm > libfame-0.9.1-6.rf.src.rpm > xine-lib-1.0.1-2.rf.src.rpm > Yes the whole xine is not required. BuildRequires /usr/bin/xine-config (to bemore precise!) which is provided by xine-lib-devel package. The above libs of course are required by xine-lib and indirectly required by emotion. :-) -- Cheers, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. From bugs.michael at gmx.net Mon May 30 16:26:27 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 30 May 2005 18:26:27 +0200 Subject: Approval Require for kyum [was Re: New Package: kyum] In-Reply-To: <0MKwh2-1DclhL0s6t-0004SA@mrelayeu.kundenserver.de> References: <0ML29c-1DXlu92LpI-0000e3@mrelayeu.kundenserver.de> <4289F654.7090907@city-fan.org> <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> <20050517223520.4de6bc8f.bugs.michael@gmx.net> <0MKwpI-1DYS2e3SIz-0002kY@mrelayeu.kundenserver.de> <20050518200636.020b57d3.bugs.michael@gmx.net> <0MKxQS-1DZwMf0AiV-0004pm@mrelayeu.kundenserver.de> <20050522222811.07231021.bugs.michael@gmx.net> <0MKwh2-1DaErA2CsL-0002gs@mrelayeu.kundenserver.de> <0MKwh2-1DclhL0s6t-0004SA@mrelayeu.kundenserver.de> Message-ID: <20050530182627.22cf47f9.bugs.michael@gmx.net> On Mon, 30 May 2005 16:56:46 +0200, Jochen Schmitt wrote: > I resent this message with a change subject, becous I didn't get > any respone for it. > > It will be nice, if anyone - aspecialy Michael Schwendt - can > approval my package. Sorry, but you need to add yourself to bug #159090. From bugs.michael at gmx.net Mon May 30 16:26:33 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 30 May 2005 18:26:33 +0200 Subject: Fedora Extras: packages with EVR upgrade problems Message-ID: <20050530182633.284959cc.bugs.michael@gmx.net> CVS based %epoch:%version-%release (EVR) comparison. EVR of packages for Fedora Extras Development should be higher than packages for Fedora Extras FC3. The following packages violate this upgrade path: galeon 0:1.3.21-2.fc3 in FC-3 branch is newer than devel gpredict 0:0.5.1-1 in FC-3 branch is newer than devel inadyn 0:1.90-11.fc3 in FC-3 branch is newer than devel c-ares 0:1.2.1-2 in FC-3 branch is equal to devel flumotion 0:0.1.8-1 in FC-3 branch is equal to devel ghc 0:6.4-8 in FC-3 branch is equal to devel iozone 0:3-1 in FC-3 branch is equal to devel From ville.skytta at iki.fi Mon May 30 16:27:00 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 30 May 2005 19:27:00 +0300 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <429B284B.7000700@research.att.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429AA2C2.60300@research.att.com> <513a3b305052922525e6b7416@mail.gmail.com> <429B284B.7000700@research.att.com> Message-ID: <1117470420.4633.60.camel@bobcat.mine.nu> On Mon, 2005-05-30 at 10:50 -0400, John Ellson wrote: > Didier Casse wrote: > > >cannot be installed. Is there a possibility that somebody maintains > >xine in FC extras? > > > There are additional depencies as well, but xine itself isn't required. > I was able to continue testing E by installing the following from DAG's > repository: > > aalib-1.4.0-5.dag.src.rpm > libfame-0.9.1-6.rf.src.rpm > xine-lib-1.0.1-2.rf.src.rpm aalib is in Extras, libfame and xine-lib are not, and most likely will not be due to legal/patent issues (don't ask me). You can grab the latter two also at rpm.livna.org, but packages containing dependencies to things not in FC or Extras cannot enter the Extras repository. From andres at baravalle.it Mon May 30 16:35:18 2005 From: andres at baravalle.it (Andres Baravalle) Date: Mon, 30 May 2005 17:35:18 +0100 Subject: Request for review: phpGrabComics Message-ID: <429B40C6.9060407@baravalle.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I would like to have a review on the phpGrabComics package (I'm the author of the program). phpGrabComics home page: http://www.baravalle.it/phpGrabComics/ src.rpm url: http://osdn.dl.sourceforge.net/sourceforge/phpgrabcomics/phpgrabcomics-1.5.1-1.src.rpm Summary: GNU phpGrabComics - grabs and saves comic strips from the web Description: GNU phpGrabComics is a software program to grab and save comic strips from the web. It supports several sites, such as Dilbert, Calvin and Hobbes, Snoopy and Il Manifesto. Thanks in advance, Andres ____________ Andres Baravalle http://www.baravalle.it ____________ Gli uomini d'azione sono poco pratici. La stessa azione li allontana dalla loro meta. Paco Ignacio Taibo I -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCm0DFysFWZEikY0oRAvFcAJ49r6ormbI2MZ9Byp5Kmuo8qjxw0QCfeCHw SSFA1u4QR+0hK/Rb3zj4LBM= =V4M+ -----END PGP SIGNATURE----- From Nicolas.Mailhot at laPoste.net Mon May 30 17:19:07 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 30 May 2005 19:19:07 +0200 Subject: Imlib2 (was: Re: Request for review: Enlightenment DR17 + EFL) In-Reply-To: <20050530112107.7d3e3078.bugs.michael@gmx.net> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050530042133.7e41e0c3.bugs.michael@gmx.net> <513a3b305052919312e5998e0@mail.gmail.com> <20050530053258.1df99559.bugs.michael@gmx.net> <48348.192.54.193.37.1117439002.squirrel@rousalka.dyndns.org> <20050530112107.7d3e3078.bugs.michael@gmx.net> Message-ID: <1117473547.4985.3.camel@rousalka.dyndns.org> Le lundi 30 mai 2005 ? 11:21 +0200, Michael Schwendt a ?crit : > On Mon, 30 May 2005 09:43:22 +0200 (CEST), Nicolas Mailhot wrote: > > > > On Mon, 30 May 2005 10:31:05 +0800, Didier Casse wrote: > > > > >> The principle of splitting is not to download the whole thing. What do > > >> you propose as an alternative? > > > > Have a package with the core loaders and one or several for rarely used > > loaders. Add a virtual per loader and use it in other specs. Move loaders > > from optional to core as the actual use changes. > > Would that be worthwhile? Effectively, you would need to revisit all > dependencies regularly, as whether they add/remove usage of more loaders > or filters, and then flip the virtual dependencies accordingly. If the loader packages are really complex this is a good way to isolate its changes from the rest of the system. Now that's a compromise like everyone else - I just wanted to point out you had alternatives other than "a package per loader" or "a package for all the loaders" Regards,, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Nicolas.Mailhot at laPoste.net Mon May 30 17:26:37 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 30 May 2005 19:26:37 +0200 Subject: Fedora Extras: missing bugzilla components In-Reply-To: <20050530153515.48f1e6e2@nausicaa.camperquake.de> References: <20050530133508.6f569b5e.bugs.michael@gmx.net> <20050530153515.48f1e6e2@nausicaa.camperquake.de> Message-ID: <1117474002.4985.5.camel@rousalka.dyndns.org> Le lundi 30 mai 2005 ? 15:35 +0200, Ralf Ertzinger a ?crit : > Hi. > > Michael Schwendt wrote: > > > What do you need to do? See if your package is on this list and if it is > > approved, request addition of a bugzilla component entry on this Wiki > > page: http://fedoraproject.org/wiki/Extras/BugzillaAdmin > > I will need edit rights for that page. > > ID: 1110551931.36.46387 > Name: RalfErtzinger Same here Name: NicolasMailhot -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Mon May 30 17:34:19 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 30 May 2005 19:34:19 +0200 Subject: Fedora Extras: missing bugzilla components In-Reply-To: <1117474002.4985.5.camel@rousalka.dyndns.org> References: <20050530133508.6f569b5e.bugs.michael@gmx.net> <20050530153515.48f1e6e2@nausicaa.camperquake.de> <1117474002.4985.5.camel@rousalka.dyndns.org> Message-ID: <20050530193419.19695a02.bugs.michael@gmx.net> On Mon, 30 May 2005 19:26:37 +0200, Nicolas Mailhot wrote: > Le lundi 30 mai 2005 ? 15:35 +0200, Ralf Ertzinger a ?crit : > > Hi. > > > > Michael Schwendt wrote: > > > > > What do you need to do? See if your package is on this list and if it is > > > approved, request addition of a bugzilla component entry on this Wiki > > > page: http://fedoraproject.org/wiki/Extras/BugzillaAdmin > > > > I will need edit rights for that page. > > > > ID: 1110551931.36.46387 > > Name: RalfErtzinger > > Same here > > Name: NicolasMailhot Done. From Jochen at herr-schmitt.de Mon May 30 18:15:05 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 30 May 2005 20:15:05 +0200 Subject: Approval Require for kyum [was Re: New Package: kyum] In-Reply-To: <20050530182627.22cf47f9.bugs.michael@gmx.net> References: <4289F654.7090907@city-fan.org> <0ML21M-1DY4Cn1T4J-0005lf@mrelayeu.kundenserver.de> <20050517223520.4de6bc8f.bugs.michael@gmx.net> <0MKwpI-1DYS2e3SIz-0002kY@mrelayeu.kundenserver.de> <20050518200636.020b57d3.bugs.michael@gmx.net> <0MKxQS-1DZwMf0AiV-0004pm@mrelayeu.kundenserver.de> <20050522222811.07231021.bugs.michael@gmx.net> <0MKwh2-1DaErA2CsL-0002gs@mrelayeu.kundenserver.de> <0MKwh2-1DclhL0s6t-0004SA@mrelayeu.kundenserver.de> <20050530182627.22cf47f9.bugs.michael@gmx.net> Message-ID: <0ML25U-1DconC2lGm-0001vj@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 30 May 2005 18:26:27 +0200, you wrote: >Sorry, but you need to add yourself to bug #159090. Thank you for your notification. I had an older version of gamin installed on my system. with the version the build works fine. But after I have updated to the most current version, I had the same problems which are described in the bug report. So I checked out a copy of gamin from the cvs. After I modified the SPEC file in a way, that the *.la will not be deleted. With the new built version of gamin, the build of kyum works fine. So I have wrote a comment to the bugzilla bug report. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.0 (Build 2001) iQA/AwUBQptYM09gByurcX4MEQJqHwCguUWqDoqLolhL6Os0KpuO+lLSNKAAn2Va 5tLWNGC+mmHb5bQQ24yC9mAS =cUFb -----END PGP SIGNATURE----- From buildsys at fedoraproject.org Mon May 30 21:13:17 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 30 May 2005 17:13:17 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050530211317.2E15880F8@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 13 bochs-2.2-2 centericq-4.20.0-10 centericq-4.20.0-9 dosbox-0.63-5 dosbox-0.63-6 flim-1.14.7-3 kakasi-2.3.4-20 mew-4.2-1 namazu-2.0.14-3 perl-Text-Kakasi-2.04-1 sylpheed-claws-1.9.11-1 vpnc-0.3.3-2 w3m-el-1.4.4-1 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From a.kurtz at hardsun.net Mon May 30 21:29:31 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Mon, 30 May 2005 14:29:31 -0700 Subject: Request for review: latex-prosper In-Reply-To: <1117423940.6112.61.camel@laptop.mpeters.local> References: <1117414576.6112.52.camel@laptop.mpeters.local> <513a3b30505291939dc0cd89@mail.gmail.com> <1117423940.6112.61.camel@laptop.mpeters.local> Message-ID: <1117488571.30905.7.camel@rydia.hardsun.net> On Sun, 2005-05-29 at 20:32 -0700, Michael A. Peters wrote: > On Mon, 2005-05-30 at 10:39 +0800, Didier Casse wrote: > > On 5/30/05, Michael A. Peters wrote: > > > http://mpeters.us/fc_extras/latex-prosper.spec > > > http://mpeters.us/fc_extras/latex-prosper-1.00.4-0.1.src.rpm > > > > > > This is the prosper class for latex > > > > Dear Michael, > > This is a nice tool. ;-) > > > > I think for your Source0, it's better to write: > > > > http://umn.dl.sourceforge.net/sourceforge/prosper/prosper-%{name}-%{version}.tar.gz > > > > I agree - but it easier for testers to get the source to md5sum check > with upstream if macros aren't used in the source tag (IE they can cut > and paste into a wget) spectool is your friend. It's part of fedora-rpmdevtools. "spectool -g package.spec" will fill in the macros and download the package. Wiki says it's a matter of personal taste. -- Aaron Kurtz GPG Key ID: ED588CF2 From foolish at fedoraforum.org Mon May 30 22:11:04 2005 From: foolish at fedoraforum.org (Sindre Pedersen Bjordal) Date: Tue, 31 May 2005 00:11:04 +0200 Subject: Self-Introduction: Sindre Pedersen =?iso-8859-1?q?Bj=F8rdal?= Message-ID: <1117491064.2555.15.camel@localhost.localdomain> Full legal name: Sindre Pedersen Bj?rdal City, Country: Aalesund, Norway Status: Graduating from Spjelkavik upper secondary school in a week. Goals: I use Fedora as my desktop at home and there's some packages I would like to contribute and maintain, like the smeg menu editor and xchat-gnome. I would do QA on software I use. Historical Qualifications: I've been a community manager at FedoraForum.org for a while. Help out at fedorafaq.org as well. Fingerprint: pub 1024D/68C744ED 2004-04-19 Key fingerprint = 8900 372F 4F3F 49AF 6547 C1DA 2353 D9AE 68C7 44ED uid Sindre Pedersen Bj?rdal (Unofficial Fedora F.A.Q.) uid Sindre Pedersen Bj?rdal uid Sindre Pedersen Bj?rdal (Unofficial Fedora user support forum) sub 1024g/2340EB47 2004-04-19 -- Sindre Pedersen Bjordal www.fedoraforum.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mpeters at mac.com Mon May 30 23:06:22 2005 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 30 May 2005 16:06:22 -0700 Subject: Request for review: latex-prosper In-Reply-To: <1117488571.30905.7.camel@rydia.hardsun.net> References: <1117414576.6112.52.camel@laptop.mpeters.local> <513a3b30505291939dc0cd89@mail.gmail.com> <1117423940.6112.61.camel@laptop.mpeters.local> <1117488571.30905.7.camel@rydia.hardsun.net> Message-ID: <1117494382.4072.2.camel@laptop.mpeters.local> On Mon, 2005-05-30 at 14:29 -0700, Aaron Kurtz wrote: > > spectool is your friend. It's part of fedora-rpmdevtools. "spectool -g > package.spec" will fill in the macros and download the package. Wiki > says it's a matter of personal taste. > OK - then I will definitely change my spec files to use macros - it's aggravating when I change the version and forget to change the source - I got use to doing it the other way, and only started doing the source w/o macros when it was brought up that it was easier to testers to get the source w/o macros in the source line. Since that is not the case (at least currently), back to %{name}-%{version} it is :) From wtogami at redhat.com Tue May 31 00:58:21 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 30 May 2005 14:58:21 -1000 Subject: Fedora Extras: missing bugzilla components In-Reply-To: <20050530133508.6f569b5e.bugs.michael@gmx.net> References: <20050530133508.6f569b5e.bugs.michael@gmx.net> Message-ID: <429BB6AD.8070008@redhat.com> http://fedoraproject.org/wiki/Extras/BugzillaAdmin I am adding these to Bugzilla. Please edit this page to add corrections. GiNaC C++ library for symbolic calculation qspencer at ieee.org Maelstrom A space combat game. extras-orphan at fedoraproject.org SIMVoleon Volume rendering library for Coin redhat-bugzilla at camperquake.de balsa Balsa Mail Client adrian at lisas.de cdlabelgen Generates frontcards and traycards for inserting in CD jewelcases. harald at redhat.com cln Class Library for Numbers qspencer at ieee.org cvsup CVS-Optimized General-Purpose Network File Distribution System client adrian at lisas.de enchant An Enchanting Spell Checking Library adrian at lisas.de enemies-of-carlotta A simple mailing list manager redhat-bugzilla at camperquake.de exim-doc Documentation for the exim mail transfer agent dwmw2 at redhat.com exim The exim mail transfer agent dwmw2 at redhat.com flumotion Flumotion - the Fluendo Streaming Server thomas at apestaart.org fping Scriptable, parallelized ping-like utility kaboom at oobleck.net freenx freenx application/thin-client server zipsonic at gmail.com gnuchess The GNU chess program kaboom at oobleck.net hula A calendar and mail server NO BUGZILLA ADDRESS kile-i18n i18n support for Kile extras-orphan at fedoraproject.org lapack The LAPACK libraries for numerical linear algebra. tcallawa at redhat.com milter-greylist Milter for greylisting, the next step in the spam control war enrico.scholz at informatik.tu-chemnitz.de mod_security Security module for the Apache HTTP Server mfleming+rpm at enlartenment.com moin MoinMoin is a Python clone of WikiWiki matthias at rpmforge.net Nabi Simple Hangul X Input Method djoo at redhat.com nx Proxy system for X11 zipsonic at gmail.com octave-forge Contributed functions for octave qspencer at ieee.org ots A text summarizer extras-orphan at fedoraproject.org rzip A large-file compression program i at stingr.net syslog-ng Syslog replacement daemon jpo at di.uminho.pt tdl To-do list manager extras-orphan at fedoraproject.org util-vserver Linux virtual server utilities enrico.scholz at informatik.tu-chemnitz.de w3m-el W3m interface for Emacs tagoh at redhat.com xdaliclock A clock for the X Window System kaboom at oobleck.net From foolish at fedoraforum.org Tue May 31 01:38:26 2005 From: foolish at fedoraforum.org (Sindre Pedersen Bjordal) Date: Tue, 31 May 2005 03:38:26 +0200 Subject: Request for review: smeg (Simple menu editor gnome) & pyxdg Message-ID: <1117503506.16959.10.camel@localhost.localdomain> http://foolish.digitalinc.info/pakker/SRPMS/smeg.spec http://foolish.digitalinc.info/pakker/SRPMS/smeg-0.7-1.src.rpm http://foolish.digitalinc.info/pakker/SRPMS/pyxdg.spec http://foolish.digitalinc.info/pakker/SRPMS/pyxdg-0.12-1.src.rpm This is the smeg menu editor for gnome. This allows the user to edit the menu, add new menus and entries through a simple interface. A menu editor is one of the most requested features amongst the fedoraforum.org crowd. Smeg depends on pyxdg, a python library to access freedesktop.org standards. Used Rudolfs spec for this from Newrpms and adapted it to the fedora template. -- Sindre Pedersen Bjordal www.fedoraforum.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tagoh at redhat.com Tue May 31 03:14:13 2005 From: tagoh at redhat.com (Akira TAGOH) Date: Tue, 31 May 2005 12:14:13 +0900 (JST) Subject: Fedora Extras: missing bugzilla components In-Reply-To: <20050530133508.6f569b5e.bugs.michael@gmx.net> References: <20050530133508.6f569b5e.bugs.michael@gmx.net> Message-ID: <20050531.121413.3580252863594990515.tagoh@redhat.com> >>>>> On Mon, 30 May 2005 13:35:08 +0200, >>>>> "MS" == Michael Schwendt wrote: MS> An increasing number of packages do not have a component entry in bugzilla! MS> What do you need to do? See if your package is on this list and if it is MS> approved, request addition of a bugzilla component entry on this Wiki page: MS> http://fedoraproject.org/wiki/Extras/BugzillaAdmin MS> Offer: reply off-list and state package name(s) and bugzilla account e-mail MS> address, and I request creation of the bugzilla component(s). [snip] MS> w3m-el I thought I added it into wiki. but I seem to forgot to do it :) done. -- Akira TAGOH From buildsys at fedoraproject.org Tue May 31 05:13:39 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 31 May 2005 01:13:39 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050531051339.B4605810E@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 1 viruskiller-0.9-5 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 May 31 06:13:22 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 31 May 2005 09:13:22 +0300 Subject: Fedora Extras: missing bugzilla components In-Reply-To: <429BB6AD.8070008@redhat.com> References: <20050530133508.6f569b5e.bugs.michael@gmx.net> <429BB6AD.8070008@redhat.com> Message-ID: <1117520002.4633.102.camel@bobcat.mine.nu> On Mon, 2005-05-30 at 14:58 -1000, Warren Togami wrote: > extras-orphan at fedoraproject.org Is this address actually delivered somewhere? From wtogami at redhat.com Tue May 31 08:34:05 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 30 May 2005 22:34:05 -1000 Subject: Fedora Extras: missing bugzilla components In-Reply-To: <1117520002.4633.102.camel@bobcat.mine.nu> References: <20050530133508.6f569b5e.bugs.michael@gmx.net> <429BB6AD.8070008@redhat.com> <1117520002.4633.102.camel@bobcat.mine.nu> Message-ID: <429C217D.5090102@redhat.com> Ville Skytt? wrote: > On Mon, 2005-05-30 at 14:58 -1000, Warren Togami wrote: > > >>extras-orphan at fedoraproject.org > > > Is this address actually delivered somewhere? > We haven't come to a decision on that yet, but I think it would be best to have it go into /dev/null, and anybody can set a Bugzilla watch on it if they want to see it. That way they receive mail, but no duplicates that would happen with a list. Warren Togami wtogami at redhat.com From bugs.michael at gmx.net Tue May 31 09:27:43 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 31 May 2005 11:27:43 +0200 Subject: Fedora Extras: missing bugzilla components In-Reply-To: <429BB6AD.8070008@redhat.com> References: <20050530133508.6f569b5e.bugs.michael@gmx.net> <429BB6AD.8070008@redhat.com> Message-ID: <20050531112743.3a72814d.bugs.michael@gmx.net> On Mon, 30 May 2005 14:58:21 -1000, Warren Togami wrote: > http://fedoraproject.org/wiki/Extras/BugzillaAdmin > I am adding these to Bugzilla. Please edit this page to add corrections. > SIMVoleon > Volume rendering library for Coin > redhat-bugzilla at camperquake.de No. Correct entry has been submitted via the Wiki. > balsa > Balsa Mail Client > adrian at lisas.de No. Pawel Salek. Unknown address. > kile-i18n > i18n support for Kile > extras-orphan at fedoraproject.org No. Rex Dieter. No idea what his bugzilla account e-mail is. It's not possible anymore to look it up in the components list. It's only displayed in tickets. From rc040203 at freenet.de Tue May 31 09:36:33 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 31 May 2005 11:36:33 +0200 Subject: Fedora Extras: missing bugzilla components In-Reply-To: <20050531112743.3a72814d.bugs.michael@gmx.net> References: <20050530133508.6f569b5e.bugs.michael@gmx.net> <429BB6AD.8070008@redhat.com> <20050531112743.3a72814d.bugs.michael@gmx.net> Message-ID: <1117532193.12828.65.camel@mccallum.corsepiu.local> On Tue, 2005-05-31 at 11:27 +0200, Michael Schwendt wrote: > On Mon, 30 May 2005 14:58:21 -1000, Warren Togami wrote: > > > http://fedoraproject.org/wiki/Extras/BugzillaAdmin > > I am adding these to Bugzilla. Please edit this page to add corrections. > > > SIMVoleon > > Volume rendering library for Coin > > redhat-bugzilla at camperquake.de > > No. Correct entry has been submitted via the Wiki. I already complained to Warren on PM. I had been using email address in the Wiki which had no corresponding bugzilla account, and either the script Warren might have used screwed up in this case or he did. Why this amateurish Wiki? Why aren't packages automatically assigned to persons as part of the package "approval process" and bugzilla accounts automatically created as part of this process? Ralf From ivazquez at ivazquez.net Tue May 31 04:54:37 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 31 May 2005 00:54:37 -0400 Subject: Fedora Extras: packages with EVR upgrade problems In-Reply-To: <20050530182633.284959cc.bugs.michael@gmx.net> References: <20050530182633.284959cc.bugs.michael@gmx.net> Message-ID: <1117515277.6931.1.camel@ignacio.ignacio.lan> On Mon, 2005-05-30 at 18:26 +0200, Michael Schwendt wrote: > gpredict 0:0.5.1-1 in FC-3 branch is newer than devel gpredict currently won't even build in devel due to the lack of gnome- vfs. Before you ask, no, I am not interested in becoming its maintainer. I have put in a request upstream for gpredict to be updated to GTK+ 2.x, so we (or more properly, I) will have to see where that leads. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mpeters at mac.com Tue May 31 10:34:34 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 31 May 2005 03:34:34 -0700 Subject: Request for Review: sword Message-ID: <1117535674.4072.27.camel@laptop.mpeters.local> http://mpeters.us/fc_extras/sword.spec http://mpeters.us/fc_extras/sword-1.5.8-0.1.src.rpm The sword project provides an api for bible study related software. Three (that I know of) front ends for Linux exist - gnomesword (gnome), bibletime (kde), and jsword (a java interface) modules for bible texts, commentaries, lexicons, and general books (IE complete works of josephus) are made available to the user through the front end that the user chooses. This spec file has been tested and builds on both x86 and ppc (in rawhide, will fc3 test tomorrow) For testers - I do not intend to package any of the modules, the front end clients allow you to download and install them in your home directory. I do however have a shell script (somewhat ugly) that generates rpm's from the raw .zip module files for global installation if anyone is interested. I will be submitting gnomesword shortly. I have no plans for packaging the other interfaces. I don't use KDE and java is ugly :p From mpeters at mac.com Tue May 31 10:53:41 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 31 May 2005 03:53:41 -0700 Subject: Request for Review: gnomesword Message-ID: <1117536821.4072.32.camel@laptop.mpeters.local> http://mpeters.us/fc_extras/gnomesword.spec http://mpeters.us/fc_extras/gnomesword-2.1.2-0.1.src.rpm This is a gnome-centric front end to the crosswire sword API. Depends upon sword package I just submitted for review. Builds and works on x86 and ppc in rawhide, have not tested on other platforms. Will test in fc3 tomorrow. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 31 14:27:55 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 31 May 2005 16:27:55 +0200 Subject: Request for review : php-pecl-pdo and php-pecl-pdo-sqlite Message-ID: <20050531162755.6019e306@python2> Hi, I've imported into the CVS devel branch the newer sqlite v3 compatible php module based on PDO. It will replace the current php-pecl-sqlite in functionality, but unfortunately _isn't_ a drop-in replacement as already discussed. Please feel free to review the packages :-) Also see : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156240 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.27_FC3 Load : 0.85 0.91 0.74 From katzj at redhat.com Tue May 31 14:30:45 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 31 May 2005 10:30:45 -0400 Subject: Fedora Extras: missing bugzilla components In-Reply-To: <1117532193.12828.65.camel@mccallum.corsepiu.local> References: <20050530133508.6f569b5e.bugs.michael@gmx.net> <429BB6AD.8070008@redhat.com> <20050531112743.3a72814d.bugs.michael@gmx.net> <1117532193.12828.65.camel@mccallum.corsepiu.local> Message-ID: <1117549845.3849.33.camel@bree.local.net> On Tue, 2005-05-31 at 11:36 +0200, Ralf Corsepius wrote: > Why this amateurish Wiki? > > Why aren't packages automatically assigned to persons as part of the > package "approval process" and bugzilla accounts automatically created > as part of this process? Because things like that require work and effort and there's only so much time. The plan is for the process to include that, but right now, the bits aren't there. If you'd like to help in implementing the code so this can happen, let me know (reply to me directly) and I'll get you in the loop for that. The same is true for other infrastructure related tasks around Fedora Extras. The Fedora Extras Steering Committee is doing what we can to move things along, but there are only so many hours in the day. Feel free to look at http://www.fedoraproject.org/wiki/FedoraExtrasSchedule (our current task list) and mail the owners of tasks if you're specifically interested in helping to move the task forward. Jeremy From tcallawa at redhat.com Tue May 31 14:47:43 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 31 May 2005 09:47:43 -0500 Subject: Fedora Extras: packages with EVR upgrade problems In-Reply-To: <20050530182633.284959cc.bugs.michael@gmx.net> References: <20050530182633.284959cc.bugs.michael@gmx.net> Message-ID: <1117550863.3991.41.camel@localhost.localdomain> On Mon, 2005-05-30 at 18:26 +0200, Michael Schwendt wrote: > CVS based %epoch:%version-%release (EVR) comparison. EVR of packages for > Fedora Extras Development should be higher than packages for Fedora Extras > FC3. The following packages violate this upgrade path: > c-ares 0:1.2.1-2 in FC-3 branch is equal to devel Fixed in cvs, new tags and builds requested. Thanks, ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From dag at wieers.com Tue May 31 14:52:26 2005 From: dag at wieers.com (Dag Wieers) Date: Tue, 31 May 2005 16:52:26 +0200 (CEST) Subject: New package: gaim-meanwhile In-Reply-To: <1116933896.18458.33.camel@yoda.jdub.homelinux.org> References: <1116933896.18458.33.camel@yoda.jdub.homelinux.org> Message-ID: On Tue, 24 May 2005, Josh Boyer wrote: > gaim-meanwhile: Lotus Sametime Community Client plugin for Gaim > > This is a Gaim plugin that uses the meanwhile library to allow users to > connect to a Sametime server with Gaim. > > Project URL: http://meanwhile.sourceforge.net > > SRPM URL: http://jdub.homelinux.org/files/gaim-meanwhile/ > > gaim-meanwhile requires the meanwhile package which was posted for > review earlier. You might want to know that gaim-meanwhile will be shipped as part of gaim starting from gaim 1.4. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From tcallawa at redhat.com Tue May 31 14:55:00 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 31 May 2005 09:55:00 -0500 Subject: Request for review: Enlightenment DR17 + EFL In-Reply-To: <513a3b3050529223560951b82@mail.gmail.com> References: <513a3b305052909433f8d4ec9@mail.gmail.com> <429A0664.3010505@research.att.com> <20050529185127.GC26225@ryoko.camperquake.de> <429A169F.7070403@research.att.com> <20050529192746.GD26225@ryoko.camperquake.de> <429A19A3.40604@research.att.com> <513a3b305052919103e75b08f@mail.gmail.com> <429A9150.1060101@research.att.com> <429A9A26.8000602@research.att.com> <513a3b3050529223560951b82@mail.gmail.com> Message-ID: <1117551300.3991.44.camel@localhost.localdomain> On Mon, 2005-05-30 at 13:35 +0800, Didier Casse wrote: > The solution, as discussed with Carsten, to avoid this in the future > would be to set: > > CFLAGS="-O2 -fomit-frame-pointer" > export CFLAGS > > in the spec file for a generic binary. Umm, lets not be so hasty to blast away the RPM_OPT_FLAGS. If you need -fomit-frame-pointer for a package, do this instead: CFLAGS="$RPM_OPT_FLAGS -fomit-frame-pointer" ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jwboyer at jdub.homelinux.org Tue May 31 17:31:32 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 31 May 2005 12:31:32 -0500 Subject: New package: gaim-meanwhile In-Reply-To: References: <1116933896.18458.33.camel@yoda.jdub.homelinux.org> Message-ID: <1117560693.3107.14.camel@yoda.jdub.homelinux.org> On Tue, 2005-05-31 at 16:52 +0200, Dag Wieers wrote: > You might want to know that gaim-meanwhile will be shipped as part of > gaim starting from gaim 1.4. Thanks for the tip. Although I have heard it was still undecided. At any rate, I'll have to watch this one closely. josh From qspencer at ieee.org Tue May 31 18:41:43 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Tue, 31 May 2005 13:41:43 -0500 Subject: Spec file questions Message-ID: <429CAFE7.6000802@ieee.org> I've been looking over the octave spec file (imported from core) because it looks like it could be cleaned up quite a bit, and I'm wondering about a couple of things: 1. The spec file has had for a very long time the following lines: %build LC_ALL=POSIX export LC_ALL CXXFLAGS="$RPM_OPT_FLAGS -fPIC -D_GNU_SOURCE" ./configure --lots-of-switches-here ... I'm not familiar with LC_ALL, but it appears to be locale-related. Grepping through the source, I see the following in config.guess: # Set LC_ALL=C to ensure ld outputs messages in English. ld_supported_targets=`cd /; LC_ALL=C ld --help 2>&1 \ ... This doesn't appear to be defined or used anywhere else in the source code. Does changing the definition have any effect at all? It looks to me like I can safely remove it. 2. The make install section of the spec file has the following strip $RPM_BUILD_ROOT/usr/libexec/octave/%{version}/oct/*/*.oct I remember hearing that RPM automatically strips executable code to form the "debuginfo" packages, so you don't normally have to do this. These files are precompiled modules that need to be stripped--is this done manually because RPM doesn't know that? 3. In a past review, I seem to recall someone saying that it's preferable to use %exclude rather than do "rm" commands in $RPM_BUILD_ROOT. What about doc files? Does "%exclude %doc path/to/files*" work? -Quentin From sopwith at redhat.com Tue May 31 18:51:04 2005 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 31 May 2005 14:51:04 -0400 (EDT) Subject: CVS branching is done Message-ID: I've created FC-4 branches for all the Fedora Extras packages, and for all the packages included in Fedora Core 4. For distro CVS, the devel branch is targetting FC5 now and the FC-4 branch needs to be used for all FC4 updates. For extras CVS, the devel branch is for packages on top of rawhide (FC5-to-be), and the FC-4 branch needs to be used for the FE4 release/updates. Best, -- Elliot From kaboom at oobleck.net Tue May 31 19:06:18 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 31 May 2005 15:06:18 -0400 (EDT) Subject: Fedora Extras: missing bugzilla components (fwd) Message-ID: resending to extras, since gmx.net blocks my emails.... later, chris ---------- Forwarded message ---------- Date: Tue, 31 May 2005 14:59:36 -0400 (EDT) From: Chris Ricker To: Michael Schwendt Subject: Re: Fedora Extras: missing bugzilla components On Mon, 30 May 2005, Michael Schwendt wrote: > gnuchess > xdaliclock I think I requested both of these through the Wiki when I imported them into Extras from Core. The requests eventually disappeared from the Wiki, but I'm not sure they ever transferred over to me It may be that bugzilla for these is special since they were in core for <= FC3? At any rate, my bugzilla is kaboom at oobleck.net if you can fix it thanks, chris From skvidal at phy.duke.edu Tue May 31 19:25:12 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 31 May 2005 15:25:12 -0400 Subject: Requesting builds Message-ID: <1117567512.18404.43.camel@cutter> Hey Folks, Please do not request builds right now. Thanks, also if you're not doing so read your fedora-maintainers mail. -sv From mpeters at mac.com Tue May 31 19:29:17 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 31 May 2005 12:29:17 -0700 Subject: package submission policy question Message-ID: <1117567758.4072.73.camel@laptop.mpeters.local> A private e-mail from a packager I highly respect expressed some concerns relating to two package I requested for review sword (and by extension gnomesword) The concern was two-fold: 1) the nature of the software could be seen as religious efforts/campaigns 2) the title of the software, sword, could invoke negative reactions from some people I would like these issues clarified with respect to Fedora Extra policy, as I am sure that as the Fedora community grows, other people will want to submit similar software. A little background - in Fedora Core 3, the previous version of sword and gnomesword did not work because the gnome libraries in core 3 were too new. On my private yum repository, I built two compatibility packages needed to allow gnomesword to build, and offered them for Fedora Core 3. The only package in my repository that got more downloads was my build of gstreamer-ffmpeg. There definitely is a demand for this software. Last week, a new stable version of sword and gnomesword were released, and compatibility libraries are no longer needed for gnomesword, hence my submission. Neither software package installs any biblical texts, those are to be installed by the user - typically in the users home directory, from a repository of modules that does respect the intellectual property rights of the copyright holders. Both projects are primarily developed by christians, and yes - I also am a christian, but the software is not useful only to the christian community. It is also useful to the scholarship community in general. There are modules for greek and hebrew and latin for those studying the texts in the old languages, as well as modules for general books - including the complete works of Josephus, quite useful to anyone studying 1st century palestine. None of the packages install any religious texts, they simply install the software needed to make use of texts that the user chooses to install. With respect to the name "sword" there is nothing I can do about that, that's the upstream name. It refers to the Bible as being the sword of truth, it is not used to indicate any kind of violent intentions. These packages are not suitable for rpm.livna.org, extras is imho the place for them. If there is to be a policy that excludes these kind of packages from extras, I would like it discussed and defined so that a repository similar to rpm.livna.org but for packages that can be perceived as religious/political could be set up such packages (of course not being particular to any one religion or philosophy or political viewpoint) It should be noted that sword and gnomesword (and I believe the kde interface bibletime) are in debian sarge (and I think woody) and are also in the mandrake equivalent of extras. I know they don't set fedora packaging policy, but to my knowledge, there have been no issues with the name sword and the nature of the software with those distributions. At any rate, I would like this clarified if possible. From bugs.michael at gmx.net Tue May 31 19:41:36 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 31 May 2005 21:41:36 +0200 Subject: Fedora Extras: missing bugzilla components (fwd) In-Reply-To: References: Message-ID: <20050531214136.075c2943.bugs.michael@gmx.net> On Tue, 31 May 2005 15:06:18 -0400 (EDT), Chris Ricker wrote: > resending to extras, since gmx.net blocks my emails.... > > later, > chris > > ---------- Forwarded message ---------- > Date: Tue, 31 May 2005 14:59:36 -0400 (EDT) > From: Chris Ricker > To: Michael Schwendt > Subject: Re: Fedora Extras: missing bugzilla components > > On Mon, 30 May 2005, Michael Schwendt wrote: > > > gnuchess > > xdaliclock > > I think I requested both of these through the Wiki when I imported them > into Extras from Core. The requests eventually disappeared from the Wiki, > but I'm not sure they ever transferred over to me You requested "xaliclock" according to the Wiki page change history. ;) > It may be that bugzilla for these is special since they were in core for > <= FC3? No. > At any rate, my bugzilla is kaboom at oobleck.net if you can fix it Warren has added gnuchess and xdaliclock meanwhile (see his reply in this thread). From mattdm at mattdm.org Tue May 31 19:41:33 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 31 May 2005 15:41:33 -0400 Subject: package submission policy question In-Reply-To: <1117567758.4072.73.camel@laptop.mpeters.local> References: <1117567758.4072.73.camel@laptop.mpeters.local> Message-ID: <20050531194133.GA7581@jadzia.bu.edu> On Tue, May 31, 2005 at 12:29:17PM -0700, Michael A. Peters wrote: > 1) the nature of the software could be seen as religious > efforts/campaigns Hey, we've already got ddate in util-linux. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From sopwith at redhat.com Tue May 31 19:44:11 2005 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 31 May 2005 15:44:11 -0400 (EDT) Subject: package submission policy question In-Reply-To: <1117567758.4072.73.camel@laptop.mpeters.local> References: <1117567758.4072.73.camel@laptop.mpeters.local> Message-ID: On Tue, 31 May 2005, Michael A. Peters wrote: > The concern was two-fold: > > 1) the nature of the software could be seen as religious > efforts/campaigns > > 2) the title of the software, sword, could invoke negative reactions > from some people $0.02 from me (with FESCO being the final word on things). I'm sure those perspectives are possible, but you gave a good explanation of why they aren't reasonable. Now that the issue has come up, someone will be offended no matter whether you include the packages or don't include them. Installing and using the packages is entirely optional, so it's not like people are being forced to read the books. Public opinion is a fickle thing that may wind up turning solidly against these packages, but for now I think it's best if Fedora package policies are limited to the technical and legal realms, while keeping general good taste of the majority in mind. Best, -- Elliot From buildsys at fedoraproject.org Tue May 31 20:19:54 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 31 May 2005 16:19:54 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050531201954.0C4378185@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 12 WindowMaker-0.91.0-2.fc4 c-ares-1.2.1-4 c-ares-1.2.1-4.fc4 dkms-2.0.5.2-4 dkms-2.0.5.2-4.fc4 ghc-6.4-1 ghc-6.4-1.fc4 inkscape-0.41-7 meanwhile-0.4.2-1 meanwhile-0.4.2-1.fc4 moodss-20.1-3 moodss-20.1-3.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From notting at redhat.com Tue May 31 20:52:07 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 31 May 2005 16:52:07 -0400 Subject: package submission policy question In-Reply-To: <1117567758.4072.73.camel@laptop.mpeters.local> References: <1117567758.4072.73.camel@laptop.mpeters.local> Message-ID: <20050531205207.GA5834@nostromo.devel.redhat.com> Michael A. Peters (mpeters at mac.com) said: > Neither software package installs any biblical texts, those are to be > installed by the user - typically in the users home directory, from a > repository of modules that does respect the intellectual property rights > of the copyright holders. I'd think the copyright on that would have lapsed into the public domain by now. Bill From mattdm at mattdm.org Tue May 31 21:20:05 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 31 May 2005 17:20:05 -0400 Subject: package submission policy question In-Reply-To: <20050531205207.GA5834@nostromo.devel.redhat.com> References: <1117567758.4072.73.camel@laptop.mpeters.local> <20050531205207.GA5834@nostromo.devel.redhat.com> Message-ID: <20050531212005.GA11772@jadzia.bu.edu> On Tue, May 31, 2005 at 04:52:07PM -0400, Bill Nottingham wrote: > > Neither software package installs any biblical texts, those are to be > > installed by the user - typically in the users home directory, from a > > repository of modules that does respect the intellectual property rights > > of the copyright holders. > I'd think the copyright on that would have lapsed into the > public domain by now. I'm not a lawyer, but probably various translations have their own copyrights. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From buildsys at fedoraproject.org Tue May 31 21:53:24 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 31 May 2005 17:53:24 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050531215324.9DBFD8185@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 13 WindowMaker-0.91.0-1 WindowMaker-0.91.0-2 WindowMaker-0.91.0-2.fc3 c-ares-1.2.1-4 c-ares-1.2.1-4.fc3 dkms-2.0.5.2-4 dkms-2.0.5.2-4.fc3 ghc-6.4-1 ghc-6.4-1.fc3 meanwhile-0.4.2-1 meanwhile-0.4.2-1.fc3 netcdf-3.6.0-3.p1 netcdf-3.6.0-3.p1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From skvidal at phy.duke.edu Tue May 31 22:01:02 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 31 May 2005 18:01:02 -0400 Subject: Fedora Extras 4/Fedora Extras Development Message-ID: <1117576862.18404.62.camel@cutter> Ok Folks, The Extras 4 tree has been made and development is now for builds for to-be-FC5 in the buildsystem. I wonder what will break. :) -sv From notting at redhat.com Tue May 31 22:21:05 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 31 May 2005 18:21:05 -0400 Subject: package submission policy question In-Reply-To: <20050531212005.GA11772@jadzia.bu.edu> References: <1117567758.4072.73.camel@laptop.mpeters.local> <20050531205207.GA5834@nostromo.devel.redhat.com> <20050531212005.GA11772@jadzia.bu.edu> Message-ID: <20050531222105.GA7811@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > > > Neither software package installs any biblical texts, those are to be > > > installed by the user - typically in the users home directory, from a > > > repository of modules that does respect the intellectual property rights > > > of the copyright holders. > > I'd think the copyright on that would have lapsed into the > > public domain by now. > > I'm not a lawyer, but probably various translations have their own > copyrights. Ah, but were the copyrights assigned to the original translators, the compilers of the translations, or to King James himself? Bill From mpeters at mac.com Tue May 31 21:31:28 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 31 May 2005 14:31:28 -0700 Subject: package submission policy question In-Reply-To: <20050531205207.GA5834@nostromo.devel.redhat.com> References: <1117567758.4072.73.camel@laptop.mpeters.local> <20050531205207.GA5834@nostromo.devel.redhat.com> Message-ID: <1117575089.3357.10.camel@laptop.mpeters.local> On Tue, 2005-05-31 at 16:52 -0400, Bill Nottingham wrote: > Michael A. Peters (mpeters at mac.com) said: > > Neither software package installs any biblical texts, those are to be > > installed by the user - typically in the users home directory, from a > > repository of modules that does respect the intellectual property rights > > of the copyright holders. > > I'd think the copyright on that would have lapsed into the > public domain by now. It's funny. Old greek new testaments like Tisch are public domain, as they existed before 1911 (or whatever the date is). But the current greek new testament - which is suppose to closer to what the texts originally said - is not public domain, despite the vast majority of it being verbatim from manuscripts they have found (in fact I suspect all of it, just not all from the same manuscript) They do enforce their copyright - it's apparently very expensive to do (the scholarship to determine letter for letter what the original text most likely looked like) Modern translations are considered new works for purposes of copyright, and I guess original versions that are deduced rather than found are as well. It may be an exception because of the amount of work required to produce it. The differences between tisch and what is supposedly modern are actually quite minor, but :shrug: