From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 1 14:32:45 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 1 Feb 2005 15:32:45 +0100 Subject: New game : Fish Fillets - Next Generation Message-ID: <20050201153245.51d0a395@python2> Hi, Regarding this package request for the Fish Fillets game : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145202 I went over Michal Ambroz's spec file, split out the noarch stuff, cleaned up things here and there and imported into CVS these 3 new packages : fillets-ng fillets-ng-data fillets-ng-data-cs The game works fine for me, I see no more obvious mistakes or forgotten things in the specs, so I'll request an initial build to Seth shortly, after getting at least a bit more feedback. From here on, I can maintain the changes to the package until the day Michal has CVS access to do it himself. Comments and remarks welcome. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3 Load : 0.13 0.17 0.30 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 1 15:14:50 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 1 Feb 2005 16:14:50 +0100 Subject: Updating packages? Message-ID: <20050201161450.1615434d@python2> Hi, After looking at this new bug (dated mid-December) : https://bugzilla.redhat.com/beta/show_bug.cgi?id=143177 I was wondering what the general consensus about updating packages currently was. In this particular case, lua being updated to 5.0.0 to 5.0.2, it seems like an important and win-win situation since all packages that link against lua do so statically, thus the earlier it gets updated to this bugfix release, the better. I know Panu is a bit busy and less involved in apt/Fedora/etc. lately, so I was wondering if this kind of update could take place without him or not, and if so, who would decide and who would do it. My personal opinion is that Extras is currently in a Rawhide type of state, thus this could/should be done, and eventual bugs would get ironed out later on during a freeze (FC4's for instance), or through package updates post-release. I know this differs a lot from the fedora.us "review, review, review, test, test, test" (and sometimes "give up, abandon" :-() process, but is what has always been done with Rewhide/Development. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3 Load : 1.26 1.33 1.07 From pmatilai at welho.com Tue Feb 1 16:11:21 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 1 Feb 2005 18:11:21 +0200 (EET) Subject: Updating packages? In-Reply-To: <20050201161450.1615434d@python2> References: <20050201161450.1615434d@python2> Message-ID: On Tue, 1 Feb 2005, Matthias Saou wrote: > Hi, > > After looking at this new bug (dated mid-December) : > https://bugzilla.redhat.com/beta/show_bug.cgi?id=143177 Oops, I've somehow managed to completely miss that bug :-/ > > I was wondering what the general consensus about updating packages > currently was. In this particular case, lua being updated to 5.0.0 to > 5.0.2, it seems like an important and win-win situation since all packages > that link against lua do so statically, thus the earlier it gets updated to > this bugfix release, the better. > > I know Panu is a bit busy and less involved in apt/Fedora/etc. lately, so I > was wondering if this kind of update could take place without him or not, > and if so, who would decide and who would do it. Updating it would only make sense, and here's the updated package: http://fedora.laiskiainen.org/SRPMS.extras/lua-5.0.2-1.src.rpm ..but for that to make it to Extras somebody needs to do the importing since I still don't have CVS access. - Panu - From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 1 16:13:29 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 1 Feb 2005 17:13:29 +0100 Subject: Updating packages? In-Reply-To: References: <20050201161450.1615434d@python2> Message-ID: <20050201171329.557b00f0@python2> Panu Matilainen wrote : > Updating it would only make sense, and here's the updated package: > http://fedora.laiskiainen.org/SRPMS.extras/lua-5.0.2-1.src.rpm > ..but for that to make it to Extras somebody needs to do the importing > since I still don't have CVS access. I'll do that for you right now, no problem :-) Thanks for the quick update! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3 Load : 0.31 0.37 0.49 From mattdm at mattdm.org Tue Feb 1 16:35:43 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 1 Feb 2005 11:35:43 -0500 Subject: Fedora Extras Package Updates In-Reply-To: <1107201422.30076.36.camel@opus.phy.duke.edu> References: <1107201422.30076.36.camel@opus.phy.duke.edu> Message-ID: <20050201163543.GA2837@jadzia.bu.edu> On Mon, Jan 31, 2005 at 02:57:02PM -0500, seth vidal wrote: > Hi Everyone, Seth, you are seriously goin' to down with this stuff. Thanks! -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From skvidal at phy.duke.edu Tue Feb 1 16:51:38 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 01 Feb 2005 11:51:38 -0500 Subject: Fedora Extras Package Updates In-Reply-To: <20050201163543.GA2837@jadzia.bu.edu> References: <1107201422.30076.36.camel@opus.phy.duke.edu> <20050201163543.GA2837@jadzia.bu.edu> Message-ID: <1107276698.25100.100.camel@cutter> On Tue, 2005-02-01 at 11:35 -0500, Matthew Miller wrote: > On Mon, Jan 31, 2005 at 02:57:02PM -0500, seth vidal wrote: > > Hi Everyone, > > Seth, you are seriously goin' to down with this stuff. Thanks! I'm not doing much of anything. The people who make the packages do all the work. I just rebuild and post the stuff. People to thank: Ville Skytt? Matthias Saou Warren Togami Michael Schwendt Jeremy Katz Phillip Compton I'm sure I've forgotten some other folks who are checking in packages. I just offered to build and host them in reasonably sane build environments. These guys deserve the credit. -sv From skvidal at fedoraproject.org Tue Feb 1 19:32:02 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 01 Feb 2005 14:32:02 -0500 Subject: rsync'ing sites heads up! Message-ID: <1107286322.25100.117.camel@cutter> Hey folks, In order to migrate from pre-extras to extras we need to shuffle the dir hierarchy a bit. This will probably mean that for those people who are using rysnc mirrors that everything will shift around and you'll need to rsync all of it. sorry, it sucks, but that's the way it is. your sync path shouldn't have to change, though. :) -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Tue Feb 1 21:18:29 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 01 Feb 2005 16:18:29 -0500 Subject: lua package error Message-ID: <1107292709.25100.146.camel@cutter> Hey, Can someone upload the latest lua tarball to match the spec file. I can't build until that gets uploaded otherwise I get: Error: lua cvs update: Updating devel % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed M 0 182k 0 1157 0 0 22226 0 0:00:08 --:--:-- 0:00:08 22226M100 182k 100 182k 0 0 1277k -rw-rw-r-- 1 build build 187287 Nov 7 23:49 lua-5.0.tar.gz rpmbuild --define "_sourcedir /rpmbuild/extras/cvs/rpms/lua/devel" -- define "_builddir /rpmbuild/extras/cvs/rpms/lua/dev error: File /rpmbuild/extras/cvs/rpms/lua/devel/lua-5.0.2.tar.gz: No such file or directory Building target platforms: i386 Building for target i386 make: *** [i386] Error 1 thanks, -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 1 23:13:50 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 2 Feb 2005 00:13:50 +0100 Subject: lua package error In-Reply-To: <1107292709.25100.146.camel@cutter> References: <1107292709.25100.146.camel@cutter> Message-ID: <20050202001350.1da57609@python2> seth vidal wrote : > Can someone upload the latest lua tarball to match the spec file. I > can't build until that gets uploaded otherwise I get [...] Argh, my bad. (I'm still not used to the look-aside cache in addition to the CVS repository as I wasn't previously working that way) My problem now is that I'm at home, and the http upload is restricted to certain IP addresses... mine being one of them, but my ISP had that good idea of putting transparent proxies for port 80 :-( Either someone else could do it, or it'll have to wait 10h from now, when I get at my office. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3 Load : 0.09 0.11 0.14 From fedora at wir-sind-cool.org Tue Feb 1 23:37:41 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 2 Feb 2005 00:37:41 +0100 Subject: lua package error In-Reply-To: <20050202001350.1da57609@python2> References: <1107292709.25100.146.camel@cutter> <20050202001350.1da57609@python2> Message-ID: <20050202003741.0b80fadd.fedora@wir-sind-cool.org> On Wed, 2 Feb 2005 00:13:50 +0100, Matthias Saou wrote: > seth vidal wrote : > > > Can someone upload the latest lua tarball to match the spec file. I > > can't build until that gets uploaded otherwise I get [...] > > Argh, my bad. (I'm still not used to the look-aside cache in addition to > the CVS repository as I wasn't previously working that way) > > My problem now is that I'm at home, and the http upload is restricted to > certain IP addresses... mine being one of them, but my ISP had that good > idea of putting transparent proxies for port 80 :-( > > Either someone else could do it, or it'll have to wait 10h from now, when I > get at my office. done. From skvidal at phy.duke.edu Wed Feb 2 00:30:52 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 01 Feb 2005 19:30:52 -0500 Subject: lua package error In-Reply-To: <20050202001350.1da57609@python2> References: <1107292709.25100.146.camel@cutter> <20050202001350.1da57609@python2> Message-ID: <1107304252.25100.164.camel@cutter> On Wed, 2005-02-02 at 00:13 +0100, Matthias Saou wrote: > seth vidal wrote : > > > Can someone upload the latest lua tarball to match the spec file. I > > can't build until that gets uploaded otherwise I get [...] > > Argh, my bad. (I'm still not used to the look-aside cache in addition to > the CVS repository as I wasn't previously working that way) > > My problem now is that I'm at home, and the http upload is restricted to > certain IP addresses... mine being one of them, but my ISP had that good > idea of putting transparent proxies for port 80 :-( > > Either someone else could do it, or it'll have to wait 10h from now, when I > get at my office. michael schwendt got to it. thanks michael! -sv From skvidal at fedoraproject.org Wed Feb 2 01:20:56 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 01 Feb 2005 20:20:56 -0500 Subject: New Packages and a New Layout in Fedora Extras Message-ID: <1107307256.25100.174.camel@cutter> Hi All, New Packages: lua x86, x86_64 openct x86, x86_64 gnofract4d x86 (build errors on x86_64) We've also reorganized a little bit for the migration to official 'extras' status. The directory hierarchy looks like this: extras/ -> 3 -> SRPMS -> i386 -> debug -> x86_64 -> testing -> 3 -> SRPMS -> i386 ->debug ... -> development -> SRPMS -> i386 -> debug -> x86_64 http://fedoraproject.org/wiki/Extras_2fFC3Status Follow updates and new packages at: http://fedoraproject.org/infofeed/ Report problems at Bugzilla: http://bugzilla.redhat.com/ thanks, -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mattdm at mattdm.org Wed Feb 2 01:48:56 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 1 Feb 2005 20:48:56 -0500 Subject: New Packages and a New Layout in Fedora Extras In-Reply-To: <1107307256.25100.174.camel@cutter> References: <1107307256.25100.174.camel@cutter> Message-ID: <20050202014856.GA25559@jadzia.bu.edu> On Tue, Feb 01, 2005 at 08:20:56PM -0500, seth vidal wrote: > The directory hierarchy looks like this: Thanks Seth! Can you give a quick 'du' of this tree, for the lazy^H^H^H^Hbusy mirror admin? -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From skvidal at phy.duke.edu Wed Feb 2 02:09:45 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 01 Feb 2005 21:09:45 -0500 Subject: New Packages and a New Layout in Fedora Extras In-Reply-To: <20050202014856.GA25559@jadzia.bu.edu> References: <1107307256.25100.174.camel@cutter> <20050202014856.GA25559@jadzia.bu.edu> Message-ID: <1107310185.25100.178.camel@cutter> On Tue, 2005-02-01 at 20:48 -0500, Matthew Miller wrote: > On Tue, Feb 01, 2005 at 08:20:56PM -0500, seth vidal wrote: > > The directory hierarchy looks like this: > > Thanks Seth! > > Can you give a quick 'du' of this tree, for the lazy^H^H^H^Hbusy mirror > admin? 2.8GB -sv From mattdm at mattdm.org Wed Feb 2 03:13:10 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 1 Feb 2005 22:13:10 -0500 Subject: New Packages and a New Layout in Fedora Extras In-Reply-To: <1107310185.25100.178.camel@cutter> References: <1107307256.25100.174.camel@cutter> <20050202014856.GA25559@jadzia.bu.edu> <1107310185.25100.178.camel@cutter> Message-ID: <20050202031310.GA28680@jadzia.bu.edu> On Tue, Feb 01, 2005 at 09:09:45PM -0500, seth vidal wrote: > > Can you give a quick 'du' of this tree, for the lazy^H^H^H^Hbusy mirror > > admin? > 2.8GB Okay, cool -- small enough to stick on one afs volume with no complaints. Thanks! -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 2 10:00:44 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 2 Feb 2005 11:00:44 +0100 Subject: New Packages and a New Layout in Fedora Extras In-Reply-To: <1107307256.25100.174.camel@cutter> References: <1107307256.25100.174.camel@cutter> Message-ID: <20050202110044.2c382481@python2> seth vidal wrote : > We've also reorganized a little bit for the migration to official > 'extras' status. > > The directory hierarchy looks like this: [...] Cool. I've noticed you also cleaned up the packages to remove obsolete builds it seems. Similarly, I think the x86_64 build logs would need cleaning up, since I wanted to go through them to see if there were any bugs I already knew about and could fix, but many of the logs are old or strange and correspond to packages that are successfully built. For instance : camE caca-utils (very weird, shouldn't it be "libcaca"?) libcaca-devel Those a probably remains of when imlib2 wasn't rebuilt yet, but have all been rebuilt since. At a glance, same goes for gpgme and related packages, and certainly others. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3 Load : 0.27 0.35 0.36 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 2 14:48:40 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 2 Feb 2005 15:48:40 +0100 Subject: Status of monkey-bubble (and frozen-bubble) Message-ID: <20050202154840.2308be6b@python2> Hi, Regarding monkey-bubble, I have a few questions : https://bugzilla.fedora.us/show_bug.cgi?id=1915 The first is to know if we couldn't import it into Extras. Seems like the main issue at the time was that the fedora.us build server was rebuilding it wrong. The last .src.rpm of the above bug works great for me on FC3 after a simple s/gettext/gettext-devel/ in the build deps. The second is to know if there are any kind of legal implications in doing so : I had decided not to import frozen-bubble because of its name and gameplay similarity with the original "Puzzle Bobble" (almost certainly copyrighted and trademarked), and monkey-bubble is in the exact same situation. When I looked around for more information, I noticed that many distributions, including SuSE, were offering frozen-bubble, and the author had never received any questions regarding legal aspects. In this particular case, since the gameplay has already been cloned in many commercial products (other arcade games from other manufacturers than Taito), that the name, although similar, is actually quite different, and that the entire artwork is 100% original and free, I'd tend to be ok with including both in Extras. Has anyone else done research on the subject? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3 Load : 0.12 0.18 0.27 From fedora at wir-sind-cool.org Wed Feb 2 15:17:30 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 2 Feb 2005 16:17:30 +0100 Subject: New Packages and a New Layout in Fedora Extras In-Reply-To: <20050202110044.2c382481@python2> References: <1107307256.25100.174.camel@cutter> <20050202110044.2c382481@python2> Message-ID: <20050202161730.3550656f.fedora@wir-sind-cool.org> On Wed, 2 Feb 2005 11:00:44 +0100, Matthias Saou wrote: > seth vidal wrote : > > > We've also reorganized a little bit for the migration to official > > 'extras' status. > > > > The directory hierarchy looks like this: > [...] > > Cool. I've noticed you also cleaned up the packages to remove obsolete > builds it seems. Similarly, I think the x86_64 build logs would need > cleaning up, since I wanted to go through them to see if there were any > bugs I already knew about and could fix, but many of the logs are old or > strange and correspond to packages that are successfully built. For > instance : > > camE > caca-utils (very weird, shouldn't it be "libcaca"?) > libcaca-devel > > Those a probably remains of when imlib2 wasn't rebuilt yet, but have all > been rebuilt since. At a glance, same goes for gpgme and related packages, > and certainly others. Please don't request a rebuild for gpgme, because it's too late now, as CVS in a development type of state for these packages. Transition to gpgme 1.0 is in progress. The old gpgme 0.4.x would not rebuild on x86_64 because it depends on newpg, which in turn fails in one of the tests. The work-around has been explained on fedora-devel, but has only been implemented for gpgme03 in favour of moving to GPGME 1.0 and GnuPG 2. From no-reply-gw at fcp.homelinux.org Wed Feb 2 16:13:29 2005 From: no-reply-gw at fcp.homelinux.org (=?iso-8859-1?B?aXVyb2Rpdmlp?=) Date: Wed, 2 Feb 2005 17:13:29 +0100 Subject: I\'m new to Linux: Web Design Packages Message-ID: Hello to all, i'm a three part newbie: new to programming in general new to linux and fedora new to the forum... here's my first question: I will be installing Fedora Core 3 onto my laptop in the next week (when time allows) and the first major project i will undertake it designing a website for myself. Being new to programming i know of a few terms that are related to web design PHP, HTML etc. what would anyone recommend as a good all-around package (either in Fedora, or as an add-on) to try out? Thanks -- This is an email sent via the webforum on http://fcp.homelinux.org From fedora at leemhuis.info Wed Feb 2 16:32:48 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 02 Feb 2005 17:32:48 +0100 Subject: New Packages and a New Layout in Fedora Extras In-Reply-To: <20050202110044.2c382481@python2> References: <1107307256.25100.174.camel@cutter> <20050202110044.2c382481@python2> Message-ID: <1107361968.5860.7.camel@localhost.localdomain> Am Mittwoch, den 02.02.2005, 11:00 +0100 schrieb Matthias Saou: > seth vidal wrote : > > > We've also reorganized a little bit for the migration to official > > 'extras' status. > > > > The directory hierarchy looks like this: > [...] > > Cool. I've noticed you also cleaned up the packages to remove obsolete > builds it seems. Similarly, I think the x86_64 build logs would need > cleaning up, since I wanted to go through them to see if there were any > bugs I already knew about and could fix, but many of the logs are old or > strange and correspond to packages that are successfully built. For > instance : > > camE > caca-utils (very weird, shouldn't it be "libcaca"?) > libcaca-devel I'm also working on those "failed for x86_64" packages ATM ;-) I have a rough list of actual x86_64 build problems in pre-extras. I'll try to bring some info in the wiki later today that should be helpful for you. But we should try to avoid working on the same packages. Can you mark those you plan to fix in the Wiki after I created that list? Thanks. CU thl -- Thorsten Leemhuis From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 2 16:38:48 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 2 Feb 2005 17:38:48 +0100 Subject: New Packages and a New Layout in Fedora Extras In-Reply-To: <1107361968.5860.7.camel@localhost.localdomain> References: <1107307256.25100.174.camel@cutter> <20050202110044.2c382481@python2> <1107361968.5860.7.camel@localhost.localdomain> Message-ID: <20050202173848.6e99fbc5@python2> Thorsten Leemhuis wrote : > > Cool. I've noticed you also cleaned up the packages to remove obsolete > > builds it seems. Similarly, I think the x86_64 build logs would need > > cleaning up, since I wanted to go through them to see if there were any > > bugs I already knew about and could fix, but many of the logs are old or > > strange and correspond to packages that are successfully built. For > > instance : > > > > camE > > caca-utils (very weird, shouldn't it be "libcaca"?) > > libcaca-devel > > I'm also working on those "failed for x86_64" packages ATM ;-) I have a > rough list of actual x86_64 build problems in pre-extras. > > I'll try to bring some info in the wiki later today that should be > helpful for you. But we should try to avoid working on the same > packages. Can you mark those you plan to fix in the Wiki after I created > that list? Thanks. I haven't started working on fixes, I was just browsing the "failed" build logs where I found lots of confusing stuff in the logs... thus my remark regarding cleaning them up. One thing I could do though, if no one else already started the same thing (you or seth, I guess), would be to list all x86_64 build logs that are no longer relevant and should be removed. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3 Load : 1.34 0.78 0.41 From skvidal at phy.duke.edu Wed Feb 2 16:44:08 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 02 Feb 2005 11:44:08 -0500 Subject: New Packages and a New Layout in Fedora Extras In-Reply-To: <20050202173848.6e99fbc5@python2> References: <1107307256.25100.174.camel@cutter> <20050202110044.2c382481@python2> <1107361968.5860.7.camel@localhost.localdomain> <20050202173848.6e99fbc5@python2> Message-ID: <1107362648.27149.44.camel@opus.phy.duke.edu> > I haven't started working on fixes, I was just browsing the "failed" build > logs where I found lots of confusing stuff in the logs... thus my remark > regarding cleaning them up. One thing I could do though, if no one else > already started the same thing (you or seth, I guess), would be to list all > x86_64 build logs that are no longer relevant and should be removed. send me the list which are all fixed up and I'll get rid of the old logs. sorry. -sv From sopwith at redhat.com Wed Feb 2 17:19:35 2005 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 2 Feb 2005 12:19:35 -0500 (EST) Subject: Fedora Extras available for download Message-ID: So you're wondering what's up with Fedora Extras these days. We have an announcement to make. So what should I put in the announcement? <|Jef|> Sopwith: that we are all deeply deeply ashamed for the delay and we throw ourselves on the mercy of the community and ask for forgiveness Thanks to the efforts of all the Extras contributors, you can now get Fedora Extras packages from the main Fedora download site at http://download.fedora.redhat.com/pub/fedora/linux/extras/ Fedora Extras are sets of packages that augment Fedora Core but do not replace Fedora Core component packages. These packages, like all packages that are part of The Fedora Project, must conform to the legal requirements of the project and conform to the Fedora Extras policies. Examples of packages currently available in Fedora Extras include: bittorrent cfengine gqview jikes libsigc++ openslp rxvt sqlite starfighter zope with a total of over 500 packages available! The fedora-extras-list (https://www.redhat.com/mailman/listinfo/fedora-extras-list/) is the best place to discuss Extras. If you'd like to start becoming involved with Extras development, a good step beyond joining fedora-extras-list might be http://cvs.fedora.redhat.com/extras.shtml Sopwith: bug reports via bugzilla.redhat.com, not bugzilla.fedora.us Please remember to report bugs at http://bugzilla.redhat.com/bugzilla/ Use a Product of "Fedora Extras". Seth Vidal deserves special recognition for continuing to be the engine behind getting builds done and organized through the fedoraproject.org site. And thanks to you all for being part of Fedora! -- Elliot From ville.skytta at iki.fi Wed Feb 2 17:26:42 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 02 Feb 2005 19:26:42 +0200 Subject: Status of monkey-bubble (and frozen-bubble) In-Reply-To: <20050202154840.2308be6b@python2> References: <20050202154840.2308be6b@python2> Message-ID: <1107365202.21089.40.camel@bobcat.mine.nu> On Wed, 2005-02-02 at 15:48 +0100, Matthias Saou wrote: > When I looked around for more information, I noticed that many > distributions, including SuSE, were offering frozen-bubble, and the author > had never received any questions regarding legal aspects. frozen-bubble requires perl-SDL, and a full-featured perl-SDL requires smpeg. Dunno if f-b would work with a smpeg-less p-S, or if shipping such a p-S would be crippling it. From sopwith at redhat.com Wed Feb 2 17:19:35 2005 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 2 Feb 2005 12:19:35 -0500 (EST) Subject: Fedora Extras available for download Message-ID: So you're wondering what's up with Fedora Extras these days. We have an announcement to make. So what should I put in the announcement? <|Jef|> Sopwith: that we are all deeply deeply ashamed for the delay and we throw ourselves on the mercy of the community and ask for forgiveness Thanks to the efforts of all the Extras contributors, you can now get Fedora Extras packages from the main Fedora download site at http://download.fedora.redhat.com/pub/fedora/linux/extras/ Fedora Extras are sets of packages that augment Fedora Core but do not replace Fedora Core component packages. These packages, like all packages that are part of The Fedora Project, must conform to the legal requirements of the project and conform to the Fedora Extras policies. Examples of packages currently available in Fedora Extras include: bittorrent cfengine gqview jikes libsigc++ openslp rxvt sqlite starfighter zope with a total of over 500 packages available! The fedora-extras-list (https://www.redhat.com/mailman/listinfo/fedora-extras-list/) is the best place to discuss Extras. If you'd like to start becoming involved with Extras development, a good step beyond joining fedora-extras-list might be http://cvs.fedora.redhat.com/extras.shtml Sopwith: bug reports via bugzilla.redhat.com, not bugzilla.fedora.us Please remember to report bugs at http://bugzilla.redhat.com/bugzilla/ Use a Product of "Fedora Extras". Seth Vidal deserves special recognition for continuing to be the engine behind getting builds done and organized through the fedoraproject.org site. And thanks to you all for being part of Fedora! -- Elliot -- fedora-announce-list mailing list fedora-announce-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-announce-list From fedora at leemhuis.info Wed Feb 2 18:01:48 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 02 Feb 2005 19:01:48 +0100 Subject: New Packages and a New Layout in Fedora Extras In-Reply-To: <1107362648.27149.44.camel@opus.phy.duke.edu> References: <1107307256.25100.174.camel@cutter> <20050202110044.2c382481@python2> <1107361968.5860.7.camel@localhost.localdomain> <20050202173848.6e99fbc5@python2> <1107362648.27149.44.camel@opus.phy.duke.edu> Message-ID: <1107367308.5860.16.camel@localhost.localdomain> Am Mittwoch, den 02.02.2005, 11:44 -0500 schrieb seth vidal: > > I haven't started working on fixes, I was just browsing the "failed" build > > logs where I found lots of confusing stuff in the logs... thus my remark > > regarding cleaning them up. One thing I could do though, if no one else > > already started the same thing (you or seth, I guess), would be to list all > > x86_64 build logs that are no longer relevant and should be removed. > > send me the list which are all fixed up and I'll get rid of the old > logs. Remove these: gnome-vfsmm26.log libgnomemm26.log libgnomeuimm26.log adns.log blender.log bochs-dlxlinux.log bochs.log caca-utils.log camE.log camlp4.log cvsgraph.log duplicity.log fontforge.log galculator.log gconfmm26.log gconmm26.log giblib.log glibmm24.log gpgme03.log gtkmm24.log i810switch.log ifplugd.log libcaca-devel.log libglademm24.log libgnomecanvasmm26.log libsig++20.log libsigc++20.log liferea.log lyx.log nget.log perl-Convert-BinHex.log perl-Module- Build.log pgadmin3.log python-adns.log python-imaging-devel.log scons.log scorched3d.log seahorse.log sqlite-tcl.log stellarium.log vbetest.log xmms-sid.log atitvout.log i8kutils.log lrmi.log s3switch.log synaptic.log tripwire.log No 100% guarantee for completion and correctness. But should be mostly correct ;-) Thanks CU thl -- Thorsten Leemhuis From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 2 18:01:11 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 2 Feb 2005 19:01:11 +0100 Subject: Status of monkey-bubble (and frozen-bubble) In-Reply-To: <1107365202.21089.40.camel@bobcat.mine.nu> References: <20050202154840.2308be6b@python2> <1107365202.21089.40.camel@bobcat.mine.nu> Message-ID: <20050202190111.43cc4061@python2> Ville Skytt? wrote : > On Wed, 2005-02-02 at 15:48 +0100, Matthias Saou wrote: > > > When I looked around for more information, I noticed that many > > distributions, including SuSE, were offering frozen-bubble, and the author > > had never received any questions regarding legal aspects. > > frozen-bubble requires perl-SDL, and a full-featured perl-SDL requires > smpeg. Dunno if f-b would work with a smpeg-less p-S, or if shipping > such a p-S would be crippling it. D'oh! You're right. I guess that was the ultimate reason for keeping it out, beyond any legal reasons *sigh* So back to monkey-bubble... it's neat, it's fun... it should be in Extras! :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3 Load : 0.37 0.34 0.51 From skvidal at phy.duke.edu Wed Feb 2 18:30:32 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 02 Feb 2005 13:30:32 -0500 Subject: Status of monkey-bubble (and frozen-bubble) In-Reply-To: <20050202190111.43cc4061@python2> References: <20050202154840.2308be6b@python2> <1107365202.21089.40.camel@bobcat.mine.nu> <20050202190111.43cc4061@python2> Message-ID: <1107369032.27149.48.camel@opus.phy.duke.edu> > D'oh! You're right. I guess that was the ultimate reason for keeping it > out, beyond any legal reasons *sigh* > > So back to monkey-bubble... it's neat, it's fun... it should be in Extras! > :-) > agreed. monkey bubble rocks. -sv From skvidal at phy.duke.edu Wed Feb 2 18:44:58 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 02 Feb 2005 13:44:58 -0500 Subject: New Packages and a New Layout in Fedora Extras In-Reply-To: <1107367308.5860.16.camel@localhost.localdomain> References: <1107307256.25100.174.camel@cutter> <20050202110044.2c382481@python2> <1107361968.5860.7.camel@localhost.localdomain> <20050202173848.6e99fbc5@python2> <1107362648.27149.44.camel@opus.phy.duke.edu> <1107367308.5860.16.camel@localhost.localdomain> Message-ID: <1107369898.27149.60.camel@opus.phy.duke.edu> > Remove these: > > gnome-vfsmm26.log libgnomemm26.log libgnomeuimm26.log adns.log > blender.log bochs-dlxlinux.log bochs.log caca-utils.log camE.log > camlp4.log cvsgraph.log duplicity.log fontforge.log galculator.log > gconfmm26.log gconmm26.log giblib.log glibmm24.log gpgme03.log > gtkmm24.log i810switch.log ifplugd.log libcaca-devel.log > libglademm24.log libgnomecanvasmm26.log libsig++20.log libsigc++20.log > liferea.log lyx.log nget.log perl-Convert-BinHex.log perl-Module- > Build.log pgadmin3.log python-adns.log python-imaging-devel.log > scons.log scorched3d.log seahorse.log sqlite-tcl.log stellarium.log > vbetest.log xmms-sid.log atitvout.log i8kutils.log lrmi.log s3switch.log > synaptic.log tripwire.log > > No 100% guarantee for completion and correctness. But should be mostly > correct ;-) done. thanks. -sv From daniel-wittenberg at starken.com Wed Feb 2 19:03:10 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Wed, 02 Feb 2005 13:03:10 -0600 Subject: snort ? Message-ID: <1107370990.17357.9.camel@forensic.starken.com> I know there was talk at one point of including snort, anyone know why it didn't make the cut this time or how to get it included? Dan From fedora at wir-sind-cool.org Wed Feb 2 19:35:04 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 2 Feb 2005 20:35:04 +0100 Subject: snort ? In-Reply-To: <1107370990.17357.9.camel@forensic.starken.com> References: <1107370990.17357.9.camel@forensic.starken.com> Message-ID: <20050202203504.5568eaa0.fedora@wir-sind-cool.org> On Wed, 02 Feb 2005 13:03:10 -0600, Daniel Wittenberg wrote: > I know there was talk at one point of including snort, anyone know why > it didn't make the cut this time or how to get it included? Snort was packaged and available for Red Hat Linux <= 9 or so, but never updated in a working way. From daniel-wittenberg at starken.com Wed Feb 2 19:50:41 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Wed, 02 Feb 2005 13:50:41 -0600 Subject: snort ? In-Reply-To: <20050202203504.5568eaa0.fedora@wir-sind-cool.org> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> Message-ID: <1107373841.17357.14.camel@forensic.starken.com> It is still currently being supported and RPM's have been built through 2.3.0 for FC1/2/3 and RHEL and RHL9. Dan On Wed, 2005-02-02 at 20:35 +0100, Michael Schwendt wrote: > On Wed, 02 Feb 2005 13:03:10 -0600, Daniel Wittenberg wrote: > > > I know there was talk at one point of including snort, anyone know why > > it didn't make the cut this time or how to get it included? > > Snort was packaged and available for Red Hat Linux <= 9 or so, > but never updated in a working way. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list From fedora at wir-sind-cool.org Wed Feb 2 20:03:30 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 2 Feb 2005 21:03:30 +0100 Subject: snort ? In-Reply-To: <1107373841.17357.14.camel@forensic.starken.com> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> Message-ID: <20050202210330.58a01d0a.fedora@wir-sind-cool.org> On Wed, 02 Feb 2005 13:50:41 -0600, Daniel Wittenberg wrote: > > > I know there was talk at one point of including snort, anyone know why > > > it didn't make the cut this time or how to get it included? > > > > Snort was packaged and available for Red Hat Linux <= 9 or so, > > but never updated in a working way. > > It is still currently being supported and RPM's have been built through > 2.3.0 for FC1/2/3 and RHEL and RHL9. It has not been updated fedora.us since RHL9, and hence at Fedora Extras there's the opportunity to start with completely fresh Snort packages. From bdpepple at ameritech.net Wed Feb 2 21:13:01 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Wed, 02 Feb 2005 16:13:01 -0500 Subject: Are packages in Fedora Extras not being QA? Message-ID: <1107378781.5577.0.camel@shuttle.273piedmont.org> I just installed a package (starfighter) from Fedora Extras, and it looks like the package hasn't had any QA done. There's some obvious problems with it, that would have been caught if the QA procedures that were established at Fedora.us were being used. Has any formal QA procedures been set-up for Fedora Extras yet? /B -- Brian Pepple -------------- next part -------------- A non-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 Feb 2 21:28:10 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 02 Feb 2005 11:28:10 -1000 Subject: Are packages in Fedora Extras not being QA? In-Reply-To: <1107378781.5577.0.camel@shuttle.273piedmont.org> References: <1107378781.5577.0.camel@shuttle.273piedmont.org> Message-ID: <420145EA.8050709@redhat.com> Brian Pepple wrote: > I just installed a package (starfighter) from Fedora Extras, and it > looks like the package hasn't had any QA done. There's some obvious > problems with it, that would have been caught if the QA procedures that > were established at Fedora.us were being used. Has any formal QA > procedures been set-up for Fedora Extras yet? > It seems that many refused to contribute to fedora.us because there were QA requirements. For now treat the newer packages in Extras as rawhide-ish. Just file a Bugzilla report. The owner is supposed to be responsible for fixing it. In the future I hope we will begin using the "testing" tree for new packages, and only after testing they be moved to the "extras" tree. This may actually happen soon now that the trees actually exist... http://www.fedora.us/PUBLISH However as the backlog here indicates, contributors seem to think TESTING THINGS BEFORE RELEASING is unreasonably difficult. Is it? Warren Togami wtogami at redhat.com From laroche at redhat.com Wed Feb 2 22:08:21 2005 From: laroche at redhat.com (Florian La Roche) Date: Wed, 2 Feb 2005 23:08:21 +0100 Subject: Are packages in Fedora Extras not being QA? In-Reply-To: <420145EA.8050709@redhat.com> References: <1107378781.5577.0.camel@shuttle.273piedmont.org> <420145EA.8050709@redhat.com> Message-ID: <20050202220821.GA5336@dudweiler.stuttgart.redhat.com> > http://www.fedora.us/PUBLISH > However as the backlog here indicates, contributors seem to think > TESTING THINGS BEFORE RELEASING is unreasonably difficult. Is it? Using the fast feedback cycle to just move on is often very good. After some startup time I think having a "stable" branch will be good where new packages have to stay in some testing brnach first and each time packages go to major new upstream versions, they should stay some longer time there until they go into the stable branch. greetings, Florian La Roche From bdpepple at ameritech.net Wed Feb 2 21:47:12 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Wed, 02 Feb 2005 16:47:12 -0500 Subject: Are packages in Fedora Extras not being QA? In-Reply-To: <420145EA.8050709@redhat.com> References: <1107378781.5577.0.camel@shuttle.273piedmont.org> <420145EA.8050709@redhat.com> Message-ID: <1107380832.5842.3.camel@shuttle.273piedmont.org> On Wed, 2005-02-02 at 11:28 -1000, Warren Togami wrote: > For now treat the newer packages in Extras as rawhide-ish. Just file a > Bugzilla report. The owner is supposed to be responsible for fixing it. Looks like two bugs were filed against it already, but were closed without any apparent action. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143285 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143284 /B -- Brian Pepple -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rdieter at math.unl.edu Wed Feb 2 21:58:41 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 02 Feb 2005 15:58:41 -0600 Subject: Are packages in Fedora Extras not being QA? In-Reply-To: <1107380832.5842.3.camel@shuttle.273piedmont.org> References: <1107378781.5577.0.camel@shuttle.273piedmont.org> <420145EA.8050709@redhat.com> <1107380832.5842.3.camel@shuttle.273piedmont.org> Message-ID: <42014D11.1060002@math.unl.edu> Brian Pepple wrote: > On Wed, 2005-02-02 at 11:28 -1000, Warren Togami wrote: > >>For now treat the newer packages in Extras as rawhide-ish. Just file a >>Bugzilla report. The owner is supposed to be responsible for fixing it. > > > Looks like two bugs were filed against it already, but were closed > without any apparent action. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143285 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143284 What do you mean without action? One was closed WONTFIX, the other closed RAWHIDE (ie, fixed in cvs). -- Rex From bdpepple at ameritech.net Wed Feb 2 22:15:56 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Wed, 02 Feb 2005 17:15:56 -0500 Subject: Are packages in Fedora Extras not being QA? In-Reply-To: <42014D11.1060002@math.unl.edu> References: <1107378781.5577.0.camel@shuttle.273piedmont.org> <420145EA.8050709@redhat.com> <1107380832.5842.3.camel@shuttle.273piedmont.org> <42014D11.1060002@math.unl.edu> Message-ID: <1107382556.6321.14.camel@shuttle.273piedmont.org> On Wed, 2005-02-02 at 15:58 -0600, Rex Dieter wrote: > Brian Pepple wrote: > > Looks like two bugs were filed against it already, but were closed > > without any apparent action. > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143285 > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143284 > > What do you mean without action? One was closed WONTFIX, the other > closed RAWHIDE (ie, fixed in cvs). Meaning the a fix actually has been published in Extras. The bug regarding the malformed .desktop file was reported about 6 weeks ago, but no fix was ever pushed to Extra (or Pre-Extras). Seems like that should be something real easy to publish, since only the % {desktop_vendor} macro needs to be fixed in the spec file. /B -- Brian Pepple -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 2 23:26:03 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 3 Feb 2005 00:26:03 +0100 Subject: Are packages in Fedora Extras not being QA? In-Reply-To: <1107382556.6321.14.camel@shuttle.273piedmont.org> References: <1107378781.5577.0.camel@shuttle.273piedmont.org> <420145EA.8050709@redhat.com> <1107380832.5842.3.camel@shuttle.273piedmont.org> <42014D11.1060002@math.unl.edu> <1107382556.6321.14.camel@shuttle.273piedmont.org> Message-ID: <20050203002603.14ce028b@python2> Brian Pepple wrote : > On Wed, 2005-02-02 at 15:58 -0600, Rex Dieter wrote: > > Brian Pepple wrote: > > > Looks like two bugs were filed against it already, but were closed > > > without any apparent action. > > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143285 > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143284 > > > > What do you mean without action? One was closed WONTFIX, the other > > closed RAWHIDE (ie, fixed in cvs). > > Meaning the a fix actually has been published in Extras. > > The bug regarding the malformed .desktop file was reported about 6 weeks > ago, but no fix was ever pushed to Extra (or Pre-Extras). Seems like > that should be something real easy to publish, since only the % > {desktop_vendor} macro needs to be fixed in the spec file. Then it's just that the rebuild was missed... I'll ask Seth to rebuild now *wink* The "no action taken" regarding the binary not being in $PATH (the other bug) is true, though, because I don't see any reason to take any, as explained in the bug. Feel free to express a contradictory opinion, as if there are reasons I simply can't ignore, I'll abide ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3 Load : 0.19 0.45 0.43 From bdpepple at ameritech.net Wed Feb 2 23:52:30 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Wed, 02 Feb 2005 18:52:30 -0500 Subject: Are packages in Fedora Extras not being QA? In-Reply-To: <20050203002603.14ce028b@python2> References: <1107378781.5577.0.camel@shuttle.273piedmont.org> <420145EA.8050709@redhat.com> <1107380832.5842.3.camel@shuttle.273piedmont.org> <42014D11.1060002@math.unl.edu> <1107382556.6321.14.camel@shuttle.273piedmont.org> <20050203002603.14ce028b@python2> Message-ID: <1107388350.6803.4.camel@shuttle.273piedmont.org> On Thu, 2005-02-03 at 00:26 +0100, Matthias Saou wrote: > The "no action taken" regarding the binary not being in $PATH (the other > bug) is true, though, because I don't see any reason to take any, as > explained in the bug. Feel free to express a contradictory opinion, as if > there are reasons I simply can't ignore, I'll abide ;-) Yeah, I don't really have a problem with that, though we might want to have it confirm to how other games are set-up in Fedora. This is really the only game package that I'm aware of that has the binary in /usr/games. /B -- Brian Pepple -------------- next part -------------- A non-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 Feb 2 20:15:57 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Wed, 02 Feb 2005 14:15:57 -0600 Subject: snort ? In-Reply-To: <20050202210330.58a01d0a.fedora@wir-sind-cool.org> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> Message-ID: <1107375357.17357.17.camel@forensic.starken.com> I'm not sure I completely understand. Do the new RPM's just need to be uploaded somewhere then? Just let me know what needs to be done, or if there is a procedure somewhere send me URL and I'll take care of it. Thanks, Dan On Wed, 2005-02-02 at 21:03 +0100, Michael Schwendt wrote: > It has not been updated fedora.us since RHL9, and hence at Fedora Extras > there's the opportunity to start with completely fresh Snort packages. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list From fedora at wir-sind-cool.org Thu Feb 3 00:42:37 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 3 Feb 2005 01:42:37 +0100 Subject: snort ? In-Reply-To: <1107375357.17357.17.camel@forensic.starken.com> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> Message-ID: <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> On Wed, 02 Feb 2005 14:15:57 -0600, Daniel Wittenberg wrote: > I'm not sure I completely understand. Do the new RPM's just need to be > uploaded somewhere then? Just let me know what needs to be done, or if > there is a procedure somewhere send me URL and I'll take care of it. Not sure how else to explain it, since you should be in the know as you submitted the fedora.us update, which didn't make it. 1.) Snort once was in fedora.us for Red Hat Linux. 2.) An update request stalled in QA because it was a huge and complete rewrite which had many issues, and when built, it didn't result in binary packages which would upgrade the existing fedora.us packages. Interest in fixing it and getting an update published didn't seem to exist. While the old update tried to cover SuSE Linux and other distributions with lots of conditional spec sections, that newest one fiddles with macros to switch between Fedora and Caos. Lots of other conditionals increase the spec file's size to 2.4 times the size of Dag Wieers' spec. And it should at least build with defaults and not require lots of manual --with/without switches. I'm not aware of any new package submission policies for Fedora Extras yet. These will likely come in the future. I don't know whether we apply any first-come first-served rule when somebody submits a package. ;) It has been suggested that maybe Dag Wieers, who also maintains Snort packages, might want to maintain them in Fedora Extras, too. If multiple people are interested in creating and maintaining Snort packages in Fedora Extras, it would be great if they discussed and finished a candidate source rpm. Starting there, it could be imported into CVS and built for testing. From gmureddu at prodigy.net.mx Thu Feb 3 02:06:00 2005 From: gmureddu at prodigy.net.mx (Gain Paolo Mureddu) Date: Wed, 02 Feb 2005 20:06:00 -0600 Subject: I\'m new to Linux: Web Design Packages In-Reply-To: References: Message-ID: <42018708.2050306@prodigy.net.mx> iurodivii wrote: >Hello to all, i'm a three part newbie: >new to programming in general >new to linux and fedora >new to the forum... > >here's my first question: > >I will be installing Fedora Core 3 onto my laptop in the next week (when time allows) and the first major project i will undertake it designing a website for myself. Being new to programming i know of a few terms that are related to web design PHP, HTML etc. what would anyone recommend as a good all-around package (either in Fedora, or as an add-on) to try out? > >Thanks > > > > I'd very strongly suggest you (as a newbie) to try either or all of these packages: NVU, Quanta and BlueFish, NVU is like an IDE so it is WYSIWYG and Quanta and BlueFish are very good coding tools with syntax hihglight and stuff, very useful them both. From daniel-wittenberg at starken.com Thu Feb 3 04:19:55 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Wed, 02 Feb 2005 22:19:55 -0600 Subject: snort ? In-Reply-To: <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> Message-ID: <1107404396.10215.7.camel@localhost.localdomain> > 2.) An update request stalled in QA because it was a huge and complete > rewrite which had many issues, and when built, it didn't result in binary > packages which would upgrade the existing fedora.us packages. Interest in > fixing it and getting an update published didn't seem to exist. This is the first I have heard of this. > While the old update tried to cover SuSE Linux and other distributions > with lots of conditional spec sections, that newest one fiddles with > macros to switch between Fedora and Caos. Lots of other conditionals > increase the spec file's size to 2.4 times the size of Dag Wieers' > spec. Just curious, but what does the size of the .spec file mean? I have seen some pretty big, complicated .specs coming out of RH for packages, so little confused about why this seems to be so important to you. > And it should at least build with defaults and not require lots of > manual --with/without switches. I agree with this one. > I'm not aware of any new package submission policies for Fedora Extras > yet. These will likely come in the future. > > I don't know whether we apply any first-come first-served rule when > somebody submits a package. ;) > > It has been suggested that maybe Dag Wieers, who also maintains Snort > packages, might want to maintain them in Fedora Extras, too. > > If multiple people are interested in creating and maintaining Snort > packages in Fedora Extras, it would be great if they discussed and > finished a candidate source rpm. Starting there, it could be imported into > CVS and built for testing. That's fine with me too obviously, it just seems odd that you wouldn't want the people maintaining the official RPMs to maintain these too with little to no extra effort. 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 skvidal at phy.duke.edu Thu Feb 3 05:02:55 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 03 Feb 2005 00:02:55 -0500 Subject: fedora-extras-release Message-ID: <1107406975.7339.1.camel@cutter> Hey folks, Do we need a fedora-extras-release package with, maybe, a fedora- extras-release file in /etc and a fedora-extras.repo file in /etc/yum.repos.d? Would that be something we should pull in? So people can tell us what fedora extras tree their using? -sv From mattdm at mattdm.org Thu Feb 3 05:02:30 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 3 Feb 2005 00:02:30 -0500 Subject: fedora-extras-release In-Reply-To: <1107406975.7339.1.camel@cutter> References: <1107406975.7339.1.camel@cutter> Message-ID: <20050203050230.GA23649@jadzia.bu.edu> On Thu, Feb 03, 2005 at 12:02:55AM -0500, seth vidal wrote: > Do we need a fedora-extras-release package with, maybe, a fedora- > extras-release file in /etc and a fedora-extras.repo file > in /etc/yum.repos.d? > Would that be something we should pull in? > So people can tell us what fedora extras tree their using? Is using a FE tree with a different version than the main FC release intended to be something that would work? -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From skvidal at phy.duke.edu Thu Feb 3 05:07:02 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 03 Feb 2005 00:07:02 -0500 Subject: fedora-extras-release In-Reply-To: <20050203050230.GA23649@jadzia.bu.edu> References: <1107406975.7339.1.camel@cutter> <20050203050230.GA23649@jadzia.bu.edu> Message-ID: <1107407222.7339.3.camel@cutter> On Thu, 2005-02-03 at 00:02 -0500, Matthew Miller wrote: > On Thu, Feb 03, 2005 at 12:02:55AM -0500, seth vidal wrote: > > Do we need a fedora-extras-release package with, maybe, a fedora- > > extras-release file in /etc and a fedora-extras.repo file > > in /etc/yum.repos.d? > > Would that be something we should pull in? > > So people can tell us what fedora extras tree their using? > > Is using a FE tree with a different version than the main FC release > intended to be something that would work? I'm not really sure, but it's not like it would be the first time someone would mix things around. :) -sv From skvidal at fedoraproject.org Thu Feb 3 05:34:54 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 03 Feb 2005 00:34:54 -0500 Subject: New Packages and Updates for Fedora Extras 3 Message-ID: <1107408895.7339.11.camel@cutter> Hi all, fillets-ng - x86, x86_64 fillets-ng-data - x86, x86_64 fillets-ng-data-cs - x86, x86_64 starfighter - x86, x86_64 libassuan - x86, x86_64 perl-MLDBM - - x86, x86_64 gnome-themes-extras - - x86, x86_64 Release Tag Cleanups - no change to the package: libsafe - x86 only openal uqm-content pam_mount - x86 - build errors on x86_64 wxPython - x86 - build errors on x86_64 Urls of happiness: http://fedoraproject.org/extras/EXTRAS Status page: http://fedoraproject.org/wiki/Extras_2fFC3Status Follow updates and new packages at: http://fedoraproject.org/infofeed/ Report problems at Bugzilla: http://bugzilla.redhat.com/ thanks, -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Thu Feb 3 05:50:16 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 03 Feb 2005 00:50:16 -0500 Subject: Wiki Changes Message-ID: <1107409816.7339.14.camel@cutter> Hey, I'm going to make a Contributors page. I'll put down the names of folks I know who are checking packages in and making changes. If anyone knows of folks I'm missing, add them. http://fedoraproject.org/wiki/Extras_2fContributors thanks, -sv From skvidal at phy.duke.edu Thu Feb 3 06:50:34 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 03 Feb 2005 01:50:34 -0500 Subject: Are packages in Fedora Extras not being QA? In-Reply-To: <20050203002603.14ce028b@python2> References: <1107378781.5577.0.camel@shuttle.273piedmont.org> <420145EA.8050709@redhat.com> <1107380832.5842.3.camel@shuttle.273piedmont.org> <42014D11.1060002@math.unl.edu> <1107382556.6321.14.camel@shuttle.273piedmont.org> <20050203002603.14ce028b@python2> Message-ID: <1107413434.7339.19.camel@cutter> > Then it's just that the rebuild was missed... I'll ask Seth to rebuild now > *wink* done. -sv From skvidal at phy.duke.edu Thu Feb 3 06:51:43 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 03 Feb 2005 01:51:43 -0500 Subject: New Packages and a New Layout in Fedora Extras In-Reply-To: <20050202110044.2c382481@python2> References: <1107307256.25100.174.camel@cutter> <20050202110044.2c382481@python2> Message-ID: <1107413503.7339.21.camel@cutter> On Wed, 2005-02-02 at 11:00 +0100, Matthias Saou wrote: > seth vidal wrote : > > > We've also reorganized a little bit for the migration to official > > 'extras' status. > > > > The directory hierarchy looks like this: > [...] > > Cool. I've noticed you also cleaned up the packages to remove obsolete > builds it seems. Similarly, I think the x86_64 build logs would need > cleaning up, since I wanted to go through them to see if there were any > bugs I already knew about and could fix, but many of the logs are old or > strange and correspond to packages that are successfully built. For > instance : > > camE > caca-utils (very weird, shouldn't it be "libcaca"?) > libcaca-devel > > Those a probably remains of when imlib2 wasn't rebuilt yet, but have all > been rebuilt since. At a glance, same goes for gpgme and related packages, > and certainly others. Thanks to Thorsten I cleaned up all the sutff that was old, there. let me know if I missed anything else. thanks -sv From notting at redhat.com Thu Feb 3 07:13:22 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 3 Feb 2005 02:13:22 -0500 Subject: fedora-extras-release In-Reply-To: <1107406975.7339.1.camel@cutter> References: <1107406975.7339.1.camel@cutter> Message-ID: <20050203071322.GC8404@nostromo.devel.redhat.com> seth vidal (skvidal at phy.duke.edu) said: > Hey folks, > Do we need a fedora-extras-release package with, maybe, a fedora- > extras-release file in /etc and a fedora-extras.repo file > in /etc/yum.repos.d? > > Would that be something we should pull in? As a container for .repo files, sure. (It could contain keys, too.) As a general release distinguisher, I'm not so certain it has as much use. After all, people shouldn't be pulling from *multiple* versions, and the version of the repo should be pretty easy to distinguish from the package version. Bill From skvidal at phy.duke.edu Thu Feb 3 07:18:53 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 03 Feb 2005 02:18:53 -0500 Subject: fedora-extras-release In-Reply-To: <20050203071322.GC8404@nostromo.devel.redhat.com> References: <1107406975.7339.1.camel@cutter> <20050203071322.GC8404@nostromo.devel.redhat.com> Message-ID: <1107415133.7339.25.camel@cutter> On Thu, 2005-02-03 at 02:13 -0500, Bill Nottingham wrote: > seth vidal (skvidal at phy.duke.edu) said: > > Hey folks, > > Do we need a fedora-extras-release package with, maybe, a fedora- > > extras-release file in /etc and a fedora-extras.repo file > > in /etc/yum.repos.d? > > > > Would that be something we should pull in? > > As a container for .repo files, sure. (It could contain > keys, too.) As a general release distinguisher, I'm not so > certain it has as much use. After all, people shouldn't be > pulling from *multiple* versions, and the version of the > repo should be pretty easy to distinguish from the package version. > I was almost thinking, maybe put a fedora-extras package in fedora core. so a user, if they so desired, could: yum install fedora-extras and then once it's done they have the extras repo all ready to go. thoughts? -sv From ivazquez at ivazquez.net Thu Feb 3 07:35:11 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 03 Feb 2005 02:35:11 -0500 Subject: fedora-extras-release In-Reply-To: <1107415133.7339.25.camel@cutter> References: <1107406975.7339.1.camel@cutter> <20050203071322.GC8404@nostromo.devel.redhat.com> <1107415133.7339.25.camel@cutter> Message-ID: <1107416111.6395.6.camel@ignacio.ignacio.lan> On Thu, 2005-02-03 at 02:18 -0500, seth vidal wrote: > I was almost thinking, maybe put a fedora-extras package in fedora core. > > > so a user, if they so desired, could: > yum install fedora-extras > > and then once it's done they have the extras repo all ready to go. > > thoughts? I have a yum-repos package in my repo that does basically that, but for more than just Fedora Extras. Feel free to take a look at it for ideas. http://fedora.ivazquez.net/yum/3/i386/RPMS.ivazquez/yum- repos-0.0.3-0.iva.0.noarch.rpm http://fedora.ivazquez.net/yum/3/i386/SRPMS.ivazquez/yum- repos-0.0.3-0.iva.0.src.rpm -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Thu Feb 3 08:29:41 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 03 Feb 2005 03:29:41 -0500 Subject: fedora-extras-release In-Reply-To: <1107416111.6395.6.camel@ignacio.ignacio.lan> References: <1107406975.7339.1.camel@cutter> <20050203071322.GC8404@nostromo.devel.redhat.com> <1107415133.7339.25.camel@cutter> <1107416111.6395.6.camel@ignacio.ignacio.lan> Message-ID: <1107419381.7339.49.camel@cutter> > I have a yum-repos package in my repo that does basically that, but for > more than just Fedora Extras. Feel free to take a look at it for ideas. > > http://fedora.ivazquez.net/yum/3/i386/RPMS.ivazquez/yum- > repos-0.0.3-0.iva.0.noarch.rpm > > http://fedora.ivazquez.net/yum/3/i386/SRPMS.ivazquez/yum- > repos-0.0.3-0.iva.0.src.rpm > Your package is fine but we can't use it in fedora core or extras. It points to repositories that ship packages which are illegal to link or point to under the DMCA in the US. Unfortunately red hat is bound under those laws as it is a US-based company. Thanks, -sv From ivazquez at ivazquez.net Thu Feb 3 08:42:03 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 03 Feb 2005 03:42:03 -0500 Subject: fedora-extras-release In-Reply-To: <1107419381.7339.49.camel@cutter> References: <1107406975.7339.1.camel@cutter> <20050203071322.GC8404@nostromo.devel.redhat.com> <1107415133.7339.25.camel@cutter> <1107416111.6395.6.camel@ignacio.ignacio.lan> <1107419381.7339.49.camel@cutter> Message-ID: <1107420123.6395.10.camel@ignacio.ignacio.lan> On Thu, 2005-02-03 at 03:29 -0500, seth vidal wrote: > > I have a yum-repos package in my repo that does basically that, but for > > more than just Fedora Extras. Feel free to take a look at it for ideas. > > > > http://fedora.ivazquez.net/yum/3/i386/RPMS.ivazquez/yum- > > repos-0.0.3-0.iva.0.noarch.rpm > > > > http://fedora.ivazquez.net/yum/3/i386/SRPMS.ivazquez/yum- > > repos-0.0.3-0.iva.0.src.rpm > > > > Your package is fine but we can't use it in fedora core or extras. > It points to repositories that ship packages which are illegal to link > or point to under the DMCA in the US. Unfortunately red hat is bound > under those laws as it is a US-based company. Believe me, I understand that. I'm not suggesting that you include the whole package, just take from it possible ideas. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ -------------- next part -------------- A non-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 wir-sind-cool.org Thu Feb 3 11:59:26 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 3 Feb 2005 12:59:26 +0100 Subject: snort ? In-Reply-To: <1107404396.10215.7.camel@localhost.localdomain> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> Message-ID: <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> On Wed, 02 Feb 2005 22:19:55 -0600, Daniel Wittenberg wrote: > > > 2.) An update request stalled in QA because it was a huge and complete > > rewrite which had many issues, and when built, it didn't result in binary > > packages which would upgrade the existing fedora.us packages. Interest in > > fixing it and getting an update published didn't seem to exist. > > This is the first I have heard of this. Desinterest is the only suitable interpretation for inactivity since 2003. > > While the old update tried to cover SuSE Linux and other distributions > > with lots of conditional spec sections, that newest one fiddles with > > macros to switch between Fedora and Caos. Lots of other conditionals > > increase the spec file's size to 2.4 times the size of Dag Wieers' > > spec. > > Just curious, but what does the size of the .spec file mean? I have > seen some pretty big, complicated .specs coming out of RH for packages, > so little confused about why this seems to be so important to you. It isn't important. It's just a comparison as a result of reviewing a src.rpm which didn't even build https://bugzilla.fedora.us/attachment.cgi?id=383&action=view and which apparently was unfinished work-in-progress with no clear word on what version was considered the final release candidate. Hence when work starts on seeking for the cause of a failed build, lots of unclean/sloppy packaging is found in addition to clear defects, and general cleanup is suggested (such as replacing absolute paths with rpm macros and making short-circuit installs possible). So it can be concentrated on making the important parts of a spec file work and increase the likelihood that it will build successfully in the build environment. I don't argue about how elaborate spec files (think XFree86/xorg-x11) can be, when they "just work" or when the package maintainer knows his stuff and manages to build the desired binaries from them. However, in a large spec which fails, lots of mistakes and pitfalls are buried beneath many unnecessary things, which decrease readability and increase maintenance requirements. > > And it should at least build with defaults and not require lots of > > manual --with/without switches. > > I agree with this one. > > > I'm not aware of any new package submission policies for Fedora Extras > > yet. These will likely come in the future. > > > > I don't know whether we apply any first-come first-served rule when > > somebody submits a package. ;) > > > > It has been suggested that maybe Dag Wieers, who also maintains Snort > > packages, might want to maintain them in Fedora Extras, too. > > > > If multiple people are interested in creating and maintaining Snort > > packages in Fedora Extras, it would be great if they discussed and > > finished a candidate source rpm. Starting there, it could be imported into > > CVS and built for testing. > > That's fine with me too obviously, it just seems odd that you wouldn't > want the people maintaining the official RPMs to maintain these too with > little to no extra effort. Nobody said that. Apparently, the rpms are not ready. And what effort will be necessary to maintain them remains to be seen. You don't know what road of development the packages will take in Fedora CVS. IMO, there's nothing like a Fedora packaging prerogative for people who provide rpms for upstream projects. It would be beneficial if package maintainers have good contact with upstream developers. But it could be that the Fedora community disagrees with the rpms provided there and would want the packaging to be different. Concerning the bits which build for cAos Linux, I would consider it wrong to accept them and would not feel good about it. Once included, other packagers would want to include spec sections which handle the peculiarities of e.g. Mandrake Linux or SuSE Linux, respectively. Unsupported areas. -- Fedora Core release 3 (Heidelberg) - Linux 2.6.10-1.760_FC3 loadavg: 0.10 0.55 0.36 From ndbecker2 at verizon.net Thu Feb 3 14:34:49 2005 From: ndbecker2 at verizon.net (Neal Becker) Date: Thu, 3 Feb 2005 09:34:49 -0500 Subject: extras breaks smart --gui Message-ID: <200502030934.49555.ndbecker2@verizon.net> rpm -q smart smart-0.28-11.rhfc3.at [create new /var/lib/smart] smart update [...OK] smart --gui [... OK] Now add this to /etc/smart/channels/smart/channel: [extras] name=Fedora Core 3 - x86_64 - Extras baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/3/x86_64 type=rpm-md smart update [... OK] now run smart --gui: smart --gui python2.4: Objects/stringobject.c:105: PyString_FromString: Assertion `str != ((void *)0)' failed. Aborted From fedora at wir-sind-cool.org Thu Feb 3 14:57:19 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 3 Feb 2005 15:57:19 +0100 Subject: extras breaks smart --gui In-Reply-To: <200502030934.49555.ndbecker2@verizon.net> References: <200502030934.49555.ndbecker2@verizon.net> Message-ID: <20050203155719.3716319c.fedora@wir-sind-cool.org> On Thu, 3 Feb 2005 09:34:49 -0500, Neal Becker wrote: > rpm -q smart > smart-0.28-11.rhfc3.at .at => ATrpms, right? > [create new /var/lib/smart] > smart update > [...OK] > > smart --gui > [... OK] > > Now add this to /etc/smart/channels/smart/channel: > [extras] > name=Fedora Core 3 - x86_64 - Extras > baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/3/x86_64 > type=rpm-md > > smart update > [... OK] What packages were updated here? > now run smart --gui: > smart --gui > python2.4: Objects/stringobject.c:105: PyString_FromString: Assertion `str != > ((void *)0)' failed. > Aborted Submit a bug report at buzilla.atrpms.net and request that the smartpm package is made compatible with Fedora Extras, whatever upgrades may be necessary at ATrpms to achieve that. The package depends on Python 2.4 which is not even available in Fedora Core 3. -- Fedora Core release 3 (Heidelberg) - Linux 2.6.10-1.760_FC3 loadavg: 1.10 1.09 1.03 From dzrudy at gmail.com Thu Feb 3 15:56:33 2005 From: dzrudy at gmail.com (Dawid Zamirski) Date: Thu, 03 Feb 2005 10:56:33 -0500 Subject: Anjuta x86_64 crashes when creatina a new project. Message-ID: <420249B1.8000406@gmail.com> Regardless of the project type I choose, the program throws the following error message: "The Application "anjuta" has quit unexpectedly. You can inform the developers of what happened to help them fix it. Or you can restart the application right now." It happerns when it launches autogen.sh I didn't have such problem with Anjuta-1.2.2-3.1 from dag repository. From daniel-wittenberg at starken.com Thu Feb 3 16:07:42 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Thu, 03 Feb 2005 10:07:42 -0600 Subject: snort ? In-Reply-To: <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> Message-ID: <1107446862.23434.2.camel@forensic.starken.com> > Nobody said that. Apparently, the rpms are not ready. Are you still looking at the ancient ones? We have been supporting Fedora RPMs with snort all along, just didn't get updated in the Fedora area. The past is irrelavant at this point to me, I'm looking at the current RPMs which are much much more refined and build just fine. If the Fedora naming scheme is different than what is "officially posted" I am MORE than happy to drop the 0.fdr out of the name and make the naming scheme more "standard". This would also allow me to rip out all of the special clauses to build specifically for Fedora. So my question still stands, what would it take to get the CURRENT snort 2.3.0+ RPMs included in Fedora Extras? Dan From fedora at wir-sind-cool.org Thu Feb 3 16:49:39 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 3 Feb 2005 17:49:39 +0100 Subject: snort ? In-Reply-To: <1107446862.23434.2.camel@forensic.starken.com> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> Message-ID: <20050203174939.318a88ec.fedora@wir-sind-cool.org> On Thu, 03 Feb 2005 10:07:42 -0600, Daniel Wittenberg wrote: > > Nobody said that. Apparently, the rpms are not ready. > > Are you still looking at the ancient ones? No. 2.3.something, but you never link a specific src.rpm, so better do that. [Did you miss my comment in bugzilla?] > We have been supporting > Fedora RPMs with snort all along, just didn't get updated in the Fedora > area. The past is irrelavant at this point to me, I'm looking at the > current RPMs which are much much more refined and build just fine. If > the Fedora naming scheme is different than what is "officially posted" I > am MORE than happy to drop the 0.fdr out of the name and make the naming > scheme more "standard". This would also allow me to rip out all of the > special clauses to build specifically for Fedora. > > So my question still stands, what would it take to get the CURRENT snort > 2.3.0+ RPMs included in Fedora Extras? - A candidate source rpm which is considered "ready", - which is roughly the same quality as other packages in Fedora Extras, - and a sponsor who would serve as a proxy to CVS for updates until Fedora Extras is ready to accept project contributors and create accounts for them. Revised package submission and QA policies for Fedora Extras are not known yet. So, fedora.us documents should be taken as a good guideline. -- Fedora Core release 3 (Heidelberg) - Linux 2.6.10-1.760_FC3 loadavg: 1.00 1.00 1.19 From fedora at wir-sind-cool.org Thu Feb 3 16:56:32 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 3 Feb 2005 17:56:32 +0100 Subject: Anjuta x86_64 crashes when creatina a new project. In-Reply-To: <420249B1.8000406@gmail.com> References: <420249B1.8000406@gmail.com> Message-ID: <20050203175632.49ef4f4a.fedora@wir-sind-cool.org> On Thu, 03 Feb 2005 10:56:33 -0500, Dawid Zamirski wrote: > Regardless of the project type I choose, the program throws the > following error message: > > "The Application "anjuta" has quit unexpectedly. > You can inform the developers of what happened to help them fix it. Or > you can restart the application right now." > > It happerns when it launches autogen.sh > I didn't have such problem with Anjuta-1.2.2-3.1 from dag repository. Could be true. Please file a bug report at http://bugzilla.redhat.com Can anybody confirm this and contribute some trouble-shooting? I looked up the package you referred to. There is no patch or anything like that in Dag's source rpm, and the spec file differences are subtle. So, in case you only replaced Anjuta, downgrading to Dag's version should make it work again for now. The x86_64 packages are basically a free extra of a src.rpm rebuild and maybe an added fix to make it build at all. Many of the packages would benefit from dedicated testers and maintainers who make sure everything works on x86_64. From daniel-wittenberg at starken.com Thu Feb 3 16:56:56 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Thu, 03 Feb 2005 10:56:56 -0600 Subject: snort ? In-Reply-To: <20050203174939.318a88ec.fedora@wir-sind-cool.org> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> Message-ID: <1107449816.23434.8.camel@forensic.starken.com> On Thu, 2005-02-03 at 17:49 +0100, Michael Schwendt wrote: > On Thu, 03 Feb 2005 10:07:42 -0600, Daniel Wittenberg wrote: > > > > Nobody said that. Apparently, the rpms are not ready. > > > > Are you still looking at the ancient ones? > > No. 2.3.something, but you never link a specific src.rpm, so better do > that. [Did you miss my comment in bugzilla?] The URL was posted for the latest RPMs, but I assumed people could fill in FC 1/2/3 and get the latest. So instead I just posted the exact URL for the 2.3.0 src.rpm. > - A candidate source rpm which is considered "ready", > - which is roughly the same quality as other packages in Fedora > Extras, > - and a sponsor who would serve as a proxy to CVS for updates > until Fedora Extras is ready to accept project contributors > and create accounts for them. > > Revised package submission and QA policies for Fedora Extras are not known > yet. So, fedora.us documents should be taken as a good guideline. I'm not bitching here, so don't take this wrong, I'm merely curious, but if the submission and QA policies aren't set doesn't that make it hard to say the RPM is "ready", since there are no guidelines to follow for that? We have been rebuilding and using these RPM's in production with little changes to the .spec or other code for awhile, so I think they are working and ready, but may not conform to "official" specs, whatever those might be. Dan From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 3 17:17:08 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 3 Feb 2005 18:17:08 +0100 Subject: Anjuta x86_64 crashes when creatina a new project. In-Reply-To: <20050203175632.49ef4f4a.fedora@wir-sind-cool.org> References: <420249B1.8000406@gmail.com> <20050203175632.49ef4f4a.fedora@wir-sind-cool.org> Message-ID: <20050203181708.2e28db6c@python2> Michael Schwendt wrote : > On Thu, 03 Feb 2005 10:56:33 -0500, Dawid Zamirski wrote: > > > Regardless of the project type I choose, the program throws the > > following error message: > > > > "The Application "anjuta" has quit unexpectedly. > > You can inform the developers of what happened to help them fix it. Or > > you can restart the application right now." > > > > It happerns when it launches autogen.sh > > I didn't have such problem with Anjuta-1.2.2-3.1 from dag repository. > > Could be true. Please file a bug report at http://bugzilla.redhat.com > > Can anybody confirm this and contribute some trouble-shooting? > > I looked up the package you referred to. There is no patch or anything > like that in Dag's source rpm, and the spec file differences are subtle. > So, in case you only replaced Anjuta, downgrading to Dag's version > should make it work again for now. > > The x86_64 packages are basically a free extra of a src.rpm rebuild and > maybe an added fix to make it build at all. Many of the packages would > benefit from dedicated testers and maintainers who make sure everything > works on x86_64. BTW, about the anjuta rpm, one thing that needs fixing is adding gettext-devel to the requirements. I just got this report from a user : -- From: "Paul Frields" Subject: Anjuta RPM suggestion If gettext-devel is not installed, anjuta will fail to autogenerate Makefile.in (and intl/ folder skeleton) for new projects as new users might expect. The program defaults as installed then generate errors, which is not consistent with Fedora behavioral guidelines. Would it be possible to add a Requires: gettext-devel for your package so that the behavior is as expected? Thanks Matthias, I enjoy mirroring your site for use by workers here in our office. -- If pcompton is lurking, I hope he'll pick it up, otherwise, the next person to open a bug report could include it as a bonus ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3 Load : 0.53 1.02 1.22 From fedora at wir-sind-cool.org Thu Feb 3 17:22:45 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 3 Feb 2005 18:22:45 +0100 Subject: snort ? In-Reply-To: <1107449816.23434.8.camel@forensic.starken.com> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> Message-ID: <20050203182245.2325c70b.fedora@wir-sind-cool.org> On Thu, 03 Feb 2005 10:56:56 -0600, Daniel Wittenberg wrote: > > - A candidate source rpm which is considered "ready", > > - which is roughly the same quality as other packages in Fedora > > Extras, > > - and a sponsor who would serve as a proxy to CVS for updates > > until Fedora Extras is ready to accept project contributors > > and create accounts for them. > > > > Revised package submission and QA policies for Fedora Extras are not known > > yet. So, fedora.us documents should be taken as a good guideline. > > I'm not bitching here, so don't take this wrong, I'm merely curious, but > if the submission and QA policies aren't set doesn't that make it hard > to say the RPM is "ready", since there are no guidelines to follow for > that? We've been following fedora.us guidelines for a long time. So one cannot say there would be no guidelines. Adhering to those guidelines would get rid of the redundant and dangerous explicit dependencies in your package (libpcap, pcre e.g.), for instance. Also, with "ready" I mean that an rpmbuild rebuild creates the binary packages as intended. The latest src.rpm you linked now still does not do that, but requires lots of manual switches. Other comments posted before. The package would benefit from a cleanup. Btw, I'm perfectly fine if somebody else wants to sponsor this package now or when it's considered ready. I find enough packages to review in the fedora.us queue. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 3 17:27:01 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 3 Feb 2005 18:27:01 +0100 Subject: snort ? In-Reply-To: <20050203182245.2325c70b.fedora@wir-sind-cool.org> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> Message-ID: <20050203182701.0b9bc1f7@python2> Michael Schwendt wrote : [...] > Also, with "ready" I mean that an rpmbuild rebuild creates the binary > packages as intended. The latest src.rpm you linked now still does not do > that, but requires lots of manual switches. Other comments posted before. > The package would benefit from a cleanup. > > Btw, I'm perfectly fine if somebody else wants to sponsor this package > now or when it's considered ready. I find enough packages to review in > the fedora.us queue. I'd be willing to cleanup, test and import the package. I last used snort about 4 or 5 years ago, but am quite curious to see how it has evolved ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3 Load : 1.63 0.91 0.91 From fedora at wir-sind-cool.org Thu Feb 3 17:29:32 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 3 Feb 2005 18:29:32 +0100 Subject: Anjuta deps In-Reply-To: <20050203181708.2e28db6c@python2> References: <420249B1.8000406@gmail.com> <20050203175632.49ef4f4a.fedora@wir-sind-cool.org> <20050203181708.2e28db6c@python2> Message-ID: <20050203182932.020bc562.fedora@wir-sind-cool.org> On Thu, 3 Feb 2005 18:17:08 +0100, Matthias Saou wrote: > BTW, about the anjuta rpm, one thing that needs fixing is adding > gettext-devel to the requirements. I just got this report from a user : > > -- > > From: "Paul Frields" > Subject: Anjuta RPM suggestion > > If gettext-devel is not installed, anjuta will fail to autogenerate > Makefile.in (and intl/ folder skeleton) for new projects as new users might > > expect. The program defaults as installed then generate errors, which is > not > consistent with Fedora behavioral guidelines. Would it be possible to add a > > Requires: gettext-devel for your package so that the behavior is as > expected? Thanks Matthias, I enjoy mirroring your site for use by workers > here in our office. > > -- > > If pcompton is lurking, I hope he'll pick it up, otherwise, the next person > to open a bug report could include it as a bonus ;-) What do you think? Should it also require autoconf, automake and what else it may run in its autogen scripts? IIRC, we've had the topic before somewhere, and if some of the tools are considered optional, a separate anjuta-foo meta package could pull in a complete build environment. -- Fedora Core release 3 (Heidelberg) - Linux 2.6.10-1.760_FC3 loadavg: 1.01 1.02 1.03 From daniel-wittenberg at starken.com Thu Feb 3 17:36:03 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Thu, 03 Feb 2005 11:36:03 -0600 Subject: snort ? In-Reply-To: <20050203182245.2325c70b.fedora@wir-sind-cool.org> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> Message-ID: <1107452163.23434.23.camel@forensic.starken.com> > We've been following fedora.us guidelines for a long time. So one cannot > say there would be no guidelines. Adhering to those guidelines would get > rid of the redundant and dangerous explicit dependencies in your package > (libpcap, pcre e.g.), for instance. What do you mean by 'redundant and dangerous' dependencies? Just to be clear, you mean the Requires and not the BuildRequires correct? We had problems in the past with those not being picked up correctly, which is why they were explicitly listed. It looks like they are build fine now on fc3 so they can probably be removed from the Requires section. So while it may not be possibly needed now, how is it considered dangerous? > Also, with "ready" I mean that an rpmbuild rebuild creates the binary > packages as intended. The latest src.rpm you linked now still does not do > that, but requires lots of manual switches. Other comments posted before. > The package would benefit from a cleanup. Can you give specifics about what you are talking please. Dan From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 3 17:55:26 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 3 Feb 2005 18:55:26 +0100 Subject: Anjuta deps In-Reply-To: <20050203182932.020bc562.fedora@wir-sind-cool.org> References: <420249B1.8000406@gmail.com> <20050203175632.49ef4f4a.fedora@wir-sind-cool.org> <20050203181708.2e28db6c@python2> <20050203182932.020bc562.fedora@wir-sind-cool.org> Message-ID: <20050203185526.2b7f5e7f@python2> Michael Schwendt wrote : > What do you think? Should it also require autoconf, automake and what else > it may run in its autogen scripts? IIRC, we've had the topic before > somewhere, and if some of the tools are considered optional, a separate > anjuta-foo meta package could pull in a complete build environment. Well, I don't really like meta-packages, and anjuta's main targets are definitely C/C++ programmers, so it would make sense to me. But I'm sure plenty of others will think otherwise ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3 Load : 0.03 0.34 0.64 From fedora at leemhuis.info Thu Feb 3 17:58:41 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 03 Feb 2005 18:58:41 +0100 Subject: Anjuta x86_64 crashes when creatina a new project. In-Reply-To: <20050203175632.49ef4f4a.fedora@wir-sind-cool.org> References: <420249B1.8000406@gmail.com> <20050203175632.49ef4f4a.fedora@wir-sind-cool.org> Message-ID: <1107453521.5968.3.camel@localhost.localdomain> Am Donnerstag, den 03.02.2005, 17:56 +0100 schrieb Michael Schwendt: > On Thu, 03 Feb 2005 10:56:33 -0500, Dawid Zamirski wrote: > > > Regardless of the project type I choose, the program throws the > > following error message: > > > > "The Application "anjuta" has quit unexpectedly. > > You can inform the developers of what happened to help them fix it. Or > > you can restart the application right now." > > > > It happerns when it launches autogen.sh > > I didn't have such problem with Anjuta-1.2.2-3.1 from dag repository. > > Could be true. Please file a bug report at http://bugzilla.redhat.com > > Can anybody confirm this and contribute some trouble-shooting? Confirmed. See also: https://bugzilla.redhat.com/beta/show_bug.cgi?id=147010 -- Thorsten Leemhuis From kevinverma at gmail.com Thu Feb 3 18:01:04 2005 From: kevinverma at gmail.com (Kevin Verma) Date: Thu, 3 Feb 2005 22:01:04 +0400 Subject: swsusp, thinkpad module, bootsplash Message-ID: <200502032201.04483.kevinverma@gmail.com> Hi, I just want to bring a list of packages I desire some one to create for Fedora under extras. All relates to the kernel package maybe some one will love to patch swsusp2, thinkpad module & bootsplash to Fedora core 3 kernel. http://softwaresuspend.berlios.de/ http://bootsplash.org/ http://bootsplash.de Regards, From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 3 18:03:34 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 3 Feb 2005 19:03:34 +0100 Subject: snort ? In-Reply-To: <20050203182701.0b9bc1f7@python2> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> Message-ID: <20050203190334.32ecc663@python2> Matthias Saou wrote : > Michael Schwendt wrote : > > [...] > > Also, with "ready" I mean that an rpmbuild rebuild creates the binary > > packages as intended. The latest src.rpm you linked now still does not do > > that, but requires lots of manual switches. Other comments posted before. > > The package would benefit from a cleanup. > > > > Btw, I'm perfectly fine if somebody else wants to sponsor this package > > now or when it's considered ready. I find enough packages to review in > > the fedora.us queue. > > I'd be willing to cleanup, test and import the package. I last used snort > about 4 or 5 years ago, but am quite curious to see how it has evolved ;-) Started looking at it... yes, there is quite some cleanup to be done to get a readable Fedora-centric spec, but nothing too hard. My main concern, and I'd like opinions regarding it, is with the database backends. I see two immediate solutions : 1) Link against both mysql and postgresql and have the package require both database's libs by default. 2) Keep different binaries as it is now, but replace the nasty scriplets that link "snort" to the various "snort-*" binaries and use alternatives instead. I personally prefer 1), while providing --without rebuild switches for both backends (and keeping a --with oracle, as it doesn't cost much, like there is in the php spec). Dan : I hope you don't see this as a "hostile takeover" of the spec, it's just that having it shorter and more readable will greatly help maintaining the package. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3 Load : 0.25 0.31 0.54 From skvidal at phy.duke.edu Thu Feb 3 18:09:23 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 03 Feb 2005 13:09:23 -0500 Subject: Anjuta x86_64 crashes when creatina a new project. In-Reply-To: <20050203175632.49ef4f4a.fedora@wir-sind-cool.org> References: <420249B1.8000406@gmail.com> <20050203175632.49ef4f4a.fedora@wir-sind-cool.org> Message-ID: <1107454163.2013.11.camel@opus.phy.duke.edu> On Thu, 2005-02-03 at 17:56 +0100, Michael Schwendt wrote: > On Thu, 03 Feb 2005 10:56:33 -0500, Dawid Zamirski wrote: > > > Regardless of the project type I choose, the program throws the > > following error message: > > > > "The Application "anjuta" has quit unexpectedly. > > You can inform the developers of what happened to help them fix it. Or > > you can restart the application right now." > > > > It happerns when it launches autogen.sh > > I didn't have such problem with Anjuta-1.2.2-3.1 from dag repository. > > Could be true. Please file a bug report at http://bugzilla.redhat.com > > Can anybody confirm this and contribute some trouble-shooting? I tested it out on an fc3 x86_64. it works and runs just fine. but it does die on autogen.sh -sv From fedora at wir-sind-cool.org Thu Feb 3 18:09:54 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 3 Feb 2005 19:09:54 +0100 Subject: snort ? In-Reply-To: <1107452163.23434.23.camel@forensic.starken.com> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <1107452163.23434.23.camel@forensic.starken.com> Message-ID: <20050203190954.5671b1dd.fedora@wir-sind-cool.org> On Thu, 03 Feb 2005 11:36:03 -0600, Daniel Wittenberg wrote: > > We've been following fedora.us guidelines for a long time. So one cannot > > say there would be no guidelines. Adhering to those guidelines would get > > rid of the redundant and dangerous explicit dependencies in your package > > (libpcap, pcre e.g.), for instance. > > What do you mean by 'redundant and dangerous' dependencies? Just to be > clear, you mean the Requires and not the BuildRequires correct? We had > problems in the past with those not being picked up correctly, which is > why they were explicitly listed. It looks like they are build fine now > on fc3 so they can probably be removed from the Requires section. So > while it may not be possibly needed now, how is it considered dangerous? We have automatic RPM dependencies on library sonames. These are generated at the end of the rpmbuild process. Example: $ rpm -qpR snort-2.3.0-1.i386.rpm | grep cap libpcap -> libpcap.so.0.8.3 That information is enough to make modern package tools find the package which provides libpcap.so.0.8.3: $ rpm --redhatprovides libpcap.so.0.8.3 libpcap-0.8.3-7 When you add an explicit "Requires: libpcap", you tie your package against a specific package name, which may or may not provide the needed library or which may not be available anymore during an upgrade of other packages. With that, the library could not be moved into another package, e.g. libpcap0, when the main libpcap package was upgraded to libpcap.so.1. The dangers are in creating unneeded dependencies on packages, which may be obsolete or renamed during upgrades and then break your dependencies. The dangers are also in trusting these manually determined dependencies more than the actual dependencies determined by rpmbuild. If e.g. a configure script would reject an incompatible libfoo-devel and build without libfoo, your binaries would still depend on libfoo, giving a false impression. > > Also, with "ready" I mean that an rpmbuild rebuild creates the binary > > packages as intended. The latest src.rpm you linked now still does not do > > that, but requires lots of manual switches. Other comments posted before. > > The package would benefit from a cleanup. > > Can you give specifics about what you are talking please. Not repeating my previous replies, though. Most important, a default "rpmbuild --rebuild snort-2.3.0-0.fdr.1.src.rpm" creates a single package, no MySQL support, no Postgresql support, and so on. This doesn't look like intended. Ugly things I would really like to see removed: the conditional cruft for Fedora and cAos specific sections (commented on that before) and vendor/packager tag mangling, as well as the silly buildroot=/ checks which add no safety (emptying the buildroot anywhere else than at the start of %install makes a poor and confusing spec design). From ivazquez at ivazquez.net Thu Feb 3 18:26:13 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 03 Feb 2005 13:26:13 -0500 Subject: swsusp, thinkpad module, bootsplash In-Reply-To: <200502032201.04483.kevinverma@gmail.com> References: <200502032201.04483.kevinverma@gmail.com> Message-ID: <1107455174.6395.15.camel@ignacio.ignacio.lan> On Thu, 2005-02-03 at 22:01 +0400, Kevin Verma wrote: > I just want to bring a list of packages I desire some one to create for Fedora > under extras. All relates to the kernel package maybe some one will love to > patch swsusp2, thinkpad module & bootsplash to Fedora core 3 kernel. > > http://softwaresuspend.berlios.de/ I have actually tried to build 2.6.10-1.741_FC3 with swsusp2 support, but experienced a compile error during the build. http://fedora.ivazquez.net/files/kernel-2.6.spec http://fedora.ivazquez.net/files/kernel-2.6.log Also, you'll need the Fedora-specific patches for swsusp2, as well as a mkinitrd modified to support swsusp2. http://softwaresuspend.berlios.de/fedora/ http://fedora.ivazquez.net/yum/3/i386/SRPMS.alternatives/mkinitrd-4.1.18-2.iva.1.swsusp2.src.rpm http://fedora.ivazquez.net/yum/3/i386/RPMS.alternatives/mkinitrd-4.1.18-2.iva.1.swsusp2.i386.rpm -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ -------------- next part -------------- A non-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 Thu Feb 3 17:37:23 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Thu, 03 Feb 2005 11:37:23 -0600 Subject: snort ? In-Reply-To: <20050203182701.0b9bc1f7@python2> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> Message-ID: <1107452243.23434.26.camel@forensic.starken.com> I'm certainly open to making the changes if you want to send them my way. Once they are pushed into the main cvs for snort then hopefully it shouldn't need to be updated again. Can we dump the stupid naming convention since it appears nobody really follows it anyway? Dan On Thu, 2005-02-03 at 18:27 +0100, Matthias Saou wrote: > I'd be willing to cleanup, test and import the package. I last used snort > about 4 or 5 years ago, but am quite curious to see how it has evolved ;-) > > Matthias From rdieter at math.unl.edu Thu Feb 3 18:59:03 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 03 Feb 2005 12:59:03 -0600 Subject: snort ? In-Reply-To: <1107452243.23434.26.camel@forensic.starken.com> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> Message-ID: <42027477.3070408@math.unl.edu> Daniel Wittenberg wrote: > Can we dump the stupid naming convention since it appears nobody really > follows it anyway? What "stupid naming convention" are you referring to? -- Rex From fedora at wir-sind-cool.org Thu Feb 3 19:03:48 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 3 Feb 2005 20:03:48 +0100 Subject: snort ? In-Reply-To: <1107452243.23434.26.camel@forensic.starken.com> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> Message-ID: <20050203200348.20a0fea2.fedora@wir-sind-cool.org> On Thu, 03 Feb 2005 11:37:23 -0600, Daniel Wittenberg wrote: > I'm certainly open to making the changes if you want to send them my > way. Once they are pushed into the main cvs for snort then hopefully it > shouldn't need to be updated again. > > Can we dump the stupid naming convention since it appears nobody really > follows it anyway? It's stupid to assume that "nobody really follows it". Every package at fedora.us follows it with good reason. Fedora Extras no longer needs to follow it, and hence the 0.fdr. prefix is gone. From kevinverma at gmail.com Thu Feb 3 19:06:52 2005 From: kevinverma at gmail.com (Kevin Verma) Date: Thu, 3 Feb 2005 23:06:52 +0400 Subject: swsusp, thinkpad module, bootsplash In-Reply-To: <1107455174.6395.15.camel@ignacio.ignacio.lan> References: <200502032201.04483.kevinverma@gmail.com> <1107455174.6395.15.camel@ignacio.ignacio.lan> Message-ID: <200502032306.52521.kevinverma@gmail.com> I tried patching swsusp and bootsplash my self but there is a lot of code mis-match and some things I won't understand. So I decided not to take a risk. However I can always take official kernel from kernel.org but I guess it would be a good idea to take some suggestion from the famous Desktop Kernel guy. Cheers, Kevin On Thursday 03 February 2005 22:26, Ignacio Vazquez-Abrams wrote: > On Thu, 2005-02-03 at 22:01 +0400, Kevin Verma wrote: > > I just want to bring a list of packages I desire some one to create for > > Fedora under extras. All relates to the kernel package maybe some one > > will love to patch swsusp2, thinkpad module & bootsplash to Fedora core 3 > > kernel. > > > > http://softwaresuspend.berlios.de/ > > I have actually tried to build 2.6.10-1.741_FC3 with swsusp2 support, > but experienced a compile error during the build. > > http://fedora.ivazquez.net/files/kernel-2.6.spec > http://fedora.ivazquez.net/files/kernel-2.6.log > > Also, you'll need the Fedora-specific patches for swsusp2, as well as a > mkinitrd modified to support swsusp2. > > http://softwaresuspend.berlios.de/fedora/ > > http://fedora.ivazquez.net/yum/3/i386/SRPMS.alternatives/mkinitrd-4.1.18-2. >iva.1.swsusp2.src.rpm > > http://fedora.ivazquez.net/yum/3/i386/RPMS.alternatives/mkinitrd-4.1.18-2.i >va.1.swsusp2.i386.rpm From gmureddu at prodigy.net.mx Thu Feb 3 19:17:49 2005 From: gmureddu at prodigy.net.mx (Gain Paolo Mureddu) Date: Thu, 03 Feb 2005 13:17:49 -0600 Subject: swsusp, thinkpad module, bootsplash In-Reply-To: <200502032201.04483.kevinverma@gmail.com> References: <200502032201.04483.kevinverma@gmail.com> Message-ID: <420278DD.6020708@prodigy.net.mx> Kevin Verma wrote: >Hi, > >I just want to bring a list of packages I desire some one to create for Fedora >under extras. All relates to the kernel package maybe some one will love to >patch swsusp2, thinkpad module & bootsplash to Fedora core 3 kernel. > >http://softwaresuspend.berlios.de/ >http://bootsplash.org/ >http://bootsplash.de > >Regards, > >-- >fedora-extras-list mailing list >fedora-extras-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-extras-list > > > As for bootsplash, I've tried to make a vanilla kernel with a mixture of the patchsets of Alan Cox and Con Kolivas (one for features and the other for performance) which incidentally add support for bootsplash. As you may already know, bootsplash also requires userspace applications to be used and configured... Anyway, I built the kernel, does boot right, but for some strange reason, whenever I configure bootsplash with a given theme, the new kernel will simply NOT display it, no matter what I do. I've tried to do this very same procedure, with the same patches and source in a Gentoo computer and userspace programs, and there was no problem... WTH?!?! I'm pretty sure there must be something that prevents its initialization from the initrd, but what? It doesn't matter whether you specify or not a different resolution of the framebuffered console (even if you compile *wthout* logo support, as you are supposed to) so something like vga=791 won't work even though newer bootsplahs addimitedly has support for 16-bit framebuffers, but if I specify vga=792 for a 32-bit (24-bit) 1024x768 framebuffer ti doesn't work either. I'll keep trying to get this working with a vanilla kernel and maybe be able to extrapolate from there (trying to use as close as I can the same patches Red Hat uses for the kernels, without using those of the .src.rpm). I can't promise anything... I really think that a bootspalsh based graphical boot is preferable over the current X based one, not only becuase of the overhead, but because of sustomizeablity (I haven't found where to customize RHGB, and I've been looking for a way since FC1) From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 3 19:20:26 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 3 Feb 2005 20:20:26 +0100 Subject: snort ? In-Reply-To: <1107452243.23434.26.camel@forensic.starken.com> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> Message-ID: <20050203202026.76300c95@python2> Daniel Wittenberg wrote : > I'm certainly open to making the changes if you want to send them my > way. Once they are pushed into the main cvs for snort then hopefully it > shouldn't need to be updated again. Here's my first go : http://ftp.us.freshrpms.net/pub/freshrpms/fedora/linux/testing/3/snort/ Please note that I've basically rewritten the spec file... I see no reason why it wouldn't build fine on cAos or any other major rpm-based distribution, though. Both MySQL and PostgreSQL support are included by default, but can be disabled, and Oracle support is optional and working (I've tested building against 9i). I haven't tested resulting binary packages at all yet, nor have I looked at the init script, sysconfig file or logrotate entry, which are taken from the original source. But I'll do some testing now, and finish off the last remaining bit : the log directory (which isn't included yet). Feedback very welcome of course! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3 Load : 0.15 0.34 0.43 From daniel-wittenberg at starken.com Thu Feb 3 19:26:45 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Thu, 03 Feb 2005 13:26:45 -0600 Subject: snort ? In-Reply-To: <42027477.3070408@math.unl.edu> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> <42027477.3070408@math.unl.edu> Message-ID: <1107458805.5055.1.camel@localhost.localdomain> http://www.fedora.us/wiki/PackageNamingGuidelines This includes using fdr in the package name, which nobody really follows anyway, which is why I think it's stupid as a standard because nobody follows it include the official Fedora package maintainers. If it is legacy it should be removed. Dan On Thu, 2005-02-03 at 12:59 -0600, Rex Dieter wrote: > Daniel Wittenberg wrote: > > > Can we dump the stupid naming convention since it appears nobody really > > follows it anyway? > > What "stupid naming convention" are you referring to? > > -- Rex > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list -------------- next part -------------- A non-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 Thu Feb 3 19:28:28 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Thu, 03 Feb 2005 13:28:28 -0600 Subject: snort ? In-Reply-To: <20050203200348.20a0fea2.fedora@wir-sind-cool.org> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> <20050203200348.20a0fea2.fedora@wir-sind-cool.org> Message-ID: <1107458908.5055.4.camel@localhost.localdomain> Ok, maybe stupid to assume nobody follows it, but I haven't seen any packages that actually follow it. Dan On Thu, 2005-02-03 at 20:03 +0100, Michael Schwendt wrote: > On Thu, 03 Feb 2005 11:37:23 -0600, Daniel Wittenberg wrote: > > > I'm certainly open to making the changes if you want to send them my > > way. Once they are pushed into the main cvs for snort then hopefully it > > shouldn't need to be updated again. > > > > Can we dump the stupid naming convention since it appears nobody really > > follows it anyway? > > It's stupid to assume that "nobody really follows it". Every package at > fedora.us follows it with good reason. Fedora Extras no longer needs to > follow it, and hence the 0.fdr. prefix is gone. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From joe at eshu.net Thu Feb 3 19:28:33 2005 From: joe at eshu.net (Joe Christy) Date: Thu, 03 Feb 2005 11:28:33 -0800 Subject: swsusp, thinkpad module, bootsplash In-Reply-To: <200502032306.52521.kevinverma@gmail.com> References: <200502032201.04483.kevinverma@gmail.com> <1107455174.6395.15.camel@ignacio.ignacio.lan> <200502032306.52521.kevinverma@gmail.com> Message-ID: <42027B61.8050709@eshu.net> Having patched about half a dozen successive Fedora kernels for swsusp2, I don't see how one could build a swsusp2 package - a new kernel package, maybe, but that would perhaps cause some suport issues? More importantly, while I can now now do the Fedora/swsusp2 thing fairly painlessly now, I haven't had the time to figure out how to build a reasonable kernel rpm that incorporates swsusp2, because of the way swsusp2 uses its apply script. In any case, I'm in the process of adding 010-pre and 990-post patches for swsusp against kernel-2.6.10-1.760_FC3 now, and I correspond regularly with the swsusp2 maintainers, so it should show up at http://softwaresuspend.berlios.de/fedora/ before too long. Joe -- ============================= Joe Christy ============================== ------------------ http://public.xdi.org/=joe.christy ------------------ == If I can save you any time, give it to me, I'll keep it with mine. == From daniel-wittenberg at starken.com Thu Feb 3 19:29:52 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Thu, 03 Feb 2005 13:29:52 -0600 Subject: snort ? (last time) Message-ID: <1107458992.5055.6.camel@localhost.localdomain> Sorry guys, I really didn't mean to be such a PITA about this, so I think I'll just shutup now and let you guys do what you think is right. 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 rdieter at math.unl.edu Thu Feb 3 19:33:11 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 03 Feb 2005 13:33:11 -0600 Subject: snort ? In-Reply-To: <1107458805.5055.1.camel@localhost.localdomain> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> <42027477.3070408@math.unl.edu> <1107458805.5055.1.camel@localhost.localdomain> Message-ID: <42027C77.6090706@math.unl.edu> Daniel Wittenberg wrote: > http://www.fedora.us/wiki/PackageNamingGuidelines > > This includes using fdr in the package name, which nobody really follows > anyway, which is why I think it's stupid as a standard because nobody > follows it include the official Fedora package maintainers. If it is > legacy it should be removed. IMO, it's not stupid, and all packages hosted at fedora.us follow that scheme. -- Rex From byte at aeon.com.my Thu Feb 3 19:26:45 2005 From: byte at aeon.com.my (Colin Charles) Date: Fri, 04 Feb 2005 00:56:45 +0530 Subject: fedora-extras-release In-Reply-To: <1107415133.7339.25.camel@cutter> References: <1107406975.7339.1.camel@cutter> <20050203071322.GC8404@nostromo.devel.redhat.com> <1107415133.7339.25.camel@cutter> Message-ID: <1107458805.5647.78.camel@localhost.localdomain> On Thu, 2005-02-03 at 02:18 -0500, seth vidal wrote: > I was almost thinking, maybe put a fedora-extras package in fedora > core. > > > so a user, if they so desired, could: > yum install fedora-extras > > and then once it's done they have the extras repo all ready to go. > > thoughts? Good idea, can we have this sorted now? What are thoughts on including a package into Core, *after* its been released? I guess this is a noble aim for FC-4 - we have a "fedora-extras" package that basically provides /etc/yum.repos.d/fedora-extras.repo and the ones in /usr/share/rhn, /usr/share/doc/fedora-release-$releasever -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From bdpepple at ameritech.net Thu Feb 3 19:34:00 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Thu, 03 Feb 2005 14:34:00 -0500 Subject: snort ? In-Reply-To: <1107458805.5055.1.camel@localhost.localdomain> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> <42027477.3070408@math.unl.edu> <1107458805.5055.1.camel@localhost.localdomain> Message-ID: <1107459240.14155.2.camel@shuttle.273piedmont.org> On Thu, 2005-02-03 at 13:26 -0600, Daniel Wittenberg wrote: > This includes using fdr in the package name, which nobody really follows > anyway, which is why I think it's stupid as a standard because nobody > follows it include the official Fedora package maintainers. If it is > legacy it should be removed. Wasn't that addressed in Michael's reply? On Thu, 2005-02-03 at 20:03 +0100, Michael Schwendt wrote: > It's stupid to assume that "nobody really follows it". Every package at > fedora.us follows it with good reason. Fedora Extras no longer needs to > follow it, and hence the 0.fdr. prefix is gone. /B -- Brian Pepple -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Thu Feb 3 19:39:22 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 03 Feb 2005 14:39:22 -0500 Subject: snort ? (last time) In-Reply-To: <1107458992.5055.6.camel@localhost.localdomain> References: <1107458992.5055.6.camel@localhost.localdomain> Message-ID: <1107459562.2013.14.camel@opus.phy.duke.edu> On Thu, 2005-02-03 at 13:29 -0600, Daniel Wittenberg wrote: > Sorry guys, I really didn't mean to be such a PITA about this, so I > think I'll just shutup now and let you guys do what you think is right. > It's not a pita. It's just growing pains. in short: the .fdr. tags are history. Don't worry with them. We don't do repo tags/branding with fedora extras packages so don't fret with them. If you have a specific release tag question, float it here and we'll get it sorted and hopefully documented as we go. Cool? -sv From adrian at lisas.de Thu Feb 3 19:40:19 2005 From: adrian at lisas.de (Adrian Reber) Date: Thu, 3 Feb 2005 20:40:19 +0100 Subject: how to use CVS Message-ID: <20050203194019.GA2868@lisas.de> Hello, I maintain some smaller packages in fedora.us which have been ported to Fedora Extras but have a newer version in fedora.us than the version in CVS. My question is now how does the upload process work. I have updated the spec and sources file in my local copy of the checkout. Before I mess something up I justed wanted to ask how do I upload a new tar.gz. Is "make upload" the correct way to upload the package? Adrian From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 3 19:42:45 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 3 Feb 2005 20:42:45 +0100 Subject: fedora-extras-release In-Reply-To: <1107458805.5647.78.camel@localhost.localdomain> References: <1107406975.7339.1.camel@cutter> <20050203071322.GC8404@nostromo.devel.redhat.com> <1107415133.7339.25.camel@cutter> <1107458805.5647.78.camel@localhost.localdomain> Message-ID: <20050203204245.1a5e03b6@python2> Colin Charles wrote : > On Thu, 2005-02-03 at 02:18 -0500, seth vidal wrote: > > I was almost thinking, maybe put a fedora-extras package in fedora > > core. > > > > > > so a user, if they so desired, could: > > yum install fedora-extras > > > > and then once it's done they have the extras repo all ready to go. > > > > thoughts? > > Good idea, can we have this sorted now? > > What are thoughts on including a package into Core, *after* its been > released? > > I guess this is a noble aim for FC-4 - we have a "fedora-extras" package > that basically provides /etc/yum.repos.d/fedora-extras.repo and the ones > in /usr/share/rhn, /usr/share/doc/fedora-release-$releasever Maybe push it out for FC < 4 as an update? Would be nice IMHO. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3 Load : 0.11 0.49 0.56 From kevinverma at gmail.com Thu Feb 3 19:43:57 2005 From: kevinverma at gmail.com (Kevin Verma) Date: Thu, 3 Feb 2005 23:43:57 +0400 Subject: Fedora Extra ISO ? Message-ID: <200502032343.57307.kevinverma@gmail.com> Are Fedora Extras available as an ISO file as well ? From daniel-wittenberg at starken.com Thu Feb 3 19:44:55 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Thu, 03 Feb 2005 13:44:55 -0600 Subject: snort ? (last time) In-Reply-To: <1107459562.2013.14.camel@opus.phy.duke.edu> References: <1107458992.5055.6.camel@localhost.localdomain> <1107459562.2013.14.camel@opus.phy.duke.edu> Message-ID: <1107459896.5055.11.camel@localhost.localdomain> Well, I'll dump those tags from the official RPMs, but it sounds like the general consensus is to start fresh and not use the old .spec. So for now I'll just watch and see what people come up with, and maybe see if we can roll the changes to the normal ones. I have no personal attachment to maintaining these, just figured I'd try to keep from duplicating effort. Dan On Thu, 2005-02-03 at 14:39 -0500, seth vidal wrote: > On Thu, 2005-02-03 at 13:29 -0600, Daniel Wittenberg wrote: > > Sorry guys, I really didn't mean to be such a PITA about this, so I > > think I'll just shutup now and let you guys do what you think is right. > > > > It's not a pita. It's just growing pains. > > in short: > > the .fdr. tags are history. Don't worry with them. > > We don't do repo tags/branding with fedora extras packages so don't fret > with them. > > If you have a specific release tag question, float it here and we'll > get it sorted and hopefully documented as we go. > > Cool? > > -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Thu Feb 3 19:45:50 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 03 Feb 2005 14:45:50 -0500 Subject: Fedora Extra ISO ? In-Reply-To: <200502032343.57307.kevinverma@gmail.com> References: <200502032343.57307.kevinverma@gmail.com> Message-ID: <1107459950.2013.18.camel@opus.phy.duke.edu> On Thu, 2005-02-03 at 23:43 +0400, Kevin Verma wrote: > Are Fedora Extras available as an ISO file as well ? > No. Not at this time and it is being debated whether or not they ever will be. -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 3 19:49:13 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 3 Feb 2005 20:49:13 +0100 Subject: snort ? In-Reply-To: <20050203202026.76300c95@python2> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> <20050203202026.76300c95@python2> Message-ID: <20050203204913.4fbc51f4@python2> Matthias Saou wrote : > Here's my first go : > http://ftp.us.freshrpms.net/pub/freshrpms/fedora/linux/testing/3/snort/ I've now replaced it with the second go : Change /etc/snort to 0640 and include /var/log/snort with 0640 permissions as well. It runs, but I don't know much more, so any kind of further testing is most welcome ;-) I have no problem temporarily maintaining this package in Extras if needed, until things settle down and someone else can finally pick it up. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3 Load : 0.07 0.23 0.41 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 3 19:54:19 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 3 Feb 2005 20:54:19 +0100 Subject: snort ? (last time) In-Reply-To: <1107459896.5055.11.camel@localhost.localdomain> References: <1107458992.5055.6.camel@localhost.localdomain> <1107459562.2013.14.camel@opus.phy.duke.edu> <1107459896.5055.11.camel@localhost.localdomain> Message-ID: <20050203205419.5ea061a0@python2> Daniel Wittenberg wrote : > Well, I'll dump those tags from the official RPMs, but it sounds like > the general consensus is to start fresh and not use the old .spec. So > for now I'll just watch and see what people come up with, and maybe see > if we can roll the changes to the normal ones. I have no personal > attachment to maintaining these, just figured I'd try to keep from > duplicating effort. The consensus in Fedora Extras could be put like this : 1) Reuse fedora.us package if it exists... 2) If not, reuse freshrpms.net package if it exists... 3) If not, reuse what could have been pending at fedora.us... 4) If it wasn't there, or is too old, or too messy, then... 5) Come up with a new package from whatever source seems best :-) The main limitation at the moment is that the Fedora Extras submission process isn't perfectly defined yet, unlike the fedora.us one was. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3 Load : 0.12 0.30 0.40 From fedora at wir-sind-cool.org Thu Feb 3 19:54:29 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 3 Feb 2005 20:54:29 +0100 Subject: snort ? In-Reply-To: <1107458908.5055.4.camel@localhost.localdomain> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> <20050203200348.20a0fea2.fedora@wir-sind-cool.org> <1107458908.5055.4.camel@localhost.localdomain> Message-ID: <20050203205429.2a3c7c7e.fedora@wir-sind-cool.org> On Thu, 03 Feb 2005 13:28:28 -0600, Daniel Wittenberg wrote: > Ok, maybe stupid to assume nobody follows it, but I haven't seen any > packages that actually follow it. Daniel, please stop here acting like this. I wrote explicitly that _all_ packages in fedora.us adhere to those naming guidelines. See quote below. With regard to the old fedora.us Wiki, it's closed and no longer updated. See Wiki main page. And yes, in the newer fedoraproject.org Wiki, the same information could be removed. But every day has just 24 hours, developers are busy with other stuff, and hardly anyone did miss the changes in Fedora pre-Extras and CVS. > Dan > > On Thu, 2005-02-03 at 20:03 +0100, Michael Schwendt wrote: > > On Thu, 03 Feb 2005 11:37:23 -0600, Daniel Wittenberg wrote: > > > > > I'm certainly open to making the changes if you want to send them my > > > way. Once they are pushed into the main cvs for snort then hopefully it > > > shouldn't need to be updated again. > > > > > > Can we dump the stupid naming convention since it appears nobody really > > > follows it anyway? > > > > It's stupid to assume that "nobody really follows it". Every package at > > fedora.us follows it with good reason. Fedora Extras no longer needs to > > follow it, and hence the 0.fdr. prefix is gone. From fedora at wir-sind-cool.org Thu Feb 3 20:02:46 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 3 Feb 2005 21:02:46 +0100 Subject: how to use CVS In-Reply-To: <20050203194019.GA2868@lisas.de> References: <20050203194019.GA2868@lisas.de> Message-ID: <20050203210246.2327cde0.fedora@wir-sind-cool.org> On Thu, 3 Feb 2005 20:40:19 +0100, Adrian Reber wrote: > I maintain some smaller packages in fedora.us which have been ported to > Fedora Extras but have a newer version in fedora.us than the version in > CVS. Unbelievable. How did this happen? For the FC-2 and older branches it is likely, because these cannot be created by us (see FC3Status page in the fedoraproject.org Wiki). But for packages in "devel" all should be up-to-date. > My question is now how does the upload process work. > I have updated the spec and sources file in my local copy of the > checkout. Before I mess something up I justed wanted to ask how do I > upload a new tar.gz. Is "make upload" the correct way to upload the > package? make new-sources FILES="foo1.tar.gz foo2.tar.gz" Uploads files into lookaside cache and creates a new "sources" file in your local working copy. You need to commit the "sources" files manually. make upload FILES="foo1.tar.gz foo2.tar.gz" Same as above, but _appends_ to local "sources" files. cvs-import.sh Can auto-import full source rpms and create new modules on-the-fly. Default branch is "devel". Other branches like "-b FC-2". HTH From daniel-wittenberg at starken.com Thu Feb 3 20:04:32 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Thu, 03 Feb 2005 14:04:32 -0600 Subject: snort ? In-Reply-To: <20050203205429.2a3c7c7e.fedora@wir-sind-cool.org> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> <20050203200348.20a0fea2.fedora@wir-sind-cool.org> <1107458908.5055.4.camel@localhost.localdomain> <20050203205429.2a3c7c7e.fedora@wir-sind-cool.org> Message-ID: <1107461072.5055.20.camel@localhost.localdomain> I am obviously missing something, so I'm gonna just sit back and watch the list now. When I look at the package names at: http://download.fedora.us/fedora/fedora/3/i386/RPMS.os/ That's why I said I had never seen the naming convention followed. I realize there aren't enough hours in the day to get everything done, but when the information I have found on naming convention doens't match what I see the repo's, that is where my statement comes from. I understand what you are saying, but that doesn't match what is shown on the website, and how am I supposed to know that what is on the website is wrong and outdated ? If there is a new one I'd like to see it because I'm obviously confused and would like to understand how things are going to work. I'm not trying to start a fight or anything, just I'm very confused and have been willing to help push snort out and contribute what little I can to opensource. For now I'll just sit and watch and maybe I can learn something since I seem to be doing more harm than good. Dan > Daniel, please stop here acting like this. I wrote explicitly that > _all_ packages in fedora.us adhere to those naming guidelines. See > quote below. > > With regard to the old fedora.us Wiki, it's closed and no longer > updated. See Wiki main page. And yes, in the newer fedoraproject.org > Wiki, the same information could be removed. But every day has just > 24 hours, developers are busy with other stuff, and hardly anyone > did miss the changes in Fedora pre-Extras and CVS. -------------- next part -------------- A non-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 Feb 3 20:05:02 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 03 Feb 2005 21:05:02 +0100 Subject: snort ? In-Reply-To: <20050203202026.76300c95@python2> (Matthias Saou's message of "Thu, 3 Feb 2005 20:20:26 +0100") References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> <20050203202026.76300c95@python2> Message-ID: <876519csup.fsf@kosh.ultra.csn.tu-chemnitz.de> Matthias Saou writes: >> I'm certainly open to making the changes if you want to send them my >> way. Once they are pushed into the main cvs for snort then hopefully it >> shouldn't need to be updated again. > > Here's my first go : > http://ftp.us.freshrpms.net/pub/freshrpms/fedora/linux/testing/3/snort/ > ... > Feedback very welcome of course! ok... * is there a 'make' missing in %build? * rules should be installed with the '-p' switch to keep timestamps (useful e.g. for automatic updates) * %{_sysconfdir}/rc.d/init.d should be written as %_initrddir * Requires(...): are missing for the %scriptlets * I would put the rules into a separate subpackage to allow easier updates * As I like and use minimal systems I would prefer -mysql, -postgresql subpackages which use 'alternatives' to set a link to /usr/sbin/snortd. So, unneeded dependencies will be prevented Enrico From ville.skytta at iki.fi Thu Feb 3 20:09:23 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 03 Feb 2005 22:09:23 +0200 Subject: how to use CVS In-Reply-To: <20050203194019.GA2868@lisas.de> References: <20050203194019.GA2868@lisas.de> Message-ID: <1107461363.20626.14.camel@bobcat.mine.nu> On Thu, 2005-02-03 at 20:40 +0100, Adrian Reber wrote: > I have updated the spec and sources file in my local copy of the > checkout. Before I mess something up I justed wanted to ask how do I > upload a new tar.gz. Is "make upload" the correct way to upload the > package? s/the package/the tarball/, yes. "make upload FILES=foo-1.0.tar.gz" in foo/devel will upload the tarball, and additionally update "sources" and ".cvsignore" for you, but not commit them. You may need to revert the manually made changes to those files before "make upload" to make it work. IIRC. From fedora at wir-sind-cool.org Thu Feb 3 20:10:03 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 3 Feb 2005 21:10:03 +0100 Subject: snort ? In-Reply-To: <1107461072.5055.20.camel@localhost.localdomain> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> <20050203200348.20a0fea2.fedora@wir-sind-cool.org> <1107458908.5055.4.camel@localhost.localdomain> <20050203205429.2a3c7c7e.fedora@wir-sind-cool.org> <1107461072.5055.20.camel@localhost.localdomain> Message-ID: <20050203211003.4f3d3b67.fedora@wir-sind-cool.org> On Thu, 03 Feb 2005 14:04:32 -0600, Daniel Wittenberg wrote: > I am obviously missing something, so I'm gonna just sit back and watch > the list now. When I look at the package names at: > > http://download.fedora.us/fedora/fedora/3/i386/RPMS.os/ > > That's why I said I had never seen the naming convention followed. *sigh* That's Fedora Core (!) mirrored at download.fedora.us! Look here! This is Fedora.us Extras: http://download.fedora.us/fedora/fedora/2/i386/RPMS.stable/ From rdieter at math.unl.edu Thu Feb 3 20:11:50 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 03 Feb 2005 14:11:50 -0600 Subject: snort ? In-Reply-To: <1107461072.5055.20.camel@localhost.localdomain> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> <20050203200348.20a0fea2.fedora@wir-sind-cool.org> <1107458908.5055.4.camel@localhost.localdomain> <20050203205429.2a3c7c7e.fedora@wir-sind-cool.org> <1107461072.5055.20.camel@localhost.localdomain> Message-ID: <42028586.30309@math.unl.edu> Daniel Wittenberg wrote: > I am obviously missing something, so I'm gonna just sit back and watch > the list now. When I look at the package names at: > > http://download.fedora.us/fedora/fedora/3/i386/RPMS.os/ > > That's why I said I had never seen the naming convention followed. Those are "core" OS files from redhat, *not* from Fedora Extras. -- Rex From daniel-wittenberg at starken.com Thu Feb 3 20:18:42 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Thu, 03 Feb 2005 14:18:42 -0600 Subject: snort ? In-Reply-To: <20050203211003.4f3d3b67.fedora@wir-sind-cool.org> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> <20050203200348.20a0fea2.fedora@wir-sind-cool.org> <1107458908.5055.4.camel@localhost.localdomain> <20050203205429.2a3c7c7e.fedora@wir-sind-cool.org> <1107461072.5055.20.camel@localhost.localdomain> <20050203211003.4f3d3b67.fedora@wir-sind-cool.org> Message-ID: <1107461923.5055.25.camel@localhost.localdomain> Ok, I feel stupider by the minute, but how can you tell that it is extras? It looks at first glance to me like just the Fedora Core 2 RPM's? Dan On Thu, 2005-02-03 at 21:10 +0100, Michael Schwendt wrote: > On Thu, 03 Feb 2005 14:04:32 -0600, Daniel Wittenberg wrote: > > > I am obviously missing something, so I'm gonna just sit back and watch > > the list now. When I look at the package names at: > > > > http://download.fedora.us/fedora/fedora/3/i386/RPMS.os/ > > > > That's why I said I had never seen the naming convention followed. > > *sigh* > > That's Fedora Core (!) mirrored at download.fedora.us! > > > Look here! This is Fedora.us Extras: > > http://download.fedora.us/fedora/fedora/2/i386/RPMS.stable/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Thu Feb 3 20:19:23 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 03 Feb 2005 15:19:23 -0500 Subject: snort ? In-Reply-To: <20050203211003.4f3d3b67.fedora@wir-sind-cool.org> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> <20050203200348.20a0fea2.fedora@wir-sind-cool.org> <1107458908.5055.4.camel@localhost.localdomain> <20050203205429.2a3c7c7e.fedora@wir-sind-cool.org> <1107461072.5055.20.camel@localhost.localdomain> <20050203211003.4f3d3b67.fedora@wir-sind-cool.org> Message-ID: <1107461963.2013.21.camel@opus.phy.duke.edu> On Thu, 2005-02-03 at 21:10 +0100, Michael Schwendt wrote: > On Thu, 03 Feb 2005 14:04:32 -0600, Daniel Wittenberg wrote: > > > I am obviously missing something, so I'm gonna just sit back and watch > > the list now. When I look at the package names at: > > > > http://download.fedora.us/fedora/fedora/3/i386/RPMS.os/ > > > > That's why I said I had never seen the naming convention followed. > > *sigh* > > That's Fedora Core (!) mirrored at download.fedora.us! > > > Look here! This is Fedora.us Extras: > > http://download.fedora.us/fedora/fedora/2/i386/RPMS.stable/ > Here's an idea - let's just forget about what WAS at fedora.us and start focusing on what is or should be in fedora extras, okay? We're not starting from scratch, we're going to suggest strongly the spec file standard from fedora.us but we're starting from scratch on release tags and such things. Just remember, accidents happen, so if things seem goofy on a few packages then it is probably just a mistake, not anything else. cool? -sv From skvidal at phy.duke.edu Thu Feb 3 20:20:08 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 03 Feb 2005 15:20:08 -0500 Subject: snort ? In-Reply-To: <1107461923.5055.25.camel@localhost.localdomain> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> <20050203200348.20a0fea2.fedora@wir-sind-cool.org> <1107458908.5055.4.camel@localhost.localdomain> <20050203205429.2a3c7c7e.fedora@wir-sind-cool.org> <1107461072.5055.20.camel@localhost.localdomain> <20050203211003.4f3d3b67.fedora@wir-sind-cool.org> <1107461923.5055.25.camel@localhost.localdomain> Message-ID: <1107462008.2013.23.camel@opus.phy.duke.edu> On Thu, 2005-02-03 at 14:18 -0600, Daniel Wittenberg wrote: > Ok, I feel stupider by the minute, but how can you tell that it is > extras? It looks at first glance to me like just the Fedora Core 2 > RPM's? For Extras pkgs for fc3 and above you can always look at: http://fedoraproject.org/extras/ -sv From fedora at wir-sind-cool.org Thu Feb 3 20:35:13 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 3 Feb 2005 21:35:13 +0100 Subject: snort ? In-Reply-To: <1107461923.5055.25.camel@localhost.localdomain> References: <1107370990.17357.9.camel@forensic.starken.com> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> <20050203200348.20a0fea2.fedora@wir-sind-cool.org> <1107458908.5055.4.camel@localhost.localdomain> <20050203205429.2a3c7c7e.fedora@wir-sind-cool.org> <1107461072.5055.20.camel@localhost.localdomain> <20050203211003.4f3d3b67.fedora@wir-sind-cool.org> <1107461923.5055.25.camel@localhost.localdomain> Message-ID: <20050203213513.100c6d78.fedora@wir-sind-cool.org> On Thu, 03 Feb 2005 14:18:42 -0600, Daniel Wittenberg wrote: > > > I am obviously missing something, so I'm gonna just sit back and watch > > > the list now. When I look at the package names at: > > > > > > http://download.fedora.us/fedora/fedora/3/i386/RPMS.os/ > > > > > > That's why I said I had never seen the naming convention followed. > > > > *sigh* > > > > That's Fedora Core (!) mirrored at download.fedora.us! > > > > > > Look here! This is Fedora.us Extras: > > > > http://download.fedora.us/fedora/fedora/2/i386/RPMS.stable/ > > > Ok, I feel stupider by the minute, but how can you tell that it is > extras? It looks at first glance to me like just the Fedora Core 2 > RPM's? Enter parent directory where you find the individual channels os, updates, updates-testing : Fedora Core + Updates + Test Updates stable, testing, unstable : extras (!) http://www.fedora.us/wiki/FedoraHOWTO -> http://www.fedora.us/wiki/FedoraChannels But this is history. Fedora.us for FC3 never existed, since Fedora pre-Extras was created at fedoraproject.org/pre-extras. And now we have "Fedora Extras": http://download.fedora.redhat.com/pub/fedora/linux/extras/ From kevinverma at gmail.com Thu Feb 3 20:56:37 2005 From: kevinverma at gmail.com (Kevin Verma) Date: Fri, 4 Feb 2005 00:56:37 +0400 Subject: swsusp, thinkpad module, bootsplash In-Reply-To: <420278DD.6020708@prodigy.net.mx> References: <200502032201.04483.kevinverma@gmail.com> <420278DD.6020708@prodigy.net.mx> Message-ID: <200502040056.37241.kevinverma@gmail.com> On Thursday 03 February 2005 23:17, Gain Paolo Mureddu wrote: > As for bootsplash, I've tried to make a vanilla kernel with a mixture of > the patchsets of Alan Cox and Con Kolivas (one for features and the > other for performance) which incidentally add support for bootsplash. As > you may already know, bootsplash also requires userspace applications to > be used and configured... Anyway, I built the kernel, does boot right, > but for some strange reason, whenever I configure bootsplash with a > given theme, the new kernel will simply NOT display it, no matter what > I do. I've tried to do this very same procedure, with the same patches > and source in a Gentoo computer and userspace programs, and there was no > problem... WTH?!?! I guess its the udev which causes this problem, I am not too sure will like to investigate better this time. > > I'm pretty sure there must be something that prevents its initialization > from the initrd, but what? It doesn't matter whether you specify or not > a different resolution of the framebuffered console (even if you compile > *wthout* logo support, as you are supposed to) so something like vga=791 > won't work even though newer bootsplahs addimitedly has support for > 16-bit framebuffers, but if I specify vga=792 for a 32-bit (24-bit) > 1024x768 framebuffer ti doesn't work either. I'll keep trying to get > this working with a vanilla kernel and maybe be able to extrapolate from > there (trying to use as close as I can the same patches Red Hat uses for > the kernels, without using those of the .src.rpm). I can't promise > anything... I really think that a bootspalsh based graphical boot is > preferable over the current X based one, not only becuase of the > overhead, but because of sustomizeablity (I haven't found where to > customize RHGB, and I've been looking for a way since FC1) RHGB is not good enough bootsplash seems to be better, and as a user I'd like a choice, bootsplash better. I think as per Joe Christy it will be good to follow his work of swsusp and then pre-pare bootsplash patches. http://softwaresuspend.berlios.de/fedora/ I'd request Joe to share his latest patches with us. Cheers, From skvidal at phy.duke.edu Thu Feb 3 21:07:31 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 03 Feb 2005 16:07:31 -0500 Subject: fedora-extras-release In-Reply-To: <20050203204245.1a5e03b6@python2> References: <1107406975.7339.1.camel@cutter> <20050203071322.GC8404@nostromo.devel.redhat.com> <1107415133.7339.25.camel@cutter> <1107458805.5647.78.camel@localhost.localdomain> <20050203204245.1a5e03b6@python2> Message-ID: <1107464852.2013.38.camel@opus.phy.duke.edu> On Thu, 2005-02-03 at 20:42 +0100, Matthias Saou wrote: > Colin Charles wrote : > > > On Thu, 2005-02-03 at 02:18 -0500, seth vidal wrote: > > > I was almost thinking, maybe put a fedora-extras package in fedora > > > core. > > > > > > > > > so a user, if they so desired, could: > > > yum install fedora-extras > > > > > > and then once it's done they have the extras repo all ready to go. > > > > > > thoughts? > > > > Good idea, can we have this sorted now? > > > > What are thoughts on including a package into Core, *after* its been > > released? > > > > I guess this is a noble aim for FC-4 - we have a "fedora-extras" package > > that basically provides /etc/yum.repos.d/fedora-extras.repo and the ones > > in /usr/share/rhn, /usr/share/doc/fedora-release-$releasever > > Maybe push it out for FC < 4 as an update? Would be nice IMHO. > I got the following, terribly verbose, response from notting when I posed the thought to him: skvidal: worksforme Matthias, you wanna put it together or should I? We're thinking: include the repos from the readme.extras at: http://fedoraproject.org/extras/readme.extras put them both in one file and maybe include the gpg key in %docs -sv From kevinverma at gmail.com Thu Feb 3 21:11:50 2005 From: kevinverma at gmail.com (Kevin Verma) Date: Fri, 4 Feb 2005 01:11:50 +0400 Subject: swsusp, thinkpad module, bootsplash In-Reply-To: <42027B61.8050709@eshu.net> References: <200502032201.04483.kevinverma@gmail.com> <200502032306.52521.kevinverma@gmail.com> <42027B61.8050709@eshu.net> Message-ID: <200502040111.51051.kevinverma@gmail.com> On Thursday 03 February 2005 23:28, Joe Christy wrote: > Having patched about half a dozen successive Fedora kernels for swsusp2, > I don't see how one could build a swsusp2 package - a new kernel > package, maybe, but that would perhaps cause some suport issues? > > More importantly, while I can now now do the Fedora/swsusp2 thing fairly > painlessly now, I haven't had the time to figure out how to build a > reasonable kernel rpm that incorporates swsusp2, because of the way > swsusp2 uses its apply script. > > In any case, I'm in the process of adding 010-pre and 990-post patches > for swsusp against kernel-2.6.10-1.760_FC3 now, and I correspond > regularly with the swsusp2 maintainers, so it should show up at > http://softwaresuspend.berlios.de/fedora/ before too long. Joe, I used the current information on http://softwaresuspend.berlios.de/fedora/ and the patches as provided wget -c http://download.berlios.de/softwaresuspend/software-suspend-2.1.5.15-for-2.6.10.tar.bz2 wget -c http://softwaresuspend.berlios.de/fedora/010-2.6.10-1.741-to-2.1.5.15-pre wget -c http://softwaresuspend.berlios.de/fedora/990-2.6.10-1.741-to-2.1.5.15-post # rpmbuild -bp --target=i686 /usr/src/redhat/SPECS/kernel-2.6.spec using kernel-2.6.10-1.741_FC3 # cp 010-2.6.10-1.741-to-2.1.5.15-pre 990-2.6.10-1.741-to-2.1.5.15-post /root/software-suspend-2.1.5.15-for-2.6.10/ # cd /usr/src/redhat/BUILD/kernel-2.6.10/linux-2.6.10 # /root/software-suspend-2.1.5.15-for-2.6.10/apply Applying 010-2.6.10-1.741-to-2.1.5.15-pre ... 010-2.6.10-1.741-to-2.1.5.15-pre will not apply cleanly. Reverse applied patches [Yn]? Reversing patches... Done. Nothing happenes please suggest ... I guess I should patch by hand ... From daniel-wittenberg at starken.com Thu Feb 3 18:12:51 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Thu, 03 Feb 2005 12:12:51 -0600 Subject: snort ? In-Reply-To: <20050203190334.32ecc663@python2> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <20050203190334.32ecc663@python2> Message-ID: <1107454371.23434.31.camel@forensic.starken.com> No, but it seems to make more sense if we can come up with one, so there are dozens of copies of snort RPM's out floating around. I know of at least 3 different ones right now that all run on FC3. So if you have changes you'd like to see, how about sending them to me and I'll look at pushing them into the official RPM's ? I personally don't see what's wrong with specifying which DB you want to compile for, most people in the past have liked the fact they didn't have to install all the libraries for both just to recompile the SRPM. I mean if most of it ends up getting ripped out then it probably will mean a spec specifically for FC3, which will be different than from what you get from snort.org, which I don't like, but that's the way opensource goes I guess. Dan > Dan : I hope you don't see this as a "hostile takeover" of the spec, it's > just that having it shorter and more readable will greatly help maintaining > the package. > > Matthias From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 3 21:59:17 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 3 Feb 2005 22:59:17 +0100 Subject: snort ? In-Reply-To: <1107454371.23434.31.camel@forensic.starken.com> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <20050203190334.32ecc663@python2> <1107454371.23434.31.camel@forensic.starken.com> Message-ID: <20050203225917.7f8d4620@python2> Daniel Wittenberg wrote : > No, but it seems to make more sense if we can come up with one, so there > are dozens of copies of snort RPM's out floating around. I know of at > least 3 different ones right now that all run on FC3. So if you have > changes you'd like to see, how about sending them to me and I'll look at > pushing them into the official RPM's ? I personally don't see what's > wrong with specifying which DB you want to compile for, most people in > the past have liked the fact they didn't have to install all the > libraries for both just to recompile the SRPM. I mean if most of it > ends up getting ripped out then it probably will mean a spec > specifically for FC3, which will be different than from what you get > from snort.org, which I don't like, but that's the way opensource goes I > guess. I understand what you mean, and how you feel, but "A spec specifically for FC3, different from what you get from upstream" is what RH/FC has always been, and Fedora Extras will be no different. I do hope to see upstream included spec files and Extras spec files become identical or at least similar for packages that will be maintained by an upstream developer ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.25 0.12 0.10 From gemi at bluewin.ch Thu Feb 3 22:07:12 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Thu, 03 Feb 2005 23:07:12 +0100 Subject: General questions about Extras development Message-ID: <1107468432.13339.8.camel@scriabin.tannenrauch.ch> Now that Extras is open for package retrieval, I would like to know what the policy and procedures are going to be. I have several packages in Extras taken over from fedora.us (I have checked out the CVS) 1. How am I going to change these? 2. How can I check in new ones? 3. When are the packages built? 4. Will there be a document with precise instructions for how to create spec files and additional data present in the CVS (for the spec file there is already some information on the old site) 5. How is QA done? 6. Will the process become quicker? Regards -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 3 22:24:52 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 3 Feb 2005 23:24:52 +0100 Subject: snort ? In-Reply-To: <876519csup.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> <20050203202026.76300c95@python2> <876519csup.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20050203232452.289ca48e@python2> Enrico Scholz wrote : > > Feedback very welcome of course! > > ok... > > * is there a 'make' missing in %build? Indeed, d'oh! :-) > * rules should be installed with the '-p' switch to keep timestamps > (useful e.g. for automatic updates) Right, can always be useful. > * %{_sysconfdir}/rc.d/init.d should be written as %_initrddir That one, I'm not sure. No one has ever been able to confirm or dis-confirm to me if this confusing name was normal or actually a typo. %_initddir or %_rcinitdir I would have understood... but %_initrddir!? IMHO, having "initrd" is really weird, that's why I tend ot avoid that macro altogether :-/ > * Requires(...): are missing for the %scriptlets Yup, thanks for noticing. > * I would put the rules into a separate subpackage to allow easier > updates I guess you mean "custom" or "local" updates, right? Indeed, it could be interesting to override the defaults. So, a "snort-rules" package with mutual requirements between it and "snort" is what you'd expect? In general, I'd probably be opposed to such a split, but in this case, as this is a package that is clearly targeted at sysadmins and advanced users, it does make sense. > * As I like and use minimal systems I would prefer -mysql, -postgresql > subpackages which use 'alternatives' to set a link to > /usr/sbin/snortd. So, unneeded dependencies will be prevented I understand, but that will add quite a bit of complexity to the package... the postgresql-libs are only 360kB and don't have any special deps, so the extra 420kB created by an additional snort binary makes it a loosing situation, definitely not "worth the trouble" from my POV. OTOH, mysql pulls in 5MB+ and some deps (perl modules and eventually others on minimal systems), so maybe just only enabling PostgreSQL support by default could be done, as it is the "preferred" RH/FC detabase anyway, and leave the MySQL optional with the rpmbuild switch? Or... just have alternatives choose between the plain version and another "db" version which has both databases supported? Hey, I actually think this last idea isn't that bad :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.33 0.24 0.18 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 3 22:31:11 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 3 Feb 2005 23:31:11 +0100 Subject: fedora-extras-release In-Reply-To: <1107464852.2013.38.camel@opus.phy.duke.edu> References: <1107406975.7339.1.camel@cutter> <20050203071322.GC8404@nostromo.devel.redhat.com> <1107415133.7339.25.camel@cutter> <1107458805.5647.78.camel@localhost.localdomain> <20050203204245.1a5e03b6@python2> <1107464852.2013.38.camel@opus.phy.duke.edu> Message-ID: <20050203233111.04bbc0c2@python2> seth vidal wrote : > posed the thought to him: > > skvidal: worksforme > > > Matthias, you wanna put it together or should I? > > We're thinking: > include the repos from the readme.extras at: > http://fedoraproject.org/extras/readme.extras > > put them both in one file and maybe include the gpg key in %docs Sure, I can give it a whirl. Just two questions : 1) Wouldn't it be better to ask all the mirrors which ones intend to mirror Extras (or which ones already have!) and include a mirrorlist URL instead of a baseurl one? 2) What should the package be named? "fedora-extras"? "fedora-extras-release"? Something else? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.00 0.07 0.12 From skvidal at phy.duke.edu Thu Feb 3 22:34:25 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 03 Feb 2005 17:34:25 -0500 Subject: fedora-extras-release In-Reply-To: <20050203233111.04bbc0c2@python2> References: <1107406975.7339.1.camel@cutter> <20050203071322.GC8404@nostromo.devel.redhat.com> <1107415133.7339.25.camel@cutter> <1107458805.5647.78.camel@localhost.localdomain> <20050203204245.1a5e03b6@python2> <1107464852.2013.38.camel@opus.phy.duke.edu> <20050203233111.04bbc0c2@python2> Message-ID: <1107470065.2013.60.camel@opus.phy.duke.edu> > Sure, I can give it a whirl. Just two questions : > 1) Wouldn't it be better to ask all the mirrors which ones intend to mirror > Extras (or which ones already have!) and include a mirrorlist URL instead > of a baseurl one? > 2) What should the package be named? "fedora-extras"? > "fedora-extras-release"? Something else? oh sure, if you want to do it intelligently! :) I'll see what we can get out of the mirror people and mayb make a mirrorlist up. -sv From skvidal at phy.duke.edu Thu Feb 3 22:49:43 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 03 Feb 2005 17:49:43 -0500 Subject: General questions about Extras development In-Reply-To: <1107468432.13339.8.camel@scriabin.tannenrauch.ch> References: <1107468432.13339.8.camel@scriabin.tannenrauch.ch> Message-ID: <1107470983.2013.64.camel@opus.phy.duke.edu> On Thu, 2005-02-03 at 23:07 +0100, G?rard Milmeister wrote: > Now that Extras is open for package retrieval, I would like to know > what the policy and procedures are going to be. > > I have several packages in Extras taken over from fedora.us (I have > checked out the CVS) Here's how you go about getting a fedora extras cvs account: http://fedoraproject.org/wiki/Extras_2fCvsAccess > 1. How am I going to change these? once you get an account you can. > 2. How can I check in new ones? see one. > 3. When are the packages built? Right now you edit up this page: http://fedoraproject.org/wiki/Extras_2fFC3Status and put the build requests in the second section. Then I build them. In the future you tag a check in as to be built and it's then built. > 4. Will there be a document with precise instructions for how > to create spec files and additional data present in the CVS > (for the spec file there is already some information on the > old site) Still there, on http://fedoraproject.org/Extras > 5. How is QA done? Carefully, we hope. At first it's done by you and we can push packages into Fedora Extras Testing before they're pushed out to the world. > 6. Will the process become quicker? Right now cvs checkin to build has about a 1 day turn around time. I hope to make it faster than that in the NEAR future. Hope this helps. -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 3 22:55:21 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 3 Feb 2005 23:55:21 +0100 Subject: fedora-extras-release In-Reply-To: <1107470065.2013.60.camel@opus.phy.duke.edu> References: <1107406975.7339.1.camel@cutter> <20050203071322.GC8404@nostromo.devel.redhat.com> <1107415133.7339.25.camel@cutter> <1107458805.5647.78.camel@localhost.localdomain> <20050203204245.1a5e03b6@python2> <1107464852.2013.38.camel@opus.phy.duke.edu> <20050203233111.04bbc0c2@python2> <1107470065.2013.60.camel@opus.phy.duke.edu> Message-ID: <20050203235521.456d30df@python2> seth vidal wrote : > > Sure, I can give it a whirl. Just two questions : > > 1) Wouldn't it be better to ask all the mirrors which ones intend to mirror > > Extras (or which ones already have!) and include a mirrorlist URL instead > > of a baseurl one? > > 2) What should the package be named? "fedora-extras"? > > "fedora-extras-release"? Something else? > > oh sure, if you want to do it intelligently! :) > > I'll see what we can get out of the mirror people and mayb make a > mirrorlist up. That would be the best IMHO, as the whole point of that package, and the yum repo entry it contains, is to have everything working with only a few commands and no editing at all ;-) Attached are a .spec and .repo that could suit the job (the key at the URL from the repo is also needed). Consensus will be needed for the name, and voices heard if anything else needs to be added. Too bad though that it seems sysconfig/rhn/ can only take info from the single "sources" file, as from my understanding this means that the current RHN notification tool won't automatically be aware of Extras after this package is installed. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.16 0.27 0.18 -------------- next part -------------- A non-text attachment was scrubbed... Name: fedora-extras-release.spec Type: application/octet-stream Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fedora-extras.repo Type: application/octet-stream Size: 628 bytes Desc: not available URL: From daniel-wittenberg at starken.com Thu Feb 3 18:18:43 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Thu, 03 Feb 2005 12:18:43 -0600 Subject: snort ? In-Reply-To: <20050203190954.5671b1dd.fedora@wir-sind-cool.org> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <1107452163.23434.23.camel@forensic.starken.com> <20050203190954.5671b1dd.fedora@wir-sind-cool.org> Message-ID: <1107454723.23434.36.camel@forensic.starken.com> > Not repeating my previous replies, though. Most important, a default > "rpmbuild --rebuild snort-2.3.0-0.fdr.1.src.rpm" creates a single package, > no MySQL support, no Postgresql support, and so on. This doesn't look like > intended. Still not clear on this, when I rebuild it I get the one RPM with no DB support. ? > Ugly things I would really like to see removed: the conditional > cruft for Fedora I completely agree with this, and never liked the naming scheme for the official Fedora RPM's anyway. > and cAos specific sections (commented on that before) and > vendor/packager tag mangling, I didn't personally add the cAos build info, and still not sure what's wrong with having it there, doesn't hurt anything unless you explicitly build for it. Like having the oracle build info, it's there if you want it (and some people have used it, make their life easier), but doesn't hurt anything normally. > well as the silly buildroot=/ checks > which add no safety (emptying the buildroot anywhere else than at the > start of %install makes a poor and confusing spec design). Some of this was legacy for broken RPM setups that wouldn't do these checks, and were almost always added in response to things getting hosed. I agree that we've come along ways in the last year with RPM building that most of this stuff shouldn't happen anymore and can be cleaned up. Dan From fedora at wir-sind-cool.org Thu Feb 3 23:40:56 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 4 Feb 2005 00:40:56 +0100 Subject: snort ? In-Reply-To: <1107454723.23434.36.camel@forensic.starken.com> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <1107452163.23434.23.camel@forensic.starken.com> <20050203190954.5671b1dd.fedora@wir-sind-cool.org> <1107454723.23434.36.camel@forensic.starken.com> Message-ID: <20050204004056.63afb54b.fedora@wir-sind-cool.org> On Thu, 03 Feb 2005 12:18:43 -0600, Daniel Wittenberg wrote: > > > Not repeating my previous replies, though. Most important, a default > > "rpmbuild --rebuild snort-2.3.0-0.fdr.1.src.rpm" creates a single package, > > no MySQL support, no Postgresql support, and so on. This doesn't look like > > intended. > > Still not clear on this, when I rebuild it I get the one RPM with no DB > support. ? Unlike the packages offered for download at snort.org, unlike the older packages in fedora.us, unlike Dag's package. Why only a single package without db support? Why are all sub-packages disabled by default? > > and cAos specific sections (commented on that before) and > > vendor/packager tag mangling, > > I didn't personally add the cAos build info, and still not sure what's > wrong with having it there, doesn't hurt anything unless you explicitly > build for it. Like having the oracle build info, it's there if you want > it (and some people have used it, make their life easier), but doesn't > hurt anything normally. cAos Linux specific spec sections and an optional Oracle sub-package are two completely different things. As outlined earlier, if such cAos related sections made it into a Fedora Extras package, it would open the door for Mandrake/SuSE/whatever specific spec code as requested by other packagers who might want to add something like that. And once in CVS you would want to update those spec sections, too, although they are unrelated. Where to draw the line? I say we package for Fedora and maybe the various flavours of Red Hat Linux. If someone really packages for multiple unrelated distributions, it should not be so much effort to keep multiple spec files in sync. > > well as the silly buildroot=/ checks > > which add no safety (emptying the buildroot anywhere else than at the > > start of %install makes a poor and confusing spec design). > > Some of this was legacy for broken RPM setups that wouldn't do these > checks, and were almost always added in response to things getting > hosed. I agree that we've come along ways in the last year with RPM > building that most of this stuff shouldn't happen anymore and can be > cleaned up. Several years ago already, and superfluous if buildroot is set at the top of a spec file. ;) From alexl at users.sourceforge.net Fri Feb 4 00:09:36 2005 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Thu, 03 Feb 2005 16:09:36 -0800 Subject: download.fedora.us apt repository not being updated Message-ID: <02lla55gov.fsf@allele2.biol.berkeley.edu> Hi, It appears that the apt repository for Fedora Extras hasn't been updated in a few days, the most recent packages there are from 1 Feb: http://download.fedora.us/fedora/fedora/3/i386/RPMS.extras/?M=D even though new packages (from 3 Feb) have arrived in both the new official Extras tree: http://download.fedora.redhat.com/pub/fedora/linux/extras/3/i386/ and the old "Pre Extras" tree: http://fedoraproject.org/pre-extras/3/i386/?C=M;O=D When Pre Extras was the sole source, the delay between the above tree being updated and the apt tree being updated was at most 6-12 hours. Is there some manual intervention required to rebuild the apt repository when updated packages are added, or is it because it is now supposed to be populated from the "official" download.fedora.redhat.com site? Alex From fedora at wir-sind-cool.org Fri Feb 4 00:25:15 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 4 Feb 2005 01:25:15 +0100 Subject: New Packages and a New Layout in Fedora Extras In-Reply-To: <1107362648.27149.44.camel@opus.phy.duke.edu> References: <1107307256.25100.174.camel@cutter> <20050202110044.2c382481@python2> <1107361968.5860.7.camel@localhost.localdomain> <20050202173848.6e99fbc5@python2> <1107362648.27149.44.camel@opus.phy.duke.edu> Message-ID: <20050204012515.3c891ef6.fedora@wir-sind-cool.org> On Wed, 02 Feb 2005 11:44:08 -0500, seth vidal wrote: > > I haven't started working on fixes, I was just browsing the "failed" build > > logs where I found lots of confusing stuff in the logs... thus my remark > > regarding cleaning them up. One thing I could do though, if no one else > > already started the same thing (you or seth, I guess), would be to list all > > x86_64 build logs that are no longer relevant and should be removed. > > send me the list which are all fixed up and I'll get rid of the old > logs. Can be removed (x86_64): audacity.log (built) cryptplug.log (obsolete with gpgme in queue) gpgme.log (in queue) irssi.log (built) newpg.log (obsolete with gnupg2 in queue) opensc.log (in queue) scribus.log (#146961) From wtogami at redhat.com Fri Feb 4 00:35:52 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 03 Feb 2005 14:35:52 -1000 Subject: download.fedora.us apt repository not being updated In-Reply-To: <02lla55gov.fsf@allele2.biol.berkeley.edu> References: <02lla55gov.fsf@allele2.biol.berkeley.edu> Message-ID: <4202C368.8000306@redhat.com> Alex Lancaster wrote: > When Pre Extras was the sole source, the delay between the above tree > being updated and the apt tree being updated was at most 6-12 hours. Thanks for the notification. Apparently I broke the apt repo sync script with a typo. It is fixed now and in progress. Warren Togami wtogami at redhat.com From toshio at tiki-lounge.com Fri Feb 4 01:13:54 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 3 Feb 2005 17:13:54 -0800 Subject: cvs.fedora.redhat.com down Message-ID: <20050203171354.A3456@tiki-lounge.com> Is cvs.fedora.redhat.com down right now? I was going to fix up some python packages for x86i_64 work but it doesn't look like things are running. On the python note -- does anyone have an x86_64 to test a package? I modified the pexpect.spec to hopefully get it to build but I don't have a multilib system to test it on so I don't know that it solves the build problem. If someone tests this and it works, there's quite a few other packages that I can update similarly. -Toshio -------------- next part -------------- %define pyver %(python -c 'import sys ; print sys.version[:3]') %{!?python_sitelib: %define python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")} %{!?python_sitearch: %define python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} Summary: Expect module for Python Name: pexpect Version: 0.999 Release: 2 License: PSFL Group: Development/Languages URL: http://pexpect.sourceforge.net Source: http://download.sourceforge.net/pexpect/%{name}-%{version}.tgz Source1: http://download.sourceforge.net/pexpect/pexpect-doc.tgz Source2: http://download.sourceforge.net/pexpect/pexpect-examples.tgz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root Requires: python-abi = %{pyver} BuildRequires: python-devel >= 0:2.2 %description Pexpect is a pure Python module for spawning child applications; controlling them; and responding to expected patterns in their output. Pexpect works like Don Libes' Expect. Pexpect allows your script to spawn a child application and control it as if a human were typing commands. Pexpect can be used for automating interactive applications such as ssh, ftp, passwd, telnet, etc. It can be used to a automate setup scripts for duplicating software package installations on different servers. It can be used for automated software testing. Pexpect is in the spirit of Don Libes' Expect, but Pexpect is pure Python. Unlike other Expect-like modules for Python, Pexpect does not require TCL or Expect nor does it require C extensions to be compiled. It should work on any platform that supports the standard Python pty module. %prep %setup -q -a1 -a2 rm -rf $(find . -type d -name CVS) %build python setup.py build %install python setup.py install -O1 --root $RPM_BUILD_ROOT #touch %{name}-ghost.files #for file in $(find $RPM_BUILD_ROOT -type f -name "*.py"); do #for suffix in c o; do #if [ ! -e "$file$suffix" ]; then #touch "$file$suffix" #echo "%ghost $file$suffix" | sed "s|$RPM_BUILD_ROOT||" \ #>> %{name}-ghost.files #fi #done #done %clean rm -rf $RPM_BUILD_ROOT #%files -f %{name}-ghost.files %files %defattr(-,root,root,-) %{python_sitelib}/pexpect.py %{python_sitelib}/pexpect.pyc %ghost %{python_sitelib}/pexpect.pyo %doc README.txt doc examples %changelog * Thu Feb 03 2005 Toshio Kuratomi 0.999-2 - Use python_sitelib macro to resolve build issues on x86_64. - ghost *.pyo * Mon May 31 2004 Panu Matilainen 0.999-0.fdr.1 - get rid of distrel munging, buildsys does that... - update to 0.999 - update doc and example tarballs - fix build on python <> 2.2 - use -O1 in install to generate .pyo files instead of manually creating the files - require python-abi = pyver to get dependencies right * Sun Jul 27 2003 Panu Matilainen 0.98-0.fdr.3 - own .pyo files too as suggested by Ville (#517) * Sat Jul 26 2003 Panu Matilainen 0.98-0.fdr.2 - fixes by Ville (bug #517) applied * Sat Jul 26 2003 Panu Matilainen - Initial Fedora packaging From skvidal at phy.duke.edu Fri Feb 4 01:26:00 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 03 Feb 2005 20:26:00 -0500 Subject: cvs.fedora.redhat.com down In-Reply-To: <20050203171354.A3456@tiki-lounge.com> References: <20050203171354.A3456@tiki-lounge.com> Message-ID: <1107480360.11323.2.camel@cutter> On Thu, 2005-02-03 at 17:13 -0800, Toshio Kuratomi wrote: > Is cvs.fedora.redhat.com down right now? I was going to fix up some > python packages for x86i_64 work but it doesn't look like things are > running. > yes cvs.fedora.redhat.com is being shipped to the colocation facility in Phoenix. It should be back online sometime monday. Sorry for the inconvenience but it needs to live in the new place. -sv From wtogami at redhat.com Fri Feb 4 01:36:00 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 03 Feb 2005 15:36:00 -1000 Subject: swsusp, thinkpad module, bootsplash In-Reply-To: <200502032201.04483.kevinverma@gmail.com> References: <200502032201.04483.kevinverma@gmail.com> Message-ID: <4202D180.7030000@redhat.com> Kevin Verma wrote: > Hi, > > I just want to bring a list of packages I desire some one to create for Fedora > under extras. All relates to the kernel package maybe some one will love to > patch swsusp2, thinkpad module & bootsplash to Fedora core 3 kernel. > > http://softwaresuspend.berlios.de/ > http://bootsplash.org/ > http://bootsplash.de > Fedora Extras will not be doing anything that requires patching the main kernel in Core. If you want certain functionality in the main kernel package, you must convince upstream kernel.org to merge it, then convince davej to enable that feature after we have pulled the new upstream kernel. Thinkpad module however is something that Fedora Extras has packaged in the past, and can will probably do again in the future. Some kernel infrastructure needs to be fixed in order to make proper module packages that we can agree on for this project. Warren Togami wtogami at redhat.com From toshio at tiki-lounge.com Fri Feb 4 01:55:13 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 3 Feb 2005 17:55:13 -0800 Subject: cvs.fedora.redhat.com down In-Reply-To: <1107480360.11323.2.camel@cutter>; from skvidal@phy.duke.edu on Thu, Feb 03, 2005 at 08:26:00PM -0500 References: <20050203171354.A3456@tiki-lounge.com> <1107480360.11323.2.camel@cutter> Message-ID: <20050203175513.A4148@tiki-lounge.com> On Thu, Feb 03, 2005 at 08:26:00PM -0500, seth vidal wrote: > > yes cvs.fedora.redhat.com is being shipped to the colocation facility in > Phoenix. It should be back online sometime monday. Sorry for the > inconvenience but it needs to live in the new place. > No worries. It just startled me that before dinner I was able to pull down a package to work on and after dinner I was staring into the face of the void :-) I'll pull down srpms and work from there until Monday. That is, if I've got the right idea about fixing up (some of the) python x86_64 failures. Am I correct in my assumption that the old %{_libdir}/python%{pyver}/site-packages/... won't work with x86_64 but the new style (as defined in fedora-spectemplates) %{python_sitelib} for arch independent and %{python_sitelib} for arch specific python files will? -Toshio From joe at eshu.net Fri Feb 4 03:37:48 2005 From: joe at eshu.net (Joe Christy) Date: Thu, 03 Feb 2005 19:37:48 -0800 Subject: swsusp, thinkpad module, bootsplash In-Reply-To: <200502040111.51051.kevinverma@gmail.com> References: <200502032201.04483.kevinverma@gmail.com> <200502032306.52521.kevinverma@gmail.com> <42027B61.8050709@eshu.net> <200502040111.51051.kevinverma@gmail.com> Message-ID: <4202EE0C.7030002@eshu.net> Vis-a-vis Kevin's note of 02/03/2005 01:11 PM: > ... > I used the current information on http://softwaresuspend.berlios.de/fedora/ > and the patches as provided > > wget -c > http://download.berlios.de/softwaresuspend/software-suspend-2.1.5.15-for-2.6.10.tar.bz2 > wget -c > http://softwaresuspend.berlios.de/fedora/010-2.6.10-1.741-to-2.1.5.15-pre > wget -c > http://softwaresuspend.berlios.de/fedora/990-2.6.10-1.741-to-2.1.5.15-post > # rpmbuild -bp --target=i686 /usr/src/redhat/SPECS/kernel-2.6.spec using > kernel-2.6.10-1.741_FC3 > > # cp 010-2.6.10-1.741-to-2.1.5.15-pre > 990-2.6.10-1.741-to-2.1.5.15-post /root/software-suspend-2.1.5.15-for-2.6.10/ > > # cd /usr/src/redhat/BUILD/kernel-2.6.10/linux-2.6.10 > # /root/software-suspend-2.1.5.15-for-2.6.10/apply > Applying 010-2.6.10-1.741-to-2.1.5.15-pre ... > 010-2.6.10-1.741-to-2.1.5.15-pre will not apply cleanly. Reverse applied > patches [Yn]? > Reversing patches... > Done. > > > Nothing happenes please suggest ... I guess I should patch by hand ... > ... That's odd, it worked fine for me a couple of weeks ago. I habitually make a copy of the Fedora patched sources in /usr/src and work there (because I also update the ibm_acpi from the included 0.8 to 0.10 and pare the config to only provide for the hardware I actually have, etc.). I can't see why "apply"ing in the rpm build tree would be any different from "apply"ing in an exact clone in /usr/src/. BUT, even presuming that they apply cleanly (in the rpm build tree), the problem then would be that you would have a new kernel-2.6.10-1.760_FC3.i686.rpm that would *NOT* be a *Fedora* * Core* kernel-2.6.10-1.760_FC3.i686.rpm. IMHO, better to follow the http://softwaresuspend.berlios.de/fedora/ instructions _exactly_ and just build & install a custom kernel from /usr/src/ w/o mixing it up with the rpm packages. As Warren points out, Extras is not the right place to be introducing patched versions of the Core kernels. In any case, for 2.6.10-1.760_FC3, you need the two new patches which should be appearing at http://softwaresuspend.berlios.de/fedora/ RSN. Let me know out of band, Kevin, if you're brave/foolish enough to want them directly w/o before they've been vetted by someone other than me. Joe -- ============================= Joe Christy ============================== ------------------ http://public.xdi.org/=joe.christy ------------------ == If I can save you any time, give it to me, I'll keep it with mine. == From joe at eshu.net Fri Feb 4 03:50:55 2005 From: joe at eshu.net (Joe Christy) Date: Thu, 03 Feb 2005 19:50:55 -0800 Subject: swsusp, thinkpad module, bootsplash In-Reply-To: <200502040056.37241.kevinverma@gmail.com> References: <200502032201.04483.kevinverma@gmail.com> <420278DD.6020708@prodigy.net.mx> <200502040056.37241.kevinverma@gmail.com> Message-ID: <4202F11F.3020400@eshu.net> Vis-a-vis Kevin's note of 02/03/2005 12:56 PM: > On Thursday 03 February 2005 23:17, Gain Paolo Mureddu wrote: > >> ... whenever I configure bootsplash with a >>given theme, the new kernel will simply NOT display it, no matter what >>I do. I've tried to do this very same procedure, with the same patches >>and source in a Gentoo computer and userspace programs, and there was no >>problem... WTH?!?! > > I guess its the udev which causes this problem, I am not too sure will like to > investigate better this time. I'm quite skeptical about it being udev. udev simply manages the /dev tree. More likely, it's something to with initrd and its contents. >>... > > RHGB is not good enough bootsplash seems to be better, and as a user I'd like > a choice, bootsplash better. > > I think as per Joe Christy it will be good to follow his work of swsusp and > then pre-pare bootsplash patches. ... FWIW, swsusp2 also has the bootsplash patches, though I've never used their capabilities. I'm not one for eye-candy so I mostly turn off rhbg in grub.conf, and frankly, when you get to fiddling the kerneldown at the closer-to-the-machine level that swsusp2 does, you *want* to see the messages that rhgb/bootsplash would cover up. Joe -- ============================= Joe Christy ============================== ------------------ http://public.xdi.org/=joe.christy ------------------ == If I can save you any time, give it to me, I'll keep it with mine. == From ville.skytta at iki.fi Fri Feb 4 07:50:29 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 04 Feb 2005 09:50:29 +0200 Subject: cvs.fedora.redhat.com down In-Reply-To: <20050203175513.A4148@tiki-lounge.com> References: <20050203171354.A3456@tiki-lounge.com> <1107480360.11323.2.camel@cutter> <20050203175513.A4148@tiki-lounge.com> Message-ID: <1107503429.20626.148.camel@bobcat.mine.nu> On Thu, 2005-02-03 at 17:55 -0800, Toshio Kuratomi wrote: > That is, if I've got the right idea about fixing up (some of the) python > x86_64 failures. Am I correct in my assumption that the old > %{_libdir}/python%{pyver}/site-packages/... won't work with x86_64 That might work for arch-dependent Python extensions, and most likely not for arch-independent ones on x86_64. > but the new style (as defined in fedora-spectemplates) > %{python_sitelib} for arch independent and > %{python_sitelib} for arch specific python files will? The latter should obviously be %{python_sitearch}. But yes, it should work. Note that in the majority of cases, it's not a matter of individual _files_, but complete Python extension _packages_. So, if a tarball you're creating contains *any* arch-dependent stuff, all of it, not only the arch-dependent bits, will probably land in % {python_sitearch} (ie. what distutils.sysconfig.get_python_lib(1) returns). From rc040203 at freenet.de Fri Feb 4 07:35:03 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 04 Feb 2005 08:35:03 +0100 Subject: fedora-extras-release In-Reply-To: <1107406975.7339.1.camel@cutter> References: <1107406975.7339.1.camel@cutter> Message-ID: <1107502503.5389.558.camel@mccallum.corsepiu.local> On Thu, 2005-02-03 at 00:02 -0500, seth vidal wrote: > Hey folks, > Do we need a fedora-extras-release package with, maybe, a fedora- > extras-release file in /etc I don't see why this would be useful. > and a fedora-extras.repo file > in /etc/yum.repos.d? This would be useful. I.e. I am for adding a package containing an appropriate yum setup, but I am opposed to adding /etc/fedora-extras-release. Ralf From skvidal at phy.duke.edu Fri Feb 4 09:02:02 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 04 Feb 2005 04:02:02 -0500 Subject: fedora-extras-release In-Reply-To: <20050203235521.456d30df@python2> References: <1107406975.7339.1.camel@cutter> <20050203071322.GC8404@nostromo.devel.redhat.com> <1107415133.7339.25.camel@cutter> <1107458805.5647.78.camel@localhost.localdomain> <20050203204245.1a5e03b6@python2> <1107464852.2013.38.camel@opus.phy.duke.edu> <20050203233111.04bbc0c2@python2> <1107470065.2013.60.camel@opus.phy.duke.edu> <20050203235521.456d30df@python2> Message-ID: <1107507722.3568.16.camel@cutter> > That would be the best IMHO, as the whole point of that package, and the > yum repo entry it contains, is to have everything working with only a few > commands and no editing at all ;-) I've got a list of about 10 or 12 mirrors now - we can start with those. > Attached are a .spec and .repo that could suit the job (the key at the URL > from the repo is also needed). Consensus will be needed for the name, and > voices heard if anything else needs to be added. Thanks, I'll take a look tomorrow. > Too bad though that it seems sysconfig/rhn/ can only take info from the > single "sources" file, as from my understanding this means that the current > RHN notification tool won't automatically be aware of Extras after this > package is installed. Seems like a good reason to make sure pup can be seen from the notification area. :) -sv From skvidal at phy.duke.edu Fri Feb 4 09:04:12 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 04 Feb 2005 04:04:12 -0500 Subject: New Packages and a New Layout in Fedora Extras In-Reply-To: <20050204012515.3c891ef6.fedora@wir-sind-cool.org> References: <1107307256.25100.174.camel@cutter> <20050202110044.2c382481@python2> <1107361968.5860.7.camel@localhost.localdomain> <20050202173848.6e99fbc5@python2> <1107362648.27149.44.camel@opus.phy.duke.edu> <20050204012515.3c891ef6.fedora@wir-sind-cool.org> Message-ID: <1107507852.3568.18.camel@cutter> On Fri, 2005-02-04 at 01:25 +0100, Michael Schwendt wrote: > On Wed, 02 Feb 2005 11:44:08 -0500, seth vidal wrote: > > > > I haven't started working on fixes, I was just browsing the "failed" build > > > logs where I found lots of confusing stuff in the logs... thus my remark > > > regarding cleaning them up. One thing I could do though, if no one else > > > already started the same thing (you or seth, I guess), would be to list all > > > x86_64 build logs that are no longer relevant and should be removed. > > > > send me the list which are all fixed up and I'll get rid of the old > > logs. > > Can be removed (x86_64): > > audacity.log (built) > cryptplug.log (obsolete with gpgme in queue) > gpgme.log (in queue) > irssi.log (built) > newpg.log (obsolete with gnupg2 in queue) > opensc.log (in queue) > scribus.log (#146961) > Thanks, done. -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 4 09:44:20 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 4 Feb 2005 10:44:20 +0100 Subject: fedora-extras-release In-Reply-To: <1107507722.3568.16.camel@cutter> References: <1107406975.7339.1.camel@cutter> <20050203071322.GC8404@nostromo.devel.redhat.com> <1107415133.7339.25.camel@cutter> <1107458805.5647.78.camel@localhost.localdomain> <20050203204245.1a5e03b6@python2> <1107464852.2013.38.camel@opus.phy.duke.edu> <20050203233111.04bbc0c2@python2> <1107470065.2013.60.camel@opus.phy.duke.edu> <20050203235521.456d30df@python2> <1107507722.3568.16.camel@cutter> Message-ID: <20050204104420.7117ad38@python2> seth vidal wrote : > > Too bad though that it seems sysconfig/rhn/ can only take info from the > > single "sources" file, as from my understanding this means that the current > > RHN notification tool won't automatically be aware of Extras after this > > package is installed. > > Seems like a good reason to make sure pup can be seen from the > notification area. :) Hmmm, this may sound silly to some, but... what is pup? (and where can I get more info about it?) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.61 0.73 0.34 From gauret at free.fr Fri Feb 4 09:48:34 2005 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 04 Feb 2005 10:48:34 +0100 Subject: cvs.fedora.redhat.com down References: <20050203171354.A3456@tiki-lounge.com> Message-ID: Toshio Kuratomi wrote: > On the python note -- does anyone have an x86_64 to test a package???I > modified the pexpect.spec to hopefully get it to build but I don't have > a multilib system to test it on so I don't know that it solves the build > problem.??If?someone?tests?this?and?it?works,?there's?quite?a?few?other > packages that I can update similarly. Yes, feel free to send me those files, and please tell me what tests I should run on the rebuilt package (that is: if it rebuilds and installs :o) ) Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq' | dc From toshio at tiki-lounge.com Fri Feb 4 12:45:55 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 4 Feb 2005 04:45:55 -0800 Subject: cvs.fedora.redhat.com down In-Reply-To: <1107503429.20626.148.camel@bobcat.mine.nu>; from ville.skytta@iki.fi on Fri, Feb 04, 2005 at 09:50:29AM +0200 References: <20050203171354.A3456@tiki-lounge.com> <1107480360.11323.2.camel@cutter> <20050203175513.A4148@tiki-lounge.com> <1107503429.20626.148.camel@bobcat.mine.nu> Message-ID: <20050204044555.A17059@tiki-lounge.com> On Fri, Feb 04, 2005 at 09:50:29AM +0200, Ville Skytt? wrote: > On Thu, 2005-02-03 at 17:55 -0800, Toshio Kuratomi wrote: > > > That is, if I've got the right idea about fixing up (some of the) python > > x86_64 failures. Am I correct in my assumption that the old > > %{_libdir}/python%{pyver}/site-packages/... won't work with x86_64 > > That might work for arch-dependent Python extensions, and most likely > not for arch-independent ones on x86_64. > > > but the new style (as defined in fedora-spectemplates) > > %{python_sitelib} for arch independent and > > %{python_sitelib} for arch specific python files will? > > The latter should obviously be %{python_sitearch}. But yes, it should > work. > > Note that in the majority of cases, it's not a matter of individual > _files_, but complete Python extension _packages_. > > So, if a tarball you're creating contains *any* arch-dependent stuff, > all of it, not only the arch-dependent bits, will probably land in % > {python_sitearch} (ie. what distutils.sysconfig.get_python_lib(1) > returns). > Hmmm... thanks for pointing out the difference. So I'll check at the module level for whether the whole module is arch-dependent or not... and stare suspiciously at the build scripts of any package providing both arch dependent and arch independent modules. -Toshio From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 4 13:00:40 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 04 Feb 2005 14:00:40 +0100 Subject: snort ? In-Reply-To: <20050203232452.289ca48e@python2> (Matthias Saou's message of "Thu, 3 Feb 2005 23:24:52 +0100") References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> <20050203202026.76300c95@python2> <876519csup.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050203232452.289ca48e@python2> Message-ID: <87u0osbhtz.fsf@kosh.ultra.csn.tu-chemnitz.de> thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) writes: >> * %{_sysconfdir}/rc.d/init.d should be written as %_initrddir > > That one, I'm not sure. No one has ever been able to confirm or dis-confirm > to me if this confusing name was normal or actually a typo. %_initddir or > %_rcinitdir I would have understood... but %_initrddir!? IMHO, having > "initrd" is really weird, that's why I tend ot avoid that macro altogether > :-/ Mixing the FHS compliant /etc/init.d and the RH style /etc/rc.d/init.d would cause huge problems (e.g. two independent directories with initscripts). Therefore, I prefer to use the %_initrddir macro across all packages. >> * I would put the rules into a separate subpackage to allow easier >> updates > > I guess you mean "custom" or "local" updates, right? Indeed, it could > be interesting to override the defaults. Correct. These rules can be compared with an antivirus database and should be updated regularly. The release cycles of snort are much too long for this. > So, a "snort-rules" package with mutual requirements between it and > "snort" is what you'd expect? In general, Add a 'Requires: rules(snort)' in the main package, and a 'Provides: rules(snort)' in your rules package. >> * As I like and use minimal systems I would prefer -mysql, -postgresql >> subpackages which use 'alternatives' to set a link to >> /usr/sbin/snortd. So, unneeded dependencies will be prevented > > I understand, but that will add quite a bit of complexity to the package... > the postgresql-libs are only 360kB and don't have any special deps, so the > extra 420kB created by an additional snort binary makes it a loosing > situation, definitely not "worth the trouble" from my POV. OTOH, mysql > pulls in 5MB+ and some deps (perl modules and eventually others on minimal > systems), Yes, postgresql-libs are ok. But as you said: MySQL requires perl which needs 50MB. > so maybe just only enabling PostgreSQL support by default could be > done, as it is the "preferred" RH/FC detabase anyway, and leave the > MySQL optional with the rpmbuild switch? > > Or... just have alternatives choose between the plain version and another > "db" version which has both databases supported? Hey, I actually think this > last idea isn't that bad :-) This would save only one subpackage... I do not know if we want a Gentoo style system where everybody has to configure and build the packages with the appropriate switches himself. Enrico From skvidal at phy.duke.edu Fri Feb 4 14:59:57 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 04 Feb 2005 09:59:57 -0500 Subject: fedora-extras-release In-Reply-To: <20050204104420.7117ad38@python2> References: <1107406975.7339.1.camel@cutter> <20050203071322.GC8404@nostromo.devel.redhat.com> <1107415133.7339.25.camel@cutter> <1107458805.5647.78.camel@localhost.localdomain> <20050203204245.1a5e03b6@python2> <1107464852.2013.38.camel@opus.phy.duke.edu> <20050203233111.04bbc0c2@python2> <1107470065.2013.60.camel@opus.phy.duke.edu> <20050203235521.456d30df@python2> <1107507722.3568.16.camel@cutter> <20050204104420.7117ad38@python2> Message-ID: <1107529197.31004.1.camel@opus.phy.duke.edu> On Fri, 2005-02-04 at 10:44 +0100, Matthias Saou wrote: > seth vidal wrote : > > > > Too bad though that it seems sysconfig/rhn/ can only take info from the > > > single "sources" file, as from my understanding this means that the > current > > > RHN notification tool won't automatically be aware of Extras after this > > > package is installed. > > > > Seems like a good reason to make sure pup can be seen from the > > notification area. :) > > Hmmm, this may sound silly to some, but... what is pup? (and where can I > get more info about it?) > Why it most certainly is silly! :) Pup stands for Package updater. It is a graphical interface using the yum backend modules for packaging updating. Paul Nasrat and some others inside red hat are working on it. It's not intended to be like synaptic or any of the other updater interfaces. It's intended to target tasks the user will commonly do and let them do them more easily. Check out the archives of the fedora-config-list. -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 4 15:02:05 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 4 Feb 2005 16:02:05 +0100 Subject: snort ? In-Reply-To: <87u0osbhtz.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> <20050203202026.76300c95@python2> <876519csup.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050203232452.289ca48e@python2> <87u0osbhtz.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20050204160205.28f3c369@python2> Enrico Scholz wrote : > Mixing the FHS compliant /etc/init.d and the RH style /etc/rc.d/init.d > would cause huge problems (e.g. two independent directories with > initscripts). Therefore, I prefer to use the %_initrddir macro across > all packages. Hmmm... I'm actually never sure which one of /etc/init.d and /etc/rc.d/init.d is supposed to be the correct one for RH/FC, but I think it's the latter. I don't see how mixing them could cause "huge problems" since there's a symlink from one to the other currently, and we're far from being able to simply nuke it and expect things to still work. Also, I don't see any mention of init.d nor rc.d in the current FHS (2.3) over at http://www.pathname.com/fhs/pub/fhs-2.3.html :-( I'm really not against using a macro for the init scripts in the first place, on the contrary, but using one with such a weird name, that no one has even been able to explain to me, is simply something I prefer avoiding for now. I'd really love to get any information as to _why_ it's called _initrddir (such a confusing choice IMHO). > >> * I would put the rules into a separate subpackage to allow easier > >> updates > > > > I guess you mean "custom" or "local" updates, right? Indeed, it could > > be interesting to override the defaults. > > Correct. These rules can be compared with an antivirus database and > should be updated regularly. The release cycles of snort are much too > long for this. > > > So, a "snort-rules" package with mutual requirements between it and > > "snort" is what you'd expect? In general, > > Add a 'Requires: rules(snort)' in the main package, and a 'Provides: > rules(snort)' in your rules package. Understood. Seems sane and useful, will make that change. > > so maybe just only enabling PostgreSQL support by default could be > > done, as it is the "preferred" RH/FC detabase anyway, and leave the > > MySQL optional with the rpmbuild switch? > > > > Or... just have alternatives choose between the plain version and another > > "db" version which has both databases supported? Hey, I actually think this > > last idea isn't that bad :-) > > This would save only one subpackage... I do not know if we want a Gentoo > style system where everybody has to configure and build the packages > with the appropriate switches himself. What do you mean? I see two options with 2 packages each : - Have snort, w/ postgresl-libs dep, and snort-mysql and being able to switch from one to the other with alternatives (or have it be automatic, as if snort-mysql is installed, it makes sense to use that one). - Have snort, plain build, and snort-sql with both backends, and again have alternatives switch between both. Where to you see any package rebuilding to get a feature here? Maybe I wasn't clear enough in my previous message, sorry. As for the oracle backend, it will require a rebuild anyway, so I don't see it as a problem to just leave it in the main package. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.25 0.31 0.52 From rdieter at math.unl.edu Fri Feb 4 15:10:50 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 04 Feb 2005 09:10:50 -0600 Subject: kmymoney2 In-Reply-To: References: <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <20050131222016.GA9816@thacker.dyndns.org> <1107505209l.7472l.3l@devel.mpeters.us> Message-ID: <4203907A.1040505@math.unl.edu> Rex Dieter wrote: > On Fri, 4 Feb 2005, Michael A. Peters wrote: > >> On 02/03/2005 10:51:31 AM, Elliot Lee wrote: >> >>> > gnucash we're waiting on the port to gtk2 >>> >>> gnucash is staying in core for now because the maintainer says so. :) >>> (I >>> assume this means that the gtk2 port is forthcoming.) >> >> >> Even if a gtk2 port is not forthcoming, it is really the only mature >> app that does what it does. > > > kmymoney2 is pretty nice (I suppose I should submit it to extras now > that I opened my mouth). OK, done: kmymoney2: http://bugzilla.fedora.us/show_bug.cgi?id=2412 -- Rex From skvidal at phy.duke.edu Fri Feb 4 15:18:26 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 04 Feb 2005 10:18:26 -0500 Subject: kmymoney2 In-Reply-To: <4203907A.1040505@math.unl.edu> References: <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <20050131222016.GA9816@thacker.dyndns.org> <1107505209l.7472l.3l@devel.mpeters.us> <4203907A.1040505@math.unl.edu> Message-ID: <1107530306.31004.5.camel@opus.phy.duke.edu> > > > > kmymoney2 is pretty nice (I suppose I should submit it to extras now > > that I opened my mouth). > > OK, done: > kmymoney2: http://bugzilla.fedora.us/show_bug.cgi?id=2412 > okay so we need to stop this. bugzilla.fedora.us is not to be used for fedora extras anymore. If you want to add a new package go to bugzilla.redhat.com Seriously we need to close down all use of fedora.us - both for the wiki and bugzilla. -sv From rdieter at math.unl.edu Fri Feb 4 15:22:03 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 04 Feb 2005 09:22:03 -0600 Subject: don't use bugzilla.fedora.us In-Reply-To: <1107530306.31004.5.camel@opus.phy.duke.edu> References: <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <20050131222016.GA9816@thacker.dyndns.org> <1107505209l.7472l.3l@devel.mpeters.us> <4203907A.1040505@math.unl.edu> <1107530306.31004.5.camel@opus.phy.duke.edu> Message-ID: <4203931B.6040407@math.unl.edu> seth vidal wrote: >>>kmymoney2 is pretty nice (I suppose I should submit it to extras now >>>that I opened my mouth). >> >>OK, done: >>kmymoney2: http://bugzilla.fedora.us/show_bug.cgi?id=2412 >> > > > okay so we need to stop this. > > bugzilla.fedora.us is not to be used for fedora extras anymore. If you > want to add a new package go to bugzilla.redhat.com > > Seriously we need to close down all use of fedora.us - both for the wiki > and bugzilla. My apologies... I must've misread previous announcements. Should existing submissions to bugzilla.fedora.us should be re-submitted to bugzilla.redhat.com? -- Rex From skvidal at phy.duke.edu Fri Feb 4 15:26:39 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 04 Feb 2005 10:26:39 -0500 Subject: don't use bugzilla.fedora.us In-Reply-To: <4203931B.6040407@math.unl.edu> References: <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <20050131222016.GA9816@thacker.dyndns.org> <1107505209l.7472l.3l@devel.mpeters.us> <4203907A.1040505@math.unl.edu> <1107530306.31004.5.camel@opus.phy.duke.edu> <4203931B.6040407@math.unl.edu> Message-ID: <1107530799.31004.11.camel@opus.phy.duke.edu> > My apologies... I must've misread previous announcements. > > Should existing submissions to bugzilla.fedora.us should be re-submitted > to bugzilla.redhat.com? I think closing them out if they're closeable and only opening new items in bugzilla.r.c would make the most sense. seem reasonable? -sv From rdieter at math.unl.edu Fri Feb 4 15:28:24 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 04 Feb 2005 09:28:24 -0600 Subject: don't use bugzilla.fedora.us In-Reply-To: <1107530799.31004.11.camel@opus.phy.duke.edu> References: <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <20050131222016.GA9816@thacker.dyndns.org> <1107505209l.7472l.3l@devel.mpeters.us> <4203907A.1040505@math.unl.edu> <1107530306.31004.5.camel@opus.phy.duke.edu> <4203931B.6040407@math.unl.edu> <1107530799.31004.11.camel@opus.phy.duke.edu> Message-ID: <42039498.9020209@math.unl.edu> seth vidal wrote: >>My apologies... I must've misread previous announcements. >> >>Should existing submissions to bugzilla.fedora.us should be re-submitted >>to bugzilla.redhat.com? > > > I think closing them out if they're closeable and only opening new items > in bugzilla.r.c would make the most sense. > > seem reasonable? Sounds very reasonable to me. -- Rex From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 4 15:51:20 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 4 Feb 2005 16:51:20 +0100 Subject: Bugzilla usage (was: Re: kmymoney2) In-Reply-To: <1107530306.31004.5.camel@opus.phy.duke.edu> References: <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <20050131222016.GA9816@thacker.dyndns.org> <1107505209l.7472l.3l@devel.mpeters.us> <4203907A.1040505@math.unl.edu> <1107530306.31004.5.camel@opus.phy.duke.edu> Message-ID: <20050204165120.22c14585@python2> seth vidal wrote : > bugzilla.fedora.us is not to be used for fedora extras anymore. If you > want to add a new package go to bugzilla.redhat.com Regarding this... I never liked using bugzilla from the very beginning, and I find it much easier to reach a large "mostly passive" community through a mailing-list than through a bugzilla. My ideal way of working would be : 1) Make requests for new packages, or post links to packages in order to submit them on the mailing-list (so maybe later on have a fedora-extras-devel-list for that and use fedora-extras similarly to fedora-list). 2) From there, let discussions and initial improvements and fixes take place, everyone sees them immediately and may participate (see the snort messages from the past 2 days). 3) Once the package passes initial QA, then have the maintainer import it into Extras, and have all that is needed created (CVS directory by the import, bugzilla component...). 4) Start using bugzilla from there on for that package, pretty much like it has always been done for RH/FC. This will avoid bloating bugzilla with repeated RFE's regarding packages that can't be included (think any package that seems ok but needs to link to a patent encumbered lib to be useful), and most of all from gazillions of open submissions that will stay open forever (like in fedora.us). I really hope to see Fedora Extras draw a clear line between "what's in" on one side, and "what isn't yet / what will never be" on the other. Thoughts? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.66 0.45 0.31 From skvidal at phy.duke.edu Fri Feb 4 16:11:14 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 04 Feb 2005 11:11:14 -0500 Subject: Bugzilla usage (was: Re: kmymoney2) In-Reply-To: <20050204165120.22c14585@python2> References: <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <20050131222016.GA9816@thacker.dyndns.org> <1107505209l.7472l.3l@devel.mpeters.us> <4203907A.1040505@math.unl.edu> <1107530306.31004.5.camel@opus.phy.duke.edu> <20050204165120.22c14585@python2> Message-ID: <1107533474.31004.17.camel@opus.phy.duke.edu> > Regarding this... I never liked using bugzilla from the very beginning, and > I find it much easier to reach a large "mostly passive" community through a > mailing-list than through a bugzilla. My ideal way of working would be : I agree. But if you're going to open a bug - definitely do it in bugzilla.r.c :) > 1) Make requests for new packages, or post links to packages in order to > submit them on the mailing-list (so maybe later on have a > fedora-extras-devel-list for that and use fedora-extras similarly to > fedora-list). I'd actually encourage things to work as: fedora-list for problems in fc or fe. fedora-extras-list for devel, requests for packages and itp messages, as well as discussion. > 2) From there, let discussions and initial improvements and fixes take > place, everyone sees them immediately and may participate (see the snort > messages from the past 2 days). > 3) Once the package passes initial QA, then have the maintainer import it > into Extras, and have all that is needed created (CVS directory by the > import, bugzilla component...). WORKSFORME > 4) Start using bugzilla from there on for that package, pretty much like it > has always been done for RH/FC. yop. > This will avoid bloating bugzilla with repeated RFE's regarding packages > that can't be included (think any package that seems ok but needs to link > to a patent encumbered lib to be useful), and most of all from gazillions > of open submissions that will stay open forever (like in fedora.us). > I really hope to see Fedora Extras draw a clear line between "what's in" on > one side, and "what isn't yet / what will never be" on the other. I agree I never liked the 'everything in bugzilla' way of doing requests for packages either. However, I do think that if you want something tracked over the long term it needs to be in bugzilla. > Thoughts? my head hurts from nodding in agreement -sv From fedora at leemhuis.info Fri Feb 4 16:31:09 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 04 Feb 2005 17:31:09 +0100 Subject: If anyone wants to test building on x86_64, but has no machine to test Message-ID: <1107534669.5838.13.camel@localhost.localdomain> Hi *! If anyone has no x86_64 system but wants to fix his or other peoples packages that are currently failing on x86_64 (see http://www.fedoraproject.com/wiki/Extras_2fFC3Status ): Just send me a notice and a link to the package, a bugzilla entry or a diff against CVS. If I find time I'll try to test if it is building on x86_64. CU thl -- Thorsten Leemhuis From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 4 16:51:21 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 04 Feb 2005 17:51:21 +0100 Subject: snort ? In-Reply-To: <20050204160205.28f3c369@python2> (Matthias Saou's message of "Fri, 4 Feb 2005 16:02:05 +0100") References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> <20050203202026.76300c95@python2> <876519csup.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050203232452.289ca48e@python2> <87u0osbhtz.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050204160205.28f3c369@python2> Message-ID: <87acqkb75i.fsf@kosh.ultra.csn.tu-chemnitz.de> thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) writes: >> Mixing the FHS compliant /etc/init.d and the RH style /etc/rc.d/init.d >> would cause huge problems (e.g. two independent directories with >> initscripts). Therefore, I prefer to use the %_initrddir macro across >> all packages. > > Hmmm... I'm actually never sure which one of /etc/init.d and > /etc/rc.d/init.d is supposed to be the correct one for RH/FC, but I think > it's the latter. I don't see how mixing them could cause "huge > problems" Ok... assume a package A which has | %files | /etc/init.d/A for whatever reasons. Now, install this package on an empty system (e.g. in a '--root' chroot installation). When there are other flaws (e.g. missing 'Requires(pre): chkconfig|/etc/init.d|...'), this package might be installed before the /etc/init.d symlink is created. This will create it as a directory, and the subsequent installation of 'chkconfig' or 'initscripts' (which would make it a symlink) can not fix it. So you will create two init.d directories with a distinct set of initscripts. > since there's a symlink from one to the other currently, and we're > far from being able to simply nuke it and expect things to still > work. Also, I don't see any mention of init.d nor rc.d in the current > FHS (2.3) over at http://www.pathname.com/fhs/pub/fhs-2.3.html :-( mmh... I could swear that FHS specified /etc/init.d as the location for initscripts. But LSB does it: | An init.d file is installed in /etc/init.d (which may be a symlink to | another location). [http://www.linuxbase.org/spec//booksets/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html] > I'd really love to get any information as to _why_ it's called _initrddir > (such a confusing choice IMHO). Sorry, I can not help here. But RH6.2 (rpm-4.0.2-6x) has this macro already. >> > so maybe just only enabling PostgreSQL support by default could be >> > done, as it is the "preferred" RH/FC detabase anyway, and leave the >> > MySQL optional with the rpmbuild switch? >> > >> > Or... just have alternatives choose between the plain version and >> > another "db" version which has both databases supported? Hey, I >> > actually think this >> > last idea isn't that bad :-) >> >> This would save only one subpackage... I do not know if we want a Gentoo >> style system where everybody has to configure and build the packages >> with the appropriate switches himself. > > What do you mean? I see two options with 2 packages each : > - Have snort, w/ postgresl-libs dep, and snort-mysql and being able to > switch from one to the other with alternatives (or have it be automatic, as > if snort-mysql is installed, it makes sense to use that one). > - Have snort, plain build, and snort-sql with both backends, and again have > alternatives switch between both. Ok, I assume that there are three classes of people: * such ones, which want snort without database support (a really minimal solution; perhaps usefully in firewalls) * such ones, which want postgresl support * such ones, which want mysql support I do not think that somebody needs both database backends. Your first option (where I could live with), would discriminate MySQL users somehow but has good technical reasons (the 50MB perl deps). But when you create the infrastructure for multiple subpackages, why not create all three packages (plain, psql, mysql)? > Where to you see any package rebuilding to get a feature here? E.g. when you decide to package option 2 (plain + mysql/psql), I can not use the prebuild packages from Fedora Extras but would have to rebuild it manually (I need psql but do not want MySQL + deps on the machine). > Maybe I wasn't clear enough in my previous message, sorry. As for the > oracle backend, it will require a rebuild anyway, so I don't see it as > a problem to just leave it in the main package. Yes, that's clear. With packages outside of Fedora, you are on your own. Enrioc From daniel-wittenberg at starken.com Fri Feb 4 17:02:36 2005 From: daniel-wittenberg at starken.com (Daniel Wittenberg) Date: Fri, 04 Feb 2005 11:02:36 -0600 Subject: snort ? In-Reply-To: <87acqkb75i.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1107370990.17357.9.camel@forensic.starken.com> <20050202203504.5568eaa0.fedora@wir-sind-cool.org> <1107373841.17357.14.camel@forensic.starken.com> <20050202210330.58a01d0a.fedora@wir-sind-cool.org> <1107375357.17357.17.camel@forensic.starken.com> <20050203014237.56ecdaaf.fedora@wir-sind-cool.org> <1107404396.10215.7.camel@localhost.localdomain> <20050203125926.0ab5d8a8.fedora@wir-sind-cool.org> <1107446862.23434.2.camel@forensic.starken.com> <20050203174939.318a88ec.fedora@wir-sind-cool.org> <1107449816.23434.8.camel@forensic.starken.com> <20050203182245.2325c70b.fedora@wir-sind-cool.org> <20050203182701.0b9bc1f7@python2> <1107452243.23434.26.camel@forensic.starken.com> <20050203202026.76300c95@python2> <876519csup.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050203232452.289ca48e@python2> <87u0osbhtz.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050204160205.28f3c369@python2> <87acqkb75i.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1107536556.7578.3.camel@forensic.starken.com> With the regular snort RPM's we used /etc/init.d mainly because of standards and made it easier for portability, since most other RPM-based distros we saw were using /etc/init.d We also did split the packages are purpose because of what is mentioned here, the 3 classes of people wanting 3 different builds, and when snort is on firewalls and sometimes critical area, people tend not to want it to be bloated with more code than it has to. Just FYI on why we did things certain ways in case it helps. Dan On Fri, 2005-02-04 at 17:51 +0100, Enrico Scholz wrote: > thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) writes: > > >> Mixing the FHS compliant /etc/init.d and the RH style /etc/rc.d/init.d > >> would cause huge problems (e.g. two independent directories with > >> initscripts). Therefore, I prefer to use the %_initrddir macro across > >> all packages. > > > > Hmmm... I'm actually never sure which one of /etc/init.d and > > /etc/rc.d/init.d is supposed to be the correct one for RH/FC, but I think > > it's the latter. I don't see how mixing them could cause "huge > > problems" > > Ok... assume a package A which has > > | %files > | /etc/init.d/A > > for whatever reasons. Now, install this package on an empty system > (e.g. in a '--root' chroot installation). When there are other > flaws (e.g. missing 'Requires(pre): chkconfig|/etc/init.d|...'), > this package might be installed before the /etc/init.d symlink is > created. This will create it as a directory, and the subsequent > installation of 'chkconfig' or 'initscripts' (which would make it a > symlink) can not fix it. > > So you will create two init.d directories with a distinct set of > initscripts. > > > > since there's a symlink from one to the other currently, and we're > > far from being able to simply nuke it and expect things to still > > work. Also, I don't see any mention of init.d nor rc.d in the current > > FHS (2.3) over at http://www.pathname.com/fhs/pub/fhs-2.3.html :-( > > mmh... I could swear that FHS specified /etc/init.d as the location for > initscripts. But LSB does it: > > | An init.d file is installed in /etc/init.d (which may be a symlink to > | another location). > [http://www.linuxbase.org/spec//booksets/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html] > > > > I'd really love to get any information as to _why_ it's called _initrddir > > (such a confusing choice IMHO). > > Sorry, I can not help here. But RH6.2 (rpm-4.0.2-6x) has this macro > already. > > > >> > so maybe just only enabling PostgreSQL support by default could be > >> > done, as it is the "preferred" RH/FC detabase anyway, and leave the > >> > MySQL optional with the rpmbuild switch? > >> > > >> > Or... just have alternatives choose between the plain version and > >> > another "db" version which has both databases supported? Hey, I > >> > actually think this > >> > last idea isn't that bad :-) > >> > >> This would save only one subpackage... I do not know if we want a Gentoo > >> style system where everybody has to configure and build the packages > >> with the appropriate switches himself. > > > > What do you mean? I see two options with 2 packages each : > > - Have snort, w/ postgresl-libs dep, and snort-mysql and being able to > > switch from one to the other with alternatives (or have it be automatic, as > > if snort-mysql is installed, it makes sense to use that one). > > - Have snort, plain build, and snort-sql with both backends, and again have > > alternatives switch between both. > > Ok, I assume that there are three classes of people: > > * such ones, which want snort without database support (a really minimal > solution; perhaps usefully in firewalls) > * such ones, which want postgresl support > * such ones, which want mysql support > > I do not think that somebody needs both database backends. > > Your first option (where I could live with), would discriminate MySQL > users somehow but has good technical reasons (the 50MB perl deps). But > when you create the infrastructure for multiple subpackages, why not > create all three packages (plain, psql, mysql)? > > > > Where to you see any package rebuilding to get a feature here? > > E.g. when you decide to package option 2 (plain + mysql/psql), I can not > use the prebuild packages from Fedora Extras but would have to rebuild > it manually (I need psql but do not want MySQL + deps on the machine). > > > > Maybe I wasn't clear enough in my previous message, sorry. As for the > > oracle backend, it will require a rebuild anyway, so I don't see it as > > a problem to just leave it in the main package. > > Yes, that's clear. With packages outside of Fedora, you are on your own. > > > > Enrioc > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list From dwmw2 at infradead.org Fri Feb 4 17:16:31 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 04 Feb 2005 17:16:31 +0000 Subject: PPC extras. Message-ID: <1107537391.18239.106.camel@baythorne.infradead.org> I'm working on building FC3 extras for ppc. I've got most of it built. Not exactly relishing the thought of cvsup, although cm3 does seem to have a PPC port, so I may switch to using that for both i386 and ppc. Downloadable at ftp://peach.ipv6.infradead.org/pub/RPMS.extras for now, IPv6-only as the name implies, until I stick them somewhere with better bandwidth. Major failure mode so far has been random use of i386 inline assembly. A bunch of packages failed due to files present in the buildroot which aren't packaged, and clamav seems to want dietlibc. Any suggestions for how best to automate the Extras/ppc builds in future would be welcomed. -- dwmw2 From fedora at leemhuis.info Fri Feb 4 17:28:58 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 04 Feb 2005 18:28:58 +0100 Subject: PPC extras. In-Reply-To: <1107537391.18239.106.camel@baythorne.infradead.org> References: <1107537391.18239.106.camel@baythorne.infradead.org> Message-ID: <1107538138.5838.22.camel@localhost.localdomain> Am Freitag, den 04.02.2005, 17:16 +0000 schrieb David Woodhouse: > Major failure mode so far has been random use of i386 inline assembly. A > bunch of packages failed due to files present in the buildroot which > aren't packaged, and clamav seems to want dietlibc. The update which is planed at http://bugzilla.fedora.us/show_bug.cgi?id=1715 does not need it anymore. HTH CU thl -- Thorsten Leemhuis From dwmw2 at infradead.org Fri Feb 4 17:36:42 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 04 Feb 2005 17:36:42 +0000 Subject: PPC extras. In-Reply-To: <1107538138.5838.22.camel@localhost.localdomain> References: <1107537391.18239.106.camel@baythorne.infradead.org> <1107538138.5838.22.camel@localhost.localdomain> Message-ID: <1107538602.18239.109.camel@baythorne.infradead.org> On Fri, 2005-02-04 at 18:28 +0100, Thorsten Leemhuis wrote: > > The update which is planed at > http://bugzilla.fedora.us/show_bug.cgi?id=1715 > > does not need it anymore. Thanks. That one builds fine and is now in the FTP directory with the others. Btw, this warning isn't relevant for FC3, is it? ... ** WARNING: building with '--disable-zlib-vcheck' because Red Hat is unable ** to apply a simple security fix within 5 months. On failures or ** successful DOS attacks on your mailserver, please blame RH ** but not fedora.us. ** ** See https://bugzilla.redhat.com/beta/show_bug.cgi?id=131385 ** and http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0797 ** for references -- dwmw2 From fedora at leemhuis.info Fri Feb 4 17:51:04 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 04 Feb 2005 18:51:04 +0100 Subject: PPC extras. In-Reply-To: <1107538602.18239.109.camel@baythorne.infradead.org> References: <1107537391.18239.106.camel@baythorne.infradead.org> <1107538138.5838.22.camel@localhost.localdomain> <1107538602.18239.109.camel@baythorne.infradead.org> Message-ID: <1107539464.5838.34.camel@localhost.localdomain> Am Freitag, den 04.02.2005, 17:36 +0000 schrieb David Woodhouse: > On Fri, 2005-02-04 at 18:28 +0100, Thorsten Leemhuis wrote: > > > > The update which is planed at > > http://bugzilla.fedora.us/show_bug.cgi?id=1715 > > > > does not need it anymore. > > Thanks. That one builds fine and is now in the FTP directory with the > others. > > Btw, this warning isn't relevant for FC3, is it? ... > > ** WARNING: building with '--disable-zlib-vcheck' because Red Hat is unable > ** to apply a simple security fix within 5 months. On failures or > ** successful DOS attacks on your mailserver, please blame RH > ** but not fedora.us. > ** > ** See https://bugzilla.redhat.com/beta/show_bug.cgi?id=131385 > ** and http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0797 > ** for references The update is newer then the package IIRC; Discussion on the warning and how to proceed is in the above bugzilla entry. -- Thorsten Leemhuis From adrian at lisas.de Fri Feb 4 18:56:33 2005 From: adrian at lisas.de (Adrian Reber) Date: Fri, 4 Feb 2005 19:56:33 +0100 Subject: how to use CVS In-Reply-To: <20050203210246.2327cde0.fedora@wir-sind-cool.org> References: <20050203194019.GA2868@lisas.de> <20050203210246.2327cde0.fedora@wir-sind-cool.org> Message-ID: <20050204185633.GB1584@lisas.de> On Thu, Feb 03, 2005 at 09:02:46PM +0100, Michael Schwendt wrote: > Unbelievable. How did this happen? For the FC-2 and older branches > it is likely, because these cannot be created by us (see FC3Status > page in the fedoraproject.org Wiki). But for packages in "devel" > all should be up-to-date. Unbelievable, but true :-) antiword in devel is 0.35 and in fedora.us it has been updated to 0.36 http://bugzilla.fedora.us/show_bug.cgi?id=2270 > make new-sources FILES="foo1.tar.gz foo2.tar.gz" [...] > make upload FILES="foo1.tar.gz foo2.tar.gz" [...] > cvs-import.sh [...] > HTH Yes it does. Exactly what I was looking for. Thanks. I will try it out next week when the CVS server is online again. Adrian From gauret at free.fr Fri Feb 4 22:51:55 2005 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 04 Feb 2005 23:51:55 +0100 Subject: If anyone wants to test building on x86_64, but has no machine to test References: <1107534669.5838.13.camel@localhost.localdomain> Message-ID: Thorsten Leemhuis wrote: > If anyone has no x86_64 system but wants to fix his or other peoples > packages that are currently failing on x86_64 (see > http://www.fedoraproject.com/wiki/Extras_2fFC3Status ): > > Just send me a notice and a link to the package, a bugzilla entry or a > diff against CVS. If I find time I'll try to test if it is building on > x86_64. And if Thorsten is unavailable or just overloaded with requests, I can test builds on x86_64 too. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info For external use only From smooge at gmail.com Fri Feb 4 23:22:53 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Fri, 4 Feb 2005 16:22:53 -0700 Subject: Updating clamav Message-ID: <80d7e409050204152243df53df@mail.gmail.com> Extra currently has 0.71 clamav, and the stable clamav is 0.81 with security fixes. With that in mind.. what can I do to get an updated spec file/srpm/ for the build system? -- Stephen J Smoogen. CSIRT/Linux System Administrator From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 4 23:27:15 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 05 Feb 2005 00:27:15 +0100 Subject: PPC extras. In-Reply-To: <1107538602.18239.109.camel@baythorne.infradead.org> (David Woodhouse's message of "Fri, 04 Feb 2005 17:36:42 +0000") References: <1107537391.18239.106.camel@baythorne.infradead.org> <1107538138.5838.22.camel@localhost.localdomain> <1107538602.18239.109.camel@baythorne.infradead.org> Message-ID: <87sm4baoto.fsf@kosh.ultra.csn.tu-chemnitz.de> dwmw2 at infradead.org (David Woodhouse) writes: >> The update which is planed at >> http://bugzilla.fedora.us/show_bug.cgi?id=1715 >> >> does not need it anymore. > > Thanks. That one builds fine and is now in the FTP directory with the > others. > > Btw, this warning isn't relevant for FC3, is it? ... No; FC3 had the needed fix from the beginning. Only FC1/FC2 were affected by the zlib bug. The message is just a reminder/documentation about a disabled security switch ;) > ** WARNING: building with '--disable-zlib-vcheck' because Red Hat is unable > ** to apply a simple security fix within 5 months. On failures or > ** successful DOS attacks on your mailserver, please blame RH > ** but not fedora.us. > ** > ** See https://bugzilla.redhat.com/beta/show_bug.cgi?id=131385 > ** and http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0797 > ** for references Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 4 23:50:03 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 05 Feb 2005 00:50:03 +0100 Subject: Updating clamav In-Reply-To: <80d7e409050204152243df53df@mail.gmail.com> (Stephen J. Smoogen's message of "Fri, 4 Feb 2005 16:22:53 -0700") References: <80d7e409050204152243df53df@mail.gmail.com> Message-ID: <87oeezanro.fsf@kosh.ultra.csn.tu-chemnitz.de> smooge at gmail.com ("Stephen J. Smoogen") writes: > Extra currently has 0.71 clamav, and the stable clamav is 0.81 with > security fixes. With that in mind.. what can I do to get an updated > spec file/srpm/ for the build system? I really don't know if I shall give it free for publishing. There are lots of non-trivial changes between 0.71 and 0.81 which should pass QA first. But as you said... 0.71 has security issues and does not accept new databases. For now, you could either check it out from CVS or use my src.rpm[1] submitted for QA. Enrico Footnotes: [1] http://www-user.tu-chemnitz.de/~ensc/fedora/clamav-0.81-0.fdr.2.src.rpm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From smooge at gmail.com Sat Feb 5 00:02:27 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Fri, 4 Feb 2005 17:02:27 -0700 Subject: Updating clamav In-Reply-To: <87oeezanro.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <80d7e409050204152243df53df@mail.gmail.com> <87oeezanro.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <80d7e40905020416027b3a9c66@mail.gmail.com> On Sat, 05 Feb 2005 00:50:03 +0100, Enrico Scholz wrote: > smooge at gmail.com ("Stephen J. Smoogen") writes: > > > Extra currently has 0.71 clamav, and the stable clamav is 0.81 with > > security fixes. With that in mind.. what can I do to get an updated > > spec file/srpm/ for the build system? > > I really don't know if I shall give it free for publishing. There are > lots of non-trivial changes between 0.71 and 0.81 which should pass QA > first. But as you said... 0.71 has security issues and does not accept > new databases. > > For now, you could either check it out from CVS or use my src.rpm[1] > submitted for QA. > Ok what can I do to help QA this. I have been using the DAG version 0.81 on my RHEL-3 box.. and know most of the items needed. I am moving my RHEL-3 box to Fedora since my RHEL-QA license has ended. I would like to get the various code issues I have compiled for RHEL into the extras tree (mimedefang, and bsdgames) > Enrico > > Footnotes: > [1] http://www-user.tu-chemnitz.de/~ensc/fedora/clamav-0.81-0.fdr.2.src.rpm > Thanks I am recompiling locally and will test. > -- > 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 enrico.scholz at informatik.tu-chemnitz.de Sat Feb 5 00:12:25 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 05 Feb 2005 01:12:25 +0100 Subject: dietlibc maintainership Message-ID: <87ekfvamqe.fsf@kosh.ultra.csn.tu-chemnitz.de> Hello, as dietlibc will not exist anymore in FC4 and lot of my projects rely on it, I would like to see it in Extras. The current maintainer (Jeremy Katz) has not interest in continuing maintainership, so I would do this job. My spec file (see [1]) is *not* based on the FC3 one but is nearer on the upstream tarball (no patches). Are there any objections against this? If not, I will checkin it at monday into CVS. Enrico Footnotes: [1] https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From smooge at gmail.com Sat Feb 5 00:14:44 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Fri, 4 Feb 2005 17:14:44 -0700 Subject: Updating clamav In-Reply-To: <80d7e40905020416027b3a9c66@mail.gmail.com> References: <80d7e409050204152243df53df@mail.gmail.com> <87oeezanro.fsf@kosh.ultra.csn.tu-chemnitz.de> <80d7e40905020416027b3a9c66@mail.gmail.com> Message-ID: <80d7e409050204161477f99698@mail.gmail.com> On Fri, 4 Feb 2005 17:02:27 -0700, Stephen J. Smoogen wrote: > On Sat, 05 Feb 2005 00:50:03 +0100, Enrico Scholz > wrote: > > smooge at gmail.com ("Stephen J. Smoogen") writes: > > > > > Extra currently has 0.71 clamav, and the stable clamav is 0.81 with > > > security fixes. With that in mind.. what can I do to get an updated > > > spec file/srpm/ for the build system? > > > > I really don't know if I shall give it free for publishing. There are > > lots of non-trivial changes between 0.71 and 0.81 which should pass QA > > first. But as you said... 0.71 has security issues and does not accept > > new databases. > > Quick QA remarks: 1) .fdr. is no longer wanted in SPEC files. 2) zlib update for fedora core 2 has been released. Comment about --disable-zlib can be removed from several areas it is posted. -- Stephen J Smoogen. CSIRT/Linux System Administrator From enrico.scholz at informatik.tu-chemnitz.de Sat Feb 5 00:16:48 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 05 Feb 2005 01:16:48 +0100 Subject: dietlibc maintainership In-Reply-To: <87ekfvamqe.fsf@kosh.ultra.csn.tu-chemnitz.de> (Enrico Scholz's message of "Sat, 05 Feb 2005 01:12:25 +0100") References: <87ekfvamqe.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <877jlnamj3.fsf@kosh.ultra.csn.tu-chemnitz.de> enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) writes: > My spec file (see [1]) > ... > Footnotes: > [1] https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel oops... there was an old url in my clipboard... right one is http://www-user.tu-chemnitz.de/~ensc/fedora/dietlibc.spec Enrico From wtogami at redhat.com Sat Feb 5 02:11:13 2005 From: wtogami at redhat.com (Warren Togami) Date: Fri, 04 Feb 2005 16:11:13 -1000 Subject: dietlibc maintainership In-Reply-To: <877jlnamj3.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <87ekfvamqe.fsf@kosh.ultra.csn.tu-chemnitz.de> <877jlnamj3.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <42042B41.5000108@redhat.com> Enrico Scholz wrote: > enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) writes: > > >>My spec file (see [1]) >>... >>Footnotes: >>[1] https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel > > > oops... there was an old url in my clipboard... right one is > > http://www-user.tu-chemnitz.de/~ensc/fedora/dietlibc.spec > Go for it, I will review and sponsor your addition. Warren From skvidal at phy.duke.edu Sat Feb 5 05:12:02 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 05 Feb 2005 00:12:02 -0500 Subject: Including udftools In-Reply-To: <20050204105818.22b8a5ae@python2> References: <20050204105818.22b8a5ae@python2> Message-ID: <1107580322.8961.36.camel@cutter> On Fri, 2005-02-04 at 10:58 +0100, Matthias Saou wrote: > Hi, > > I just received this email about udftools : > Matthias: only two question: why not put this on fedora-extras-list? any reticence on your part for bringing it in? -sv From jwboyer at jdub.homelinux.org Sat Feb 5 05:20:43 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 04 Feb 2005 23:20:43 -0600 Subject: AFS in Extras Message-ID: <1107580844.21998.3.camel@jdub.homelinux.org> IIRC, someone out there had some RPMs that allowed AFS to be used with the 2.6 kernel. I don't remember who, but I do know a couple people using said RPMs. Any chance that person could come forward and maintain them for Fedora Extras? josh From skvidal at phy.duke.edu Sat Feb 5 05:30:06 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 05 Feb 2005 00:30:06 -0500 Subject: AFS in Extras In-Reply-To: <1107580844.21998.3.camel@jdub.homelinux.org> References: <1107580844.21998.3.camel@jdub.homelinux.org> Message-ID: <1107581406.8961.38.camel@cutter> On Fri, 2005-02-04 at 23:20 -0600, Josh Boyer wrote: > IIRC, someone out there had some RPMs that allowed AFS to be used with > the 2.6 kernel. I don't remember who, but I do know a couple people > using said RPMs. > > Any chance that person could come forward and maintain them for Fedora > Extras? The only trick there is the kernel modules involved. They are, umm, not fun to track when the kernel changes in core. -sv From ville.skytta at iki.fi Sat Feb 5 09:51:53 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 05 Feb 2005 11:51:53 +0200 Subject: PPC extras. In-Reply-To: <1107537391.18239.106.camel@baythorne.infradead.org> References: <1107537391.18239.106.camel@baythorne.infradead.org> Message-ID: <1107597113.30769.96.camel@bobcat.mine.nu> On Fri, 2005-02-04 at 17:16 +0000, David Woodhouse wrote: > Major failure mode so far has been random use of i386 inline assembly. A > bunch of packages failed due to files present in the buildroot which > aren't packaged, and clamav seems to want dietlibc. You don't happen to have the build logs available somewhere, so non-PPC- owner package maintainers could have a look? From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sat Feb 5 10:23:52 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sat, 5 Feb 2005 11:23:52 +0100 Subject: Including udftools In-Reply-To: <1107580322.8961.36.camel@cutter> References: <20050204105818.22b8a5ae@python2> <1107580322.8961.36.camel@cutter> Message-ID: <20050205112352.3ed22a38@python2> seth vidal wrote : > On Fri, 2005-02-04 at 10:58 +0100, Matthias Saou wrote: > > Hi, > > > > I just received this email about udftools : > > Matthias: > only two question: > why not put this on fedora-extras-list? > any reticence on your part for bringing it in? Two answers ;-) - Because I think it's a package for Core - Nope, I could package it for Extras for now, and let someone take it later on to include it into Core I was just asking in case some RH developer was already planning on putting it in now that the shipped kernel supports packet writing. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.47 0.23 0.14 From wtogami at redhat.com Sat Feb 5 10:47:08 2005 From: wtogami at redhat.com (Warren Togami) Date: Sat, 05 Feb 2005 00:47:08 -1000 Subject: AFS in Extras In-Reply-To: <1107581406.8961.38.camel@cutter> References: <1107580844.21998.3.camel@jdub.homelinux.org> <1107581406.8961.38.camel@cutter> Message-ID: <4204A42C.8060306@redhat.com> seth vidal wrote: > On Fri, 2005-02-04 at 23:20 -0600, Josh Boyer wrote: > >>IIRC, someone out there had some RPMs that allowed AFS to be used with >>the 2.6 kernel. I don't remember who, but I do know a couple people >>using said RPMs. >> >>Any chance that person could come forward and maintain them for Fedora >>Extras? > > > The only trick there is the kernel modules involved. > > They are, umm, not fun to track when the kernel changes in core. > > -sv https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145914 We need to come to agreement on this (and maybe other issues), implement, document and backport to FC3. Then we will have a common standard for kernel module packaging in Extras. Warren Togami wtogami at redhat.com From dwmw2 at infradead.org Sat Feb 5 11:28:48 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 05 Feb 2005 11:28:48 +0000 Subject: PPC extras. In-Reply-To: <1107597113.30769.96.camel@bobcat.mine.nu> References: <1107537391.18239.106.camel@baythorne.infradead.org> <1107597113.30769.96.camel@bobcat.mine.nu> Message-ID: <1107602928.7716.9.camel@baythorne.infradead.org> On Sat, 2005-02-05 at 11:51 +0200, Ville Skytt? wrote: > You don't happen to have the build logs available somewhere, so non- > PPC-owner package maintainers could have a look? ftp://peach.ipv6.infradead.org/pub/SRPMS.extras/logs/ gpgme fails its own gpgsm tests. cvsup wants switching to cm3 which supports PPC. I may also separate modula3 and modula3-devel and a bunch of the libraries into separate packages. I did that once before, long ago. Inventor needs a GCC bug fixed (the RHEL4 GCC also ICEs on this one). torcs seems to use -mieee-fp in its autocrap script and hence decides that libm isn't present on the system and aborts. stow and gnugo fail due to /usr/share/info/dir being present in the buildroot but unpackaged. fbida fails due to /usr/X11R6/lib/X11/app-defaults/Ida being present but unpackaged. A whole bunch of other stuff fails due to random use of inline assembly. -- dwmw2 From dwmw2 at infradead.org Sat Feb 5 11:34:29 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 05 Feb 2005 11:34:29 +0000 Subject: AFS in Extras In-Reply-To: <1107581406.8961.38.camel@cutter> References: <1107580844.21998.3.camel@jdub.homelinux.org> <1107581406.8961.38.camel@cutter> Message-ID: <1107603269.7716.13.camel@baythorne.infradead.org> On Sat, 2005-02-05 at 00:30 -0500, seth vidal wrote: > > Any chance that person could come forward and maintain them for > > Fedora Extras? > > The only trick there is the kernel modules involved. > > They are, umm, not fun to track when the kernel changes in core. The correct solution is just to finish the write support in the real Linux AFS code. All the keyring management stuff is now in, which is mostly what we were waiting for. -- dwmw2 From ville.skytta at iki.fi Sat Feb 5 12:23:22 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 05 Feb 2005 14:23:22 +0200 Subject: Bugzilla usage (was: Re: kmymoney2) In-Reply-To: <1107533474.31004.17.camel@opus.phy.duke.edu> References: <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <20050131222016.GA9816@thacker.dyndns.org> <1107505209l.7472l.3l@devel.mpeters.us> <4203907A.1040505@math.unl.edu> <1107530306.31004.5.camel@opus.phy.duke.edu> <20050204165120.22c14585@python2> <1107533474.31004.17.camel@opus.phy.duke.edu> Message-ID: <1107606202.30769.183.camel@bobcat.mine.nu> On Fri, 2005-02-04 at 11:11 -0500, seth vidal wrote: > > Regarding this... I never liked using bugzilla from the very beginning, and > > I find it much easier to reach a large "mostly passive" community through a > > mailing-list than through a bugzilla. My ideal way of working would be : > > I agree. But if you're going to open a bug - definitely do it in > bugzilla.r.c :) Agreed, except I have no problem with using Bugzilla. > > 1) Make requests for new packages, or post links to packages in order to > > submit them on the mailing-list (so maybe later on have a > > fedora-extras-devel-list for that and use fedora-extras similarly to > > fedora-list). Good. > I'd actually encourage things to work as: > fedora-list for problems in fc or fe. If that means that package maintainers need to subscribe to yet another high volume mailing list (this one with a low S/N ratio, I guess), personal opinion: no thank you. > fedora-extras-list for devel, > requests for packages and itp messages, as well as discussion. Fine, but see below. > > 2) From there, let discussions and initial improvements and fixes take > > place, everyone sees them immediately and may participate (see the snort > > messages from the past 2 days). > > Disagreement. This will cause too much traffic, and people cannot choose to not receive stuff they're not interested in. Example: my Ctrl-D fingers are getting tired because of the Snort discussions. I'd rather see discussion moved to Bugzilla earlier when the effort to package or QA something starts, ie. when someone posts a "I'm interested in helping out with this" response to a ITP/submission/request + a link to the Bugzilla entry posted to the list so interested parties can choose to track and participate; no need to broadcast this to everyone. In the Bugzilla side, there's already a QA contact set for all Extras entries. I don't know where those messages end up currently, but that could be a mailing list where people wanting to see all of that traffic could subscribe to. Bugzilla is smart enough to add an In-Reply-To header to the mails it sends, so threads should work too. > > 3) Once the package passes initial QA, then have the maintainer import it > > into Extras, and have all that is needed created (CVS directory by the > > import, bugzilla component...). > > WORKSFORME Ditto. > > 4) Start using bugzilla from there on for that package, pretty much like it > > has always been done for RH/FC. > > yop. Yep. > > This will avoid bloating bugzilla with repeated RFE's regarding packages > > that can't be included (think any package that seems ok but needs to link > > to a patent encumbered lib to be useful), Yes, but instead, we'll see mailing list archives bloated with this stuff and repeated RFE's broadcast to the world via the lists. With Bugzilla, it's somewhat better: one can add a keyword for requests for packages that cannot be included. Place the link to a query listing these packages somewhere prominently, teach users to click & skim that before placing such a RFE, problem solved. If not Bugzilla, maintain a separate document. Mailing lists are not the answer for this, they're actually the worst choice when used alone. > > and most of all from gazillions > > of open submissions that will stay open forever (like in fedora.us). IMO, this is a welcome feature, not a problem. If something stays open forever, it means there's not enough interest to include it. Keeping an open entry available somewhere in case interested parties surface later helps in reducing dupes, and keeps track of past experiences. > > I really hope to see Fedora Extras draw a clear line between "what's in" on > > one side, and "what isn't yet / what will never be" on the other. The "never" part is the same as for Fedora Core. There are basic rules on what cannot be included. In addition to that, a list of packages that fall under this category probably needs to be maintained somewhere, see above. Remaining two categories: what's in is what's in (unless due to some changes it will move to the "never" category), and what isn't yet is what's left after the "in" and "never" parts. What clear lines remain to be drawn _in Extras_? > However, I do think that if you want something > tracked over the long term it needs to be in bugzilla. Right. From ville.skytta at iki.fi Sat Feb 5 12:27:24 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 05 Feb 2005 14:27:24 +0200 Subject: don't use bugzilla.fedora.us In-Reply-To: <42039498.9020209@math.unl.edu> References: <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <20050131222016.GA9816@thacker.dyndns.org> <1107505209l.7472l.3l@devel.mpeters.us> <4203907A.1040505@math.unl.edu> <1107530306.31004.5.camel@opus.phy.duke.edu> <4203931B.6040407@math.unl.edu> <1107530799.31004.11.camel@opus.phy.duke.edu> <42039498.9020209@math.unl.edu> Message-ID: <1107606444.30769.188.camel@bobcat.mine.nu> On Fri, 2005-02-04 at 09:28 -0600, Rex Dieter wrote: > seth vidal wrote: > >>My apologies... I must've misread previous announcements. > >> > >>Should existing submissions to bugzilla.fedora.us should be re-submitted > >>to bugzilla.redhat.com? > > > > I think closing them out if they're closeable and only opening new items > > in bugzilla.r.c would make the most sense. > > > > seem reasonable? > > Sounds very reasonable to me. Ditto, but for >= FC3 only. Stuff destined to download.fedora.us FC2 and older repos should still be submitted to bugzilla.fedora.us. Don't start closing any b.f.u entries without taking this into account. From mccabemt at gmail.com Sat Feb 5 12:35:18 2005 From: mccabemt at gmail.com (Michael McCabe) Date: Sat, 05 Feb 2005 07:35:18 -0500 Subject: AFS in Extras In-Reply-To: <1107603269.7716.13.camel@baythorne.infradead.org> References: <1107580844.21998.3.camel@jdub.homelinux.org> <1107581406.8961.38.camel@cutter> <1107603269.7716.13.camel@baythorne.infradead.org> Message-ID: <4204BD86.1050203@gmail.com> Would we be waiting until Open AFS is stable? David Woodhouse wrote: >On Sat, 2005-02-05 at 00:30 -0500, seth vidal wrote: > > >>>Any chance that person could come forward and maintain them for >>>Fedora Extras? >>> >>> >>The only trick there is the kernel modules involved. >> >>They are, umm, not fun to track when the kernel changes in core. >> >> > >The correct solution is just to finish the write support in the real >Linux AFS code. All the keyring management stuff is now in, which is >mostly what we were waiting for. > > > From jwboyer at jdub.homelinux.org Sat Feb 5 12:42:24 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 05 Feb 2005 06:42:24 -0600 Subject: AFS in Extras In-Reply-To: <1107603269.7716.13.camel@baythorne.infradead.org> References: <1107580844.21998.3.camel@jdub.homelinux.org> <1107581406.8961.38.camel@cutter> <1107603269.7716.13.camel@baythorne.infradead.org> Message-ID: <1107607344.21998.5.camel@jdub.homelinux.org> On Sat, 2005-02-05 at 11:34 +0000, David Woodhouse wrote: > On Sat, 2005-02-05 at 00:30 -0500, seth vidal wrote: > > > Any chance that person could come forward and maintain them for > > > Fedora Extras? > > > > The only trick there is the kernel modules involved. > > > > They are, umm, not fun to track when the kernel changes in core. > > The correct solution is just to finish the write support in the real > Linux AFS code. All the keyring management stuff is now in, which is > mostly what we were waiting for. That would make me even happier. But until that's done, OpenAFS supposedly works now... josh From mccabemt at gmail.com Sat Feb 5 12:49:18 2005 From: mccabemt at gmail.com (Michael McCabe) Date: Sat, 05 Feb 2005 07:49:18 -0500 Subject: AFS in Extras In-Reply-To: <1107607344.21998.5.camel@jdub.homelinux.org> References: <1107580844.21998.3.camel@jdub.homelinux.org> <1107581406.8961.38.camel@cutter> <1107603269.7716.13.camel@baythorne.infradead.org> <1107607344.21998.5.camel@jdub.homelinux.org> Message-ID: <4204C0CE.3040800@gmail.com> It works but its stability still leaves something to be desired. If someone was interested in helping me get off the ground I might be able to maintain the RPMs for the next year. (I've never packaged kernel modules before) Mike 'Josh Boyer wrote: >On Sat, 2005-02-05 at 11:34 +0000, David Woodhouse wrote: > > >>On Sat, 2005-02-05 at 00:30 -0500, seth vidal wrote: >> >> >>>>Any chance that person could come forward and maintain them for >>>>Fedora Extras? >>>> >>>> >>>The only trick there is the kernel modules involved. >>> >>>They are, umm, not fun to track when the kernel changes in core. >>> >>> >>The correct solution is just to finish the write support in the real >>Linux AFS code. All the keyring management stuff is now in, which is >>mostly what we were waiting for. >> >> > >That would make me even happier. But until that's done, OpenAFS >supposedly works now... > >josh > >-- >fedora-extras-list mailing list >fedora-extras-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-extras-list > > > From dwmw2 at infradead.org Sat Feb 5 13:20:33 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 05 Feb 2005 13:20:33 +0000 Subject: AFS in Extras In-Reply-To: <4204BD86.1050203@gmail.com> References: <1107580844.21998.3.camel@jdub.homelinux.org> <1107581406.8961.38.camel@cutter> <1107603269.7716.13.camel@baythorne.infradead.org> <4204BD86.1050203@gmail.com> Message-ID: <1107609633.19262.398.camel@hades.cambridge.redhat.com> On Sat, 2005-02-05 at 07:35 -0500, Michael McCabe top-posted: > Would we be waiting until Open AFS is stable? No, the new code bears no relation to OpenAFS. Please don't top-post. -- dwmw2 From gauret at free.fr Sat Feb 5 16:58:03 2005 From: gauret at free.fr (Aurelien Bompard) Date: Sat, 05 Feb 2005 17:58:03 +0100 Subject: Bugzilla usage (was: Re: kmymoney2) References: <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <20050131222016.GA9816@thacker.dyndns.org> <1107505209l.7472l.3l@devel.mpeters.us> <4203907A.1040505@math.unl.edu> <1107530306.31004.5.camel@opus.phy.duke.edu> <20050204165120.22c14585@python2> <1107533474.31004.17.camel@opus.phy.duke.edu> <1107606202.30769.183.camel@bobcat.mine.nu> Message-ID: Ville Skytt? wrote: > Disagreement.??This?will?cause?too?much?traffic,?and?people?cannot > choose to not receive stuff they're not interested in.??Example:?my > Ctrl-D fingers are getting tired because of the Snort discussions. I have no problem with bugzilla either (mainly because I used it a lot at fedora.us), but at least you can choose what you read from the mailing lists if you use GMane's NNTP gateway. I personally access all the fedora-related lists with my news client, and it works great. I also like the fact that a bugzilla query is easier than a search in the online mailing-list archives (especially if we use keywords). Making the search easy is what will lower the level of duplicate RFEs. We need a database behind it. I think we need something web-based on top of the mailing-list. Maybe bugzilla is not fit for the task (because too complex), but then, what could we use ? Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "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 mattdm at mattdm.org Sat Feb 5 17:14:58 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 5 Feb 2005 12:14:58 -0500 Subject: AFS in Extras In-Reply-To: <1107580844.21998.3.camel@jdub.homelinux.org> References: <1107580844.21998.3.camel@jdub.homelinux.org> Message-ID: <20050205171458.GA1641@jadzia.bu.edu> On Fri, Feb 04, 2005 at 11:20:43PM -0600, Josh Boyer wrote: > IIRC, someone out there had some RPMs that allowed AFS to be used with > the 2.6 kernel. I don't remember who, but I do know a couple people > using said RPMs. Me, maybe? > Any chance that person could come forward and maintain them for Fedora > Extras? Possibly. There's quite a few things I'm not really happy with yet -- in particular, the way the kernel modules get made ends up pretty much completely ignoring any RPM dependency information, which is unfortunate. And, there's a lot of crazy unstability right now, with surprises with every new kernel release. At the very least, I think this should wait for the 1.4 OpenAFS release. Part of the problem is a collision between Fedora's new plan -- "track upstream as closely as possible" -- and the new 2.6 kernel world order -- "2.6 isn't really stable; vendors make forked branches which are stable". Both fine ideas on their own, but a bad mix. This particularly shows up with external modules like OpenAFS, but, on a tangental note, probably also explains why my updated system at work kernel panics with the new FC2 errata kernel on boot with something with the adaptec SCSI driver. (I'm at home with the new baby, so this is just a report from someone else of what's on the screen when the machine failed to come back up.) Anyway, I'm not really sure what to do about it, other than: 1) Hope that major donations to openafs development catch on: and major and ongoing Linux development takes place or 2) hope that NFS4 ends up being amazing and perfect, and start migrating everything or 3) hope that the in-kernel AFS client gets some lovin'. (Unlikely, from what I've heard, unless, again, some major money shows up.) -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From mattdm at mattdm.org Sat Feb 5 17:22:49 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 5 Feb 2005 12:22:49 -0500 Subject: AFS in Extras In-Reply-To: <1107603269.7716.13.camel@baythorne.infradead.org> References: <1107580844.21998.3.camel@jdub.homelinux.org> <1107581406.8961.38.camel@cutter> <1107603269.7716.13.camel@baythorne.infradead.org> Message-ID: <20050205172249.GC1641@jadzia.bu.edu> On Sat, Feb 05, 2005 at 11:34:29AM +0000, David Woodhouse wrote: > > The only trick there is the kernel modules involved. > > They are, umm, not fun to track when the kernel changes in core. > The correct solution is just to finish the write support in the real > Linux AFS code. All the keyring management stuff is now in, which is > mostly what we were waiting for. Is that really all that's missing at this point? I should look again, then. What about caching? And the mountpoint thing? -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From mattdm at mattdm.org Sat Feb 5 17:15:17 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 5 Feb 2005 12:15:17 -0500 Subject: AFS in Extras In-Reply-To: <1107581406.8961.38.camel@cutter> References: <1107580844.21998.3.camel@jdub.homelinux.org> <1107581406.8961.38.camel@cutter> Message-ID: <20050205171517.GB1641@jadzia.bu.edu> On Sat, Feb 05, 2005 at 12:30:06AM -0500, seth vidal wrote: > The only trick there is the kernel modules involved. > They are, umm, not fun to track when the kernel changes in core. That is *such* a huge "umm". :) -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From skvidal at phy.duke.edu Sat Feb 5 17:53:26 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 05 Feb 2005 12:53:26 -0500 Subject: AFS in Extras In-Reply-To: <20050205171517.GB1641@jadzia.bu.edu> References: <1107580844.21998.3.camel@jdub.homelinux.org> <1107581406.8961.38.camel@cutter> <20050205171517.GB1641@jadzia.bu.edu> Message-ID: <1107626006.15457.2.camel@cutter> On Sat, 2005-02-05 at 12:15 -0500, Matthew Miller wrote: > On Sat, Feb 05, 2005 at 12:30:06AM -0500, seth vidal wrote: > > The only trick there is the kernel modules involved. > > They are, umm, not fun to track when the kernel changes in core. > > That is *such* a huge "umm". :) U M M that better? :) -sv From justin.georgeson at gmail.com Sat Feb 5 22:35:45 2005 From: justin.georgeson at gmail.com (Justin Georgeson) Date: Sat, 5 Feb 2005 22:35:45 +0000 (UTC) Subject: fedora-extras-release References: <1107406975.7339.1.camel@cutter> <20050203071322.GC8404@nostromo.devel.redhat.com> <1107415133.7339.25.camel@cutter> <1107458805.5647.78.camel@localhost.localdomain> <20050203204245.1a5e03b6@python2> <1107464852.2013.38.camel@opus.phy.duke.edu> <20050203233111.04bbc0c2@python2> <1107470065.2013.60.camel@opus.phy.duke.edu> <20050203235521.456d30df@python2> Message-ID: Matthias Saou writes: > Too bad though that it seems sysconfig/rhn/ can only take info from the > single "sources" file, as from my understanding this means that the current > RHN notification tool won't automatically be aware of Extras after this > package is installed. Add a post install script that does echo "..." >> /etc/sysconfig/rhn/sources and a post uninstall script that does grep -v "..." /etc/sysconfig/rhn/sources > /tmp/sources.new mv /etc/sysconfig/rhn/sources.rpmsave mv /tmp/sources.new /etc/sysconfig/rhn/sources You could add some 'if [ $? != 0 ]; ...' stuff to rollout the changes if a command fails, but it would mean that up2date can use Extras and the rhn_applet will se updates. :) From jim-cornette at insight.rr.com Sat Feb 5 23:33:36 2005 From: jim-cornette at insight.rr.com (Jim Cornette) Date: Sat, 05 Feb 2005 18:33:36 -0500 Subject: fedora-extras-release In-Reply-To: References: <1107406975.7339.1.camel@cutter> <20050203071322.GC8404@nostromo.devel.redhat.com> <1107415133.7339.25.camel@cutter> <1107458805.5647.78.camel@localhost.localdomain> <20050203204245.1a5e03b6@python2> <1107464852.2013.38.camel@opus.phy.duke.edu> <20050203233111.04bbc0c2@python2> <1107470065.2013.60.camel@opus.phy.duke.edu> <20050203235521.456d30df@python2> Message-ID: <420557D0.8070502@insight.rr.com> Justin Georgeson wrote: >Matthias Saou writes: > > > >>Too bad though that it seems sysconfig/rhn/ can only take info from the >>single "sources" file, as from my understanding this means that the current >>RHN notification tool won't automatically be aware of Extras after this >>package is installed. >> >> > >Add a post install script that does > >echo "..." >> /etc/sysconfig/rhn/sources > >and a post uninstall script that does > >grep -v "..." /etc/sysconfig/rhn/sources > /tmp/sources.new >mv /etc/sysconfig/rhn/sources.rpmsave >mv /tmp/sources.new /etc/sysconfig/rhn/sources > >You could add some 'if [ $? != 0 ]; ...' stuff to rollout the changes if a >command fails, but it would mean that up2date can use Extras and the rhn_applet >will se updates. > >:) > >-- >fedora-extras-list mailing list >fedora-extras-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-extras-list > > > I'd me more in favor of the script checking the /etc/sysconfig/rhn/sources to see if an entry exists, then appending the entry into the file if there are no entries for fedora-extras. I use up2date a lot and use specific mirrors that I would not like to have bothered. Jim -- character density, n.: The number of very weird people in the office. From toshio at tiki-lounge.com Sun Feb 6 05:51:42 2005 From: toshio at tiki-lounge.com (Toshio) Date: Sun, 06 Feb 2005 00:51:42 -0500 Subject: More python x86_64 packages (Was Re: pexpect spec/srpm) In-Reply-To: <200502041838.08893.gauret@free.fr> References: <20050203171354.A3456@tiki-lounge.com> <20050204092515.A21028@tiki-lounge.com> <200502041838.08893.gauret@free.fr> Message-ID: <1107669103.454.24.camel@Madison.badger.com> Hi Aur?lien, Thanks for testing the pexpect changes. I have some more packages to test if they build on x86_64: Packages slightly modifed from Fedora Extras SRPMS: straw http://www.tiki-lounge.com/~toshio/fedora/straw-0.22.1-5.src.rpm pyzor http://www.tiki-lounge.com/~toshio/fedora/pyzor-0.4.0-7.src.rpm python-dialog http://www.tiki-lounge.com/~toshio/fedora/python-dialog-2.0.6-2.src.rpm Package modified from the update on fedora.us: gnome-blog http://www.tiki-lounge.com/~toshio/fedora/gnome-blog-0.8-0.fdr.3.src.rpm Package already checked: pexpect http://www.tiki-lounge.com/~toshio/fedora/pexpect-0.999-2.src.rpm All of them build on i386. Except for pyzor, I did a minimal test to see if they'd run after being built as well (which they all did). (pyzor will run "help" and "discover". Beyond that, I didn't test for correct operation.) Assuming these now build and run on x86_64, what's the next step? Does someone want to check them into CVS on Monday or should I submit diffs in bugzilla.redhat.com? -Toshio PS: Aur?lien I noticed that python-dialog has an update on http://sourceforge.net/projects/pythondialog/ New maintainers, but it looks like a bugfix release. On Fri, 2005-02-04 at 18:38 +0100, Aurelien Bompard wrote: > It rebuilds fine, installs fine, and I've tested a few examples shipped with > it, they seem to work fine. > This looks good to me :) > > Bye, > > Aur?lien -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From byte at aeon.com.my Sun Feb 6 07:55:16 2005 From: byte at aeon.com.my (Colin Charles) Date: Sun, 06 Feb 2005 15:55:16 +0800 Subject: PPC extras. In-Reply-To: <1107537391.18239.106.camel@baythorne.infradead.org> References: <1107537391.18239.106.camel@baythorne.infradead.org> Message-ID: <1107676517.5367.77.camel@localhost.localdomain> On Fri, 2005-02-04 at 17:16 +0000, David Woodhouse wrote: > Any suggestions for how best to automate the Extras/ppc builds in > future > would be welcomed. Using the script that seth uses for building x86/x86_64 will be appropriate, I'm guessing What is it built against, the FC-3 snapshot we posted at duke/fedoraproject, or Rawhide? -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From wtogami at redhat.com Sun Feb 6 08:16:42 2005 From: wtogami at redhat.com (Warren Togami) Date: Sat, 05 Feb 2005 22:16:42 -1000 Subject: More python x86_64 packages (Was Re: pexpect spec/srpm) In-Reply-To: <1107669103.454.24.camel@Madison.badger.com> References: <20050203171354.A3456@tiki-lounge.com> <20050204092515.A21028@tiki-lounge.com> <200502041838.08893.gauret@free.fr> <1107669103.454.24.camel@Madison.badger.com> Message-ID: <4205D26A.8070705@redhat.com> Toshio wrote: > > Assuming these now build and run on x86_64, what's the next step? Does > someone want to check them into CVS on Monday or should I submit diffs > in bugzilla.redhat.com? The regular method of tracking issues is filing bugs against those components in Bugzilla and it is the package owner's responsibility to fix them. This is especially important when there are multiple different issues, because it is otherwise confusing. When submitting changes, it is always best to submit unidiff patches rather than full SRPMS, especially when changes are relatively small. Warren Togami wtogami at redhat.com From gauret at free.fr Sun Feb 6 11:36:09 2005 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 6 Feb 2005 12:36:09 +0100 Subject: More python x86_64 packages (Was Re: pexpect spec/srpm) In-Reply-To: <1107669103.454.24.camel@Madison.badger.com> References: <20050203171354.A3456@tiki-lounge.com> <200502041838.08893.gauret@free.fr> <1107669103.454.24.camel@Madison.badger.com> Message-ID: <200502061236.12029.gauret@free.fr> Hi ! > Packages slightly modifed from Fedora Extras SRPMS: > straw > http://www.tiki-lounge.com/~toshio/fedora/straw-0.22.1-5.src.rpm It builds fine, but it's a noarch package anyway. I get a few depreciation warnings on launch : /usr/lib/python2.3/site-packages/straw/MainWindow.py:785: DeprecationWarning: use gtk.UIManager self._item_factory = gtk.ItemFactory(gtk.Menu, '') /usr/lib/python2.3/site-packages/straw/MainWindow.py:588: DeprecationWarning: use gtk.UIManager self.item_factory = gtk.ItemFactory(gtk.Menu, "") /usr/lib/python2.3/site-packages/straw/MainWindow.py:239: DeprecationWarning: use gtk.UIManager self._item_factory = gtk.ItemFactory(gtk.Menu, '') Use of deprecated SAXv1 function characters Apart from that, it seems to run fine. > pyzor > http://www.tiki-lounge.com/~toshio/fedora/pyzor-0.4.0-7.src.rpm Builds fine, but it's a noarch too. Seems to run fine > python-dialog > http://www.tiki-lounge.com/~toshio/fedora/python-dialog-2.0.6-2.src.rpm Builds fine (noarch), runs fine. I'll update it. > Package modified from the update on fedora.us: > gnome-blog > http://www.tiki-lounge.com/~toshio/fedora/gnome-blog-0.8-0.fdr.3.src.rpm Builds fine (noarch). Can't test it since I don't have a blog (yes, it's true !). I don't use GNOME, and when I launch gnome-blog-poster from the command line, I get : $ gnome-blog-poster Traceback (most recent call last): File "/usr/bin/gnome-blog-poster", line 51, in ? app = BloggerApp() File "/usr/bin/gnome-blog-poster", line 32, in __init__ poster._showPrefDialog() UnboundLocalError: local variable 'poster' referenced before assignment Is this a bug ? Bye, Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info A Black Hole is where God divided by zero. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 220 bytes Desc: not available URL: From dwmw2 at infradead.org Sun Feb 6 11:54:21 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 06 Feb 2005 11:54:21 +0000 Subject: PPC extras. In-Reply-To: <1107676517.5367.77.camel@localhost.localdomain> References: <1107537391.18239.106.camel@baythorne.infradead.org> <1107676517.5367.77.camel@localhost.localdomain> Message-ID: <1107690861.7716.14.camel@baythorne.infradead.org> On Sun, 2005-02-06 at 15:55 +0800, Colin Charles wrote: > What is it built against, the FC-3 snapshot we posted at > duke/fedoraproject, or Rawhide? Building on FC3 at the moment -- I don't have anything running rawhide yet. -- dwmw2 From dwmw2 at infradead.org Sun Feb 6 12:48:04 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 06 Feb 2005 12:48:04 +0000 Subject: AFS in Extras In-Reply-To: <20050205172249.GC1641@jadzia.bu.edu> References: <1107580844.21998.3.camel@jdub.homelinux.org> <1107581406.8961.38.camel@cutter> <1107603269.7716.13.camel@baythorne.infradead.org> <20050205172249.GC1641@jadzia.bu.edu> Message-ID: <1107694084.7716.23.camel@baythorne.infradead.org> On Sat, 2005-02-05 at 12:22 -0500, Matthew Miller wrote: > > The correct solution is just to finish the write support in the real > > Linux AFS code. All the keyring management stuff is now in, which is > > mostly what we were waiting for. > > Is that really all that's missing at this point? I should look again, > then. What about caching? And the mountpoint thing? As I understand it, all the caching code is there and should be workable. Write support is completely absent because it was waiting for the keyrings -- that's what we were _waiting_ for; it's not the only thing that was missing. -- dwmw2 From toshio at tiki-lounge.com Sun Feb 6 14:53:16 2005 From: toshio at tiki-lounge.com (Toshio) Date: Sun, 06 Feb 2005 09:53:16 -0500 Subject: More python x86_64 packages (Was Re: pexpect spec/srpm) In-Reply-To: <4205D26A.8070705@redhat.com> References: <20050203171354.A3456@tiki-lounge.com> <20050204092515.A21028@tiki-lounge.com> <200502041838.08893.gauret@free.fr> <1107669103.454.24.camel@Madison.badger.com> <4205D26A.8070705@redhat.com> Message-ID: <1107701596.12599.1.camel@Madison.badger.com> On Sat, 2005-02-05 at 22:16 -1000, Warren Togami wrote: > Toshio wrote: > > > > Assuming these now build and run on x86_64, what's the next step? Does > > someone want to check them into CVS on Monday or should I submit diffs > > in bugzilla.redhat.com? > > The regular method of tracking issues is filing bugs against those > components in Bugzilla and it is the package owner's responsibility to > fix them. This is especially important when there are multiple > different issues, because it is otherwise confusing. > > When submitting changes, it is always best to submit unidiff patches > rather than full SRPMS, especially when changes are relatively small. Roger wilco. I'll make diffs when cvs comes back on Monday and submit to bugzilla. Thanks, -Toshio -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Sun Feb 6 14:59:08 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 06 Feb 2005 08:59:08 -0600 Subject: AFS in Extras In-Reply-To: <20050205171458.GA1641@jadzia.bu.edu> References: <1107580844.21998.3.camel@jdub.homelinux.org> <20050205171458.GA1641@jadzia.bu.edu> Message-ID: <1107701949.5684.5.camel@jdub.homelinux.org> On Sat, 2005-02-05 at 12:14 -0500, Matthew Miller wrote: > On Fri, Feb 04, 2005 at 11:20:43PM -0600, Josh Boyer wrote: > > IIRC, someone out there had some RPMs that allowed AFS to be used with > > the 2.6 kernel. I don't remember who, but I do know a couple people > > using said RPMs. > > Me, maybe? Yeah! > Possibly. There's quite a few things I'm not really happy with yet -- in > particular, the way the kernel modules get made ends up pretty much > completely ignoring any RPM dependency information, which is unfortunate. Seems you aren't the only one :). > > And, there's a lot of crazy unstability right now, with surprises with every > new kernel release. At the very least, I think this should wait for the 1.4 > OpenAFS release. Any ideas on when that is? I don't follow OpenAFS mailing lists too often. > 2) hope that NFS4 ends up being amazing and perfect, and start migrating > everything Sadly migration really isn't an option for me... > 3) hope that the in-kernel AFS client gets some lovin'. (Unlikely, from > what I've heard, unless, again, some major money shows up.) > David Howells was working on it at one point. Seems not anymore. josh From ghenry at suretecsystems.com Sun Feb 6 15:05:21 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sun, 6 Feb 2005 15:05:21 -0000 (GMT) Subject: Orphaned Packages Message-ID: <1327.192.168.100.89.1107702321.squirrel@webmail.suretecsystems.com> Hi all, Just looking at: http://fedoraproject.org/wiki/Extras/OrphanedPackages What does one do to take one over :-) Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1467 624141 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From toshio at tiki-lounge.com Sun Feb 6 15:09:21 2005 From: toshio at tiki-lounge.com (Toshio) Date: Sun, 06 Feb 2005 10:09:21 -0500 Subject: More python x86_64 packages (Was Re: pexpect spec/srpm) In-Reply-To: <200502061236.12029.gauret@free.fr> References: <20050203171354.A3456@tiki-lounge.com> <200502041838.08893.gauret@free.fr> <1107669103.454.24.camel@Madison.badger.com> <200502061236.12029.gauret@free.fr> Message-ID: <1107702562.12599.16.camel@Madison.badger.com> On Sun, 2005-02-06 at 12:36 +0100, Aurelien Bompard wrote: > Hi ! > > > Packages slightly modifed from Fedora Extras SRPMS: > > straw > > http://www.tiki-lounge.com/~toshio/fedora/straw-0.22.1-5.src.rpm > > It builds fine, but it's a noarch package anyway. I get a few depreciation > warnings on launch : > /usr/lib/python2.3/site-packages/straw/MainWindow.py:785: > DeprecationWarning: use gtk.UIManager > self._item_factory = gtk.ItemFactory(gtk.Menu, '') > /usr/lib/python2.3/site-packages/straw/MainWindow.py:588: > DeprecationWarning: use gtk.UIManager > self.item_factory = gtk.ItemFactory(gtk.Menu, "") > /usr/lib/python2.3/site-packages/straw/MainWindow.py:239: > DeprecationWarning: use gtk.UIManager > self._item_factory = gtk.ItemFactory(gtk.Menu, '') > Use of deprecated SAXv1 function characters > > Apart from that, it seems to run fine. > I get those warnings on FC3 i386 too. There's a new version of straw that may address these but there were problems found during QA: https://bugzilla.fedora.us/show_bug.cgi?id=1841 > > pyzor > > http://www.tiki-lounge.com/~toshio/fedora/pyzor-0.4.0-7.src.rpm > > Builds fine, but it's a noarch too. Seems to run fine > > > python-dialog > > http://www.tiki-lounge.com/~toshio/fedora/python-dialog-2.0.6-2.src.rpm > > Builds fine (noarch), runs fine. I'll update it. > Great! Do you want me to open a bug for this or would that just be redundant at this point? > > Package modified from the update on fedora.us: > > gnome-blog > > http://www.tiki-lounge.com/~toshio/fedora/gnome-blog-0.8-0.fdr.3.src.rpm > > Builds fine (noarch). Can't test it since I don't have a blog (yes, it's > true !). I don't use GNOME, and when I launch gnome-blog-poster from the > command line, I get : > $ gnome-blog-poster > Traceback (most recent call last): > File "/usr/bin/gnome-blog-poster", line 51, in ? > app = BloggerApp() > File "/usr/bin/gnome-blog-poster", line 32, in __init__ > poster._showPrefDialog() > UnboundLocalError: local variable 'poster' referenced before assignment > > Is this a bug ? > Yep. Looks to be a bug in the gnome-blog code. I'll have a go at fixing it and submit it as a separate bugzilla for gnome-blog. Looks good then, I'll make some diffs against the CVS devel specs and submit to bugzilla on Monday. I'll mention that you had success building and testing them on x86_64 in the bug reports and reference this email thread. Thanks! -Toshio -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pcompton at proteinmedia.com Sun Feb 6 15:40:13 2005 From: pcompton at proteinmedia.com (Phillip Compton) Date: Sun, 06 Feb 2005 10:40:13 -0500 Subject: Anjuta x86_64 crashes when creatina a new project. In-Reply-To: <20050203181708.2e28db6c@python2> References: <420249B1.8000406@gmail.com> <20050203175632.49ef4f4a.fedora@wir-sind-cool.org> <20050203181708.2e28db6c@python2> Message-ID: <1107704414.5277.19.camel@earlgrey.compton.net> On Thu, 2005-02-03 at 18:17 +0100, Matthias Saou wrote: > BTW, about the anjuta rpm, one thing that needs fixing is adding > gettext-devel to the requirements. I just got this report from a user : > Requires: gettext-devel for your package so that the behavior is as > expected? Thanks Matthias, I enjoy mirroring your site for use by workers > here in our office. > > -- > > If pcompton is lurking, I hope he'll pick it up, otherwise, the next person > to open a bug report could include it as a bonus ;-) *de-lurks for a second* I'll be sure to include that once cvs is back, unless you'd rather be the Extras maintainer, Matthias. You've been packaging Anjuta for quite some time, and I'll happily step aside if you'd like to continue with it. Phil From mattdm at mattdm.org Sun Feb 6 17:09:58 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 6 Feb 2005 12:09:58 -0500 Subject: AFS in Extras In-Reply-To: <1107694084.7716.23.camel@baythorne.infradead.org> References: <1107580844.21998.3.camel@jdub.homelinux.org> <1107581406.8961.38.camel@cutter> <1107603269.7716.13.camel@baythorne.infradead.org> <20050205172249.GC1641@jadzia.bu.edu> <1107694084.7716.23.camel@baythorne.infradead.org> Message-ID: <20050206170958.GA19167@jadzia.bu.edu> On Sun, Feb 06, 2005 at 12:48:04PM +0000, David Woodhouse wrote: > > Is that really all that's missing at this point? I should look again, > > then. What about caching? And the mountpoint thing? > As I understand it, all the caching code is there and should be > workable. Write support is completely absent because it was waiting for > the keyrings -- that's what we were _waiting_ for; it's not the only > thing that was missing. Ah, okay. I'll keep holding my breath, then. :) -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From mattdm at mattdm.org Sun Feb 6 17:13:13 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 6 Feb 2005 12:13:13 -0500 Subject: AFS in Extras In-Reply-To: <1107701949.5684.5.camel@jdub.homelinux.org> References: <1107580844.21998.3.camel@jdub.homelinux.org> <20050205171458.GA1641@jadzia.bu.edu> <1107701949.5684.5.camel@jdub.homelinux.org> Message-ID: <20050206171313.GB19167@jadzia.bu.edu> On Sun, Feb 06, 2005 at 08:59:08AM -0600, Josh Boyer wrote: > > Me, maybe? > Yeah! :) It's always nice to hear that people are putting all that work to use. > > And, there's a lot of crazy unstability right now, with surprises with every > > new kernel release. At the very least, I think this should wait for the 1.4 > > OpenAFS release. > Any ideas on when that is? I don't follow OpenAFS mailing lists too > often. I wouldn't be surprised if it's this summer. I also wouldn't be surprised if it's not. > > 2) hope that NFS4 ends up being amazing and perfect, and start migrating > > everything > Sadly migration really isn't an option for me... Yeah, nor for a lot of people. -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From ville.skytta at iki.fi Sun Feb 6 18:01:14 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 06 Feb 2005 20:01:14 +0200 Subject: Orphaned Packages In-Reply-To: <1327.192.168.100.89.1107702321.squirrel@webmail.suretecsystems.com> References: <1327.192.168.100.89.1107702321.squirrel@webmail.suretecsystems.com> Message-ID: <1107712874.30769.389.camel@bobcat.mine.nu> On Sun, 2005-02-06 at 15:05 +0000, Gavin Henry wrote: > http://fedoraproject.org/wiki/Extras/OrphanedPackages > > What does one do to take one over :-) >From that page (I just added the "telling which ..." bit): If you want to step forward and take over maintenance of one or several of these packages, please post to fedora-extras-list telling which packages you'd like to take over, and join open bug reports where attention is needed. From nphilipp at redhat.com Mon Feb 7 11:48:17 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 07 Feb 2005 12:48:17 +0100 Subject: fedora-extras-release In-Reply-To: <420557D0.8070502@insight.rr.com> References: <1107406975.7339.1.camel@cutter> <20050203071322.GC8404@nostromo.devel.redhat.com> <1107415133.7339.25.camel@cutter> <1107458805.5647.78.camel@localhost.localdomain> <20050203204245.1a5e03b6@python2> <1107464852.2013.38.camel@opus.phy.duke.edu> <20050203233111.04bbc0c2@python2> <1107470065.2013.60.camel@opus.phy.duke.edu> <20050203235521.456d30df@python2> <420557D0.8070502@insight.rr.com> Message-ID: <1107776897.4719.2.camel@gibraltar.stuttgart.redhat.com> On Sat, 2005-02-05 at 18:33 -0500, Jim Cornette wrote: > Justin Georgeson wrote: > > >Matthias Saou writes: > > > > > > > >>Too bad though that it seems sysconfig/rhn/ can only take info from the > >>single "sources" file, as from my understanding this means that the current > >>RHN notification tool won't automatically be aware of Extras after this > >>package is installed. > >> > >> > > > >Add a post install script that does > > > >echo "..." >> /etc/sysconfig/rhn/sources > > > >and a post uninstall script that does > > > >grep -v "..." /etc/sysconfig/rhn/sources > /tmp/sources.new > >mv /etc/sysconfig/rhn/sources.rpmsave > >mv /tmp/sources.new /etc/sysconfig/rhn/sources > > > >You could add some 'if [ $? != 0 ]; ...' stuff to rollout the changes if a > >command fails, but it would mean that up2date can use Extras and the rhn_applet > >will se updates. > > > >:) > > > >-- > >fedora-extras-list mailing list > >fedora-extras-list at redhat.com > >https://www.redhat.com/mailman/listinfo/fedora-extras-list > > > > > > > I'd me more in favor of the script checking the > /etc/sysconfig/rhn/sources to see if an entry exists, then appending the > entry into the file if there are no entries for fedora-extras. I use > up2date a lot and use specific mirrors that I would not like to have > bothered. Oh it would be so much better if you could just put some keyword like "yumconf" into sources and up2date would read the repositories from /etc/yum.conf or /etc/yum.repos.d/*.conf. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From giallu at gmail.com Sun Feb 6 22:58:07 2005 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 6 Feb 2005 23:58:07 +0100 Subject: My open tickets in bugzilla.fedora.us In-Reply-To: References: Message-ID: I have a couple of pending package requests in bugzilla.fedora.us: https://bugzilla.fedora.us/show_bug.cgi?id=2329 and https://bugzilla.fedora.us/show_bug.cgi?id=2398 that I would like to help you close. The former (a library for visualization of 3D chemical structures) already had positive reviews, and I also included the suggested enhancements. The latter is just a port to FC3 of an already published (by livna) package: alleyoop, a gnome based frontend for valgrind. Better to submit the same requests to bugzilla.redhat.com so we can close to fedora.us ones? Cheers Gianluca From wtogami at redhat.com Sun Feb 6 23:10:02 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 06 Feb 2005 13:10:02 -1000 Subject: My open tickets in bugzilla.fedora.us In-Reply-To: References: Message-ID: <4206A3CA.2000901@redhat.com> Gianluca Sforna wrote: > I have a couple of pending package requests in bugzilla.fedora.us: > https://bugzilla.fedora.us/show_bug.cgi?id=2329 > and > https://bugzilla.fedora.us/show_bug.cgi?id=2398 > that I would like to help you close. > > The former (a library for visualization of 3D chemical structures) > already had positive reviews, and I also included the suggested > enhancements. > The latter is just a port to FC3 of an already published (by livna) > package: alleyoop, a gnome based frontend for valgrind. > Better to submit the same requests to bugzilla.redhat.com so we can > close to fedora.us ones? No, there is no equivalent process at RH Extras yet, and there is strong resistance against creating one which I believe is a huge mistake. We will probably be arguing over this and other issues during FUDCON. So keep the fedora.us reports open for now. I will be soon posting an interim New Package adding process proposal here. Warren Togami wtogami at redhat.com From jim-cornette at insight.rr.com Sun Feb 6 23:28:02 2005 From: jim-cornette at insight.rr.com (Jim Cornette) Date: Sun, 06 Feb 2005 18:28:02 -0500 Subject: fedora-extras-release In-Reply-To: <1107776897.4719.2.camel@gibraltar.stuttgart.redhat.com> References: <1107406975.7339.1.camel@cutter> <20050203071322.GC8404@nostromo.devel.redhat.com> <1107415133.7339.25.camel@cutter> <1107458805.5647.78.camel@localhost.localdomain> <20050203204245.1a5e03b6@python2> <1107464852.2013.38.camel@opus.phy.duke.edu> <20050203233111.04bbc0c2@python2> <1107470065.2013.60.camel@opus.phy.duke.edu> <20050203235521.456d30df@python2> <420557D0.8070502@insight.rr.com> <1107776897.4719.2.camel@gibraltar.stuttgart.redhat.com> Message-ID: <4206A802.5030508@insight.rr.com> Nils Philippsen wrote: >On Sat, 2005-02-05 at 18:33 -0500, Jim Cornette wrote: > > >>Justin Georgeson wrote: >> >> >> >>>Matthias Saou writes: >>> >>> >>> >>> >>> >>>>Too bad though that it seems sysconfig/rhn/ can only take info from the >>>>single "sources" file, as from my understanding this means that the current >>>>RHN notification tool won't automatically be aware of Extras after this >>>>package is installed. >>>> >>>> >>>> >>>> >>>Add a post install script that does >>> >>>echo "..." >> /etc/sysconfig/rhn/sources >>> >>>and a post uninstall script that does >>> >>>grep -v "..." /etc/sysconfig/rhn/sources > /tmp/sources.new >>>mv /etc/sysconfig/rhn/sources.rpmsave >>>mv /tmp/sources.new /etc/sysconfig/rhn/sources >>> >>>You could add some 'if [ $? != 0 ]; ...' stuff to rollout the changes if a >>>command fails, but it would mean that up2date can use Extras and the rhn_applet >>>will se updates. >>> >>>:) >>> >>>-- >>>fedora-extras-list mailing list >>>fedora-extras-list at redhat.com >>>https://www.redhat.com/mailman/listinfo/fedora-extras-list >>> >>> >>> >>> >>> >>I'd me more in favor of the script checking the >>/etc/sysconfig/rhn/sources to see if an entry exists, then appending the >>entry into the file if there are no entries for fedora-extras. I use >>up2date a lot and use specific mirrors that I would not like to have >>bothered. >> >> > >Oh it would be so much better if you could just put some keyword like >"yumconf" into sources and up2date would read the repositories >from /etc/yum.conf or /etc/yum.repos.d/*.conf. > >Nils > > Diverting up2date over to use a common file for configuring mirrors seems to be a better approach than to worry about the need to configure the listings in both config files. I would prefer this scheme over touching up2date configuration files, appending data, etc to anotger program's config file. Jim From wtogami at redhat.com Mon Feb 7 05:29:36 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 06 Feb 2005 19:29:36 -1000 Subject: My open tickets in bugzilla.fedora.us In-Reply-To: References: Message-ID: <4206FCC0.2080706@redhat.com> I looked into your two packages and the Bugzilla history. Some comments below. Gianluca Sforna wrote: > I have a couple of pending package requests in bugzilla.fedora.us: > https://bugzilla.fedora.us/show_bug.cgi?id=2329 Compton is a long time trusted contributor, so we can fast track this into FC3 Extras now that we are no longer stuck on the valgrind issue. As for maintainership of the package in Extras, being a package owner does NOT automatically give you the right to full CVS access. You would need to convince one of the existing "Trusted" contributors to sponsor your membership and take responsibility if anything goes wrong. (When the account management system is written though, then we can probably give CVS access to many more people with commit access to their own packages only, until they become sponsored.) So anyway, I will personally review this package and import it this week. > and > https://bugzilla.fedora.us/show_bug.cgi?id=2398 IANAL, but the license issues surrounding this software are confusing and possibly problematic. http://www.tecn.upf.es/openMOIV/openmoiv/license.html "Because OpenMOIV is a derived product of Molecular Inventor (you can consider OpenMOIV as a modification of Molecular Inventor), you need to accept two licenses in order to use it: the original license from Silicon Graphics (applicable to the initial source code) and the GNU/LGPL license for our modifications and improvements." "Molecular Inventor License" has language like "non-transferable and non-exclusive" and "Licensee shall not assign or otherwise transfer its rights or obligations under this License Agreement without the prior written consent..." To my non-lawyer eyes, this sounds contradictory to the GPL or LGPL, where it is very important that rights are transferrable. It is one thing to dual-license software, the copyright holder can release software under different licenses, however if OpenMOIV explicitly says that you must accept BOTH licenses, then it sounds horribly problematic. However... http://oss.sgi.com/projects/inventor/license.html http://freshmeat.net/projects/openinventor/ From the looks of it though, here SGI explicitly states "LGPL" as the license for Open Inventor with no mention of the "Molecular Inventor" license. So it may be possible that OpenMOIV is just confused in their licensing statement? In any case we need to clear this up in order to move forward. Please find more information (URL's) about this situation so we can summarize the legal question for submission to Red Hat's legal queue. They will give us a 'yes' or 'no'. Warren Togami wtogami at redhat.com From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 7 10:02:16 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 7 Feb 2005 11:02:16 +0100 Subject: Anjuta x86_64 crashes when creatina a new project. In-Reply-To: <1107704414.5277.19.camel@earlgrey.compton.net> References: <420249B1.8000406@gmail.com> <20050203175632.49ef4f4a.fedora@wir-sind-cool.org> <20050203181708.2e28db6c@python2> <1107704414.5277.19.camel@earlgrey.compton.net> Message-ID: <20050207110216.54de09dc@python2> Phillip Compton wrote : > On Thu, 2005-02-03 at 18:17 +0100, Matthias Saou wrote: > > > BTW, about the anjuta rpm, one thing that needs fixing is adding > > gettext-devel to the requirements. I just got this report from a user : > > > Requires: gettext-devel for your package so that the behavior is as > > expected? Thanks Matthias, I enjoy mirroring your site for use by workers > > here in our office. > > > > -- > > > > If pcompton is lurking, I hope he'll pick it up, otherwise, the next person > > to open a bug report could include it as a bonus ;-) > > *de-lurks for a second* > > I'll be sure to include that once cvs is back, unless you'd rather be > the Extras maintainer, Matthias. You've been packaging Anjuta for quite > some time, and I'll happily step aside if you'd like to continue with > it. Well, I don't use anjuta on a regular basis, although I get realtime feedback by some colleagues who do ;-) so it would be best to have it maintained by someone who knows it really well. Now, about that change... see what Michael wrote. I'm not so sure now... but for me, anjuta is clearly primarily an IDE for C/C++, thus requiring autotools, gettext-devel and such to have it full-featured for this purpose seems sensible to me, even if these could be considered "optional". But of course, this is only my own opinion ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.19 0.29 0.48 From fedora at wir-sind-cool.org Mon Feb 7 10:14:22 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 7 Feb 2005 11:14:22 +0100 Subject: My open tickets in bugzilla.fedora.us In-Reply-To: <4206FCC0.2080706@redhat.com> References: <4206FCC0.2080706@redhat.com> Message-ID: <20050207111422.2a31e154.fedora@wir-sind-cool.org> On Sun, 06 Feb 2005 19:29:36 -1000, Warren Togami wrote: > I looked into your two packages and the Bugzilla history. Some comments > below. > > Gianluca Sforna wrote: > > I have a couple of pending package requests in bugzilla.fedora.us: > > https://bugzilla.fedora.us/show_bug.cgi?id=2329 > > IANAL, but the license issues surrounding this software are confusing > and possibly problematic. > > http://www.tecn.upf.es/openMOIV/openmoiv/license.html > "Because OpenMOIV is a derived product of Molecular Inventor (you can > consider OpenMOIV as a modification of Molecular Inventor), you need to > accept two licenses in order to use it: the original license from > Silicon Graphics (applicable to the initial source code) and the > GNU/LGPL license for our modifications and improvements." > > "Molecular Inventor License" has language like "non-transferable and > non-exclusive" and "Licensee shall not assign or otherwise transfer its > rights or obligations under this License Agreement without the prior > written consent..." To my non-lawyer eyes, this sounds contradictory to > the GPL or LGPL, where it is very important that rights are transferrable. > > It is one thing to dual-license software, the copyright holder can > release software under different licenses, however if OpenMOIV > explicitly says that you must accept BOTH licenses, then it sounds > horribly problematic. However... > > http://oss.sgi.com/projects/inventor/license.html > http://freshmeat.net/projects/openinventor/ > > From the looks of it though, here SGI explicitly states "LGPL" as the > license for Open Inventor with no mention of the "Molecular Inventor" > license. So it may be possible that OpenMOIV is just confused in their > licensing statement? > > In any case we need to clear this up in order to move forward. Please > find more information (URL's) about this situation so we can summarize > the legal question for submission to Red Hat's legal queue. They will > give us a 'yes' or 'no'. The Molecular Inventor pages and licence are here: http://www.sgi.com/products/evaluation/molecular_inventor/ http://www.sgi.com/industries/sciences/chembio/resources/molinv/molinv.html Here SGI links OpenMOIV, which means they are aware of it. However, the source files itself contain the LGPL header and the clause that "all other liences must be accepted". So, maybe there's an IANAL type of misunderstanding in the chosen licencing scheme by either SGI or the OpenMOIV authors. Whether they are permitted to apply the LGPL to their derived library or whether their licencing specific page http://www.tecn.upf.es/openMOIV/openmoiv/license.html really tries to restrict the LGPL is not clear. As I understand it, only to get SGI's original Molecular Inventor source you need to accept SGI's licence. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 7 10:15:24 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 7 Feb 2005 11:15:24 +0100 Subject: Bugzilla usage (was: Re: kmymoney2) In-Reply-To: <1107606202.30769.183.camel@bobcat.mine.nu> References: <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <20050131222016.GA9816@thacker.dyndns.org> <1107505209l.7472l.3l@devel.mpeters.us> <4203907A.1040505@math.unl.edu> <1107530306.31004.5.camel@opus.phy.duke.edu> <20050204165120.22c14585@python2> <1107533474.31004.17.camel@opus.phy.duke.edu> <1107606202.30769.183.camel@bobcat.mine.nu> Message-ID: <20050207111524.5bc926c6@python2> Ville Skytt? wrote : [...] > > However, I do think that if you want something > > tracked over the long term it needs to be in bugzilla. > > Right. This pretty much sums up the discussion about what to use bugzilla for. As for me, initial packaging discussions, before anything is released, aren't really suited for bugzilla entries. Sure, they'll stay there for the long term, but for what purpose? If it's about tricks, patches etc. to get the package right, then that just needs to be put as comments in the spec file. Also, these kind of packaging problems, if reported upstream, are often fixed in later versions of the software... so things discussed become irrelevant, thus there isn't much point in keeping those discussions preciously. Regarding the software that will never be able to make it into Fedora, may it be Core, Extras or any other part, I also agree that we need a list somewhere for reference and where to direct recurrent requests. I guess a Wiki page would be enough, with a list of obvious reasons "Copyrighted material", "Patented code in the USA", "Non-free license" etc. and lists of precise software concerned. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.10 0.14 0.36 From wtogami at redhat.com Mon Feb 7 10:18:53 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 07 Feb 2005 00:18:53 -1000 Subject: My open tickets in bugzilla.fedora.us In-Reply-To: <20050207111422.2a31e154.fedora@wir-sind-cool.org> References: <4206FCC0.2080706@redhat.com> <20050207111422.2a31e154.fedora@wir-sind-cool.org> Message-ID: <4207408D.9060408@redhat.com> Michael Schwendt wrote: > > The Molecular Inventor pages and licence are here: > > http://www.sgi.com/products/evaluation/molecular_inventor/ > http://www.sgi.com/industries/sciences/chembio/resources/molinv/molinv.html > > Here SGI links OpenMOIV, which means they are aware of it. However, the > source files itself contain the LGPL header and the clause that "all other > liences must be accepted". So, maybe there's an IANAL type of > misunderstanding in the chosen licencing scheme by either SGI or the > OpenMOIV authors. Whether they are permitted to apply the LGPL to their > derived library or whether their licencing specific page > http://www.tecn.upf.es/openMOIV/openmoiv/license.html really tries to > restrict the LGPL is not clear. As I understand it, only to get SGI's > original Molecular Inventor source you need to accept SGI's licence. > This is far too much uncertainty for us to just ignore. Please prepare an organized summary for submission to the legal queue, so they can quickly understand the situation. If you care about OpenMOIV going into Extras, you should really talk to upstream OpenMOIV about it too. The suspect only the acceptable situation here is for OpenMOIV to be totally and without a doubt LGPL. But we will see. Warren Togami wtogami at redhat.com From wtogami at redhat.com Mon Feb 7 10:21:59 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 07 Feb 2005 00:21:59 -1000 Subject: Interim New Package Process Message-ID: <42074147.7060302@redhat.com> (Until we can agree on a better process with better tools, I propose this simple process to operate Extras at least during the next 2 weeks. I really think this process is horrible, but we need SOMETHING to work from rather than unwritten rules for the short-term. We will be arguing about details for the final process between now and FUDCON.) Contibutor Levels (jargon needed to understand the process below) ================= (Highest) "Trusted" or RH FC Engineer These people can sponsor "Contributor" membership, where they take responsibility for the new member to have full CVS access. These members can veto (or stall) "Contributor" nominations or new package additions and force a discussion, vote, or something. (Currently everyone with CVS access is also "Trusted", but that may quickly change as we accept many more members in the coming weeks.) (Middle) "Contributor" These members can sponsor new package additions and act as intermediaries for those who do not yet have CVS access. Contributors have full CVS access but are expected to respect package ownership. These members can veto (or stall) new package additions if there is good technical reason. (Lowest) "Packager" These members own packages in Extras but are not sponsored. They can get CVS access to their own packages. Their goal is to show competency and hard work in order earn trust so someone will sponsor them. (We may not be able to create Packager status accounts until the database driven account management system goes into production.) Interim Extras Package Process ------------------------------ I. NEW PACKAGES --------------- You can add a new package if it meets these requirements: * Another Extras Contributor or RH engineer (but not yourself) to sponsor your package. * No known legal/licensing problems. * Nobody vetos it. II. IMPORT TO CVS ================== Use cvs-import.sh from the common module. If you do not have CVS access, then convince a package sponsor to checkin for you. That package sponsor is probably the same person who does the package review. III. PACKAGE REVIEW ==================== Package should comply with most of the packaging best practices (yet to be rewritten) so it is of reasonably good quality. This is FAR LESS than strict QA requirements of fedora.us. Judgement of the reviewer of "good enough". Package quality can be fixed AFTER import but before build. In most cases it would be safe to push a less than certain package, and use resulting testing to fix it quickly and push again. However if it would endanger existing users, or other packages, then don't do this. Again up to the judgement of the reviewer. IV. ANNOUNCE ------------- After a package has been reviewed, post to fedora-extras-commits at redhat.com with Subject "APPROVED: packagefoo, packagebar, packagebaz..." Body should contain package names, short descriptions, who reviewed, and who will maintain those packages. (This is so we can easily search where a package came from, and who reviewed it.) V. CREATE BUGZILLA COMPONENT ============================= http://fedoraproject.org/wiki/Extras_2fFC3Status Edit this page and add a request for a new Bugzilla component. Include 1) Package name 2) Description (from Summary field) 3) Bugzilla account e-mail address of package owner For example: foommoorpg:Totally Awesome and Free 3D Online RPG Game:bob at somewhere.net foommoorpg-data:9GB of Data for Foo MMORPG:bob at somewhere.net footrainer:Cheating Program for Foo MMORPG:bob at somewhere.net VI. REQUEST BUILD ================= http://fedoraproject.org/wiki/Extras_2fFC3Status Edit this page and add your package to the "build needed" section. For example: * foommoorpg (i386, x86_64) * foommoorpg-data (noarch) * footrainer (i386, x86_64) * fooutil (i386 only) VII. UPDATES ========== Just do it, or funnel it through the package sponsor if you don't have CVS access yet. Warren Togami wtogami at redhat.com From giallu at gmail.com Mon Feb 7 10:40:58 2005 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 7 Feb 2005 11:40:58 +0100 Subject: My open tickets in bugzilla.fedora.us In-Reply-To: <4207408D.9060408@redhat.com> References: <4206FCC0.2080706@redhat.com> <20050207111422.2a31e154.fedora@wir-sind-cool.org> <4207408D.9060408@redhat.com> Message-ID: On Mon, 07 Feb 2005 00:18:53 -1000, Warren Togami wrote: > This is far too much uncertainty for us to just ignore. Please prepare > an organized summary for submission to the legal queue, so they can > quickly understand the situation. If you care about OpenMOIV going into > Extras, you should really talk to upstream OpenMOIV about it too. OK, since I am in contact with the authors, I will try to ask them if is possible to clarify the licensing. I am > > The suspect only the acceptable situation here is for OpenMOIV to be > totally and without a doubt LGPL. But we will see. This would still not solve the issue with linking it with GPL libs like Coin2 and SoQt. I will ask if they can also help us on this topic. Thanks for your help Gianluca From fedora at wir-sind-cool.org Mon Feb 7 11:07:24 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 7 Feb 2005 12:07:24 +0100 Subject: My open tickets in bugzilla.fedora.us In-Reply-To: <4207408D.9060408@redhat.com> References: <4206FCC0.2080706@redhat.com> <20050207111422.2a31e154.fedora@wir-sind-cool.org> <4207408D.9060408@redhat.com> Message-ID: <20050207120724.57eaba41.fedora@wir-sind-cool.org> On Mon, 07 Feb 2005 00:18:53 -1000, Warren Togami wrote: > > The Molecular Inventor pages and licence are here: > > > > http://www.sgi.com/products/evaluation/molecular_inventor/ > > http://www.sgi.com/industries/sciences/chembio/resources/molinv/molinv.html > > > > Here SGI links OpenMOIV, which means they are aware of it. However, the > > source files itself contain the LGPL header and the clause that "all other > > liences must be accepted". So, maybe there's an IANAL type of > > misunderstanding in the chosen licencing scheme by either SGI or the > > OpenMOIV authors. Whether they are permitted to apply the LGPL to their > > derived library or whether their licencing specific page > > http://www.tecn.upf.es/openMOIV/openmoiv/license.html really tries to > > restrict the LGPL is not clear. As I understand it, only to get SGI's > > original Molecular Inventor source you need to accept SGI's licence. > > > > This is far too much uncertainty for us to just ignore. Please prepare > an organized summary for submission to the legal queue, so they can > quickly understand the situation. If you care about OpenMOIV going into > Extras, you should really talk to upstream OpenMOIV about it too. > > The suspect only the acceptable situation here is for OpenMOIV to be > totally and without a doubt LGPL. But we will see. Shame upon me. Admittedly, I took it too light. I will be interested in learning how they worked out their licencing with SGI. From fedora at wir-sind-cool.org Mon Feb 7 11:15:32 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 7 Feb 2005 12:15:32 +0100 Subject: Interim New Package Process In-Reply-To: <42074147.7060302@redhat.com> References: <42074147.7060302@redhat.com> Message-ID: <20050207121532.0a6fd299.fedora@wir-sind-cool.org> On Mon, 07 Feb 2005 00:21:59 -1000, Warren Togami wrote: > V. CREATE BUGZILLA COMPONENT > ============================= > http://fedoraproject.org/wiki/Extras_2fFC3Status > Edit this page and add a request for a new Bugzilla component. Include > 1) Package name > 2) Description (from Summary field) > 3) Bugzilla account e-mail address of package owner > > For example: > foommoorpg:Totally Awesome and Free 3D Online RPG Game:bob at somewhere.net > foommoorpg-data:9GB of Data for Foo MMORPG:bob at somewhere.net > footrainer:Cheating Program for Foo MMORPG:bob at somewhere.net Unfortunately, with the Wiki there must be a space character before and after the colon to allow for cut'n'paste. We could work around this by using a separate wiki page, which starts with #FORMAT plain and would disable wiki markup processing. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 7 12:19:17 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 7 Feb 2005 13:19:17 +0100 Subject: New candidates for inclusion in Extras : udftools and starfighter-music Message-ID: <20050207131917.44e53bb8@python2> Hi, Here are packages I'd like to add to Extras : - udftools : As UDF packet writing support is now in the latest FC kernels, these tools are useful "out of the box" on FC without any kernel patching or recompiling, thus should be easily accessible to all users. - starfighter-music : My current starfighter package doesn't bundle the musics, as they are in a separate zip file and aren't necessarily updated at the same time as the main game (i.e. game is at 1.1 and music 1.0 currenty). One question about this is whether to make the main package require the music one for everyone to get the complete gaming experience (I'd favour this) or to let people optionally install the musics themselves. If I understood Warren's last process proposal : - I need someone (besides myself) to sponsor my package (?). - There needs to be no legal/licensing problems (*). - Nobody must oppose a veto. They should all comply with "best practices", and I'll announce to the commits list if/once approved. (*) : The starfighter-music zip doesn't contain any license information. But I assume that it is covered by the same one as the main program (GNU GPL) since it seems to be split apart only for practical reasons. Should I add a copy of the GNU GPL to the package nevertheless? Is having it depend on the main package which contains the license details enough? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.22 0.27 0.54 From vincenzo_yahoo_addressguard-gmane at yahoo.it Mon Feb 7 11:48:52 2005 From: vincenzo_yahoo_addressguard-gmane at yahoo.it (Vincenzo Ciancia) Date: Mon, 07 Feb 2005 12:48:52 +0100 Subject: FUSE - filesystem in userspace Message-ID: Hi all, I've been sent here from the fedora-general mailing list. I just would like to ask people who can to consider fuse (filesystem in userspace) and sshfs for inclusion into fedora. They both are available at http://fuse.sourceforge.net The latter is a particularly comfortable way to access files on any sshd-enabled machine (i.e. any linux machine nowadays) as if they where local, without superuser intervention, without other support on the server and with a simple and "just works" feeling (you only have to type "sshfs user at host:remotedir localdir"). Fuse is used in a wide range of projects, some is listed at: http://fuse.sourceforge.net/filesystems.html Including this in fedora would give huge visibility to it, which is needed for people to easily distribute userspace filesystems they create - btw debian and gentoo already include it so that addition to fedora would make it almost a de-facto standard, and a safe bet for filesystems coders to just list "install fuse from your vendor" as a prerequisite. Bye Vincenzo -- Please note that I do not read the e-mail address used in the from field but I read vincenzo_ml at yahoo dot it Attenzione: non leggo l'indirizzo di posta usato nel campo from, ma leggo vincenzo_ml at yahoo dot it From gene at czarc.net Mon Feb 7 13:17:58 2005 From: gene at czarc.net (Gene Czarcinski) Date: Mon, 7 Feb 2005 08:17:58 -0500 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <20050207131917.44e53bb8@python2> References: <20050207131917.44e53bb8@python2> Message-ID: <200502070817.58736.gene@czarc.net> On Monday 07 February 2005 07:19, Matthias Saou wrote: > Here are packages I'd like to add to Extras : > > - udftools : As UDF packet writing support is now in the latest FC kernels, > these tools are useful "out of the box" on FC without any kernel patching > or recompiling, thus should be easily accessible to all users. Second From fedora at wir-sind-cool.org Mon Feb 7 12:54:20 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 7 Feb 2005 13:54:20 +0100 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <20050207131917.44e53bb8@python2> References: <20050207131917.44e53bb8@python2> Message-ID: <20050207135420.773a2b08.fedora@wir-sind-cool.org> On Mon, 7 Feb 2005 13:19:17 +0100, Matthias Saou wrote: > Here are packages I'd like to add to Extras : > - starfighter-music : My current starfighter package doesn't bundle the > musics, as they are in a separate zip file and aren't necessarily updated > at the same time as the main game (i.e. game is at 1.1 and music 1.0 > currenty). One question about this is whether to make the main package > require the music one for everyone to get the complete gaming experience > (I'd favour this) or to let people optionally install the musics > themselves. > > If I understood Warren's last process proposal : > - I need someone (besides myself) to sponsor my package (?). > - There needs to be no legal/licensing problems (*). > - Nobody must oppose a veto. > > They should all comply with "best practices", and I'll announce to the > commits list if/once approved. > > (*) : The starfighter-music zip doesn't contain any license information. > But I assume that it is covered by the same one as the main program (GNU > GPL) since it seems to be split apart only for practical reasons. Should I > add a copy of the GNU GPL to the package nevertheless? Is having it depend > on the main package which contains the license details enough? One thing for sure, the music zip package is not GPL'ed, because the composers did not release their music as GPL. Included in the zip are 13 MOD files (Protracker or equivalent) and 1 S3M file (Scream Tracker). The credits within the files indicate that they were not made specifically for Starfighter, but were taken from the public domain and made in 1993 to 1996. Usually, MOD files which were not published by their composers directly, were ripped from PC/Amiga demos or music demo shows and then released in the public domain without prior written consent by their authors. If not ripped from commercial games, the composer usually have nothing against their music being used in other "free" (here as in free beer) software. This package is at most "License: Public Domain", but not GPL. From dwmw2 at infradead.org Mon Feb 7 14:18:17 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 07 Feb 2005 14:18:17 +0000 Subject: qemu. Message-ID: <1107785897.19262.411.camel@hades.cambridge.redhat.com> I'd like to add qemu to Extras. Anyone want to second it? ftp://ftp.uk.linux.org/pub/people/dwmw2/fc2-mac/SRPMS/qemu-0.6.1-1.src.rpm -- dwmw2 From mattdm at mattdm.org Mon Feb 7 14:20:22 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 7 Feb 2005 09:20:22 -0500 Subject: qemu. In-Reply-To: <1107785897.19262.411.camel@hades.cambridge.redhat.com> References: <1107785897.19262.411.camel@hades.cambridge.redhat.com> Message-ID: <20050207142022.GA23386@jadzia.bu.edu> On Mon, Feb 07, 2005 at 02:18:17PM +0000, David Woodhouse wrote: > I'd like to add qemu to Extras. Anyone want to second it? > ftp://ftp.uk.linux.org/pub/people/dwmw2/fc2-mac/SRPMS/qemu-0.6.1-1.src.rpm It's been on my list of Things I Want To Check Out..... -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From fedora at wir-sind-cool.org Mon Feb 7 14:28:00 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 7 Feb 2005 15:28:00 +0100 Subject: qemu. In-Reply-To: <1107785897.19262.411.camel@hades.cambridge.redhat.com> References: <1107785897.19262.411.camel@hades.cambridge.redhat.com> Message-ID: <20050207152800.727a6250.fedora@wir-sind-cool.org> On Mon, 07 Feb 2005 14:18:17 +0000, David Woodhouse wrote: > I'd like to add qemu to Extras. Anyone want to second it? > > ftp://ftp.uk.linux.org/pub/people/dwmw2/fc2-mac/SRPMS/qemu-0.6.1-1.src.rpm I would assume that Enrico Scholz would, because: https://bugzilla.fedora.us/show_bug.cgi?id=623 From toshio at tiki-lounge.com Mon Feb 7 15:05:02 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 7 Feb 2005 07:05:02 -0800 Subject: Bugzilla usage (was: Re: kmymoney2) In-Reply-To: <20050207111524.5bc926c6@python2>; from thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net on Mon, Feb 07, 2005 at 11:15:24AM +0100 References: <20050131222016.GA9816@thacker.dyndns.org> <1107505209l.7472l.3l@devel.mpeters.us> <4203907A.1040505@math.unl.edu> <1107530306.31004.5.camel@opus.phy.duke.edu> <20050204165120.22c14585@python2> <1107533474.31004.17.camel@opus.phy.duke.edu> <1107606202.30769.183.camel@bobcat.mine.nu> <20050207111524.5bc926c6@python2> Message-ID: <20050207070502.A13505@tiki-lounge.com> On Mon, Feb 07, 2005 at 11:15:24AM +0100, Matthias Saou wrote: > Regarding the software that will never be able to make it into Fedora, may > it be Core, Extras or any other part, I also agree that we need a list > somewhere for reference and where to direct recurrent requests. I guess a > Wiki page would be enough, with a list of obvious reasons "Copyrighted > material", "Patented code in the USA", "Non-free license" etc. and lists of > precise software concerned. > It would be good if the reason was verbose enough that license changes/patent expiry/etc could quickly be compared to the former legal reasons for excluding the software to see if anything's really changed or what specific license requirements are problematic. A list that would have been helpful to explain the MySQL 4 problems to people at various stages, for instance. -Toshio From skvidal at phy.duke.edu Mon Feb 7 15:21:12 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 07 Feb 2005 10:21:12 -0500 Subject: Interim New Package Process In-Reply-To: <42074147.7060302@redhat.com> References: <42074147.7060302@redhat.com> Message-ID: <1107789672.30385.11.camel@opus.phy.duke.edu> > IV. ANNOUNCE > ------------- > After a package has been reviewed, post to > fedora-extras-commits at redhat.com with > Subject "APPROVED: packagefoo, packagebar, packagebaz..." > Body should contain package names, short descriptions, who reviewed, and > who will maintain those packages. > since fedora-extras-commits doesn't have any archives wouldn't it make more sense to post this to fedora-extras-list? Then people can scan archives for approved pkgs. -sv From skvidal at phy.duke.edu Mon Feb 7 15:31:44 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 07 Feb 2005 10:31:44 -0500 Subject: Interim New Package Process In-Reply-To: <20050207121532.0a6fd299.fedora@wir-sind-cool.org> References: <42074147.7060302@redhat.com> <20050207121532.0a6fd299.fedora@wir-sind-cool.org> Message-ID: <1107790304.30385.14.camel@opus.phy.duke.edu> On Mon, 2005-02-07 at 12:15 +0100, Michael Schwendt wrote: > On Mon, 07 Feb 2005 00:21:59 -1000, Warren Togami wrote: > > > V. CREATE BUGZILLA COMPONENT > > ============================= > > http://fedoraproject.org/wiki/Extras_2fFC3Status > > Edit this page and add a request for a new Bugzilla component. Include > > 1) Package name > > 2) Description (from Summary field) > > 3) Bugzilla account e-mail address of package owner > > > > For example: > > foommoorpg:Totally Awesome and Free 3D Online RPG Game:bob at somewhere.net > > foommoorpg-data:9GB of Data for Foo MMORPG:bob at somewhere.net > > footrainer:Cheating Program for Foo MMORPG:bob at somewhere.net > > Unfortunately, with the Wiki there must be a space character before and > after the colon to allow for cut'n'paste. We could work around this by > using a separate wiki page, which starts with > > #FORMAT plain > > and would disable wiki markup processing. or just enclose the area you want in {{{ }}} That is the equivalent of a
and not having a space doesn't hurt cut-n-paste - it just means you can't double-click select. -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 7 15:53:23 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 7 Feb 2005 16:53:23 +0100 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <20050207135420.773a2b08.fedora@wir-sind-cool.org> References: <20050207131917.44e53bb8@python2> <20050207135420.773a2b08.fedora@wir-sind-cool.org> Message-ID: <20050207165323.6cc06bb9@python2> Michael Schwendt wrote : > One thing for sure, the music zip package is not GPL'ed, because the > composers did not release their music as GPL. Included in the zip are 13 > MOD files (Protracker or equivalent) and 1 S3M file (Scream Tracker). The > credits within the files indicate that they were not made specifically for > Starfighter, but were taken from the public domain and made in 1993 to > 1996. Usually, MOD files which were not published by their composers > directly, were ripped from PC/Amiga demos or music demo shows and then > released in the public domain without prior written consent by their > authors. If not ripped from commercial games, the composer usually have > nothing against their music being used in other "free" (here as in free > beer) software. > > This package is at most "License: Public Domain", but not GPL. Thanks for these infos. The lack of information on starfighter's web page, and the fact that I didn't know that MOD files could contain that kind of information made me do wrong assumptions :-) So... "License: Public Domain" in Extras, or kept out because of the blurry status of those files? I'd vote for "in"... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.24 0.20 0.17 From skvidal at phy.duke.edu Mon Feb 7 15:55:13 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 07 Feb 2005 10:55:13 -0500 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <20050207165323.6cc06bb9@python2> References: <20050207131917.44e53bb8@python2> <20050207135420.773a2b08.fedora@wir-sind-cool.org> <20050207165323.6cc06bb9@python2> Message-ID: <1107791713.30385.24.camel@opus.phy.duke.edu> On Mon, 2005-02-07 at 16:53 +0100, Matthias Saou wrote: > Michael Schwendt wrote : > > > One thing for sure, the music zip package is not GPL'ed, because the > > composers did not release their music as GPL. Included in the zip are 13 > > MOD files (Protracker or equivalent) and 1 S3M file (Scream Tracker). The > > credits within the files indicate that they were not made specifically > for > > Starfighter, but were taken from the public domain and made in 1993 to > > 1996. Usually, MOD files which were not published by their composers > > directly, were ripped from PC/Amiga demos or music demo shows and then > > released in the public domain without prior written consent by their > > authors. If not ripped from commercial games, the composer usually have > > nothing against their music being used in other "free" (here as in free > > beer) software. > > > > This package is at most "License: Public Domain", but not GPL. > > Thanks for these infos. The lack of information on starfighter's web page, > and the fact that I didn't know that MOD files could contain that kind of > information made me do wrong assumptions :-) > So... "License: Public Domain" in Extras, or kept out because of the blurry > status of those files? I'd vote for "in"... > Public Domain, should be legit for redistribution. But bug the starfighter author. See what s/he thinks. -sv From dawson at fnal.gov Mon Feb 7 15:55:05 2005 From: dawson at fnal.gov (Troy Dawson) Date: Mon, 07 Feb 2005 09:55:05 -0600 Subject: kernel module rpm naming convention Message-ID: <42078F59.3060609@fnal.gov> Hello, The AFS discussion brought up something that I've been trying to find out. Unfortunatly nobody followed up on the comment from Warren. For our RHEL 3 based distribution we have been following the kernel-module naming convention found at http://www.fedora.us/wiki/PackagingKernelModules We have even modified yum 2.0.x (currently 2.0.7) to work with this naming convention. Basically the question is, will Fedora extra's follow that naming convention or is there something better? If that is the naming convention that is needed, and yum 2.1.x (and 2.2.x) doesn't handle it yet, we'll be willing to try to help with getting it working in the newer yum's. But if there is something that the community has deamed better, then can I be pointed at it and hopefully I can be of some help. Thanks Troy Dawson -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From cra at WPI.EDU Mon Feb 7 17:17:04 2005 From: cra at WPI.EDU (Charles R. Anderson) Date: Mon, 7 Feb 2005 12:17:04 -0500 Subject: kernel module rpm naming convention In-Reply-To: <42078F59.3060609@fnal.gov> References: <42078F59.3060609@fnal.gov> Message-ID: <20050207171704.GL11938@angus.ind.WPI.EDU> On Mon, Feb 07, 2005 at 09:55:05AM -0600, Troy Dawson wrote: > http://www.fedora.us/wiki/PackagingKernelModules > > We have even modified yum 2.0.x (currently 2.0.7) to work with this > naming convention. Why did yum need to be modified? From wtogami at redhat.com Mon Feb 7 18:41:56 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 07 Feb 2005 08:41:56 -1000 Subject: My open tickets in bugzilla.fedora.us In-Reply-To: References: <4206FCC0.2080706@redhat.com> <20050207111422.2a31e154.fedora@wir-sind-cool.org> <4207408D.9060408@redhat.com> Message-ID: <4207B674.90405@redhat.com> Gianluca Sforna wrote: > > This would still not solve the issue with linking it with GPL libs > like Coin2 and SoQt. I will ask if they can also help us on this > topic. > Yikes, is this even a fixable situation? AFAIK GPL and LGPL cannot link no? Warren From wtogami at redhat.com Mon Feb 7 18:43:29 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 07 Feb 2005 08:43:29 -1000 Subject: Interim New Package Process In-Reply-To: <1107789672.30385.11.camel@opus.phy.duke.edu> References: <42074147.7060302@redhat.com> <1107789672.30385.11.camel@opus.phy.duke.edu> Message-ID: <4207B6D1.9030903@redhat.com> seth vidal wrote: >>IV. ANNOUNCE >>------------- >>After a package has been reviewed, post to >>fedora-extras-commits at redhat.com with >>Subject "APPROVED: packagefoo, packagebar, packagebaz..." >>Body should contain package names, short descriptions, who reviewed, and >>who will maintain those packages. >> > > > since fedora-extras-commits doesn't have any archives wouldn't it make > more sense to post this to fedora-extras-list? Then people can scan > archives for approved pkgs. > Huh? fedora-extras-commits DOES have archives. Warren From skvidal at phy.duke.edu Mon Feb 7 18:48:07 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 07 Feb 2005 13:48:07 -0500 Subject: Interim New Package Process In-Reply-To: <4207B6D1.9030903@redhat.com> References: <42074147.7060302@redhat.com> <1107789672.30385.11.camel@opus.phy.duke.edu> <4207B6D1.9030903@redhat.com> Message-ID: <1107802087.12613.0.camel@cutter> > > > > > > since fedora-extras-commits doesn't have any archives wouldn't it make > > more sense to post this to fedora-extras-list? Then people can scan > > archives for approved pkgs. > > > > Huh? fedora-extras-commits DOES have archives. Sorry, Got it confused with fedora-cvs-commits which has no contents in the archives. no problem on messages to fedora-extras-commits -sv From wtogami at redhat.com Mon Feb 7 18:45:21 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 07 Feb 2005 08:45:21 -1000 Subject: FUSE - filesystem in userspace In-Reply-To: References: Message-ID: <4207B741.8010804@redhat.com> Vincenzo Ciancia wrote: > Hi all, I've been sent here from the fedora-general mailing list. I just > would like to ask people who can to consider fuse (filesystem in userspace) > and sshfs for inclusion into fedora. They both are available at > > http://fuse.sourceforge.net My understanding of this is that this would require patching the FC kernel, which is something Extras cannot do. Is this incorrect? If that is the case, then you must convince upstream kernel.org to merge FUSE into the standard kernel. Then adding userspace packages like sshfs would be fairly easy to do. Warren Togami wtogami at redhat.com From enrico.scholz at informatik.tu-chemnitz.de Mon Feb 7 18:47:23 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 07 Feb 2005 19:47:23 +0100 Subject: Updating clamav In-Reply-To: <80d7e409050204161477f99698@mail.gmail.com> (Stephen J. Smoogen's message of "Fri, 4 Feb 2005 17:14:44 -0700") References: <80d7e409050204152243df53df@mail.gmail.com> <87oeezanro.fsf@kosh.ultra.csn.tu-chemnitz.de> <80d7e40905020416027b3a9c66@mail.gmail.com> <80d7e409050204161477f99698@mail.gmail.com> Message-ID: <87u0oocimc.fsf@kosh.ultra.csn.tu-chemnitz.de> smooge at gmail.com ("Stephen J. Smoogen") writes: >> > >> > > Extra currently has 0.71 clamav, and the stable clamav is 0.81 with >> > > security fixes. With that in mind.. what can I do to get an updated >> > > spec file/srpm/ for the build system? >> > >> > I really don't know if I shall give it free for publishing. There are >> > lots of non-trivial changes between 0.71 and 0.81 which should pass QA >> > first. But as you said... 0.71 has security issues and does not accept >> > new databases. >> > > > Quick QA remarks: > > 1) .fdr. is no longer wanted in SPEC files. ignore this; the package is for fedora.us. The CVS version should not have this tag. > 2) zlib update for fedora core 2 has been released. Comment about > --disable-zlib can be removed from several areas it is posted. This is required for FC3 as it ships zlib-2.2.1. But the check requires >=2.2.2 or <2. Enrico From fedora at wir-sind-cool.org Mon Feb 7 18:55:54 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 7 Feb 2005 19:55:54 +0100 Subject: My open tickets in bugzilla.fedora.us In-Reply-To: <4207B674.90405@redhat.com> References: <4206FCC0.2080706@redhat.com> <20050207111422.2a31e154.fedora@wir-sind-cool.org> <4207408D.9060408@redhat.com> <4207B674.90405@redhat.com> Message-ID: <20050207195554.01f29eaf.fedora@wir-sind-cool.org> On Mon, 07 Feb 2005 08:41:56 -1000, Warren Togami wrote: > Gianluca Sforna wrote: > > > > This would still not solve the issue with linking it with GPL libs > > like Coin2 and SoQt. I will ask if they can also help us on this > > topic. > > > > Yikes, is this even a fixable situation? AFAIK GPL and LGPL cannot link no? Well, it's not done, so no need to fix anything. It just was mentioned as an alternative to linking and Open Inventor (LGPL), and there the fun would start (several permutations of library combinations are possible). From tcallawa at redhat.com Mon Feb 7 18:54:49 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 07 Feb 2005 12:54:49 -0600 Subject: FUSE - filesystem in userspace In-Reply-To: References: Message-ID: <1107802490.3664.28.camel@localhost.localdomain> On Mon, 2005-02-07 at 12:48 +0100, Vincenzo Ciancia wrote: > Hi all, I've been sent here from the fedora-general mailing list. I just > would like to ask people who can to consider fuse (filesystem in userspace) > and sshfs for inclusion into fedora. Just to make sure I'm reading this right, are you offering to maintain these packages in fedora-extras, or simply looking for them to be included and maintained by someone? :) ~spot --- Tom "spot" Callaway LCA, RHCE Red Hat Sales Engineer || Aurora Linux Project Leader "If you are going through hell, keep going." -- Sir Winston Churchill From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 7 19:01:50 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 7 Feb 2005 20:01:50 +0100 Subject: FUSE - filesystem in userspace In-Reply-To: <4207B741.8010804@redhat.com> References: <4207B741.8010804@redhat.com> Message-ID: <20050207200150.0fe31d53@python2> Warren Togami wrote : > Vincenzo Ciancia wrote: > > Hi all, I've been sent here from the fedora-general mailing list. I just > > would like to ask people who can to consider fuse (filesystem in userspace) > > and sshfs for inclusion into fedora. They both are available at > > > > http://fuse.sourceforge.net > > My understanding of this is that this would require patching the FC > kernel, which is something Extras cannot do. Is this incorrect? > > If that is the case, then you must convince upstream kernel.org to merge > FUSE into the standard kernel. Then adding userspace packages like > sshfs would be fairly easy to do. The 3rd line of the website reads : "Simple installation (no need to patch or recompile the kernel)" It does require a kernel module, though, so it's a similar situation to AFS and many others... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.04 0.35 0.32 From ville.skytta at iki.fi Mon Feb 7 19:07:58 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 07 Feb 2005 21:07:58 +0200 Subject: kernel module rpm naming convention In-Reply-To: <42078F59.3060609@fnal.gov> References: <42078F59.3060609@fnal.gov> Message-ID: <1107803278.30769.656.camel@bobcat.mine.nu> On Mon, 2005-02-07 at 09:55 -0600, Troy Dawson wrote: > Basically the question is, will Fedora extra's follow that naming > convention or is there something better? The whole kernel module packaging situation, not only the naming part, is still somewhat unclear, but it is being actively worked on. If I were you, I would not take anything from the past granted, and possibly waste time on patching depsolvers, but hold the module packages for a while until "official" documented instructions how to do that stuff are released. That's what I do wrt. my kernel module packages anyway, FWIW. From fedora at leemhuis.info Mon Feb 7 19:15:53 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 07 Feb 2005 20:15:53 +0100 Subject: FUSE - filesystem in userspace In-Reply-To: <20050207200150.0fe31d53@python2> References: <4207B741.8010804@redhat.com> <20050207200150.0fe31d53@python2> Message-ID: <1107803753.5932.14.camel@localhost.localdomain> Am Montag, den 07.02.2005, 20:01 +0100 schrieb Matthias Saou: > Warren Togami wrote : > > > Vincenzo Ciancia wrote: > > > Hi all, I've been sent here from the fedora-general mailing list. I > just > > > would like to ask people who can to consider fuse (filesystem in > userspace) > > > and sshfs for inclusion into fedora. They both are available at > > > > > > http://fuse.sourceforge.net > > > > My understanding of this is that this would require patching the FC > > kernel, which is something Extras cannot do. Is this incorrect? > > > > If that is the case, then you must convince upstream kernel.org to merge > > FUSE into the standard kernel. Then adding userspace packages like > > sshfs would be fairly easy to do. [...] > It does require a kernel module, though, so it's a similar situation to AFS > and many others... AFAIK the process of merging FUSE has already started (its in -mm) -- so AFAICS it should be soon in 2.6.12 or 2.6.13. So IMHO it's best to wait a bit here. But yes, maybe I'm totally wrong and it will never be included. -- Thorsten Leemhuis From lfarkas at bppiac.hu Mon Feb 7 19:17:29 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Mon, 07 Feb 2005 20:17:29 +0100 Subject: FUSE - filesystem in userspace In-Reply-To: <20050207200150.0fe31d53@python2> References: <4207B741.8010804@redhat.com> <20050207200150.0fe31d53@python2> Message-ID: <4207BEC9.8020802@bppiac.hu> Matthias Saou wrote: > Warren Togami wrote : > > >>Vincenzo Ciancia wrote: >> >>>Hi all, I've been sent here from the fedora-general mailing list. I > > just > >>>would like to ask people who can to consider fuse (filesystem in > > userspace) > >>>and sshfs for inclusion into fedora. They both are available at >>> >>>http://fuse.sourceforge.net >> >>My understanding of this is that this would require patching the FC >>kernel, which is something Extras cannot do. Is this incorrect? >> >>If that is the case, then you must convince upstream kernel.org to merge >>FUSE into the standard kernel. Then adding userspace packages like >>sshfs would be fairly easy to do. > > > The 3rd line of the website reads : > > "Simple installation (no need to patch or recompile the kernel)" > > It does require a kernel module, though, so it's a similar situation to AFS > and many others... and Linus opinion is also intersting: http://marc.theaimsgroup.com/?l=linux-kernel&m=110080420816859&w=2 -- Levente "Si vis pacem para bellum!" From enrico.scholz at informatik.tu-chemnitz.de Mon Feb 7 19:37:48 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 07 Feb 2005 20:37:48 +0100 Subject: qemu. In-Reply-To: <1107785897.19262.411.camel@hades.cambridge.redhat.com> (David Woodhouse's message of "Mon, 07 Feb 2005 14:18:17 +0000") References: <1107785897.19262.411.camel@hades.cambridge.redhat.com> Message-ID: <87oeewcgab.fsf@kosh.ultra.csn.tu-chemnitz.de> dwmw2 at infradead.org (David Woodhouse) writes: > I'd like to add qemu to Extras. Anyone want to second it? > > ftp://ftp.uk.linux.org/pub/people/dwmw2/fc2-mac/SRPMS/qemu-0.6.1-1.src.rpm ok; I do not insist on my fedora.us package, so feel free to maintain qemu. But please fix the following issues first: * do not own common directories like /usr/bin or /usr/share/doc * move /usr/share/doc/qemu-{doc,tech}.html to a better location * make it honor the $RPM_OPT_FLAGS * prevent binary stripping by 'make install'; let rpm create a meaningful -debuginfo package * unregister the init-script at uninstallation * %{?_smp_mflags} can be used * mark the initscript as '%config' * license should be 'GPL/LGPL' Enrico From vincenzo_yahoo_addressguard-gmane at yahoo.it Mon Feb 7 19:38:01 2005 From: vincenzo_yahoo_addressguard-gmane at yahoo.it (Vincenzo Ciancia) Date: Mon, 07 Feb 2005 20:38:01 +0100 Subject: FUSE - filesystem in userspace References: <1107802490.3664.28.camel@localhost.localdomain> Message-ID: Tom 'spot' Callaway wrote: > > Just to make sure I'm reading this right, are you offering to maintain > these packages in fedora-extras, or simply looking for them to be > included and maintained by someone? :) The second one - if I had the time to package it, gain trust, and become the mantainer (perhaps by trashing the whole of RelFS but I hope not to do so) I would have come here with an rpm :) I know, everyone has few time, but maybe there's someone which finds the thing interesting. V. -- Please note that I do not read the e-mail address used in the from field but I read vincenzo_ml at yahoo dot it Attenzione: non leggo l'indirizzo di posta usato nel campo from, ma leggo vincenzo_ml at yahoo dot it From dwmw2 at infradead.org Tue Feb 8 09:06:52 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 08 Feb 2005 09:06:52 +0000 Subject: Packages failing build on PPC. In-Reply-To: <1107602928.7716.9.camel@baythorne.infradead.org> References: <1107537391.18239.106.camel@baythorne.infradead.org> <1107597113.30769.96.camel@bobcat.mine.nu> <1107602928.7716.9.camel@baythorne.infradead.org> Message-ID: <1107853612.7716.141.camel@baythorne.infradead.org> On Sat, 2005-02-05 at 11:28 +0000, David Woodhouse wrote: > On Sat, 2005-02-05 at 11:51 +0200, Ville Skytt? wrote: > > You don't happen to have the build logs available somewhere, so non- > > PPC-owner package maintainers could have a look? > > ftp://peach.ipv6.infradead.org/pub/SRPMS.extras/logs/ Also now http://david.woodhou.se/fc3-extras-ppc-logs/ for the benefit of the IPv6-challenged (although most of you have no excuse for that). I'd appreciate it if package maintainers could take a quick look -- if a build log for your package exists, that's because it failed to build. I can give accounts on PPC machines to package maintainers who need it. Some things in there are OK to be i386-only, but others I'm not sure about -- why sqlite, for example? I see PPC builds of that elsewhere. So I've included all packages here. In the long run, I'd like to see a policy of having to have a bug filed to permit _any_ architecture exclusion. Even if that's a long-term thing like "LILO doesn't make any sense at all on non-i386", I'd like to see it filed, and I'd like to see the build system refusing to honour ExcludeArch: or ExclusiveArch: without the bug number being listed in the specfile. > gpgme fails its own gpgsm tests. > > cvsup wants switching to cm3 which supports PPC. I may also separate > modula3 and modula3-devel and a bunch of the libraries into separate > packages. I did that once before, long ago. > > Inventor needs a GCC bug fixed (the RHEL4 GCC also ICEs on this one). > > torcs seems to use -mieee-fp in its autocrap script and hence decides > that libm isn't present on the system and aborts. > > stow and gnugo fail due to /usr/share/info/dir being present in the > buildroot but unpackaged. > > fbida fails due to /usr/X11R6/lib/X11/app-defaults/Ida being present but > unpackaged. > > A whole bunch of other stuff fails due to random use of inline assembly. > -- dwmw2 From giallu at gmail.com Tue Feb 8 11:24:15 2005 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 8 Feb 2005 12:24:15 +0100 Subject: My open tickets in bugzilla.fedora.us In-Reply-To: <4207B674.90405@redhat.com> References: <4206FCC0.2080706@redhat.com> <20050207111422.2a31e154.fedora@wir-sind-cool.org> <4207408D.9060408@redhat.com> <4207B674.90405@redhat.com> Message-ID: On Mon, 07 Feb 2005 08:41:56 -1000, Warren Togami wrote: > Gianluca Sforna wrote: > > > > This would still not solve the issue with linking it with GPL libs > > like Coin2 and SoQt. I will ask if they can also help us on this > > topic. > > > > Yikes, is this even a fixable situation? AFAIK GPL and LGPL cannot link no? > > Warren > Of course IANAL, but my understanding is you can not link a LGPL app to a GPL library (anything linked to GPL has to be GPL). On the contrary, you can link a GPL app to a LGPL lib since the latter gives you the right to link from an app under any license. So it seems that, in order to allow us to make another OpenMOIV package linked to Coin, they would need to release the next version as GPL (or at least with dual licensing). Gianluca From fedora at wir-sind-cool.org Tue Feb 8 15:44:30 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 8 Feb 2005 16:44:30 +0100 Subject: My open tickets in bugzilla.fedora.us In-Reply-To: References: <4206FCC0.2080706@redhat.com> <20050207111422.2a31e154.fedora@wir-sind-cool.org> <4207408D.9060408@redhat.com> <4207B674.90405@redhat.com> Message-ID: <20050208164430.14db405d.fedora@wir-sind-cool.org> On Tue, 8 Feb 2005 12:24:15 +0100, Gianluca Sforna wrote: > On Mon, 07 Feb 2005 08:41:56 -1000, Warren Togami wrote: > > Gianluca Sforna wrote: > > > > > > This would still not solve the issue with linking it with GPL libs > > > like Coin2 and SoQt. I will ask if they can also help us on this > > > topic. > > > > > > > Yikes, is this even a fixable situation? AFAIK GPL and LGPL cannot link no? > > > > Warren > > > > Of course IANAL, but my understanding is you can not link a LGPL app > to a GPL library (anything linked to GPL has to be GPL). > On the contrary, you can link a GPL app to a LGPL lib since the latter > gives you the right to link from an app under any license. The important bit is the end-product and under which terms it is licenced. The LGPL gives the ability to publish software with "less free" licence terms than GPL. Hence the original name was changed to LESSER GPL (the LGPL permits use of LGPL'ed pieces in proprietary software). You can link GPL and LGPL libraries when creating applications. You can mix GPL and LGPL components in your own software just fine as long as you choose the GPL for your end-product. The LGPL is upwards compatible with the GPL. The end-product can also be a library. But if you wanted to choose the LGPL for it, neither you nor anybody else could apply its terms and create a proprietary app with it, because the GPL'ed pieces it is based on would require the end-product to be GPL, too. OpenMOIV library, on the contrary, is not your own software. If you built it in a way that made it GPL only, this is not what the authors intended (releasing packages like that would impose more strict free software licence terms on the library users). > So it seems that, in order to allow us to make another OpenMOIV > package linked to Coin, they would need to release the next version as > GPL (or at least with dual licensing). Dual licencing is no solution for a library, since LGPL is not an option when the library was built with GPL'ed parts. From dawson at fnal.gov Tue Feb 8 17:12:17 2005 From: dawson at fnal.gov (Troy Dawson) Date: Tue, 08 Feb 2005 11:12:17 -0600 Subject: kernel module rpm naming convention In-Reply-To: <20050208170102.3457074330@hormel.redhat.com> References: <20050208170102.3457074330@hormel.redhat.com> Message-ID: <4208F2F1.9080606@fnal.gov> > Date: Mon, 7 Feb 2005 12:17:04 -0500 > From: "Charles R. Anderson" > Subject: Re: kernel module rpm naming convention > To: fedora-extras-list at redhat.com > Message-ID: <20050207171704.GL11938 at angus.ind.WPI.EDU> > Content-Type: text/plain; charset=us-ascii > > On Mon, Feb 07, 2005 at 09:55:05AM -0600, Troy Dawson wrote: > >> http://www.fedora.us/wiki/PackagingKernelModules >> >>We have even modified yum 2.0.x (currently 2.0.7) to work with this >>naming convention. > > > Why did yum need to be modified? > Yum would install the kernel-module-- rpm's just fine. The problem we wanted fixed was when you do a kernel update. We wanted it to find all the kernel-module rpm's, that went with the new kernel. Troy Dawson -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From james at westexe.demon.co.uk Tue Feb 8 23:56:45 2005 From: james at westexe.demon.co.uk (James Wilkinson) Date: Tue, 8 Feb 2005 23:56:45 +0000 Subject: My open tickets in bugzilla.fedora.us In-Reply-To: <20050208164430.14db405d.fedora@wir-sind-cool.org> References: <4206FCC0.2080706@redhat.com> <20050207111422.2a31e154.fedora@wir-sind-cool.org> <4207408D.9060408@redhat.com> <4207B674.90405@redhat.com> <20050208164430.14db405d.fedora@wir-sind-cool.org> Message-ID: <20050208235645.GA8393@howells.westexe.demon.co.uk> Michael Schwendt wrote: > OpenMOIV library, on the contrary, is not your own software. If you built > it in a way that made it GPL only, this is not what the authors intended > (releasing packages like that would impose more strict free software > licence terms on the library users). Hang on! What about section 3 of the LGPL: "You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library." (The term "Library" is defined as "any such software library or work", so if a program is licensed under the LGPL, it is referred to as a library). The LGPL was explicitly written so that recipients could make modifications (or link with GPL code) and release those modifications under the GPL. James. -- James Wilkinson | TCP/IP evolved primarily by actually being _used_, Exeter Devon UK | rather than being handed down from on high by a vendor E-mail address: james | or a brontosaurus or any other saurian silliness. @westexe.demon.co.uk | -- The megahal program, trained on my quote file. From smooge at gmail.com Wed Feb 9 00:41:37 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Tue, 8 Feb 2005 17:41:37 -0700 Subject: Updating clamav In-Reply-To: <87u0oocimc.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <80d7e409050204152243df53df@mail.gmail.com> <87oeezanro.fsf@kosh.ultra.csn.tu-chemnitz.de> <80d7e40905020416027b3a9c66@mail.gmail.com> <80d7e409050204161477f99698@mail.gmail.com> <87u0oocimc.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <80d7e40905020816412c2430ab@mail.gmail.com> On Mon, 07 Feb 2005 19:47:23 +0100, Enrico Scholz wrote: > smooge at gmail.com ("Stephen J. Smoogen") writes: > > >> > > >> > > Extra currently has 0.71 clamav, and the stable clamav is 0.81 with > >> > > security fixes. With that in mind.. what can I do to get an updated > >> > > spec file/srpm/ for the build system? > >> > > >> > I really don't know if I shall give it free for publishing. There are > >> > lots of non-trivial changes between 0.71 and 0.81 which should pass QA > >> > first. But as you said... 0.71 has security issues and does not accept > >> > new databases. > >> > > > > > Quick QA remarks: > > > > 1) .fdr. is no longer wanted in SPEC files. > > ignore this; the package is for fedora.us. The CVS version should not > have this tag. > > > > 2) zlib update for fedora core 2 has been released. Comment about > > --disable-zlib can be removed from several areas it is posted. > > This is required for FC3 as it ships zlib-2.2.1. But the check requires > >=2.2.2 or <2. > Hmmm ok. The one thing though is that the comments should be removed as they are a bit snarky and non-professional.. even if true about updates being needed. -- Stephen J Smoogen. CSIRT/Linux System Administrator From fedora at wir-sind-cool.org Wed Feb 9 00:53:38 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 9 Feb 2005 01:53:38 +0100 Subject: My open tickets in bugzilla.fedora.us In-Reply-To: <20050208235645.GA8393@howells.westexe.demon.co.uk> References: <4206FCC0.2080706@redhat.com> <20050207111422.2a31e154.fedora@wir-sind-cool.org> <4207408D.9060408@redhat.com> <4207B674.90405@redhat.com> <20050208164430.14db405d.fedora@wir-sind-cool.org> <20050208235645.GA8393@howells.westexe.demon.co.uk> Message-ID: <20050209015338.0c4e7b00.fedora@wir-sind-cool.org> On Tue, 8 Feb 2005 23:56:45 +0000, James Wilkinson wrote: > > OpenMOIV library, on the contrary, is not your own software. If you built > > it in a way that made it GPL only, this is not what the authors intended > > (releasing packages like that would impose more strict free software > > licence terms on the library users). > > Hang on! > > What about section 3 of the LGPL: "You may opt to apply the terms of the > ordinary GNU General Public License instead of this License to a given > copy of the Library." > > (The term "Library" is defined as "any such software library or work", > so if a program is licensed under the LGPL, it is referred to as a > library). > > The LGPL was explicitly written so that recipients could make > modifications (or link with GPL code) and release those modifications > under the GPL. Completing the quote: "To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library." This belongs to the "upwards compatible" side of the LGPL. When e.g. you derive work from LGPL'ed code (even if you just copy fragments into your own project) you are free to apply the GPL, instead of the LGPL, to that work. This makes it possible to create free software based on LGPL'ed software and not being forced to apply the same lesser free licence terms to your derived work. E.g. you could fork libbar (GPL) from libfoo (LGPL). Problems with LGPL are lurking in many places unless it happens to be a core library like glibc. From cra at WPI.EDU Wed Feb 9 04:07:00 2005 From: cra at WPI.EDU (Charles R. Anderson) Date: Tue, 8 Feb 2005 23:07:00 -0500 Subject: requesting sponsor for new package: xmms-jess Message-ID: <20050209040700.GV11938@angus.ind.WPI.EDU> I've packaged a visualization plugin for xmms called JESS: http://angus.ind.wpi.edu/~cra/fedora/extras/xmms-jess/ URL : http://arquier.free.fr/ Summary : JESS Visualization Plugin for XMMS Description : JESS is a visualization plugin for XMMS with blur, image distortion, oscilloscope, 3D rotating grids with synchro zoom, fading palette, and synchronized flash effects. * Tue Feb 08 2005 Charles R. Anderson > - 0:2.91-1 - initial package for Fedora Extras Is anyone interested in sponsoring this for inclusion to Extras? Thanks. From skvidal at fedoraproject.org Wed Feb 9 05:14:00 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 09 Feb 2005 00:14:00 -0500 Subject: Fedora Extras Packages Message-ID: <1107926040.32017.11.camel@cutter> CVS is Alive, Alive! Package updates/builds: New/Updated: opensc libassuan gpgme03 perl-Cache-Cache gpgme gnupg2 libksba scribus scribus-templates meld gramps Removed: crytplug libgcrypt1 newpg thanks to all the contributors who made these happen. -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Wed Feb 9 08:08:45 2005 From: wtogami at redhat.com (Warren Togami) Date: Tue, 08 Feb 2005 22:08:45 -1000 Subject: Tracking Thoughts Re: requesting sponsor for new package: xmms-jess In-Reply-To: <20050209040700.GV11938@angus.ind.WPI.EDU> References: <20050209040700.GV11938@angus.ind.WPI.EDU> Message-ID: <4209C50D.6070504@redhat.com> Charles R. Anderson wrote: > I've packaged a visualization plugin for xmms called JESS: > > http://angus.ind.wpi.edu/~cra/fedora/extras/xmms-jess/ > > > URL : http://arquier.free.fr/ > Summary : JESS Visualization Plugin for XMMS > Description : > JESS is a visualization plugin for XMMS with blur, image distortion, > oscilloscope, 3D rotating grids with synchro zoom, fading palette, and > synchronized flash effects. > > > * Tue Feb 08 2005 Charles R. Anderson > - 0:2.91-1 > > - initial package for Fedora Extras > > > Is anyone interested in sponsoring this for inclusion to Extras? May I point out that without a database driven tracking system, there is no way to easily track requests like this. So if nobody deals with it immediately, it will become lost since it is not in any queue. It will be confusing when there are 500 similar requests and a random set of 300 are finished. With database tracked reports, this thing can be tracked, query for open issues, and closed when done. Yes there are many valid arguments against Bugzilla too. I think that these concerns were mainly implementation details (and push/pull communication concerns) that are possible to fix. But instead we have a total rejection of anything resembling the old fedora.us process in favor of this unstructured mess. Anyhow, I should not be using my time now to argue about this now. We can more effectively discuss this during FUDCON week. Warren Togami wtogami at redhat.com From skvidal at fedoraproject.org Wed Feb 9 08:50:56 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 09 Feb 2005 03:50:56 -0500 Subject: Fedora Extras Packages Message-ID: <1107939056.7945.2.camel@cutter> Hi, one more new package: perl-Razor-Agent x86, x86_64 Status page: http://fedoraproject.org/wiki/Extras_2fFC3Status Follow updates and new packages at: http://fedoraproject.org/infofeed/ Report problems at Bugzilla: http://bugzilla.redhat.com/ thanks, -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Wed Feb 9 08:54:02 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 09 Feb 2005 03:54:02 -0500 Subject: Tracking Thoughts Re: requesting sponsor for new package: xmms-jess In-Reply-To: <4209C50D.6070504@redhat.com> References: <20050209040700.GV11938@angus.ind.WPI.EDU> <4209C50D.6070504@redhat.com> Message-ID: <1107939242.7945.4.camel@cutter> > May I point out that without a database driven tracking system, there is > no way to easily track requests like this. So if nobody deals with it > immediately, it will become lost since it is not in any queue. It will > be confusing when there are 500 similar requests and a random set of 300 > are finished. With database tracked reports, this thing can be tracked, > query for open issues, and closed when done. sounds like a good reason to work on a database, then. > Yes there are many valid arguments against Bugzilla too. I think that > these concerns were mainly implementation details (and push/pull > communication concerns) that are possible to fix. But instead we have a > total rejection of anything resembling the old fedora.us process in > favor of this unstructured mess. no, we have a transition from one overly-structured mess into something that can evolve. > Anyhow, I should not be using my time now to argue about this now. We > can more effectively discuss this during FUDCON week. And yet, you are using your time to argue it now. -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 9 10:30:26 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 9 Feb 2005 11:30:26 +0100 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <20050207131917.44e53bb8@python2> References: <20050207131917.44e53bb8@python2> Message-ID: <20050209113026.4e9651a9@python2> Matthias Saou wrote : > - udftools : As UDF packet writing support is now in the latest FC kernels, > these tools are useful "out of the box" on FC without any kernel patching > or recompiling, thus should be easily accessible to all users. I've just imported this trivial package into CVS. Not sure if I did the right thing, as no one "sponsored" me... but nobody either opposed or commented on the idea either. People interested in reviewing it can do so now. My basic testing went fine, but I still want to check x86_64 before asking for the initial build (and also incorporate any suggested changes). Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.07 0.18 0.24 From wtogami at redhat.com Wed Feb 9 10:32:55 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 09 Feb 2005 00:32:55 -1000 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <20050209113026.4e9651a9@python2> References: <20050207131917.44e53bb8@python2> <20050209113026.4e9651a9@python2> Message-ID: <4209E6D7.60003@redhat.com> Matthias Saou wrote: > > I've just imported this trivial package into CVS. Not sure if I did the > right thing, as no one "sponsored" me... but nobody either opposed or > commented on the idea either. https://www.redhat.com/archives/fedora-extras-list/2005-February/msg00208.html By the Interim New Package Process you (someone with CVS access) can import before review, no problem. Warren Togami wtogami at redhat.com From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 9 10:36:55 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 9 Feb 2005 11:36:55 +0100 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <1107791713.30385.24.camel@opus.phy.duke.edu> References: <20050207131917.44e53bb8@python2> <20050207135420.773a2b08.fedora@wir-sind-cool.org> <20050207165323.6cc06bb9@python2> <1107791713.30385.24.camel@opus.phy.duke.edu> Message-ID: <20050209113655.1d7bf723@python2> seth vidal wrote : > Public Domain, should be legit for redistribution. But bug the > starfighter author. See what s/he thinks. Here is my question, and the answer I got : -- On Monday 07 Feb 2005 16:10, you wrote: > other: I want to package the starfighter music in an rpm for Fedora Extras, > but am not sure about the license it falls under, as the website seems to > indicate that everything is covered by the GPL, but the infomation inside > the MOD files indicate that they are public domain. Hmmm... this is something I'm not sure on myself I'm afraid. The music is indeed within the public domain whilst the game itself is GPL. I'm not sure if that therefore means I cannot distribute the music with the rest of the game, or if the authors would turn a blind eye to it. It is a tricky one. But I haven't attempted to contact any of the authors... however the last time I did contact a music author I was told the music should be distributed freely. Too be 100% honest, I can't be sure on this matter. Sorry, Stevie :( -- My understanding of "Public Domain" is that you can basically do whatever you like with whatever it is that you've got. There are no obligation of providing the source code AFAIK, but we are here concerned about MOD music files, not an actual program, so I don't think it's relevant. Basically, they're public domain... seems enough to me to include them. Thoughts? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.12 0.20 0.25 From fedora at wir-sind-cool.org Wed Feb 9 11:06:18 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 9 Feb 2005 12:06:18 +0100 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <20050209113655.1d7bf723@python2> References: <20050207131917.44e53bb8@python2> <20050207135420.773a2b08.fedora@wir-sind-cool.org> <20050207165323.6cc06bb9@python2> <1107791713.30385.24.camel@opus.phy.duke.edu> <20050209113655.1d7bf723@python2> Message-ID: <20050209120618.382415d8.fedora@wir-sind-cool.org> On Wed, 9 Feb 2005 11:36:55 +0100, Matthias Saou wrote: > seth vidal wrote : > > > Public Domain, should be legit for redistribution. But bug the > > starfighter author. See what s/he thinks. > > Here is my question, and the answer I got : > > -- > > On Monday 07 Feb 2005 16:10, you wrote: > > other: I want to package the starfighter music in an rpm for Fedora > Extras, > > but am not sure about the license it falls under, as the website seems to > > indicate that everything is covered by the GPL, but the infomation inside > > the MOD files indicate that they are public domain. > > Hmmm... this is something I'm not sure on myself I'm afraid. The music is > indeed within the public domain whilst the game itself is GPL. I'm not sure > > if that therefore means I cannot distribute the music with the rest of the > game, or if the authors would turn a blind eye to it. > > It is a tricky one. But I haven't attempted to contact any of the > authors... > however the last time I did contact a music author I was told the music > should be distributed freely. > > Too be 100% honest, I can't be sure on this matter. Sorry, > > Stevie :( > > -- > > My understanding of "Public Domain" is that you can basically do whatever > you like with whatever it is that you've got. There are no obligation of > providing the source code AFAIK, but we are here concerned about MOD music > files, not an actual program, so I don't think it's relevant. > Basically, they're public domain... seems enough to me to include them. > Thoughts? Yes. Btw, a .mod file is "the source code" raw material for this type of music format. It's not preprocessed. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 9 11:52:46 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 9 Feb 2005 12:52:46 +0100 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <20050209120618.382415d8.fedora@wir-sind-cool.org> References: <20050207131917.44e53bb8@python2> <20050207135420.773a2b08.fedora@wir-sind-cool.org> <20050207165323.6cc06bb9@python2> <1107791713.30385.24.camel@opus.phy.duke.edu> <20050209113655.1d7bf723@python2> <20050209120618.382415d8.fedora@wir-sind-cool.org> Message-ID: <20050209125246.3bd2fa3e@python2> Michael Schwendt wrote : > > My understanding of "Public Domain" is that you can basically do whatever > > you like with whatever it is that you've got. There are no obligation of > > providing the source code AFAIK, but we are here concerned about MOD music > > files, not an actual program, so I don't think it's relevant. > > Basically, they're public domain... seems enough to me to include them. > > Thoughts? > > Yes. > > Btw, a .mod file is "the source code" raw material for this type of music > format. It's not preprocessed. OK, and thanks for the details. That's what I thought and meant by "not being relevant", as we do have the source code, it's not like if we had a public domain binary program without its sources, as we definitely couldn't include that. So I'll import "starfighter-music" and make it depend on "starfighter", as well as make "starfighter" depend on it (but without any versions, as I don't think it would be useful). Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.15 0.25 0.16 From robert at marcanoonline.com Wed Feb 9 13:51:47 2005 From: robert at marcanoonline.com (Robert Marcano) Date: Wed, 09 Feb 2005 09:51:47 -0400 Subject: Mirrors Message-ID: <1107957107.5768.5.camel@tprobert.intranet.promca.com> Were the mirrors administrators notified about the new fedora extras tree? I have been unable to find a mirror with the "extras" directory, only with the "core" directory, The only mirrors available are from the fedora.us mirror, but it does not have the x86_64 and SRPMS directories available to download ________________________________________ Robert Marcano web: http://www.marcanoonline.com/ blog: http://www.marcanoonline.com/plog/ From skvidal at phy.duke.edu Wed Feb 9 14:05:25 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 09 Feb 2005 09:05:25 -0500 Subject: Mirrors In-Reply-To: <1107957107.5768.5.camel@tprobert.intranet.promca.com> References: <1107957107.5768.5.camel@tprobert.intranet.promca.com> Message-ID: <1107957925.21824.0.camel@cutter> On Wed, 2005-02-09 at 09:51 -0400, Robert Marcano wrote: > Were the mirrors administrators notified about the new fedora extras > tree? I have been unable to find a mirror with the "extras" directory, > only with the "core" directory, The only mirrors available are from the > fedora.us mirror, but it does not have the x86_64 and SRPMS directories > available to download the mirroring of extras is not an obligation every mirror maintainer will want to undertake. I have a list of 25-30 mirrors right now who have mirrored it - I need to upload it before long. -sv From robert at marcanoonline.com Wed Feb 9 14:15:01 2005 From: robert at marcanoonline.com (Robert Marcano) Date: Wed, 09 Feb 2005 10:15:01 -0400 Subject: Mirrors In-Reply-To: <1107957925.21824.0.camel@cutter> References: <1107957107.5768.5.camel@tprobert.intranet.promca.com> <1107957925.21824.0.camel@cutter> Message-ID: <1107958501.5768.10.camel@tprobert.intranet.promca.com> On Wed, 2005-02-09 at 09:05 -0500, seth vidal wrote: > On Wed, 2005-02-09 at 09:51 -0400, Robert Marcano wrote: > > Were the mirrors administrators notified about the new fedora extras > > tree? I have been unable to find a mirror with the "extras" directory, > > only with the "core" directory, The only mirrors available are from the > > fedora.us mirror, but it does not have the x86_64 and SRPMS directories > > available to download > > the mirroring of extras is not an obligation every mirror maintainer > will want to undertake. true, but i just was curious because i was unable to find one > > I have a list of 25-30 mirrors right now who have mirrored it - I need > to upload it before long. cool. I hope at least one of them allows rsync to populate my internal mirror for 10 machines > > -sv > ________________________________________ Robert Marcano From dgregor at redhat.com Wed Feb 9 17:02:57 2005 From: dgregor at redhat.com (Dennis Gregorovic) Date: Wed, 09 Feb 2005 12:02:57 -0500 Subject: New candidates packages for Extras Message-ID: <1107968577.3582.21.camel@dhcp83-72.boston.redhat.com> I would like to add the following packages to Extras. These are all Artistic license except perl-Test-AutoBuild, which is GPL. perl-Test-AutoBuild (http://www.autobuild.org/): This is a Perl module that provides a Framework for performing continuous, unattended, automated software builds. It is a side-project of mine. The rest of these are required for Test::AutoBuild to run. perl-Class-MethodMaker: Perl module for creating generic object-oriented methods perl-Config-Record: Perl module for Configuration file access perl-Pod-POM: Perl module for representing a POD object model perl-Template-Toolkit: The Template Toolkit is a fast, powerful and extensible template processing system. perl-Text-Autoformat: Perl module for Automatic text wrapping and reformatting perl-XML-XPath: Perl modules for parsing and evaluating XPath statements Any objections? Cheers -- Dennis -- Dennis Gregorovic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Wed Feb 9 17:03:53 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 09 Feb 2005 11:03:53 -0600 Subject: New candidates packages for Extras In-Reply-To: <1107968577.3582.21.camel@dhcp83-72.boston.redhat.com> References: <1107968577.3582.21.camel@dhcp83-72.boston.redhat.com> Message-ID: <1107968633.3664.107.camel@localhost.localdomain> On Wed, 2005-02-09 at 12:02 -0500, Dennis Gregorovic wrote: > I would like to add the following packages to Extras. These are all > Artistic license except perl-Test-AutoBuild, which is GPL. Great! We certainly could use more perl packages in the system, its one of the major complaints I hear again and again. ~spot --- Tom "spot" Callaway LCA, RHCE Red Hat Sales Engineer || Aurora Linux Project Leader "If you are going through hell, keep going." -- Sir Winston Churchill From skvidal at phy.duke.edu Wed Feb 9 17:14:05 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 09 Feb 2005 12:14:05 -0500 Subject: New candidates packages for Extras In-Reply-To: <1107968633.3664.107.camel@localhost.localdomain> References: <1107968577.3582.21.camel@dhcp83-72.boston.redhat.com> <1107968633.3664.107.camel@localhost.localdomain> Message-ID: <1107969245.21824.60.camel@cutter> On Wed, 2005-02-09 at 11:03 -0600, Tom 'spot' Callaway wrote: > On Wed, 2005-02-09 at 12:02 -0500, Dennis Gregorovic wrote: > > I would like to add the following packages to Extras. These are all > > Artistic license except perl-Test-AutoBuild, which is GPL. > > Great! We certainly could use more perl packages in the system, its one > of the major complaints I hear again and again. > But maybe a separate repo for: fedora-extras-oh-my-god-the-perl-stuff-just-keeps-on-coming or something like that? :) -sv From Lam at Lam.pl Wed Feb 9 17:30:05 2005 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 09 Feb 2005 18:30:05 +0100 Subject: New candidates packages for Extras In-Reply-To: <1107969245.21824.60.camel@cutter> References: <1107968577.3582.21.camel@dhcp83-72.boston.redhat.com> <1107968633.3664.107.camel@localhost.localdomain> <1107969245.21824.60.camel@cutter> Message-ID: <1107970205.5831.4.camel@pensja.lam.pl> Dnia 09-02-2005, ?ro o godzinie 12:14 -0500, seth vidal napisa?(a): > But maybe a separate repo for: > fedora-extras-oh-my-god-the-perl-stuff-just-keeps-on-coming Or maybe just one package perl-CPANtoRPM containing a generic automatic spec generator and RPM builder? :) I really like the idea of having everything packaged and managed using RPM even if it's not in extras. The time for creating such tool should be shorter (having all the CPAN compiling, testing and installing framework done already by Perl people) than maintainig tens of packages in extras, right? :) Or maybe somebody already did that? :) Lam From robert at marcanoonline.com Wed Feb 9 17:36:30 2005 From: robert at marcanoonline.com (Robert Marcano) Date: Wed, 09 Feb 2005 13:36:30 -0400 Subject: New candidates packages for Extras In-Reply-To: <1107970205.5831.4.camel@pensja.lam.pl> References: <1107968577.3582.21.camel@dhcp83-72.boston.redhat.com> <1107968633.3664.107.camel@localhost.localdomain> <1107969245.21824.60.camel@cutter> <1107970205.5831.4.camel@pensja.lam.pl> Message-ID: <1107970591.1102.0.camel@tprobert.intranet.promca.com> On Wed, 2005-02-09 at 18:30 +0100, Leszek Matok wrote: > Dnia 09-02-2005, ?ro o godzinie 12:14 -0500, seth vidal napisa?(a): > > But maybe a separate repo for: > > fedora-extras-oh-my-god-the-perl-stuff-just-keeps-on-coming > Or maybe just one package perl-CPANtoRPM containing a generic automatic > spec generator and RPM builder? :) I really like the idea of having > everything packaged and managed using RPM even if it's not in extras. > The time for creating such tool should be shorter (having all the CPAN > compiling, testing and installing framework done already by Perl people) > than maintainig tens of packages in extras, right? :) > > Or maybe somebody already did that? :) http://perl.arix.com/cpan2rpm/ > > Lam > > -- > 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/ blog: http://www.marcanoonline.com/plog/ From fedora at wir-sind-cool.org Wed Feb 9 16:45:07 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 9 Feb 2005 17:45:07 +0100 Subject: requesting sponsor for new package: xmms-jess In-Reply-To: <20050209040700.GV11938@angus.ind.WPI.EDU> References: <20050209040700.GV11938@angus.ind.WPI.EDU> Message-ID: <20050209174507.59a4301b.fedora@wir-sind-cool.org> On Tue, 8 Feb 2005 23:07:00 -0500, Charles R. Anderson wrote: > I've packaged a visualization plugin for xmms called JESS: > > http://angus.ind.wpi.edu/~cra/fedora/extras/xmms-jess/ > > > URL : http://arquier.free.fr/ > Summary : JESS Visualization Plugin for XMMS > Description : > JESS is a visualization plugin for XMMS with blur, image distortion, > oscilloscope, 3D rotating grids with synchro zoom, fading palette, and > synchronized flash effects. > > > * Tue Feb 08 2005 Charles R. Anderson > - 0:2.91-1 > > - initial package for Fedora Extras > > > Is anyone interested in sponsoring this for inclusion to Extras? My take on this is: * I'd like to see the CVS accounts creation thingy get going first, so more of the current fedora.us package developers can work on their packages without needing another person as a gateway to CVS. I consider this important particularly for update requests which consist of more than a small patch. If package owners need to mail sponsors or trusted developers (or whatever we call them) and make available src.rpms on some website and transfer files back and forth and all that stuff before CVS can be updated, that is no improvement compared with the fedora.us process. No public queue, probably even communication via private mail or bugzilla tickets which get buried beneath dozens to hundreds of other bugs. [Does every package owner have a CVS gateway contact person already?] Being a package sponsor would mean to apply at least the security relevant sanity checks from fedora.us [and most likely skim over the technical spec details] before importing something. So, package request approval is not simplified unless there is a level of trust between two people already. Usually, community QA does not kick in before binaries are built and published somewhere. The fine folks who comment on src.rpms prior to release, or reply to extras-commits-list, are an exception. I want to see how the "promotion" of external contributors works out in practice. When that works, resources are free. And as such, my focus is on keeping the existing packages in Fedora Extras maintained and supporting the current package owners. * I'd like to get confirmation on whether we are complete, that is whether all the packages transferred from fedora.us have an active package owner. At least one trusted developer is being missed for several weeks. * I'd like to avoid the bottleneck of a few contributors trying to battle a flood of new package requests, and the uncertainty that the barrier to getting CVS access might be a problem. External contributors always bear the risk of dropping off all of sudden when they consider the project's procedures a burden. I'd like to avoid that an external packager's first package is accepted, but his other six packages don't seem to make it because of lack of resources or lack of interest. * There's also still the old fedora.us package submission list, which is still active with regard to packages which have been reviewed and which are being worked on (sometimes in conjunction with upstream authors). It makes no sense to kill the active parts of it. But it would make sense to transfer unreviewed package requests into a new queue/list which targets Fedora Extras and would be processed differently. Michael -- Fedora Core release 3 (Heidelberg) - Linux 2.6.10-1.762_FC3 loadavg: 1.10 1.13 1.37 From jpo at di.uminho.pt Wed Feb 9 17:46:39 2005 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Wed, 09 Feb 2005 17:46:39 +0000 Subject: New candidates packages for Extras In-Reply-To: <1107968577.3582.21.camel@dhcp83-72.boston.redhat.com> References: <1107968577.3582.21.camel@dhcp83-72.boston.redhat.com> Message-ID: <420A4C7F.3030100@di.uminho.pt> Dennis Gregorovic, Some of these perl modules already exist in the QA queues of Fedora.us. In particular: - perl-XML-XPath is ready - perl-Pod-POM is under QA - perl-Text-Autoformat may need an update - perl-Template Toolkit Right now fails a test GD test in FC3 (this module still isn't in the bugzilla but almost every build requirement is; talk to Ville Skytta for more information) Regards, jpo > I would like to add the following packages to Extras. These are all > Artistic license except perl-Test-AutoBuild, which is GPL. > > perl-Test-AutoBuild (http://www.autobuild.org/): > This is a Perl module that provides a Framework for performing > continuous, unattended, automated software builds. It is a side-project > of mine. The rest of these are required for Test::AutoBuild to run. > > perl-Class-MethodMaker: > Perl module for creating generic object-oriented methods > perl-Config-Record: > Perl module for Configuration file access > perl-Pod-POM: > Perl module for representing a POD object model > perl-Template-Toolkit: > The Template Toolkit is a fast, powerful and extensible template > processing system. > perl-Text-Autoformat: > Perl module for Automatic text wrapping and reformatting > perl-XML-XPath: > Perl modules for parsing and evaluating XPath statements > > Any objections? > -- Jos? Pedro Oliveira mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo From steve at silug.org Wed Feb 9 18:04:37 2005 From: steve at silug.org (Steven Pritchard) Date: Wed, 9 Feb 2005 12:04:37 -0600 Subject: New candidates packages for Extras In-Reply-To: <1107968577.3582.21.camel@dhcp83-72.boston.redhat.com> References: <1107968577.3582.21.camel@dhcp83-72.boston.redhat.com> Message-ID: <20050209180437.GA31816@osiris.silug.org> On Wed, Feb 09, 2005 at 12:02:57PM -0500, Dennis Gregorovic wrote: > perl-Text-Autoformat: > Perl module for Automatic text wrapping and reformatting https://bugzilla.fedora.us/show_bug.cgi?id=1354 Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From dgregor at redhat.com Wed Feb 9 18:17:51 2005 From: dgregor at redhat.com (Dennis Gregorovic) Date: Wed, 09 Feb 2005 13:17:51 -0500 Subject: New candidates packages for Extras In-Reply-To: <420A4C7F.3030100@di.uminho.pt> References: <1107968577.3582.21.camel@dhcp83-72.boston.redhat.com> <420A4C7F.3030100@di.uminho.pt> Message-ID: <1107973071.3582.30.camel@dhcp83-72.boston.redhat.com> jpo, Thank you for pointing these out. As you can tell, I didn't check the Fedora.us queues before my first post. (I'm new to Fedora.us/Extras process) Ville, what's the status on these packages? Would you like to add them to Extras? Cheers -- Dennis On Wed, 2005-02-09 at 17:46 +0000, Jose Pedro Oliveira wrote: > Dennis Gregorovic, > > Some of these perl modules already exist in the > QA queues of Fedora.us. > > In particular: > - perl-XML-XPath is ready > - perl-Pod-POM is under QA > - perl-Text-Autoformat may need an update > - perl-Template Toolkit > Right now fails a test GD test in FC3 > (this module still isn't in the bugzilla but almost every > build requirement is; talk to Ville Skytta for more information) > > > Regards, > jpo > > > I would like to add the following packages to Extras. These are all > > Artistic license except perl-Test-AutoBuild, which is GPL. > > > > perl-Test-AutoBuild (http://www.autobuild.org/): > > This is a Perl module that provides a Framework for performing > > continuous, unattended, automated software builds. It is a side-project > > of mine. The rest of these are required for Test::AutoBuild to run. > > > > perl-Class-MethodMaker: > > Perl module for creating generic object-oriented methods > > perl-Config-Record: > > Perl module for Configuration file access > > perl-Pod-POM: > > Perl module for representing a POD object model > > perl-Template-Toolkit: > > The Template Toolkit is a fast, powerful and extensible template > > processing system. > > perl-Text-Autoformat: > > Perl module for Automatic text wrapping and reformatting > > perl-XML-XPath: > > Perl modules for parsing and evaluating XPath statements > > > > Any objections? > > > > -- Dennis Gregorovic -------------- next part -------------- A non-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 Wed Feb 9 18:22:25 2005 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Wed, 09 Feb 2005 18:22:25 +0000 Subject: New candidates packages for Extras In-Reply-To: <1107970591.1102.0.camel@tprobert.intranet.promca.com> References: <1107968577.3582.21.camel@dhcp83-72.boston.redhat.com> <1107968633.3664.107.camel@localhost.localdomain> <1107969245.21824.60.camel@cutter> <1107970205.5831.4.camel@pensja.lam.pl> <1107970591.1102.0.camel@tprobert.intranet.promca.com> Message-ID: <420A54E1.3080404@di.uminho.pt> Robert Marcano wrote: >>Or maybe just one package perl-CPANtoRPM containing a generic automatic >>spec generator and RPM builder? :) I really like the idea of having >>everything packaged and managed using RPM even if it's not in extras. >>The time for creating such tool should be shorter (having all the CPAN >>compiling, testing and installing framework done already by Perl people) >>than maintainig tens of packages in extras, right? :) >> >>Or maybe somebody already did that? :) > > http://perl.arix.com/cpan2rpm/ > >>Lam I have several tools listed here: http://gsd.di.uminho.pt/jpo/perl/specfiles/#TOOLS While several of these tools are able to create RPMS they usually don't detect the building requirements (modules required for running the test suite). Another problem is that rpm doesn't catch all module requirements, in particular the ones loaded with "require". And this is only one of the problems, we still have to check system, open, backticks, ... All comes back to human reviewers... Regards, jpo PS - The last link of the above list may be promising. -- Jos? Pedro Oliveira mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo From Lam at Lam.pl Wed Feb 9 19:57:32 2005 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 09 Feb 2005 20:57:32 +0100 Subject: New candidates packages for Extras In-Reply-To: <420A54E1.3080404@di.uminho.pt> References: <1107968577.3582.21.camel@dhcp83-72.boston.redhat.com> <1107968633.3664.107.camel@localhost.localdomain> <1107969245.21824.60.camel@cutter> <1107970205.5831.4.camel@pensja.lam.pl> <1107970591.1102.0.camel@tprobert.intranet.promca.com> <420A54E1.3080404@di.uminho.pt> Message-ID: <1107979052.5831.23.camel@pensja.lam.pl> Dnia 09-02-2005, ?ro o godzinie 18:22 +0000, Jose Pedro Oliveira napisa? (a): > While several of these tools are able to create > RPMS they usually don't detect the building > requirements (modules required for running the > test suite). I guess it's not a big issue as we're talking about building binary RPM- s from CPAN sources only for your own usage, not src.rpms to distribute further. Even if something fails in the process it's no different from building things from CPAN without making RPM-s out of them. But if it works, you have your perl-anything packaged and ready for rpm -i and rpm -e :) > Another problem is that rpm doesn't catch all > module requirements, in particular the ones > loaded with "require". And this is only one > of the problems, we still have to check > system, open, backticks, ... Both problems exist, but remember CPAN has its built-in dependencies between Perl modules. They can be easily imported to the spec file if we have a consistent naming scheme. Even if there are exceptions (packages that can't be automated this way) they can have their specific packages or be blacklisted or anything. CPAN page seems to have some problems ATM (at least for me), but I guess one of the projects linked from the page you pasted could evolve quickly to do the job, especially after (if) being included in Fedora Extras, when lots of people will have a chance to find its bugs :) Lam From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 9 20:31:50 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 9 Feb 2005 21:31:50 +0100 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <20050207131917.44e53bb8@python2> References: <20050207131917.44e53bb8@python2> Message-ID: <20050209213150.3519b56b@python2> Matthias Saou wrote : > - starfighter-music [...] Yikes. "Much ado about nothing" :-) I started wondering, so I asked... and I was right : "Aye... The music is already in the pak file. The music is just there as a seperate download because a lot of people requested access to the music files since they wanted to listen to them seperately ;)" Sooo... basically the separate package it totally irrelevant (that's what I get for never playing the game with sound on!), but things did get cleared up regarding the license of the included music files. Should this be reflected in the "License:" tag of the package? Or does "public domain" mean that these files can be reused in any proprietary or free software, thus relicensed just about any way one wants? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.42 0.29 0.33 From skvidal at fedoraproject.org Wed Feb 9 20:35:47 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 09 Feb 2005 15:35:47 -0500 Subject: Fedora Extras Package Updates Message-ID: <1107981347.4617.8.camel@cutter> Hi everyone: Packages and what platforms they were built for: elmo (x86_64) gpa (x86_64) manedit (i386, x86_64) plib (i386, x86_64) torcs (i386, x86_64) torcs-data (i386, x86_64) udftools (i386, x86_64) mhash (i386, x86_64) gazpacho (i386, x86_64) Status page: http://fedoraproject.org/wiki/Extras_2fFC3Status Follow updates and new packages at: http://fedoraproject.org/infofeed/ Report problems at Bugzilla: http://bugzilla.redhat.com/ thanks, -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Wed Feb 9 20:59:58 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 09 Feb 2005 10:59:58 -1000 Subject: Unsearchable Subject Mail Message-ID: <420A79CE.6070603@redhat.com> Subject: New candidates packages for Extras Using generic names like this for mail subjects makes it really difficult to find discussion about a certain package. Why not at least put the package name(s) in the Subject line so it can be found easier later? The trouble with this however is that it will be done in many arbitrary ways, and some people won't do it at all. Another thought of how this "evolving" process is worse than a database tracked process. Warren Togami wtogami at redhat.com From skvidal at phy.duke.edu Wed Feb 9 21:09:04 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 09 Feb 2005 16:09:04 -0500 Subject: Unsearchable Subject Mail In-Reply-To: <420A79CE.6070603@redhat.com> References: <420A79CE.6070603@redhat.com> Message-ID: <1107983345.4617.17.camel@cutter> On Wed, 2005-02-09 at 10:59 -1000, Warren Togami wrote: > Subject: New candidates packages for Extras > > Using generic names like this for mail subjects makes it really > difficult to find discussion about a certain package. Why not at least > put the package name(s) in the Subject line so it can be found easier later? > > The trouble with this however is that it will be done in many arbitrary > ways, and some people won't do it at all. Another thought of how this > "evolving" process is worse than a database tracked process. > But at least you're not being snide or snippy about it. And that's important! -sv From fedora at wir-sind-cool.org Wed Feb 9 21:41:32 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 9 Feb 2005 22:41:32 +0100 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <20050209213150.3519b56b@python2> References: <20050207131917.44e53bb8@python2> <20050209213150.3519b56b@python2> Message-ID: <20050209224132.428bb629.fedora@wir-sind-cool.org> On Wed, 9 Feb 2005 21:31:50 +0100, Matthias Saou wrote: > Matthias Saou wrote : > > > - starfighter-music > [...] > > Yikes. > > "Much ado about nothing" :-) > > I started wondering, so I asked... and I was right : > > "Aye... The music is already in the pak file. The music is just there as a > seperate download because a lot of people requested access to the music > files > since they wanted to listen to them seperately ;)" > > Sooo... basically the separate package it totally irrelevant (that's what I > get for never playing the game with sound on!), but things did get cleared > up regarding the license of the included music files. Should this be > reflected in the "License:" tag of the package? Or does "public domain" > mean that these files can be reused in any proprietary or free software, > thus relicensed just about any way one wants? That's a question for lawyers, whether somebody also waives all his rights in the composition (melody, accompany and such details) when he releases music into the public domain. It is my understanding that work released into the public domain is not even copyrighted. There is no evidence to believe that these files were not released into the public domain. Upstream could add a note or a README which explains where these files come from and that they are believed to be in the public domain. I find it unimportant to do that at the rpm level as you can download thousands of MOD files freely. With a bit of research (on composer's pseudonyms or song titles) it might be possible to find exactly these files in some place where they can be downloaded independent from the GPL. There are MOD music collectors who maintain composer information painstakingly, so proper credits can be given when reusing a file from such a collection. From fabrice.colin at ntlworld.com Wed Feb 9 22:37:51 2005 From: fabrice.colin at ntlworld.com (Fabrice Colin) Date: Wed, 09 Feb 2005 22:37:51 +0000 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <20050209224132.428bb629.fedora@wir-sind-cool.org> References: <20050207131917.44e53bb8@python2> <20050209213150.3519b56b@python2> <20050209224132.428bb629.fedora@wir-sind-cool.org> Message-ID: <420A90BF.7060300@ntlworld.com> Michael Schwendt wrote: > I find it unimportant to do that at the rpm level as you can download > thousands of MOD files freely. With a bit of research (on composer's > pseudonyms or song titles) it might be possible to find exactly these > files in some place where they can be downloaded independent from the GPL. > There are MOD music collectors who maintain composer information > painstakingly, so proper credits can be given when reusing a file from > such a collection. > If these MOD files were ripped from Amiga demos as previously suggested, a good place to look would be the "mods" branch of Aminet : http://ftp.uni-paderborn.de/aminet/dirs/tree_mods.html Fabrice From notting at redhat.com Wed Feb 9 22:59:50 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 9 Feb 2005 17:59:50 -0500 Subject: new package: aqhbci-qt-tools Message-ID: <20050209225950.GD17951@nostromo.devel.redhat.com> It's a setup widget for HBCI accounts; can be used by the HBCI support in gnucash, although doesn't really seem like a Core thing. (If only all the support could be abstracted so simply...) Requires some stuff that went into Core today, so it can't be built just yet. Any objections? Bill From wtogami at redhat.com Wed Feb 9 23:03:38 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 09 Feb 2005 13:03:38 -1000 Subject: new package: aqhbci-qt-tools In-Reply-To: <20050209225950.GD17951@nostromo.devel.redhat.com> References: <20050209225950.GD17951@nostromo.devel.redhat.com> Message-ID: <420A96CA.2010408@redhat.com> Bill Nottingham wrote: > It's a setup widget for HBCI accounts; can be used by > the HBCI support in gnucash, although doesn't really seem > like a Core thing. (If only all the support could be abstracted > so simply...) > > Requires some stuff that went into Core today, so it can't > be built just yet. > > Any objections? Can we import it after CVS is branched for FC-4, or do you intend on pushing that FC4 Core stuff into FC3 Extras too? Warren Togami wtogami at redhat.com From notting at redhat.com Wed Feb 9 23:11:40 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 9 Feb 2005 18:11:40 -0500 Subject: new package: aqhbci-qt-tools In-Reply-To: <420A96CA.2010408@redhat.com> References: <20050209225950.GD17951@nostromo.devel.redhat.com> <420A96CA.2010408@redhat.com> Message-ID: <20050209231140.GA18400@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > Bill Nottingham wrote: > >It's a setup widget for HBCI accounts; can be used by > >the HBCI support in gnucash, although doesn't really seem > >like a Core thing. (If only all the support could be abstracted > >so simply...) > > > >Requires some stuff that went into Core today, so it can't > >be built just yet. > > > >Any objections? > > Can we import it after CVS is branched for FC-4, or do you intend on > pushing that FC4 Core stuff into FC3 Extras too? It will probably go out as a FC3 update. I can wait until after that to import. Bill From ville.skytta at iki.fi Wed Feb 9 23:14:38 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 10 Feb 2005 01:14:38 +0200 Subject: New candidates packages for Extras In-Reply-To: <420A4C7F.3030100@di.uminho.pt> References: <1107968577.3582.21.camel@dhcp83-72.boston.redhat.com> <420A4C7F.3030100@di.uminho.pt> Message-ID: <1107990878.5731.16.camel@bobcat.mine.nu> On Wed, 2005-02-09 at 17:46 +0000, Jose Pedro Oliveira wrote: > - perl-XML-XPath is ready Will import it this week. I don't insist maintaining it though, let me know if you want it. http://bugzilla.fedora.us/show_bug.cgi?id=2356 > - perl-Pod-POM is under QA http://bugzilla.fedora.us/show_bug.cgi?id=1954 (I don't insist maintaining this either.) > - perl-Text-Autoformat may need an update http://bugzilla.fedora.us/show_bug.cgi?id=1354 > - perl-Template Toolkit > Right now fails a test GD test in FC3 > (this module still isn't in the bugzilla but almost every > build requirement is; talk to Ville Skytta for more information) http://cachalot.mine.nu/3/SRPMS.extras/perl-Template-Toolkit-2.14-0.fdr.1.src.rpm IIRC the above perl-XML-XPath and perl-POD-POM are the only TT dependencies missing from Core/Extras. But although I think the TT package is "ready", I haven't submitted it yet due to the failing GD related tests which Jose noted. And once TT is in, it's time for... *drum roll*... Bugzilla! I've 2.16.8 packaged (ugly, but can't really do it very cleanly), I haven't yet updated it to 2.18 because perl-DBD-MySQL in FC3 is too old. http://cachalot.mine.nu/3/SRPMS.extras/bugzilla-2.16.8-0.fdr.1.src.rpm 2.18 has also one new dependency: http://cachalot.mine.nu/3/SRPMS.extras/perl-PatchReader-0.9.5-0.1.src.rpm From tcallawa at redhat.com Wed Feb 9 23:23:34 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 09 Feb 2005 17:23:34 -0600 Subject: new package for review: logjam Message-ID: <1107991414.3664.138.camel@localhost.localdomain> Just imported: logjam Logjam is a gtk2 client for LiveJournal.com. I've been maintaining RPMS for this package since Red Hat Linux 7.3 was the current release. Please review, according to the Interim New Package Process. Thanks, ~spot --- Tom "spot" Callaway LCA, RHCE Red Hat Sales Engineer || Aurora Linux Project Leader "If you are going through hell, keep going." -- Sir Winston Churchill From tcallawa at redhat.com Wed Feb 9 23:32:04 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 09 Feb 2005 17:32:04 -0600 Subject: requesting sponsor for new package: xmms-jess In-Reply-To: <20050209040700.GV11938@angus.ind.WPI.EDU> References: <20050209040700.GV11938@angus.ind.WPI.EDU> Message-ID: <1107991924.3664.148.camel@localhost.localdomain> On Tue, 2005-02-08 at 23:07 -0500, Charles R. Anderson wrote: > I've packaged a visualization plugin for xmms called JESS: > > http://angus.ind.wpi.edu/~cra/fedora/extras/xmms-jess/ > Is anyone interested in sponsoring this for inclusion to Extras? I'll sponsor this. On review, the package looks good. I had one minor issue with its use of LINE_MAX, which conflicts with a header in glibc- headers, throwing a compiler warning, but it is otherwise fine. Do you want me to import this for you? ~spot --- Tom "spot" Callaway LCA, RHCE Red Hat Sales Engineer || Aurora Linux Project Leader "If you are going through hell, keep going." -- Sir Winston Churchill From dgregor at redhat.com Wed Feb 9 23:47:17 2005 From: dgregor at redhat.com (Dennis Gregorovic) Date: Wed, 09 Feb 2005 18:47:17 -0500 Subject: New candidates packages for Extras In-Reply-To: <1107990878.5731.16.camel@bobcat.mine.nu> References: <1107968577.3582.21.camel@dhcp83-72.boston.redhat.com> <420A4C7F.3030100@di.uminho.pt> <1107990878.5731.16.camel@bobcat.mine.nu> Message-ID: <1107992837.5584.9.camel@dhcp83-72.boston.redhat.com> On Thu, 2005-02-10 at 01:14 +0200, Ville Skytt? wrote: > On Wed, 2005-02-09 at 17:46 +0000, Jose Pedro Oliveira wrote: > > > - perl-XML-XPath is ready > > Will import it this week. I don't insist maintaining it though, let me > know if you want it. http://bugzilla.fedora.us/show_bug.cgi?id=2356 > > > - perl-Pod-POM is under QA > > http://bugzilla.fedora.us/show_bug.cgi?id=1954 > (I don't insist maintaining this either.) > > > - perl-Text-Autoformat may need an update > > http://bugzilla.fedora.us/show_bug.cgi?id=1354 > > > - perl-Template Toolkit > > Right now fails a test GD test in FC3 > > (this module still isn't in the bugzilla but almost every > > build requirement is; talk to Ville Skytta for more information) > > http://cachalot.mine.nu/3/SRPMS.extras/perl-Template-Toolkit-2.14-0.fdr.1.src.rpm > > IIRC the above perl-XML-XPath and perl-POD-POM are the only TT > dependencies missing from Core/Extras. But although I think the TT > package is "ready", I haven't submitted it yet due to the failing GD > related tests which Jose noted. > > And once TT is in, it's time for... *drum roll*... Bugzilla! > > I've 2.16.8 packaged (ugly, but can't really do it very cleanly), I > haven't yet updated it to 2.18 because perl-DBD-MySQL in FC3 is too old. > http://cachalot.mine.nu/3/SRPMS.extras/bugzilla-2.16.8-0.fdr.1.src.rpm > 2.18 has also one new dependency: > http://cachalot.mine.nu/3/SRPMS.extras/perl-PatchReader-0.9.5-0.1.src.rpm That's cool about getting Bugzilla and those other packages into Extras. I don't have any particular desire to own any of these, but I can take them if you want. I'll hold off on perl-Test-AutoBuild until you're able to get TT in. -- Dennis Gregorovic -------------- next part -------------- A non-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 wir-sind-cool.org Thu Feb 10 00:16:36 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 10 Feb 2005 01:16:36 +0100 Subject: new package for review: logjam In-Reply-To: <1107991414.3664.138.camel@localhost.localdomain> References: <1107991414.3664.138.camel@localhost.localdomain> Message-ID: <20050210011636.5ce58eab.fedora@wir-sind-cool.org> On Wed, 09 Feb 2005 17:23:34 -0600, Tom 'spot' Callaway wrote: > Just imported: logjam > > Logjam is a gtk2 client for LiveJournal.com. I've been maintaining RPMS > for this package since Red Hat Linux 7.3 was the current release. > > Please review, according to the Interim New Package Process. Had a brief look only: * First of all, rebuild failed for me. Last lines here: make[1]: Leaving directory `/home/misc/tmp/rpm/BUILD/logjam-4.4.0' + /usr/lib/rpm/redhat/find-lang.sh /home/misc/tmp/rpm/tmp/logjam-4.4.0.root logjam No translations found for logjam in /home/misc/tmp/rpm/tmp/logjam-4.4.0.root error: Bad exit status from /home/misc/tmp/rpm/tmp/rpm-tmp.59001 (%install) * Missing build requirement: gettext-devel * Likely missing build requirement: librsvg2-devel It also fails to recognize and use gtkhtml3-devel because it searches for libgtkhtml-3.0.so while FC3 has libgtkhtml-3.1.so : checking for libgtkhtml-3.0... not found checking for librsvg-2.0 > 2.2.3... not found logjam 4.4.0 build configuration: - Using GTK: yes - Using GtkSpell: yes - Using GtkHTML: no - Using librsvg: no - Use docklet ("tray icon"): yes - Using networking backend: curl - Build XMMS helper: yes * "Vendor" and "Packager" are usually left empty and are filled in by the build system. * rpmlint reports a non-standard "Group": X11/Applications http://fedoraproject.org/wiki/RPMGroups * In desktop file, I assume we still use "X-Red-Hat-Extra;" instead of "X-Red-Hat-Base;" -- tags Comment= and GenericName= could be set, especially because the name "Logjam" in the "Internet" menu is very ambiguous. From fedora at wir-sind-cool.org Thu Feb 10 00:32:22 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 10 Feb 2005 01:32:22 +0100 Subject: new package for review: logjam In-Reply-To: <20050210011636.5ce58eab.fedora@wir-sind-cool.org> References: <1107991414.3664.138.camel@localhost.localdomain> <20050210011636.5ce58eab.fedora@wir-sind-cool.org> Message-ID: <20050210013222.4fe5a240.fedora@wir-sind-cool.org> > * In desktop file, I assume we still use "X-Red-Hat-Extra;" instead of > "X-Red-Hat-Base;" -- tags Comment= and GenericName= could be set, > especially because the name "Logjam" in the "Internet" menu is very > ambiguous. X-Fedora even as we've done it at fedora.us at least From toshio at tiki-lounge.com Thu Feb 10 00:40:48 2005 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 09 Feb 2005 19:40:48 -0500 Subject: gstreamer-pythpn build error Message-ID: <1107996049.8636.107.camel@Madison.badger.com> Just took a look at: http://fedoraproject.org/extras/3/build-logs/x86_64/gstreamer-python.log From rom what I can tell, someone checked in an updated spec file but didn't update the lookaside cache with the new software version. Never having used the fedora cvs build system to import stuff, though, I'm not certain I understand how the whole thing works. (Are you supposed to run cvs-import.sh on an SRPM everytime you change what Source and patch files are referenced from a spec?) If someone can glance at the build log and say "that's what it looks like." I'll file it in bugzilla and change the Status Page to reflect that it's an error on both x86 and x86_64. -Toshio -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From moe at blagblagblag.org Thu Feb 10 00:50:20 2005 From: moe at blagblagblag.org (jeff) Date: Wed, 9 Feb 2005 17:50:20 -0700 Subject: RFI: tor Message-ID: <200502091750.20954.moe@blagblagblag.org> I humbly Request For Inclusion the package tor. "Tor: An anonymous Internet communication system Tor is a toolset for a wide range of organizations and people that want to improve their safety and security on the Internet. Using Tor can help you anonymize web browsing and publishing, instant messaging, IRC, SSH, and more. Tor also provides a platform on which software developers can build new applications with built-in anonymity, safety, and privacy features." http://tor.eff.org/ EFF rocks. SRPMS which compile cleanly on FC3 are available @ http://tor.eff.org/dist/rpm/ -Jeff P.S. It's a bit unclear to me whether I should be bugzilling this or not. From fedora at wir-sind-cool.org Thu Feb 10 01:01:45 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 10 Feb 2005 02:01:45 +0100 Subject: gstreamer-pythpn build error In-Reply-To: <1107996049.8636.107.camel@Madison.badger.com> References: <1107996049.8636.107.camel@Madison.badger.com> Message-ID: <20050210020145.26617779.fedora@wir-sind-cool.org> On Wed, 09 Feb 2005 19:40:48 -0500, Toshio wrote: > Just took a look at: > http://fedoraproject.org/extras/3/build-logs/x86_64/gstreamer-python.log > > From rom what I can tell, someone checked in an updated spec file but didn't > update the lookaside cache with the new software version. ack > Never having > used the fedora cvs build system to import stuff, though, I'm not > certain I understand how the whole thing works. (Are you supposed to run > cvs-import.sh on an SRPM everytime you change what Source and patch > files are referenced from a spec?) No. The lookaside cache is not CVS based. It's accessed via "make" targets. And you can also upload individual files independent from a src.rpm import. From toshio at tiki-lounge.com Thu Feb 10 02:03:42 2005 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 09 Feb 2005 21:03:42 -0500 Subject: gstreamer-pythpn build error In-Reply-To: <20050210020145.26617779.fedora@wir-sind-cool.org> References: <1107996049.8636.107.camel@Madison.badger.com> <20050210020145.26617779.fedora@wir-sind-cool.org> Message-ID: <1108001023.8636.115.camel@Madison.badger.com> On Thu, 2005-02-10 at 02:01 +0100, Michael Schwendt wrote: > On Wed, 09 Feb 2005 19:40:48 -0500, Toshio wrote: > > > Just took a look at: > > http://fedoraproject.org/extras/3/build-logs/x86_64/gstreamer-python.log > > > > From rom what I can tell, someone checked in an updated spec file but didn't > > update the lookaside cache with the new software version. > > ack > > > Never having > > used the fedora cvs build system to import stuff, though, I'm not > > certain I understand how the whole thing works. (Are you supposed to run > > cvs-import.sh on an SRPM everytime you change what Source and patch > > files are referenced from a spec?) > > No. The lookaside cache is not CVS based. It's accessed via "make" > targets. And you can also upload individual files independent from a > src.rpm import. Hmmm... The make upload* targets? So I take it some invocation of that would need to be run to sync the Source version in the spec file with the Source version in the cache? -Toshio -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at wir-sind-cool.org Thu Feb 10 02:21:25 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 10 Feb 2005 03:21:25 +0100 Subject: gstreamer-pythpn build error In-Reply-To: <1108001023.8636.115.camel@Madison.badger.com> References: <1107996049.8636.107.camel@Madison.badger.com> <20050210020145.26617779.fedora@wir-sind-cool.org> <1108001023.8636.115.camel@Madison.badger.com> Message-ID: <20050210032125.2efc0f56.fedora@wir-sind-cool.org> On Wed, 09 Feb 2005 21:03:42 -0500, Toshio wrote: > On Thu, 2005-02-10 at 02:01 +0100, Michael Schwendt wrote: > > On Wed, 09 Feb 2005 19:40:48 -0500, Toshio wrote: > > > > > Just took a look at: > > > http://fedoraproject.org/extras/3/build-logs/x86_64/gstreamer-python.log > > > > > > From rom what I can tell, someone checked in an updated spec file but didn't > > > update the lookaside cache with the new software version. > > > > ack > > > > > Never having > > > used the fedora cvs build system to import stuff, though, I'm not > > > certain I understand how the whole thing works. (Are you supposed to run > > > cvs-import.sh on an SRPM everytime you change what Source and patch > > > files are referenced from a spec?) > > > > No. The lookaside cache is not CVS based. It's accessed via "make" > > targets. And you can also upload individual files independent from a > > src.rpm import. > > Hmmm... The make upload* targets? So I take it some invocation of that > would need to be run to sync the Source version in the spec file with > the Source version in the cache? A simple upload: https://www.redhat.com/archives/fedora-extras-list/2005-February/msg00098.html From rc040203 at freenet.de Thu Feb 10 05:00:59 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 10 Feb 2005 06:00:59 +0100 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <20050209224132.428bb629.fedora@wir-sind-cool.org> References: <20050207131917.44e53bb8@python2> <20050209213150.3519b56b@python2> <20050209224132.428bb629.fedora@wir-sind-cool.org> Message-ID: <1108011659.31499.236.camel@mccallum.corsepiu.local> On Wed, 2005-02-09 at 22:41 +0100, Michael Schwendt wrote: > On Wed, 9 Feb 2005 21:31:50 +0100, Matthias Saou wrote: > > > Matthias Saou wrote : > > > > > - starfighter-music > > [...] > > > > Yikes. > > > > "Much ado about nothing" :-) > > > > I started wondering, so I asked... and I was right : > > > > "Aye... The music is already in the pak file. The music is just there as a > > seperate download because a lot of people requested access to the music > > files > > since they wanted to listen to them seperately ;)" > > > > Sooo... basically the separate package it totally irrelevant (that's what I > > get for never playing the game with sound on!), but things did get cleared > > up regarding the license of the included music files. Should this be > > reflected in the "License:" tag of the package? Or does "public domain" > > mean that these files can be reused in any proprietary or free software, > > thus relicensed just about any way one wants? > > That's a question for lawyers, whether somebody also waives all his rights > in the composition (melody, accompany and such details) when he releases > music into the public domain. It is my understanding that work released > into the public domain is not even copyrighted. No. This is a matter of applicable law, in particular national laws. What you say, to my knowledge probably is true in the US, but it definitely is not true in certain countries, e.g. Germany. In Germany, you can not give up any copyright nor assign any copyright to anybody on any "creative work" (this applies to musical compositions, recordings/performance/arrangements of music as well as to SW). I.e. even if you did not explicitly put a "Copyright (c)" notice on such a piece of work it will be copyrighted by you. In Germany, all you only can do is to give away "licenses to the public", and "express your will not to enforce unauthorized copying/modifications", but you can not give up any copyright. Ralf From tcallawa at redhat.com Thu Feb 10 05:34:48 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 09 Feb 2005 23:34:48 -0600 Subject: new package for review: logjam In-Reply-To: <20050210011636.5ce58eab.fedora@wir-sind-cool.org> References: <1107991414.3664.138.camel@localhost.localdomain> <20050210011636.5ce58eab.fedora@wir-sind-cool.org> Message-ID: <1108013688.3664.163.camel@localhost.localdomain> On Thu, 2005-02-10 at 01:16 +0100, Michael Schwendt wrote: > On Wed, 09 Feb 2005 17:23:34 -0600, Tom 'spot' Callaway wrote: > > > Just imported: logjam > > > > Logjam is a gtk2 client for LiveJournal.com. I've been maintaining RPMS > > for this package since Red Hat Linux 7.3 was the current release. > > > > Please review, according to the Interim New Package Process. > > Had a brief look only: > > * First of all, rebuild failed for me. Last lines here: > > make[1]: Leaving directory `/home/misc/tmp/rpm/BUILD/logjam-4.4.0' > + /usr/lib/rpm/redhat/find-lang.sh /home/misc/tmp/rpm/tmp/logjam-4.4.0.root logjam > No translations found for logjam in /home/misc/tmp/rpm/tmp/logjam-4.4.0.root > error: Bad exit status from /home/misc/tmp/rpm/tmp/rpm-tmp.59001 (%install) I can't reproduce this one... can you checkout the latest and try again? Everything else I fixed, here's the changelog: - use make, not %__make - no need to export CFLAGS first - BuildRequires aspell-devel, desktop-file-utils - change PreReq to Requires - delete $RPM_BUILD_ROOT first - use desktop-file-install to install logjam.desktop - nuke Vendor and Packager lines - add patch to look for gtkhtml3.1 - modify logjam.desktop to refer to X-Fedora-Extras - add Comment and GenericName to logjam.desktop - change Group to User Interface/Desktops ~spot --- Tom "spot" Callaway LCA, RHCE Red Hat Sales Engineer || Aurora Linux Project Leader "If you are going through hell, keep going." -- Sir Winston Churchill From wtogami at redhat.com Thu Feb 10 05:54:24 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 09 Feb 2005 19:54:24 -1000 Subject: new package for review: logjam In-Reply-To: <1108013688.3664.163.camel@localhost.localdomain> References: <1107991414.3664.138.camel@localhost.localdomain> <20050210011636.5ce58eab.fedora@wir-sind-cool.org> <1108013688.3664.163.camel@localhost.localdomain> Message-ID: <420AF710.2070305@redhat.com> Tom 'spot' Callaway wrote: >> >>make[1]: Leaving directory `/home/misc/tmp/rpm/BUILD/logjam-4.4.0' >>+ /usr/lib/rpm/redhat/find-lang.sh /home/misc/tmp/rpm/tmp/logjam-4.4.0.root logjam >>No translations found for logjam in /home/misc/tmp/rpm/tmp/logjam-4.4.0.root >>error: Bad exit status from /home/misc/tmp/rpm/tmp/rpm-tmp.59001 (%install) > > > I can't reproduce this one... can you checkout the latest and try again? > If it was translations, that error might have been due to the lack of gettext* in the buildroot. Or (less likely in this case) a Makefile race. Consider adding "%_smp_mflags -j3" to your .rpmmacros, which sometimes exposes Makefile races even on uniprocessor build machines. Everyone that does packaging should do this, in order to avoid a surprise failure on a SMP build system. Warren Togami wtogami at redhat.com From tcallawa at redhat.com Thu Feb 10 05:53:39 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 09 Feb 2005 23:53:39 -0600 Subject: new package for review: logjam In-Reply-To: <420AF710.2070305@redhat.com> References: <1107991414.3664.138.camel@localhost.localdomain> <20050210011636.5ce58eab.fedora@wir-sind-cool.org> <1108013688.3664.163.camel@localhost.localdomain> <420AF710.2070305@redhat.com> Message-ID: <1108014819.3664.169.camel@localhost.localdomain> On Wed, 2005-02-09 at 19:54 -1000, Warren Togami wrote: > Consider adding "%_smp_mflags -j3" to your .rpmmacros, which sometimes > exposes Makefile races even on uniprocessor build machines. Everyone > that does packaging should do this, in order to avoid a surprise failure > on a SMP build system. Warren, do you have a good .rpmmacros file that I could use as a reference? ~spot --- Tom "spot" Callaway LCA, RHCE Red Hat Sales Engineer || Aurora Linux Project Leader "If you are going through hell, keep going." -- Sir Winston Churchill From wtogami at redhat.com Thu Feb 10 06:02:28 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 09 Feb 2005 20:02:28 -1000 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <1108011659.31499.236.camel@mccallum.corsepiu.local> References: <20050207131917.44e53bb8@python2> <20050209213150.3519b56b@python2> <20050209224132.428bb629.fedora@wir-sind-cool.org> <1108011659.31499.236.camel@mccallum.corsepiu.local> Message-ID: <420AF8F4.3010604@redhat.com> Ralf Corsepius wrote: > > I.e. even if you did not explicitly put a "Copyright (c)" notice on such > a piece of work it will be copyrighted by you. In Germany, all you only > can do is to give away "licenses to the public", and "express your will > not to enforce unauthorized copying/modifications", but you can not give > up any copyright. > You are correct, except I think it was the Berne Convention (along with the past 2 or 3 copyright acts in the USA) that made registration of copyrights in America optional. If you write anything in America, it is automatically protected by copyright even if you don't explicitly include a copyright notice. But it does help to have one, and register the copyright to be able to prove ownership and possibly enforce it. Anyhow, my only point is that it is supposed to be a global standard of minimally 50 years without necessary notice or registration. That isn't limited to just Germany. http://www.free-culture.cc/ (I read about this in Lawrence Lessig's book here. Highly recommend reading this book, although it isn't about Open Source, it is about similar ethical ideals of how "Big Media Uses Technology and the Law to Lock Down Culture and Control Creativity".) Warren Togami wtogami at redhat.com From wtogami at redhat.com Thu Feb 10 06:08:04 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 09 Feb 2005 20:08:04 -1000 Subject: new package for review: logjam In-Reply-To: <1108014819.3664.169.camel@localhost.localdomain> References: <1107991414.3664.138.camel@localhost.localdomain> <20050210011636.5ce58eab.fedora@wir-sind-cool.org> <1108013688.3664.163.camel@localhost.localdomain> <420AF710.2070305@redhat.com> <1108014819.3664.169.camel@localhost.localdomain> Message-ID: <420AFA44.7050308@redhat.com> Tom 'spot' Callaway wrote: > On Wed, 2005-02-09 at 19:54 -1000, Warren Togami wrote: > > >>Consider adding "%_smp_mflags -j3" to your .rpmmacros, which sometimes >>exposes Makefile races even on uniprocessor build machines. Everyone >>that does packaging should do this, in order to avoid a surprise failure >>on a SMP build system. > > > Warren, do you have a good .rpmmacros file that I could use as a > reference? > Install fedora-rpmdevtools from Extras, then use fedora-buildrpmtree. That creates a ~/.rpmmacros file for your non-root user along with non-root build tree in ~/rpmbuild. [builder5 at ibmlaptop ~]$ cat .rpmmacros %_topdir %(echo $HOME)/rpmbuild %_smp_mflags -j3 %__arch_install_post /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot fedora-rpmdevtools contains those two extra build checks, which causes a build failure if you have bad RPATH or buildroot traces in your package payload. It is good to force these problems to be fixed. Warren Togami wtogami at redhat.com From tcallawa at redhat.com Thu Feb 10 06:45:33 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 10 Feb 2005 00:45:33 -0600 Subject: new package for review: logjam In-Reply-To: <420AFA44.7050308@redhat.com> References: <1107991414.3664.138.camel@localhost.localdomain> <20050210011636.5ce58eab.fedora@wir-sind-cool.org> <1108013688.3664.163.camel@localhost.localdomain> <420AF710.2070305@redhat.com> <1108014819.3664.169.camel@localhost.localdomain> <420AFA44.7050308@redhat.com> Message-ID: <1108017933.3664.172.camel@localhost.localdomain> On Wed, 2005-02-09 at 20:08 -1000, Warren Togami wrote: > Tom 'spot' Callaway wrote: > > On Wed, 2005-02-09 at 19:54 -1000, Warren Togami wrote: > > > > > >>Consider adding "%_smp_mflags -j3" to your .rpmmacros, which sometimes > >>exposes Makefile races even on uniprocessor build machines. Everyone > >>that does packaging should do this, in order to avoid a surprise failure > >>on a SMP build system. Sneaking back on topic, with -j3, it still builds for me. I suspect the missing gettext in the buildroot was what caused the translation error. ~spot --- Tom "spot" Callaway LCA, RHCE Red Hat Sales Engineer || Aurora Linux Project Leader "If you are going through hell, keep going." -- Sir Winston Churchill From skvidal at fedoraproject.org Thu Feb 10 07:26:54 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 10 Feb 2005 02:26:54 -0500 Subject: Fedora Extras - New/Updated Packages Message-ID: <1108020414.4617.64.camel@cutter> Hi All, New stuff fedora-rpmdevtools (i386, x86_64) imlib2 (i386, x86_64) pyzor (i386, x86_64) tpb (i386, x86_64) tla (i386, x86_64) torcs (i386) Status page: http://fedoraproject.org/wiki/Extras_2fFC3Status Follow updates and new packages at: http://fedoraproject.org/infofeed/ Report problems at Bugzilla: http://bugzilla.redhat.com/ thanks, -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 10 09:45:18 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 10 Feb 2005 10:45:18 +0100 Subject: new package for review: logjam In-Reply-To: <1108017933.3664.172.camel@localhost.localdomain> References: <1107991414.3664.138.camel@localhost.localdomain> <20050210011636.5ce58eab.fedora@wir-sind-cool.org> <1108013688.3664.163.camel@localhost.localdomain> <420AF710.2070305@redhat.com> <1108014819.3664.169.camel@localhost.localdomain> <420AFA44.7050308@redhat.com> <1108017933.3664.172.camel@localhost.localdomain> Message-ID: <20050210104518.56784b8b@python2> Tom 'spot' Callaway wrote : > On Wed, 2005-02-09 at 20:08 -1000, Warren Togami wrote: > > Tom 'spot' Callaway wrote: > > > On Wed, 2005-02-09 at 19:54 -1000, Warren Togami wrote: > > > > > > > > >>Consider adding "%_smp_mflags -j3" to your .rpmmacros, which sometimes > > >>exposes Makefile races even on uniprocessor build machines. Everyone > > >>that does packaging should do this, in order to avoid a surprise failure > > >>on a SMP build system. > > Sneaking back on topic, with -j3, it still builds for me. I suspect the > missing gettext in the buildroot was what caused the translation error. Yup. And Michael pointed that out in his first review mail : gettext-devel is most certainly the guilty one, and you'll need to add it to BuildRequires (as he wrote). Note that for RH/RHEL or FC < 3, it's "gettext" and not "gettext-devel" since the split happened very recently. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.01 0.16 0.18 From gauret at free.fr Thu Feb 10 10:22:11 2005 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 10 Feb 2005 11:22:11 +0100 Subject: Fedora Extras CVS Howto somewhere ? Message-ID: Hi, Is there some kind of "Fedora Extras CVS Howto" anywhere ? I've read the Makefile.common and cvs-import.sh, but I still can't figure out the correct way to update a package in CVS. I've updated the spec file, and now what should I do ? Is a "make upload FILES=newtarball.tar.gz && cvs ci" enough ? Thanks, Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "Never trust a computer you can't throw out a window." -- Steve Wozniak From svenwahl at web.de Thu Feb 10 11:07:44 2005 From: svenwahl at web.de (Sven Wahl) Date: Thu, 10 Feb 2005 12:07:44 +0100 Subject: fedora-meld.desktop: MimeType=x-directory/normal? Message-ID: <1108033664.4900.49.camel@lux.homenetwork> Hi I updated meld from version 0.9.4.1-3 to 0.9.5-1 using Fedora Extras yesterday. The new .desktop-file fedora-meld.desktop that comes with meld-0.9.5-1.noarch.rpm contains the following line: MimeType=x-directory/normal; This set the file association for directories to meld. So, whenever I'm browsing my file system with Nautilus now, Gnome tries to open directories with the Meld-Diff Viewer. Is this an intended feature or is it a bug? Regards, Sven From rc040203 at freenet.de Thu Feb 10 12:18:53 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 10 Feb 2005 13:18:53 +0100 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <420AF8F4.3010604@redhat.com> References: <20050207131917.44e53bb8@python2> <20050209213150.3519b56b@python2> <20050209224132.428bb629.fedora@wir-sind-cool.org> <1108011659.31499.236.camel@mccallum.corsepiu.local> <420AF8F4.3010604@redhat.com> Message-ID: <1108037934.31499.267.camel@mccallum.corsepiu.local> On Wed, 2005-02-09 at 20:02 -1000, Warren Togami wrote: > Ralf Corsepius wrote: > > > > I.e. even if you did not explicitly put a "Copyright (c)" notice on such > > a piece of work it will be copyrighted by you. In Germany, all you only > > can do is to give away "licenses to the public", and "express your will > > not to enforce unauthorized copying/modifications", but you can not give > > up any copyright. > > > > You are correct, except I think it was the Berne Convention (along with > the past 2 or 3 copyright acts in the USA) that made registration of > copyrights in America optional. If you write anything in America, it is > automatically protected by copyright even if you don't explicitly > include a copyright notice. But it does help to have one, and register > the copyright to be able to prove ownership and possibly enforce it. > > Anyhow, my only point is that it is supposed to be a global standard of > minimally 50 years without necessary notice or registration. That isn't > limited to just Germany. :) What I outlined above ("Freedom of Arts") is part of Germany's constitution ("Grundgesetz"). I guess you can imagine the impact of this on "Copyright assignments", like those RH wants to apply to Fedora Extras contributions and those the FSF uses for SW they "own". According to German laws, these "assignments" - in best case - are bilateral "contracts"/"license agreements" or "expressions of will". In "worst case" they are "just void", because a court could judge such assignments as "immoral" and therefore the whole "contract" to be invalid. AFAICT, none of these has ever been challenged at a German court, but I would not bet on the result. The crucial points probably would be "whether the piece of work qualifies as 'free, substantial, creative work'" and on whether "a 'German court' is in charge at all". As far as pieces of music are concerned, I would not distribute any of them unless their ownership is 100% bullet proof. In best case, not before having received a written permission to ship them. Ralf From skvidal at phy.duke.edu Thu Feb 10 13:09:55 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 10 Feb 2005 08:09:55 -0500 Subject: Fedora Extras CVS Howto somewhere ? In-Reply-To: References: Message-ID: <1108040995.8233.10.camel@cutter> On Thu, 2005-02-10 at 11:22 +0100, Aurelien Bompard wrote: > Hi, > > Is there some kind of "Fedora Extras CVS Howto" anywhere ? I've read the > Makefile.common and cvs-import.sh, but I still can't figure out the correct > way to update a package in CVS. I've updated the spec file, and now what > should I do ? Is a "make upload FILES=newtarball.tar.gz && cvs ci" enough ? > No, there isn't one - but if you want to put up questions you have maybe we can assemble a howto at: http://fedoraproject.org/wiki/Extras as we go -sv From gauret at free.fr Thu Feb 10 13:59:12 2005 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 10 Feb 2005 14:59:12 +0100 Subject: Fedora Extras CVS Howto somewhere ? References: <1108040995.8233.10.camel@cutter> Message-ID: seth vidal wrote: > No, there isn't one - but if you want to put up questions you have maybe > we can assemble a howto at: > http://fedoraproject.org/wiki/Extras as we go OK. Please allow my account, "AurelienBompard" to edit pages in the wiki. Thanks, Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in: we're computer professionals. We cause accidents." -- Nathaniel Borenstein From fedora at wir-sind-cool.org Thu Feb 10 14:23:44 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 10 Feb 2005 15:23:44 +0100 Subject: new package for review: logjam In-Reply-To: <20050210104518.56784b8b@python2> References: <1107991414.3664.138.camel@localhost.localdomain> <20050210011636.5ce58eab.fedora@wir-sind-cool.org> <1108013688.3664.163.camel@localhost.localdomain> <420AF710.2070305@redhat.com> <1108014819.3664.169.camel@localhost.localdomain> <420AFA44.7050308@redhat.com> <1108017933.3664.172.camel@localhost.localdomain> <20050210104518.56784b8b@python2> Message-ID: <20050210152344.41e6288a.fedora@wir-sind-cool.org> On Thu, 10 Feb 2005 10:45:18 +0100, Matthias Saou wrote: > Tom 'spot' Callaway wrote : > > > On Wed, 2005-02-09 at 20:08 -1000, Warren Togami wrote: > > > Tom 'spot' Callaway wrote: > > > > On Wed, 2005-02-09 at 19:54 -1000, Warren Togami wrote: > > > > > > > > > > > >>Consider adding "%_smp_mflags -j3" to your .rpmmacros, which > sometimes > > > >>exposes Makefile races even on uniprocessor build machines. Everyone > > > > >>that does packaging should do this, in order to avoid a surprise > failure > > > >>on a SMP build system. > > > > Sneaking back on topic, with -j3, it still builds for me. I suspect the > > missing gettext in the buildroot was what caused the translation error. > > Yup. And Michael pointed that out in his first review mail : gettext-devel > is most certainly the guilty one, and you'll need to add it to > BuildRequires (as he wrote). Note that for RH/RHEL or FC < 3, it's > "gettext" and not "gettext-devel" since the split happened very recently. Yes, and it is really just needed for building. The added explicit dependency on gettext is not correct, and the other dependencies on gtk2, xmms, gtkhtml3, librsvg2 are redundant, not needed, and would only require unnecessary rebuilds if a library were moved into a package with a different name. 'rpm -qR logjam' shows the automatic dependencies on the libraries already. Also, Tom mentioned "requested cleanups" in his cvs commit. The following added line is not cleanup, but bad habit, in particular since a good buildroot is set at the top of the spec file already. It should simple become 'rm -rf $RPM_BUILD_ROOT' here: %install +[ -n "$RPM_BUILD_ROOT" -a "$RPM_BUILD_ROOT" != / ] && rm -rf $RPM_BUILD_ROOT Rest of the packaging appears good and not unusual. As I don't run a blog, I won't comment on the run-time behaviour. From skvidal at phy.duke.edu Thu Feb 10 15:00:46 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 10 Feb 2005 10:00:46 -0500 Subject: Fedora Extras CVS Howto somewhere ? In-Reply-To: References: <1108040995.8233.10.camel@cutter> Message-ID: <1108047647.25835.2.camel@opus.phy.duke.edu> On Thu, 2005-02-10 at 14:59 +0100, Aurelien Bompard wrote: > seth vidal wrote: > > No, there isn't one - but if you want to put up questions you have maybe > > we can assemble a howto at: > > http://fedoraproject.org/wiki/Extras as we go > > OK. Please allow my account, "AurelienBompard" to edit pages in the wiki. > done. -sv From nphilipp at redhat.com Thu Feb 10 15:26:13 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 10 Feb 2005 16:26:13 +0100 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <20050207135420.773a2b08.fedora@wir-sind-cool.org> References: <20050207131917.44e53bb8@python2> <20050207135420.773a2b08.fedora@wir-sind-cool.org> Message-ID: <1108049173.28783.20.camel@wombat.tiptoe.de> On Mon, 2005-02-07 at 13:54 +0100, Michael Schwendt wrote: > On Mon, 7 Feb 2005 13:19:17 +0100, Matthias Saou wrote: > > > Here are packages I'd like to add to Extras : > > > - starfighter-music : My current starfighter package doesn't bundle the > > musics, as they are in a separate zip file and aren't necessarily updated > > at the same time as the main game (i.e. game is at 1.1 and music 1.0 > > currenty). One question about this is whether to make the main package > > require the music one for everyone to get the complete gaming experience > > (I'd favour this) or to let people optionally install the musics > > themselves. > > > > If I understood Warren's last process proposal : > > - I need someone (besides myself) to sponsor my package (?). > > - There needs to be no legal/licensing problems (*). > > - Nobody must oppose a veto. > > > > They should all comply with "best practices", and I'll announce to the > > commits list if/once approved. > > > > (*) : The starfighter-music zip doesn't contain any license information. > > But I assume that it is covered by the same one as the main program (GNU > > GPL) since it seems to be split apart only for practical reasons. Should I > > add a copy of the GNU GPL to the package nevertheless? Is having it depend > > on the main package which contains the license details enough? > > One thing for sure, the music zip package is not GPL'ed, because the > composers did not release their music as GPL. Included in the zip are 13 > MOD files (Protracker or equivalent) and 1 S3M file (Scream Tracker). The > credits within the files indicate that they were not made specifically for > Starfighter, but were taken from the public domain and made in 1993 to > 1996. Usually, MOD files which were not published by their composers > directly, were ripped from PC/Amiga demos or music demo shows and then > released in the public domain without prior written consent by their > authors. If not ripped from commercial games, the composer usually have > nothing against their music being used in other "free" (here as in free > beer) software. > > This package is at most "License: Public Domain", but not GPL. This would indeed be the case if and only if the original authors explicitly state that their work is in the Public Domain which would probably be taken as a similar statement without waiver of copyright in countries like Germany (but IANAL). Do we really have statements to that effect from the original authors? The music having been downloaded from "Public Domain" (quotes intentional) BBSs, CDs, ... does not automatically mean that the work is in fact Public Domain, it could be anything between that and freeware without permission to use commercially, etc. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From fedora at wir-sind-cool.org Thu Feb 10 15:14:32 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 10 Feb 2005 16:14:32 +0100 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <1108037934.31499.267.camel@mccallum.corsepiu.local> References: <20050207131917.44e53bb8@python2> <20050209213150.3519b56b@python2> <20050209224132.428bb629.fedora@wir-sind-cool.org> <1108011659.31499.236.camel@mccallum.corsepiu.local> <420AF8F4.3010604@redhat.com> <1108037934.31499.267.camel@mccallum.corsepiu.local> Message-ID: <20050210161432.22340d04.fedora@wir-sind-cool.org> On Thu, 10 Feb 2005 13:18:53 +0100, Ralf Corsepius wrote: > As far as pieces of music are concerned, I would not distribute any of > them unless their ownership is 100% bullet proof. In best case, not > before having received a written permission to ship them. Even written permission is void in case the music covers another piece of music by a different composer. Don't be surprised if you got written permission for redistribution and later find out he unintentionally and subconsciously covered (and hence copied) a piece of music on the CD he had listened to three months ago. Even if nobody complains, what to do? In the case of these MOD files, it's very unlikely that you will be able to track down their creators (four or five) as they didn't enter a lot of contact information into the instrument headers as much as other musicians did. The use of pseudonyms and "demo scene" group names, the appearance of terms like "BBS" and "music disk", are enough reason to believe that the files appeared in the public domain. Many hobby musicians from that area are more than happy to see their music being spread widely and reused in other free productions. It has happened occasionally that great demo music was used in a commercial game without prior consent by the musician, and he received no compensation, maybe was not even mentioned in the game's credits. Musicians know that can happen, when they don't try to protect their rights from the start. Production and distribution of music is not Fedora Extras' area of activity. It's not as if we try to enter the Top 50 charts with these musics (like it was done with "Zombie Nation - Kernkraft 400" in 1999 with a melody ripped off from an ancient Commodore 64 game without prior consent). Comments on other forms of art, e.g. pictures, fonts or other graphics in games, anyone? ;o) -- Fedora Core release 3 (Heidelberg) - Linux 2.6.10-1.762_FC3 loadavg: 0.06 0.29 0.23 From fedora at wir-sind-cool.org Thu Feb 10 14:00:15 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 10 Feb 2005 15:00:15 +0100 Subject: Fedora Extras CVS Howto somewhere ? In-Reply-To: References: Message-ID: <20050210150015.798d2fcd.fedora@wir-sind-cool.org> On Thu, 10 Feb 2005 11:22:11 +0100, Aurelien Bompard wrote: > Hi, > > Is there some kind of "Fedora Extras CVS Howto" anywhere ? I've read the > Makefile.common and cvs-import.sh, but I still can't figure out the correct > way to update a package in CVS. I've updated the spec file, and now what > should I do ? Is a "make upload FILES=newtarball.tar.gz && cvs ci" enough ? For uploads and complete src.rpm auto-imports: https://www.redhat.com/archives/fedora-extras-list/2005-February/msg00098.html You either prepare your update package outside CVS and then cvs-import.sh it automatically and your done. Or you prepare your changes in your CVS working copy, upload new binaries into the lookaside cache, and at the end commit every changed file including the 'sources' file. As a test whether the full commit was fine, enter a different directory and checkout a fresh working copy there. It should succeed in fetching the binaries from lookaside cache and also pass simple build tests such as 'make i386' or 'make srpm' at least. From gauret at free.fr Thu Feb 10 15:48:34 2005 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 10 Feb 2005 16:48:34 +0100 Subject: Fedora Extras CVS Howto somewhere ? References: <1108040995.8233.10.camel@cutter> <1108047647.25835.2.camel@opus.phy.duke.edu> Message-ID: Allright, I've added my two questions to this page. I've also added what I think are the right answers, so please fix the page if I was wrong. http://fedoraproject.org/wiki/Extras_2fUsingCvsFaq Thanks, Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "Make everything as simple as possible, but not simpler." -- Albert Einstein From nphilipp at redhat.com Thu Feb 10 16:07:26 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 10 Feb 2005 17:07:26 +0100 Subject: Artwork, was: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <20050210161432.22340d04.fedora@wir-sind-cool.org> References: <20050207131917.44e53bb8@python2> <20050209213150.3519b56b@python2> <20050209224132.428bb629.fedora@wir-sind-cool.org> <1108011659.31499.236.camel@mccallum.corsepiu.local> <420AF8F4.3010604@redhat.com> <1108037934.31499.267.camel@mccallum.corsepiu.local> <20050210161432.22340d04.fedora@wir-sind-cool.org> Message-ID: <1108051646.28783.28.camel@wombat.tiptoe.de> On Thu, 2005-02-10 at 16:14 +0100, Michael Schwendt wrote: > Comments on other forms of art, e.g. pictures, fonts or other graphics in > games, anyone? ;o) Well I was about to start something about non-free (or dubiously licensed) stuff in torcs-data, but I've seen that this has already been resolved in CVS with the newer version 1.2.3 stuff. Besides, it might make sense to move non-free (as in speech) artwork to livna as long as it is distributable and the copyright situation is clear. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From aaron.bennett at olin.edu Thu Feb 10 16:15:14 2005 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Thu, 10 Feb 2005 11:15:14 -0500 Subject: Fedora Extras CVS Howto somewhere ? In-Reply-To: <20050210150015.798d2fcd.fedora@wir-sind-cool.org> References: <20050210150015.798d2fcd.fedora@wir-sind-cool.org> Message-ID: <420B8892.1090606@olin.edu> Michael Schwendt wrote: >>Hi, >> >>Is there some kind of "Fedora Extras CVS Howto" anywhere ? I've read the >>Makefile.common and cvs-import.sh, but I still can't figure out the correct >>way to update a package in CVS. I've updated the spec file, and now what >>should I do ? Is a "make upload FILES=newtarball.tar.gz && cvs ci" enough ? >> >> > >For uploads and complete src.rpm auto-imports: > https://www.redhat.com/archives/fedora-extras-list/2005-February/msg00098.html > >You either prepare your update package outside CVS and then cvs-import.sh >it automatically and your done. Or you prepare your changes in your CVS >working copy, upload new binaries into the lookaside cache, and at the >end commit every changed file including the 'sources' file. > >As a test whether the full commit was fine, enter a different directory >and checkout a fresh working copy there. It should succeed in fetching the >binaries from lookaside cache and also pass simple build tests such as >'make i386' or 'make srpm' at least. > > I'd add this to the wikpage, but I don't have edit access. Can you allow "AaronBennett" to edit the wiki as well? -- Aaron Bennett UNIX Administrator Franklin W. Olin College of Engineering From gauret at free.fr Thu Feb 10 16:47:09 2005 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 10 Feb 2005 17:47:09 +0100 Subject: Fedora Extras CVS Howto somewhere ? References: <20050210150015.798d2fcd.fedora@wir-sind-cool.org> Message-ID: Michael Schwendt wrote: > Or you prepare your changes in your CVS > working copy, upload new binaries into the lookaside cache, and at the > end commit every changed file including the 'sources' file. OK. To upload the tarballs to the lookaside cache, should I use "make upload" or "make new-sources" ? Thanks for the info Aur?lien, who is overly precaucious with his brand-new cvs account :) -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info If one keeps trying, one successes eventually. Therefore, the more one fails, the closer one is to success. -- Shadok moto. From joy_friendship2u at yahoo.co.uk Thu Feb 10 16:57:16 2005 From: joy_friendship2u at yahoo.co.uk (joyabrata ghosh) Date: Thu, 10 Feb 2005 16:57:16 +0000 (GMT) Subject: unsubscription request Message-ID: <20050210165716.59105.qmail@web25806.mail.ukl.yahoo.com> hi , plz unsubscribe me from mailing list. ===== JOYABRATA ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com From fedora at wir-sind-cool.org Thu Feb 10 18:09:53 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 10 Feb 2005 19:09:53 +0100 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <1108049173.28783.20.camel@wombat.tiptoe.de> References: <20050207131917.44e53bb8@python2> <20050207135420.773a2b08.fedora@wir-sind-cool.org> <1108049173.28783.20.camel@wombat.tiptoe.de> Message-ID: <20050210190953.7e156b14.fedora@wir-sind-cool.org> On Thu, 10 Feb 2005 16:26:13 +0100, Nils Philippsen wrote: > On Mon, 2005-02-07 at 13:54 +0100, Michael Schwendt wrote: > > On Mon, 7 Feb 2005 13:19:17 +0100, Matthias Saou wrote: > > > > > Here are packages I'd like to add to Extras : > > > > > - starfighter-music : My current starfighter package doesn't bundle the > > > musics, as they are in a separate zip file and aren't necessarily updated > > > at the same time as the main game (i.e. game is at 1.1 and music 1.0 > > > currenty). One question about this is whether to make the main package > > > require the music one for everyone to get the complete gaming experience > > > (I'd favour this) or to let people optionally install the musics > > > themselves. > > > > > > If I understood Warren's last process proposal : > > > - I need someone (besides myself) to sponsor my package (?). > > > - There needs to be no legal/licensing problems (*). > > > - Nobody must oppose a veto. > > > > > > They should all comply with "best practices", and I'll announce to the > > > commits list if/once approved. > > > > > > (*) : The starfighter-music zip doesn't contain any license information. > > > But I assume that it is covered by the same one as the main program (GNU > > > GPL) since it seems to be split apart only for practical reasons. Should I > > > add a copy of the GNU GPL to the package nevertheless? Is having it depend > > > on the main package which contains the license details enough? > > > > One thing for sure, the music zip package is not GPL'ed, because the > > composers did not release their music as GPL. Included in the zip are 13 > > MOD files (Protracker or equivalent) and 1 S3M file (Scream Tracker). The > > credits within the files indicate that they were not made specifically for > > Starfighter, but were taken from the public domain and made in 1993 to > > 1996. Usually, MOD files which were not published by their composers > > directly, were ripped from PC/Amiga demos or music demo shows and then > > released in the public domain without prior written consent by their > > authors. If not ripped from commercial games, the composer usually have > > nothing against their music being used in other "free" (here as in free > > beer) software. > > > > This package is at most "License: Public Domain", but not GPL. > > This would indeed be the case if and only if the original authors > explicitly state that their work is in the Public Domain which would > probably be taken as a similar statement without waiver of copyright in > countries like Germany (but IANAL). Do we really have statements to that > effect from the original authors? Let me ask a different question, please, since the discussion leads to nowhere so far. We need solutions. Decisions. There are other games which include lots of music and graphics (e.g. the Wesnoth developers even have been asked to modify some graphics), which we would need to treat similarly. As Matthias found, the same music files as included within the separate .zip archive are also included in the main source tarball wrapped into a binary .pak file together with sound effect WAV files. That tarball is shipped with a copy of the GPL. The music files' filenames are hardcoded in the source code. If the files had been coverted into .ogg format by the Starfighter developers to escape from having to use a MOD playing library -- if need be, I can expand on why that can be a problem -- all information about their origin would be lost (the original instrument headers in the MOD format were abused to replace file names with other text strings; the format has no other place where to include copyright/licence information). So, here's the question: Generally, how do we treat FOSS packages which include binary music files or graphics and which don't cover that artwork with any special purpose licence? Such as: * The Open Source Music License (OSML) http://www.rootrecords.org/licenses.html * Free Art License http://artlibre.org/licence.php/lalgb.html > The music having been downloaded from "Public Domain" (quotes > intentional) BBSs, CDs, ... does not automatically mean that the work is > in fact Public Domain, it could be anything between that and freeware > without permission to use commercially, etc. Freeware and Public Domain Software are two different things. We can argue endlessly. I don't care where the music files were downloaded from. I don't care whether "Public Domain" BBSs or download servers also carry freeware, shareware and other forms of software and misguide their users with that mixture. The important bit is how this music was released originally. Amiga demo software, music demos, individual pieces of mod music usually were either released into the public domain implicitly or explicitly marked as something else. In the public domain, to be used by other people however they like (even commercially, BBS download fees as the least form). Many musicians did do music, which was never used inside a program. Programmed in assembler languages, you could reuse published software not as trivially as music and graphics files. Hence [good] music was reused much more often and spread much more, too. MOD files are source files. High-profile musicians with special interests usually did not publish their music before a corresponding program (e.g. a music demo disk) was released and used the music exclusively for some time. Those musicians who wanted their music not being spread freely, usually made it clear inside the files and asked programmers to protect the music data at least a bit. The only uncertainty with the Starfighter musics is their origin. Maybe they were taken from a freeware demo program and were not considered public domain work originally. I don't want to decide whether approximately 10 years ago a musician did not care what other people might do with his music. Unless it's explicitly written anywhere that a MOD music file from the home computer area shall not be seen as public domain work, I treat such files as PD. http://www.bellevuelinux.org/publicdomain.html As comparison, the Debian people highlight "13 different music tracks": ;) http://packages.debian.org/testing/games/starfighter -- Fedora Core release 3 (Heidelberg) - Linux 2.6.10-1.762_FC3 loadavg: 1.01 1.07 1.08 From fedora at wir-sind-cool.org Thu Feb 10 18:11:30 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 10 Feb 2005 19:11:30 +0100 Subject: Fedora Extras CVS Howto somewhere ? In-Reply-To: References: <20050210150015.798d2fcd.fedora@wir-sind-cool.org> Message-ID: <20050210191130.1000ea2c.fedora@wir-sind-cool.org> On Thu, 10 Feb 2005 17:47:09 +0100, Aurelien Bompard wrote: > Michael Schwendt wrote: > > Or you prepare your changes in your CVS > > working copy, upload new binaries into the lookaside cache, and at the > > end commit every changed file including the 'sources' file. > > OK. To upload the tarballs to the lookaside cache, should I use "make > upload" or "make new-sources" ? > > Thanks for the info > > Aur?lien, who is overly precaucious with his brand-new cvs account :) As explained in the linked archive mail. "make new-sources" to upload and create a new 'sources' file. "make upload" to upload and append to the existing sources file. -- Fedora Core release 3 (Heidelberg) - Linux 2.6.10-1.762_FC3 loadavg: 1.39 1.13 1.03 From fedora at wir-sind-cool.org Thu Feb 10 16:30:45 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 10 Feb 2005 17:30:45 +0100 Subject: Fedora Extras CVS Howto somewhere ? In-Reply-To: <420B8892.1090606@olin.edu> References: <20050210150015.798d2fcd.fedora@wir-sind-cool.org> <420B8892.1090606@olin.edu> Message-ID: <20050210173045.4a33f966.fedora@wir-sind-cool.org> On Thu, 10 Feb 2005 11:15:14 -0500, Aaron Bennett wrote: > Michael Schwendt wrote: > >For uploads and complete src.rpm auto-imports: > > https://www.redhat.com/archives/fedora-extras-list/2005-February/msg00098.html > > > >You either prepare your update package outside CVS and then cvs-import.sh > >it automatically and your done. Or you prepare your changes in your CVS ^^^^ !you're! > >working copy, upload new binaries into the lookaside cache, and at the > >end commit every changed file including the 'sources' file. > > > >As a test whether the full commit was fine, enter a different directory > >and checkout a fresh working copy there. It should succeed in fetching the > >binaries from lookaside cache and also pass simple build tests such as > >'make i386' or 'make srpm' at least. > > > > > I'd add this to the wikpage, but I don't have edit access. Can you > allow "AaronBennett" to edit the wiki as well? Done. Preferably such requests are GPG-signed. -- Fedora Core release 3 (Heidelberg) - Linux 2.6.10-1.762_FC3 loadavg: 1.25 1.13 1.07 From gauret at free.fr Thu Feb 10 18:21:50 2005 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 10 Feb 2005 19:21:50 +0100 Subject: Fedora Extras CVS Howto somewhere ? References: <20050210150015.798d2fcd.fedora@wir-sind-cool.org> <20050210191130.1000ea2c.fedora@wir-sind-cool.org> Message-ID: Michael Schwendt wrote: > As explained in the linked archive mail. "make new-sources" to > upload and create a new 'sources' file. "make upload" to upload > and append to the existing sources file. Sorry... Thanks again. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "Quand on pense qu'il suffirait que les gens n'ach?tent pas pour que ?a ne se vende plus ! " -- Coluche, 1978 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 10 18:51:50 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 10 Feb 2005 19:51:50 +0100 Subject: gstreamer-pythpn build error In-Reply-To: <20050210032125.2efc0f56.fedora@wir-sind-cool.org> References: <1107996049.8636.107.camel@Madison.badger.com> <20050210020145.26617779.fedora@wir-sind-cool.org> <1108001023.8636.115.camel@Madison.badger.com> <20050210032125.2efc0f56.fedora@wir-sind-cool.org> Message-ID: <20050210195150.0d344182@python2> Hi, For now, I've uploaded the required gstreamer-python source to the lookaside cache, as I'm not even sure Thomasvs is on this list (haven't seen him post here yet). I've also requested a new build. Matthias Thomas, for reference : > > Hmmm... The make upload* targets? So I take it some invocation of that > > would need to be run to sync the Source version in the spec file with > > the Source version in the cache? > > A simple upload: > https://www.redhat.com/archives/fedora-extras-list/2005-February/msg00098.html -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.22 0.36 0.50 From aaron.bennett at olin.edu Thu Feb 10 18:55:41 2005 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Thu, 10 Feb 2005 13:55:41 -0500 Subject: Fedora Extras CVS Howto somewhere ? In-Reply-To: <20050210173045.4a33f966.fedora@wir-sind-cool.org> References: <20050210150015.798d2fcd.fedora@wir-sind-cool.org> <420B8892.1090606@olin.edu> <20050210173045.4a33f966.fedora@wir-sind-cool.org> Message-ID: <420BAE2D.90102@olin.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: | On Thu, 10 Feb 2005 11:15:14 -0500, Aaron Bennett wrote: | |> I'd add this to the wikpage, but I don't have edit access. Can |> you allow "AaronBennett" to edit the wiki as well? | | | Done. Preferably such requests are GPG-signed. | | Thank you! Here's my signature for your reference. - -- Aaron Bennett UNIX Administrator Franklin W. Olin College of Engineering -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCC64tc0PuKgpwjc4RAspYAJwKDUOPVUp4BC2ZCyWJZYJqo/ZfsACgkhX4 xw+CB8XoKZXInRoC9Ikbykw= =jwEM -----END PGP SIGNATURE----- From ivazquez at ivazquez.net Thu Feb 10 19:07:33 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 10 Feb 2005 14:07:33 -0500 Subject: Requests for inclusion Message-ID: <1108062454.6879.15.camel@localhost.localdomain> I went mucking through my repository, looking for packages that I felt could/should be in extras. Here's what I've found so far: gPHPedit 0.9.50: PHP/HTML/CSS Development Environment for GNOME 2.x http://www.gphpedit.org http://fedora.ivazquez.net/yum/3/i386/RPMS.ivazquez/gphpedit-0.9.50-0.iva.0.i386.rpm http://fedora.ivazquez.net/yum/3/i386/SRPMS.ivazquez/gphpedit-0.9.50-0.iva.0.src.rpm kphone 4.1.0: A SIP (Session Initiation Protocol) user agent for Linux http://www.wirlab.net/kphone http://fedora.ivazquez.net/yum/3/i386/RPMS.ivazquez/kphone-4.1.0-0.iva.0.i386.rpm http://fedora.ivazquez.net/yum/3/i386/SRPMS.ivazquez/kphone-4.1.0-0.iva.0.src.rpm leafpad 0.7.9: GTK+ based simple text editor http://tarot.freeshell.org/leafpad http://fedora.ivazquez.net/yum/3/i386/RPMS.ivazquez/leafpad-0.7.9-0.iva.0.i386.rpm http://fedora.ivazquez.net/yum/3/i386/SRPMS.ivazquez/leafpad-0.7.9-0.iva.0.src.rpm libosip 0.9.7: oSIP is an implementation of SIP http://www.fsf.org/software/osip/osip.html http://fedora.ivazquez.net/yum/3/i386/RPMS.ivazquez/libosip-0.9.7-0.iva.0.i386.rpm http://fedora.ivazquez.net/yum/3/i386/RPMS.ivazquez/libosip-devel-0.9.7-0.iva.0.i386.rpm http://fedora.ivazquez.net/yum/3/i386/SRPMS.ivazquez/libosip-0.9.7-0.iva.0.src.rpm linphone 0.12.2: Phone anywhere in the whole world by using the Internet (requires libosip 0.x) http://www.linphone.org/?lang=us&rubrique=1 http://fedora.ivazquez.net/yum/3/i386/RPMS.ivazquez/linphone-0.12.2-0.iva.1.i386.rpm http://fedora.ivazquez.net/yum/3/i386/RPMS.ivazquez/linphone-devel-0.12.2-0.iva.1.i386.rpm http://fedora.ivazquez.net/yum/3/i386/SRPMS.ivazquez/linphone-0.12.2-0.iva.1.src.rpm lock-keys-applet 1.0: A GNOME panel applet that shows the status of the lock keys http://mfcn.ilo.de/led_applet http://fedora.ivazquez.net/yum/3/i386/RPMS.ivazquez/lock-keys-applet-1.0-0.iva.0.i386.rpm http://fedora.ivazquez.net/yum/3/i386/SRPMS.ivazquez/lock-keys-applet-1.0-0.iva.0.src.rpm mail-notification 1.0: A status icon that informs you if you have new mail http://www.nongnu.org/mailnotify http://fedora.ivazquez.net/yum/3/i386/RPMS.ivazquez/mail-notification-1.0-2.iva.0.i386.rpm http://fedora.ivazquez.net/yum/3/i386/SRPMS.ivazquez/mail-notification-1.0-2.iva.0.src.rpm pam_mysql 0.50: PAM module for auth UNIX users using MySQL data base http://sf.net/projects/pam-mysql http://fedora.ivazquez.net/yum/3/i386/RPMS.ivazquez/pam_mysql-0.50-1.iva.0.i386.rpm http://fedora.ivazquez.net/yum/3/i386/SRPMS.ivazquez/pam_mysql-0.50-1.iva.0.src.rpm xCHM 0.9.7: A viewer for Microsoft Compiled HTMLHelp files http://xchm.sourceforge.net/ http://fedora.ivazquez.net/yum/3/i386/RPMS.ivazquez/xchm-0.9.7-0.iva.0.i386.rpm http://fedora.ivazquez.net/yum/3/i386/SRPMS.ivazquez/xchm-0.9.7-0.iva.0.src.rpm -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ -------------- next part -------------- A non-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 Feb 10 19:12:00 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 10 Feb 2005 20:12:00 +0100 Subject: gstreamer-pythpn build error In-Reply-To: <20050210195150.0d344182@python2> References: <1107996049.8636.107.camel@Madison.badger.com> <20050210020145.26617779.fedora@wir-sind-cool.org> <1108001023.8636.115.camel@Madison.badger.com> <20050210032125.2efc0f56.fedora@wir-sind-cool.org> <20050210195150.0d344182@python2> Message-ID: <1108062720.6036.24.camel@localhost.localdomain> Am Donnerstag, den 10.02.2005, 19:51 +0100 schrieb Matthias Saou: > > For now, I've uploaded the required gstreamer-python source to the > lookaside cache, as I'm not even sure Thomasvs is on this list > (haven't > seen him post here yet). > I've also requested a new build. And I canceled the x86_64 build. I just tried, it still fails. It installs the files /usr/lib/python2.3/site-packages/gst/__init__.py? but (I think, did not look at it closely) they need to be placed in /usr/lib64/python2.3/site-packages/gst/__init__.py? /me needs to open a report in bugzilla... -- Thorsten Leemhuis From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 10 19:17:10 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 10 Feb 2005 20:17:10 +0100 Subject: gstreamer-pythpn build error In-Reply-To: <1108062720.6036.24.camel@localhost.localdomain> References: <1107996049.8636.107.camel@Madison.badger.com> <20050210020145.26617779.fedora@wir-sind-cool.org> <1108001023.8636.115.camel@Madison.badger.com> <20050210032125.2efc0f56.fedora@wir-sind-cool.org> <20050210195150.0d344182@python2> <1108062720.6036.24.camel@localhost.localdomain> Message-ID: <20050210201710.58b262ca@python2> Thorsten Leemhuis wrote : > Am Donnerstag, den 10.02.2005, 19:51 +0100 schrieb Matthias Saou: > > > > For now, I've uploaded the required gstreamer-python source to the > > lookaside cache, as I'm not even sure Thomasvs is on this list > > (haven't > > seen him post here yet). > > I've also requested a new build. > > And I canceled the x86_64 build. I just tried, it still fails. It > installs the files > > /usr/lib/python2.3/site-packages/gst/__init__.py? > > but (I think, did not look at it closely) they need to be placed in > > /usr/lib64/python2.3/site-packages/gst/__init__.py? > > /me needs to open a report in bugzilla... I'll try to see with Thomasvs if/how I can give him access to my x86_64 machine to fix these kind of things, as he doesn't have access to one right now. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.25 0.59 0.51 From ville.skytta at iki.fi Thu Feb 10 20:13:29 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 10 Feb 2005 22:13:29 +0200 Subject: Requests for inclusion In-Reply-To: <1108062454.6879.15.camel@localhost.localdomain> References: <1108062454.6879.15.camel@localhost.localdomain> Message-ID: <1108066409.5731.81.camel@bobcat.mine.nu> On Thu, 2005-02-10 at 14:07 -0500, Ignacio Vazquez-Abrams wrote: > I went mucking through my repository, looking for packages that I felt > could/should be in extras. Here's what I've found so far: [...] > mail-notification 1.0: A status icon that informs you if you have new mail This is already in. From ivazquez at ivazquez.net Thu Feb 10 20:23:02 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 10 Feb 2005 15:23:02 -0500 Subject: Requests for inclusion In-Reply-To: <1108066409.5731.81.camel@bobcat.mine.nu> References: <1108062454.6879.15.camel@localhost.localdomain> <1108066409.5731.81.camel@bobcat.mine.nu> Message-ID: <1108066982.6879.23.camel@localhost.localdomain> On Thu, 2005-02-10 at 22:13 +0200, Ville Skytt? wrote: > On Thu, 2005-02-10 at 14:07 -0500, Ignacio Vazquez-Abrams wrote: > > mail-notification 1.0: A status icon that informs you if you have new mail > > This is already in. So it is. Never mind that one then. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ -------------- next part -------------- A non-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 Thu Feb 10 20:28:41 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 10 Feb 2005 21:28:41 +0100 (CET) Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <1108011659.31499.236.camel@mccallum.corsepiu.local> References: <20050207131917.44e53bb8@python2> <20050209213150.3519b56b@python2> <20050209224132.428bb629.fedora@wir-sind-cool.org> <1108011659.31499.236.camel@mccallum.corsepiu.local> Message-ID: <45347.81.64.155.54.1108067321.squirrel@rousalka.dyndns.org> On Jeu 10 f?vrier 2005 6:00, Ralf Corsepius a ?crit : > On Wed, 2005-02-09 at 22:41 +0100, Michael Schwendt wrote: >> On Wed, 9 Feb 2005 21:31:50 +0100, Matthias Saou wrote: >> >> That's a question for lawyers, whether somebody also waives all his >> rights >> in the composition (melody, accompany and such details) when he releases >> music into the public domain. It is my understanding that work released >> into the public domain is not even copyrighted. > No. This is a matter of applicable law, in particular national laws. > What you say, to my knowledge probably is true in the US, but it > definitely is not true in certain countries, e.g. Germany. > > In Germany, you can not give up any copyright nor assign any copyright > to anybody on any "creative work" (this applies to musical compositions, > recordings/performance/arrangements of music as well as to SW). Same in France and probably most Europe. You must understand most European people do not believe in the transcendental nature of the "free" market (Europe signed the Kyoto protocol - the USA pushed for creation of a pollution quota market, I guess someday you'll be able do do anything in America provided you put enough money on the table). On the contrary they think there are some higher rules (moral, social...) that take precedance over making everything a product. So in Europe (GB excepted probably) you can sell what amounts to copyright assignation in all practical matters except the original author retains unalienable "moral" rights on his creations. What this means practicaly is a pacifist can contest in court the use of one of his creations by the army (in a recruitement ad...), you can not limit the diffusion of a creation (song, book...) you don't like just by buying all publication rights and refusing to exercise them, etc You could say someone who wanted his book to be published should not have sold the copyright to an ennemy, but modern financial structures are so complex you got strange ownership situations all the time, and Europeans decided some safeguards were needed. Of course you have to convince the judge the current use of your creation is totally contrary to your beliefs and this is not a ploy to pull out of an ill-advised contract, plus it sends a real bad message to people that could buy some use rights on your other creations, so it's almost never exercised. I could easily imagine a european hacker arguing SCO should not be allowed to use the code he released for BSD because SCO decided to attack the ATT/BSD settlement. But IANAL - this is how I understand the spirit of the law, practical application is something else. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Thu Feb 10 20:58:14 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 10 Feb 2005 21:58:14 +0100 (CET) Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <1108037934.31499.267.camel@mccallum.corsepiu.local> References: <20050207131917.44e53bb8@python2> <20050209213150.3519b56b@python2> <20050209224132.428bb629.fedora@wir-sind-cool.org> <1108011659.31499.236.camel@mccallum.corsepiu.local> <420AF8F4.3010604@redhat.com> <1108037934.31499.267.camel@mccallum.corsepiu.local> Message-ID: <41082.81.64.155.54.1108069094.squirrel@rousalka.dyndns.org> On Jeu 10 f?vrier 2005 13:18, Ralf Corsepius a ?crit : > On Wed, 2005-02-09 at 20:02 -1000, Warren Togami wrote: >> Ralf Corsepius wrote: >> > >> > I.e. even if you did not explicitly put a "Copyright (c)" notice on >> such >> > a piece of work it will be copyrighted by you. In Germany, all you >> only >> > can do is to give away "licenses to the public", and "express your >> will >> > not to enforce unauthorized copying/modifications", but you can not >> give >> > up any copyright. >> > >> >> You are correct, except I think it was the Berne Convention (along with >> the past 2 or 3 copyright acts in the USA) that made registration of >> copyrights in America optional. If you write anything in America, it is >> automatically protected by copyright even if you don't explicitly >> include a copyright notice. But it does help to have one, and register >> the copyright to be able to prove ownership and possibly enforce it. The Berne Convention tried to unify American copyright laws and European "Author rights" legislation. It brought everyone closer but to this day the laws on creative works are not 100% identical both sides of the Atlantic. >> Anyhow, my only point is that it is supposed to be a global standard of >> minimally 50 years without necessary notice or registration. That isn't >> limited to just Germany. > :) > > What I outlined above ("Freedom of Arts") is part of Germany's > constitution ("Grundgesetz"). "Author rights" are heavily protected in Europe because creative works can have a political nature and European states have decided long ago political action should be protected to preserve their democratic nature. They serve a similar purpose as the first amendment in the USA, except the balance is a bit different. Free speech is not unlimited here - a lot of states have decided long ago Nazi propaganda didn't deserve the protection of the law for example. On the other hand "author rights" can provide a very versatile protection from more than just the state. The thing to remember is they are not just some sort of legislative oddity - they are considered _fundamental_ rights and when exercised can have much the same trump card effect as first amendment invocation in the USA. -- Nicolas Mailhot From ville.skytta at iki.fi Thu Feb 10 21:09:49 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 10 Feb 2005 23:09:49 +0200 Subject: New candidates packages for Extras In-Reply-To: <1107973071.3582.30.camel@dhcp83-72.boston.redhat.com> References: <1107968577.3582.21.camel@dhcp83-72.boston.redhat.com> <420A4C7F.3030100@di.uminho.pt> <1107973071.3582.30.camel@dhcp83-72.boston.redhat.com> Message-ID: <1108069789.27507.9.camel@bobcat.mine.nu> On Wed, 2005-02-09 at 13:17 -0500, Dennis Gregorovic wrote: > Thank you for pointing these out. As you can tell, I didn't check the > Fedora.us queues before my first post. (I'm new to Fedora.us/Extras > process) > > Ville, what's the status on these packages? Would you like to add them > to Extras? They will enter Extras once they pass QA in one form or another. You can help out by reviewing the existing submissions for these packages, the submission URLs were listed at https://www.redhat.com/archives/fedora-extras-list/2005-February/msg00279.html perl-XML-XPath is now in CVS, perl-Template-Toolkit fails its tests also with GD 2.21 (which incidentally also fails _it's_ own test suite on FC3). Status for others I know about is still the same as in my message in the link above. I wouldn't rush with Bugzilla at this point, better to go directly to 2.18 when a sufficiently new DBD-MySQL is available to avoid possible upgrade pains. IIRC someone mentioned possibly getting the Red Hat customized version of Bugzilla to Extras (as a package) sometime. Is someone working on it? From gauret at free.fr Thu Feb 10 23:41:07 2005 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 11 Feb 2005 00:41:07 +0100 Subject: New package for review : plone Message-ID: I've just imported a package for Plone. Plone is a powerful Content Management System based on Zope. This package is rather simple, it basically copies the files in the Zope "Products" directory. Please review. Thanks, Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info Programmer: A biological system designed to convert coffee and pizza into code. From pcompton at proteinmedia.com Fri Feb 11 02:25:48 2005 From: pcompton at proteinmedia.com (Phillip Compton) Date: Thu, 10 Feb 2005 21:25:48 -0500 Subject: fedora-meld.desktop: MimeType=x-directory/normal? In-Reply-To: <1108033664.4900.49.camel@lux.homenetwork> References: <1108033664.4900.49.camel@lux.homenetwork> Message-ID: <1108088749.5245.4.camel@earlgrey.compton.net> I've forwarded your message upstream. On Thu, 2005-02-10 at 12:07 +0100, Sven Wahl wrote: > Hi > > I updated meld from version 0.9.4.1-3 to 0.9.5-1 using Fedora Extras > yesterday. The new .desktop-file > > fedora-meld.desktop > > that comes with meld-0.9.5-1.noarch.rpm contains the following line: > > MimeType=x-directory/normal; I found it a bit curious when I was looking at the .desktop entry, but it had no effect on my machines, so I left it alone thinking it was harmless. > This set the file association for directories to meld. So, whenever I'm > browsing my file system with Nautilus now, Gnome tries to open > directories with the Meld-Diff Viewer. > > Is this an intended feature or is it a bug? I'd have to say anything that interferes with your ability to use nautilus is a bug. Has anyone else tried out the new meld package? are you seeing the same behavior? Phil From skvidal at fedoraproject.org Fri Feb 11 04:47:33 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 10 Feb 2005 23:47:33 -0500 Subject: Fedora Extras Package Updates Message-ID: <1108097253.5782.5.camel@cutter> Hi Everyone, Some busy packagers today. Lots of new/updated stuff. torcs (x86_64) logjam (x86, x86_64) opencdk (x86, x86_64) lablgtk (x86_64) kickpim (x86, x86_64) ocaml (x86, x86_64) camstream (x86, x86_64) python-dialog (x86, x86_64) gstreamer-python (x86) wxPython (x86, x86_64) wxPythonGTK2 (x86, x86_64) anjuta (x86, x86_64) pexpect (x86, x86_64) perl-XML-XPath (x86, x86_64) perl-String-ShellQuote (x86, x86_64) Status page: http://fedoraproject.org/wiki/Extras_2fFC3Status Follow updates and new packages at: http://fedoraproject.org/infofeed/ Report problems at Bugzilla: http://bugzilla.redhat.com/ thanks, -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Fri Feb 11 05:19:30 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 11 Feb 2005 00:19:30 -0500 Subject: Fedora Extras Package Updates Message-ID: <1108099171.5782.7.camel@cutter> Hi Folks, One more latecomer: inkscape x86, x86_64 Built and set. Status page: http://fedoraproject.org/wiki/Extras_2fFC3Status Follow updates and new packages at: http://fedoraproject.org/infofeed/ Report problems at Bugzilla: http://bugzilla.redhat.com/ thanks, -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Fri Feb 11 06:04:57 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 11 Feb 2005 07:04:57 +0100 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <20050210190953.7e156b14.fedora@wir-sind-cool.org> References: <20050207131917.44e53bb8@python2> <20050207135420.773a2b08.fedora@wir-sind-cool.org> <1108049173.28783.20.camel@wombat.tiptoe.de> <20050210190953.7e156b14.fedora@wir-sind-cool.org> Message-ID: <1108101897.31499.384.camel@mccallum.corsepiu.local> On Thu, 2005-02-10 at 19:09 +0100, Michael Schwendt wrote: > On Thu, 10 Feb 2005 16:26:13 +0100, Nils Philippsen wrote: > > > On Mon, 2005-02-07 at 13:54 +0100, Michael Schwendt wrote: > > > On Mon, 7 Feb 2005 13:19:17 +0100, Matthias Saou wrote: > > > > > > > Here are packages I'd like to add to Extras : > > > > > > > - starfighter-music : My current starfighter package doesn't bundle the > > > This package is at most "License: Public Domain", but not GPL. > > > > This would indeed be the case if and only if the original authors > > explicitly state that their work is in the Public Domain which would > > probably be taken as a similar statement without waiver of copyright in > > countries like Germany (but IANAL). Do we really have statements to that > > effect from the original authors? > > Let me ask a different question, please, since the discussion leads to > nowhere so far. We need solutions. Decisions. > So, here's the question: > > Generally, how do we treat FOSS packages which include binary music files > or graphics and which don't cover that artwork with any special purpose > licence? > The important bit is how this music was released originally. IANAL, but I don't see how the licensing situation of "artwork" is any different from that of other files in a package[1]. "Artwork" files are "just files" and therefore are covered by licenses. To be able to ship such files as part of the sources, the authors must be legally legitimated to do so, i.e. they must have a license permitting them to do so. As packager/distributor you must have a license permitting you to redistribute the binary package. As with most other files, you have almost no chance to track the license situation down and clarify it definitively. All you can do is to review the code and trust the program author and the license issued by him. I.e. you try to refer all potential licensing/copyright infringement claims to him. It's up to you (the packager) to "trust the authors" and take the risk or to leave it. Ralf [1] In Germany, "free software" written by "free authors" at "free will" legally is/can be considered "creative artwork" and covered by the same laws. From pmatilai at welho.com Fri Feb 11 07:56:40 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 11 Feb 2005 09:56:40 +0200 (EET) Subject: Fedora Extras Package Updates In-Reply-To: <1108097253.5782.5.camel@cutter> References: <1108097253.5782.5.camel@cutter> Message-ID: On Thu, 10 Feb 2005, seth vidal wrote: > Some busy packagers today. Lots of new/updated stuff. > wxPython (x86, x86_64) > wxPythonGTK2 (x86, x86_64) Erm, why do we have two packages of the same thing? Please kill the package named wxPython from both the repository and CVS, wxPythonGTK2 *is* wxPython, built with GTK2-support and provides "wxPython" so packages can depend on the the "real" name. It's named like that because we could (at least in theory) provide another package of it built against gtk-1.x (or whatever other widgets it might support) and let the user choose. At least that was the rationale for the naming in original fedora.us packaging :) - Panu - From skvidal at phy.duke.edu Fri Feb 11 08:01:23 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 11 Feb 2005 03:01:23 -0500 Subject: Fedora Extras Package Updates In-Reply-To: References: <1108097253.5782.5.camel@cutter> Message-ID: <1108108883.5782.9.camel@cutter> On Fri, 2005-02-11 at 09:56 +0200, Panu Matilainen wrote: >On Thu, 10 Feb 2005, seth vidal wrote: >> Some busy packagers today. Lots of new/updated stuff. >> wxPython (x86, x86_64) >> wxPythonGTK2 (x86, x86_64) > >Erm, why do we have two packages of the same thing? Please kill the >package named wxPython from both the repository and CVS, wxPythonGTK2 *is* >wxPython, built with GTK2-support and provides "wxPython" so packages can >depend on the the "real" name. It's named like that because we could (at >least in theory) provide another package of it built against gtk-1.x (or >whatever other widgets it might support) and let the user choose. >At least that was the rationale for the naming in original fedora.us >packaging :) deferring to the package maintainer - I'm just a human buildsystem. I was told to build wxPython and wxPythonGTK2, so I did. :) -sv From pmatilai at welho.com Fri Feb 11 08:05:16 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 11 Feb 2005 10:05:16 +0200 (EET) Subject: Fedora Extras Package Updates In-Reply-To: <1108108883.5782.9.camel@cutter> References: <1108097253.5782.5.camel@cutter> <1108108883.5782.9.camel@cutter> Message-ID: On Fri, 11 Feb 2005, seth vidal wrote: > On Fri, 2005-02-11 at 09:56 +0200, Panu Matilainen wrote: >> On Thu, 10 Feb 2005, seth vidal wrote: >>> Some busy packagers today. Lots of new/updated stuff. >>> wxPython (x86, x86_64) >>> wxPythonGTK2 (x86, x86_64) >> >> Erm, why do we have two packages of the same thing? Please kill the >> package named wxPython from both the repository and CVS, wxPythonGTK2 *is* >> wxPython, built with GTK2-support and provides "wxPython" so packages can >> depend on the the "real" name. It's named like that because we could (at >> least in theory) provide another package of it built against gtk-1.x (or >> whatever other widgets it might support) and let the user choose. >> At least that was the rationale for the naming in original fedora.us >> packaging :) > > deferring to the package maintainer - I'm just a human buildsystem. I > was told to build wxPython and wxPythonGTK2, so I did. :) Wasn't directed at you obviously... *I'm* supposed to be the package maintainer but lacking CVS access, it's a bit hard at times :) What we probably have here is just an artifact of the mass-import of history and all into CVS - the package has had two names in past. - Panu - From nphilipp at redhat.com Fri Feb 11 09:32:42 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 11 Feb 2005 10:32:42 +0100 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <20050210190953.7e156b14.fedora@wir-sind-cool.org> References: <20050207131917.44e53bb8@python2> <20050207135420.773a2b08.fedora@wir-sind-cool.org> <1108049173.28783.20.camel@wombat.tiptoe.de> <20050210190953.7e156b14.fedora@wir-sind-cool.org> Message-ID: <1108114363.455.34.camel@gibraltar.stuttgart.redhat.com> On Thu, 2005-02-10 at 19:09 +0100, Michael Schwendt wrote: > We can argue endlessly. I don't care where the music files were downloaded > from. I don't care whether "Public Domain" BBSs or download servers also > carry freeware, shareware and other forms of software and misguide their > users with that mixture. > > The important bit is how this music was released originally. Amiga demo > software, music demos, individual pieces of mod music usually were either > released into the public domain implicitly or explicitly marked as > something else. "Usually" and "implicitly" aren't good words when talking about legal implications. An author needs to waive his rights to certain piece of work explicitly, it just doesn't matter what was usual in certain time or in certain circles. > In the public domain, to be used by other people however > they like (even commercially, BBS download fees as the least form). Many > musicians did do music, which was never used inside a program. Programmed > in assembler languages, you could reuse published software not as > trivially as music and graphics files. Hence [good] music was reused much > more often and spread much more, too. MOD files are source files. > High-profile musicians with special interests usually did not publish > their music before a corresponding program (e.g. a music demo disk) was > released and used the music exclusively for some time. Those musicians who > wanted their music not being spread freely, usually made it clear inside > the files and asked programmers to protect the music data at least a bit. > > The only uncertainty with the Starfighter musics is their origin. This is not true. If you are uncertain about the origins of something, how can you be sure about its licensing? > Maybe > they were taken from a freeware demo program and were not considered > public domain work originally. I don't want to decide whether > approximately 10 years ago a musician did not care what other people might > do with his music. Unless it's explicitly written anywhere that a MOD > music file from the home computer area shall not be seen as public domain > work, I treat such files as PD. I'm not a lawyer, but this stance just doesn't cut it: - it bolsters the FUD certain groups spread about the free software and open source community, namely that we don't respect copyright and grab anything we can lay our hands on - with what we currently have with Fedora Extras, it puts Red Hat as the distributor of these files at risk of being legally challenged, of getting some really bad PR, ... and with Red Hatters participating in this thread Red Hat can't even claim not having known about the issue You are free to do whatever you please as long as it only affects yourself. Unfortunately this isn't the case here: we all know that we aren't sure about the origins of the music and the terms under which it was released and if worse came to worst, we might get slapped down for it. Therefore, unless the ownership w.r.t. copyright has been cleared and we know that we may distribute the music, I veto its inclusion into Fedora Extras. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-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 wir-sind-cool.org Fri Feb 11 09:54:02 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 11 Feb 2005 10:54:02 +0100 Subject: Fedora Extras Package Updates In-Reply-To: References: <1108097253.5782.5.camel@cutter> Message-ID: <20050211105402.3189f656.fedora@wir-sind-cool.org> On Fri, 11 Feb 2005 09:56:40 +0200 (EET), Panu Matilainen wrote: > On Thu, 10 Feb 2005, seth vidal wrote: > > Some busy packagers today. Lots of new/updated stuff. > > wxPython (x86, x86_64) > > wxPythonGTK2 (x86, x86_64) > > Erm, why do we have two packages of the same thing? Please kill the > package named wxPython from both the repository and CVS, wxPythonGTK2 *is* > wxPython, built with GTK2-support and provides "wxPython" so packages can > depend on the the "real" name. It's named like that because we could (at > least in theory) provide another package of it built against gtk-1.x (or > whatever other widgets it might support) and let the user choose. > At least that was the rationale for the naming in original fedora.us > packaging :) It has been pointed out before that wxPython appeared on the fedora.us FC2Status page, meaning that it was NOT rebuilt for FC2 for some reason. Nobody cared to look into it when we discussed which old package directories to remove from CVS prior to the pre-Extras mass rebuild. Please, everyone, in particular the package owners of these, check out: http://fedoraproject.org/wiki/Extras/FC3Status The lists at the bottom ("Copied from FC2Status page" and "Unknown status") cover packages which have not been rebuilt for some time. From dwmw2 at infradead.org Fri Feb 11 09:51:59 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 11 Feb 2005 09:51:59 +0000 Subject: fbida build fix Message-ID: <1108115519.20510.3.camel@localhost.localdomain> This makes fbida build. There a are bunch of other build failures which I could work around by setting _unpackaged_files_terminate_build to zero, but I don't want to do that. I'm far too lazy to mail the owners of individual packages separately -- shall I just go and fix them to remove or package the files as I see fit? --- fbida.spec 17 Dec 2004 18:54:17 -0000 1.1 +++ fbida.spec 11 Feb 2005 09:52:45 -0000 @@ -45,6 +45,7 @@ %doc Changes COPYING README TODO %doc %{_mandir}/man1/* %{_bindir}/* +%config /usr/X11R6/lib/X11/app-defaults/Ida %changelog * Sun Nov 28 2004 Adrian Reber - 2.02-1 -- dwmw2 From fedora at wir-sind-cool.org Fri Feb 11 10:47:05 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 11 Feb 2005 11:47:05 +0100 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <1108114363.455.34.camel@gibraltar.stuttgart.redhat.com> References: <20050207131917.44e53bb8@python2> <20050207135420.773a2b08.fedora@wir-sind-cool.org> <1108049173.28783.20.camel@wombat.tiptoe.de> <20050210190953.7e156b14.fedora@wir-sind-cool.org> <1108114363.455.34.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20050211114705.5abeebf8.fedora@wir-sind-cool.org> On Fri, 11 Feb 2005 10:32:42 +0100, Nils Philippsen wrote: > > The only uncertainty with the Starfighter musics is their origin. > > This is not true. If you are uncertain about the origins of something, > how can you be sure about its licensing? Judgement based on the information inside the instruments headers, as explained earlier. > > Maybe > > they were taken from a freeware demo program and were not considered > > public domain work originally. I don't want to decide whether > > approximately 10 years ago a musician did not care what other people might > > do with his music. Unless it's explicitly written anywhere that a MOD > > music file from the home computer area shall not be seen as public domain > > work, I treat such files as PD. > > I'm not a lawyer, but this stance just doesn't cut it: > > - it bolsters the FUD certain groups spread about the free software and > open source community, namely that we don't respect copyright and grab > anything we can lay our hands on Well, I fail to see the relationship. > - with what we currently have with Fedora Extras, it puts Red Hat as the > distributor of these files at risk of being legally challenged, of > getting some really bad PR, ... and with Red Hatters participating in > this thread Red Hat can't even claim not having known about the issue > > You are free to do whatever you please as long as it only affects > yourself. Unfortunately this isn't the case here: we all know that we > aren't sure about the origins of the music and the terms under which it > was released and if worse came to worst, we might get slapped down for > it. > > Therefore, unless the ownership w.r.t. copyright has been cleared and we > know that we may distribute the music, I veto its inclusion into Fedora > Extras. So, Starfighter must be dropped as it is included already. I don't care about those games. All I want to learn in threads like this is where to draw the line with regard to legal threats. And to develop a guideline for acting responsibly. No investigation, no discussion, no uncertainty => packages are accepted and stay until somebody raises doubt. The slightest uncertainty, and we jump on the tree and fear liability. I wonder what's more responsible? To exclude software only when clear legal issues are seen, such as clearly conflicting licences, or to exclude everything which might be a problem, but has not been a problem according to common knowledge for many years ("mikmod" in Core is not seen as a problem for the same reason I guess). There are file formats and implementations which are "assumed to be free of royalties", but only lawyers might be able to find out for sure. Here, an accidental finding lead to discovering an unknown copyright situation of music files. It is assumed that the author of the game took music files he's not permitted to use and redistribute. Similarly, his other work (game design/concept) could be challenged, too. This gets more interesting with regard to potentially patented technology, an area where FUD strategies are very successful. This discussion is also interesting with regard to the old topic of the "QA hurdle at fedora.us". Effectively, licencing and copyright issues require reviewers to do full audits of package contents before deciding whether to accept/reject a submission. From fedora at wir-sind-cool.org Fri Feb 11 10:51:01 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 11 Feb 2005 11:51:01 +0100 Subject: new package for review: logjam In-Reply-To: <20050210104518.56784b8b@python2> References: <1107991414.3664.138.camel@localhost.localdomain> <20050210011636.5ce58eab.fedora@wir-sind-cool.org> <1108013688.3664.163.camel@localhost.localdomain> <420AF710.2070305@redhat.com> <1108014819.3664.169.camel@localhost.localdomain> <420AFA44.7050308@redhat.com> <1108017933.3664.172.camel@localhost.localdomain> <20050210104518.56784b8b@python2> Message-ID: <20050211115101.793e988b.fedora@wir-sind-cool.org> On Thu, 10 Feb 2005 10:45:18 +0100, Matthias Saou wrote: > Tom 'spot' Callaway wrote : > > > On Wed, 2005-02-09 at 20:08 -1000, Warren Togami wrote: > > > Tom 'spot' Callaway wrote: > > > > On Wed, 2005-02-09 at 19:54 -1000, Warren Togami wrote: > > > > > > > > > > > >>Consider adding "%_smp_mflags -j3" to your .rpmmacros, which > sometimes > > > >>exposes Makefile races even on uniprocessor build machines. Everyone > > > > >>that does packaging should do this, in order to avoid a surprise > failure > > > >>on a SMP build system. > > > > Sneaking back on topic, with -j3, it still builds for me. I suspect the > > missing gettext in the buildroot was what caused the translation error. > > Yup. And Michael pointed that out in his first review mail : gettext-devel > is most certainly the guilty one, and you'll need to add it to > BuildRequires (as he wrote). Note that for RH/RHEL or FC < 3, it's > "gettext" and not "gettext-devel" since the split happened very recently. I must admit, I didn't look whether it needed gettext-devel or just gettext. The former requires the latter, so... Tom changed the BR to gettext in his last commit. Based on reading his %changelog, it seems some comments on his package have flown in via private communication channels. For the benefit of all of us, please post such comments publicly, e.g. on fedora-extras-list, so we can learn from them, too. Thank you. -- Fedora Core release 3 (Heidelberg) - Linux 2.6.10-1.762_FC3 loadavg: 0.04 0.28 0.16 From fedora at wir-sind-cool.org Fri Feb 11 11:02:38 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 11 Feb 2005 12:02:38 +0100 Subject: fbida build fix In-Reply-To: <1108115519.20510.3.camel@localhost.localdomain> References: <1108115519.20510.3.camel@localhost.localdomain> Message-ID: <20050211120238.4fd1cf6a.fedora@wir-sind-cool.org> On Fri, 11 Feb 2005 09:51:59 +0000, David Woodhouse wrote: > This makes fbida build. There a are bunch of other build failures which > I could work around by setting _unpackaged_files_terminate_build to > zero, but I don't want to do that. I'm far too lazy to mail the owners > of individual packages separately -- shall I just go and fix them to > remove or package the files as I see fit? > > --- fbida.spec 17 Dec 2004 18:54:17 -0000 1.1 > +++ fbida.spec 11 Feb 2005 09:52:45 -0000 > @@ -45,6 +45,7 @@ > %doc Changes COPYING README TODO > %doc %{_mandir}/man1/* > %{_bindir}/* > +%config /usr/X11R6/lib/X11/app-defaults/Ida > > %changelog > * Sun Nov 28 2004 Adrian Reber - 2.02-1 > Known issue. https://bugzilla.fedora.us/show_bug.cgi?id=2310 The current fbida package doesn't include ida, but just fbi, on purpose. "BuildConflicts: openmotif-devel" or a patch would have been necessary for reproducible builds in a build environment not as clean as fedora.us. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 11 11:13:47 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 11 Feb 2005 12:13:47 +0100 Subject: New package for review : plone In-Reply-To: References: Message-ID: <20050211121347.07592331@python2> Aurelien Bompard wrote : > I've just imported a package for Plone. > > Plone is a powerful Content Management System based on Zope. > This package is rather simple, it basically copies the files in the Zope > "Products" directory. > > Please review. A few comments : - You should trim down the %description a little, the two first lines have a problem and some stuff is really not needed, like a quick explanation about what the GPL does... - You should consider dropping the Epoch altogether and the one from the zope versioned requirement. - You could consider using %{version} in the Source line, it usually makes life easier. - My plone package had "System Environment/Daemons" as Group. Dunno which is best between that and your "Applications/Internet". More thoughts could be welcome. Other than that, looks ok, it's a pretty trivial package anyway... unlike zope itself ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 1.15 0.70 0.57 From dwmw2 at infradead.org Fri Feb 11 11:10:57 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 11 Feb 2005 11:10:57 +0000 Subject: fbida build fix In-Reply-To: <20050211120238.4fd1cf6a.fedora@wir-sind-cool.org> References: <1108115519.20510.3.camel@localhost.localdomain> <20050211120238.4fd1cf6a.fedora@wir-sind-cool.org> Message-ID: <1108120257.20510.8.camel@localhost.localdomain> On Fri, 2005-02-11 at 12:02 +0100, Michael Schwendt wrote: > >Known issue. > > https://bugzilla.fedora.us/show_bug.cgi?id=2310 > >The current fbida package doesn't include ida, but just fbi, on >purpose. "BuildConflicts: openmotif-devel" or a patch would have been >necessary for reproducible builds in a build environment not as clean >as fedora.us. The package in CVS appears to include ida, and builds fine with openmotif-devel installed. peach /home/dwmw2/working/extras/devel/fbida $ rpm -qlp ppc/fbida-2.02-1.ppc.rpm /usr/X11R6/lib/X11/app-defaults/Ida /usr/bin/exiftran /usr/bin/fbi /usr/bin/ida /usr/share/doc/fbida-2.02 /usr/share/doc/fbida-2.02/COPYING /usr/share/doc/fbida-2.02/Changes /usr/share/doc/fbida-2.02/README /usr/share/doc/fbida-2.02/TODO /usr/share/man/man1/exiftran.1.gz /usr/share/man/man1/fbi.1.gz /usr/share/man/man1/ida.1.gz peach /home/dwmw2/working/extras/devel/fbida $ rpm -q openmotif-devel openmotif-devel-2.2.3-6.FC3.1 -- dwmw2 From pmatilai at welho.com Fri Feb 11 11:25:49 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 11 Feb 2005 13:25:49 +0200 (EET) Subject: Fedora Extras Package Updates In-Reply-To: <20050211105402.3189f656.fedora@wir-sind-cool.org> References: <1108097253.5782.5.camel@cutter> <20050211105402.3189f656.fedora@wir-sind-cool.org> Message-ID: On Fri, 11 Feb 2005, Michael Schwendt wrote: > On Fri, 11 Feb 2005 09:56:40 +0200 (EET), Panu Matilainen wrote: > >> On Thu, 10 Feb 2005, seth vidal wrote: >>> Some busy packagers today. Lots of new/updated stuff. >>> wxPython (x86, x86_64) >>> wxPythonGTK2 (x86, x86_64) >> >> Erm, why do we have two packages of the same thing? Please kill the >> package named wxPython from both the repository and CVS, wxPythonGTK2 *is* >> wxPython, built with GTK2-support and provides "wxPython" so packages can >> depend on the the "real" name. It's named like that because we could (at >> least in theory) provide another package of it built against gtk-1.x (or >> whatever other widgets it might support) and let the user choose. >> At least that was the rationale for the naming in original fedora.us >> packaging :) > > It has been pointed out before that wxPython appeared on the fedora.us > FC2Status page, meaning that it was NOT rebuilt for FC2 for some > reason. Nobody cared to look into it when we discussed which old package > directories to remove from CVS prior to the pre-Extras mass rebuild. Well, you know that I've been "away" from this stuff for a few months until just recently so I simply haven't seen it being pointed out. Now that I've seen it: just kill the "wxPython" package from CVS, please. > > Please, everyone, in particular the package owners of these, check > out: > > http://fedoraproject.org/wiki/Extras/FC3Status > > The lists at the bottom ("Copied from FC2Status page" and "Unknown > status") cover packages which have not been rebuilt for some time. Wine can be killed as well, unless somebody wants to step up and maintain it. Would be nice if the folks packaging things for winehq took up the task. - Panu - From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 11 11:46:41 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 11 Feb 2005 12:46:41 +0100 Subject: Fedora Extras Package Updates In-Reply-To: References: <1108097253.5782.5.camel@cutter> <20050211105402.3189f656.fedora@wir-sind-cool.org> Message-ID: <20050211124641.6c960e95@python2> Panu Matilainen wrote : > Wine can be killed as well, unless somebody wants to step up and maintain > it. Would be nice if the folks packaging things for winehq took up the > task. I'll try to talk Rudolf Kastl into maintaining it. He works quite closely with the wine developers for his FC packages, does a lot of regression tests for new snapshots, and last I used his packages, they worked very well. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 1.59 1.50 0.91 From nphilipp at redhat.com Fri Feb 11 12:30:03 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 11 Feb 2005 13:30:03 +0100 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <20050211114705.5abeebf8.fedora@wir-sind-cool.org> References: <20050207131917.44e53bb8@python2> <20050207135420.773a2b08.fedora@wir-sind-cool.org> <1108049173.28783.20.camel@wombat.tiptoe.de> <20050210190953.7e156b14.fedora@wir-sind-cool.org> <1108114363.455.34.camel@gibraltar.stuttgart.redhat.com> <20050211114705.5abeebf8.fedora@wir-sind-cool.org> Message-ID: <1108125003.455.64.camel@gibraltar.stuttgart.redhat.com> On Fri, 2005-02-11 at 11:47 +0100, Michael Schwendt wrote: > So, Starfighter must be dropped as it is included already. I don't care > about those games. > > All I want to learn in threads like this is where to draw the line with > regard to legal threats. And to develop a guideline for acting > responsibly. Again, I'm not a lawyer and all my opinions are, well, my opinions ;-). If you wish, I can ask our legal counsel about more definitive statements. > No investigation, no discussion, no uncertainty => packages are accepted > and stay until somebody raises doubt. The slightest uncertainty, and we > jump on the tree and fear liability. Trying to if at all err on the cautious side hasn't served Red Hat too bad IMO ;-). Seriously, if doubt is raised we are responsible to investigate. > I wonder what's more responsible? To exclude software only when clear > legal issues are seen, such as clearly conflicting licences, or to > exclude everything which might be a problem, but has not been a problem > according to common knowledge for many years ("mikmod" in Core is not seen > as a problem for the same reason I guess). There are file formats and > implementations which are "assumed to be free of royalties", but only > lawyers might be able to find out for sure. It's not the MOD format that we're discussing, it's including MODs (or derived files, in fact the format is completely irrelevant as is whether it is software or artwork or whatnot) where we don't know where they come from, i.e. don't know who produced them initially, under what terms they were released, etc. > Here, an accidental finding lead to discovering an unknown copyright > situation of music files. It is assumed that the author of the game took > music files he's not permitted to use and redistribute. Not quite. We are fairly sure that the author hasn't produced them by himself. We are not sure where he got them from and under what terms. If I get a tarball from someone under the GPL, I look at it briefly and see who produced it and that it is in fact licensed by the GPL. Barring any clues that suggest otherwise I will take that as a fact. As soon as there is some indication that this doesn't cover the whole package I will have to rethink which is what we do now, it is my responsibility to do so. > Similarly, his > other work (game design/concept) could be challenged, too. This gets more > interesting with regard to potentially patented technology, an area where > FUD strategies are very successful. This is similar with patents. If I don't think a certain piece of software could be endangered by a patent, I won't act as if it were. If people tell me that package foo could violate a patent that's where some investigation is due. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From fedora at wir-sind-cool.org Fri Feb 11 12:35:21 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 11 Feb 2005 13:35:21 +0100 Subject: fbida build fix In-Reply-To: <1108120257.20510.8.camel@localhost.localdomain> References: <1108115519.20510.3.camel@localhost.localdomain> <20050211120238.4fd1cf6a.fedora@wir-sind-cool.org> <1108120257.20510.8.camel@localhost.localdomain> Message-ID: <20050211133521.7fefc9ac.fedora@wir-sind-cool.org> On Fri, 11 Feb 2005 11:10:57 +0000, David Woodhouse wrote: > On Fri, 2005-02-11 at 12:02 +0100, Michael Schwendt wrote: > > > >Known issue. > > > > https://bugzilla.fedora.us/show_bug.cgi?id=2310 > > > >The current fbida package doesn't include ida, but just fbi, on > >purpose. "BuildConflicts: openmotif-devel" or a patch would have been > >necessary for reproducible builds in a build environment not as clean > >as fedora.us. > > The package in CVS appears to include ida, and builds fine with > openmotif-devel installed. That's not the point. It's still the same package as before and hasn't been touched since the import, to either exclude ida or disable it with other means. Above comment holds true. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 11 12:39:34 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 11 Feb 2005 13:39:34 +0100 Subject: New package for review : plone In-Reply-To: <20050211121347.07592331@python2> References: <20050211121347.07592331@python2> Message-ID: <20050211133934.37ec5b33@python2> Matthias Saou wrote : > A few comments : [...] One last one, and I'm being veeeeery picky on this one :-) Move along if you're only interested in productive stuff! ;-) You're using tabs for the "URL:" line whereas the others use spaces... you should try to keep consistent. This is the main reason why I don't try to keep all of those headers aligned in my own spec files. And seeing the amount of spec files out there that mix tabs and spaces, and become unreadable if you're not using the author's tab spacing setting (i.e. 4 vs. 8 spaces), I'm definitely not about to change this. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.64 0.41 0.29 From fedora at wir-sind-cool.org Fri Feb 11 13:21:37 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 11 Feb 2005 14:21:37 +0100 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <1108125003.455.64.camel@gibraltar.stuttgart.redhat.com> References: <20050207131917.44e53bb8@python2> <20050207135420.773a2b08.fedora@wir-sind-cool.org> <1108049173.28783.20.camel@wombat.tiptoe.de> <20050210190953.7e156b14.fedora@wir-sind-cool.org> <1108114363.455.34.camel@gibraltar.stuttgart.redhat.com> <20050211114705.5abeebf8.fedora@wir-sind-cool.org> <1108125003.455.64.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20050211142137.64088c03.fedora@wir-sind-cool.org> On Fri, 11 Feb 2005 13:30:03 +0100, Nils Philippsen wrote: > On Fri, 2005-02-11 at 11:47 +0100, Michael Schwendt wrote: > > > So, Starfighter must be dropped as it is included already. I don't care > > about those games. > > > > All I want to learn in threads like this is where to draw the line with > > regard to legal threats. And to develop a guideline for acting > > responsibly. > > Again, I'm not a lawyer and all my opinions are, well, my opinions ;-). > If you wish, I can ask our legal counsel about more definitive > statements. I've submitted a query about licencing issues in a different package into the legal queue a few days ago. > > I wonder what's more responsible? To exclude software only when clear > > legal issues are seen, such as clearly conflicting licences, or to > > exclude everything which might be a problem, but has not been a problem > > according to common knowledge for many years ("mikmod" in Core is not seen > > as a problem for the same reason I guess). There are file formats and > > implementations which are "assumed to be free of royalties", but only > > lawyers might be able to find out for sure. > > It's not the MOD format that we're discussing, it's including MODs (or > derived files, in fact the format is completely irrelevant as is whether > it is software or artwork or whatnot) where we don't know where they > come from, i.e. don't know who produced them initially, under what terms > they were released, etc. The format suffers from similar problems. Or where do you see a difference? (I don't know how much you know about .mod history.) > > Here, an accidental finding lead to discovering an unknown copyright > > situation of music files. It is assumed that the author of the game took > > music files he's not permitted to use and redistribute. > > Not quite. We are fairly sure that the author hasn't produced them by > himself. We are not sure where he got them from and under what terms. If > I get a tarball from someone under the GPL, I look at it briefly and see > who produced it and that it is in fact licensed by the GPL. Barring any > clues that suggest otherwise I will take that as a fact. As soon as > there is some indication that this doesn't cover the whole package I > will have to rethink which is what we do now, it is my responsibility to > do so. Doesn't contradict with what I wrote above. > > Similarly, his > > other work (game design/concept) could be challenged, too. This gets more > > interesting with regard to potentially patented technology, an area where > > FUD strategies are very successful. > > This is similar with patents. If I don't think a certain piece of > software could be endangered by a patent, I won't act as if it were. If > people tell me that package foo could violate a patent that's where some > investigation is due. > > Nils The result of the investigation is the interesting bit. We've yet to deal with some example cases, including _rumours_ of patent claims. From nphilipp at redhat.com Fri Feb 11 15:56:20 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 11 Feb 2005 16:56:20 +0100 Subject: New candidates for inclusion in Extras : udftools and starfighter-music In-Reply-To: <20050211142137.64088c03.fedora@wir-sind-cool.org> References: <20050207131917.44e53bb8@python2> <20050207135420.773a2b08.fedora@wir-sind-cool.org> <1108049173.28783.20.camel@wombat.tiptoe.de> <20050210190953.7e156b14.fedora@wir-sind-cool.org> <1108114363.455.34.camel@gibraltar.stuttgart.redhat.com> <20050211114705.5abeebf8.fedora@wir-sind-cool.org> <1108125003.455.64.camel@gibraltar.stuttgart.redhat.com> <20050211142137.64088c03.fedora@wir-sind-cool.org> Message-ID: <1108137381.455.78.camel@gibraltar.stuttgart.redhat.com> On Fri, 2005-02-11 at 14:21 +0100, Michael Schwendt wrote: > On Fri, 11 Feb 2005 13:30:03 +0100, Nils Philippsen wrote: [...] > I've submitted a query about licencing issues in a different package > into the legal queue a few days ago. "legal queue" -- care to explain? I can't seem to find a fedora-legal- list yet ;-). > > It's not the MOD format that we're discussing, it's including MODs (or > > derived files, in fact the format is completely irrelevant as is whether > > it is software or artwork or whatnot) where we don't know where they > > come from, i.e. don't know who produced them initially, under what terms > > they were released, etc. > > The format suffers from similar problems. Or where do you see a > difference? (I don't know how much you know about .mod history.) Not much. My knowledge about MODs can be summed up like "something like a MIDI score along with the instrument samples" and that it originated on the Amiga. Well, I had an ST at that time so forgive my ignorance ;-). > > > > Here, an accidental finding lead to discovering an unknown copyright > > > situation of music files. It is assumed that the author of the game took > > > music files he's not permitted to use and redistribute. > > > > Not quite. We are fairly sure that the author hasn't produced them by > > himself. We are not sure where he got them from and under what terms. If > > I get a tarball from someone under the GPL, I look at it briefly and see > > who produced it and that it is in fact licensed by the GPL. Barring any > > clues that suggest otherwise I will take that as a fact. As soon as > > there is some indication that this doesn't cover the whole package I > > will have to rethink which is what we do now, it is my responsibility to > > do so. > > Doesn't contradict with what I wrote above. What I meant to say was that I don't automatically assume that the author didn't have permission to do what he did, but that the odds for it seem to be considerably higher suddenly. > > > Similarly, his > > > other work (game design/concept) could be challenged, too. This gets more > > > interesting with regard to potentially patented technology, an area where > > > FUD strategies are very successful. > > > > This is similar with patents. If I don't think a certain piece of > > software could be endangered by a patent, I won't act as if it were. If > > people tell me that package foo could violate a patent that's where some > > investigation is due. > > > > Nils > > The result of the investigation is the interesting bit. We've yet to deal > with some example cases, including _rumours_ of patent claims. Well I'd say it depends how much substance is behind such a rumour -- allegations of patent problems have so much more weight with patent numbers behind them. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From adrian at lisas.de Fri Feb 11 18:30:44 2005 From: adrian at lisas.de (Adrian Reber) Date: Fri, 11 Feb 2005 19:30:44 +0100 Subject: fbida build fix In-Reply-To: <1108115519.20510.3.camel@localhost.localdomain> References: <1108115519.20510.3.camel@localhost.localdomain> Message-ID: <20050211183044.GA20763@lisas.de> On Fri, Feb 11, 2005 at 09:51:59AM +0000, David Woodhouse wrote: > This makes fbida build. There a are bunch of other build failures which > I could work around by setting _unpackaged_files_terminate_build to > zero, but I don't want to do that. I'm far too lazy to mail the owners > of individual packages separately -- shall I just go and fix them to > remove or package the files as I see fit? I have changed it to include ida in a subpackage and therefore there is no dependency on motif if you only want to use fbi (which was the reason to build the package without motif support). I have checked in my changes as well as an update to a new version. Adrian From gauret at free.fr Fri Feb 11 14:28:57 2005 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 11 Feb 2005 15:28:57 +0100 Subject: New package for review : plone References: <20050211121347.07592331@python2> <20050211133934.37ec5b33@python2> Message-ID: Matthias Saou wrote: > You're using tabs for the "URL:" line whereas the others use spaces... you > should try to keep consistent. This is the main reason why I don't try to > keep all of those headers aligned in my own spec files. And seeing the > amount of spec files out there that mix tabs and spaces, and become > unreadable if you're not using the author's tab spacing setting (i.e. 4 > vs. 8 spaces), I'm definitely not about to change this. It's because I used an existing spec file, and I did not convert the URL tag to spaces. I like spaces, and my vim is set to 1 tab = 4 spaces (python standard). I'll change the tab into spaces, but that will be for the next release if you don't mind too much :) Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info A Black Hole is where God divided by zero. From dwmw2 at infradead.org Fri Feb 11 21:27:05 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 11 Feb 2005 21:27:05 +0000 Subject: fbida build fix In-Reply-To: <20050211183044.GA20763@lisas.de> References: <1108115519.20510.3.camel@localhost.localdomain> <20050211183044.GA20763@lisas.de> Message-ID: <1108157225.4542.3.camel@localhost.localdomain> On Fri, 2005-02-11 at 19:30 +0100, Adrian Reber wrote: >I have changed it to include ida in a subpackage and therefore there is >no dependency on motif if you only want to use fbi (which was the reason >to build the package without motif support). I have checked in my >changes as well as an update to a new version. Looks good to me... thanks. Wrote: /home/dwmw2/working/extras/devel/fbida/fbida-2.03-1.src.rpm Wrote: /home/dwmw2/working/extras/devel/fbida/ppc/fbida-2.03-1.ppc.rpm Wrote: /home/dwmw2/working/extras/devel/fbida/ppc/fbida-ida-2.03-1.ppc.rpm Wrote: /home/dwmw2/working/extras/devel/fbida/ppc/fbida-fbgs-2.03-1.ppc.rpm Wrote: /home/dwmw2/working/extras/devel/fbida/ppc/fbida-debuginfo-2.03-1.ppc.rpm -- dwmw2 From fedora at wir-sind-cool.org Fri Feb 11 21:41:26 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 11 Feb 2005 22:41:26 +0100 Subject: fbida build fix In-Reply-To: <20050211183044.GA20763@lisas.de> References: <1108115519.20510.3.camel@localhost.localdomain> <20050211183044.GA20763@lisas.de> Message-ID: <20050211224126.138c9822.fedora@wir-sind-cool.org> On Fri, 11 Feb 2005 19:30:44 +0100, Adrian Reber wrote: > On Fri, Feb 11, 2005 at 09:51:59AM +0000, David Woodhouse wrote: > > This makes fbida build. There a are bunch of other build failures which > > I could work around by setting _unpackaged_files_terminate_build to > > zero, but I don't want to do that. I'm far too lazy to mail the owners > > of individual packages separately -- shall I just go and fix them to > > remove or package the files as I see fit? > > I have changed it to include ida in a subpackage and therefore there is > no dependency on motif if you only want to use fbi (which was the reason > to build the package without motif support). I have checked in my > changes as well as an update to a new version. --- fbida.spec.~1.2.~ 2005-02-11 22:37:31.000000000 +0100 +++ fbida.spec 2005-02-11 22:38:02.397946392 +0100 @@ -67,11 +67,13 @@ %{_bindir}/exiftran %files ida +%defattr(-, root, root, -) %doc %{_mandir}/man1/ida* %{_bindir}/ida %config /usr/X11R6/lib/X11/app-defaults/Ida %files fbgs +%defattr(-, root, root, -) %doc %{_mandir}/man1/fbgs* %{_bindir}/fbgs From wtogami at redhat.com Sat Feb 12 03:29:02 2005 From: wtogami at redhat.com (Warren Togami) Date: Fri, 11 Feb 2005 17:29:02 -1000 Subject: Please Follow Procedure, Use CVS comments Message-ID: <420D77FE.6010401@redhat.com> gemi and Everyone, Why was unison and yap requested for build? There has been no request on fedora-extras-list for package review, and no APPROVED message on fedora-extras-commits showing that somebody reviewed it. (I'm currently using prolog in one of my classes, so I'm interested in your pl package. I am reviewing that one now.) https://www.redhat.com/archives/fedora-extras-list/2005-February/msg00208.html Please follow the Interim New Package Process. This is also a reminder to everyone, please use CVS commit comments when you commit any change. Warren Togami wtogami at redhat.com From wtogami at redhat.com Sat Feb 12 01:12:09 2005 From: wtogami at redhat.com (Warren Togami) Date: Fri, 11 Feb 2005 15:12:09 -1000 Subject: Review of pl package, big problems... Message-ID: <420D57E9.6070403@redhat.com> Big looking failure here, why isn't the build aborting on failure? gcc -c -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 -Wall -fPIC -DHAVE_CONFIG_H -I/home/builder5/rpmbuild/BUILD/pl-5.4.5/include -I../../src -I../../src -DSWI -DHAVE_CONFIG_H pcecall.c -o ../../src/pl/pcecall.o gmake[4]: Entering directory `/home/builder5/rpmbuild/BUILD/pl-5.4.5/packages/xpce/pl/src' LD_RUN_PATH="/usr/lib:$LD_RUN_PATH"; \ export LD_RUN_PATH; \ /home/builder5/rpmbuild/BUILD/pl-5.4.5/src/plld -shared -L/usr/X11R6/lib -export-dynamic -O3 -pthread ../../src/pl/so-interface.o ../../src/pl/pcecall.o -L../../src \ -lXPCE /usr/lib/gcc/i386-redhat-linux/3.4.2/libgcc.a -L/usr/X11R6/lib -lXpm -ljpeg -lXt -lX11 -lSM -lICE -o ../../src/pl2xpce.so; sh: pl: command not found sh: -c: line 0: syntax error near unexpected token `(' sh: -c: line 0: `gcc -o ../../src/pl2xpce.so -shared ../../src/pl/so-interface.o ../../src/pl/pcecall.o /usr/lib/gcc/i386-redhat-linux/3.4.2/libgcc.a -L(null)/lib/(null) -L/usr/X11R6/lib -L../../src -L/usr/X11R6/lib -lXPCE -lXpm -ljpeg -lXt -lX11 -lSM -lICE' gcc returned code 512 *** /home/builder5/rpmbuild/BUILD/pl-5.4.5/src/plld exit status 1 gmake[4]: *** [axpce../../src/pl2xpce.so] Error 1 gmake[4]: Leaving directory `/home/builder5/rpmbuild/BUILD/pl-5.4.5/packages/xpce/pl/src' gmake[3]: *** [../../src/pl2xpce.so] Error 2 gmake[3]: Leaving directory `/home/builder5/rpmbuild/BUILD/pl-5.4.5/packages/xpce/pl/src' gmake[2]: *** [pl-itf] Error 2 gmake[2]: Leaving directory `/home/builder5/rpmbuild/BUILD/pl-5.4.5/packages/xpce/src' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/builder5/rpmbuild/BUILD/pl-5.4.5/packages/xpce' gmake[1]: Entering directory `/home/builder5/rpmbuild/BUILD/pl-5.4.5/packages/sgml' Smaller failure here: gmake[1]: Entering directory `/home/builder5/rpmbuild/BUILD/pl-5.4.5/packages/cpp' /usr/bin/install -c -m 644 pl2cpp.html /var/tmp/pl-5.4.5-1-root-builder5/usr/lib/pl-5.4.5/doc/packages /usr/bin/install: cannot create regular file `/var/tmp/pl-5.4.5-1-root-builder5/usr/lib/pl-5.4.5/doc/packages': No such file or directory gmake[1]: *** [html-install] Error 1 gmake[1]: Leaving directory `/home/builder5/rpmbuild/BUILD/pl-5.4.5/packages/cpp' gmake[1]: Entering directory `/home/builder5/rpmbuild/BUILD/pl-5.4.5/packages/xpce' Then fails in a seemingly infinite loop, which would cause real trouble if we had an automated build system. /home/builder5/rpmbuild/BUILD/pl-5.4.5/packages/xpce/src/rel-ln /var/tmp/pl-5.4.5-1-root-builder5/usr/lib/pl-5.4.5/bin/i686-linux-gnu/pl /var/tmp/pl-5.4.5-1-root-builder5/usr/bin/xpce ./xpce-install -m 755 xpce-client /var/tmp/pl-5.4.5-1-root-builder5/usr/bin /var/tmp/pl-5.4.5-1-root-builder5/usr/lib/pl-5.4.5/bin/i686-linux-gnu/pl \ -F none \ -f ../pl/src/plrc \ -g "[library('man/man_index')],pce_make_manual_index('../man/reference/index.obj')" \ -t halt % /home/builder5/rpmbuild/BUILD/pl-5.4.5/packages/xpce/pl/src/plrc compiled into link_xpce 0.00 sec, 6,572 bytes ERROR: (/var/tmp/pl-5.4.5-1-root-builder5/usr/lib/pl-5.4.5/xpce/prolog/boot/pce_principal.pl:104): pl2xpce: cannot open shared object file: No such file or directory Warning: (/var/tmp/pl-5.4.5-1-root-builder5/usr/lib/pl-5.4.5/xpce/prolog/boot/pce_principal.pl:104): Goal (directive) failed: pce_principal: (initialization pce_host:$load_pce) ERROR: exception handler failed to define predicate pce:object/1 ERROR: exception handler failed to define predicate pce:send/2 Warning: (/var/tmp/pl-5.4.5-1-root-builder5/usr/lib/pl-5.4.5/xpce/prolog/boot/pce_principal.pl:428): Goal (directive) failed: pce_principal: (initialization object(@prolog)->true;send(@host, name_reference, prolog)) ERROR: Exported procedure pce_principal:new/2 is not defined ERROR: Exported procedure pce_principal:object/2 is not defined ERROR: Exported procedure pce_principal:send_class/3 is not defined ERROR: Exported procedure pce_principal:pce_method_implementation/2 is not defined ERROR: Exported procedure pce_principal:get_class/4 is not defined ERROR: Exported procedure pce_principal:in_pce_thread/1 is not defined ERROR: Exported procedure pce_principal:pce_dispatch/1 is not defined ERROR: Exported procedure pce_principal:get/3 is not defined ERROR: Exported procedure pce_principal:pce_call/1 is not defined ERROR: Exported procedure pce_principal:pce_end_dispatch/0 is not defined ERROR: Exported procedure pce_principal:pce_open/3 is not defined ERROR: exception handler failed to define predicate pce:send/2 From gemi at bluewin.ch Sat Feb 12 02:19:32 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Sat, 12 Feb 2005 03:19:32 +0100 Subject: Review of pl package, big problems... In-Reply-To: <420D57E9.6070403@redhat.com> References: <420D57E9.6070403@redhat.com> Message-ID: <1108174772.23435.2.camel@scriabin.tannenrauch.ch> On Fri, 2005-02-11 at 15:12 -1000, Warren Togami wrote: > Big looking failure here, why isn't the build aborting on failure? Ok, I now have a (seemingly) working build. At least "manpce." works in the pl cli. However I think, that some testing would be in order. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From wtogami at redhat.com Sat Feb 12 02:40:45 2005 From: wtogami at redhat.com (Warren Togami) Date: Fri, 11 Feb 2005 16:40:45 -1000 Subject: Review of pl package, big problems... In-Reply-To: <1108174772.23435.2.camel@scriabin.tannenrauch.ch> References: <420D57E9.6070403@redhat.com> <1108174772.23435.2.camel@scriabin.tannenrauch.ch> Message-ID: <420D6CAD.3040501@redhat.com> G?rard Milmeister wrote: > On Fri, 2005-02-11 at 15:12 -1000, Warren Togami wrote: > >>Big looking failure here, why isn't the build aborting on failure? > > > Ok, I now have a (seemingly) working build. At least "manpce." works > in the pl cli. However I think, that some testing would be in order. Possible inconsistency in package. Either disable it explicitly with a ./configure option or add the BuildRequires. checking for timegm... yes ERROR: Cannot find odbc library or the header sql.h WARNING: ODBC interface will not be build configure: creating ./config.status config.status: creating Makefile config.status: creating config.h Build failure ... config.status: creating config.h + make 'COFLAGS=-O2 -g -pipe -m32 -march=i386 -mtune=pentium4' for p in clib cpp odbc table xpce sgml sgml/RDF semweb http chr ssl; do \ if [ -r $p/Makefile ]; then ( cd $p && gmake ); fi; \ done gmake[1]: Entering directory `/home/builder5/rpmbuild/BUILD/pl-5.4.6/packages/clib' ../plld.sh -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 -Wall -fpic -I. -DHAVE_CONFIG_H -c -o error.o error.c error.c: In function `pl_error': error.c:78: warning: unused variable `argn' ../plld.sh -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 -Wall -fpic -I. -DHAVE_CONFIG_H -c -o process.o process.c Yikes, empty RPATH is very bad. This must be fixed. extracting debug info from /var/tmp/pl-5.4.6-1-root-builder5/usr/bin/xpce-client 12230 blocks + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot ERROR: file '/usr/lib/pl-5.4.6/xpce-6.4.3/lib/i686-linux-gnu/pl2xpce.so' contains a standard rpath '/usr/lib' in [/usr/lib:] ERROR: file '/usr/lib/pl-5.4.6/xpce-6.4.3/lib/i686-linux-gnu/pl2xpce.so' contains an empty rpath in [/usr/lib:] error: Bad exit status from /var/tmp/rpm-tmp.51872 (%install) https://www.redhat.com/archives/fedora-extras-list/2005-February/msg00295.html Please follow the instructions here to add check-buildroot and check-rpaths to your rpmbuild. Warren Togami wtogami at redhat.com From fedora at wir-sind-cool.org Sat Feb 12 02:56:54 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 12 Feb 2005 03:56:54 +0100 Subject: Review of pl package, big problems... In-Reply-To: <420D6CAD.3040501@redhat.com> References: <420D57E9.6070403@redhat.com> <1108174772.23435.2.camel@scriabin.tannenrauch.ch> <420D6CAD.3040501@redhat.com> Message-ID: <20050212035654.39290e59.fedora@wir-sind-cool.org> On Fri, 11 Feb 2005 16:40:45 -1000, Warren Togami wrote: > G?rard Milmeister wrote: > > On Fri, 2005-02-11 at 15:12 -1000, Warren Togami wrote: > > > >>Big looking failure here, why isn't the build aborting on failure? > > > > > > Ok, I now have a (seemingly) working build. At least "manpce." works > > in the pl cli. However I think, that some testing would be in order. > > Possible inconsistency in package. Either disable it explicitly with a > ./configure option or add the BuildRequires. > > > checking for timegm... yes > ERROR: Cannot find odbc library or the header sql.h > WARNING: ODBC interface will not be build The spec %changelog should cover that "Buildrequires: unixODBC" was added. Most likely should be unixODBC-devel instead. Such details ought to be mentioned in the changelog. From fedora at wir-sind-cool.org Sat Feb 12 03:09:19 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 12 Feb 2005 04:09:19 +0100 Subject: wxPython - Re: Fedora Extras Package Updates In-Reply-To: References: <1108097253.5782.5.camel@cutter> <20050211105402.3189f656.fedora@wir-sind-cool.org> Message-ID: <20050212040919.4ecabd42.fedora@wir-sind-cool.org> On Fri, 11 Feb 2005 13:25:49 +0200 (EET), Panu Matilainen wrote: > On Fri, 11 Feb 2005, Michael Schwendt wrote: > > On Fri, 11 Feb 2005 09:56:40 +0200 (EET), Panu Matilainen wrote: > > > >> On Thu, 10 Feb 2005, seth vidal wrote: > >>> Some busy packagers today. Lots of new/updated stuff. > >>> wxPython (x86, x86_64) > >>> wxPythonGTK2 (x86, x86_64) As an update here, wxPython _cannot_ be killed yet as bittorrent-gui still requires it. Yes, explicitly. From fedora at wir-sind-cool.org Sat Feb 12 03:24:54 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 12 Feb 2005 04:24:54 +0100 Subject: wxPython - Re: Fedora Extras Package Updates In-Reply-To: <20050212040919.4ecabd42.fedora@wir-sind-cool.org> References: <1108097253.5782.5.camel@cutter> <20050211105402.3189f656.fedora@wir-sind-cool.org> <20050212040919.4ecabd42.fedora@wir-sind-cool.org> Message-ID: <20050212042454.59934ca0.fedora@wir-sind-cool.org> On Sat, 12 Feb 2005 04:09:19 +0100, Michael Schwendt wrote: > On Fri, 11 Feb 2005 13:25:49 +0200 (EET), Panu Matilainen wrote: > > > On Fri, 11 Feb 2005, Michael Schwendt wrote: > > > On Fri, 11 Feb 2005 09:56:40 +0200 (EET), Panu Matilainen wrote: > > > > > >> On Thu, 10 Feb 2005, seth vidal wrote: > > >>> Some busy packagers today. Lots of new/updated stuff. > > >>> wxPython (x86, x86_64) > > >>> wxPythonGTK2 (x86, x86_64) > > As an update here, wxPython _cannot_ be killed yet as bittorrent-gui > still requires it. Yes, explicitly. False alarm. wxPythonGTK2 provides wxPython, too. So I deleted the files in CVS. From skvidal at fedoraproject.org Sat Feb 12 08:12:14 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Sat, 12 Feb 2005 03:12:14 -0500 Subject: Fedora Extras Package Updates Message-ID: <1108195934.3823.15.camel@cutter> Hi all, putty (i386, x86_64) - Fixes Security hole logjam (i386, x86_64) - new version plone (i386, x86_64) - first package python-imaging (i386, x86_64) perl-Net-Server (i386, x86_64) sirius (i386, x86_64) TeXmacs (i386, x86_64) antiword (i386, x86_64) fbida (i386, x86_64) ocaml (i386, x86_64) Status page: http://fedoraproject.org/wiki/Extras_2fFC3Status Follow updates and new packages at: http://fedoraproject.org/infofeed/ Report problems at Bugzilla: http://bugzilla.redhat.com/ thanks, -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Sat Feb 12 15:45:37 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 12 Feb 2005 15:45:37 +0000 Subject: Fedora extras PPC build status Message-ID: <1108223137.7436.6.camel@localhost.localdomain> I've thrown together a few scripts so the results of my PPC builds from CVS are visible (on the Legacy Internet now as well as on IPv6) at http://peach.infradead.org/extras/ You can see just the failed builds, and the logs thereof, at http://peach.infradead.org/extras/failed.html -- dwmw2 From fedora at wir-sind-cool.org Sat Feb 12 16:14:43 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 12 Feb 2005 17:14:43 +0100 Subject: Please Follow Procedure, Use CVS comments In-Reply-To: <420D77FE.6010401@redhat.com> References: <420D77FE.6010401@redhat.com> Message-ID: <20050212171443.70fd5d54.fedora@wir-sind-cool.org> On Fri, 11 Feb 2005 17:29:02 -1000, Warren Togami wrote: > gemi and Everyone, > > Why was unison and yap requested for build? There has been no request > on fedora-extras-list for package review, and no APPROVED message on > fedora-extras-commits showing that somebody reviewed it. > > (I'm currently using prolog in one of my classes, so I'm interested in > your pl package. I am reviewing that one now.) > > https://www.redhat.com/archives/fedora-extras-list/2005-February/msg00208.html > Please follow the Interim New Package Process. > > This is also a reminder to everyone, please use CVS commit comments when > you commit any change. I'd also like to point out that a quick succession of "commit, request build in wiki, built and published" makes extras-commits list useless. Once built and published, any comments would be too late. Before requesting a build, better give your package changes another look and test-build them in a clean environment, too. It's not like version upgrades and major package changes require urgent builds. Waiting a day and giving list observers the chance to comment on changes would be better in the beginning. From fedora at wir-sind-cool.org Sat Feb 12 16:16:45 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 12 Feb 2005 17:16:45 +0100 Subject: Please Follow Procedure, Use CVS comments In-Reply-To: <420D77FE.6010401@redhat.com> References: <420D77FE.6010401@redhat.com> Message-ID: <20050212171645.3005a1cc.fedora@wir-sind-cool.org> Further, it is a good idea to subscribe to commits-list and to the FC3Status page in the wiki and observe the build/bug related activity on it. From fedora at leemhuis.info Sat Feb 12 16:57:40 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 12 Feb 2005 17:57:40 +0100 Subject: Please Follow Procedure, Use CVS comments In-Reply-To: <20050212171443.70fd5d54.fedora@wir-sind-cool.org> References: <420D77FE.6010401@redhat.com> <20050212171443.70fd5d54.fedora@wir-sind-cool.org> Message-ID: <1108227460.6643.27.camel@localhost.localdomain> Am Samstag, den 12.02.2005, 17:14 +0100 schrieb Michael Schwendt: > On Fri, 11 Feb 2005 17:29:02 -1000, Warren Togami wrote: > > > gemi and Everyone, > > > > Why was unison and yap requested for build? There has been no request > > on fedora-extras-list for package review, and no APPROVED message on > > fedora-extras-commits showing that somebody reviewed it. > > > > (I'm currently using prolog in one of my classes, so I'm interested in > > your pl package. I am reviewing that one now.) > > > > https://www.redhat.com/archives/fedora-extras-list/2005-February/msg00208.html > > Please follow the Interim New Package Process. > > > > This is also a reminder to everyone, please use CVS commit comments when > > you commit any change. > > I'd also like to point out that a quick succession of "commit, request > build in wiki, built and published" makes extras-commits list useless. > Once built and published, any comments would be too late. Before > requesting a build, better give your package changes another look and > test-build them in a clean environment, too. It's not like version > upgrades and major package changes require urgent builds. Waiting a day > and giving list observers the chance to comment on changes would be better > in the beginning. Okay, shame on me, I did this also. But to make this whole situation a bit easier: Is there any reason why the Interim New Package Process is not yet in the wiki (or did I overlook it?)? If no one has objections I'm going to import it in the next days. -- Thorsten Leemhuis From ville.skytta at iki.fi Sat Feb 12 18:00:34 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 12 Feb 2005 20:00:34 +0200 Subject: Fedora extras PPC build status In-Reply-To: <1108223137.7436.6.camel@localhost.localdomain> References: <1108223137.7436.6.camel@localhost.localdomain> Message-ID: <1108231234.5281.253.camel@bobcat.mine.nu> On Sat, 2005-02-12 at 15:45 +0000, David Woodhouse wrote: > I've thrown together a few scripts so the results of my PPC builds from > CVS are visible (on the Legacy Internet now as well as on IPv6) at > http://peach.infradead.org/extras/ Thanks David, this is great stuff! It'd be nice to have this output available for x86 and x86_64 too... volunteers? From gene at czarc.net Sat Feb 12 18:23:37 2005 From: gene at czarc.net (Gene Czarcinski) Date: Sat, 12 Feb 2005 13:23:37 -0500 Subject: package criteria Message-ID: <200502121323.37373.gene@czarc.net> My question: What types of packages should be in Fedora Extras? I understand the intent is that some of the "less popular" packages now part of Fedora Core will be moved to Fedora Extras. However, what other types of packages should be added to Fedora Extras? Obviously, only packages which are fully GPL, LGPL, or at least BSD licensed should be included and I would also say: no binary-only software packages. However, there are a number of other repositories such as freshrpms, ATrpms, and DAG which have a large number of packages. Should some, a lot, all, or ??? of these packages be moved up from these (more or less single individual maintained) repositories to the multi maintained Fedora Extras? A case in point that I came across is the partimage package. I recently had the need to be able to "image" the harddisk on a laptop. Furthermore, the "restore" had to be from a DVD. After spending more time than I wished trying both a commercial package and something called "Mondo Rescue", I found that partimage worked and met my requirements. Currently, partimage is available on the DAG repository. Should partimage be included in Fedora Extras? The partimage package appears to be included in some other distributions such as mandrake and debian and I, personally, believe it is a good package. However, there has been little recent development activity and it may be orphaned. In the absence of anyone better qualified willing to do it, I would be willing to take on package responsibility (DAG might be much better since he is already doing it for his own repository). I have some experience writing/debugging C programs but only a little experience with C++ and partimage is written in C++. Comments? Is partimage a good candidate for Fedora Extras or should we avoid it? Again, what types of packages are "good" candidates? Gene From dwmw2 at infradead.org Sat Feb 12 18:24:02 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 12 Feb 2005 18:24:02 +0000 Subject: Fedora extras PPC build status In-Reply-To: <1108231234.5281.253.camel@bobcat.mine.nu> References: <1108223137.7436.6.camel@localhost.localdomain> <1108231234.5281.253.camel@bobcat.mine.nu> Message-ID: <1108232642.7436.17.camel@localhost.localdomain> On Sat, 2005-02-12 at 20:00 +0200, Ville Skytt? wrote: >Thanks David, this is great stuff! > >It'd be nice to have this output available for x86 and x86_64 too... >volunteers? The scripts are only a quick hack, but they're in CVS if you want them: cvs -d :pserver:anoncvs at cvs.infradead.org:/home/cvs login (password: anoncvs) cvs -d :pserver:anoncvs at cvs.infradead.org:/home/cvs co extras-scripts -- dwmw2 From skvidal at phy.duke.edu Sat Feb 12 18:28:38 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 12 Feb 2005 13:28:38 -0500 Subject: Please Follow Procedure, Use CVS comments In-Reply-To: <1108227460.6643.27.camel@localhost.localdomain> References: <420D77FE.6010401@redhat.com> <20050212171443.70fd5d54.fedora@wir-sind-cool.org> <1108227460.6643.27.camel@localhost.localdomain> Message-ID: <1108232918.3823.32.camel@cutter> >Okay, shame on me, I did this also. > >But to make this whole situation a bit easier: Is there any reason why >the Interim New Package Process is not yet in the wiki (or did I >overlook it?)? If no one has objections I'm going to import it in the >next days. we'll be making some more decisions at fudcon about 'policies and procedures'. Hold off on adding new, potentially invalid things to the wiki. :) -sv From skvidal at phy.duke.edu Sat Feb 12 18:38:09 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 12 Feb 2005 13:38:09 -0500 Subject: Fedora extras PPC build status In-Reply-To: <1108231234.5281.253.camel@bobcat.mine.nu> References: <1108223137.7436.6.camel@localhost.localdomain> <1108231234.5281.253.camel@bobcat.mine.nu> Message-ID: <1108233489.3823.40.camel@cutter> On Sat, 2005-02-12 at 20:00 +0200, Ville Skytt? wrote: >On Sat, 2005-02-12 at 15:45 +0000, David Woodhouse wrote: >> I've thrown together a few scripts so the results of my PPC builds from >> CVS are visible (on the Legacy Internet now as well as on IPv6) at >> http://peach.infradead.org/extras/ > >Thanks David, this is great stuff! > >It'd be nice to have this output available for x86 and x86_64 too... >volunteers? > hell, it'd be nice to have the buildsystem we were told we'd have months ago. -sv From fedora at wir-sind-cool.org Sat Feb 12 18:51:59 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 12 Feb 2005 19:51:59 +0100 Subject: partimage (was: Re: package criteria) In-Reply-To: <200502121323.37373.gene@czarc.net> References: <200502121323.37373.gene@czarc.net> Message-ID: <20050212195159.54223fd8.fedora@wir-sind-cool.org> On Sat, 12 Feb 2005 13:23:37 -0500, Gene Czarcinski wrote: > Currently, partimage is available on the DAG repository. Should partimage be > included in Fedora Extras? The partimage package appears to be included in > some other distributions such as mandrake and debian and I, personally, > believe it is a good package. However, there has been little recent > development activity and it may be orphaned. Please join here: https://bugzilla.fedora.us/show_bug.cgi?id=518 From fedora at wir-sind-cool.org Sat Feb 12 17:58:48 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 12 Feb 2005 18:58:48 +0100 Subject: Please Follow Procedure, Use CVS comments In-Reply-To: <1108227460.6643.27.camel@localhost.localdomain> References: <420D77FE.6010401@redhat.com> <20050212171443.70fd5d54.fedora@wir-sind-cool.org> <1108227460.6643.27.camel@localhost.localdomain> Message-ID: <20050212185848.60608291.fedora@wir-sind-cool.org> On Sat, 12 Feb 2005 17:57:40 +0100, Thorsten Leemhuis wrote: > Am Samstag, den 12.02.2005, 17:14 +0100 schrieb Michael Schwendt: > > On Fri, 11 Feb 2005 17:29:02 -1000, Warren Togami wrote: > > > > > gemi and Everyone, > > > > > > Why was unison and yap requested for build? There has been no request > > > on fedora-extras-list for package review, and no APPROVED message on > > > fedora-extras-commits showing that somebody reviewed it. > > > > > > (I'm currently using prolog in one of my classes, so I'm interested in > > > your pl package. I am reviewing that one now.) > > > > > > https://www.redhat.com/archives/fedora-extras-list/2005-February/msg00208.html > > > Please follow the Interim New Package Process. > > > > > > This is also a reminder to everyone, please use CVS commit comments when > > > you commit any change. > > > > I'd also like to point out that a quick succession of "commit, request > > build in wiki, built and published" makes extras-commits list useless. > > Once built and published, any comments would be too late. Before > > requesting a build, better give your package changes another look and > > test-build them in a clean environment, too. It's not like version > > upgrades and major package changes require urgent builds. Waiting a day > > and giving list observers the chance to comment on changes would be better > > in the beginning. > > Okay, shame on me, I did this also. I see a big difference between build fixes/security fixes and version upgrades, which sometimes apply big package changes (lots of activity in the spec and build requirements). We're kind of running CVS in rawhide-style, so I don't care whether a build fix release is followed by a version upgrade the other day. I'm mildly annoyed when fedora.us QA process was criticised, but a jump to a QA-less process seems to result in chaos. Without QA, and without a release manager's added pair of eyes, the packagers must do a lot more QA themselves. Also taking care that individual package upgrades don't break repository integrity (gemi's ocaml related packages, for example, depend on eachother and should only be published if all of them build and work together). I would also avoid using Seth Vidal as a trial-and-error build slave for i386. x86_64 is an exception, but you and Aurelien have offered to help with test-builds there, too. > But to make this whole situation a bit easier: Is there any reason why > the Interim New Package Process is not yet in the wiki (or did I > overlook it?)? If no one has objections I'm going to import it in the > next days. It's not as if there are any contributors with CVS access left who haven't seen Warren's message and the example approvals of new packages. FWIW, I consider this list the preferred channel for such announcements and related discussion of it. Modifications applied in the Wiki are overlooked easily and cause more confusion. We need a primary channel on which to address contributors. When something's carved in stone, it makes sense to publish it in some prominent place. Who knows? Maybe FUDCon will change this interim process already? The "testing" and "development" repositories should not be forgotten either. From fedora at wir-sind-cool.org Sat Feb 12 18:20:26 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 12 Feb 2005 19:20:26 +0100 Subject: Fedora extras PPC build status In-Reply-To: <1108223137.7436.6.camel@localhost.localdomain> References: <1108223137.7436.6.camel@localhost.localdomain> Message-ID: <20050212192026.37884bd7.fedora@wir-sind-cool.org> On Sat, 12 Feb 2005 15:45:37 +0000, David Woodhouse wrote: > I've thrown together a few scripts so the results of my PPC builds from > CVS are visible (on the Legacy Internet now as well as on IPv6) at > http://peach.infradead.org/extras/ > > You can see just the failed builds, and the logs thereof, at > http://peach.infradead.org/extras/failed.html Great list! Save yourself build attempts of packages with "0.fdr" in the release version. I'm going to see if any old ones are left and need to be disabled temporarily or removed. unison, pl and yap have no build approval. Feel free to test-build them if that helps. From ville.skytta at iki.fi Sat Feb 12 19:24:51 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 12 Feb 2005 21:24:51 +0200 Subject: partimage (was: Re: package criteria) In-Reply-To: <20050212195159.54223fd8.fedora@wir-sind-cool.org> References: <200502121323.37373.gene@czarc.net> <20050212195159.54223fd8.fedora@wir-sind-cool.org> Message-ID: <1108236291.5281.287.camel@bobcat.mine.nu> On Sat, 2005-02-12 at 19:51 +0100, Michael Schwendt wrote: > On Sat, 12 Feb 2005 13:23:37 -0500, Gene Czarcinski wrote: > > > Currently, partimage is available on the DAG repository. Should partimage be > > included in Fedora Extras? The partimage package appears to be included in > > some other distributions such as mandrake and debian and I, personally, > > believe it is a good package. However, there has been little recent > > development activity and it may be orphaned. > > Please join here: > https://bugzilla.fedora.us/show_bug.cgi?id=518 Gotchas about partimage, some apply to partition backup/restore software in general: In order to be able to backup partitions, they must usually be unmounted. And obviously, incompatible changes between versions in backup/restore software are a no go; I've heard of such changes in partimage. There's a partition image server included in the partimage package, but it's pretty damn fugly (ditto the rest of the package's contents, FWIW), and is of doubtful usefulness because NFS/SMB/$younameit mounts work well enough for storing the backups. Given those limitations, I'm not sure if it makes sense to include partimage in Extras. Feel free to disagree, but be also prepared to take package maintainership :) If nobody steps up, I'll close the above b.f.u submission soon(tm). partimage is not at all useless, but IMO it's better off used from somewhere else than the base distro (includes Extras in this context). I've used it with good results from a Knoppix CD, where the mountedness of partitions to be backed up is not a problem, nor can any version changes occur as long as one keeps the same ISO/CD handy. From wtogami at redhat.com Sat Feb 12 19:52:04 2005 From: wtogami at redhat.com (Warren Togami) Date: Sat, 12 Feb 2005 09:52:04 -1000 Subject: Review of pl package, big problems... In-Reply-To: <20050212035654.39290e59.fedora@wir-sind-cool.org> References: <420D57E9.6070403@redhat.com> <1108174772.23435.2.camel@scriabin.tannenrauch.ch> <420D6CAD.3040501@redhat.com> <20050212035654.39290e59.fedora@wir-sind-cool.org> Message-ID: <420E5E64.7010600@redhat.com> Build of pl on x86_64 seems to work, except it installs everything into /usr/lib. It is likely that the Makefile needs patching for "make install" to work properly. Warren Togami wtogami at redhat.com From moe at blagblagblag.org Sat Feb 12 20:08:32 2005 From: moe at blagblagblag.org (jeff) Date: Sat, 12 Feb 2005 13:08:32 -0700 Subject: RFI: pstoedit for inkscape Message-ID: <200502121308.32733.moe@blagblagblag.org> inkscape would like to use pstoedit to import/export postscript docs. Run inkscape (0.41 in this case) and see ~/.inkscape/extension-errors.log -------- Extension "Postscript Input" failed to load because a dependency was not met. Dependency:: type: executable location: path string: pstoedit ... -------- See also: https://bugzilla.fedora.us/show_bug.cgi?id=1440 Thanks, -Jeff From adrian at lisas.de Sat Feb 12 22:04:24 2005 From: adrian at lisas.de (Adrian Reber) Date: Sat, 12 Feb 2005 23:04:24 +0100 Subject: New package for review: gnome-cpufreq-applet Message-ID: <20050212220424.GA2631@lisas.de> I would like to include gnome-cpufreq-applet and I'm posting it here for reviews: http://lisas.de/~adrian/rpm/gnome-cpufreq-applet-0.3.1-1.src.rpm Adrian From gene at czarc.net Sat Feb 12 22:22:15 2005 From: gene at czarc.net (Gene Czarcinski) Date: Sat, 12 Feb 2005 17:22:15 -0500 Subject: partimage (was: Re: package criteria) In-Reply-To: <20050212195159.54223fd8.fedora@wir-sind-cool.org> References: <200502121323.37373.gene@czarc.net> <20050212195159.54223fd8.fedora@wir-sind-cool.org> Message-ID: <200502121722.15220.gene@czarc.net> On Saturday 12 February 2005 13:51, Michael Schwendt wrote: > On Sat, 12 Feb 2005 13:23:37 -0500, Gene Czarcinski wrote: > > Currently, partimage is available on the DAG repository. Should > > partimage be included in Fedora Extras? The partimage package appears to > > be included in some other distributions such as mandrake and debian and > > I, personally, believe it is a good package. However, there has been > > little recent development activity and it may be orphaned. > > Please join here: > https://bugzilla.fedora.us/show_bug.cgi?id=518 Added myself as a CC and I will take a look at the package. So far I am using the a build of the 0.6.4 package from DAG which includes partimage-static. I also noticed that debian has a patch file for their package but I have not examined it carefully. Gene From tjb at unh.edu Sun Feb 13 02:25:41 2005 From: tjb at unh.edu (Thomas J. Baker) Date: Sat, 12 Feb 2005 21:25:41 -0500 Subject: New package for review: gnome-cpufreq-applet In-Reply-To: <20050212220424.GA2631@lisas.de> References: <20050212220424.GA2631@lisas.de> Message-ID: <1108261541.9406.1.camel@continuity> On Sat, 2005-02-12 at 23:04 +0100, Adrian Reber wrote: > I would like to include gnome-cpufreq-applet and I'm posting it here for > reviews: > > http://lisas.de/~adrian/rpm/gnome-cpufreq-applet-0.3.1-1.src.rpm > > Adrian Doesn't build for me on x86_64: ... /bin/sh ../../libtool --mode=link gcc -O2 -g -pipe -m64 -Wall -o cpufreq-selector cpufreq.o cpufreq-sysfs.o cpufreq-procfs.o main.o - lgobject-2.0 -lglib-2.0 -lpopt mkdir .libs gcc -O2 -g -pipe -m64 -Wall -o cpufreq-selector cpufreq.o cpufreq- sysfs.o cpufreq-procfs.o main.o -lgobject-2.0 - lglib-2.0 /usr/lib/libpopt.so /usr/lib/libpopt.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[3]: *** [cpufreq-selector] Error 1 make[3]: Leaving directory `/home/tjb/rpm/BUILD/gnome-cpufreq- applet-0.3.1/src/cpufreq-selector' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/tjb/rpm/BUILD/gnome-cpufreq- applet-0.3.1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/tjb/rpm/BUILD/gnome-cpufreq- applet-0.3.1' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.67334 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.67334 (%build) neuromancer> tjb --- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From skvidal at fedoraproject.org Sun Feb 13 08:25:27 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Sun, 13 Feb 2005 03:25:27 -0500 Subject: Package Updates Message-ID: <1108283127.3670.3.camel@cutter> Hi, abcde (i386, x86_64) ocaml (i386, x86_64) lablgtk (i386, x86_64) GtkAda (i386) cook (i386, x86_64) tkcvs (i386, x86_64) tpctl (i386) configure-thinkpad (i386) ibmonitor (i386, x86_64) Status page: http://fedoraproject.org/wiki/Extras_2fFC3Status Follow updates and new packages at: http://fedoraproject.org/infofeed/ Report problems at Bugzilla: http://bugzilla.redhat.com/ thanks, -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Sun Feb 13 11:28:24 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 13 Feb 2005 12:28:24 +0100 Subject: New package for review: gnome-cpufreq-applet In-Reply-To: <1108261541.9406.1.camel@continuity> References: <20050212220424.GA2631@lisas.de> <1108261541.9406.1.camel@continuity> Message-ID: <1108294104.6116.10.camel@localhost.localdomain> Am Samstag, den 12.02.2005, 21:25 -0500 schrieb Thomas J. Baker: > On Sat, 2005-02-12 at 23:04 +0100, Adrian Reber wrote: > > I would like to include gnome-cpufreq-applet and I'm posting it here for > > reviews: > > > > http://lisas.de/~adrian/rpm/gnome-cpufreq-applet-0.3.1-1.src.rpm > > > > Adrian > > Doesn't build for me on x86_64: > ... Fixed by a "autoreconf -i -f" before configure. Adrian, cause there might be problems due to different autotools- versions we normally (at least AFAIK) solve this not by a autoreconfig in the spec file. We instead create a patch after running autoreconf -i -f against an unmodified src-tree and but the patch in the spec file. See sirius/sirius.spec for an example. Remember to remove the autoreconf cache-dir autom4te.cache/ before diffing. HTH -- Thorsten Leemhuis From ivazquez at ivazquez.net Sun Feb 13 11:34:33 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 13 Feb 2005 06:34:33 -0500 Subject: Requests for inclusion In-Reply-To: <1108062454.6879.15.camel@localhost.localdomain> References: <1108062454.6879.15.camel@localhost.localdomain> Message-ID: <1108294473.29928.3.camel@localhost.localdomain> On Thu, 2005-02-10 at 14:07 -0500, Ignacio Vazquez-Abrams wrote: > I went mucking through my repository, looking for packages that I felt > could/should be in extras. Here's what I've found so far: Does anyone else have any questions/comments/concerns? https://www.redhat.com/archives/fedora-extras-list/2005- February/msg00320.html (Sorry about not threading this; I seem to have lost the original thread.) -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From adrian at lisas.de Sun Feb 13 11:58:49 2005 From: adrian at lisas.de (Adrian Reber) Date: Sun, 13 Feb 2005 12:58:49 +0100 Subject: New package for review: gnome-cpufreq-applet In-Reply-To: <1108294104.6116.10.camel@localhost.localdomain> References: <20050212220424.GA2631@lisas.de> <1108261541.9406.1.camel@continuity> <1108294104.6116.10.camel@localhost.localdomain> Message-ID: <20050213115849.GB16941@lisas.de> On Sun, Feb 13, 2005 at 12:28:24PM +0100, Thorsten Leemhuis wrote: > > > I would like to include gnome-cpufreq-applet and I'm posting it here for > > > reviews: > > > > > > http://lisas.de/~adrian/rpm/gnome-cpufreq-applet-0.3.1-1.src.rpm > > > > > > Adrian > > > > Doesn't build for me on x86_64: > > ... > > Fixed by a "autoreconf -i -f" before configure. > > Adrian, cause there might be problems due to different autotools- > versions we normally (at least AFAIK) solve this not by a autoreconfig > in the spec file. We instead create a patch after running autoreconf -i > -f against an unmodified src-tree and but the patch in the spec file. > See sirius/sirius.spec for an example. Remember to remove the autoreconf > cache-dir autom4te.cache/ before diffing. Thanks for this information. I have changed the spec just like in sirius and created the autoreconf patch for x86_64: http://lisas.de/~adrian/rpm/gnome-cpufreq-applet-0.3.1-2.src.rpm Adrian From fedora at leemhuis.info Sun Feb 13 12:15:05 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 13 Feb 2005 13:15:05 +0100 Subject: New package for review: gnome-cpufreq-applet In-Reply-To: <20050213115849.GB16941@lisas.de> References: <20050212220424.GA2631@lisas.de> <1108261541.9406.1.camel@continuity> <1108294104.6116.10.camel@localhost.localdomain> <20050213115849.GB16941@lisas.de> Message-ID: <1108296905.6116.16.camel@localhost.localdomain> Am Sonntag, den 13.02.2005, 12:58 +0100 schrieb Adrian Reber: > On Sun, Feb 13, 2005 at 12:28:24PM +0100, Thorsten Leemhuis wrote: > > > > I would like to include gnome-cpufreq-applet and I'm posting it here for > > > > reviews: > > > > > > > > http://lisas.de/~adrian/rpm/gnome-cpufreq-applet-0.3.1-1.src.rpm > > > > > > > > Adrian > > > > > > Doesn't build for me on x86_64: > > > ... > > > > Fixed by a "autoreconf -i -f" before configure. > > > > Adrian, cause there might be problems due to different autotools- > > versions we normally (at least AFAIK) solve this not by a autoreconfig > > in the spec file. We instead create a patch after running autoreconf -i > > -f against an unmodified src-tree and but the patch in the spec file. > > See sirius/sirius.spec for an example. Remember to remove the autoreconf > > cache-dir autom4te.cache/ before diffing. > > Thanks for this information. I have changed the spec just like in sirius > and created the autoreconf patch for x86_64: > > http://lisas.de/~adrian/rpm/gnome-cpufreq-applet-0.3.1-2.src.rpm Builds fine on x86_64. -- Thorsten Leemhuis From toshio at tiki-lounge.com Sun Feb 13 14:15:31 2005 From: toshio at tiki-lounge.com (Toshio) Date: Sun, 13 Feb 2005 09:15:31 -0500 Subject: autoreconf vs patching (Was Re: New package for review: gnome-cpufreq-applet) In-Reply-To: <1108294104.6116.10.camel@localhost.localdomain> References: <20050212220424.GA2631@lisas.de> <1108261541.9406.1.camel@continuity> <1108294104.6116.10.camel@localhost.localdomain> Message-ID: <1108304135.17301.23.camel@Madison.badger.com> On Sun, 2005-02-13 at 12:28 +0100, Thorsten Leemhuis wrote: > Adrian, cause there might be problems due to different autotools- > versions we normally (at least AFAIK) solve this not by a autoreconfig > in the spec file. We instead create a patch after running autoreconf -i > -f against an unmodified src-tree and but the patch in the spec file. > See sirius/sirius.spec for an example. Remember to remove the autoreconf > cache-dir autom4te.cache/ before diffing. Opinion differs between whether to reconf or patch. Both have their ugly sides. On the debit side for patching is that it creates a large patch of autogenerated shell code that often has little significant change in it but could contain malicious code (so should be reviewed when it comes from untrusted packagers.) Autoreconf _should_ also be reproducible so putting it in the spec is logical. Searching fedora-devel will reveal that there's people on both side of the argument... probably because it's kludge either way. Thorsten -- what exactly are you thinking of in terms of version mismatch? I generally prefer to go the autoreconf route and was wondering which aspect of versioning you think is problematic so I can see if there's a way to work around it. -Toshio -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From petersen at redhat.com Sun Feb 13 15:36:14 2005 From: petersen at redhat.com (Jens Petersen) Date: Mon, 14 Feb 2005 00:36:14 +0900 Subject: ghc package bootstrapping Message-ID: <420F73EE.5090903@redhat.com> http://people.redhat.com/petersen/ghc-6.2.2-1.src.rpm GHC (Glasgow Haskell Compiler), the main-used compiler of the Haskell programming language, see , is under active development, and the RC series for ghc-6.4 has just started. Gemi originally contributed ghc to fedora.us, but due to slow reviewing and the bootstrap requirement, it got stuck in the queue... Since ghc is a compiler and largely written in Haskell, it basically needs itself to build. I just talked to the Debian maintainer of ghc, and he told me that Debian bootstraps ghc on new archs with binary packages of his binary ports. So I would like to add ghc to Extras initially with the above package based on upstream's installable binary for Linux/i386 (with configure and a Makefile fwiw). Warren already took a look at the spec file but suggested that I post here first before checking it into cvs because of the bootstrapping issue. Jens From fedora at leemhuis.info Sun Feb 13 15:49:36 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 13 Feb 2005 16:49:36 +0100 Subject: autoreconf vs patching (Was Re: New package for review: gnome-cpufreq-applet) In-Reply-To: <1108304135.17301.23.camel@Madison.badger.com> References: <20050212220424.GA2631@lisas.de> <1108261541.9406.1.camel@continuity> <1108294104.6116.10.camel@localhost.localdomain> <1108304135.17301.23.camel@Madison.badger.com> Message-ID: <1108309776.6116.45.camel@localhost.localdomain> Am Sonntag, den 13.02.2005, 09:15 -0500 schrieb Toshio: > On Sun, 2005-02-13 at 12:28 +0100, Thorsten Leemhuis wrote: > > Adrian, cause there might be problems due to different autotools- > > versions we normally (at least AFAIK) solve this not by a autoreconfig > > in the spec file. We instead create a patch after running autoreconf -i > > -f against an unmodified src-tree and but the patch in the spec file. > > See sirius/sirius.spec for an example. Remember to remove the autoreconf > > cache-dir autom4te.cache/ before diffing. [...] > Thorsten -- what exactly are you thinking of in terms of version > mismatch? Well, I have no strong option here. I only do it that way after a discussion on IRC where someone said: "if you find a need to update files, you should create patches for them, and apply them in the spec file, instead of assuming whatever version of autoconf, automake, libtool and any other macro-providing package is going to do the right thing at any later point in time" and I and some others agreed on that. -- Thorsten Leemhuis From andreas.bierfert at lowlatency.de Sun Feb 13 16:08:47 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sun, 13 Feb 2005 17:08:47 +0100 Subject: Requests for extras Message-ID: <420F7B8F.10003@lowlatency.de> Hi all, I have some packages sitting around (see fedora.us) which I would like to see included in extras: airsnort 0.2.7e: Wireless LAN (WLAN) tool which recovers encryption keys http://airsnort.shmoo.com/ http://fedora.lowlatency.de/3/i386/RPMS.stable/airsnort-0.2.7e-2.i386.rpm http://fedora.lowlatency.de/3/i386/SRPMS.stable/airsnort-0.2.7e-2.src.rpm kino 0.7.5: Kino is a non-linear DV editor for GNU/Linux http://kino.schirmacher.de http://fedora.lowlatency.de/3/i386/RPMS.stable/kino-0.7.5-1.i386.rpm http://fedora.lowlatency.de/3/i386/RPMS.stable/kino-devel-0.7.5-1.i386.rpm http://fedora.lowlatency.de/3/i386/SRPMS.stable/kino-0.7.5-1.src.rpm kismet 2005.01.R1: 802.11 wireless network sniffer http://www.kismetwireless.net http://fedora.lowlatency.de/3/i386/RPMS.stable/kismet-2005.01.R1-2.i386.rpm http://fedora.lowlatency.de/3/i386/SRPMS.stable/kismet-2005.01.R1-2.src.rpm rxvt-unicode 4.9: Rxvt-unicode is an unicode version of rxvt http://software.schmorp.de/ http://fedora.lowlatency.de/3/i386/RPMS.stable/rxvt-unicode-4.9-1.i386.rpm http://fedora.lowlatency.de/3/i386/SRPMS.stable/rxvt-unicode-4.9-1.src.rpm - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | () ASCII ribbon campaign | mail preferred cell: +49 172 9789968 | /\ against HTML mail | From petersen at redhat.com Sun Feb 13 16:14:33 2005 From: petersen at redhat.com (Jens Petersen) Date: Mon, 14 Feb 2005 01:14:33 +0900 Subject: ghc package bootstrapping In-Reply-To: <420F73EE.5090903@redhat.com> References: <420F73EE.5090903@redhat.com> Message-ID: <420F7CE9.6070104@redhat.com> Jens Petersen wrote: > http://people.redhat.com/petersen/ghc-6.2.2-1.src.rpm And here is the .spec file: http://people.redhat.com/petersen/ghc.spec for those who want to look. -Jens From dwmw2 at infradead.org Sun Feb 13 16:40:25 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 13 Feb 2005 16:40:25 +0000 Subject: ghc package bootstrapping In-Reply-To: <420F73EE.5090903@redhat.com> References: <420F73EE.5090903@redhat.com> Message-ID: <1108312826.7436.67.camel@localhost.localdomain> On Mon, 2005-02-14 at 00:36 +0900, Jens Petersen wrote: >I just talked to the Debian maintainer of ghc, >and he told me that Debian bootstraps ghc on new >archs with binary packages of his binary ports. >So I would like to add ghc to Extras initially with >the above package based on upstream's installable >binary for Linux/i386 (with configure and a Makefile fwiw). There are Debian binary packages for x86_64 and PPC too. Please include both of those. The way that Modula-3 handles bootstrapping on a new platform is to include the bootstrap compiler in assembly form and then compile it, instead of distributing binaries. That approach makes me feel slightly happier because it at least 'feels' like source code, but I suppose there's no real reason for that. Distributing as assembly can give problems with symbol versioning -- see the hoops I had to jump through to get the bootstrap compiler to use _setjmp at GLIBC_2.0 in ezm3 to get cvsup building on PPC, for example. I was toying with the idea of a portable bootstrap compiler generated by an M3->Java compiler. But then I started to feel queasy... :) -- dwmw2 From gemi at bluewin.ch Sun Feb 13 17:07:09 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Sun, 13 Feb 2005 18:07:09 +0100 Subject: ghc package bootstrapping In-Reply-To: <420F73EE.5090903@redhat.com> References: <420F73EE.5090903@redhat.com> Message-ID: <1108314429.12643.1.camel@scriabin.tannenrauch.ch> On Mon, 2005-02-14 at 00:36 +0900, Jens Petersen wrote: > http://people.redhat.com/petersen/ghc-6.2.2-1.src.rpm > > GHC (Glasgow Haskell Compiler), the main-used > compiler of the Haskell programming language, > see , is under active > development, and the RC series for ghc-6.4 has > just started. > > Gemi originally contributed ghc to fedora.us, > but due to slow reviewing and the bootstrap > requirement, it got stuck in the queue... > Since ghc is a compiler and largely written > in Haskell, it basically needs itself to build. I have the src and binary rpms in http://www.ifi.unizh.ch/staff/milmei/rpms I think haddock is also needed to make the documentation. If Jens takes care of managing ghc for Extras, then I need not do this. I have several other packages for ghc (and also nhc98 and hugs) that I could contribute. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From dwmw2 at infradead.org Sun Feb 13 17:17:50 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 13 Feb 2005 17:17:50 +0000 Subject: qemu. In-Reply-To: <87oeewcgab.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1107785897.19262.411.camel@hades.cambridge.redhat.com> <87oeewcgab.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1108315071.7436.77.camel@localhost.localdomain> On Mon, 2005-02-07 at 20:37 +0100, Enrico Scholz wrote: >ok; I do not insist on my fedora.us package, so feel free to maintain >qemu. But please fix the following issues first: Done (all but smp_mflags, at least). Thanks for the feedback. http://peach.infradead.org/extras/#qemu Runs acroread quite happily on my powerbook. Now we just need RPM to handle installation of non-native packages nicely.... :) -- dwmw2 From fedora at wir-sind-cool.org Sun Feb 13 18:03:53 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sun, 13 Feb 2005 19:03:53 +0100 Subject: autoreconf vs patching (Was Re: New package for review: gnome-cpufreq-applet) In-Reply-To: <1108309776.6116.45.camel@localhost.localdomain> References: <20050212220424.GA2631@lisas.de> <1108261541.9406.1.camel@continuity> <1108294104.6116.10.camel@localhost.localdomain> <1108304135.17301.23.camel@Madison.badger.com> <1108309776.6116.45.camel@localhost.localdomain> Message-ID: <20050213190353.670954bb.fedora@wir-sind-cool.org> On Sun, 13 Feb 2005 16:49:36 +0100, Thorsten Leemhuis wrote: > Am Sonntag, den 13.02.2005, 09:15 -0500 schrieb Toshio: > > On Sun, 2005-02-13 at 12:28 +0100, Thorsten Leemhuis wrote: > > > Adrian, cause there might be problems due to different autotools- > > > versions we normally (at least AFAIK) solve this not by a autoreconfig > > > in the spec file. We instead create a patch after running autoreconf -i > > > -f against an unmodified src-tree and but the patch in the spec file. > > > See sirius/sirius.spec for an example. Remember to remove the autoreconf > > > cache-dir autom4te.cache/ before diffing. > [...] > > Thorsten -- what exactly are you thinking of in terms of version > > mismatch? > > Well, I have no strong option here. I only do it that way after a > discussion on IRC where someone said: > > "if you find a need to update files, you should create patches for them, > and apply them in the spec file, instead of assuming whatever version of > autoconf, automake, libtool and any other macro-providing package is > going to do the right thing at any later point in time" > > and I and some others agreed on that. If it works for you... The important thing is to make sure that the upstream developers update their autotools files soon, so you don't need to recreate the patches for every minor version upgrade. From gemi at bluewin.ch Sun Feb 13 18:38:46 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Sun, 13 Feb 2005 19:38:46 +0100 Subject: Request for package import: qcad Message-ID: <1108319927.13592.7.camel@scriabin.tannenrauch.ch> The CAD application qcad at http://www.ifi.unizh.ch/staff/milmei/rpms/qcad-2.0.4.0-1.src.rpm has been in bugzilla.us for some time http://bugzilla.fedora.us/show_bug.cgi?id=848 I think most of the issues have been resolved. Menu > Help > Manual works, but needs qt-devel for /usr/bin/assistant. It would probably be better to move assistant to qt. /usr/share/qcad/library is empty for receiving future part libraries. The QCad part library is a big package that might be packaged separately. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From gemi at bluewin.ch Sun Feb 13 19:20:03 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Sun, 13 Feb 2005 20:20:03 +0100 Subject: gtkglarea2 build Message-ID: <1108322403.13767.5.camel@scriabin.tannenrauch.ch> This package seems to build fine, if one adapts the requires. lablgtk can then be built with OpenGL support. Should I commit? -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From dwmw2 at infradead.org Sun Feb 13 19:33:12 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 13 Feb 2005 19:33:12 +0000 Subject: New package for review: gnome-cpufreq-applet In-Reply-To: <1108296905.6116.16.camel@localhost.localdomain> References: <20050212220424.GA2631@lisas.de> <1108261541.9406.1.camel@continuity> <1108294104.6116.10.camel@localhost.localdomain> <20050213115849.GB16941@lisas.de> <1108296905.6116.16.camel@localhost.localdomain> Message-ID: <1108323192.7436.81.camel@localhost.localdomain> On Sun, 2005-02-13 at 13:15 +0100, Thorsten Leemhuis wrote: > >> http://lisas.de/~adrian/rpm/gnome-cpufreq-applet-0.3.1-2.src.rpm > >Builds fine on x86_64. ... and also on PPC. Seconded. Note that this package would be for FC3 only -- cpufreq_applet is already included in gnome-applets in rawhide. We should probably make sure the rawhide gnome-applets obsoletes the FC3 extras package. -- dwmw2 From dwmw2 at infradead.org Sun Feb 13 19:41:38 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 13 Feb 2005 19:41:38 +0000 Subject: Package proposal: apmud Message-ID: <1108323699.7436.92.camel@localhost.localdomain> http://david.woodhou.se/apmud-1.0.0-1.src.rpm Name : apmud Relocations: (not relocatable) Version : 1.0.0 Vendor: (none) Release : 1 Build Date: Sun 13 Feb 2005 19:39:20 GMT Install Date: (not installed) Build Host: localhost.localdomain Group : Utilities/System Source RPM: (none) Size : 90418 License: GPL Signature : (none) Summary : Power management daemon for Apple laptops. Description : pmud is a daemon which periodically polls the PMU (power manager) and performs functions such as enabling or disabling devices appropriately when the power source changes. It can also be instructed to signal init(8) that a power- failure has occured. pmud works on Apple PowerBooks and iBooks. A tool for configuring the trackpad on Apple PowerBooks and iBooks is also included. See /etc/sysconfig/trackpad. Tools for enabling video mirroring for ATI Rage 128 Mobility (m3mirror) and ATI Radeon Mobility (m6mirror) enabled PowerBooks are also included. -- dwmw2 From ville.skytta at iki.fi Sun Feb 13 20:04:35 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 13 Feb 2005 22:04:35 +0200 Subject: cvs-import: allow extra commit message Message-ID: <1108325075.5281.316.camel@bobcat.mine.nu> I think it'd be useful to be able to add a "real" commit message along with the auto-import one generated by cvs-import.sh. I tested this when importing perl-HTML-Tree a few minutes ago. Any objections against applying the attached patch? -------------- next part -------------- A non-text attachment was scrubbed... Name: cvs-import.patch Type: text/x-patch Size: 1270 bytes Desc: not available URL: From ville.skytta at iki.fi Sun Feb 13 20:15:39 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 13 Feb 2005 22:15:39 +0200 Subject: qemu. In-Reply-To: <1108315071.7436.77.camel@localhost.localdomain> References: <1107785897.19262.411.camel@hades.cambridge.redhat.com> <87oeewcgab.fsf@kosh.ultra.csn.tu-chemnitz.de> <1108315071.7436.77.camel@localhost.localdomain> Message-ID: <1108325739.5281.322.camel@bobcat.mine.nu> On Sun, 2005-02-13 at 17:17 +0000, David Woodhouse wrote: > On Mon, 2005-02-07 at 20:37 +0100, Enrico Scholz wrote: > >ok; I do not insist on my fedora.us package, so feel free to maintain > >qemu. But please fix the following issues first: > > Done (all but smp_mflags, at least). Thanks for the feedback. > > http://peach.infradead.org/extras/#qemu FWIW, "make i686" fails, see attached log. "make i386" builds ok. -------------- next part -------------- A non-text attachment was scrubbed... Name: qemu.log.gz Type: application/x-gzip Size: 2926 bytes Desc: not available URL: From fedora at wir-sind-cool.org Sun Feb 13 20:31:07 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sun, 13 Feb 2005 21:31:07 +0100 Subject: Request for package import: qcad In-Reply-To: <1108319927.13592.7.camel@scriabin.tannenrauch.ch> References: <1108319927.13592.7.camel@scriabin.tannenrauch.ch> Message-ID: <20050213213107.6997493d.fedora@wir-sind-cool.org> On Sun, 13 Feb 2005 19:38:46 +0100, G?rard Milmeister wrote: > The CAD application qcad at > http://www.ifi.unizh.ch/staff/milmei/rpms/qcad-2.0.4.0-1.src.rpm > has been in bugzilla.us for some time > http://bugzilla.fedora.us/show_bug.cgi?id=848 > > I think most of the issues have been resolved. > Menu > Help > Manual works, but needs qt-devel for /usr/bin/assistant. > It would probably be better to move assistant to qt. Yes. Please file an RFE, because qt-devel is >20 MB. I've changed a very few lines and imported the package. > /usr/share/qcad/library is empty for receiving future part libraries. > The QCad part library is a big package that might be packaged > separately. From adrian at lisas.de Sun Feb 13 21:14:40 2005 From: adrian at lisas.de (Adrian Reber) Date: Sun, 13 Feb 2005 22:14:40 +0100 Subject: New package for review: gnome-cpufreq-applet In-Reply-To: <1108323192.7436.81.camel@localhost.localdomain> References: <20050212220424.GA2631@lisas.de> <1108261541.9406.1.camel@continuity> <1108294104.6116.10.camel@localhost.localdomain> <20050213115849.GB16941@lisas.de> <1108296905.6116.16.camel@localhost.localdomain> <1108323192.7436.81.camel@localhost.localdomain> Message-ID: <20050213211440.GB3170@lisas.de> On Sun, Feb 13, 2005 at 07:33:12PM +0000, David Woodhouse wrote: > >> http://lisas.de/~adrian/rpm/gnome-cpufreq-applet-0.3.1-2.src.rpm > > > >Builds fine on x86_64. > > ... and also on PPC. Seconded. > > Note that this package would be for FC3 only -- cpufreq_applet is > already included in gnome-applets in rawhide. We should probably make > sure the rawhide gnome-applets obsoletes the FC3 extras package. Didn't knew that it is in rawhide. This probably means that it will be also there in FC4 and then it doesn't make much sense to provide it in Fedora Extras for FC3, or does it? Adrian From s.mako at gmx.net Sun Feb 13 22:46:16 2005 From: s.mako at gmx.net (Zoltan Kota) Date: Sun, 13 Feb 2005 23:46:16 +0100 (CET) Subject: pybliographer update Message-ID: Hi, I would like to update pybliographer in extras. So, now I need a sponsor as I know. Aurelien, Ville (for example :-)? You were the most active persons regarding my package submissions at fedora.us. Zoltan From dwmw2 at infradead.org Sun Feb 13 22:56:08 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 13 Feb 2005 22:56:08 +0000 Subject: New package for review: gnome-cpufreq-applet In-Reply-To: <20050213211440.GB3170@lisas.de> References: <20050212220424.GA2631@lisas.de> <1108261541.9406.1.camel@continuity> <1108294104.6116.10.camel@localhost.localdomain> <20050213115849.GB16941@lisas.de> <1108296905.6116.16.camel@localhost.localdomain> <1108323192.7436.81.camel@localhost.localdomain> <20050213211440.GB3170@lisas.de> Message-ID: <1108335369.7436.102.camel@localhost.localdomain> On Sun, 2005-02-13 at 22:14 +0100, Adrian Reber wrote: >Didn't knew that it is in rawhide. This probably means that it will be >also there in FC4 and then it doesn't make much sense to provide it in >Fedora Extras for FC3, or does it? Surely it makes sense to provide it in Extras for FC3, just not for FC4? -- dwmw2 From dwmw2 at infradead.org Mon Feb 14 01:18:16 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 14 Feb 2005 01:18:16 +0000 Subject: qemu. In-Reply-To: <1108325739.5281.322.camel@bobcat.mine.nu> References: <1107785897.19262.411.camel@hades.cambridge.redhat.com> <87oeewcgab.fsf@kosh.ultra.csn.tu-chemnitz.de> <1108315071.7436.77.camel@localhost.localdomain> <1108325739.5281.322.camel@bobcat.mine.nu> Message-ID: <1108343897.7436.119.camel@localhost.localdomain> On Sun, 2005-02-13 at 22:15 +0200, Ville Skytt? wrote: >FWIW, "make i686" fails, see attached log. "make i386" builds ok. I see that too. Does it still happen if we use qemu's default CFLAGS instead of overriding them? I'm not sure if it's really a GCC bug or whether qemu is doing something evil. Either way, I suspect you're not going to get better performance by compiling the qemu runtime for i686, because that doesn't actually affect the code it generates for itself, does it? -- dwmw2 From dwmw2 at infradead.org Mon Feb 14 01:21:45 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 14 Feb 2005 01:21:45 +0000 Subject: sqlite Message-ID: <1108344105.7436.121.camel@localhost.localdomain> Rawhide has sqlite 3.0.8-3. Is there a reason why Extras has 2.8.15? Should we update it? -- dwmw2 From byte at aeon.com.my Mon Feb 14 01:34:21 2005 From: byte at aeon.com.my (Colin Charles) Date: Mon, 14 Feb 2005 09:34:21 +0800 Subject: sqlite In-Reply-To: <1108344105.7436.121.camel@localhost.localdomain> References: <1108344105.7436.121.camel@localhost.localdomain> Message-ID: <1108344862.6792.118.camel@localhost.localdomain> On Mon, 2005-02-14 at 01:21 +0000, David Woodhouse wrote: > Rawhide has sqlite 3.0.8-3. Is there a reason why Extras has 2.8.15? > Should we update it? If Rawhide has sqlite 3.0.8-3, can we drop it from Extras eventually/soon? But in the meantime, it probably should be bumped up -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From ville.skytta at iki.fi Mon Feb 14 07:09:02 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 14 Feb 2005 09:09:02 +0200 Subject: qemu. In-Reply-To: <1108343897.7436.119.camel@localhost.localdomain> References: <1107785897.19262.411.camel@hades.cambridge.redhat.com> <87oeewcgab.fsf@kosh.ultra.csn.tu-chemnitz.de> <1108315071.7436.77.camel@localhost.localdomain> <1108325739.5281.322.camel@bobcat.mine.nu> <1108343897.7436.119.camel@localhost.localdomain> Message-ID: <1108364942.5281.376.camel@bobcat.mine.nu> On Mon, 2005-02-14 at 01:18 +0000, David Woodhouse wrote: > On Sun, 2005-02-13 at 22:15 +0200, Ville Skytt? wrote: > >FWIW, "make i686" fails, see attached log. "make i386" builds ok. > > I see that too. Does it still happen if we use qemu's default CFLAGS > instead of overriding them? I'm not sure if it's really a GCC bug or > whether qemu is doing something evil. I'll take a look later if I find time. > Either way, I suspect you're not going to get better performance by > compiling the qemu runtime for i686, because that doesn't actually > affect the code it generates for itself, does it? Dunno, that's not what I'm looking for in this particular case; test- building for i386 and i686 and watching the build log whether our optflags are being honored is something I do for most packages anyway. In addition to sometimes catching upstream configure/makefile bogosity, compiler bugs etc, it helps people who actually want to see if using different optflags makes a difference wrt. runtime performance of the package. From fedora at wir-sind-cool.org Mon Feb 14 07:23:10 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 14 Feb 2005 08:23:10 +0100 Subject: sqlite In-Reply-To: <1108344105.7436.121.camel@localhost.localdomain> References: <1108344105.7436.121.camel@localhost.localdomain> Message-ID: <20050214082310.1e48e19c.fedora@wir-sind-cool.org> On Mon, 14 Feb 2005 01:21:45 +0000, David Woodhouse wrote: > Rawhide has sqlite 3.0.8-3. Is there a reason why Extras has 2.8.15? > Should we update it? Well, first of all, it needs an active maintainer. Secondly, the 3.0.x series started as an alpha/beta development stream, and 3.0.7 was the first version not called a beta release. Work had started at getting a parallel installable sqlite3 package into fedora.us and reporting bugs upstreeam, https://bugzilla.fedora.us/show_bug.cgi?id=2135 and while it started to look promising with the 3.0.8 release, there is no packager interested in package ownership anymore. From rc040203 at freenet.de Mon Feb 14 07:55:55 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 14 Feb 2005 08:55:55 +0100 Subject: qemu. In-Reply-To: <1108364942.5281.376.camel@bobcat.mine.nu> References: <1107785897.19262.411.camel@hades.cambridge.redhat.com> <87oeewcgab.fsf@kosh.ultra.csn.tu-chemnitz.de> <1108315071.7436.77.camel@localhost.localdomain> <1108325739.5281.322.camel@bobcat.mine.nu> <1108343897.7436.119.camel@localhost.localdomain> <1108364942.5281.376.camel@bobcat.mine.nu> Message-ID: <1108367755.31499.449.camel@mccallum.corsepiu.local> On Mon, 2005-02-14 at 09:09 +0200, Ville Skytt? wrote: > On Mon, 2005-02-14 at 01:18 +0000, David Woodhouse wrote: > > On Sun, 2005-02-13 at 22:15 +0200, Ville Skytt? wrote: > > >FWIW, "make i686" fails, see attached log. "make i386" builds ok. > > > > I see that too. Does it still happen if we use qemu's default CFLAGS > > instead of overriding them? I'm not sure if it's really a GCC bug or > > whether qemu is doing something evil. What you see is a GCC ICE. In any case, whether or not qemu is trying to do something evil, an ICE always is a GCC-BUG, because gcc must never ICE. I'd recommend to file a PR at RH's bugzilla and GCC's bugzilla (http://gcc.gnu.org) Ralf From andreas.bierfert at lowlatency.de Mon Feb 14 08:21:22 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Mon, 14 Feb 2005 09:21:22 +0100 Subject: Fedora Extras Package Updates In-Reply-To: <20050211124641.6c960e95@python2> References: <1108097253.5782.5.camel@cutter> <20050211105402.3189f656.fedora@wir-sind-cool.org> <20050211124641.6c960e95@python2> Message-ID: <42105F82.3040902@lowlatency.de> Matthias Saou wrote: > I'll try to talk Rudolf Kastl into maintaining it. He works quite closely > with the wine developers for his FC packages, does a lot of regression > tests for new snapshots, and last I used his packages, they worked very > well. > > Matthias If that does not work out I would be willing to step forward... Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | () ASCII ribbon campaign | mail preferred cell: +49 172 9789968 | /\ against HTML mail | From jfontain at free.fr Mon Feb 14 08:27:09 2005 From: jfontain at free.fr (jfontain at free.fr) Date: Mon, 14 Feb 2005 09:27:09 +0100 Subject: sqlite In-Reply-To: <1108344105.7436.121.camel@localhost.localdomain> References: <1108344105.7436.121.camel@localhost.localdomain> Message-ID: <1108369629.421060dd12da5@imp4-q.free.fr> Quoting David Woodhouse : > Rawhide has sqlite 3.0.8-3. Is there a reason why Extras has 2.8.15? > Should we update it? I'd really like sqlite-tcl to be included in rawhide (I need it for moodss already in extras). 2.8.15 extra included it but 3.0.8 does not. Anything I can do to help? -- Jean-Luc Fontaine From rc040203 at freenet.de Mon Feb 14 09:32:14 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 14 Feb 2005 10:32:14 +0100 Subject: autoreconf vs patching In-Reply-To: <20050213190353.670954bb.fedora@wir-sind-cool.org> References: <20050212220424.GA2631@lisas.de> <1108261541.9406.1.camel@continuity> <1108294104.6116.10.camel@localhost.localdomain> <1108304135.17301.23.camel@Madison.badger.com> <1108309776.6116.45.camel@localhost.localdomain> <20050213190353.670954bb.fedora@wir-sind-cool.org> Message-ID: <1108373535.31499.471.camel@mccallum.corsepiu.local> On Sun, 2005-02-13 at 19:03 +0100, Michael Schwendt wrote: > On Sun, 13 Feb 2005 16:49:36 +0100, Thorsten Leemhuis wrote: > > > Am Sonntag, den 13.02.2005, 09:15 -0500 schrieb Toshio: > > > On Sun, 2005-02-13 at 12:28 +0100, Thorsten Leemhuis wrote: > > > > Adrian, cause there might be problems due to different autotools- > > > > versions we normally (at least AFAIK) solve this not by a autoreconfig > > > > in the spec file. We instead create a patch after running autoreconf -i > > > > -f against an unmodified src-tree and but the patch in the spec file. > > > > See sirius/sirius.spec for an example. Remember to remove the autoreconf > > > > cache-dir autom4te.cache/ before diffing. > > [...] > > > Thorsten -- what exactly are you thinking of in terms of version > > > mismatch? > > > > Well, I have no strong option here. I only do it that way after a > > discussion on IRC where someone said: > > > > "if you find a need to update files, you should create patches for them, > > and apply them in the spec file, instead of assuming whatever version of > > autoconf, automake, libtool and any other macro-providing package is > > going to do the right thing at any later point in time" > > > > and I and some others agreed on that. > > If it works for you... IMO, this is the only feasible approach, for 2 reasons: 1. This is how the autotools are assumed to be used. Packagers are not supposed to run any of them when building a package. If you find you can't avoid running them, something inside of the package is broken - Unfortunately there are many broken and mal-designed package configurations out there :( 2. Running autoreconf is error-prone and can break packages in subtile and hard to find ways. In probably >> 90% of all cases it will work without too many problems, but those cases it doesn't work out often are even hard to recognize. (I.e. you only think autoreconf worked, while it actually failed.) When using patches, you very likely recognize these cases and will be able to fix them. > The important thing is to make sure that the upstream developers update > their autotools files soon, so you don't need to recreate the patches for > every minor version upgrade. ACK, but ... besides broken configurations, the number one reason for having to rebuild autotool-generated files on RH system probably is RH's libtool, because vanilla libtool does not support multilibs. I.e. many source packages which have been packaged on non-RH systems, require "libtoolize" to be able to build for multilib'ed RH- architectures. This then can pull-in a chain of further dependencies, esp. with source-packages sticking with obsolete versions of the autotools (E.g. many Gnome packages). All in all, I consider using patches instead of "autoreconf"'ing to be the only acceptable approach and therefore consider running autoreconf inside of a spec to a bug. Ralf From adrian at lisas.de Mon Feb 14 10:21:33 2005 From: adrian at lisas.de (Adrian Reber) Date: Mon, 14 Feb 2005 11:21:33 +0100 Subject: New package for review: gnome-cpufreq-applet In-Reply-To: <1108335369.7436.102.camel@localhost.localdomain> References: <20050212220424.GA2631@lisas.de> <1108261541.9406.1.camel@continuity> <1108294104.6116.10.camel@localhost.localdomain> <20050213115849.GB16941@lisas.de> <1108296905.6116.16.camel@localhost.localdomain> <1108323192.7436.81.camel@localhost.localdomain> <20050213211440.GB3170@lisas.de> <1108335369.7436.102.camel@localhost.localdomain> Message-ID: <20050214102133.GA2655@lisas.de> On Sun, Feb 13, 2005 at 10:56:08PM +0000, David Woodhouse wrote: > >Didn't knew that it is in rawhide. This probably means that it will be > >also there in FC4 and then it doesn't make much sense to provide it in > >Fedora Extras for FC3, or does it? > > Surely it makes sense to provide it in Extras for FC3, just not for FC4? Okay. So if there aren't any further objections I will import it into CVS. Adrian From gauret at free.fr Mon Feb 14 10:22:47 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 14 Feb 2005 11:22:47 +0100 Subject: pybliographer update References: Message-ID: Hi, Zoltan Kota wrote: > I would like to update pybliographer in extras. So, now I need a sponsor > as I know. Aurelien, Ville (for example :-)? You were the most active > persons regarding my package submissions at fedora.us. If I understood correctly, the process is going to change in a few days, but if you want to update your package right now I can import it for you. Just put your spec file (and sources if needed) somewhere on the web. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn From fedora at wir-sind-cool.org Mon Feb 14 10:34:05 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 14 Feb 2005 11:34:05 +0100 Subject: sqlite In-Reply-To: <1108344862.6792.118.camel@localhost.localdomain> References: <1108344105.7436.121.camel@localhost.localdomain> <1108344862.6792.118.camel@localhost.localdomain> Message-ID: <20050214113405.725f0c61.fedora@wir-sind-cool.org> On Mon, 14 Feb 2005 09:34:21 +0800, Colin Charles wrote: > On Mon, 2005-02-14 at 01:21 +0000, David Woodhouse wrote: > > Rawhide has sqlite 3.0.8-3. Is there a reason why Extras has 2.8.15? > > Should we update it? > > If Rawhide has sqlite 3.0.8-3, can we drop it from Extras > eventually/soon? FYI, package in Rawhide is "sqlite3", package in FC3 Extras and older is "sqlite". Same for python-sqlite3 vs. python-sqlite. > But in the meantime, it probably should be bumped up No, the library sonames are not compatible. Hence the different package name. Further, as Jean-Luc Fontaine points out in his reply, fedora.us' sqlite package (and also the sqlite3 candidate from bugzilla QA) included sqlite-tcl. Here, coordination between Core and Extras would be beneficial. From dwmw2 at infradead.org Mon Feb 14 10:52:06 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 14 Feb 2005 10:52:06 +0000 Subject: sqlite In-Reply-To: <20050214113405.725f0c61.fedora@wir-sind-cool.org> References: <1108344105.7436.121.camel@localhost.localdomain> <1108344862.6792.118.camel@localhost.localdomain> <20050214113405.725f0c61.fedora@wir-sind-cool.org> Message-ID: <1108378326.4567.10.camel@localhost.localdomain> On Mon, 2005-02-14 at 11:34 +0100, Michael Schwendt wrote: >No, the library sonames are not compatible. Hence the different package >name. What is there that we need to remain compatible with? Are there packages outside Fedora Extras which are using 'sqlite' by name and require version 2? When introducing new versions it's customary to rename the _old_ version and let the new version keep the real name, isn't it? And if we do that, do we really need to keep 'sqlite2' around? (My only interest here is that sqlite2 failed its own tests on PPC so I want it to die, btw: http://peach.infradead.org/extras/#sqlite :) -- dwmw2 From fedora at wir-sind-cool.org Mon Feb 14 11:55:26 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 14 Feb 2005 12:55:26 +0100 Subject: sqlite In-Reply-To: <1108378326.4567.10.camel@localhost.localdomain> References: <1108344105.7436.121.camel@localhost.localdomain> <1108344862.6792.118.camel@localhost.localdomain> <20050214113405.725f0c61.fedora@wir-sind-cool.org> <1108378326.4567.10.camel@localhost.localdomain> Message-ID: <20050214125526.38bc90c3.fedora@wir-sind-cool.org> On Mon, 14 Feb 2005 10:52:06 +0000, David Woodhouse wrote: > On Mon, 2005-02-14 at 11:34 +0100, Michael Schwendt wrote: > >No, the library sonames are not compatible. Hence the different package > >name. > > What is there that we need to remain compatible with? Current dependencies in Extras are: * kannel * moodss * php-pecl-sqlite * python-sqlite > Are there packages > outside Fedora Extras which are using 'sqlite' by name and require > version 2? Can't answer that. It would be a package bug in a binary 3rd party package to require 'sqlite' by name. > When introducing new versions it's customary to rename the > _old_ version and let the new version keep the real name, isn't it? Sometimes only. It makes sense to create sqlite3 packages and continue to let the v2 series use the 'sqlite' name as long as the v3 series is beta. Even after the first non-beta 3.0.7 it can make sense to evaluate it further before making it the new 'sqlite' main package. > And > if we do that, do we really need to keep 'sqlite2' around? Well, currently only the sqlite v2 packages in Extras provide sqlite-tcl. The Rawhide sqlite3 package doesn't. > (My only interest here is that sqlite2 failed its own tests on PPC so I > want it to die, btw: http://peach.infradead.org/extras/#sqlite :) It also fails on x86_64. From dwmw2 at infradead.org Mon Feb 14 12:39:45 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 14 Feb 2005 12:39:45 +0000 Subject: sqlite In-Reply-To: <20050214125526.38bc90c3.fedora@wir-sind-cool.org> References: <1108344105.7436.121.camel@localhost.localdomain> <1108344862.6792.118.camel@localhost.localdomain> <20050214113405.725f0c61.fedora@wir-sind-cool.org> <1108378326.4567.10.camel@localhost.localdomain> <20050214125526.38bc90c3.fedora@wir-sind-cool.org> Message-ID: <1108384785.4567.29.camel@localhost.localdomain> On Mon, 2005-02-14 at 12:55 +0100, Michael Schwendt wrote: > >Current dependencies in Extras are: > > * kannel > * python-sqlite Those two I know because they account for 8% of the remaining packages listed in http://peach.infradead.org/extras/outstanding.html > * moodss > * php-pecl-sqlite Those two aren't in CVS AFAICT. Am I doing something wrong? Should I be building packages which don't have a -devel branch? >Well, currently only the sqlite v2 packages in Extras provide sqlite-tcl. >The Rawhide sqlite3 package doesn't. OTOH, the rawhide package does actually build on x86_64 and ppc. I suspect the correct answer here is to file a RFE bug to have the tcl bits included in rawhide, then use the same package for FC3 Extras. -- dwmw2 From toshio at tiki-lounge.com Mon Feb 14 13:18:58 2005 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 14 Feb 2005 08:18:58 -0500 Subject: autoreconf vs patching In-Reply-To: <1108373535.31499.471.camel@mccallum.corsepiu.local> References: <20050212220424.GA2631@lisas.de> <1108261541.9406.1.camel@continuity> <1108294104.6116.10.camel@localhost.localdomain> <1108304135.17301.23.camel@Madison.badger.com> <1108309776.6116.45.camel@localhost.localdomain> <20050213190353.670954bb.fedora@wir-sind-cool.org> <1108373535.31499.471.camel@mccallum.corsepiu.local> Message-ID: <1108387139.22178.78.camel@Madison.badger.com> On Mon, 2005-02-14 at 10:32 +0100, Ralf Corsepius wrote: Re: including patches for autotools generated files. > IMO, this is the only feasible approach, for 2 reasons: > 1. This is how the autotools are assumed to be used. > > Packagers are not supposed to run any of them when building a package. > If you find you can't avoid running them, something inside of the > package is broken - Unfortunately there are many broken and mal-designed > package configurations out there :( > Here here. I think the problem is that autotools are the means by which software is made portable but most software developers have only a few systems types on which to develop... so it's the distro packagers of their software (us) that end up fixing the autotools scripts to work. > 2. Running autoreconf is error-prone and can break packages in subtile > and hard to find ways. > > In probably >> 90% of all cases it will work without too many problems, > but those cases it doesn't work out often are even hard to recognize. > (I.e. you only think autoreconf worked, while it actually failed.) > > When using patches, you very likely recognize these cases and will be > able to fix them. > Hmm... Here's where we part ways for the time being. Probably because I've only worked on those 90% of packages so far :-) If you have some redhat/fedora.us bugzilla entries or some examples of how autoreconf messes up, I'd like to look at them so I can understand how things break and how patching would make spotting the errors easier. -Toshio -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at wir-sind-cool.org Mon Feb 14 13:37:19 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 14 Feb 2005 14:37:19 +0100 Subject: sqlite In-Reply-To: <1108384785.4567.29.camel@localhost.localdomain> References: <1108344105.7436.121.camel@localhost.localdomain> <1108344862.6792.118.camel@localhost.localdomain> <20050214113405.725f0c61.fedora@wir-sind-cool.org> <1108378326.4567.10.camel@localhost.localdomain> <20050214125526.38bc90c3.fedora@wir-sind-cool.org> <1108384785.4567.29.camel@localhost.localdomain> Message-ID: <20050214143719.1a6185a6.fedora@wir-sind-cool.org> On Mon, 14 Feb 2005 12:39:45 +0000, David Woodhouse wrote: > > * moodss > > * php-pecl-sqlite > > Those two aren't in CVS AFAICT. Am I doing something wrong? Should I be > building packages which don't have a -devel branch? Sure they are. And they are in the i386 tree, too. From fedora at wir-sind-cool.org Mon Feb 14 13:43:42 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 14 Feb 2005 14:43:42 +0100 Subject: Request for package import: qcad In-Reply-To: <20050213213107.6997493d.fedora@wir-sind-cool.org> References: <1108319927.13592.7.camel@scriabin.tannenrauch.ch> <20050213213107.6997493d.fedora@wir-sind-cool.org> Message-ID: <20050214144342.140d24d1.fedora@wir-sind-cool.org> On Sun, 13 Feb 2005 21:31:07 +0100, Michael Schwendt wrote: > On Sun, 13 Feb 2005 19:38:46 +0100, G?rard Milmeister wrote: > > > The CAD application qcad at > > http://www.ifi.unizh.ch/staff/milmei/rpms/qcad-2.0.4.0-1.src.rpm > > has been in bugzilla.us for some time > > http://bugzilla.fedora.us/show_bug.cgi?id=848 > > > > I think most of the issues have been resolved. > > Menu > Help > Manual works, but needs qt-devel for /usr/bin/assistant. > > It would probably be better to move assistant to qt. > > Yes. Please file an RFE, because qt-devel is >20 MB. Ok, now that the Qt maintainer closed the RFE as WONTFIX, we need an alternative (qt-devel on FC3 contains the 26 MB html docs two times due to a bug). a) Split off a qcad-manual package which then can depend on qt-devel just for Qt Assistant. b) Add a Qt warning dialog when /usr/bin/assistant does not exist (will be English only; but the manual is English only, too) c) Delete the dependency on /usr/bin/assistant and have a non-working QCad help menu when qt-devel is not installed. FWIW, I'm for a) or for b), but interested in other comments. From dwmw2 at infradead.org Mon Feb 14 13:54:30 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 14 Feb 2005 13:54:30 +0000 Subject: sqlite In-Reply-To: <20050214143719.1a6185a6.fedora@wir-sind-cool.org> References: <1108344105.7436.121.camel@localhost.localdomain> <1108344862.6792.118.camel@localhost.localdomain> <20050214113405.725f0c61.fedora@wir-sind-cool.org> <1108378326.4567.10.camel@localhost.localdomain> <20050214125526.38bc90c3.fedora@wir-sind-cool.org> <1108384785.4567.29.camel@localhost.localdomain> <20050214143719.1a6185a6.fedora@wir-sind-cool.org> Message-ID: <1108389271.19262.577.camel@hades.cambridge.redhat.com> On Mon, 2005-02-14 at 14:37 +0100, Michael Schwendt wrote: > On Mon, 14 Feb 2005 12:39:45 +0000, David Woodhouse wrote: > > > > * moodss > > > * php-pecl-sqlite > > > > Those two aren't in CVS AFAICT. Am I doing something wrong? Should I be > > building packages which don't have a -devel branch? > > Sure they are. And they are in the i386 tree, too. Hm, you're right. It's just that both of them appeared to build fine even without sqlite installed. I didn't look in the 'built' list for them :) -- dwmw2 From s.mako at gmx.net Mon Feb 14 14:09:57 2005 From: s.mako at gmx.net (Zoltan Kota) Date: Mon, 14 Feb 2005 15:09:57 +0100 (CET) Subject: pybliographer update In-Reply-To: References: Message-ID: On Mon, 14 Feb 2005, Aurelien Bompard wrote: > > I would like to update pybliographer in extras. So, now I need a sponsor > > as I know. Aurelien, Ville (for example :-)? You were the most active > > persons regarding my package submissions at fedora.us. > > If I understood correctly, the process is going to change in a few days, but > if you want to update your package right now I can import it for you. Just > put your spec file (and sources if needed) somewhere on the web. OK. Thanks! (We will see what will be the situation after Fudcon :-) Zoltan From gauret at free.fr Mon Feb 14 16:13:10 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 14 Feb 2005 17:13:10 +0100 Subject: amarok 1.2 Message-ID: Hi all, I've just updated amarok 1.2 in CVS. Since it's a pretty big update, I'd be happy if someone who likes amarok could test it for a day or two before I ask for the official build. Thanks Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info In God we Trust. All others must submit an X.509 certificate. From gemi at bluewin.ch Mon Feb 14 18:01:10 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 14 Feb 2005 19:01:10 +0100 Subject: qcad and qt assistant Message-ID: <1108404070.18219.2.camel@scriabin.tannenrauch.ch> I don't really see a problem of moving assitant over to qt. If qt-devel is not installed, then assitant simply doesn't show the qt help, when invoked. I suppose that there are other apps around that use assistant as their help viewer. However I propose a simple solution for now: Copy the binary /usr/lib/qt-3.3/bin/assistant to /usr/bin/qcad-assistant and include it in the rpm for qcad. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From fkooman at tuxed.net Mon Feb 14 18:09:04 2005 From: fkooman at tuxed.net (F. Kooman) Date: Mon, 14 Feb 2005 19:09:04 +0100 Subject: amarok 1.2 In-Reply-To: References: Message-ID: <1108404544.15543.13.camel@dilithium.bromstraat.net> On Mon, 2005-02-14 at 17:13 +0100, Aurelien Bompard wrote: > Hi all, > > I've just updated amarok 1.2 in CVS. Since it's a pretty big update, I'd be > happy if someone who likes amarok could test it for a day or two before I > ask for the official build. I can't find Amarok in the Sound & Video menu using GNOME. Maybe because it's desktop file is located in the applications/kde directory? [fkooman at dilithium ~]$ rpm -ql amarok | grep desktop$ /usr/share/applications/kde/fedora-amarok.desktop [..] Comparing to K3B for example: [fkooman at dilithium ~]$ rpm -ql k3b | grep desktop$ /usr/share/applications/fedora-k3b.desktop [..] I like Amarok so far, so maybe it's a good idea to also put in the GNOME menus :) Fran?ois -- Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html From rdieter at math.unl.edu Mon Feb 14 18:50:36 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 14 Feb 2005 12:50:36 -0600 Subject: amarok 1.2 In-Reply-To: <1108404544.15543.13.camel@dilithium.bromstraat.net> References: <1108404544.15543.13.camel@dilithium.bromstraat.net> Message-ID: <4210F2FC.8010103@math.unl.edu> F. Kooman wrote: > On Mon, 2005-02-14 at 17:13 +0100, Aurelien Bompard wrote: > >>Hi all, >> >>I've just updated amarok 1.2 in CVS. Since it's a pretty big update, I'd be >>happy if someone who likes amarok could test it for a day or two before I >>ask for the official build. > > > I can't find Amarok in the Sound & Video menu using GNOME. Maybe because > it's desktop file is located in the applications/kde directory? Shouldn't matter. gnome *should* find it in applications or any subdirectory thereof. At least that's what the freedesktop.org standard allows, and if gnome doesn't find it, it's a bug. -- Rex From ville.skytta at iki.fi Mon Feb 14 19:12:44 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 14 Feb 2005 21:12:44 +0200 Subject: amarok 1.2 In-Reply-To: <4210F2FC.8010103@math.unl.edu> References: <1108404544.15543.13.camel@dilithium.bromstraat.net> <4210F2FC.8010103@math.unl.edu> Message-ID: <1108408364.5281.430.camel@bobcat.mine.nu> On Mon, 2005-02-14 at 12:50 -0600, Rex Dieter wrote: > F. Kooman wrote: > > On Mon, 2005-02-14 at 17:13 +0100, Aurelien Bompard wrote: > > > >>Hi all, > >> > >>I've just updated amarok 1.2 in CVS. Since it's a pretty big update, I'd be > >>happy if someone who likes amarok could test it for a day or two before I > >>ask for the official build. > > > > > > I can't find Amarok in the Sound & Video menu using GNOME. Maybe because > > it's desktop file is located in the applications/kde directory? > > Shouldn't matter. gnome *should* find it in applications or any > subdirectory thereof. At least that's what the freedesktop.org standard > allows, and if gnome doesn't find it, it's a bug. The amarok specfile does: desktop-file-install [...] --add-only-show-in KDE [...] From fedora at wir-sind-cool.org Mon Feb 14 19:31:27 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 14 Feb 2005 20:31:27 +0100 Subject: qcad and qt assistant In-Reply-To: <1108404070.18219.2.camel@scriabin.tannenrauch.ch> References: <1108404070.18219.2.camel@scriabin.tannenrauch.ch> Message-ID: <20050214203127.0d5b015e.fedora@wir-sind-cool.org> On Mon, 14 Feb 2005 19:01:10 +0100, G?rard Milmeister wrote: > I don't really see a problem of moving assitant over to qt. If qt-devel > is not installed, then assitant simply doesn't show the qt help, when > invoked. > I suppose that there are other apps around that use assistant as their > help viewer. > However I propose a simple solution for now: Copy the > binary /usr/lib/qt-3.3/bin/assistant to /usr/bin/qcad-assistant and > include it in the rpm for qcad. I've sent two of the three attached patches upstream. The first one opens a Qt warning dialog when Qt Assistant can't be launched or encounters other errors. The second one removes references to two missing images in the English manual. The third is a diff against current spec file. -------------- next part -------------- A non-text attachment was scrubbed... Name: qcad-assistant.patch Type: application/octet-stream Size: 1275 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qcad-manual-bugs.patch Type: application/octet-stream Size: 814 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qcad.spec.patch Type: application/octet-stream Size: 828 bytes Desc: not available URL: From gemi at bluewin.ch Mon Feb 14 21:20:20 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 14 Feb 2005 22:20:20 +0100 Subject: qcad and qt assistant In-Reply-To: <20050214203127.0d5b015e.fedora@wir-sind-cool.org> References: <1108404070.18219.2.camel@scriabin.tannenrauch.ch> <20050214203127.0d5b015e.fedora@wir-sind-cool.org> Message-ID: <1108416020.7902.2.camel@scriabin.tannenrauch.ch> On Mon, 2005-02-14 at 20:31 +0100, Michael Schwendt wrote: > On Mon, 14 Feb 2005 19:01:10 +0100, G?rard Milmeister wrote: > > > I don't really see a problem of moving assitant over to qt. If qt-devel > > is not installed, then assitant simply doesn't show the qt help, when > > invoked. > > I suppose that there are other apps around that use assistant as their > > help viewer. > > However I propose a simple solution for now: Copy the > > binary /usr/lib/qt-3.3/bin/assistant to /usr/bin/qcad-assistant and > > include it in the rpm for qcad. > > I've sent two of the three attached patches upstream. > > The first one opens a Qt warning dialog when Qt Assistant can't be > launched or encounters other errors. The second one removes references to > two missing images in the English manual. > > The third is a diff against current spec file. The problem here is that the warning dialog doesn't give the user a hint that he has to install qt-devel. I tried out my idea of a solution and included a copy of assistant as /usr/libexec/qcad/assistant. However on installing the resulting rpm, I get "unpacking of archive failed on file /usr/libexec/qcad/assistant;4211154a: cpio: MD5 sum mismatch" -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From gauret at free.fr Mon Feb 14 22:00:03 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 14 Feb 2005 23:00:03 +0100 Subject: amarok 1.2 References: <1108404544.15543.13.camel@dilithium.bromstraat.net> <4210F2FC.8010103@math.unl.edu> <1108408364.5281.430.camel@bobcat.mine.nu> Message-ID: Ville Skytt? wrote: > The amarok specfile does: > desktop-file-install [...] --add-only-show-in KDE [...] True. I've removed this statement, thanks. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "Never trust a computer you can't throw out a window." -- Steve Wozniak From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 14 22:16:00 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 14 Feb 2005 23:16:00 +0100 Subject: Requests for extras In-Reply-To: <420F7B8F.10003@lowlatency.de> References: <420F7B8F.10003@lowlatency.de> Message-ID: <20050214231600.37f243b9@python2> Andreas Bierfert wrote : > kino 0.7.5: Kino is a non-linear DV editor for GNU/Linux > http://kino.schirmacher.de To be full-featured, kino unfortunately requires to be built against some libraries that cannot be included in Fedora Extras, like a52dec, ffmpeg and libquicktime. So I don't think it'll ever make it in... at least not until those deps can be split into some form of plugins, too bad. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.21 0.31 0.30 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 14 22:18:18 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 14 Feb 2005 23:18:18 +0100 Subject: cvs-import: allow extra commit message In-Reply-To: <1108325075.5281.316.camel@bobcat.mine.nu> References: <1108325075.5281.316.camel@bobcat.mine.nu> Message-ID: <20050214231818.422cd4ac@python2> Ville Skytt? wrote : > I think it'd be useful to be able to add a "real" commit message along > with the auto-import one generated by cvs-import.sh. I tested this when > importing perl-HTML-Tree a few minutes ago. > > Any objections against applying the attached patch? Without knowing any of the technical implications (although with a glance at the patch, I don't see any, myself), I'd personally appreciate this change :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.61 0.39 0.31 From fedora at wir-sind-cool.org Mon Feb 14 22:21:09 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 14 Feb 2005 23:21:09 +0100 Subject: qcad and qt assistant In-Reply-To: <1108416020.7902.2.camel@scriabin.tannenrauch.ch> References: <1108404070.18219.2.camel@scriabin.tannenrauch.ch> <20050214203127.0d5b015e.fedora@wir-sind-cool.org> <1108416020.7902.2.camel@scriabin.tannenrauch.ch> Message-ID: <20050214232109.4d39c5c1.fedora@wir-sind-cool.org> On Mon, 14 Feb 2005 22:20:20 +0100, G?rard Milmeister wrote: > > I've sent two of the three attached patches upstream. > > > > The first one opens a Qt warning dialog when Qt Assistant can't be > > launched or encounters other errors. The second one removes references to > > two missing images in the English manual. > > > > The third is a diff against current spec file. > > The problem here is that the warning dialog doesn't give the user a hint > that he has to install qt-devel. Well, I consider feedback much better than no feedback at all. And I wanted to propose something which can be merged upstream. At least the warning dialog says that /usr/bin/assistant ... could not be started. But the attached revised patch adds the message "If Qt Assistant is missing, you need to install the qt-devel package." It only adds this, if Qt Assistant could not be started. That can be due to several reasons, though, such as help files not found. -------------- next part -------------- A non-text attachment was scrubbed... Name: qcad-assistant.patch Type: application/octet-stream Size: 1445 bytes Desc: not available URL: From gemi at bluewin.ch Mon Feb 14 22:29:29 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 14 Feb 2005 23:29:29 +0100 Subject: qcad and qt assistant In-Reply-To: <20050214232109.4d39c5c1.fedora@wir-sind-cool.org> References: <1108404070.18219.2.camel@scriabin.tannenrauch.ch> <20050214203127.0d5b015e.fedora@wir-sind-cool.org> <1108416020.7902.2.camel@scriabin.tannenrauch.ch> <20050214232109.4d39c5c1.fedora@wir-sind-cool.org> Message-ID: <1108420170.30749.0.camel@scriabin.tannenrauch.ch> On Mon, 2005-02-14 at 23:21 +0100, Michael Schwendt wrote: > On Mon, 14 Feb 2005 22:20:20 +0100, G?rard Milmeister wrote: > > > > I've sent two of the three attached patches upstream. > > > > > > The first one opens a Qt warning dialog when Qt Assistant can't be > > > launched or encounters other errors. The second one removes references to > > > two missing images in the English manual. > > > > > > The third is a diff against current spec file. > > > > The problem here is that the warning dialog doesn't give the user a hint > > that he has to install qt-devel. > > Well, I consider feedback much better than no feedback at all. And I > wanted to propose something which can be merged upstream. At least the > warning dialog says that /usr/bin/assistant ... could not be started. > > But the attached revised patch adds the message "If Qt Assistant is > missing, you need to install the qt-devel package." It only adds this, if > Qt Assistant could not be started. That can be due to several reasons, > though, such as help files not found. So let us go for this. Will you checkin the patches? -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From fedora at wir-sind-cool.org Mon Feb 14 22:33:06 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 14 Feb 2005 23:33:06 +0100 Subject: qcad and qt assistant In-Reply-To: <1108420170.30749.0.camel@scriabin.tannenrauch.ch> References: <1108404070.18219.2.camel@scriabin.tannenrauch.ch> <20050214203127.0d5b015e.fedora@wir-sind-cool.org> <1108416020.7902.2.camel@scriabin.tannenrauch.ch> <20050214232109.4d39c5c1.fedora@wir-sind-cool.org> <1108420170.30749.0.camel@scriabin.tannenrauch.ch> Message-ID: <20050214233306.047a9c77.fedora@wir-sind-cool.org> On Mon, 14 Feb 2005 23:29:29 +0100, G?rard Milmeister wrote: > On Mon, 2005-02-14 at 23:21 +0100, Michael Schwendt wrote: > > On Mon, 14 Feb 2005 22:20:20 +0100, G?rard Milmeister wrote: > > > > > > I've sent two of the three attached patches upstream. > > > > > > > > The first one opens a Qt warning dialog when Qt Assistant can't be > > > > launched or encounters other errors. The second one removes references to > > > > two missing images in the English manual. > > > > > > > > The third is a diff against current spec file. > > > > > > The problem here is that the warning dialog doesn't give the user a hint > > > that he has to install qt-devel. > > > > Well, I consider feedback much better than no feedback at all. And I > > wanted to propose something which can be merged upstream. At least the > > warning dialog says that /usr/bin/assistant ... could not be started. > > > > But the attached revised patch adds the message "If Qt Assistant is > > missing, you need to install the qt-devel package." It only adds this, if > > Qt Assistant could not be started. That can be due to several reasons, > > though, such as help files not found. > > So let us go for this. Will you checkin the patches? Okay. From gemi at bluewin.ch Mon Feb 14 22:38:34 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 14 Feb 2005 23:38:34 +0100 Subject: Request for package import: skencil Message-ID: <1108420714.5083.4.camel@scriabin.tannenrauch.ch> I repackaged skencil (from atrpms) for Extras: http://www.ifi.unizh.ch/staff/milmei/rpms/skencil-0.6.16-1.src.rpm The package from atrpms conflicts with python-imaging included in Extras. I further added an icon, a .desktop file and a mime type for skencil documents. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From pcompton at proteinmedia.com Tue Feb 15 01:14:46 2005 From: pcompton at proteinmedia.com (Phillip Compton) Date: Mon, 14 Feb 2005 20:14:46 -0500 Subject: Request for package import: qcad In-Reply-To: <20050214144342.140d24d1.fedora@wir-sind-cool.org> References: <1108319927.13592.7.camel@scriabin.tannenrauch.ch> <20050213213107.6997493d.fedora@wir-sind-cool.org> <20050214144342.140d24d1.fedora@wir-sind-cool.org> Message-ID: <1108430086.5259.1.camel@earlgrey.compton.net> On Mon, 2005-02-14 at 14:43 +0100, Michael Schwendt wrote: > Ok, now that the Qt maintainer closed the RFE as WONTFIX, we need an > alternative (qt-devel on FC3 contains the 26 MB html docs two times due to > a bug). > > a) Split off a qcad-manual package which then can depend on qt-devel > just for Qt Assistant. > b) Add a Qt warning dialog when /usr/bin/assistant does not exist > (will be English only; but the manual is English only, too) > c) Delete the dependency on /usr/bin/assistant and have a non-working > QCad help menu when qt-devel is not installed. > > FWIW, I'm for a) or for b), but interested in other comments. I'm for a), although I would vote for qcad-docs as the sub-package. Phil From rc040203 at freenet.de Tue Feb 15 04:02:35 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 15 Feb 2005 05:02:35 +0100 Subject: autoreconf vs patching In-Reply-To: <1108387139.22178.78.camel@Madison.badger.com> References: <20050212220424.GA2631@lisas.de> <1108261541.9406.1.camel@continuity> <1108294104.6116.10.camel@localhost.localdomain> <1108304135.17301.23.camel@Madison.badger.com> <1108309776.6116.45.camel@localhost.localdomain> <20050213190353.670954bb.fedora@wir-sind-cool.org> <1108373535.31499.471.camel@mccallum.corsepiu.local> <1108387139.22178.78.camel@Madison.badger.com> Message-ID: <1108440156.31499.621.camel@mccallum.corsepiu.local> On Mon, 2005-02-14 at 08:18 -0500, Toshio wrote: > On Mon, 2005-02-14 at 10:32 +0100, Ralf Corsepius wrote: > Re: including patches for autotools generated files. > > IMO, this is the only feasible approach, for 2 reasons: > > 1. This is how the autotools are assumed to be used. > > > > Packagers are not supposed to run any of them when building a package. > > If you find you can't avoid running them, something inside of the > > package is broken - Unfortunately there are many broken and mal-designed > > package configurations out there :( > > > Here here. I think the problem is that autotools are the means by which > software is made portable but most software developers have only a few > systems types on which to develop... so it's the distro packagers of > their software (us) that end up fixing the autotools scripts to work. Yes, but ... how many times do you end up adjusting sources for other tools? The autotools are developer tools like many others, so similar to you having to fix broken/incompatible c/c++ code, adjusting hard-coded paths, broken scripts etc. you'll have to cope with them. I.e. the "right way" to deal with such problems would be to get these packages fixed upstream or not to package these packages ("We can't package your package is broken and needs to be fixed"). > > 2. Running autoreconf is error-prone and can break packages in subtile > > and hard to find ways. > > > > In probably >> 90% of all cases it will work without too many problems, > > but those cases it doesn't work out often are even hard to recognize. > > (I.e. you only think autoreconf worked, while it actually failed.) > > > > When using patches, you very likely recognize these cases and will be > > able to fix them. > > > Hmm... Here's where we part ways for the time being. Probably because > I've only worked on those 90% of packages so far :-) Probably :-) From the autotools' POV, probably >>90% of all packages are trivial. The remaining 10% can be hard, sometimes very hard. > If you have some > redhat/fedora.us bugzilla entries or some examples of how autoreconf > messes up, I'd like to look at them so I can understand how things break > and how patching would make spotting the errors easier. Well, it basically is a matter of complexity. Typical examples for case when autoreconf can break things are * Running autoreconf on configurations using advanced autoconf tricks to setup configuration subdirectories or mixing versions of autotools across configuration subdirs. Somewhat oversimplifying: Using autoreconf becomes dangerous when a package consist of several subpackages. * Running autoreconf will run the currently installed of current autotools. In cases configurations have been written using older/obsolete versions of the autotools, this can introduce behavioral changes or even break configurations, because the autotools have changed their behavior or because a package author might have exploited autotools internals which meanwhile have changed. * Running autoreconf on configurations having been created by customized/modified/hacked autotools. E.g. RH's libtool is such kind of "hacked" autotool, i.e. running a non-RH libtool on configurations having been created by RH-libtool can break a package - Of cause this will not hit you on RH-based systems :) However, others also use similar "modified/customized" autotools and ship scripts having been generated by these tools, so you are likely to trip problems related to the "hacks" they apply. * Like any other tools, autoreconf is not bug-free. It is known to fail due to bugs in some cases (c.f. autoconf's CVS). If you want to see some of these problems, take a complex source-tree and try autoreconf on them. One case to try would be running autoreconf on packages or sub-packages from the "uberbaum", e.g. GCC, binutils, snavigator. insight, gdb etc. Ralf From funkyres at gmail.com Tue Feb 15 06:19:29 2005 From: funkyres at gmail.com (Michael Peters) Date: Mon, 14 Feb 2005 22:19:29 -0800 Subject: Request for Package: madwifi and wpa Message-ID: <485bb88405021422195d610656@mail.gmail.com> I'd like to request a package for Fedora Extras - madwifi - and probably wpa_supplicant I apologize if they have been requested, I seen unable to find where existing requested packages are. I'm assuming there is a bugzilla place for these requests where they are suppose to go, I have not been able to find it (looked at fedora.us and the link from there to http://www.fedoraproject.org/ - and did not see it) I did see a extras as a product at the bugzilla.redhat.com bugzilla, but did not see how to add a request there. I do not wish to maintain either of them, but I have a spec file (attached) for madwifi based on the spec file from http://pipiche.free.fr/Downloads/Fedora/SRPMS/ that someone could start with, if they wanted. It may not be up to extras spec file policy, but I looked in the list archives for what that was, found a link from earlier this month - and it's 404 - http://fedoraproject.org/Extras I changed the spec file to put the tools in /usr/bin instead of /usr/local/bin - and I changed the name of the kernel module package to match what rpm.livna.org does with their kernel modules. The project is still in beta without a stable release yet, hence the cvs nature. -=- wpa_supplicant has a stable release and is located at http://hostap.epitest.fi/wpa_supplicant/ It's a daemon, an init script would likely be needed, I *think* the init script needs to be started before the wifi card is brought up, but I'm still reading through the docs (and deciding whether or not wpa is something I really need where I live - community where parking on street is forbidden, no thru traffic, big field behind my house with coyotes, etc.) I don't believe either has any legal issues, madwifi kernel taints because of an FCC regulation (though I wonder if that part could be removed from kernel module and done in userspace). -- http://mpeters.us/ -------------- next part -------------- A non-text attachment was scrubbed... Name: madwifi.spec Type: application/octet-stream Size: 2878 bytes Desc: not available URL: From fedora at leemhuis.info Tue Feb 15 06:44:59 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 15 Feb 2005 07:44:59 +0100 Subject: Request for Package: madwifi and wpa In-Reply-To: <485bb88405021422195d610656@mail.gmail.com> References: <485bb88405021422195d610656@mail.gmail.com> Message-ID: <1108449899.4692.6.camel@thl.ct.heise.de> Am Montag, den 14.02.2005, 22:19 -0800 schrieb Michael Peters: > I'd like to request a package for Fedora Extras - madwifi - and > probably wpa_supplicant > I apologize if they have been requested, I seen unable to find where > existing requested packages are. AFAIK there are legal problems with the madwifi firmware - IANAL but when I read http://www.mattfoster.clara.co.uk/madwifi-5.htm I thought madwifi was not a candidate for fedora-extras. So I submitted it to livna: http://bugzilla.livna.org/show_bug.cgi?id=319 ATM it has "PUBLISH +1" give it another review and we can publish it ;-) CU thl -- Thorsten Leemhuis From dwmw2 at infradead.org Tue Feb 15 08:32:18 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 15 Feb 2005 08:32:18 +0000 Subject: Request for Package: madwifi and wpa In-Reply-To: <1108449899.4692.6.camel@thl.ct.heise.de> References: <485bb88405021422195d610656@mail.gmail.com> <1108449899.4692.6.camel@thl.ct.heise.de> Message-ID: <1108456338.22597.44.camel@baythorne.infradead.org> On Tue, 2005-02-15 at 07:44 +0100, Thorsten Leemhuis wrote: > AFAIK there are legal problems with the madwifi firmware - IANAL but > when I read http://www.mattfoster.clara.co.uk/madwifi-5.htm > I thought madwifi was not a candidate for fedora-extras. So I > submitted it to livna: Make it use the OpenBSD HAL and it should be OK in Extras. -- dwmw2 From giallu at gmail.com Tue Feb 15 08:42:57 2005 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 15 Feb 2005 09:42:57 +0100 Subject: Requests for extras In-Reply-To: <20050214231600.37f243b9@python2> References: <420F7B8F.10003@lowlatency.de> <20050214231600.37f243b9@python2> Message-ID: On Mon, 14 Feb 2005 23:16:00 +0100, Matthias Saou wrote: > Andreas Bierfert wrote : > > > kino 0.7.5: Kino is a non-linear DV editor for GNU/Linux > > http://kino.schirmacher.de > > To be full-featured, kino unfortunately requires to be built against some > libraries that cannot be included in Fedora Extras, like a52dec, ffmpeg and > libquicktime. So I don't think it'll ever make it in... at least not until > those deps can be split into some form of plugins, too bad. At least can we push it to livna?? From fedora at wir-sind-cool.org Tue Feb 15 08:48:44 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 15 Feb 2005 09:48:44 +0100 Subject: qcad and qt assistant In-Reply-To: <1108404070.18219.2.camel@scriabin.tannenrauch.ch> References: <1108404070.18219.2.camel@scriabin.tannenrauch.ch> Message-ID: <20050215094844.28b06546.fedora@wir-sind-cool.org> On Mon, 14 Feb 2005 19:01:10 +0100, G?rard Milmeister wrote: > I don't really see a problem of moving assitant over to qt. If qt-devel > is not installed, then assitant simply doesn't show the qt help, when > invoked. It opens a series of error boxes, and therefore it really requires the qt-devel html docs. I verified that when I saw the WONTFIX. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 15 08:48:30 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 15 Feb 2005 09:48:30 +0100 Subject: Requests for extras In-Reply-To: References: <420F7B8F.10003@lowlatency.de> <20050214231600.37f243b9@python2> Message-ID: <20050215094830.4853c432@python2> Gianluca Sforna wrote : > On Mon, 14 Feb 2005 23:16:00 +0100, Matthias Saou wrote: > > Andreas Bierfert wrote : > > > > > kino 0.7.5: Kino is a non-linear DV editor for GNU/Linux > > > http://kino.schirmacher.de > > > > To be full-featured, kino unfortunately requires to be built against some > > libraries that cannot be included in Fedora Extras, like a52dec, ffmpeg and > > libquicktime. So I don't think it'll ever make it in... at least not until > > those deps can be split into some form of plugins, too bad. > > At least can we push it to livna?? Feel free to do whatever you want. I've already got packages here : http://freshrpms.net/rpm/kino Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.82 0.50 0.25 From andreas.bierfert at lowlatency.de Tue Feb 15 11:26:48 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Tue, 15 Feb 2005 12:26:48 +0100 Subject: Requests for extras In-Reply-To: References: <420F7B8F.10003@lowlatency.de> <20050214231600.37f243b9@python2> Message-ID: <4211DC78.5040102@lowlatency.de> Gianluca Sforna wrote: > At least can we push it to livna?? Thats what I will do then... -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | () ASCII ribbon campaign | mail preferred cell: +49 172 9789968 | /\ against HTML mail | From enrico.scholz at informatik.tu-chemnitz.de Tue Feb 15 15:38:08 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 15 Feb 2005 16:38:08 +0100 Subject: [patch] Enable proxy-caching for curl Message-ID: <87mzu525r3.fsf@kosh.ultra.csn.tu-chemnitz.de> Hi, I have attached a small patch which prevents 'curl' from sending a 'Pragma: no-cache' header. With this patch, subsequent 'make clean && make i386' will download the tarballs only once. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: curl-cache.patch Type: text/x-patch Size: 829 bytes Desc: prevents 'Pragma: no-cache' header URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From ville.skytta at iki.fi Tue Feb 15 17:02:53 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 15 Feb 2005 19:02:53 +0200 Subject: cvs-import: allow extra commit message In-Reply-To: <20050214231818.422cd4ac@python2> References: <1108325075.5281.316.camel@bobcat.mine.nu> <20050214231818.422cd4ac@python2> Message-ID: <1108486973.29314.56.camel@bobcat.mine.nu> On Mon, 2005-02-14 at 23:18 +0100, Matthias Saou wrote: > Ville Skytt? wrote : > > > I think it'd be useful to be able to add a "real" commit message along > > with the auto-import one generated by cvs-import.sh. I tested this when > > importing perl-HTML-Tree a few minutes ago. > > > > Any objections against applying the attached patch? > > Without knowing any of the technical implications (although with a glance > at the patch, I don't see any, myself), I'd personally appreciate this > change :-) I tried to commit it, but was denied: **** Access denied: scop is not in ACL for common Doh. Could someone help with getting this applied? From ville.skytta at iki.fi Tue Feb 15 17:07:55 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 15 Feb 2005 19:07:55 +0200 Subject: [patch] Enable proxy-caching for curl In-Reply-To: <87mzu525r3.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <87mzu525r3.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1108487275.29314.61.camel@bobcat.mine.nu> On Tue, 2005-02-15 at 16:38 +0100, Enrico Scholz wrote: > I have attached a small patch which prevents 'curl' from sending a > 'Pragma: no-cache' header. With this patch, subsequent 'make clean && > make i386' will download the tarballs only once. But "make clean" removes the tarball, no? From enrico.scholz at informatik.tu-chemnitz.de Tue Feb 15 17:37:51 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 15 Feb 2005 18:37:51 +0100 Subject: [patch] Enable proxy-caching for curl In-Reply-To: <1108487275.29314.61.camel@bobcat.mine.nu> (Ville Skytt's message of "Tue, 15 Feb 2005 19:07:55 +0200") References: <87mzu525r3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1108487275.29314.61.camel@bobcat.mine.nu> Message-ID: <87y8dpzpu8.fsf@kosh.ultra.csn.tu-chemnitz.de> ville.skytta at iki.fi (Ville Skytt?) writes: >> I have attached a small patch which prevents 'curl' from sending a >> 'Pragma: no-cache' header. With this patch, subsequent 'make clean && >> make i386' will download the tarballs only once. > > But "make clean" removes the tarball, no? Yes, but the next 'make' will take the tarball from the proxy, which is cheaper and faster than downloading it from the fedora server. E.g. currently I get: | $ make | --> 1108488444.156 8639 kosh.ultra.csn.tu-chemnitz.de TCP_MISS/200 152497 GET .... | | $ make clean | $ make | --> 1108488476.676 1643 kosh.ultra.csn.tu-chemnitz.de TCP_CLIENT_REFRESH_MISS/200 152497 GET ... --> the file was downloaded twice Applying my patch results into | $ make clean | $ make | --> 1108488572.244 9 kosh.ultra.csn.tu-chemnitz.de TCP_MEM_HIT/200 152505 GET ... --> the file was taken from the cache Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From carwyn at carwyn.com Tue Feb 15 18:09:26 2005 From: carwyn at carwyn.com (Carwyn Edwards) Date: Tue, 15 Feb 2005 18:09:26 +0000 Subject: Package Naming Message-ID: <42123AD6.1090908@carwyn.com> It the new naming stuff here: http://www.fedoraproject.org/wiki/PackageNamingGuidelines .. in progress or is there a good idea of what it will be like? I'm writing naming guidelines for out dev team here (Edinburgh Uni) and was hoping to make them compatible. Carwyn From toshio at tiki-lounge.com Tue Feb 15 19:10:35 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 15 Feb 2005 11:10:35 -0800 Subject: autoreconf vs patching In-Reply-To: <1108440156.31499.621.camel@mccallum.corsepiu.local>; from rc040203@freenet.de on Tue, Feb 15, 2005 at 05:02:35AM +0100 References: <20050212220424.GA2631@lisas.de> <1108261541.9406.1.camel@continuity> <1108294104.6116.10.camel@localhost.localdomain> <1108304135.17301.23.camel@Madison.badger.com> <1108309776.6116.45.camel@localhost.localdomain> <20050213190353.670954bb.fedora@wir-sind-cool.org> <1108373535.31499.471.camel@mccallum.corsepiu.local> <1108387139.22178.78.camel@Madison.badger.com> <1108440156.31499.621.camel@mccallum.corsepiu.local> Message-ID: <20050215111035.A1428@tiki-lounge.com> On Tue, Feb 15, 2005 at 05:02:35AM +0100, Ralf Corsepius wrote: > On Mon, 2005-02-14 at 08:18 -0500, Toshio wrote: > > On Mon, 2005-02-14 at 10:32 +0100, Ralf Corsepius wrote: > > Re: including patches for autotools generated files. > > > IMO, this is the only feasible approach, for 2 reasons: > > > 1. This is how the autotools are assumed to be used. > > > > > > Packagers are not supposed to run any of them when building a package. > > > If you find you can't avoid running them, something inside of the > > > package is broken - Unfortunately there are many broken and mal-designed > > > package configurations out there :( > > > > > Here here. I think the problem is that autotools are the means by which > > software is made portable but most software developers have only a few > > systems types on which to develop... so it's the distro packagers of > > their software (us) that end up fixing the autotools scripts to work. > Yes, but ... how many times do you end up adjusting sources for other > tools? > > The autotools are developer tools like many others, so similar to you > having to fix broken/incompatible c/c++ code, adjusting hard-coded > paths, broken scripts etc. you'll have to cope with them. > > I.e. the "right way" to deal with such problems would be to get these > packages fixed upstream or not to package these packages ("We can't > package your package is broken and needs to be fixed"). > I agree that the packages need to be fixed upstream. However, if we want a piece of software in for FC3 and the next release is in 6 months, aren't we stuck fixing the problems ourselves and sending the patches we generate upstream? (Unless we can backport from upstream, of course.) This is something that is up to the volunteer offering to package the software -- "I'm willing to spend time fixing the auto-tools scripts" or "I've got other software I want to get in... I'll report the bug and wait for the next version." > > If you have some > > redhat/fedora.us bugzilla entries or some examples of how autoreconf > > messes up, I'd like to look at them so I can understand how things break > > and how patching would make spotting the errors easier. > Well, it basically is a matter of complexity. > > Typical examples for case when autoreconf can break things are > > * Running autoreconf on configurations using advanced autoconf tricks to > setup configuration subdirectories or mixing versions of autotools > across configuration subdirs. > Somewhat oversimplifying: Using autoreconf becomes dangerous when a > package consist of several subpackages. > But running autoreconf on each subpackage should alleviate this aspect, right? (It doesn't address the ramifications of this though... that one subpackage may be okay to run with the latest autotools while another may require an earlier version... but see below) > * Running autoreconf will run the currently installed of current > autotools. In cases configurations have been written using > older/obsolete versions of the autotools, this can introduce behavioral > changes or even break configurations, because the autotools have changed > their behavior or because a package author might have exploited > autotools internals which meanwhile have changed. > Which is, however, a bug that should be patched in the configure.ac/etc and sent upstream, yes? Or else requiring specific versions of auto* in the builrequires? The advantage of upstream doing this is they may have some knowledge that moving from automake-1.5 to automake-1.6 broke the build in this way and can check if that happens here as well. The advantage of packagers fixing this is we see a lot of autotools breakage and may be able to spot the proper fixes more easily. > * Running autoreconf on configurations having been created by > customized/modified/hacked autotools. > E.g. RH's libtool is such kind of "hacked" autotool, i.e. running a > non-RH libtool on configurations having been created by RH-libtool can > break a package - Of cause this will not hit you on RH-based systems :) > However, others also use similar "modified/customized" autotools and > ship scripts having been generated by these tools, so you are likely to > trip problems related to the "hacks" they apply. > But this implies that we are commonly going to have to run the autotools on our packages anyhow, yes? > * Like any other tools, autoreconf is not bug-free. It is known to fail > due to bugs in some cases (c.f. autoconf's CVS). > True, but what's the difference for this case when running a buggy autoreconf and generating a patch of the output vs running autoreconf in the spec file? Which is my basic question for any of these points. How is running autoreconf, generating a patch, and then applying that patch from the spec file more robust than running autoreconf from the spec file? > If you want to see some of these problems, take a complex source-tree > and try autoreconf on them. One case to try would be running autoreconf > on packages or sub-packages from the "uberbaum", e.g. GCC, binutils, > snavigator. insight, gdb etc. > Will do. Thanks, -Toshio From jwboyer at jdub.homelinux.org Wed Feb 16 01:04:31 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 15 Feb 2005 19:04:31 -0600 Subject: Request for Package: distcc Message-ID: <1108515871.5271.2.camel@jdub.homelinux.org> So I haven't been following exactly what needs to be done to get a package into Extras lately. I've been busy and apologize for that. What would it take to get a distcc package into Extras? thx, josh From andreas.bierfert at lowlatency.de Wed Feb 16 08:47:33 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Wed, 16 Feb 2005 09:47:33 +0100 Subject: Request for Package: distcc In-Reply-To: <1108515871.5271.2.camel@jdub.homelinux.org> References: <1108515871.5271.2.camel@jdub.homelinux.org> Message-ID: <421308A5.3020905@lowlatency.de> Josh Boyer wrote: > What would it take to get a distcc package into Extras? If you want to maintain it, post a spec or src.rpm and a brief description and get somebody with cvs access to sponsor you. I'd be willing to do some work on distcc. Did so a while back: http://fedora.lowlatency.de/3/i386/SRPMS.testing/distcc-2.18.2-0.fdr.1.src.rpm 2.18.3 is current version tough... Andreas - Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | () ASCII ribbon campaign | mail preferred cell: +49 172 9789968 | /\ against HTML mail | From pmmm at rnl.ist.utl.pt Wed Feb 16 10:05:33 2005 From: pmmm at rnl.ist.utl.pt (Pedro Morais) Date: Wed, 16 Feb 2005 10:05:33 +0000 Subject: Request for package inclusion: gettext lint tools Message-ID: <200502161005.33483.pmmm@rnl.ist.utl.pt> Hi! I'm the author of this set of tools for translators and would be willing to maintain the package in Fedora Extras. It's already bean included in the FreeBSD ports system and Mandrake's cooker contrib. The gettext lint tools is a collection of tools for checking the validity, consistency and spelling of PO and POT files. It also includes an experimental glossary building tool. It's distributed under the GPL. Homepage: http://gettext-lint.sourceforge.net/ Source rpm and source tarball: http://sourceforge.net/project/showfiles.php?group_id=122521 The RPMs in that page were build using FC2, also tested in in RHL9. Thanks for your comments, Pedro Morais From dwmw2 at infradead.org Wed Feb 16 10:09:57 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 16 Feb 2005 10:09:57 +0000 Subject: Request for Package: distcc In-Reply-To: <421308A5.3020905@lowlatency.de> References: <1108515871.5271.2.camel@jdub.homelinux.org> <421308A5.3020905@lowlatency.de> Message-ID: <1108548597.22597.70.camel@baythorne.infradead.org> On Wed, 2005-02-16 at 09:47 +0100, Andreas Bierfert wrote: > Josh Boyer wrote: > > What would it take to get a distcc package into Extras? > > If you want to maintain it, post a spec or src.rpm and a brief description and > get somebody with cvs access to sponsor you. I'll sponsor Josh. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 392 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Wed Feb 16 11:54:17 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 16 Feb 2005 05:54:17 -0600 Subject: Request for Package: distcc In-Reply-To: <421308A5.3020905@lowlatency.de> References: <1108515871.5271.2.camel@jdub.homelinux.org> <421308A5.3020905@lowlatency.de> Message-ID: <1108554857.5271.7.camel@jdub.homelinux.org> On Wed, 2005-02-16 at 09:47 +0100, Andreas Bierfert wrote: > > Josh Boyer wrote: > > What would it take to get a distcc package into Extras? > > If you want to maintain it, post a spec or src.rpm and a brief description and > get somebody with cvs access to sponsor you. Ok, I'll see what I can do. > > I'd be willing to do some work on distcc. Did so a while back: > http://fedora.lowlatency.de/3/i386/SRPMS.testing/distcc-2.18.2-0.fdr.1.src.rpm > > 2.18.3 is current version tough... I know http://dag.wieers.com/packages/distcc has the most recent RPM. I could use that as a starting point and fix up anything that needs fixing... I think I'll email the current packager of that to see if he's interested first. Don't want to step on anyone toes. josh From jwboyer at jdub.homelinux.org Wed Feb 16 11:54:56 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 16 Feb 2005 05:54:56 -0600 Subject: Request for Package: distcc In-Reply-To: <1108548597.22597.70.camel@baythorne.infradead.org> References: <1108515871.5271.2.camel@jdub.homelinux.org> <421308A5.3020905@lowlatency.de> <1108548597.22597.70.camel@baythorne.infradead.org> Message-ID: <1108554896.5271.9.camel@jdub.homelinux.org> On Wed, 2005-02-16 at 10:09 +0000, David Woodhouse wrote: > On Wed, 2005-02-16 at 09:47 +0100, Andreas Bierfert wrote: > > Josh Boyer wrote: > > > What would it take to get a distcc package into Extras? > > > > If you want to maintain it, post a spec or src.rpm and a brief description and > > get somebody with cvs access to sponsor you. > > I'll sponsor Josh. Thanks. Much appreciated. josh From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 16 19:11:02 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 16 Feb 2005 20:11:02 +0100 Subject: New package for review : lighttpd Message-ID: <20050216201102.358d7678@python2> Hi, I've wrapped up a package for lighttpd. It looks like a really neat little http server, about as light as thttpd, but with features much closer to apache's! I've only done some basic testing, no benchmarking yet, but I really can't wait to do some ;-) Here you can find my current testing package : http://ftp.us.freshrpms.net/pub/freshrpms/fedora/linux/testing/3/ (please ignore the release tag, my build system ads it automatically) The only current issue I clearly see is that the mod_vhost_mysql I split off on purpose doesn't seem to link to libmysqlclient properly... I haven't looked into it, so any clues are very welcome. I haven't tried enabling LDAP support yet, so I don't know what exactly changes when doing so (no module seems to be skipped when it's disabled). Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 0.11 0.45 0.69 From stfn at gmx.net Wed Feb 16 19:45:01 2005 From: stfn at gmx.net (Stefan Hoelldampf) Date: Wed, 16 Feb 2005 20:45:01 +0100 Subject: New package for review : lighttpd In-Reply-To: <20050216201102.358d7678@python2> References: <20050216201102.358d7678@python2> Message-ID: <4213A2BD.8050605@gmx.net> Matthias Saou wrote: > I've wrapped up a package for lighttpd. It looks like a really neat little > http server, about as light as thttpd, but with features much closer to > apache's! I've only done some basic testing, no benchmarking yet, but I > really can't wait to do some ;-) > > Here you can find my current testing package : > http://ftp.us.freshrpms.net/pub/freshrpms/fedora/linux/testing/3/ > (please ignore the release tag, my build system ads it automatically) The changelog entry refers to 1.3.1-1 instead of 1.3.10-1. Regards, Stefan From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 16 20:19:19 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 16 Feb 2005 21:19:19 +0100 Subject: New package for review : lighttpd In-Reply-To: <4213A2BD.8050605@gmx.net> References: <20050216201102.358d7678@python2> <4213A2BD.8050605@gmx.net> Message-ID: <20050216211919.585ae0dc@python2> Stefan Hoelldampf wrote : > Matthias Saou wrote: > > > I've wrapped up a package for lighttpd. It looks like a really neat little > > http server, about as light as thttpd, but with features much closer to > > apache's! I've only done some basic testing, no benchmarking yet, but I > > really can't wait to do some ;-) > > > > Here you can find my current testing package : > > http://ftp.us.freshrpms.net/pub/freshrpms/fedora/linux/testing/3/ > > (please ignore the release tag, my build system ads it automatically) > > The changelog entry refers to 1.3.1-1 instead of 1.3.10-1. EasyFix -> Fixed ;-) I've also changed the home of the lighttpd user from /var/log/lighttpd to /var/www/lighttpd as it makes more sense. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 0.18 0.05 0.02 From smooge at gmail.com Wed Feb 16 20:27:47 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 16 Feb 2005 13:27:47 -0700 Subject: Upstream SPEC files Message-ID: <80d7e409050216122722f98158@mail.gmail.com> Looking through the mimedefang source code I see it comes with its own spec file. While it does not look like the fedora extra ones.. I was wondering if I should use it or use my own in packaging it for Extras. The advantage is that bugs in it can be pushed upstream. The problem is that it may not meet various fedora packaging criteria at some point (It has a long comment area at the top of the spec file.) Advice? -- Stephen J Smoogen. CSIRT/Linux System Administrator From perbj at stanford.edu Wed Feb 16 20:28:22 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Wed, 16 Feb 2005 12:28:22 -0800 Subject: New package for review : lighttpd In-Reply-To: <20050216211919.585ae0dc@python2> References: <20050216201102.358d7678@python2> <4213A2BD.8050605@gmx.net> <20050216211919.585ae0dc@python2> Message-ID: <1108585702.5315.57.camel@localhost.localdomain> On Wed, 2005-02-16 at 21:19 +0100, Matthias Saou wrote: > I've also changed the home of the lighttpd user from /var/log/lighttpd to > /var/www/lighttpd as it makes more sense. Hmm, so what about the /srv tree? Now, I realize that defaulting Apache to using something under /srv could easily break lots of installations, but you're defaulting lighttpd to something new anyways so perhaps putting it under /srv/www/lighttpd or somesuch... Relevant part of FHS 2.3: "The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs. On large systems it can be useful to structure /srv by administrative context, such as /srv/physics/www, /srv/compsci/cvs, etc. This setup will differ from host to host. Therefore, no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv. However /srv should always exist on FHS compliant systems and should be used as the default location for such data." http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM Somehow /srv just makes more sense to me than /var for this, now that it exists. (The /srv directory is provided by "filesystem" in FC3. Of course, this is just a nitpick/suggestion, feel free to disagree, but taking the opportunity to move toward closer FHS compliance in a non- breaking way sounds like a reasonable deal to me. Best regards, Per Bjornsson -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From fedora at wir-sind-cool.org Wed Feb 16 20:50:03 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 16 Feb 2005 21:50:03 +0100 Subject: Upstream SPEC files In-Reply-To: <80d7e409050216122722f98158@mail.gmail.com> References: <80d7e409050216122722f98158@mail.gmail.com> Message-ID: <20050216215003.7c8dcc0a.fedora@wir-sind-cool.org> On Wed, 16 Feb 2005 13:27:47 -0700, Stephen J. Smoogen wrote: > Looking through the mimedefang source code I see it comes with its own > spec file. While it does not look like the fedora extra ones.. I was > wondering if I should use it or use my own in packaging it for Extras. > The advantage is that bugs in it can be pushed upstream. The problem > is that it may not meet various fedora packaging criteria at some > point (It has a long comment area at the top of the spec file.) > > Advice? After a brief look, the included spec file would benefit from major cleanup and corrections. E.g. the %post script is just plain ugly. Lots of chown/chgrp/chmod calls and instructions printed to stdout. All that can go in favour of using %attr. The CVS log at the top in addition to the regular %changelog adds another place where to search for log entries. It requires you to scroll down before you can see the interesting bits of a spec file. ./configure and its first three arguments could be replaced with %configure. The %clean section is also over the top. A single "rm -rf $RPM_BUILD_ROOT" is enough. Everything else is removed automatically for normal rebuilds. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 16 21:39:01 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 16 Feb 2005 22:39:01 +0100 Subject: New package for review : lighttpd In-Reply-To: <1108585702.5315.57.camel@localhost.localdomain> References: <20050216201102.358d7678@python2> <4213A2BD.8050605@gmx.net> <20050216211919.585ae0dc@python2> <1108585702.5315.57.camel@localhost.localdomain> Message-ID: <20050216223901.41ea2d4a@python2> Per Bjornsson wrote : > On Wed, 2005-02-16 at 21:19 +0100, Matthias Saou wrote: > > > I've also changed the home of the lighttpd user from /var/log/lighttpd to > > /var/www/lighttpd as it makes more sense. > > Hmm, so what about the /srv tree? Now, I realize that defaulting Apache > to using something under /srv could easily break lots of installations, > but you're defaulting lighttpd to something new anyways so perhaps > putting it under /srv/www/lighttpd or somesuch... > > Relevant part of FHS 2.3: > "The methodology used to name subdirectories of /srv is unspecified as > there is currently no consensus on how this should be done. One method > for structuring data under /srv is by protocol, eg. ftp, rsync, www, and > cvs. On large systems it can be useful to structure /srv by > administrative context, such as /srv/physics/www, /srv/compsci/cvs, etc. > This setup will differ from host to host. Therefore, no program should > rely on a specific subdirectory structure of /srv existing or data > necessarily being stored in /srv. However /srv should always exist on > FHS compliant systems and should be used as the default location for > such data." > http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM > > Somehow /srv just makes more sense to me than /var for this, now that it > exists. (The /srv directory is provided by "filesystem" in FC3. Of > course, this is just a nitpick/suggestion, feel free to disagree, but > taking the opportunity to move toward closer FHS compliance in a non- > breaking way sounds like a reasonable deal to me. I actually agree completely and totally with the above! :-) Especially since we're talking about an initial package, and not possibly breaking upgrades and sysadmin habits ;-) So... I'll go with /srv/www/lighttpd, then? Or is there already some kind of consensus for RH/FC about how to structure directories under /srv? Maybe /srv/lighttpd directly? I think I prefer with at least an indication of the protocol, myself. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 0.76 0.98 0.62 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 16 22:20:38 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 16 Feb 2005 23:20:38 +0100 Subject: New package for review : lighttpd In-Reply-To: <20050216201102.358d7678@python2> References: <20050216201102.358d7678@python2> Message-ID: <20050216232038.025dcfa1@python2> Hi again, I've put up a new package : - Fixed the libmysqlclient linking problem : When --with-mysql isn't specified but mysql_config is detected, the mysql support is enabled, but the mysql includes and cflags left empty. This is an upstream bug that I've worked around by simply explicitly enabling mysql. - Moved the default web files and home of the user to /srv/www/lighttpd. - Excluded the .la files. Spec, i386 & src rpms and build log here : http://ftp.us.freshrpms.net/pub/freshrpms/fedora/linux/testing/3/ Further suggestions are still welcome of course :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 0.29 0.28 0.36 From moe at blagblagblag.org Thu Feb 17 03:31:33 2005 From: moe at blagblagblag.org (jeff) Date: Wed, 16 Feb 2005 20:31:33 -0700 Subject: absolute path in bluefish icon Message-ID: <200502162031.33876.moe@blagblagblag.org> The fedora-extras version of bluefish has an absolute path to it's icon in the menu. Because of this, bluefish does not theme correctly. It reads: $ grep Icon /usr/share/applications/fedora-bluefish.desktop Icon=/usr/share/pixmaps/bluefish-icon.png When it should just read: Icon=bluefish-icon.png (or just bluefish.png...) Version : 1.0 Release : 1 Build Host: extras.linux.duke.edu Source RPM: bluefish-1.0-1.src.rpm Thanks, -Jeff From msmart890 at access-4-free.com Thu Feb 17 03:51:26 2005 From: msmart890 at access-4-free.com (Michael Smart) Date: Wed, 16 Feb 2005 21:51:26 -0600 Subject: unsubscription request In-Reply-To: <20050210165716.59105.qmail@web25806.mail.ukl.yahoo.com> References: <20050210165716.59105.qmail@web25806.mail.ukl.yahoo.com> Message-ID: <421414BE.5080109@access-4-free.com> joyabrata ghosh wrote: >hi , plz unsubscribe me from mailing list. > >===== >JOYABRATA > > > > > >___________________________________________________________ >ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com > >-- >fedora-extras-list mailing list >fedora-extras-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-extras-list > > > hi , plz unsubscribe me from mailing list. From pcompton at proteinmedia.com Thu Feb 17 03:58:12 2005 From: pcompton at proteinmedia.com (Phillip Compton) Date: Wed, 16 Feb 2005 22:58:12 -0500 Subject: absolute path in bluefish icon In-Reply-To: <200502162031.33876.moe@blagblagblag.org> References: <200502162031.33876.moe@blagblagblag.org> Message-ID: <1108612693.5330.1.camel@earlgrey.compton.net> On Wed, 2005-02-16 at 20:31 -0700, jeff wrote: > The fedora-extras version of bluefish has an absolute path to > it's icon in the menu. Because of this, bluefish does not theme > correctly. > > It reads: > $ grep Icon /usr/share/applications/fedora-bluefish.desktop > Icon=/usr/share/pixmaps/bluefish-icon.png > > When it should just read: > Icon=bluefish-icon.png (or just bluefish.png...) > > Version : 1.0 > Release : 1 > Build Host: extras.linux.duke.edu > Source RPM: bluefish-1.0-1.src.rpm I probably won't have time until this weekend, but I'll be sure to fix that. Phil From smooge at gmail.com Thu Feb 17 04:28:09 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 16 Feb 2005 21:28:09 -0700 Subject: Upstream SPEC files In-Reply-To: <20050216215003.7c8dcc0a.fedora@wir-sind-cool.org> References: <80d7e409050216122722f98158@mail.gmail.com> <20050216215003.7c8dcc0a.fedora@wir-sind-cool.org> Message-ID: <80d7e40905021620282942eba4@mail.gmail.com> On Wed, 16 Feb 2005 21:50:03 +0100, Michael Schwendt wrote: > On Wed, 16 Feb 2005 13:27:47 -0700, Stephen J. Smoogen wrote: > > > Looking through the mimedefang source code I see it comes with its own > > spec file. While it does not look like the fedora extra ones.. I was > > wondering if I should use it or use my own in packaging it for Extras. > > The advantage is that bugs in it can be pushed upstream. The problem > > is that it may not meet various fedora packaging criteria at some > > point (It has a long comment area at the top of the spec file.) > > > > Advice? > > After a brief look, the included spec file would benefit from major > cleanup and corrections. > Thanks.. I did have an alternate mimedefang that did several of your recommendations. I will see if David Skoll will take it with the rest of the items below in it. > E.g. the %post script is just plain ugly. Lots of chown/chgrp/chmod calls > and instructions printed to stdout. All that can go in favour of using > %attr. > > The CVS log at the top in addition to the regular %changelog adds another > place where to search for log entries. It requires you to scroll down > before you can see the interesting bits of a spec file. > > ./configure and its first three arguments could be replaced with %configure. > > The %clean section is also over the top. A single "rm -rf $RPM_BUILD_ROOT" > is enough. Everything else is removed automatically for normal rebuilds. > > -- > 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 tcallawa at redhat.com Thu Feb 17 05:05:37 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 16 Feb 2005 23:05:37 -0600 Subject: Duplicating packages from Freshrpms Message-ID: <1108616737.4467.13.camel@localhost.localdomain> Since I suspect the answer to this question is interesting to others besides me... Matthias, what is your opinion on moving packages from freshrpms into fedora-extras? I noticed that imlib2 is in both repositories, but libcaca (the package I was about to create tonight) is not. Thanks in advance, ~spot --- Tom "spot" Callaway LCA, RHCE Red Hat Sales Engineer || Aurora Linux Project Leader "If you are going through hell, keep going." -- Sir Winston Churchill From fedora at wir-sind-cool.org Thu Feb 17 05:35:36 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 17 Feb 2005 06:35:36 +0100 Subject: Duplicating packages from Freshrpms In-Reply-To: <1108616737.4467.13.camel@localhost.localdomain> References: <1108616737.4467.13.camel@localhost.localdomain> Message-ID: <20050217063536.254ea3bb.fedora@wir-sind-cool.org> On Wed, 16 Feb 2005 23:05:37 -0600, Tom 'spot' Callaway wrote: > Since I suspect the answer to this question is interesting to others > besides me... > > Matthias, what is your opinion on moving packages from freshrpms into > fedora-extras? I noticed that imlib2 is in both repositories, but > libcaca (the package I was about to create tonight) is not. This is in CVS: Summary: Library for Colour AsCii Art, text mode graphics Name: libcaca Version: 0.9 Release: 5 From tcallawa at redhat.com Thu Feb 17 05:39:06 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 16 Feb 2005 23:39:06 -0600 Subject: Duplicating packages from Freshrpms In-Reply-To: <20050217063536.254ea3bb.fedora@wir-sind-cool.org> References: <1108616737.4467.13.camel@localhost.localdomain> <20050217063536.254ea3bb.fedora@wir-sind-cool.org> Message-ID: <1108618746.4467.15.camel@localhost.localdomain> On Thu, 2005-02-17 at 06:35 +0100, Michael Schwendt wrote: >On Wed, 16 Feb 2005 23:05:37 -0600, Tom 'spot' Callaway wrote: > >> Since I suspect the answer to this question is interesting to others >> besides me... >> >> Matthias, what is your opinion on moving packages from freshrpms into >> fedora-extras? I noticed that imlib2 is in both repositories, but >> libcaca (the package I was about to create tonight) is not. > >This is in CVS: Whoops. Sorry. :) ~spot --- Tom "spot" Callaway LCA, RHCE Red Hat Sales Engineer || Aurora Linux Project Leader "If you are going through hell, keep going." -- Sir Winston Churchill From adrian at lisas.de Thu Feb 17 06:37:38 2005 From: adrian at lisas.de (Adrian Reber) Date: Thu, 17 Feb 2005 07:37:38 +0100 Subject: grip being removed from development tree Message-ID: <20050217063738.GA1873@lisas.de> As grip has been removed from the development tree I would like to import it to CVS so that it is ready in Extras when FC4 comes out. I would import the SRPM from FC3. Any objections? Adrian From wtogami at redhat.com Thu Feb 17 06:41:10 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 17 Feb 2005 01:41:10 -0500 Subject: grip being removed from development tree In-Reply-To: <20050217063738.GA1873@lisas.de> References: <20050217063738.GA1873@lisas.de> Message-ID: <42143C86.4010305@redhat.com> Adrian Reber wrote: > As grip has been removed from the development tree I would like to > import it to CVS so that it is ready in Extras when FC4 comes out. > I would import the SRPM from FC3. Any objections? > Wait until the Extras CVS is branched please. This will happen soon. Warren Togami wtogami at redhat.com From petersen at redhat.com Thu Feb 17 08:59:05 2005 From: petersen at redhat.com (Jens Petersen) Date: Thu, 17 Feb 2005 17:59:05 +0900 Subject: ghc package bootstrapping In-Reply-To: <1108312826.7436.67.camel@localhost.localdomain> References: <420F73EE.5090903@redhat.com> <1108312826.7436.67.camel@localhost.localdomain> Message-ID: <42145CD9.6090207@redhat.com> David Woodhouse wrote: > There are Debian binary packages for x86_64 and PPC too. Please include > both of those. When will a ppc port be added to Fedora Core/Extras? :) > The way that Modula-3 handles bootstrapping on a new platform is to > include the bootstrap compiler in assembly form and then compile it, > instead of distributing binaries. > > That approach makes me feel slightly happier because it at least 'feels' > like source code, but I suppose there's no real reason for that. > Distributing as assembly can give problems with symbol versioning -- see > the hoops I had to jump through to get the bootstrap compiler to use > _setjmp at GLIBC_2.0 in ezm3 to get cvsup building on PPC, for example. For ghc it is possible to bootstrap with ghc-generated bootstrap C files. But then it really just comes down to whether one trusts the ghc compiler used to generate them over the binary from upstream/debian. Also generating the bootstrap files is non trivial in practise - I managed it for x86_64, but have had problems getting it working for i386... So while I sympathise I think just using binary tarballs like debian to bootstrap ghc for Extras will be easier and good enough. Once we have that in place, we should rebuild ghc completely from source anyway. Jens From dwmw2 at infradead.org Thu Feb 17 09:24:36 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 17 Feb 2005 09:24:36 +0000 Subject: ghc package bootstrapping In-Reply-To: <42145CD9.6090207@redhat.com> References: <420F73EE.5090903@redhat.com> <1108312826.7436.67.camel@localhost.localdomain> <42145CD9.6090207@redhat.com> Message-ID: <1108632276.31449.18.camel@localhost.localdomain> On Thu, 2005-02-17 at 17:59 +0900, Jens Petersen wrote: >David Woodhouse wrote: >> There are Debian binary packages for x86_64 and PPC too. Please include >> both of those. > >When will a ppc port be added to Fedora Core/Extras? :) I've been running Fedora Core on PPC since FC2. The stated plan is to include PPC support in FC4 if it looks good enough to ship. I recently updated my PowerBook from FC3 to rawhide and it certainly does look good enough to ship -- we just have a couple of mac-related installer bugs to fix, but once installed it works as well as the other platforms. So hopefully the answer to your first question, officially, is 'FC4'. As for Extras, AFAICT the builds for PPC are more organised than the i386/x86_64 builds. See http://peach.infradead.org/extras/ We even have Modula-3 support and hence cvsup, which x86_64 still lacks :) >So while I sympathise I think just using binary tarballs like debian >to bootstrap ghc for Extras will be easier and good enough. Once we >have that in place, we should rebuild ghc completely from source anyway. Yeah, you're probably right. We can make the RPM both require and provide something like 'ghc-compiler', and make a bootstrap package based on the debian binaries which also provides that. -- dwmw2 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 17 09:58:25 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 17 Feb 2005 10:58:25 +0100 Subject: Duplicating packages from Freshrpms In-Reply-To: <1108618746.4467.15.camel@localhost.localdomain> References: <1108616737.4467.13.camel@localhost.localdomain> <20050217063536.254ea3bb.fedora@wir-sind-cool.org> <1108618746.4467.15.camel@localhost.localdomain> Message-ID: <20050217105825.25cae002@python2> Tom 'spot' Callaway wrote : > On Thu, 2005-02-17 at 06:35 +0100, Michael Schwendt wrote: > >On Wed, 16 Feb 2005 23:05:37 -0600, Tom 'spot' Callaway wrote: > > > >> Since I suspect the answer to this question is interesting to others > >> besides me... > >> > >> Matthias, what is your opinion on moving packages from freshrpms into > >> fedora-extras? I noticed that imlib2 is in both repositories, but > >> libcaca (the package I was about to create tonight) is not. > > > >This is in CVS: > > Whoops. Sorry. :) I guess you got confused by the fact that there is no binary "libcaca" package, since the source one produces one -devel one (with only headers and static libs) and one caca-utils one ;-) When everything got merged to start Extras, all fedora.us packages got precedence, but I then had the few remaining ones that were over at freshrpms.net, and not yet in Extras, imported. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 1.93 1.31 0.73 From byte at aeon.com.my Thu Feb 17 19:39:59 2005 From: byte at aeon.com.my (Colin Charles) Date: Fri, 18 Feb 2005 03:39:59 +0800 Subject: Package proposal: apmud In-Reply-To: <1108323699.7436.92.camel@localhost.localdomain> References: <1108323699.7436.92.camel@localhost.localdomain> Message-ID: <1108669200.5753.29.camel@localhost.localdomain> On Sun, 2005-02-13 at 19:41 +0000, David Woodhouse wrote: > http://david.woodhou.se/apmud-1.0.0-1.src.rpm > > Name : apmud Relocations: (not > relocatable) > Version : 1.0.0 Vendor: (none) Aye. Ack'ed on IRC, now for the list I guess. -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From wtogami at redhat.com Fri Feb 18 03:59:30 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 17 Feb 2005 22:59:30 -0500 Subject: DKMS into Fedora Extras Message-ID: <42156822.2080600@redhat.com> Opinions here? Is this something that we want in Extras? (Is this sane and unlikely to cause trouble?) Warren -------- Original Message -------- Subject: RE: DKMS into Fedora Extras Date: Thu, 17 Feb 2005 19:46:18 -0600 From: To: , CC: Bug 2435. http://bugzilla.fedora.us/show_bug.cgi?id=2435 What needs to be done from here? Thanks, Gary >Matt Domsch wrote: > >As RH is dragging their feet on DKMS, let's get it put into Extras. >Would you care to do so, or shall I? (I'm hoping you'll say >you've got the time to do it). >http://www.fedoraproject.org/wiki/Extras > >I spoke with about half the folks on the Contributors list >tonight, and they're good with it. They'd sponsor me as a >contributor, or by transitive property, you. :-) Jeremy Katz >and Tom "Spot" Callaway in particular. > >Thanks, >Matt From wtogami at redhat.com Fri Feb 18 04:16:00 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 17 Feb 2005 23:16:00 -0500 Subject: Review of pl package, big problems... In-Reply-To: <420E5E64.7010600@redhat.com> References: <420D57E9.6070403@redhat.com> <1108174772.23435.2.camel@scriabin.tannenrauch.ch> <420D6CAD.3040501@redhat.com> <20050212035654.39290e59.fedora@wir-sind-cool.org> <420E5E64.7010600@redhat.com> Message-ID: <42156C00.8060206@redhat.com> Warren Togami wrote: > Build of pl on x86_64 seems to work, except it installs everything into > /usr/lib. It is likely that the Makefile needs patching for "make > install" to work properly. https://bugzilla.redhat.com/beta/show_bug.cgi?id=149038 Filed this here. Fix this or declare x86-64 unfixable (if the resulting binary really is) if you want pl to be pushed. Warren Togami wtogami at redhat.com From tcallawa at redhat.com Fri Feb 18 05:17:36 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 17 Feb 2005 23:17:36 -0600 Subject: DKMS into Fedora Extras In-Reply-To: <42156822.2080600@redhat.com> References: <42156822.2080600@redhat.com> Message-ID: <1108703856.4293.50.camel@localhost.localdomain> On Thu, 2005-02-17 at 22:59 -0500, Warren Togami wrote: >Opinions here? Is this something that we want in Extras? (Is this sane >and unlikely to cause trouble?) I'm not opposed to its inclusion, although, I think it may be overkill for kernel modules packaged in Extras. This is assuming that Dell will give a GPL-compatible patent grant for the patents pending (received?) on DKMS. They may have already done this. ~spot --- Tom "spot" Callaway LCA, RHCE Red Hat Sales Engineer || Aurora Linux Project Leader "If you are going through hell, keep going." -- Sir Winston Churchill From rdieter at math.unl.edu Fri Feb 18 17:24:35 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 18 Feb 2005 11:24:35 -0600 Subject: geomview(x86_64) crasher, pull from repo? Message-ID: <421624D3.5020703@math.unl.edu> Could someone with a x86_64 box confirm geomview crash: http://bugzilla.redhat.com/bugzilla/146584 I haven't got any x86_64 box to test it with. If so, it probably out to be pulled from the (x86_64) repo until it is fixed. -- Rex From rdieter at math.unl.edu Fri Feb 18 17:33:12 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 18 Feb 2005 11:33:12 -0600 Subject: x86_64 pkg update/rebuild request: gsview Message-ID: <421626D8.7070809@math.unl.edu> fixes borkiness on x86_64 http://bugzilla.redhat.com/bugzilla/146223#c7 -- Rex From steve at silug.org Fri Feb 18 19:21:15 2005 From: steve at silug.org (Steven Pritchard) Date: Fri, 18 Feb 2005 13:21:15 -0600 Subject: OpenVPN Message-ID: <20050218192115.GA14511@osiris.silug.org> Is anyone interested enough in OpenVPN to help me get it into Extras? https://bugzilla.fedora.us/show_bug.cgi?id=1531 It's a great piece of software. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From cra at WPI.EDU Fri Feb 18 19:36:38 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Fri, 18 Feb 2005 14:36:38 -0500 Subject: OpenVPN In-Reply-To: <20050218192115.GA14511@osiris.silug.org> References: <20050218192115.GA14511@osiris.silug.org> Message-ID: <20050218193638.GA7032@angus.ind.WPI.EDU> On Fri, Feb 18, 2005 at 01:21:15PM -0600, Steven Pritchard wrote: > Is anyone interested enough in OpenVPN to help me get it into Extras? > > https://bugzilla.fedora.us/show_bug.cgi?id=1531 > > It's a great piece of software. Yes, I'll be looking at this software soon, and I will most likely work to get it into Extras. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 18 19:52:26 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 18 Feb 2005 20:52:26 +0100 Subject: OpenVPN In-Reply-To: <20050218193638.GA7032@angus.ind.WPI.EDU> References: <20050218192115.GA14511@osiris.silug.org> <20050218193638.GA7032@angus.ind.WPI.EDU> Message-ID: <20050218205226.07027adf@python2> Chuck R. Anderson wrote : > On Fri, Feb 18, 2005 at 01:21:15PM -0600, Steven Pritchard wrote: > > Is anyone interested enough in OpenVPN to help me get it into Extras? > > > > https://bugzilla.fedora.us/show_bug.cgi?id=1531 > > > > It's a great piece of software. > > Yes, I'll be looking at this software soon, and I will most likely > work to get it into Extras. I've already done so myself, but am still wondering what the best way to get it into Extras is. Should I proxy the changes into CVS and ask for rebuilds while Steven could be the component owner in bugzilla, or should someone sponsor him to get CVS access so that he can manage everything on his own? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 0.08 0.76 1.00 From steve at silug.org Fri Feb 18 21:02:43 2005 From: steve at silug.org (Steven Pritchard) Date: Fri, 18 Feb 2005 15:02:43 -0600 Subject: OpenVPN In-Reply-To: <20050218205226.07027adf@python2> References: <20050218192115.GA14511@osiris.silug.org> <20050218193638.GA7032@angus.ind.WPI.EDU> <20050218205226.07027adf@python2> Message-ID: <20050218210243.GA14818@osiris.silug.org> On Fri, Feb 18, 2005 at 08:52:26PM +0100, Matthias Saou wrote: > Should I proxy the changes into CVS and ask for rebuilds while Steven > could be the component owner in bugzilla, or should someone sponsor > him to get CVS access so that he can manage everything on his own? I did already send the form in... :-) I'm perfectly fine with somebody else playing CVS proxy for me in the mean time though... Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From dwmw2 at infradead.org Sat Feb 19 15:54:33 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 19 Feb 2005 15:54:33 +0000 Subject: OpenVPN In-Reply-To: <20050218205226.07027adf@python2> References: <20050218192115.GA14511@osiris.silug.org> <20050218193638.GA7032@angus.ind.WPI.EDU> <20050218205226.07027adf@python2> Message-ID: <1108828473.15768.46.camel@localhost.localdomain> On Fri, 2005-02-18 at 20:52 +0100, Matthias Saou wrote: >> Yes, I'll be looking at this software soon, and I will most likely >> work to get it into Extras. > >I've already done so myself, but am still wondering what the best way to >get it into Extras is. Should I proxy the changes into CVS and ask for >rebuilds while Steven could be the component owner in bugzilla, or should >someone sponsor him to get CVS access so that he can manage everything on >his own? Probably best do to both -- import it yourself and act as a proxy until Steven's account is set up. Steven, please could you add init scripts for OpenVPN. There's some at http://projects.drzeus.cx/openvpn-initscripts/ which may make a useful starting point, although I think they may be a bit out of date now -- our initscripts handle bridges and have a separate ifup-eth which can be called from other ifup-* files now. -- dwmw2 From adrian at lisas.de Sat Feb 19 19:55:32 2005 From: adrian at lisas.de (Adrian Reber) Date: Sat, 19 Feb 2005 20:55:32 +0100 Subject: xmlindent imported Message-ID: <20050219195532.GA18177@lisas.de> I would like to announce the import of xmlindent. Reviewed by Ville Skytt?: https://bugzilla.fedora.us/show_bug.cgi?id=2078 Adrian From steve at silug.org Sat Feb 19 21:26:19 2005 From: steve at silug.org (Steven Pritchard) Date: Sat, 19 Feb 2005 15:26:19 -0600 Subject: OpenVPN In-Reply-To: <1108828473.15768.46.camel@localhost.localdomain> References: <20050218192115.GA14511@osiris.silug.org> <20050218193638.GA7032@angus.ind.WPI.EDU> <20050218205226.07027adf@python2> <1108828473.15768.46.camel@localhost.localdomain> Message-ID: <20050219212619.GA17987@osiris.silug.org> On Sat, Feb 19, 2005 at 03:54:33PM +0000, David Woodhouse wrote: > Steven, please could you add init scripts for OpenVPN. There's some at > http://projects.drzeus.cx/openvpn-initscripts/ which may make a useful > starting point, although I think they may be a bit out of date now -- > our initscripts handle bridges and have a separate ifup-eth which can be > called from other ifup-* files now. They appear to be for OpenVPN 1.x, so there will be some major surgery involved. Interesting idea though... I'll definitely work on it. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From stfn at gmx.net Sun Feb 20 11:55:06 2005 From: stfn at gmx.net (Stefan Hoelldampf) Date: Sun, 20 Feb 2005 12:55:06 +0100 Subject: Different versions: torcs-1.2.3-1 and torcs-data-1.2.2-1 Message-ID: <42187A9A.1060407@gmx.net> Hi, torcs is at version 1.2.3-1 but torcs-data still at 1.2.2-1. I don't know whether the following problem is related to the different versions. Starting "Quick Race" with default settings returns: > $ torcs > Visual Properties Report > ------------------------ > Compatibility mode, properties unknown. > Can't open file data/img/splash-simucfg.png > WARNING: grscene:initBackground Failed to open shadow2.rgb for reading > WARNING: no shadow mapping on cars for this track > WARNING: ssgLoadAC: Failed to open 'tracks/road/g-track-3/track.ac' for reading > /usr/bin/torcs: line 52: 16923 Segmentation fault $LIBDIR/torcs-bin -l $LOCAL_CONF -L $LIBDIR -D $DATADIR $* Regards, Stefan From fedora at leemhuis.info Sun Feb 20 13:05:30 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 20 Feb 2005 14:05:30 +0100 Subject: DKMS into Fedora Extras In-Reply-To: <42156822.2080600@redhat.com> References: <42156822.2080600@redhat.com> Message-ID: <1108904731.6115.32.camel@localhost.localdomain> Am Donnerstag, den 17.02.2005, 22:59 -0500 schrieb Warren Togami: > Opinions here? Is this something that we want in Extras? (Is this sane > and unlikely to cause trouble?) I'm against including it. At least from a short look into the presentation and in the rpm. My main concerns: It can autorecomile modules and puts them into the proper kernel-modules dir. This seems wrong very for me. Those files may overwrite existing modules (okay, in fact it copies them away and installs the new one). And the resulting modules are not in the rpmdb afaics. So if you remove the kernel later the directory /lib/modules/$(uname -r) can't be deleted by rpm. That a great problem IMHO cause the /lib/modules/ dir will soon get messy. Also I don't think fedora has a real benefit from DKMS. We could start using it for our kernel-module-rpms but I don't think adding another layer makes sense. IMHO we should create something similar to DKMS that is based on our existing src.rpms. That shouldn't be to hard AFGAICS. I think of a init script that tries to recompile kernel-module-*.src.rpms and/or autoinstall kenrel-module-*.rpms for a newly installed kernel automatically. I have something like that in my mind but did not started with it yet because I wanted to wait for the kernel-devel-* packages in FC4 / FC3 extras... -- Thorsten Leemhuis From skvidal at fedoraproject.org Sun Feb 20 21:19:14 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Sun, 20 Feb 2005 16:19:14 -0500 Subject: Extras Updates Message-ID: <1108934354.7032.16.camel@cutter> Hi, Sorry for the silence last week. I was at linuxworld and FUDCon and I was a bit busy. But packages are all built now. allegro (x86_64) amarok (i386, x86_64) apt (i386) awstats (noarch) - security update centericq (i386, x86_64) doctorj (i386, x86_64) dosbox (i386, x86_64) fbdesk (i386, x86_64) fbida (i386) gazpacho (i386, x86_64) glunarclock (i386, x86_64) gnofract4d (i386, x86_64) gnome-cpufreq-applet (i386, x86_64) gtk-qt-engine (i386, x86_64) hping2 (i386, x86_64) Inventor (i386, x86_64) jhead (i386, x86_64) js (i386, x86_64) kover (i386, x86_64) lablgl (x86_64) libvisual (i386, x86_64) most (i386, x86_64) perl-ExtUtils-CBuilder (i386, x86_64) perl-ExtUtils-Depends (i386, x86_64) perl-ExtUtils-PkgConfig (i386, x86_64) perl-Glib (i386, x86_64) perl-Gtk2 (i386, x86_64) perl-HTML-Tree (i386, x86_64) perl-IO-stringy (i386, x86_64) perl-String-Ediff (i386, x86_64) php-pecl-mailparse (i386, x86_64) php-pecl-sqlite (i386, x86_64) pth (i386, x86_64) python-sqlite (x86_64) rpmlint (i386, x86_64) sqlite (i386, x86_64) - straw (x86_64) sylpheed-claws (i386) tkcvs (i386, x86_64) ulogd (i386, x86_64) xmlindent (i386, x86_64) Removed: vice - legal concerns Just a world full of packages. Extras info: http://fedoraproject.org/wiki/Extras Status page: http://fedoraproject.org/wiki/Extras/FC3Status Follow updates and new packages at: http://fedoraproject.org/infofeed/ Report problems at Bugzilla: http://bugzilla.redhat.com/ thanks, -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Mon Feb 21 05:31:52 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 00:31:52 -0500 Subject: DKMS into Fedora Extras In-Reply-To: <1108904731.6115.32.camel@localhost.localdomain> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> Message-ID: <1108963912.7032.33.camel@cutter> On Sun, 2005-02-20 at 14:05 +0100, Thorsten Leemhuis wrote: >Am Donnerstag, den 17.02.2005, 22:59 -0500 schrieb Warren Togami: >> Opinions here? Is this something that we want in Extras? (Is this sane >> and unlikely to cause trouble?) > >I'm against including it. At least from a short look into the >presentation and in the rpm. My main concerns: > >It can autorecomile modules and puts them into the proper kernel-modules >dir. This seems wrong very for me. Those files may overwrite existing >modules (okay, in fact it copies them away and installs the new one). >And the resulting modules are not in the rpmdb afaics. So if you remove >the kernel later the directory /lib/modules/$(uname -r) can't be deleted >by rpm. That a great problem IMHO cause the /lib/modules/ dir will soon >get messy. What if it automatically built the module into an rpm then installed it? Would that be better? The major reason for wanting DKMS is to let it help us keep up with kernel modules in extras. -sv From kevinverma at gmail.com Mon Feb 21 05:22:42 2005 From: kevinverma at gmail.com (Kevin Verma) Date: Mon, 21 Feb 2005 09:22:42 +0400 Subject: Fedora Installation on USB Mass Storage devices Message-ID: <1108963362.7759.1.camel@localhost.localdomain> I'll like to know if this is possible to install Fedora on a USB mass storage device yet ? Cheers, -- Kevin Verma From skvidal at phy.duke.edu Mon Feb 21 05:56:21 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 00:56:21 -0500 Subject: Fedora Installation on USB Mass Storage devices In-Reply-To: <1108963362.7759.1.camel@localhost.localdomain> References: <1108963362.7759.1.camel@localhost.localdomain> Message-ID: <1108965381.7032.38.camel@cutter> On Mon, 2005-02-21 at 09:22 +0400, Kevin Verma wrote: >I'll like to know if this is possible to install Fedora on a USB mass >storage device yet ? 1. Don't crosspost 2. Don't crosspost off topic posts. fedora-list is the best place to ask this question. -sv From fedora at leemhuis.info Mon Feb 21 06:07:50 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 21 Feb 2005 07:07:50 +0100 Subject: DKMS into Fedora Extras In-Reply-To: <1108963912.7032.33.camel@cutter> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> Message-ID: <1108966070.5033.9.camel@thl.ct.heise.de> Am Montag, den 21.02.2005, 00:31 -0500 schrieb seth vidal: > On Sun, 2005-02-20 at 14:05 +0100, Thorsten Leemhuis wrote: > >Am Donnerstag, den 17.02.2005, 22:59 -0500 schrieb Warren Togami: > >> Opinions here? Is this something that we want in Extras? (Is this sane > >> and unlikely to cause trouble?) > > > >I'm against including it. At least from a short look into the > >presentation and in the rpm. My main concerns: > > > >It can autorecomile modules and puts them into the proper kernel-modules > >dir. This seems wrong very for me. Those files may overwrite existing > >modules (okay, in fact it copies them away and installs the new one). > >And the resulting modules are not in the rpmdb afaics. So if you remove > >the kernel later the directory /lib/modules/$(uname -r) can't be deleted > >by rpm. That a great problem IMHO cause the /lib/modules/ dir will soon > >get messy. > > What if it automatically built the module into an rpm then installed it? > Would that be better? The major reason for wanting DKMS is to let it > help us keep up with kernel modules in extras. Well, even then I think DKMS buys us noting and is not worth the trouble. We want to provide kernel-modules anyway and so we have to prepare SRPMS. Why not use them to rebuild the kernel-module directly? A (small?) init-script could do this. This could also try first to download the module from the web if it available -- this way you also don't need to have special kernel-module-* magic in yum. I'll sit down the next days and code something up to show you. AFAICS it should not be to hard (but maybe I'm wrong)... CU thl From rdieter at math.unl.edu Mon Feb 21 15:26:01 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 21 Feb 2005 09:26:01 -0600 Subject: Macaulay2 x86_64 patch/rebuild request Message-ID: I've submitted a specfile patch: http://bugzilla.redhat.com/149225 to address the x86_64 failed build log: http://www.leemhuis.info/files/fedorarpms/misc/Macaulay2.x86_64.log Could someone apply the patch and try rebuilding? -- Rex From dwmw2 at infradead.org Mon Feb 21 16:27:33 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 21 Feb 2005 16:27:33 +0000 Subject: Package proposal: hfsplusutils Message-ID: <1109003253.19262.719.camel@hades.cambridge.redhat.com> http://david.woodhou.se/hfsplusutils-1.0.4-2.src.rpm Name : hfsplusutils Relocations: (not relocatable) Version : 1.0.4 Vendor: (none) Release : 2 Build Date: Mon 21 Feb 2005 16:22:31 GMT Install Date: (not installed) Build Host: fish.cambridge.redhat.com Group : Applications/File Source RPM: (none) Size : 187877 License: GPL Signature : (none) URL : ftp://ftp.penguinppc.org/users/hasi/hfsplus_1.0.4.src.tar.bz2 Summary : Tools for reading Macintosh HFS+ volumes. Description : This package is a set of tools that allow access to HFS+ formatted volumes. HFS+ is a modernized version of Apple Computers HFS Filesystem. -- dwmw2 From tcallawa at redhat.com Mon Feb 21 16:29:29 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 21 Feb 2005 10:29:29 -0600 Subject: DKMS into Fedora Extras In-Reply-To: <1108966070.5033.9.camel@thl.ct.heise.de> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> Message-ID: <1109003370.10854.41.camel@localhost.localdomain> On Mon, 2005-02-21 at 07:07 +0100, Thorsten Leemhuis wrote: >A (small?) init-script could do this. This could also try first to >download the module from the web if it available -- this way you also >don't need to have special kernel-module-* magic in yum. > >I'll sit down the next days and code something up to show you. AFAICS it >should not be to hard (but maybe I'm wrong)... This is one of the problems that we need to solve, so I'm very interested in seeing your approach. However, I think it is important that whatever solution we adopt "just works" with yum, and without requiring the user to have a development toolchain installed. ~spot --- Tom "spot" Callaway LCA, RHCE Red Hat Sales Engineer || Aurora Linux Project Leader "If you are going through hell, keep going." -- Sir Winston Churchill From tjb at unh.edu Mon Feb 21 16:43:17 2005 From: tjb at unh.edu (Thomas J. Baker) Date: Mon, 21 Feb 2005 11:43:17 -0500 Subject: Mirrors Message-ID: <1109004197.27708.6.camel@wintermute.sr.unh.edu> Any update on the extras mirror list. Thanks, tjb --- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From fedora at leemhuis.info Mon Feb 21 17:09:19 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 21 Feb 2005 18:09:19 +0100 Subject: DKMS into Fedora Extras In-Reply-To: <1109003370.10854.41.camel@localhost.localdomain> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> Message-ID: <1109005759.6007.7.camel@localhost.localdomain> Am Montag, den 21.02.2005, 10:29 -0600 schrieb Tom 'spot' Callaway: > On Mon, 2005-02-21 at 07:07 +0100, Thorsten Leemhuis wrote: > > >A (small?) init-script could do this. This could also try first to > >download the module from the web if it available -- this way you also > >don't need to have special kernel-module-* magic in yum. > > > >I'll sit down the next days and code something up to show you. AFAICS it > >should not be to hard (but maybe I'm wrong)... > > This is one of the problems that we need to solve, so I'm very > interested in seeing your approach. > > However, I think it is important that whatever solution we adopt "just > works" with yum, That should be possible. > and without requiring the user to have a development > toolchain installed. ? I don't understand you here. What do you mean by toolchain -- GCC, make, kernel-devel are needed of course -- but they are also needed by DKMS afaics. But the solution I dream of is a two way solution -- make the kernel- module build automatically if everything needed to do it is installed. If not use the old kernel until all kernel-modules are ready and/or download them with yum (what about apt?) automatically if available. -- Thorsten Leemhuis From tcallawa at redhat.com Mon Feb 21 17:13:19 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 21 Feb 2005 11:13:19 -0600 Subject: DKMS into Fedora Extras In-Reply-To: <1109005759.6007.7.camel@localhost.localdomain> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> Message-ID: <1109005999.10854.53.camel@localhost.localdomain> On Mon, 2005-02-21 at 18:09 +0100, Thorsten Leemhuis wrote: >> and without requiring the user to have a development >> toolchain installed. > >? I don't understand you here. What do you mean by toolchain -- GCC, >make, kernel-devel are needed of course -- but they are also needed by >DKMS afaics. No, this is exactly what I mean. I think we can solve this problem without requiring the end-user to have gcc installed. ~spot --- Tom "spot" Callaway LCA, RHCE Red Hat Sales Engineer || Aurora Linux Project Leader "If you are going through hell, keep going." -- Sir Winston Churchill From fedora at leemhuis.info Mon Feb 21 17:38:01 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 21 Feb 2005 18:38:01 +0100 Subject: DKMS into Fedora Extras In-Reply-To: <1109005999.10854.53.camel@localhost.localdomain> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> Message-ID: <1109007481.6007.15.camel@localhost.localdomain> Am Montag, den 21.02.2005, 11:13 -0600 schrieb Tom 'spot' Callaway: > On Mon, 2005-02-21 at 18:09 +0100, Thorsten Leemhuis wrote: > > >> and without requiring the user to have a development > >> toolchain installed. > > > >? I don't understand you here. What do you mean by toolchain -- GCC, > >make, kernel-devel are needed of course -- but they are also needed by > >DKMS afaics. > > No, this is exactly what I mean. I think we can solve this problem > without requiring the end-user to have gcc installed. Well, could you enlighten me a bit on your thoughts? Seems I'm missing something here... Of course we can rebuild kernel-modules in extras an push then the same time when a new kernel goes out. Then we only have to solve the install/yum/apt problem. -- Thorsten Leemhuis From adrian at lisas.de Mon Feb 21 17:53:29 2005 From: adrian at lisas.de (Adrian Reber) Date: Mon, 21 Feb 2005 18:53:29 +0100 Subject: Package proposal: hfsplusutils In-Reply-To: <1109003253.19262.719.camel@hades.cambridge.redhat.com> References: <1109003253.19262.719.camel@hades.cambridge.redhat.com> Message-ID: <20050221175329.GA8988@lisas.de> On Mon, Feb 21, 2005 at 04:27:33PM +0000, David Woodhouse wrote: > http://david.woodhou.se/hfsplusutils-1.0.4-2.src.rpm > > > Name : hfsplusutils Relocations: (not relocatable) W: hfsplusutils summary-ended-with-dot Tools for reading Macintosh HFS+ volumes. E: hfsplusutils zero-length /usr/share/doc/hfsplusutils-1.0.4/mail/extents.diff Including the manpage in hfsplus-1.0.4/doc/man would be nice. Maybe some buildrequires. At least I had to install automake14 and libtool to build it. Adrian From tcallawa at redhat.com Mon Feb 21 17:56:50 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 21 Feb 2005 11:56:50 -0600 Subject: DKMS into Fedora Extras In-Reply-To: <1109007481.6007.15.camel@localhost.localdomain> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> Message-ID: <1109008610.10854.66.camel@localhost.localdomain> On Mon, 2005-02-21 at 18:38 +0100, Thorsten Leemhuis wrote: >Of course we can rebuild kernel-modules in extras an push then the same >time when a new kernel goes out. Then we only have to solve the >install/yum/apt problem. Yes. This is more in line with my thoughts. We should able to teach the Extras buildsystem (no, not Seth) to watch updates for new kernels, and rebuild packages marked as kernel-modules to match. New packages marked as kernel-modules get built for all available kernels. This requires some things (off the top of my head): - buildsystem awareness of the kernel packages in Fedora Core (and updates), but it shouldn't be terribly difficult, will just require network connectivity, kept in a table so that new "kernel-module" packages can be built for all available kernels. - a mechanism for marking a package as a "kernel-module" package - kernel-module packages will need to identify the kernel package they were built for, so that yum/apt can resolve dependencies. - yum/apt will need to handle kernel-module packages in the same way it handles kernel packages (allow multiple packages to be installed, rpm -i instead of rpm -U, remove matching kernel-module packages when kernel is removed) The biggest downside to this is that it means that we have a LOT of "kernel-module" packages in FE (one per kernel per package), but I think the end-user transparency is worth it. ~spot --- Tom "spot" Callaway LCA, RHCE Red Hat Sales Engineer || Aurora Linux Project Leader "If you are going through hell, keep going." -- Sir Winston Churchill From ville.skytta at iki.fi Mon Feb 21 18:21:25 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 21 Feb 2005 20:21:25 +0200 Subject: DKMS into Fedora Extras In-Reply-To: <1109008610.10854.66.camel@localhost.localdomain> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> Message-ID: <1109010085.6386.152.camel@bobcat.mine.nu> On Mon, 2005-02-21 at 11:56 -0600, Tom 'spot' Callaway wrote: > On Mon, 2005-02-21 at 18:38 +0100, Thorsten Leemhuis wrote: > > >Of course we can rebuild kernel-modules in extras an push then the same > >time when a new kernel goes out. Then we only have to solve the > >install/yum/apt problem. > > Yes. This is more in line with my thoughts. We should able to teach the > Extras buildsystem (no, not Seth) to watch updates for new kernels, and > rebuild packages marked as kernel-modules to match. New packages marked > as kernel-modules get built for all available kernels. > > This requires some things (off the top of my head): > - buildsystem awareness of the kernel packages in Fedora Core (and > updates), but it shouldn't be terribly difficult, will just require > network connectivity, kept in a table so that new "kernel-module" > packages can be built for all available kernels. > - a mechanism for marking a package as a "kernel-module" package At least "Provides: kernel-module" and "Provides: kernel-modules" are already in module packages out there for this purpose. > - kernel-module packages will need to identify the kernel package they > were built for, so that yum/apt can resolve dependencies. > - yum/apt will need to handle kernel-module packages in the same way it > handles kernel packages (allow multiple packages to be installed, rpm -i > instead of rpm -U, remove matching kernel-module packages when kernel is > removed) Also: - It should be possible to build the module packages also outside of The Buildsystem, preferably with no specfile/SRPM changes required. - Ditto against custom kernels that are packaging-wise compatible with the FC kernels. Some additional more or less related issues more or less in progress: https://bugzilla.redhat.com/145914 https://bugzilla.redhat.com/147553 https://bugzilla.redhat.com/149210 https://bugzilla.redhat.com/149249 > The biggest downside to this is that it means that we have a LOT of > "kernel-module" packages in FE (one per kernel per package), but I think > the end-user transparency is worth it. Ditto. Back to the original topic: FWIW, I'm not against including DKMS in Extras. Including it does not automatically mean that it would be the Ultimate Official way to build modules for Extras at all. From skvidal at phy.duke.edu Mon Feb 21 18:25:09 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 13:25:09 -0500 Subject: DKMS into Fedora Extras In-Reply-To: <1109010085.6386.152.camel@bobcat.mine.nu> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109010085.6386.152.camel@bobcat.mine.nu> Message-ID: <1109010309.16633.20.camel@opus.phy.duke.edu> > Back to the original topic: FWIW, I'm not against including DKMS in > Extras. Including it does not automatically mean that it would be the > Ultimate Official way to build modules for Extras at all. +1 There are some modules we can't build for various reasons but a user might want to do so to keep their system running. I know a fair number of folks who use DKMS with rhel3 to keep their weirdo modules-of-pain working from kernel to kernel. -sv From tcallawa at redhat.com Mon Feb 21 18:24:01 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 21 Feb 2005 12:24:01 -0600 Subject: DKMS into Fedora Extras In-Reply-To: <1109010085.6386.152.camel@bobcat.mine.nu> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109010085.6386.152.camel@bobcat.mine.nu> Message-ID: <1109010241.10854.71.camel@localhost.localdomain> On Mon, 2005-02-21 at 20:21 +0200, Ville Skytt? wrote: >Back to the original topic: FWIW, I'm not against including DKMS in >Extras. Including it does not automatically mean that it would be the >Ultimate Official way to build modules for Extras at all. I agree, however, I would like to see a formal patent grant from Dell before we include it. Adding Matt to the CC list, since he's the requesting owner, and doesn't seem to be on this list yet. ~spot --- Tom "spot" Callaway LCA, RHCE Red Hat Sales Engineer || Aurora Linux Project Leader "If you are going through hell, keep going." -- Sir Winston Churchill From fedora at leemhuis.info Mon Feb 21 18:37:47 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 21 Feb 2005 19:37:47 +0100 Subject: DKMS into Fedora Extras In-Reply-To: <1109008610.10854.66.camel@localhost.localdomain> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> Message-ID: <1109011067.6007.34.camel@localhost.localdomain> Am Montag, den 21.02.2005, 11:56 -0600 schrieb Tom 'spot' Callaway: > On Mon, 2005-02-21 at 18:38 +0100, Thorsten Leemhuis wrote: > >Of course we can rebuild kernel-modules in extras an push then the same > >time when a new kernel goes out. Then we only have to solve the > >install/yum/apt problem. > > Yes. This is more in line with my thoughts. Thank you spot for clarifying. > We should able to teach the > Extras buildsystem ...when its ready... (SCNR) > (no, not Seth)to watch updates for new kernels, [...] > - a mechanism for marking a package as a "kernel-module" package Currently all out kernel-module-packages have a "Provides: kernel- module". Something like that > - kernel-module packages will need to identify the kernel package they > were built for, so that yum/apt can resolve dependencies. Don't know if you now, but currently we simply produce kernel-module packages that have the uname in it's name; e.g. like this: kernel-module-ipw2200-2.6.10-1.766_FC3smp > - yum/apt will need to handle kernel-module packages in the same way it > handles kernel packages (allow multiple packages to be installed, rpm -i > instead of rpm -U, remove matching kernel-module packages when kernel is > removed) This is already done if a package has a "Provides: kernel-module" (or was it "Provides: kernel-modules"?) > The biggest downside to this is that it means that we have a LOT of > "kernel-module" packages in FE (one per kernel per package), but I think > the end-user transparency is worth it. I like the older approach a bit more -- with the uname in the name you solve a lot of problems and it's also transparency to the end-user. And But The install and not update mechanism can lead to problems, see here: https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=394 But of course, uname in the package-name makes the name quite long... Also I'm wondering how we should deal with kernel-modules in extras in general. davej/Core refuses everything that is not upstream for a good reason. If we put everything in extras it looks a bit "odd" IMHO. -- Thorsten Leemhuis From bugs.michael at gmx.net Mon Feb 21 18:37:13 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 21 Feb 2005 19:37:13 +0100 Subject: x86_64 pkg update/rebuild request: gsview In-Reply-To: <421626D8.7070809@math.unl.edu> References: <421626D8.7070809@math.unl.edu> Message-ID: <20050221193713.2f20da1d.bugs.michael@gmx.net> On Fri, 18 Feb 2005 11:33:12 -0600, Rex Dieter wrote: > > fixes borkiness on x86_64 > http://bugzilla.redhat.com/bugzilla/146223#c7 Imported. From bugs.michael at gmx.net Mon Feb 21 18:37:30 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 21 Feb 2005 19:37:30 +0100 Subject: geomview(x86_64) crasher, pull from repo? In-Reply-To: <421624D3.5020703@math.unl.edu> References: <421624D3.5020703@math.unl.edu> Message-ID: <20050221193730.2923c410.bugs.michael@gmx.net> On Fri, 18 Feb 2005 11:24:35 -0600, Rex Dieter wrote: > Could someone with a x86_64 box confirm geomview crash: > http://bugzilla.redhat.com/bugzilla/146584 > > I haven't got any x86_64 box to test it with. > > If so, it probably out to be pulled from the (x86_64) repo until it is > fixed. Removal requested. As much as some people are excited about untested x86_64 builds, we should not offer any packages which crash so badly. If no fix is found and the next upstream update (please point them to above bug report) doesn't fix it either, ExcludeArch x86_64 should be added until geomview is confirmed as fixed. For (re)build requests it would be good if you could open a Wiki account. From rdieter at math.unl.edu Mon Feb 21 18:42:30 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 21 Feb 2005 12:42:30 -0600 Subject: geomview(x86_64) crasher, pull from repo? In-Reply-To: <20050221193730.2923c410.bugs.michael@gmx.net> References: <421624D3.5020703@math.unl.edu> <20050221193730.2923c410.bugs.michael@gmx.net> Message-ID: <421A2B96.1020504@math.unl.edu> Michael Schwendt wrote: > For (re)build requests it would be good if you could open a Wiki account. I have a wiki account: "RexDieter". I suppose I need to be granted access to edit the Extras/FC3Status page? -- Rex From ville.skytta at iki.fi Mon Feb 21 18:47:06 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 21 Feb 2005 20:47:06 +0200 Subject: DKMS into Fedora Extras In-Reply-To: <1109011067.6007.34.camel@localhost.localdomain> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> Message-ID: <1109011626.6386.161.camel@bobcat.mine.nu> On Mon, 2005-02-21 at 19:37 +0100, Thorsten Leemhuis wrote: > This is already done if a package has a "Provides: kernel-module" (or > was it "Provides: kernel-modules"?) It's "kernel-module" in fedora.us, and the Extras (and fedora.us) apt has been tweaked to DTRT + magic with that. Elsewhere (I don't remember where), it's "kernel-modules", and yum has that built-in/hardcoded in its list of packages to install, not upgrade. @Seth, others who have experience with yum and these "kernel-modules" packages: Let's say we have kernel-V-R installed, and kernel-module-foo built for that installed. Now, we get an update for the module package only; the kernel does not change. Obviously, the already installed module package and the new one conflict. What happens when one does "yum update"? From skvidal at phy.duke.edu Mon Feb 21 18:52:07 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 13:52:07 -0500 Subject: DKMS into Fedora Extras In-Reply-To: <1109011626.6386.161.camel@bobcat.mine.nu> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> Message-ID: <1109011927.16633.27.camel@opus.phy.duke.edu> On Mon, 2005-02-21 at 20:47 +0200, Ville Skytt? wrote: > On Mon, 2005-02-21 at 19:37 +0100, Thorsten Leemhuis wrote: > > > This is already done if a package has a "Provides: kernel-module" (or > > was it "Provides: kernel-modules"?) > > It's "kernel-module" in fedora.us, and the Extras (and fedora.us) apt > has been tweaked to DTRT + magic with that. > > Elsewhere (I don't remember where), it's "kernel-modules", and yum has > that built-in/hardcoded in its list of packages to install, not upgrade. > > @Seth, others who have experience with yum and these "kernel-modules" > packages: > > Let's say we have kernel-V-R installed, and kernel-module-foo built for > that installed. Now, we get an update for the module package only; the > kernel does not change. Obviously, the already installed module package > and the new one conflict. What happens when one does "yum update"? > it tries to install it. Same thing as happens in up2date. I'm open to suggestions that don't seem like pretty nasty hacks to solve the problem. -sv From fedora at leemhuis.info Mon Feb 21 18:57:45 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 21 Feb 2005 19:57:45 +0100 Subject: DKMS into Fedora Extras In-Reply-To: <1109011626.6386.161.camel@bobcat.mine.nu> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> Message-ID: <1109012266.6007.36.camel@localhost.localdomain> Am Montag, den 21.02.2005, 20:47 +0200 schrieb Ville Skytt?: > Let's say we have kernel-V-R installed, and kernel-module-foo built > for > that installed. Now, we get an update for the module package only; > the > kernel does not change. Obviously, the already installed module > package > and the new one conflict. What happens when one does "yum update"? It fails: https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=394 -- Thorsten Leemhuis From bugs.michael at gmx.net Mon Feb 21 19:03:02 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 21 Feb 2005 20:03:02 +0100 Subject: geomview(x86_64) crasher, pull from repo? In-Reply-To: <421A2B96.1020504@math.unl.edu> References: <421624D3.5020703@math.unl.edu> <20050221193730.2923c410.bugs.michael@gmx.net> <421A2B96.1020504@math.unl.edu> Message-ID: <20050221200302.73242267.bugs.michael@gmx.net> On Mon, 21 Feb 2005 12:42:30 -0600, Rex Dieter wrote: > Michael Schwendt wrote: > > > For (re)build requests it would be good if you could open a Wiki account. > > I have a wiki account: "RexDieter". > > I suppose I need to be granted access to edit the Extras/FC3Status page? Yes. You're in the EditGroup now. From skvidal at phy.duke.edu Mon Feb 21 19:05:03 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 14:05:03 -0500 Subject: DKMS into Fedora Extras In-Reply-To: <1109012266.6007.36.camel@localhost.localdomain> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> Message-ID: <1109012703.16633.35.camel@opus.phy.duke.edu> On Mon, 2005-02-21 at 19:57 +0100, Thorsten Leemhuis wrote: > Am Montag, den 21.02.2005, 20:47 +0200 schrieb Ville Skytt?: > > Let's say we have kernel-V-R installed, and kernel-module-foo built > > for > > that installed. Now, we get an update for the module package only; > > the > > kernel does not change. Obviously, the already installed module > > package > > and the new one conflict. What happens when one does "yum update"? > > It fails: > > https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=394 I'm not sure what the other modes should be. we might be able to do something like: if two kernel modules have the same name but different versions then it's an update. that would require: - kernel-version-in-module-package-name - provides: kernel-module in the header - consistent use. if that's do-able I should be able to write that code w/o it being too excruciating. -sv From ville.skytta at iki.fi Mon Feb 21 19:06:52 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 21 Feb 2005 21:06:52 +0200 Subject: DKMS into Fedora Extras In-Reply-To: <1109011927.16633.27.camel@opus.phy.duke.edu> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109011927.16633.27.camel@opus.phy.duke.edu> Message-ID: <1109012812.6386.173.camel@bobcat.mine.nu> On Mon, 2005-02-21 at 13:52 -0500, seth vidal wrote: > On Mon, 2005-02-21 at 20:47 +0200, Ville Skytt? wrote: > > Let's say we have kernel-V-R installed, and kernel-module-foo built for > > that installed. Now, we get an update for the module package only; the > > kernel does not change. Obviously, the already installed module package > > and the new one conflict. What happens when one does "yum update"? > > it tries to install it. Same thing as happens in up2date. ...and aborts the transaction if there are conflicts, file-based or others? What does the error message roughly look like? > I'm open to suggestions that don't seem like pretty nasty hacks to solve > the problem. I don't have that now, sorry. But I do think _something_ new is most likely needed in yum to make this whole scenario to Just Work; it probably isn't solvable anywhere else. From fedora at leemhuis.info Mon Feb 21 19:21:37 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 21 Feb 2005 20:21:37 +0100 Subject: DKMS into Fedora Extras In-Reply-To: <1109012703.16633.35.camel@opus.phy.duke.edu> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> Message-ID: <1109013698.6007.41.camel@localhost.localdomain> Am Montag, den 21.02.2005, 14:05 -0500 schrieb seth vidal: > On Mon, 2005-02-21 at 19:57 +0100, Thorsten Leemhuis wrote: > > Am Montag, den 21.02.2005, 20:47 +0200 schrieb Ville Skytt?: > > > Let's say we have kernel-V-R installed, and kernel-module-foo built > > > for > > > that installed. Now, we get an update for the module package only; > > > the > > > kernel does not change. Obviously, the already installed module > > > package > > > and the new one conflict. What happens when one does "yum update"? > > > > It fails: > > > > https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=394 > > I'm not sure what the other modes should be. > > we might be able to do something like: > if two kernel modules have the same name but different versions then > it's an update. > > that would require: > - kernel-version-in-module-package-name > - provides: kernel-module in the header > - consistent use. > > if that's do-able I should be able to write that code w/o it being too > excruciating. Of course we should solve this problem somehow. But IMHO we first should discuss how kernel-module are packaged in extras. It seems some people don't like the kernel-version-in-module-package-name scheme. Maybe you, Panu, Ville, Spot, Anvil, me and maybe other should discuss this somewhere (lists, IRC,...) and come to an agreement before we fix yum. -- Thorsten Leemhuis From tcallawa at redhat.com Mon Feb 21 19:19:00 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 21 Feb 2005 13:19:00 -0600 Subject: DKMS into Fedora Extras In-Reply-To: <1109012703.16633.35.camel@opus.phy.duke.edu> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> Message-ID: <1109013540.10854.77.camel@localhost.localdomain> On Mon, 2005-02-21 at 14:05 -0500, seth vidal wrote: >we might be able to do something like: >if two kernel modules have the same name but different versions then >it's an update. > >that would require: > - kernel-version-in-module-package-name > - provides: kernel-module in the header > - consistent use. I think that's doable. Lets take this thread over here: https://www.redhat.com/mailman/listinfo/fedora-packaging ~spot --- Tom "spot" Callaway LCA, RHCE Red Hat Sales Engineer || Aurora Linux Project Leader "If you are going through hell, keep going." -- Sir Winston Churchill From toshio at tiki-lounge.com Mon Feb 21 20:37:19 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 21 Feb 2005 12:37:19 -0800 Subject: DKMS into Fedora Extras In-Reply-To: <1109013540.10854.77.camel@localhost.localdomain>; from tcallawa@redhat.com on Mon, Feb 21, 2005 at 01:19:00PM -0600 References: <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> Message-ID: <20050221123719.A21733@tiki-lounge.com> On Mon, Feb 21, 2005 at 01:19:00PM -0600, Tom 'spot' Callaway wrote: > > I think that's doable. Lets take this thread over here: > https://www.redhat.com/mailman/listinfo/fedora-packaging > Changing the subject slightly.... Do we need another mailing list? Breaking fedora-extras away from fedora-devel was very logical, but is breaking packaging discussions away from extras-list necessary at this point in time? How many people will want to be involved in extras-list but not packaging and vice versa? Perhaps this is tied to the manner in which packages will be requested from now on. If we use fedora-extras-list as presently, then it might be a good idea to have separate lists for discussion of how to package vs packages we want to include. But if much of this is eventually going into a ticketting system then is there really enough traffic on extras to make that necessary? Was anything decided about this at FUDCon? I'm not against a separate list per se, I just think that the traffic doesn't justify needing a new list yet and the synthesis of keeping ideas from these two lists together is still worthwhile. -Toshio From skvidal at phy.duke.edu Mon Feb 21 20:47:18 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 15:47:18 -0500 Subject: DKMS into Fedora Extras In-Reply-To: <20050221123719.A21733@tiki-lounge.com> References: <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <20050221123719.A21733@tiki-lounge.com> Message-ID: <1109018838.16633.68.camel@opus.phy.duke.edu> On Mon, 2005-02-21 at 12:37 -0800, Toshio Kuratomi wrote: > Changing the subject slightly.... Do we need another mailing list? Breaking > fedora-extras away from fedora-devel was very logical, but is breaking > packaging discussions away from extras-list necessary at this point in time? > How many people will want to be involved in extras-list but not packaging > and vice versa? it's not just for extras packaging - but for packaging discussions in general at least that was my perspective. Also it keeps the packaging discussion free of the 'this was built' and 'I want this' posts. > Perhaps this is tied to the manner in which packages will be requested from > now on. If we use fedora-extras-list as presently, then it might be a good > idea to have separate lists for discussion of how to package vs packages we > want to include. But if much of this is eventually going into a ticketting > system then is there really enough traffic on extras to make that necessary? > Was anything decided about this at FUDCon? > > I'm not against a separate list per se, I just think that the traffic > doesn't justify needing a new list yet and the synthesis of keeping ideas > from these two lists together is still worthwhile. extras is for discussion of things going into extras. packaging is to discuss packaging guidelines and rules for both extras and core - that's why that discussion needed to move. re: fudcon - lots of things came out of it - we're working on implementing those now - fedora-packaging was one of them. -sv From tcallawa at redhat.com Mon Feb 21 20:44:52 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 21 Feb 2005 14:44:52 -0600 Subject: DKMS into Fedora Extras In-Reply-To: <20050221123719.A21733@tiki-lounge.com> References: <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <20050221123719.A21733@tiki-lounge.com> Message-ID: <1109018692.10854.122.camel@localhost.localdomain> On Mon, 2005-02-21 at 12:37 -0800, Toshio Kuratomi wrote: >Changing the subject slightly.... Do we need another mailing list? Breaking >fedora-extras away from fedora-devel was very logical, but is breaking >packaging discussions away from extras-list necessary at this point in time? >How many people will want to be involved in extras-list but not packaging >and vice versa? fedora-extras-list is for things that are packaged. fedora-packaging is where the standards and practices for packaging are discussed. I want to do it on a separate mailing list to retain what little remains of my sanity. :) ~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 Mon Feb 21 21:24:15 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 21 Feb 2005 13:24:15 -0800 Subject: DKMS into Fedora Extras In-Reply-To: <1109018838.16633.68.camel@opus.phy.duke.edu>; from skvidal@phy.duke.edu on Mon, Feb 21, 2005 at 03:47:18PM -0500 References: <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <20050221123719.A21733@tiki-lounge.com> <1109018838.16633.68.camel@opus.phy.duke.edu> Message-ID: <20050221132415.C21733@tiki-lounge.com> First off, thanks Tom and Seth for the quick, informative replies., On Mon, Feb 21, 2005 at 03:47:18PM -0500, seth vidal wrote: > > it's not just for extras packaging - but for packaging discussions in > general at least that was my perspective. Also it keeps the packaging > discussion free of the 'this was built' and 'I want this' posts. But will this noise end up in a ticketting system in the future? (I feel a bit in the dark about that aspect. If it won't then yes, I agree, we need to get this stuff separated out.) [snip my context] > > extras is for discussion of things going into extras. > > packaging is to discuss packaging guidelines and rules for both extras > and core - that's why that discussion needed to move. > I agree with the ideal being expressed here [packaging = extras + core] I just don't want to be so pure we don't get enough fodder to drive the idealization of good practice. OTOH, I'm sure all the vocal people will subscribe to all the development lists anyhow so I'll just shutup :-) > re: fudcon - lots of things came out of it - we're working on > implementing those now - fedora-packaging was one of them. > Is anyone doing a writeup of fudcon? The developer relevant/decison making/discussion aspects anyhow? -Toshio From gemi at bluewin.ch Mon Feb 21 21:37:05 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 21 Feb 2005 22:37:05 +0100 Subject: Packaging icons for new mime-types Message-ID: <1109021825.1919.2.camel@scriabin.tannenrauch.ch> I think it is pretty clear how to install a new mime-type used by package. However I do not entirely understand how to install a corresponding icon. What I did for TeXmacs is that I packaged an icon named gnome- mime-text-texmacs.xpm in the directory $RPM_BUILD_ROOT% {_datadir}/icons/gnome/48x48/mimetypes/gnome-mime-text-texmacs.xpm. Is the correct way to do it? -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From skvidal at phy.duke.edu Mon Feb 21 21:51:44 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 16:51:44 -0500 Subject: DKMS into Fedora Extras In-Reply-To: <20050221132415.C21733@tiki-lounge.com> References: <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <20050221123719.A21733@tiki-lounge.com> <1109018838.16633.68.camel@opus.phy.duke.edu> <20050221132415.C21733@tiki-lounge.com> Message-ID: <1109022704.24448.6.camel@opus.phy.duke.edu> > > > > packaging is to discuss packaging guidelines and rules for both extras > > and core - that's why that discussion needed to move. > > > I agree with the ideal being expressed here [packaging = extras + core] > I just don't want to be so pure we don't get enough fodder to drive the > idealization of good practice. OTOH, I'm sure all the vocal people will > subscribe to all the development lists anyhow so I'll just shutup :-) > > > re: fudcon - lots of things came out of it - we're working on > > implementing those now - fedora-packaging was one of them. > > > Is anyone doing a writeup of fudcon? The developer relevant/decison > making/discussion aspects anyhow? > already done. http://www.bytebot.net/talks/FedoraMeetingStatusReport.pdf you need to keep up with your fedora blogs ;) -sv From wtogami at redhat.com Mon Feb 21 22:31:21 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 21 Feb 2005 12:31:21 -1000 Subject: Package proposal: hfsplusutils In-Reply-To: <1109003253.19262.719.camel@hades.cambridge.redhat.com> References: <1109003253.19262.719.camel@hades.cambridge.redhat.com> Message-ID: <421A6139.4000703@redhat.com> Shouldn't this go into FC4 core? Warren From toshio at tiki-lounge.com Mon Feb 21 22:32:34 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 21 Feb 2005 14:32:34 -0800 Subject: DKMS into Fedora Extras In-Reply-To: <1109022704.24448.6.camel@opus.phy.duke.edu>; from skvidal@phy.duke.edu on Mon, Feb 21, 2005 at 04:51:44PM -0500 References: <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <20050221123719.A21733@tiki-lounge.com> <1109018838.16633.68.camel@opus.phy.duke.edu> <20050221132415.C21733@tiki-lounge.com> <1109022704.24448.6.camel@opus.phy.duke.edu> Message-ID: <20050221143234.E21733@tiki-lounge.com> On Mon, Feb 21, 2005 at 04:51:44PM -0500, seth vidal wrote: > > > > > > packaging is to discuss packaging guidelines and rules for both extras > > > and core - that's why that discussion needed to move. > > > > > I agree with the ideal being expressed here [packaging = extras + core] > > I just don't want to be so pure we don't get enough fodder to drive the > > idealization of good practice. OTOH, I'm sure all the vocal people will > > subscribe to all the development lists anyhow so I'll just shutup :-) > > > > > re: fudcon - lots of things came out of it - we're working on > > > implementing those now - fedora-packaging was one of them. > > > > > Is anyone doing a writeup of fudcon? The developer relevant/decison > > making/discussion aspects anyhow? > > > > already done. > > http://www.bytebot.net/talks/FedoraMeetingStatusReport.pdf > > > you need to keep up with your fedora blogs ;) > Thanks! From cra at WPI.EDU Mon Feb 21 22:44:23 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Mon, 21 Feb 2005 17:44:23 -0500 Subject: Package proposal: hfsplusutils In-Reply-To: <421A6139.4000703@redhat.com> References: <1109003253.19262.719.camel@hades.cambridge.redhat.com> <421A6139.4000703@redhat.com> Message-ID: <20050221224423.GE5061@angus.ind.WPI.EDU> On Mon, Feb 21, 2005 at 12:31:21PM -1000, Warren Togami wrote: > Shouldn't this go into FC4 core? I would say yes, but "the way to get packages into Core is to get them into Extras first". From dwmw2 at infradead.org Mon Feb 21 22:54:58 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 21 Feb 2005 22:54:58 +0000 Subject: Package proposal: hfsplusutils In-Reply-To: <20050221224423.GE5061@angus.ind.WPI.EDU> References: <1109003253.19262.719.camel@hades.cambridge.redhat.com> <421A6139.4000703@redhat.com> <20050221224423.GE5061@angus.ind.WPI.EDU> Message-ID: <1109026498.26578.64.camel@localhost.localdomain> On Mon, 2005-02-21 at 17:44 -0500, Chuck R. Anderson wrote: >On Mon, Feb 21, 2005 at 12:31:21PM -1000, Warren Togami wrote: >> Shouldn't this go into FC4 core? > >I would say yes, but "the way to get packages into Core is to get them >into Extras first". Well, maybe. I actually checked it out of Core CVS in order to put it up there though :) -- dwmw2 From wtogami at redhat.com Mon Feb 21 22:55:43 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 21 Feb 2005 12:55:43 -1000 Subject: Package proposal: hfsplusutils In-Reply-To: <20050221224423.GE5061@angus.ind.WPI.EDU> References: <1109003253.19262.719.camel@hades.cambridge.redhat.com> <421A6139.4000703@redhat.com> <20050221224423.GE5061@angus.ind.WPI.EDU> Message-ID: <421A66EF.8020706@redhat.com> Chuck R. Anderson wrote: > On Mon, Feb 21, 2005 at 12:31:21PM -1000, Warren Togami wrote: > >>Shouldn't this go into FC4 core? > > > I would say yes, but "the way to get packages into Core is to get them > into Extras first". > Right, this does belong in FC3 Extras. Go ahead and import it, we fix it in CVS, then build when everyone is happy. Warren From skvidal at phy.duke.edu Mon Feb 21 23:08:01 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 18:08:01 -0500 Subject: Mirrors In-Reply-To: <1109004197.27708.6.camel@wintermute.sr.unh.edu> References: <1109004197.27708.6.camel@wintermute.sr.unh.edu> Message-ID: <1109027281.24448.25.camel@opus.phy.duke.edu> On Mon, 2005-02-21 at 11:43 -0500, Thomas J. Baker wrote: > Any update on the extras mirror list. > yah - I was at lwce and fudcon last week and didn't get anything done. I've got a list of mirrors that can go - but it's not going to fly for fc4t1 release soon. -sv From nando at ccrma.Stanford.EDU Mon Feb 21 23:21:04 2005 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: 21 Feb 2005 15:21:04 -0800 Subject: DKMS into Fedora Extras In-Reply-To: <1109012703.16633.35.camel@opus.phy.duke.edu> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> Message-ID: <1109028063.21076.32.camel@cmn37.stanford.edu> On Mon, 2005-02-21 at 11:05, seth vidal wrote: > On Mon, 2005-02-21 at 19:57 +0100, Thorsten Leemhuis wrote: > > Am Montag, den 21.02.2005, 20:47 +0200 schrieb Ville Skytt?: > > > Let's say we have kernel-V-R installed, and kernel-module-foo built > > > for > > > that installed. Now, we get an update for the module package only; > > > the > > > kernel does not change. Obviously, the already installed module > > > package > > > and the new one conflict. What happens when one does "yum update"? > > > > It fails: > > > > https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=394 > > I'm not sure what the other modes should be. > > we might be able to do something like: > if two kernel modules have the same name but different versions then > it's an update. > > that would require: > - kernel-version-in-module-package-name > - provides: kernel-module in the header > - consistent use. > > if that's do-able I should be able to write that code w/o it being too > excruciating. Has anyone had problems with architecture matching between external kernel module packages and the main kernel package? I did (in Planet CCRMA), albeit a long time ago, and maybe as a result of old versions of apt not doing the right thing. But it was possible to install a kernel package of, let's say, architecture i586, on top of a i686 kernel. Obviously that does not work. There are no dependencies at the rpm level to keep that from happening. To prevent that from happening again I have both a provides (in the kernel package) and matching requires (in the kernel-module-* packages) so that it is impossible, from the point of view of rpm, to mismatch architectures. Could someone please add this, if deemed appropriate, to the list of requirements when packaging kernel modules? -- Fernando From ed at eh3.com Tue Feb 22 00:01:53 2005 From: ed at eh3.com (Ed Hill) Date: Mon, 21 Feb 2005 19:01:53 -0500 Subject: sponsorship for scientific computing stuff Message-ID: <1109030513.30620.103.camel@localhost.localdomain> Hi folks, My name is Ed Hill and I was one of the dozen or so FUDCon attendees who asked about CVS access. Given the rules posted at: http://fedoraproject.org/wiki/Extras/CvsAccess would anyone be kind enough to sponsor me? Given the chance, I'd like to help maintain a few packages related to scientific computing starting with: netCDF: https://bugzilla.fedora.us/show_bug.cgi?id=1874 NCO: https://bugzilla.fedora.us/show_bug.cgi?id=1893 I really don't have the time to "go crazy and break stuff" so I'll gladly be a responsible fellow and stick to a little corner of the Fedora Extras packaging world. thanks, Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From skvidal at phy.duke.edu Tue Feb 22 00:43:39 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 19:43:39 -0500 Subject: DKMS into Fedora Extras In-Reply-To: <1109028063.21076.32.camel@cmn37.stanford.edu> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109028063.21076.32.camel@cmn37.stanford.edu> Message-ID: <1109033019.28235.4.camel@cutter> >Has anyone had problems with architecture matching between external >kernel module packages and the main kernel package? > >I did (in Planet CCRMA), albeit a long time ago, and maybe as a result >of old versions of apt not doing the right thing. > >But it was possible to install a kernel package of, let's say, >architecture i586, on top of a i686 kernel. Obviously that does not >work. There are no dependencies at the rpm level to keep that from >happening. To prevent that from happening again I have both a provides >(in the kernel package) and matching requires (in the kernel-module-* >packages) so that it is impossible, from the point of view of rpm, to >mismatch architectures. > >Could someone please add this, if deemed appropriate, to the list of >requirements when packaging kernel modules? Yum will happily install an i586 kernel-module with an i686 kernel if there is no i686 kernel-module package available. There's no dependent arch relationship b/c kernels and kernel modules. -sv From nando at ccrma.Stanford.EDU Tue Feb 22 01:22:07 2005 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: 21 Feb 2005 17:22:07 -0800 Subject: DKMS into Fedora Extras In-Reply-To: <1109033019.28235.4.camel@cutter> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109028063.21076.32.camel@cmn37.stanford.edu> <1109033019.28235.4.camel@cutter> Message-ID: <1109035327.21076.265.camel@cmn37.stanford.edu> On Mon, 2005-02-21 at 16:43, seth vidal wrote: > >Has anyone had problems with architecture matching between external > >kernel module packages and the main kernel package? > > > >I did (in Planet CCRMA), albeit a long time ago, and maybe as a result > >of old versions of apt not doing the right thing. [to clarify a little bit: apt would install one kernel arch and afterwards it would install a different one for the kernel module - all archs were available, while I never managed to repeat it myself, it seemed to happen with certain processors only] > >But it was possible to install a kernel package of, let's say, > >architecture i586, on top of a i686 kernel. Obviously that does not > >work. There are no dependencies at the rpm level to keep that from > >happening. To prevent that from happening again I have both a provides > >(in the kernel package) and matching requires (in the kernel-module-* > >packages) so that it is impossible, from the point of view of rpm, to > >mismatch architectures. > > > >Could someone please add this, if deemed appropriate, to the list of > >requirements when packaging kernel modules? > > Yum will happily install an i586 kernel-module with an i686 kernel if > there is no i686 kernel-module package available. There's no dependent > arch relationship b/c kernels and kernel modules. I think there should be one. You can't install packages if you don't have their dependencies available, it should not be different for kernels and their modules. -- Fernando From skvidal at phy.duke.edu Tue Feb 22 01:27:40 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 20:27:40 -0500 Subject: DKMS into Fedora Extras In-Reply-To: <1109035327.21076.265.camel@cmn37.stanford.edu> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109028063.21076.32.camel@cmn37.stanford.edu> <1109033019.28235.4.camel@cutter> <1109035327.21076.265.camel@cmn37.stanford.edu> Message-ID: <1109035660.28235.8.camel@cutter> >I think there should be one. You can't install packages if you don't >have their dependencies available, it should not be different for >kernels and their modules. sure - but arch specific deps have not been included, last time I checked. -sv From skvidal at phy.duke.edu Tue Feb 22 01:32:11 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 20:32:11 -0500 Subject: DKMS into Fedora Extras In-Reply-To: <1109035660.28235.8.camel@cutter> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109028063.21076.32.camel@cmn37.stanford.edu> <1109033019.28235.4.camel@cutter> <1109035327.21076.265.camel@cmn37.stanford.edu> <1109035660.28235.8.camel@cutter> Message-ID: <1109035931.28235.10.camel@cutter> On Mon, 2005-02-21 at 20:27 -0500, seth vidal wrote: >>I think there should be one. You can't install packages if you don't >>have their dependencies available, it should not be different for >>kernels and their modules. > >sure - but arch specific deps have not been included, last time I >checked. > Just talked to katz about this: kernels provide: kernel-%{arch}=ver-rel so the modules just dep on that. -sv From nando at ccrma.Stanford.EDU Tue Feb 22 01:32:15 2005 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: 21 Feb 2005 17:32:15 -0800 Subject: DKMS into Fedora Extras In-Reply-To: <1109035660.28235.8.camel@cutter> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109028063.21076.32.camel@cmn37.stanford.edu> <1109033019.28235.4.camel@cutter> <1109035327.21076.265.camel@cmn37.stanford.edu> <1109035660.28235.8.camel@cutter> Message-ID: <1109035934.21080.271.camel@cmn37.stanford.edu> On Mon, 2005-02-21 at 17:27, seth vidal wrote: > >I think there should be one. You can't install packages if you don't > >have their dependencies available, it should not be different for > >kernels and their modules. > > sure - but arch specific deps have not been included, last time I > checked. I'm currently doing this: in the kernel package --provides includes this: kernel-2.6.10-0.6.rdt.rhfc3.ccrma-i686 in the kernel-module-alsa --requires includes this: kernel-2.6.10-0.6.rdt.rhfc3.ccrma-i686 -- Fernando From nando at ccrma.Stanford.EDU Tue Feb 22 01:35:40 2005 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: 21 Feb 2005 17:35:40 -0800 Subject: DKMS into Fedora Extras In-Reply-To: <1109035931.28235.10.camel@cutter> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109028063.21076.32.camel@cmn37.stanford.edu> <1109033019.28235.4.camel@cutter> <1109035327.21076.265.camel@cmn37.stanford.edu> <1109035660.28235.8.camel@cutter> <1109035931.28235.10.camel@cutter> Message-ID: <1109036140.21081.276.camel@cmn37.stanford.edu> On Mon, 2005-02-21 at 17:32, seth vidal wrote: > On Mon, 2005-02-21 at 20:27 -0500, seth vidal wrote: > >>I think there should be one. You can't install packages if you don't > >>have their dependencies available, it should not be different for > >>kernels and their modules. > > > >sure - but arch specific deps have not been included, last time I > >checked. > > Just talked to katz about this: > > kernels provide: > kernel-%{arch}=ver-rel > > so the modules just dep on that. Ah, good! This is recent, right?, I was not aware of it. I'll change my stuff in my next build (our emails just crossed paths) so that it matches this proposal, standard, or whatever. Hopefully this will be in the kernel module build "document" (if it is not already there). -- Fernando From skvidal at phy.duke.edu Tue Feb 22 04:40:52 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 23:40:52 -0500 Subject: DKMS into Fedora Extras In-Reply-To: <1109036140.21081.276.camel@cmn37.stanford.edu> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109028063.21076.32.camel@cmn37.stanford.edu> <1109033019.28235.4.camel@cutter> <1109035327.21076.265.camel@cmn37.stanford.edu> <1109035660.28235.8.camel@cutter> <1109035931.28235.10.camel@cutter> <1109036140.21081.276.camel@cmn37.stanford.edu> Message-ID: <1109047252.28235.36.camel@cutter> On Mon, 2005-02-21 at 17:35 -0800, Fernando Lopez-Lezcano wrote: >On Mon, 2005-02-21 at 17:32, seth vidal wrote: >> On Mon, 2005-02-21 at 20:27 -0500, seth vidal wrote: >> >>I think there should be one. You can't install packages if you don't >> >>have their dependencies available, it should not be different for >> >>kernels and their modules. >> > >> >sure - but arch specific deps have not been included, last time I >> >checked. >> >> Just talked to katz about this: >> >> kernels provide: >> kernel-%{arch}=ver-rel >> >> so the modules just dep on that. > >Ah, good! This is recent, right?, I was not aware of it. very recent. It might not have hit rawhide yet, in fact. It is, however, on the list, from what i've been told. > >I'll change my stuff in my next build (our emails just crossed paths) so >that it matches this proposal, standard, or whatever. Hopefully this >will be in the kernel module build "document" (if it is not already >there). Yes, this is handy info to know. -sv From skvidal at fedoraproject.org Tue Feb 22 06:03:12 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 22 Feb 2005 01:03:12 -0500 Subject: New/Updated Fedora Extras Packages Message-ID: <1109052192.28235.60.camel@cutter> Hi Everyone, qcad (i386, x86_64) bluefish (i386, x86_64) conglomerate (i386, x86_64) fbida (i386, x86_64) uim (i386, x86_64) TeXmacs (i386, x86_64) pl (i386) gazpacho (noarch) Removed: geomview (x86_64) Extras info: http://fedoraproject.org/wiki/Extras Status page: http://fedoraproject.org/wiki/Extras/FC3Status Follow updates and new packages at: http://fedoraproject.org/infofeed/ Report problems at Bugzilla: http://bugzilla.redhat.com/ thanks, -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Tue Feb 22 06:48:02 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 22 Feb 2005 08:48:02 +0200 Subject: DKMS into Fedora Extras In-Reply-To: <1109047252.28235.36.camel@cutter> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109028063.21076.32.camel@cmn37.stanford.edu> <1109033019.28235.4.camel@cutter> <1109035327.21076.265.camel@cmn37.stanford.edu> <1109035660.28235.8.camel@cutter> <1109035931.28235.10.camel@cutter> <1109036140.21081.276.camel@cmn37.stanford.edu> <1109047252.28235.36.camel@cutter> Message-ID: <1109054882.6386.284.camel@bobcat.mine.nu> On Mon, 2005-02-21 at 23:40 -0500, seth vidal wrote: > On Mon, 2005-02-21 at 17:35 -0800, Fernando Lopez-Lezcano wrote: > >On Mon, 2005-02-21 at 17:32, seth vidal wrote: > >> On Mon, 2005-02-21 at 20:27 -0500, seth vidal wrote: > >> >>I think there should be one. You can't install packages if you don't > >> >>have their dependencies available, it should not be different for > >> >>kernels and their modules. > >> > > >> >sure - but arch specific deps have not been included, last time I > >> >checked. > >> > >> Just talked to katz about this: > >> > >> kernels provide: > >> kernel-%{arch}=ver-rel And variants hopefully eg. kernel-smp-%{arch} = ver-rel, then? > >> so the modules just dep on that. > > > >Ah, good! This is recent, right?, I was not aware of it. > > very recent. It might not have hit rawhide yet, in fact. > It is, however, on the list, from what i've been told. Coincidence or not, at least it's at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149249 From rdieter at math.unl.edu Tue Feb 22 12:57:01 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 22 Feb 2005 06:57:01 -0600 Subject: Packaging icons for new mime-types In-Reply-To: <1109021825.1919.2.camel@scriabin.tannenrauch.ch> References: <1109021825.1919.2.camel@scriabin.tannenrauch.ch> Message-ID: G?rard Milmeister wrote: > I think it is pretty clear how to install a new mime-type used by > package. > However I do not entirely understand how to install a corresponding > icon. What I did for TeXmacs is that I packaged an icon named gnome- > mime-text-texmacs.xpm in the directory $RPM_BUILD_ROOT% > {_datadir}/icons/gnome/48x48/mimetypes/gnome-mime-text-texmacs.xpm. > Is the correct way to do it? It's certainly not wrong, but I'd suggest you put your icon(s) in %%_datadir/icons, unless you intend to support different sizes, then use the generic %%_datadir/icons/hicolor. -- Rex From dwmw2 at infradead.org Tue Feb 22 13:51:42 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 22 Feb 2005 13:51:42 +0000 Subject: Package proposal: hfsplusutils In-Reply-To: <20050221175329.GA8988@lisas.de> References: <1109003253.19262.719.camel@hades.cambridge.redhat.com> <20050221175329.GA8988@lisas.de> Message-ID: <1109080302.26578.108.camel@localhost.localdomain> On Mon, 2005-02-21 at 18:53 +0100, Adrian Reber wrote: > >W: hfsplusutils summary-ended-with-dot Tools for reading Macintosh HFS+ volumes. >E: hfsplusutils zero-length /usr/share/doc/hfsplusutils-1.0.4/mail/extents.diff done >Including the manpage in hfsplus-1.0.4/doc/man would be nice. done >Maybe some buildrequires. At least I had to install automake14 and >libtool to build it. done. Thanks for the feedback. -- dwmw2 From qspencer at ieee.org Tue Feb 22 15:36:13 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Tue, 22 Feb 2005 09:36:13 -0600 Subject: Octave add-on packages Message-ID: <421B516D.6040503@ieee.org> Hello all, I'm joining this list because I'm interested in maintaining some add-on packages for octave in Fedora Extras. Octave (currently in Fedora Core) is a high-level language for numerical computation that is mostly compatible with Matlab. Matlab (a commercial product) is distributed as a base package plus a large set of add-on "toolboxes" that serve specific needs for different users. The Octave user community has duplicated some of these, which are distributed in the octave-forge package (octave.sourceforge.net). For a while now I have built my own RPM versions of octave-forge, and I would like to see them become part of Fedora Extras, since they are becoming increasingly necessary for the octave user community. I have a few related questions. The first is regarding octave itself. I never use the Core octave packages for two reasons. First is that I like to keep up with the latest developments in octave, but more imporantly, octave is capable of linking to some improved libraries like FFTW and ATLAS (math-atlas.sourceforge.net). Support for FFTW is as simple as rebuilding the package with FFTW present on the system (I haven't figured out how to distribute ATLAS yet because it requires compile-time optimizations). However, FFTW is in Extras. I'm wondering what is the best way of dealing with this. I see three possibilities: (1) maintain a separate Octave in Extras with FFTW support, (2) move FFTW into Core, or (3) move octave into Extras. I think option 3 makes the most sense, particularly since octave has a relatively small user base (it may also make sense to do the same with the blas and lapack libraries--there are likely not many other programs that use them). My second question related to FFTW is why the Extras version is so old (2.1.5), when version 3.0.1 has been out for nearly 2 years. Octave supports only FFTW version 3. I recall freshrpms used to have a fftw3 package but it has been dropped. Is there less interest in version 3? I would like to begin with a basic version of octave-forge (this could be built for just the basic octave package in Core initially). Eventually, as time permits, there are some optional dependencies that could be added for symbolic math. Regards, Quentin Spencer From tcallawa at redhat.com Tue Feb 22 15:53:57 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 22 Feb 2005 09:53:57 -0600 Subject: sponsorship for scientific computing stuff In-Reply-To: <1109030513.30620.103.camel@localhost.localdomain> References: <1109030513.30620.103.camel@localhost.localdomain> Message-ID: <1109087637.31372.65.camel@localhost.localdomain> On Mon, 2005-02-21 at 19:01 -0500, Ed Hill wrote: >Hi folks, > >My name is Ed Hill and I was one of the dozen or so FUDCon attendees who >asked about CVS access. Given the rules posted at: > > http://fedoraproject.org/wiki/Extras/CvsAccess > >would anyone be kind enough to sponsor me? I'll sponsor you. ~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 Feb 22 15:59:21 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 22 Feb 2005 09:59:21 -0600 Subject: Octave add-on packages In-Reply-To: <421B516D.6040503@ieee.org> References: <421B516D.6040503@ieee.org> Message-ID: <1109087962.31372.71.camel@localhost.localdomain> On Tue, 2005-02-22 at 09:36 -0600, Quentin Spencer wrote: >(3) move octave into Extras. I think option 3 makes the most sense, >particularly since octave has a relatively small user base (it may also >make sense to do the same with the blas and lapack libraries--there are >likely not many other programs that use them). I think this logic makes the most sense, I don't think anything depends on octave in Core. Ivana Varekova owns this package in FC (and is CC'd here). Since we're bursting at the seams in Core, this seems like a good package to move to extras, where it can then depend on FFTW. Ivana, would you be opposed to moving octave to core and linking it to FFTW? ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From gemi at bluewin.ch Tue Feb 22 16:04:52 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Tue, 22 Feb 2005 17:04:52 +0100 Subject: Request for package import: skencil In-Reply-To: <1108420714.5083.4.camel@scriabin.tannenrauch.ch> References: <1108420714.5083.4.camel@scriabin.tannenrauch.ch> Message-ID: <1109088292.9904.0.camel@scriabin.tannenrauch.ch> On Mon, 2005-02-14 at 23:38 +0100, G?rard Milmeister wrote: > I repackaged skencil (from atrpms) for Extras: > http://www.ifi.unizh.ch/staff/milmei/rpms/skencil-0.6.16-1.src.rpm > > The package from atrpms conflicts with python-imaging included in > Extras. I further added an icon, a .desktop file and a mime type for > skencil documents. > Is it ok if import this? -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From bugs.michael at gmx.net Tue Feb 22 16:32:22 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 22 Feb 2005 17:32:22 +0100 Subject: Octave add-on packages In-Reply-To: <421B516D.6040503@ieee.org> References: <421B516D.6040503@ieee.org> Message-ID: <20050222173222.4e561aa1.bugs.michael@gmx.net> On Tue, 22 Feb 2005 09:36:13 -0600, Quentin Spencer wrote: > My second question related to FFTW is why the Extras version is so old > (2.1.5), when version 3.0.1 has been out for nearly 2 years. Octave > supports only FFTW version 3. I recall freshrpms used to have a fftw3 > package but it has been dropped. Is there less interest in version 3? Brief look: ABI and API changes between 2.1.5 and the 3 series. Website says: The API of FFTW 3.x is incompatible with that of FFTW 2.x, for reasons of performance and generality (see the FAQ the manual). We encourage you to upgrade, but we still maintain version 2.1.5 for legacy users. MPI parallel transforms are still only available in 2.1.5. No immediate API users for the 3 series are included in Fedora Extras, but dependencies which still need the 2.x API. Hence no particular interest in creating a parallel-installable fftw3 package. Your package would be the first to require the new API. From sopwith at redhat.com Tue Feb 22 18:20:48 2005 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 22 Feb 2005 13:20:48 -0500 (EST) Subject: Octave add-on packages In-Reply-To: <421B516D.6040503@ieee.org> References: <421B516D.6040503@ieee.org> Message-ID: Quentin, would you be willing to maintain the octave package itself in FE? It's on my tentative list of things to remove from FC. I use the package myself so I want to make sure it gets maintained ;-) Cheers, -- Elliot From qspencer at ieee.org Tue Feb 22 18:52:29 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Tue, 22 Feb 2005 12:52:29 -0600 Subject: Octave add-on packages Message-ID: <421B7F6D.5080602@ieee.org> >Quentin, would you be willing to maintain the octave package itself in FE? >It's on my tentative list of things to remove from FC. I use the package >myself so I want to make sure it gets maintained ;-) Yes I could do that. I've been doing maitaining one for my own use for a long time anyway, and I follow the octave mailing lists closely. From qspencer at ieee.org Tue Feb 22 18:54:23 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Tue, 22 Feb 2005 12:54:23 -0600 Subject: Octave add-on packages Message-ID: <421B7FDF.7080703@ieee.org> >No immediate API users for the 3 series are included in Fedora Extras, but >dependencies which still need the 2.x API. Hence no particular interest in >creating a parallel-installable fftw3 package. Your package would be the >first to require the new API. OK, what about adding a separate fftw3 package? I'm aware of two versions that could be used as a starting point: fftw3 for FC1 on Freshrpms.net and there's also one in Dag Wieers repository. -Quentin From ken at bonsai.com Wed Feb 23 00:58:23 2005 From: ken at bonsai.com (Ken Sedgwick) Date: Tue, 22 Feb 2005 16:58:23 -0800 Subject: Sponsor needed for ACE+TAO package Message-ID: <421BD52F.408@bonsai.com> Greetings, I'm looking for a sponsor for the inclusion of the ACE+TAO libraries into Fedora Extras. Official ACE Site http://www.cs.wustl.edu/~schmidt/ACE.html Official TAO Site http://www.cs.wustl.edu/~schmidt/TAO.html My package site: http://dist.bonsai.com/ken/ace_tao_rpm/ Source RPM: http://dist.bonsai.com/ken/ace_tao_rpm/5.4.4-2.SRC/ace+tao-5.4.4-2.src.rpm There are no legal issues: http://www.cs.wustl.edu/~schmidt/ACE-copying.html I believe that the source rpm and generated packages meet the Fedora packaging guidelines as posted on the wiki. Ken -- Ken Sedgwick Bonsai Software, Inc. (510) 610-4162 ken+5a4 at bonsai.com From tcallawa at redhat.com Wed Feb 23 01:30:14 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 22 Feb 2005 19:30:14 -0600 Subject: Sponsor needed for ACE+TAO package In-Reply-To: <421BD52F.408@bonsai.com> References: <421BD52F.408@bonsai.com> Message-ID: <1109122214.13305.13.camel@localhost.localdomain> On Tue, 2005-02-22 at 16:58 -0800, Ken Sedgwick wrote: >Source RPM: >http://dist.bonsai.com/ken/ace_tao_rpm/5.4.4-2.SRC/ace+tao-5.4.4-2.src.rpm Could you please not use "+" characters in the rpm filenames? Its a minor complaint, to be sure, but there's no reason to have it. "acetao" or "ace-tao" is preferred. >There are no legal issues: >http://www.cs.wustl.edu/~schmidt/ACE-copying.html The ACE License is not an OSI approved license. The informal rule (soon to be a formal rule) is that all packages in Fedora Extras should have an OSI approved license. Now, IANAL, but I don't see anything in the license that would prevent it from receiving OSI approval. Its just so that we have our collective backside covered, and so that we don't have to examine all sorts of odd legal licenses. If we let this in, it sets bad precedent. Based on that, I think I'll have to NAK this request. Please submit the ACE license to OSI for approval (http://www.opensource.org/docs/certification_mark.php#approval) or approach the maintainer about dual licensing the source with an OSI approved license. ~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 ghenry at suretecsystems.com Wed Feb 23 11:06:27 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Wed, 23 Feb 2005 11:06:27 -0000 (GMT) Subject: Bluemote RPM http://freshmeat.net/projects/bluemote/ Message-ID: <43583.193.195.148.66.1109156787.squirrel@webmail.suretecsystems.com> Dear all, Would anyone like to see this in extras? http://freshmeat.net/projects/bluemote/ I will volunteer. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From dwmw2 at infradead.org Wed Feb 23 14:00:04 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 23 Feb 2005 14:00:04 +0000 Subject: Bluemote RPM http://freshmeat.net/projects/bluemote/ In-Reply-To: <43583.193.195.148.66.1109156787.squirrel@webmail.suretecsystems.com> References: <43583.193.195.148.66.1109156787.squirrel@webmail.suretecsystems.com> Message-ID: <1109167204.17808.22.camel@hades.cambridge.redhat.com> On Wed, 2005-02-23 at 11:06 +0000, Gavin Henry wrote: > > Would anyone like to see this in extras? > > http://freshmeat.net/projects/bluemote/ Yeah, looks good to me. -- dwmw2 From ghenry at suretecsystems.com Wed Feb 23 15:04:06 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Wed, 23 Feb 2005 15:04:06 -0000 (GMT) Subject: Orphaned Packages - where are the bugzilla pages located? Message-ID: <53136.193.195.148.66.1109171046.squirrel@webmail.suretecsystems.com> Dear all, From: http://fedoraproject.org/wiki/Extras/OrphanedPackages I would like to look after: librsync tidy rdiff-backup cpan2rpm john Who do I need to speak to to save these? -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From rdieter at math.unl.edu Wed Feb 23 15:12:27 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 23 Feb 2005 09:12:27 -0600 Subject: Orphaned Packages - where are the bugzilla pages located? In-Reply-To: <53136.193.195.148.66.1109171046.squirrel@webmail.suretecsystems.com> References: <53136.193.195.148.66.1109171046.squirrel@webmail.suretecsystems.com> Message-ID: <421C9D5B.7070003@math.unl.edu> Gavin Henry wrote: > http://fedoraproject.org/wiki/Extras/OrphanedPackages > tidy I've got dibs on tidy, unless you feel stongly about taking it, that is. -- Rex From ghenry at suretecsystems.com Wed Feb 23 15:21:48 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Wed, 23 Feb 2005 15:21:48 -0000 (GMT) Subject: Orphaned Packages - where are the bugzilla pages located? In-Reply-To: <421C9D5B.7070003@math.unl.edu> References: <53136.193.195.148.66.1109171046.squirrel@webmail.suretecsystems.com> <421C9D5B.7070003@math.unl.edu> Message-ID: <55586.193.195.148.66.1109172108.squirrel@webmail.suretecsystems.com> > Gavin Henry wrote: > >> http://fedoraproject.org/wiki/Extras/OrphanedPackages >> tidy > > I've got dibs on tidy, unless you feel stongly about taking it, that is. No, no go for it. Maybe we could add some names to the wiki to say who has taken/wants to take them? > -- Rex > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From rdieter at math.unl.edu Wed Feb 23 15:33:28 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 23 Feb 2005 09:33:28 -0600 Subject: Orphaned Packages - tidy In-Reply-To: <55586.193.195.148.66.1109172108.squirrel@webmail.suretecsystems.com> References: <53136.193.195.148.66.1109171046.squirrel@webmail.suretecsystems.com> <421C9D5B.7070003@math.unl.edu> <55586.193.195.148.66.1109172108.squirrel@webmail.suretecsystems.com> Message-ID: <421CA248.3050905@math.unl.edu> Gavin Henry wrote: > > >>Gavin Henry wrote: >> >> >>>http://fedoraproject.org/wiki/Extras/OrphanedPackages >>>tidy >> >>I've got dibs on tidy, unless you feel stongly about taking it, that is. > > > No, no go for it. > > Maybe we could add some names to the wiki to say who has taken/wants to > take them? I just dropped tidy from the Orphaned list. -- Rex From bdpepple at ameritech.net Wed Feb 23 15:40:56 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Wed, 23 Feb 2005 10:40:56 -0500 Subject: Updated Package: Gnome-Blog 0.8 Message-ID: <1109173256.5664.6.camel@shuttle.273piedmont.org> Package update for Gnome-Blog to 0.8, and fixes x86_64 build. http://piedmont.homelinux.org/fedora/gnome-blog-0.8-4.src.rpm http://piedmont.homelinux.org/fedora/fedora_md5sum 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 ghenry at suretecsystems.com Wed Feb 23 15:44:09 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Wed, 23 Feb 2005 15:44:09 -0000 (GMT) Subject: Orphaned Packages - tidy In-Reply-To: <421CA248.3050905@math.unl.edu> References: <53136.193.195.148.66.1109171046.squirrel@webmail.suretecsystems.com> <421C9D5B.7070003@math.unl.edu><55586.193.195.148.66.1109172108.squirrel@webmail.suretecsystems.com> <421CA248.3050905@math.unl.edu> Message-ID: <58889.193.195.148.66.1109173449.squirrel@webmail.suretecsystems.com> > Gavin Henry wrote: >> >> >>>Gavin Henry wrote: >>> >>> >>>>http://fedoraproject.org/wiki/Extras/OrphanedPackages >>>>tidy >>> >>>I've got dibs on tidy, unless you feel stongly about taking it, that is. >> >> >> No, no go for it. >> >> Maybe we could add some names to the wiki to say who has taken/wants to >> take them? > > I just dropped tidy from the Orphaned list. I saw that in the changes. Maybe you could add the names of the volunteers? > > > -- Rex > > -- > 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 Wed Feb 23 16:00:01 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 23 Feb 2005 17:00:01 +0100 Subject: Orphaned Packages - where are the bugzilla pages located? In-Reply-To: <53136.193.195.148.66.1109171046.squirrel@webmail.suretecsystems.com> References: <53136.193.195.148.66.1109171046.squirrel@webmail.suretecsystems.com> Message-ID: <20050223170001.59a36d43.bugs.michael@gmx.net> On Wed, 23 Feb 2005 15:04:06 -0000 (GMT), Gavin Henry wrote: > Dear all, > > From: > > http://fedoraproject.org/wiki/Extras/OrphanedPackages > > I would like to look after: > > librsync > tidy Has been taken over by Rex Dieter already according to the Wiki. > rdiff-backup > cpan2rpm > john > > Who do I need to speak to to save these? Due lack of formal process: Where the following list of component owners, https://bugzilla.redhat.com/bugzilla/describecomponents.cgi?product=Fedora%20Extras lists the e-mail address " extras-orphan AT fedoraproject.org ", just report back, state your bugzilla account e-mail address, and you can become the new owner. For "potentially orphaned packages", to be fair, try to contact the listed owner one last time, then after maybe 1-2 weeks feel free to report back and request ownership. cpan2rpm, john : orphaned librsync, rdiff-backup : are on the list because the owner, who has been involved upstream at librsync and is the upstream author for rdiff-backup, has not updated the rpms for a very long time and has not commented on bugzilla activity either. From bji-fedora at ischo.com Wed Feb 23 16:11:41 2005 From: bji-fedora at ischo.com (Bryan Ischo) Date: Wed, 23 Feb 2005 11:11:41 -0500 (EST) Subject: Creating new extras package for missing xorg-x11 programs Message-ID: <1705.66.65.160.16.1109175101.squirrel@mail.ischo.com> Hi all. After some discussion in bug 140214, and on the Fedora Users mailing list (fedora-list at redhat.com), I have decided to try to build a new extras package to supply some of the X11 utility programs which have been removed from the xorg-x11 package. These programs include some very small and probably not-frequently-used programs: xbiff, xditview, and xeyes. Mostly I am concerned about xbiff, but I thought I'd include the other programs since they are so small, so that no one else who wants them will have to go through the trouble of building their own extras RPM for them. Technically these programs are a part of the X.org software release but the Fedora developers have decided to remove them from the base package, because their functionality is apparently redundant with some other programs available in Fedora Core (but not from my perspective as there is no program that does exactly what xbiff does for my purposes). Because there has been some suggestion that the X.org team is reorganizing the base X11 distribution for the R7 release, it seems that any SPEC file that I make now will likely be completely obsoleted at that time. For this reason I want to do the simplest, easiest thing necessary to build a spec file for these programs. Once the X.org team has reorganized their source tree into a format which is not expected to change in the near future, I'll do the extra work of making a spec file which is clean and neat. For the time being, I'm thinking of just taking the existing xorg-x11 spec file and modifying it for the purposes of creating an rpm that installs just the three programs I have mentioned. The X.org makefile system is quite complicated and I am not sure it will be worth the trouble to investigate trying to build just these programs when compiling the rpm from the source rpm. The existing xorg-x11 spec file seems to take the same approach; it lets the X.org makefiles do their thing and then as a post-processing step removes the built files that it doesn't want to install. I'd do something similar, using the xorg-x11 spec file as a base. Does this sound like a reasonable approach? What should I name this spec file/rpm? Thanks, and best wishes, Bryan ------------------------------------------------------------------------ Bryan Ischo bryan at ischo.com N, R, 6 New York, NY, USA http://www.ischo.com RedHat Linux 9 ------------------------------------------------------------------------ From funkyres at gmail.com Wed Feb 23 15:46:53 2005 From: funkyres at gmail.com (Michael Peters) Date: Wed, 23 Feb 2005 07:46:53 -0800 Subject: Package Requests Message-ID: <485bb88405022307464a76e9e8@mail.gmail.com> I have some packages I would like to request maintainers for. The first is gourmet - it is a Python/Gtk2+ recipe manager, I have been using it with success, although it does crash when attempting to print. It has one dependency not currently in Fedora or Fedora Extras - PyRTF The Gourmet homepage is http://grecipe-manager.sourceforge.net/ I already have src.rpm's - though they probably need some polish. http://mpeters.us/yum/fedora/3/SRPMS/PyRTF-0.43-0.yjl.1.fc3.src.rpm http://mpeters.us/yum/fedora/3/SRPMS/gourmet-0.7.1-0.yjl.1.3.fc3.src.rpm The other is Alexandria - a library cataloguing app done with ruby. It has a large list of dependencies (mostly ruby related) not in Extras, I'm still working on getting those resolved and building on my box. The version of Alexandria in CVS is supposedly much improved over the current release version, so that might be better to wait until next release - homepage is http://alexandria.rubyforge.org/ This weekend I'll try to get it all working on my system. I believe Mandrake Cooker has src.rpm's that may aide in that. -=- I don't wish to maintain them, I'm not particularly skilled in either Python or Ruby, and if I was, I do do not have the time to deal with bugs anyway. But I'm hoping that if I provide src.rpm's that someone else might be willing to start with those and maintain them, and I'm certainly willing to provide bugzilla feedback and testing. Both of these applications are apps that are good for LOTD - which is my passion (Penguins for the Masses) -=- My src.rpm's are signed - http://pgp.mit.edu:11371/pks/lookup?search=buildmaster%40mpeters.us&op=index and http://mpeters.us/YJL_GPG-KEY -- http://mpeters.us/ From ghenry at suretecsystems.com Wed Feb 23 16:29:17 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Wed, 23 Feb 2005 16:29:17 -0000 (GMT) Subject: netmon_applet Message-ID: <65458.193.195.148.66.1109176157.squirrel@webmail.suretecsystems.com> Dear all, I made this rpm for fedora core 1 and I would like to update it for FC3/FC4: http://www.demonseed.net/~jp/code/netmon_applet/ RPMS etc: http://www.demonseed.net/~jp/code/netmon_applet/rpm/ I know Gnome comes with network applets already, but I really like this one and only use this one. Thoughts? -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From ken at bonsai.com Wed Feb 23 16:38:59 2005 From: ken at bonsai.com (Ken Sedgwick) Date: Wed, 23 Feb 2005 08:38:59 -0800 Subject: Sponsor needed for ACE+TAO package In-Reply-To: <1109122214.13305.13.camel@localhost.localdomain> References: <421BD52F.408@bonsai.com> <1109122214.13305.13.camel@localhost.localdomain> Message-ID: <421CB1A3.3080406@bonsai.com> Tom 'spot' Callaway wrote: > On Tue, 2005-02-22 at 16:58 -0800, Ken Sedgwick wrote: > > >>Source RPM: >>http://dist.bonsai.com/ken/ace_tao_rpm/5.4.4-2.SRC/ace+tao-5.4.4-2.src.rpm > > > Could you please not use "+" characters in the rpm filenames? Its a > minor complaint, to be sure, but there's no reason to have it. "acetao" > or "ace-tao" is preferred. Will do. > Based on that, I think I'll have to NAK this request. Please submit the > ACE license to OSI for approval > (http://www.opensource.org/docs/certification_mark.php#approval) or > approach the maintainer about dual licensing the source with an OSI > approved license. Will do. Ken -- Ken Sedgwick Bonsai Software, Inc. (510) 610-4162 ken+5a4 at bonsai.com From tcallawa at redhat.com Wed Feb 23 16:45:01 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 23 Feb 2005 10:45:01 -0600 Subject: netmon_applet In-Reply-To: <65458.193.195.148.66.1109176157.squirrel@webmail.suretecsystems.com> References: <65458.193.195.148.66.1109176157.squirrel@webmail.suretecsystems.com> Message-ID: <1109177101.13305.50.camel@localhost.localdomain> On Wed, 2005-02-23 at 16:29 +0000, Gavin Henry wrote: >RPMS etc: > >http://www.demonseed.net/~jp/code/netmon_applet/rpm/ I'm just now writing the naming standards for rpm, and there are already two "do not do XXX" items in your package. (Not your fault, I can't write these standards fast enough to keep up with new packages) - Don't use underscores in the rpm name. Use - as a delimiter. - If it relies on another application to function (in this case, an applet for gnome that requires the gnome panel), it should be named according to the "%{parent}-%{child} syntax. So, based on that, I would suggest that it be renamed to: gnome-applet-netmon Also, when you rename it, you'll want to add: Provides: netmon_applet Obsoletes: netmon_applet That way, users of the old package will have a clean upgrade path. Looking into the package, you don't need to be packaging ABOUT-NLS, COPYING, or INSTALL, since they're all the generic docs. (Also, I'm not sure why ABOUT-NLS is in there, since the applet doesn't seem to be translated). Take the 0.fdr out of the version tag, not necessary for Fedora Extras. Besides all that, it looks good to me. ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From mike at flyn.org Wed Feb 23 16:53:52 2005 From: mike at flyn.org (W. Michael Petullo) Date: Wed, 23 Feb 2005 10:53:52 -0600 (CST) Subject: netmon_applet In-Reply-To: <1109177101.13305.50.camel@localhost.localdomain> References: <65458.193.195.148.66.1109176157.squirrel@webmail.suretecsystems.com> <1109177101.13305.50.camel@localhost.localdomain> Message-ID: <19537.66.151.13.191.1109177632.squirrel@zero.voxel.net> > I'm just now writing the naming standards for rpm, and there are already > two "do not do XXX" items in your package. (Not your fault, I can't > write these standards fast enough to keep up with new packages) > > - Don't use underscores in the rpm name. Use - as a delimiter. pam_ccreds-1-4.ppc.rpm pam_ccreds-1-4.ppc64.rpm pam_krb5-2.1.2-1.ppc.rpm pam_krb5-2.1.2-1.ppc64.rpm pam_passwdqc-0.7.5-2.ppc.rpm pam_passwdqc-0.7.5-2.ppc64.rpm pam_smb-1.1.7-5.ppc.rpm pam_smb-1.1.7-5.ppc64.rpm Will these core packages be renamed? This convention has been used by Red Hat's PAM module packages for as long as I can remember. There are also many more examples of the '_' character in Fedora Core. -- Mike From ghenry at suretecsystems.com Wed Feb 23 16:56:34 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Wed, 23 Feb 2005 16:56:34 -0000 (GMT) Subject: netmon_applet In-Reply-To: <1109177101.13305.50.camel@localhost.localdomain> References: <65458.193.195.148.66.1109176157.squirrel@webmail.suretecsystems.com> <1109177101.13305.50.camel@localhost.localdomain> Message-ID: <35229.193.195.148.66.1109177794.squirrel@webmail.suretecsystems.com> > On Wed, 2005-02-23 at 16:29 +0000, Gavin Henry wrote: > >>RPMS etc: >> >>http://www.demonseed.net/~jp/code/netmon_applet/rpm/ > > I'm just now writing the naming standards for rpm, and there are already > two "do not do XXX" items in your package. (Not your fault, I can't > write these standards fast enough to keep up with new packages) This was my first ever RPM ;-) OK. Do you have a draft anywhere, as I keep having to refer to the old fedora.us guides. > > - Don't use underscores in the rpm name. Use - as a delimiter. > - If it relies on another application to function (in this case, an > applet for gnome that requires the gnome panel), it should be named > according to the "%{parent}-%{child} syntax. > > So, based on that, I would suggest that it be renamed to: > > gnome-applet-netmon Fine. Do I need to get the authors permission to change his prpgrams name? As this indicates that it was authored by the gnome team, no? > > Also, when you rename it, you'll want to add: > > Provides: netmon_applet > Obsoletes: netmon_applet > > That way, users of the old package will have a clean upgrade path. So this tells RPM that it IS still really netmon_applet, but will be called gnome-applet-netmon. > > Looking into the package, you don't need to be packaging ABOUT-NLS, > COPYING, or INSTALL, since they're all the generic docs. (Also, I'm not > sure why ABOUT-NLS is in there, since the applet doesn't seem to be > translated). I first added those so RPM didn't complain about left over files. > > Take the 0.fdr out of the version tag, not necessary for Fedora Extras. So it would just be called gnome-applet-netmon? What do I do with the Release tag? > Besides all that, it looks good to me. Where do I create a new bugzilla entry for this, as it is actaully still in the fedora.us bugzilla? From tcallawa at redhat.com Wed Feb 23 16:59:08 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 23 Feb 2005 10:59:08 -0600 Subject: netmon_applet In-Reply-To: <19537.66.151.13.191.1109177632.squirrel@zero.voxel.net> References: <65458.193.195.148.66.1109176157.squirrel@webmail.suretecsystems.com> <1109177101.13305.50.camel@localhost.localdomain> <19537.66.151.13.191.1109177632.squirrel@zero.voxel.net> Message-ID: <1109177948.13305.54.camel@localhost.localdomain> On Wed, 2005-02-23 at 10:53 -0600, W. Michael Petullo wrote: >> I'm just now writing the naming standards for rpm, and there are already >> two "do not do XXX" items in your package. (Not your fault, I can't >> write these standards fast enough to keep up with new packages) >> >> - Don't use underscores in the rpm name. Use - as a delimiter. > >pam_ccreds-1-4.ppc.rpm >pam_ccreds-1-4.ppc64.rpm >pam_krb5-2.1.2-1.ppc.rpm >pam_krb5-2.1.2-1.ppc64.rpm >pam_passwdqc-0.7.5-2.ppc.rpm >pam_passwdqc-0.7.5-2.ppc64.rpm >pam_smb-1.1.7-5.ppc.rpm >pam_smb-1.1.7-5.ppc64.rpm > >Will these core packages be renamed? This convention has been used by Red >Hat's PAM module packages for as long as I can remember. There are also >many more examples of the '_' character in Fedora Core. SDL does the same thing. I'm writing exceptions to the rule in the standards documentation. ~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 rdieter at math.unl.edu Wed Feb 23 17:06:12 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 23 Feb 2005 11:06:12 -0600 Subject: netmon_applet In-Reply-To: <1109177101.13305.50.camel@localhost.localdomain> References: <65458.193.195.148.66.1109176157.squirrel@webmail.suretecsystems.com> <1109177101.13305.50.camel@localhost.localdomain> Message-ID: <421CB804.7060607@math.unl.edu> Tom 'spot' Callaway wrote: ... > So, based on that, I would suggest that it be renamed to: > gnome-applet-netmon > Also, when you rename it, you'll want to add: > Provides: netmon_applet > Obsoletes: netmon_applet FYI, you only need the Provides, thanks to a recent rpm bug^?^?^? feature where Provides do an implicit Obsoletes: http://bugzilla.redhat.com/111071 -- rex From rdieter at math.unl.edu Wed Feb 23 17:07:54 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 23 Feb 2005 11:07:54 -0600 Subject: netmon_applet In-Reply-To: <19537.66.151.13.191.1109177632.squirrel@zero.voxel.net> References: <65458.193.195.148.66.1109176157.squirrel@webmail.suretecsystems.com> <1109177101.13305.50.camel@localhost.localdomain> <19537.66.151.13.191.1109177632.squirrel@zero.voxel.net> Message-ID: <421CB86A.1050300@math.unl.edu> W. Michael Petullo wrote: >>I'm just now writing the naming standards for rpm, and there are already >>two "do not do XXX" items in your package. (Not your fault, I can't >>write these standards fast enough to keep up with new packages) >> >>- Don't use underscores in the rpm name. Use - as a delimiter. > > > pam_ccreds-1-4.ppc.rpm > pam_ccreds-1-4.ppc64.rpm > pam_krb5-2.1.2-1.ppc.rpm > pam_krb5-2.1.2-1.ppc64.rpm > pam_passwdqc-0.7.5-2.ppc.rpm > pam_passwdqc-0.7.5-2.ppc64.rpm > pam_smb-1.1.7-5.ppc.rpm > pam_smb-1.1.7-5.ppc64.rpm > > Will these core packages be renamed? This convention has been used by Red > Hat's PAM module packages for as long as I can remember. There are also > many more examples of the '_' character in Fedora Core. Most(some?) of these are simply following the upstream package name (which is OK, IMO). -- Rex From tcallawa at redhat.com Wed Feb 23 17:11:44 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 23 Feb 2005 11:11:44 -0600 Subject: netmon_applet In-Reply-To: <35229.193.195.148.66.1109177794.squirrel@webmail.suretecsystems.com> References: <65458.193.195.148.66.1109176157.squirrel@webmail.suretecsystems.com> <1109177101.13305.50.camel@localhost.localdomain> <35229.193.195.148.66.1109177794.squirrel@webmail.suretecsystems.com> Message-ID: <1109178705.13305.63.camel@localhost.localdomain> On Wed, 2005-02-23 at 16:56 +0000, Gavin Henry wrote: > >> On Wed, 2005-02-23 at 16:29 +0000, Gavin Henry wrote: >> >>>RPMS etc: >>> >>>http://www.demonseed.net/~jp/code/netmon_applet/rpm/ >> >> I'm just now writing the naming standards for rpm, and there are already >> two "do not do XXX" items in your package. (Not your fault, I can't >> write these standards fast enough to keep up with new packages) > >This was my first ever RPM ;-) > >OK. Do you have a draft anywhere, as I keep having to refer to the old >fedora.us guides. Not yet. :) I'm writing as fast as I can, but its too scattered for me to publish yet. >Fine. Do I need to get the authors permission to change his prpgrams name? You're not changing his program name, just the name of the rpm it is packaged in. You can use %setup -q -n netmon_applet-%{version} instead of just %setup -q to achieve this. >As this indicates that it was authored by the gnome team, no? Nope, it just indicates that its a gnome-applet. >So this tells RPM that it IS still really netmon_applet, but will be >called gnome-applet-netmon. Mostly, it just tells yum that it is also netmon_applet, so that users who have netmon_applet-0.4-1 installed will get gnome-applet-netmon-0.4-2 as an upgrade. >> Looking into the package, you don't need to be packaging ABOUT-NLS, >> COPYING, or INSTALL, since they're all the generic docs. (Also, I'm not >> sure why ABOUT-NLS is in there, since the applet doesn't seem to be >> translated). > >I first added those so RPM didn't complain about left over files. Doesn't complain on my side without them. :) >> >> Take the 0.fdr out of the version tag, not necessary for Fedora Extras. > >So it would just be called gnome-applet-netmon? What do I do with the >Release tag? The Release tag would simply be the build number for that package, incremented everytime you make a change, and reset to 1 with every new version of the software. So, for you, it would be: Release: 2 >> Besides all that, it looks good to me. > >Where do I create a new bugzilla entry for this, as it is actaully still >in the fedora.us bugzilla? The fedora.us bugzilla is probably a good place to put it right now, unless we're switching to bugzilla.redhat.com for this (waits for someone in charge of bugzilla to speak up). ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Wed Feb 23 17:13:15 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 23 Feb 2005 11:13:15 -0600 Subject: netmon_applet In-Reply-To: <421CB86A.1050300@math.unl.edu> References: <65458.193.195.148.66.1109176157.squirrel@webmail.suretecsystems.com> <1109177101.13305.50.camel@localhost.localdomain> <19537.66.151.13.191.1109177632.squirrel@zero.voxel.net> <421CB86A.1050300@math.unl.edu> Message-ID: <1109178795.13305.65.camel@localhost.localdomain> On Wed, 2005-02-23 at 11:07 -0600, Rex Dieter wrote: >Most(some?) of these are simply following the upstream package name >(which is OK, IMO). pam and SDL are definitely following an upstream naming policy, but in lieu of an established policy, there shouldn't be underscores in %{name}. They're the exceptions, not the rule. ~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 Feb 23 17:18:25 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 23 Feb 2005 11:18:25 -0600 Subject: netmon_applet In-Reply-To: <1109178705.13305.63.camel@localhost.localdomain> References: <65458.193.195.148.66.1109176157.squirrel@webmail.suretecsystems.com> <1109177101.13305.50.camel@localhost.localdomain> <35229.193.195.148.66.1109177794.squirrel@webmail.suretecsystems.com> <1109178705.13305.63.camel@localhost.localdomain> Message-ID: <1109179105.13305.67.camel@localhost.localdomain> >>> Looking into the package, you don't need to be packaging ABOUT-NLS, >>> COPYING, or INSTALL, since they're all the generic docs. (Also, I'm not >>> sure why ABOUT-NLS is in there, since the applet doesn't seem to be >>> translated). Replying to myself, keeping "COPYING" in there is fine, since it may be needed for GPL compliance. (I don't want the FSF on my case.) ~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 Wed Feb 23 18:00:18 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 23 Feb 2005 19:00:18 +0100 Subject: netmon_applet In-Reply-To: <1109178795.13305.65.camel@localhost.localdomain> References: <65458.193.195.148.66.1109176157.squirrel@webmail.suretecsystems.com> <1109177101.13305.50.camel@localhost.localdomain> <19537.66.151.13.191.1109177632.squirrel@zero.voxel.net> <421CB86A.1050300@math.unl.edu> <1109178795.13305.65.camel@localhost.localdomain> Message-ID: <1109181618.3076.2.camel@rousalka.dyndns.org> Le mercredi 23 f?vrier 2005 ? 11:13 -0600, Tom 'spot' Callaway a ?crit : >On Wed, 2005-02-23 at 11:07 -0600, Rex Dieter wrote: > >>Most(some?) of these are simply following the upstream package name >>(which is OK, IMO). > >pam and SDL are definitely following an upstream naming policy, but in >lieu of an established policy, there shouldn't be underscores in >%{name}. > They're the exceptions, not the rule. Well, you can define your established policy as "follow upstream naming and don't be creative". Lots of people and projects just do that (don't you hate spec files starting with several defines just to track all the variations on a common naming a project might use ?) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From tcallawa at redhat.com Wed Feb 23 18:07:13 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 23 Feb 2005 12:07:13 -0600 Subject: netmon_applet In-Reply-To: <1109181618.3076.2.camel@rousalka.dyndns.org> References: <65458.193.195.148.66.1109176157.squirrel@webmail.suretecsystems.com> <1109177101.13305.50.camel@localhost.localdomain> <19537.66.151.13.191.1109177632.squirrel@zero.voxel.net> <421CB86A.1050300@math.unl.edu> <1109178795.13305.65.camel@localhost.localdomain> <1109181618.3076.2.camel@rousalka.dyndns.org> Message-ID: <1109182034.13305.87.camel@localhost.localdomain> On Wed, 2005-02-23 at 19:00 +0100, Nicolas Mailhot wrote: >Well, you can define your established policy as "follow upstream naming >and don't be creative". Lots of people and projects just do that (don't >you hate spec files starting with several defines just to track all the >variations on a common naming a project might use ?) Agreed, but I think I'm going to go a step farther and say "Don't use underscores in %{name}". There will be exceptions, and I'm not trying to offend any upstream owners, but the naming is just cleaner if we only use "-" as a delimiter. ~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 ghenry at suretecsystems.com Wed Feb 23 20:13:20 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Wed, 23 Feb 2005 20:13:20 +0000 Subject: netmon_applet In-Reply-To: <1109179105.13305.67.camel@localhost.localdomain> References: <65458.193.195.148.66.1109176157.squirrel@webmail.suretecsystems.com> <1109178705.13305.63.camel@localhost.localdomain> <1109179105.13305.67.camel@localhost.localdomain> Message-ID: <200502232013.24077.ghenry@suretecsystems.com> On Wednesday 23 Feb 2005 17:18, Tom 'spot' Callaway wrote: > >>> Looking into the package, you don't need to be packaging ABOUT-NLS, > >>> COPYING, or INSTALL, since they're all the generic docs. (Also, I'm not > >>> sure why ABOUT-NLS is in there, since the applet doesn't seem to be > >>> translated). > > Replying to myself, keeping "COPYING" in there is fine, since it may be > needed for GPL compliance. (I don't want the FSF on my case.) > Rebuilt for FC3 and submitted here: https://bugzilla.fedora.us/show_bug.cgi?id=2439 -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pmmm at rnl.ist.utl.pt Thu Feb 24 00:28:24 2005 From: pmmm at rnl.ist.utl.pt (Pedro Morais) Date: Thu, 24 Feb 2005 00:28:24 +0000 Subject: Request for package inclusion: gettext lint tools In-Reply-To: <200502161005.33483.pmmm@rnl.ist.utl.pt> References: <200502161005.33483.pmmm@rnl.ist.utl.pt> Message-ID: <200502240028.24402.pmmm@rnl.ist.utl.pt> Just pinging the list again... Anyone interested? > Hi! > I'm the author of this set of tools for translators and would be willing to > maintain the package in Fedora Extras. > It's already been included in the FreeBSD ports system and Mandrake's > cooker contrib. > > The gettext lint tools is a collection of tools for checking the validity, > consistency and spelling of PO and POT files. It also includes an > experimental glossary building tool. > > It's distributed under the GPL. > > Homepage: > http://gettext-lint.sourceforge.net/ > > Source rpm and source tarball: > http://sourceforge.net/project/showfiles.php?group_id=122521 > > The RPMs in that page were build using FC2, also tested in in RHL9. > > Thanks for your comments, > Pedro Morais > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list -- Pedro Morais - morais at kde.org - http://www.rnl.ist.utl.pt/~pmmm/ From rkearey at redhat.com Thu Feb 24 03:37:47 2005 From: rkearey at redhat.com (Rob Kearey) Date: Thu, 24 Feb 2005 13:37:47 +1000 Subject: Mozilla Sunbird? Message-ID: <421D4C0B.20805@redhat.com> How hard would it be to package this up for extras inclusion? I had a look at using the firefox or thunderbird specfiles, but they're full of mystery and voodoo and so on. -- Rob Kearey Website: http://apac.redhat.com Red Hat Asia-Pacific Legal: http://apac.redhat.com/disclaimer +61 7 3514 8102 Stuff: http://people.redhat.com/rkearey From skvidal at fedoraproject.org Thu Feb 24 08:02:25 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 24 Feb 2005 03:02:25 -0500 Subject: Fedora Extras Package Updates Message-ID: <1109232145.10915.69.camel@cutter> Hi Everyone, advancecomp (i386, x86_64) lighttpd (i386, x86_64) - initial build putty (i386, x86_64) - security fix pybliographer (noarch) uim (i386, x86_64) - security fix Follow updates and new packages at: http://fedoraproject.org/infofeed/ Fedora Extras 3 Package RSS Feed: http://fedoraproject.org/infofeed/inputs/fc3-extras.xml Extras info: http://fedoraproject.org/wiki/Extras Status page: http://fedoraproject.org/wiki/Extras/FC3Status Report problems at Bugzilla: http://bugzilla.redhat.com/ thanks, -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ghenry at suretecsystems.com Thu Feb 24 08:06:01 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Thu, 24 Feb 2005 08:06:01 +0000 Subject: Nice one Tom! - http://fedoraproject.org/wiki/PackageNamingGuidelines Message-ID: <200502240806.09645.ghenry@suretecsystems.com> True to your word! http://fedoraproject.org/wiki/PackageNamingGuidelines Reading now. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Thu Feb 24 08:13:53 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 24 Feb 2005 09:13:53 +0100 Subject: Nice one Tom! - http://fedoraproject.org/wiki/PackageNamingGuidelines In-Reply-To: <200502240806.09645.ghenry@suretecsystems.com> References: <200502240806.09645.ghenry@suretecsystems.com> Message-ID: <20050224091353.16661fac.bugs.michael@gmx.net> On Thu, 24 Feb 2005 08:06:01 +0000, Gavin Henry wrote: > True to your word! > > http://fedoraproject.org/wiki/PackageNamingGuidelines The fedora.us versioning scheme for pre-releases and snapshots would be a worthy addition. The following page does also exist according to the wiki changelog: http://fedoraproject.org/wiki/PackagingGuidelines When it's made public and linked on the Extras page, the old PackagingHints page can go, as it seems to be included. From pmatilai at welho.com Thu Feb 24 08:18:04 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 24 Feb 2005 10:18:04 +0200 (EET) Subject: Nice one Tom! - http://fedoraproject.org/wiki/PackageNamingGuidelines In-Reply-To: <20050224091353.16661fac.bugs.michael@gmx.net> References: <200502240806.09645.ghenry@suretecsystems.com> <20050224091353.16661fac.bugs.michael@gmx.net> Message-ID: On Thu, 24 Feb 2005, Michael Schwendt wrote: > On Thu, 24 Feb 2005 08:06:01 +0000, Gavin Henry wrote: > >> True to your word! >> >> http://fedoraproject.org/wiki/PackageNamingGuidelines > > The fedora.us versioning scheme for pre-releases and snapshots would > be a worthy addition. The pre-releases *are* covered there, see "Non-numeric version in release" section. Snapshot aren't, however... - Panu - From bugs.michael at gmx.net Thu Feb 24 08:47:35 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 24 Feb 2005 09:47:35 +0100 Subject: Nice one Tom! - http://fedoraproject.org/wiki/PackageNamingGuidelines In-Reply-To: References: <200502240806.09645.ghenry@suretecsystems.com> <20050224091353.16661fac.bugs.michael@gmx.net> Message-ID: <20050224094735.13f2bfee.bugs.michael@gmx.net> On Thu, 24 Feb 2005 10:18:04 +0200 (EET), Panu Matilainen wrote: > On Thu, 24 Feb 2005, Michael Schwendt wrote: > > > On Thu, 24 Feb 2005 08:06:01 +0000, Gavin Henry wrote: > > > >> True to your word! > >> > >> http://fedoraproject.org/wiki/PackageNamingGuidelines > > > > The fedora.us versioning scheme for pre-releases and snapshots would > > be a worthy addition. > > The pre-releases *are* covered there, see "Non-numeric version in release" > section. Snapshot aren't, however... Ah, sorry. Should have reloaded it when I sent above mail. Last night I read the document while it was being edited, says the page changelog. From adrian at lisas.de Thu Feb 24 11:03:55 2005 From: adrian at lisas.de (Adrian Reber) Date: Thu, 24 Feb 2005 12:03:55 +0100 Subject: Package proposal: vnstat Message-ID: <20050224110355.GA30936@lisas.de> vnstat: A console-based network traffic monitor http://lisas.de/~adrian/rpm/vnstat-1.4-1.src.rpm http://humdi.net/vnstat/ $ vnstat -q Database updated: Thu Feb 24 12:00:01 2005 eth0 received: 8,773,946 MB (6.3%) transmitted: 129,418,731 MB (93.7%) total: 138,192,678 MB rx | tx | total -----------------------+------------+----------- yesterday 50,914 MB | 588,637 MB | 639,552 MB today 25,764 MB | 298,756 MB | 324,521 MB -----------------------+------------+----------- estimated 51,385 MB | 595,856 MB | 647,241 MB Adrian From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 24 11:55:41 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 24 Feb 2005 12:55:41 +0100 Subject: Package proposal: vnstat In-Reply-To: <20050224110355.GA30936@lisas.de> References: <20050224110355.GA30936@lisas.de> Message-ID: <20050224125541.0404302e@python2> Adrian Reber wrote : > vnstat: A console-based network traffic monitor > > http://lisas.de/~adrian/rpm/vnstat-1.4-1.src.rpm > > http://humdi.net/vnstat/ Looks good to me, just a few minor comments : - Would you mind dropping the "# -------- ..." lines from the spec? - Do you prefer having the version hardcoded in the source line? - I'd remove the leading "A" from the summary "A console-based...". - I'd remove the "In short," from the description. - It's not technically a daemon, so "System Environment/Daemons" doesn't seem the most appropriate group. Also, maybe have the cron entry use a sysconfig file with a list of interfaces to watch (defaulting to only eth0) would be a good idea? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 0.50 0.80 0.99 From adrian at lisas.de Thu Feb 24 12:58:06 2005 From: adrian at lisas.de (Adrian Reber) Date: Thu, 24 Feb 2005 13:58:06 +0100 Subject: Package proposal: vnstat In-Reply-To: <20050224125541.0404302e@python2> References: <20050224110355.GA30936@lisas.de> <20050224125541.0404302e@python2> Message-ID: <20050224125806.GA17362@lisas.de> On Thu, Feb 24, 2005 at 12:55:41PM +0100, Matthias Saou wrote: > > vnstat: A console-based network traffic monitor > > > > http://lisas.de/~adrian/rpm/vnstat-1.4-1.src.rpm > > > > http://humdi.net/vnstat/ > > Looks good to me, just a few minor comments : > > - Would you mind dropping the "# -------- ..." lines from the spec? No problem and already dropped. > - Do you prefer having the version hardcoded in the source line? Yes. > - I'd remove the leading "A" from the summary "A console-based...". Removed a A > - I'd remove the "In short," from the description. Removed a "In short," > - It's not technically a daemon, so "System Environment/Daemons" > doesn't seem the most appropriate group. Of course you are correct, but where to put is else :-) I could put in the "Applications/Internet" group but I think that it would be better in one of the "System Environment" groups. As it is neither Base, Kernel, Libraries nor Shells I thought the best would be the Daemons group. But if you have a better idea... Just say it. > Also, maybe have the cron entry use a sysconfig file with a list of > interfaces to watch (defaulting to only eth0) would be a good idea? Haven't really thought about this but to make it configurable I marked the cron entry file %config(noreplace). Can I read a config file from sysconfig easily in a cron script like I can read it in a startup script or would it require to call a script from the crontab which reads the config and starts vnstat? Adrian From qspencer at ieee.org Thu Feb 24 15:26:22 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 24 Feb 2005 09:26:22 -0600 Subject: specfile questions Message-ID: <421DF21E.6050208@ieee.org> I'm preparing a package for octave-forge, which I asked about a couple of days ago, and I have a question about spec files. Octave-forge is closely tied to the version of octave that is installed on the system, so the Requires: part of the spec file should list a specific version. It would be nice to have a single SRPM that could build on multiple versions of Fedora, which may have different versions of octave installed. Is there a way to do "Requires: octave = "? Quentin From cra at WPI.EDU Thu Feb 24 15:28:19 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Thu, 24 Feb 2005 10:28:19 -0500 Subject: specfile questions In-Reply-To: <421DF21E.6050208@ieee.org> References: <421DF21E.6050208@ieee.org> Message-ID: <20050224152819.GA19139@angus.ind.WPI.EDU> On Thu, Feb 24, 2005 at 09:26:22AM -0600, Quentin Spencer wrote: > I'm preparing a package for octave-forge, which I asked about a couple > of days ago, and I have a question about spec files. Octave-forge is > closely tied to the version of octave that is installed on the system, > so the Requires: part of the spec file should list a specific version. > It would be nice to have a single SRPM that could build on multiple > versions of Fedora, which may have different versions of octave > installed. Is there a way to do "Requires: octave = installed right now>"? How is the package tied to the specific installed version? Through dynamically linked libraries? If so, don't put any Requires: at all, just let rpm find the requirements automatically. From rdieter at math.unl.edu Thu Feb 24 15:29:27 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 24 Feb 2005 09:29:27 -0600 Subject: specfile questions In-Reply-To: <421DF21E.6050208@ieee.org> References: <421DF21E.6050208@ieee.org> Message-ID: <421DF2D7.6020601@math.unl.edu> Quentin Spencer wrote: > I'm preparing a package for octave-forge, which I asked about a couple > of days ago, and I have a question about spec files. Octave-forge is > closely tied to the version of octave that is installed on the system, > so the Requires: part of the spec file should list a specific version. > It would be nice to have a single SRPM that could build on multiple > versions of Fedora, which may have different versions of octave > installed. Is there a way to do "Requires: octave = installed right now>"? Yep. %define octave_ver %(rpm -q --qf '%%{version}' octave ) Requires: octave = %{octave_ver} -- Rex From rdieter at math.unl.edu Thu Feb 24 15:30:31 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 24 Feb 2005 09:30:31 -0600 Subject: specfile questions In-Reply-To: <421DF2D7.6020601@math.unl.edu> References: <421DF21E.6050208@ieee.org> <421DF2D7.6020601@math.unl.edu> Message-ID: <421DF317.3050508@math.unl.edu> Rex Dieter wrote: > Quentin Spencer wrote: > >> I'm preparing a package for octave-forge, which I asked about a couple >> of days ago, and I have a question about spec files. Octave-forge is >> closely tied to the version of octave that is installed on the system, >> so the Requires: part of the spec file should list a specific version. >> It would be nice to have a single SRPM that could build on multiple >> versions of Fedora, which may have different versions of octave >> installed. Is there a way to do "Requires: octave = > installed right now>"? > > > Yep. > %define octave_ver %(rpm -q --qf '%%{version}' octave ) > Requires: octave = %{octave_ver} Oops, I forgot BuildRequires: octave -- Rex From qspencer at ieee.org Thu Feb 24 15:34:02 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 24 Feb 2005 09:34:02 -0600 Subject: specfile questions In-Reply-To: <20050224152819.GA19139@angus.ind.WPI.EDU> References: <421DF21E.6050208@ieee.org> <20050224152819.GA19139@angus.ind.WPI.EDU> Message-ID: <421DF3EA.2020908@ieee.org> Chuck R. Anderson wrote: >On Thu, Feb 24, 2005 at 09:26:22AM -0600, Quentin Spencer wrote: > > >>I'm preparing a package for octave-forge, which I asked about a couple >>of days ago, and I have a question about spec files. Octave-forge is >>closely tied to the version of octave that is installed on the system, >>so the Requires: part of the spec file should list a specific version. >>It would be nice to have a single SRPM that could build on multiple >>versions of Fedora, which may have different versions of octave >>installed. Is there a way to do "Requires: octave = >installed right now>"? >> >> > >How is the package tied to the specific installed version? Through >dynamically linked libraries? If so, don't put any Requires: at all, >just let rpm find the requirements automatically. > > It installs in a directory tree that contains octave's version in the name, and it contains some binary loadable modules for octave, and the ABI can change from one version to another. From rdieter at math.unl.edu Thu Feb 24 15:45:46 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 24 Feb 2005 09:45:46 -0600 Subject: specfile questions In-Reply-To: <421DF3EA.2020908@ieee.org> References: <421DF21E.6050208@ieee.org> <20050224152819.GA19139@angus.ind.WPI.EDU> <421DF3EA.2020908@ieee.org> Message-ID: <421DF6AA.8000401@math.unl.edu> Quentin Spencer wrote: > Chuck R. Anderson wrote: >> How is the package tied to the specific installed version? Through >> dynamically linked libraries? If so, don't put any Requires: at all, >> just let rpm find the requirements automatically. >> >> > It installs in a directory tree that contains octave's version in the > name, And/or you can 'Require' that directory, something like: Requires: %%_datadir/octave-%{octave_ver} And/or the octave maintainer to make people's lives simpler, can put something in octave.spec, like Provides: octave-abi = %_octave_abi *And* provide an octave-version agnostic location to install things to... something like: /usr/share/octave/ And then octave-forge addons simply install to that /usr/share/octave location and have a single Requires: octave-abi = %_octave_abi to match the version for which it was built against. -- Rex From mattdm at mattdm.org Thu Feb 24 15:56:16 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 24 Feb 2005 10:56:16 -0500 Subject: FE package kernel module guidelines and openafs Message-ID: <20050224155616.GA5203@jadzia.bu.edu> There'd been some discussion earlier about getting my OpenAFS packages for Fedora into Extras. (They're at .) The new package guidelines state: Also, keep in mind that kernel modules without source code, or licensed with anything other than GPL or LGPL licenses do not belong in Fedora Core or Fedora Extras. OpenAFS is open source, using an OSI-approved license -- the IBM Public License -- which is not GPL compatible. Does this mean that getting OpenAFS into Extras isn't something worth even bothering with? But I do not want to force it on people that arguably are _not_ doing derived work (it would be rather preposterous to call the Andrew FileSystem a "derived work" of linux, for example, so I think it's perfectly ok to have a AFS module, for example). -- Linus Torvalds And that was before the module was actually open source. Now, it sure would have been nice if IBM would have chosen to make the code GPL'd. But it isn't, yet it is open source code which many people around the world rely on. I know there are all sorts of legal and religious issues here; mainly I want to know: is working with Fedora Extras on this worth my time, or a waste of it? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dwmw2 at infradead.org Thu Feb 24 16:04:57 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 24 Feb 2005 16:04:57 +0000 Subject: FE package kernel module guidelines and openafs In-Reply-To: <20050224155616.GA5203@jadzia.bu.edu> References: <20050224155616.GA5203@jadzia.bu.edu> Message-ID: <1109261097.5420.91.camel@hades.cambridge.redhat.com> On Thu, 2005-02-24 at 10:56 -0500, Matthew Miller wrote: > I know there are all sorts of legal and religious issues here; mainly I want > to know: is working with Fedora Extras on this worth my time, or a waste of > it? TBH, I think working on the native Linux AFS support would be a better use of anyone's time. -- dwmw2 From gdk at redhat.com Thu Feb 24 16:11:44 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Thu, 24 Feb 2005 11:11:44 -0500 (EST) Subject: FE package kernel module guidelines and openafs In-Reply-To: <20050224155616.GA5203@jadzia.bu.edu> References: <20050224155616.GA5203@jadzia.bu.edu> Message-ID: Here I refer to the Red Hat Patent Promise. The licenses that we enumerate here are the licenses that Red Hat counsel considers to be "friendly". http://www.redhat.com/legal/patent_policy.html Approved License means any of the following licenses: GNU General Public License v2.0; IBM Public License v1.0; Common Public License v0.5; Q Public License v1.0; Open Software License v1.1; and any open source license granted by Red Hat. Red Hat may add to this list in its sole discretion by publication on this page. The IBM Public License is specifically included here. I believe that any license under which we *encourage community development under our own patents* can certainly be included in Fedora Extras. --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan On Thu, 24 Feb 2005, Matthew Miller wrote: > There'd been some discussion earlier about getting my OpenAFS packages for > Fedora into Extras. (They're at .) > > The new package guidelines state: > > Also, keep in mind that kernel modules without source code, or licensed > with anything other than GPL or LGPL licenses do not belong in Fedora Core > or Fedora Extras. > > OpenAFS is open source, using an OSI-approved license -- the IBM Public > License -- which is not GPL compatible. > > Does this mean that getting OpenAFS into Extras isn't something worth even > bothering with? > > > But I do not want to force it on people that arguably are _not_ doing > derived work (it would be rather preposterous to call the Andrew > FileSystem a "derived work" of linux, for example, so I think it's > perfectly ok to have a AFS module, for example). > > -- Linus Torvalds > > > And that was before the module was actually open source. Now, it sure would > have been nice if IBM would have chosen to make the code GPL'd. But it > isn't, yet it is open source code which many people around the world rely > on. > > I know there are all sorts of legal and religious issues here; mainly I want > to know: is working with Fedora Extras on this worth my time, or a waste of > it? > > > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > > -- > 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 Thu Feb 24 16:20:48 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 24 Feb 2005 11:20:48 -0500 Subject: FE package kernel module guidelines and openafs In-Reply-To: <1109261097.5420.91.camel@hades.cambridge.redhat.com> References: <20050224155616.GA5203@jadzia.bu.edu> <1109261097.5420.91.camel@hades.cambridge.redhat.com> Message-ID: <20050224162048.GA6513@jadzia.bu.edu> On Thu, Feb 24, 2005 at 04:04:57PM +0000, David Woodhouse wrote: > > I know there are all sorts of legal and religious issues here; mainly I want > > to know: is working with Fedora Extras on this worth my time, or a waste of > > it? > TBH, I think working on the native Linux AFS support would be a better > use of anyone's time. I know you do. :) But while I'm happy to package things, doing the work needed to make that work perfectly is beyond me, and people need AFS access now. I do appreciate that _you_ are spending time on it, though. :) I'm happy to help test the native implementation; last I tried, it was discouraging. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tcallawa at redhat.com Thu Feb 24 16:29:55 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 24 Feb 2005 10:29:55 -0600 Subject: FE package kernel module guidelines and openafs In-Reply-To: References: <20050224155616.GA5203@jadzia.bu.edu> Message-ID: <1109262595.13305.190.camel@localhost.localdomain> On Thu, 2005-02-24 at 11:11 -0500, Greg DeKoenigsberg wrote: >The IBM Public License is specifically included here. I believe that any >license under which we *encourage community development under our own >patents* can certainly be included in Fedora Extras. For the kernel? I suppose however if Linus himself doesn't mind, we shouldn't. However, the kernel is very very much GPL. And the OSI is GPL incompatible. Common sense dictates you can't build code that links to kernel bits without being GPL compatible, but we know this isn't the case (else there would be no binary only modules out there). I know this is a holy war waiting to happen, so I'm going to amend the list of "acceptable kernel module licenses" to GNU General Public License v2.0, GNU Lesser General Public License v2, IBM Public License v1.0, Common Public License v0.5, Q Public License v1.0, Open Software License v1.1, and any open source license granted by Red Hat. If your conscience is ok with using one of those licenses in a kernel module, then its ok by me. ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From mattdm at mattdm.org Thu Feb 24 16:58:31 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 24 Feb 2005 11:58:31 -0500 Subject: FE package kernel module guidelines and openafs In-Reply-To: <1109262595.13305.190.camel@localhost.localdomain> References: <20050224155616.GA5203@jadzia.bu.edu> <1109262595.13305.190.camel@localhost.localdomain> Message-ID: <20050224165831.GA7996@jadzia.bu.edu> On Thu, Feb 24, 2005 at 10:29:55AM -0600, Tom 'spot' Callaway wrote: > If your conscience is ok with using one of those licenses in a kernel > module, then its ok by me. :) thanks. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fedora at leemhuis.info Thu Feb 24 17:32:24 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 24 Feb 2005 18:32:24 +0100 Subject: Package proposal: vnstat In-Reply-To: <20050224110355.GA30936@lisas.de> References: <20050224110355.GA30936@lisas.de> Message-ID: <1109266345.5990.20.camel@localhost.localdomain> Hi * Adrian, seems we are once again interested in the same packages... I did wanted to look into vnstat and package it but did not find the time yet. Thanks for your work. Am Donnerstag, den 24.02.2005, 12:03 +0100 schrieb Adrian Reber: > vnstat: A console-based network traffic monitor > > http://lisas.de/~adrian/rpm/vnstat-1.4-1.src.rpm > > http://humdi.net/vnstat/ Is the crontab entry really needed? Not everyone wants to monitor eth0. Also if you accidentally create a database as root after install (because you don't now yet that there is a vnstat user and the cron job) the cron job will fail cause the database-files are owned by root... Also the upstream documentation isn't very good AFAIK. The FAQ online is a bit better -- maybe we should include it? The included file FAQ in the %docs contains only a link to the faq online. But the FAQ is also not perfect: > How should dialup users use vnStat? > > That's all explained at the end of the README. Missing AFAICS :-( Well, that a upstream problem. But: > The idea > is to include vnStat with enable/disable parameters in > scripts related with the used interface. Example scripts > can be found from the pppd directory that came with the > source package. Maybe we should include those in %doc also? But they also don't use the vnstat-user :-( Maybe we should get rid of the vnstat user and the cronjob completely... If we do that we should ship the INSTALL file also cause there is also a bit of important info IMHO. Just my 2 euro cent. -- Thorsten Leemhuis From j.w.r.degoede at hhs.nl Thu Feb 24 18:53:42 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 24 Feb 2005 19:53:42 +0100 Subject: Volunteer to maintain a number of packages Message-ID: <421E22B6.2080802@hhs.nl> Hi, I would like to volunteer to maintain a number of packages listed on: http://fedoraproject.org/wiki/Extras_2fOrphanedPackages This are all packages listed to be removed from FC4, I've noticed that there is some discussion about this on fedora-devel so I might be a bit early. The packages I would like to volunteer for are: -gnumeric, because I use it quite often it is just way better then oocalc imho. -tuxracer & freeciv, because I'm a teacher who is trying to get his students to move to Linux and what do they want? Games! And because I like these myself :) I've been a redhat betateam member back in the days when RH still used todo closed betas, long time Linux user and coder, although I haven't done much community work. I can code C blindfolded and I'm learning to create better RPMS by the day. Also see my introductionary message to fedora-devel some time ago, or search for bugs in RH-bugzilla committed by me, or take a look at: http://x.mame.net or my outdated homepage: http://home.versatel.nl/jwrdegoede/ My bugzilla-account email is the same as I'm posting this from. Regards, Hans p.s. In order to maintain this packages Extras-CVS access would be handy, I'll take care of the paperwork part soon, any CVS account holders who want to sponsor me? From wtogami at redhat.com Thu Feb 24 19:27:24 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 24 Feb 2005 09:27:24 -1000 Subject: Volunteer to maintain a number of packages In-Reply-To: <421E22B6.2080802@hhs.nl> References: <421E22B6.2080802@hhs.nl> Message-ID: <421E2A9C.2000305@redhat.com> Hans de Goede wrote: > -tuxracer & freeciv, because I'm a teacher who is trying to get his > students to move to Linux and what do they want? Games! And because I http://projects.planetpenguin.de/racer/index.php tuxracer should not be added again. It should be replaced with ppracer which is considerably better. Nils Philippsen already volunteered to maintain ppracer, talk to him if you want to take over. Warren Togami wtogami at redhat.com From notting at redhat.com Thu Feb 24 19:27:48 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 Feb 2005 14:27:48 -0500 Subject: Volunteer to maintain a number of packages In-Reply-To: <421E22B6.2080802@hhs.nl> References: <421E22B6.2080802@hhs.nl> Message-ID: <20050224192747.GA11644@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > The packages I would like to volunteer for are: > -gnumeric, because I use it quite often it is just way better then > oocalc imho. > -tuxracer & freeciv, because I'm a teacher who is trying to get his > students to move to Linux and what do they want? Games! And because I > like these myself :) I believe part of the discussion around tuxracer was replacing it with ppracer in Extras. Bill From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 24 19:32:53 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 24 Feb 2005 20:32:53 +0100 Subject: Volunteer to maintain a number of packages In-Reply-To: <421E2A9C.2000305@redhat.com> References: <421E22B6.2080802@hhs.nl> <421E2A9C.2000305@redhat.com> Message-ID: <20050224203253.728df748@python2> Warren Togami wrote : > Hans de Goede wrote: > > -tuxracer & freeciv, because I'm a teacher who is trying to get his > > students to move to Linux and what do they want? Games! And because I > > http://projects.planetpenguin.de/racer/index.php > tuxracer should not be added again. It should be replaced with ppracer > which is considerably better. Nils Philippsen already volunteered to > maintain ppracer, talk to him if you want to take over. Neat. I was wondering why no one had decided to enhance tuxracer ever since it completely "stalled", and I'm quite happy to discover that someone actually did ;-) I'll be reviewing that package for sure if it's needed! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 0.28 0.19 0.17 From skvidal at phy.duke.edu Thu Feb 24 19:33:45 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 24 Feb 2005 14:33:45 -0500 Subject: libcaca Message-ID: <1109273625.15658.17.camel@opus.phy.duke.edu> Hey folks, So a request to rebuild libcaca came along. I'm curious about this - umm, why? I understand there's no problem with including libcaca on any legal grounds but maybe we should add a 'this is dumb' standard that can be applied occasionally, esp when there's no demand for a package. So I guess what I'm asking is: 1. is there demand for libcaca? 2. is there a good reason to continue including? If the answer to the above is no then: Can we pull it? -sv From notting at redhat.com Thu Feb 24 19:41:15 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 Feb 2005 14:41:15 -0500 Subject: libcaca In-Reply-To: <1109273625.15658.17.camel@opus.phy.duke.edu> References: <1109273625.15658.17.camel@opus.phy.duke.edu> Message-ID: <20050224194114.GB11644@nostromo.devel.redhat.com> seth vidal (skvidal at phy.duke.edu) said: > Hey folks, > So a request to rebuild libcaca came along. I'm curious about this - > umm, why? I understand there's no problem with including libcaca on any > legal grounds but maybe we should add a 'this is dumb' standard that can > be applied occasionally, esp when there's no demand for a package. > > So I guess what I'm asking is: > > 1. is there demand for libcaca? Sure! (Seriously, it's no worse than aalib, or GtkAda, or a variety of other things.) > 2. is there a good reason to continue including? Does it have a willing maintainer? Bill From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 24 19:42:26 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 24 Feb 2005 20:42:26 +0100 Subject: libcaca In-Reply-To: <1109273625.15658.17.camel@opus.phy.duke.edu> References: <1109273625.15658.17.camel@opus.phy.duke.edu> Message-ID: <20050224204226.4564b060@python2> seth vidal wrote : > Hey folks, > So a request to rebuild libcaca came along. I'm curious about this - > umm, why? I understand there's no problem with including libcaca on any > legal grounds but maybe we should add a 'this is dumb' standard that can > be applied occasionally, esp when there's no demand for a package. > > So I guess what I'm asking is: > > 1. is there demand for libcaca? > 2. is there a good reason to continue including? > > If the answer to the above is no then: > Can we pull it? It's not "dumb", it's amazing ASCII art eye-candy :-D Isn't Extras a place for all packages that have a compatible license and that someone is committed to actively maintain? If so, then I don't see why libcaca should go. Sure, probably nothing in Extras depends on it because mostly only video players use it (well, a patched SDL can too ;-)), but I do rebuild some packages against it on freshrpms.net, and it makes more sense for me to maintain packages in Extras rather than on freshrpms.net. So, to the above : 1) Yes, for some of my multimedia packages. 2) Yes : I'm committed to actively maintaining it. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 0.17 0.18 0.16 From skvidal at phy.duke.edu Thu Feb 24 19:43:11 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 24 Feb 2005 14:43:11 -0500 Subject: libcaca In-Reply-To: <20050224194114.GB11644@nostromo.devel.redhat.com> References: <1109273625.15658.17.camel@opus.phy.duke.edu> <20050224194114.GB11644@nostromo.devel.redhat.com> Message-ID: <1109274191.15658.25.camel@opus.phy.duke.edu> > Sure! > > (Seriously, it's no worse than aalib, or GtkAda, or a variety > of other things.) one thing at a time! :) > > 2. is there a good reason to continue including? > > Does it have a willing maintainer? This is what I'm asking. Matthias is maintaining it right now, I believe, I'm just curious if we want to talk about a minimum 'this is stupid' rule for inclusion :) -sv From j.w.r.degoede at hhs.nl Thu Feb 24 19:46:35 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 24 Feb 2005 20:46:35 +0100 Subject: Volunteer to maintain a number of packages In-Reply-To: <421E2A9C.2000305@redhat.com> References: <421E22B6.2080802@hhs.nl> <421E2A9C.2000305@redhat.com> Message-ID: <421E2F1B.4050402@hhs.nl> Warren Togami wrote: > Hans de Goede wrote: > >> -tuxracer & freeciv, because I'm a teacher who is trying to get his >> students to move to Linux and what do they want? Games! And because I > > > http://projects.planetpenguin.de/racer/index.php > tuxracer should not be added again. It should be replaced with ppracer > which is considerably better. Nils Philippsen already volunteered to > maintain ppracer, talk to him if you want to take over. > I'll ask him if he's planning on adding this to extras anytime soon, otherwise I might do it, does this eman that the tuxracer drop from core is final, I ask this because there was some discussion on fedora-devel that some packages which we're dropped might come back now it has been decided to go for a 5 cd set for FC4. Regards, Hans From skvidal at phy.duke.edu Thu Feb 24 19:44:19 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 24 Feb 2005 14:44:19 -0500 Subject: libcaca In-Reply-To: <20050224204226.4564b060@python2> References: <1109273625.15658.17.camel@opus.phy.duke.edu> <20050224204226.4564b060@python2> Message-ID: <1109274259.15658.27.camel@opus.phy.duke.edu> > It's not "dumb", it's amazing ASCII art eye-candy :-D see you can't even say it with a straightface. > Isn't Extras a place for all packages that have a compatible license and > that someone is committed to actively maintain? If so, then I don't see why > libcaca should go. Sure, probably nothing in Extras depends on it because > mostly only video players use it (well, a patched SDL can too ;-)), but I > do rebuild some packages against it on freshrpms.net, and it makes more > sense for me to maintain packages in Extras rather than on freshrpms.net. > > So, to the above : > > 1) Yes, for some of my multimedia packages. Well this part I do have an issue with - I guess I'm a little bothered that some package might actually DEPEND on this library. Isn't this the sort of thing to --disable=libcaca in the %configure? :) > 2) Yes : I'm committed to actively maintaining it. okie doke. -sv From bji-fedora at ischo.com Thu Feb 24 19:46:37 2005 From: bji-fedora at ischo.com (Bryan Ischo) Date: Thu, 24 Feb 2005 14:46:37 -0500 (EST) Subject: [Fwd: Creating new extras package for missing xorg-x11 programs] Message-ID: <1766.66.65.160.16.1109274397.squirrel@mail.ischo.com> Hi all. Is the question I have asked below inappropriate for this list? If so, can someone please point me to a more suitable venue for this question? Thank you! Bryan ------------------------------------------------------------------------ Bryan Ischo bryan at ischo.com N, R, 6 New York, NY, USA http://www.ischo.com RedHat Linux 7.3 ------------------------------------------------------------------------ -------- Original Message -------- Subject: Creating new extras package for missing xorg-x11 programs From: "Bryan Ischo" Date: Wed, February 23, 2005 11:11 am To: Hi all. After some discussion in bug 140214, and on the Fedora Users mailing list (fedora-list at redhat.com), I have decided to try to build a new extras package to supply some of the X11 utility programs which have been removed from the xorg-x11 package. These programs include some very small and probably not-frequently-used programs: xbiff, xditview, and xeyes. Mostly I am concerned about xbiff, but I thought I'd include the other programs since they are so small, so that no one else who wants them will have to go through the trouble of building their own extras RPM for them. Technically these programs are a part of the X.org software release but the Fedora developers have decided to remove them from the base package, because their functionality is apparently redundant with some other programs available in Fedora Core (but not from my perspective as there is no program that does exactly what xbiff does for my purposes). Because there has been some suggestion that the X.org team is reorganizing the base X11 distribution for the R7 release, it seems that any SPEC file that I make now will likely be completely obsoleted at that time. For this reason I want to do the simplest, easiest thing necessary to build a spec file for these programs. Once the X.org team has reorganized their source tree into a format which is not expected to change in the near future, I'll do the extra work of making a spec file which is clean and neat. For the time being, I'm thinking of just taking the existing xorg-x11 spec file and modifying it for the purposes of creating an rpm that installs just the three programs I have mentioned. The X.org makefile system is quite complicated and I am not sure it will be worth the trouble to investigate trying to build just these programs when compiling the rpm from the source rpm. The existing xorg-x11 spec file seems to take the same approach; it lets the X.org makefiles do their thing and then as a post-processing step removes the built files that it doesn't want to install. I'd do something similar, using the xorg-x11 spec file as a base. Does this sound like a reasonable approach? What should I name this spec file/rpm? Thanks, and best wishes, Bryan ------------------------------------------------------------------------ Bryan Ischo bryan at ischo.com N, R, 6 New York, NY, USA http://www.ischo.com RedHat Linux 9 ------------------------------------------------------------------------ From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 24 19:49:36 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 24 Feb 2005 20:49:36 +0100 Subject: libcaca In-Reply-To: <1109274259.15658.27.camel@opus.phy.duke.edu> References: <1109273625.15658.17.camel@opus.phy.duke.edu> <20050224204226.4564b060@python2> <1109274259.15658.27.camel@opus.phy.duke.edu> Message-ID: <20050224204936.73d54e07@python2> seth vidal wrote : > Well this part I do have an issue with - I guess I'm a little bothered > that some package might actually DEPEND on this library. Isn't this the > sort of thing to --disable=libcaca in the %configure? :) Hehe, don't worry : As you may have seen, there is no "libcaca" binary package, just a "libcaca-devel" one since the author decided the library just wasn't API stable enough to dynamically link to it... so this evil little bugger doesn't add any DEPENDency... but "bloats" your binary instead ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 0.14 0.19 0.14 From notting at redhat.com Thu Feb 24 19:49:41 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 Feb 2005 14:49:41 -0500 Subject: [Fwd: Creating new extras package for missing xorg-x11 programs] In-Reply-To: <1766.66.65.160.16.1109274397.squirrel@mail.ischo.com> References: <1766.66.65.160.16.1109274397.squirrel@mail.ischo.com> Message-ID: <20050224194940.GC11644@nostromo.devel.redhat.com> Bryan Ischo (bji-fedora at ischo.com) said: > which is clean and neat. For the time being, I'm thinking of just > taking the existing xorg-x11 spec file and modifying it for the purposes > of creating an rpm that installs just the three programs I have > mentioned. That would be an awfully large source RPM. :) > Does this sound like a reasonable approach? I suspect you could pull some of them out, do some Imake magic, and build them. Not sure how much pain that would be though. > What should I name this spec file/rpm? I'd say xorg-x11-extra-tools, or something like that. Bill From skvidal at phy.duke.edu Thu Feb 24 19:53:17 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 24 Feb 2005 14:53:17 -0500 Subject: libcaca In-Reply-To: <20050224204936.73d54e07@python2> References: <1109273625.15658.17.camel@opus.phy.duke.edu> <20050224204226.4564b060@python2> <1109274259.15658.27.camel@opus.phy.duke.edu> <20050224204936.73d54e07@python2> Message-ID: <1109274797.15658.29.camel@opus.phy.duke.edu> On Thu, 2005-02-24 at 20:49 +0100, Matthias Saou wrote: > seth vidal wrote : > > > Well this part I do have an issue with - I guess I'm a little bothered > > that some package might actually DEPEND on this library. Isn't this the > > sort of thing to --disable=libcaca in the %configure? :) > > Hehe, don't worry : As you may have seen, there is no "libcaca" binary > package, just a "libcaca-devel" one since the author decided the library > just wasn't API stable enough to dynamically link to it... so this evil > little bugger doesn't add any DEPENDency... but "bloats" your binary > instead ;-) > Okay, that's just a special kind of evil. -sv From bji-fedora at ischo.com Thu Feb 24 19:57:53 2005 From: bji-fedora at ischo.com (Bryan Ischo) Date: Thu, 24 Feb 2005 14:57:53 -0500 (EST) Subject: [Fwd: Creating new extras package for missing xorg-x11 programs] In-Reply-To: <20050224194940.GC11644@nostromo.devel.redhat.com> References: <1766.66.65.160.16.1109274397.squirrel@mail.ischo.com> <20050224194940.GC11644@nostromo.devel.redhat.com> Message-ID: <1943.66.65.160.16.1109275073.squirrel@mail.ischo.com> > Bryan Ischo (bji-fedora at ischo.com) said: >> which is clean and neat. For the time being, I'm thinking of just >> taking the existing xorg-x11 spec file and modifying it for the >> purposes of creating an rpm that installs just the three programs I >> have >> mentioned. > > That would be an awfully large source RPM. :) I agree completely. However this approach was suggested by a user on the fedora user's list, as being similar to one used by one of the VNC rpm's. Since it is difficult to build any of the programs in the X.org software distribution without building everything (to my limited knowledge), and since the X.org structure is supposed to be changing with the upcoming R7 release (which is I guess why the Fedora developers decided to pull some of the programs out of the Fedora xorg-x11 package ahead of that change), I'd rather not mess with the X.org makefiles. Once the X.org tree is restructured according to their plans, I would make a "real" spec file that built just those (presumably easy to build independently of the rest of the X.org tree) programs that are to be installed by the rpm. As was pointed out on fedora user's, the SRPM would be ridiculously large for the purposes of building only a couple of hundred K of installed files, but this would only be an issue for those who build from SRPM; the RPMs themselves would be quite small. >> Does this sound like a reasonable approach? > > I suspect you could pull some of them out, do some Imake magic, > and build them. Not sure how much pain that would be though. I suspect it would be alot of pain. And I'm not sure the pain is worth it if the X.org people are really going to be reorganizing their tree as was suggested by the Fedora team, as the reason for pre-emptively removing some programs from the xorg-x11 rpm. However, I will take your comments under advisement and first do some real exploring to see how difficult it would be to shrink the source RPM down by including just the files that need to be built. Being kind of unfamiliar with source RPMs - would I really be able to just pull a subset of files from the X.org software distribution for including in my source RPM? I know that RPM makes it easy to include additional patches along with a source distribution to be built, I'm not so clear on the concept of making a separate, not-released-by-the-original-authors version of their code (i.e. one which only includes the programs I am interested in) to put into the source RPM, to avoid including the entire X.org tree. >> What should I name this spec file/rpm? > > I'd say xorg-x11-extra-tools, or something like that. That sounds like a fine name to me. I will use it. Thanks, Bryan ------------------------------------------------------------------------ Bryan Ischo bryan at ischo.com N, R, 6 New York, NY, USA http://www.ischo.com RedHat Linux 7.3 ------------------------------------------------------------------------ From davej at redhat.com Thu Feb 24 20:00:16 2005 From: davej at redhat.com (Dave Jones) Date: Thu, 24 Feb 2005 15:00:16 -0500 Subject: FE package kernel module guidelines and openafs In-Reply-To: <1109262595.13305.190.camel@localhost.localdomain> References: <20050224155616.GA5203@jadzia.bu.edu> <1109262595.13305.190.camel@localhost.localdomain> Message-ID: <20050224200016.GA20219@redhat.com> On Thu, Feb 24, 2005 at 10:29:55AM -0600, Tom 'spot' Callaway wrote: > I know this is a holy war waiting to happen, so I'm going to amend the > list of "acceptable kernel module licenses" to GNU General Public > License v2.0, GNU Lesser General Public License v2, IBM Public License > v1.0, Common Public License v0.5, Q Public License v1.0, Open Software > License v1.1, and any open source license granted by Red Hat. Sure we can distribute them, but as not all of those are GPL compatible, they will taint your kernel on loading them. The only ones that don't are "GPL", "GPL v2", "GPL and additional rights", "Dual BSD/GPL" and "Dual MPL/GPL". Dave From perbj at stanford.edu Thu Feb 24 20:02:23 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Thu, 24 Feb 2005 12:02:23 -0800 Subject: [Fwd: Creating new extras package for missing xorg-x11 programs] In-Reply-To: <1766.66.65.160.16.1109274397.squirrel@mail.ischo.com> References: <1766.66.65.160.16.1109274397.squirrel@mail.ischo.com> Message-ID: <1109275343.5265.6.camel@localhost.localdomain> > These programs include some very small and probably not-frequently-used > programs: xbiff, xditview, and xeyes. Mostly I am concerned about > xbiff, but I thought I'd include the other programs since they are so > small, so that no one else who wants them will have to go through the > trouble of building their own extras RPM for them. > > Technically these programs are a part of the X.org software release but > the Fedora developers have decided to remove them from the base package, > because their functionality is apparently redundant with some other > programs available in Fedora Core (but not from my perspective as there > is no program that does exactly what xbiff does for my purposes). How about pulling from the freedesktop.org/xapps tree instead? That would give you much less source duplication... http://cvs.freedesktop.org/xapps/ http://www.freedesktop.org/Software/ProposedXAppsCVSStructure > Because there has been some suggestion that the X.org team is > reorganizing the base X11 distribution for the R7 release, it seems that > any SPEC file that I make now will likely be completely obsoleted at > that time. ... and it's more likely that your resulting specfile will be useful even after modularization if you go in this direction. (No guarantees of course...) /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From wagnerric at condor.cxo.cpqcorp.net Thu Feb 24 22:32:13 2005 From: wagnerric at condor.cxo.cpqcorp.net (Rick Wagner) Date: Thu, 24 Feb 2005 15:32:13 -0700 Subject: confirm 9bfa7e906ac01fb5cf66fa125e951de67b92c2ae In-Reply-To: References: Message-ID: <200502241532.13714.wagnerric@condor.cxo.cpqcorp.net> From byte at aeon.com.my Fri Feb 25 02:47:10 2005 From: byte at aeon.com.my (Colin Charles) Date: Fri, 25 Feb 2005 10:47:10 +0800 Subject: Maintainership: bzflag Message-ID: <1109299630.5676.23.camel@localhost.localdomain> I'd like to maintain bzflag in Extras, since thats been orphaned in Core [1] This might mean bumping up to BZFlag 2 as well (which has a lot of cool features) Bugzilla account is colin at fedoraproject.org and I'm a general all round Fedora person. Any objections? [1] - and ever since being in Bangalore on a LAN, started playing it voraciously as well ;-) -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From skvidal at fedoraproject.org Fri Feb 25 06:51:55 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 25 Feb 2005 01:51:55 -0500 Subject: Updated packages Message-ID: <1109314315.16521.32.camel@cutter> Hi Everyone, We've got some updates Packages in extras and the first package request to the testing repository. - torcs-data (noarch) - anthy (i386, x86_64) - libcaca (x86_64) testing: - cone (i386, x86_64) After cone gets some testing it will hopefully move into released. Follow updates and new packages at: http://fedoraproject.org/infofeed/ Fedora Extras 3 Package RSS Feed: http://fedoraproject.org/infofeed/inputs/fc3-extras.xml Extras info: http://fedoraproject.org/wiki/Extras Status page: http://fedoraproject.org/wiki/Extras/FC3Status Report problems at Bugzilla: http://bugzilla.redhat.com/ thanks, -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Fri Feb 25 07:03:09 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 25 Feb 2005 09:03:09 +0200 Subject: New package: ccid Message-ID: <1109314989.15854.7.camel@bobcat.mine.nu> I would like to import ccid to Extras CVS and push a build request for it as soon as possible. ccid is a pcsc-lite driver for generic CCID-compliant smart card readers. See http://pcsclite.alioth.debian.org/ccid.html http://bugzilla.fedora.us/show_bug.cgi?id=1415 This submission has already been reviewed by upstream, and later by someone else, with only minor improvements happening in between. It's not the latest ccid version, but it's the latest that works with the stable version of pcsc-lite currently in Extras. I use this about 8 hours a day, works well for me, and I think the existing reviews in the above Bugzilla entry would be enough so it can be imported, although it strictly speaking doesn't quite meet fedora.us criteria (2 reviews, but not for the same package revision). Any objections? From wtogami at redhat.com Fri Feb 25 07:08:32 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 24 Feb 2005 21:08:32 -1000 Subject: New package: ccid In-Reply-To: <1109314989.15854.7.camel@bobcat.mine.nu> References: <1109314989.15854.7.camel@bobcat.mine.nu> Message-ID: <421ECEF0.5010707@redhat.com> Ville Skytt? wrote: > I would like to import ccid to Extras CVS and push a build request for > it as soon as possible. > > ccid is a pcsc-lite driver for generic CCID-compliant smart card > readers. See http://pcsclite.alioth.debian.org/ccid.html > > http://bugzilla.fedora.us/show_bug.cgi?id=1415 > This submission has already been reviewed by upstream, and later by > someone else, with only minor improvements happening in between. It's > not the latest ccid version, but it's the latest that works with the > stable version of pcsc-lite currently in Extras. > > I use this about 8 hours a day, works well for me, and I think the > existing reviews in the above Bugzilla entry would be enough so it can > be imported, although it strictly speaking doesn't quite meet fedora.us > criteria (2 reviews, but not for the same package revision). Any > objections? > Go for it. Just remember to remove the Epoch before it goes into FE3. I will post the APPROVED message now in fedora-extras-commits. Warren Togami wtogami at redhat.com From skvidal at phy.duke.edu Fri Feb 25 07:28:24 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 02:28:24 -0500 Subject: APPROVED: ccid In-Reply-To: <421ED0D4.30001@redhat.com> References: <421ED0D4.30001@redhat.com> Message-ID: <1109316504.16521.56.camel@cutter> On Thu, 2005-02-24 at 21:16 -1000, Warren Togami wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >https://www.redhat.com/archives/fedora-extras-list/2005-February/msg00627.html >ccid - Generic USB CCID (Chip/Smart Card Interface Devices) driver. If I'm reading, correctly, what this does, someone should mention to the smartcard/certificate/directory service people who were demoing stuff at the red hat booth at lwce. I think Bob Lord was one of the guys' names. it might have some useful overlap. -sv From ville.skytta at iki.fi Fri Feb 25 07:53:54 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 25 Feb 2005 09:53:54 +0200 Subject: New package: ccid In-Reply-To: <421ECEF0.5010707@redhat.com> References: <1109314989.15854.7.camel@bobcat.mine.nu> <421ECEF0.5010707@redhat.com> Message-ID: <1109318034.15854.72.camel@bobcat.mine.nu> On Thu, 2005-02-24 at 21:08 -1000, Warren Togami wrote: > Go for it. Just remember to remove the Epoch before it goes into FE3. Ok. I will also modify the pre-FC3 packages heading to fedora.us epochless then because of the "rpm -F" bug. > I will post the APPROVED message now in fedora-extras-commits. Thanks. From ville.skytta at iki.fi Fri Feb 25 07:59:11 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 25 Feb 2005 09:59:11 +0200 Subject: APPROVED: ccid In-Reply-To: <1109316504.16521.56.camel@cutter> References: <421ED0D4.30001@redhat.com> <1109316504.16521.56.camel@cutter> Message-ID: <1109318351.15854.79.camel@bobcat.mine.nu> On Fri, 2005-02-25 at 02:28 -0500, seth vidal wrote: > If I'm reading, correctly, what this does, someone should mention to the > smartcard/certificate/directory service people who were demoing stuff at > the red hat booth at lwce. I think Bob Lord was one of the guys' names. > > it might have some useful overlap. Yep. ccid itself isn't necessarily particularly interesting here although pcsc-lite needs _some_ drivers. But they might be interested in the smart card enabling stack in Extras as a whole: pcsc-lite (+ drivers), openct, opensc. From j.w.r.degoede at hhs.nl Fri Feb 25 08:18:40 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 25 Feb 2005 09:18:40 +0100 Subject: using yum to get SRPMS Message-ID: <421EDF60.4080401@hhs.nl> A small question (just for convience) can yum be used to install SRPMS? I've read the man page but it doesn't say anything about this. Thanks & Regards, Hans From mihai at xcyb.org Fri Feb 25 08:55:15 2005 From: mihai at xcyb.org (Mihai Maties) Date: Fri, 25 Feb 2005 10:55:15 +0200 Subject: libdbi package Message-ID: <200502251055.15761@xcyb0rg> I filed a bug last summer about the libdbi package being extremely outdated. ( https://bugzilla.redhat.com/beta/show_bug.cgi?id=126421 ) Considering the fact that no other core package requires libdbi I believe that this package definitely belongs in Extras. Please review the following spec files and tell me what do you think about them: http://rpms.xcyb.org/other/libdbi.spec http://rpms.xcyb.org/other/libdbi-drivers.spec [ Ignore the "linuxdist.sh" call and the "xcyb" tag from the name, I'll remove them before offically submitting the specs to extras. ] For the moment I'm just curious what do you think about the way I splitted the packages and what would be the next course of action considering the fact that for FC3 libdbi already exists in Core. Is there a policy (like it was in fedora.us) to not provide an extras package newer than the one in core ? Mihai -- This message was scanned for spam and viruses by BitDefender. For more information please visit http://linux.bitdefender.com/ From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 25 09:06:06 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 25 Feb 2005 10:06:06 +0100 Subject: Maintainership: bzflag In-Reply-To: <1109299630.5676.23.camel@localhost.localdomain> References: <1109299630.5676.23.camel@localhost.localdomain> Message-ID: <20050225100606.6544e38a@python2> Colin Charles wrote : > I'd like to maintain bzflag in Extras, since thats been orphaned in Core > [1] > > This might mean bumping up to BZFlag 2 as well (which has a lot of cool > features) > > Bugzilla account is colin at fedoraproject.org and I'm a general all round > Fedora person. > > Any objections? > > [1] - and ever since being in Bangalore on a LAN, started playing it > voraciously as well ;-) It had already been upgraded in Rawhide to 2.0 by Nils, and I had a bugzilla entry about that update (with attached spec patch) which Warren closed once it got done. I've been maintaining that package initially (Alan adapted my freshrpms package to get it into Core), but really don't mind if someone else wants maintainership, especially if it's someone who plays it more than I do :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 0.30 0.79 1.12 From andreas.bierfert at lowlatency.de Fri Feb 25 11:39:28 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Fri, 25 Feb 2005 12:39:28 +0100 Subject: packages in pending ok... Message-ID: <421F0E70.5010101@lowlatency.de> Hi, dosbox (#2416), centericq (#735) and sylpheed-claws(#2417) in bugzilla.fedora.us got build but wait in pending for someone to verify the build. As I don't have fc{2,1} anywhere to test them I would be glad if somebody could do this... Thx Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | () ASCII ribbon campaign | mail preferred cell: +49 172 9789968 | /\ against HTML mail | From bdpepple at ameritech.net Fri Feb 25 11:53:34 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Fri, 25 Feb 2005 06:53:34 -0500 Subject: 2nd Announcement: Updated Package: Gnome-Blog 0.8 In-Reply-To: <1109173256.5664.6.camel@shuttle.273piedmont.org> References: <1109173256.5664.6.camel@shuttle.273piedmont.org> Message-ID: <1109332414.23956.4.camel@shuttle.273piedmont.org> Anyone? On Wed, 2005-02-23 at 10:40 -0500, Brian Pepple wrote: > Package update for Gnome-Blog to 0.8, and fixes x86_64 build. > > http://piedmont.homelinux.org/fedora/gnome-blog-0.8-4.src.rpm > http://piedmont.homelinux.org/fedora/fedora_md5sum -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Fri Feb 25 13:12:55 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 08:12:55 -0500 Subject: 2nd Announcement: Updated Package: Gnome-Blog 0.8 In-Reply-To: <1109332414.23956.4.camel@shuttle.273piedmont.org> References: <1109173256.5664.6.camel@shuttle.273piedmont.org> <1109332414.23956.4.camel@shuttle.273piedmont.org> Message-ID: <1109337175.16521.77.camel@cutter> On Fri, 2005-02-25 at 06:53 -0500, Brian Pepple wrote: >Anyone? > >On Wed, 2005-02-23 at 10:40 -0500, Brian Pepple wrote: >> Package update for Gnome-Blog to 0.8, and fixes x86_64 build. >> >> http://piedmont.homelinux.org/fedora/gnome-blog-0.8-4.src.rpm >> http://piedmont.homelinux.org/fedora/fedora_md5sum > Have you sent in your key and legal form? -sv From pmatilai at welho.com Fri Feb 25 14:19:52 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 25 Feb 2005 16:19:52 +0200 (EET) Subject: using yum to get SRPMS In-Reply-To: <421EDF60.4080401@hhs.nl> References: <421EDF60.4080401@hhs.nl> Message-ID: On Fri, 25 Feb 2005, Hans de Goede wrote: > A small question (just for convience) can yum be used to install SRPMS? > I've read the man page but it doesn't say anything about this. No, yum doesn't deal with SRPMS. The information is in the metadata however ... http://laiskiainen.org/repoquery/repoquery.py Then you can do things like [pmatilai at chip ~]$ repoquery.py --source --location yum http://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/core/3/i386/os/SRPMS/yum-2.1.11-3.src.rpm ..which you can turn into rpm -ivh `repoquery.py --source --location ` to install src.rpm's :) - Panu - From nphilipp at redhat.com Fri Feb 25 14:26:39 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 25 Feb 2005 15:26:39 +0100 Subject: Maintainership: bzflag In-Reply-To: <1109299630.5676.23.camel@localhost.localdomain> References: <1109299630.5676.23.camel@localhost.localdomain> Message-ID: <1109341599.17219.14.camel@gibraltar.stuttgart.redhat.com> On Fri, 2005-02-25 at 10:47 +0800, Colin Charles wrote: > I'd like to maintain bzflag in Extras, since thats been orphaned in Core > [1] > > This might mean bumping up to BZFlag 2 as well (which has a lot of cool > features) > > Bugzilla account is colin at fedoraproject.org and I'm a general all round > Fedora person. > > Any objections? Not from me (even more so if you ensure timely updates *g*). I'm not quite sure whether my last update made it into Extras' CVS(*), but even if it is it would be built yet. (*): I'm still struggling with my CVS access -- I've sent my SSH pubkey, but I can't seem to checkout. Warren? Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From bdpepple at ameritech.net Fri Feb 25 14:43:51 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Fri, 25 Feb 2005 09:43:51 -0500 Subject: 2nd Announcement: Updated Package: Gnome-Blog 0.8 In-Reply-To: <1109337175.16521.77.camel@cutter> References: <1109173256.5664.6.camel@shuttle.273piedmont.org> <1109332414.23956.4.camel@shuttle.273piedmont.org> <1109337175.16521.77.camel@cutter> Message-ID: <1109342632.25133.2.camel@shuttle.273piedmont.org> On Fri, 2005-02-25 at 08:12 -0500, seth vidal wrote: > Have you sent in your key and legal form? > > -sv No, since based on this message (https://www.redhat.com/archives/fedora- devel-list/2005-February/msg00910.html), it looked like it would be some time before people got sponsored for CVS access. /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 bugs.michael at gmx.net Fri Feb 25 16:19:33 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 25 Feb 2005 17:19:33 +0100 Subject: 2nd Announcement: Updated Package: Gnome-Blog 0.8 In-Reply-To: <1109342632.25133.2.camel@shuttle.273piedmont.org> References: <1109173256.5664.6.camel@shuttle.273piedmont.org> <1109332414.23956.4.camel@shuttle.273piedmont.org> <1109337175.16521.77.camel@cutter> <1109342632.25133.2.camel@shuttle.273piedmont.org> Message-ID: <20050225171933.5b533092.bugs.michael@gmx.net> On Fri, 25 Feb 2005 09:43:51 -0500, Brian Pepple wrote: > On Fri, 2005-02-25 at 08:12 -0500, seth vidal wrote: > > Have you sent in your key and legal form? > > > > -sv > > No, since based on this message (https://www.redhat.com/archives/fedora- > devel-list/2005-February/msg00910.html), it looked like it would be some > time before people got sponsored for CVS access. Well, to expand on that since it's a message written by my, I am a sponsor already for the first few who contacted me about CVS and whom I know from a series of tickets and packages at fedora.us or activity beyond that. Another sponsored developer is in the queue. And I plan to sponsor more contributors. It's just that I'm undecided about the semantics of "being a sponsor" as opposed to the older model of earning trust. Above message is my personal view only and not an official status report of the CVS sponsorship system. From bugs.michael at gmx.net Fri Feb 25 16:32:58 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 25 Feb 2005 17:32:58 +0100 Subject: packages in pending ok... In-Reply-To: <421F0E70.5010101@lowlatency.de> References: <421F0E70.5010101@lowlatency.de> Message-ID: <20050225173258.77ef006a.bugs.michael@gmx.net> On Fri, 25 Feb 2005 12:39:28 +0100, Andreas Bierfert wrote: > dosbox (#2416), centericq (#735) and sylpheed-claws(#2417) in bugzilla.fedora.us > got build but wait in pending for someone to verify the build. As I don't have > fc{2,1} anywhere to test them I would be glad if somebody could do this... I can take over doing a rough verification of centericq for FC1/FC2. Make it the last update for those distributions unless somebody steps forward and requests ownership of the package for FC2 or FC1. But continue to keep an eye on security vulnerabilites. dosbox : seems to start fine, but I found myself unable to enter the characters '/', '\' and ':' and hence could not mount a new drive and e.g. try a test .EXE. sylpheed-claws : since it targets the "testing" repository and given Sylpheed-claws's nature, I would publish it when it builds. Only caveat, it may be the last version that can be updated, since GPGME 1.0.1 support has entered Sylpheed already and once it appears it Sylpheed-claws, we would need to see whether the old GPGME 0.4.x is enough or whether we need to upgrade somehow. In either case, deciding on legacy distributions is something we will need to discuss in the future. It would be best if contributors with interest in FC2/FC1 would take over package maintenance or at least the testing. The publish-when-it-builds method bears a risk. From sgk284 at gmail.com Fri Feb 25 16:35:41 2005 From: sgk284 at gmail.com (Stephen Krenzel) Date: Fri, 25 Feb 2005 11:35:41 -0500 Subject: Fedora Extras: BZFlag Message-ID: <1fa01fe8050225083562a8cc56@mail.gmail.com> I've never been a maintainer before, but I do a bit of developing for BZFlag so if noone else steps up to the plate, I'd be more then happy to maintain it for Fedora. Regards, Steve From toshio at tiki-lounge.com Fri Feb 25 16:34:51 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 25 Feb 2005 08:34:51 -0800 Subject: libcaca In-Reply-To: <1109274191.15658.25.camel@opus.phy.duke.edu>; from skvidal@phy.duke.edu on Thu, Feb 24, 2005 at 02:43:11PM -0500 References: <1109273625.15658.17.camel@opus.phy.duke.edu> <20050224194114.GB11644@nostromo.devel.redhat.com> <1109274191.15658.25.camel@opus.phy.duke.edu> Message-ID: <20050225083451.A23223@tiki-lounge.com> On Thu, Feb 24, 2005 at 02:43:11PM -0500, seth vidal wrote: > > > 2. is there a good reason to continue including? > > > > Does it have a willing maintainer? > > This is what I'm asking. Matthias is maintaining it right now, I > believe, I'm just curious if we want to talk about a minimum 'this is > stupid' rule for inclusion :) > I don't think there should be a "too stupid" rule. If someone is willing to suffer through various upstream problems in order to produce a workable package because they see value in it, we should include it. If there are technical problems with the package then we could exclude it... until the bugs are fixed. -Toshio From byte at aeon.com.my Fri Feb 25 18:47:00 2005 From: byte at aeon.com.my (Colin Charles) Date: Sat, 26 Feb 2005 02:47:00 +0800 Subject: Maintainership: bzflag In-Reply-To: <1109341599.17219.14.camel@gibraltar.stuttgart.redhat.com> References: <1109299630.5676.23.camel@localhost.localdomain> <1109341599.17219.14.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1109357220.5676.109.camel@arena.soho.bytebot.net> On Fri, 2005-02-25 at 15:26 +0100, Nils Philippsen wrote: > (*): I'm still struggling with my CVS access -- I've sent my SSH > pubkey, > but I can't seem to checkout. Warren? Checkout can be done anonymously; check-in's are what require logins (and that ssh key) Did you get a little e-mail message when your account got created? -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From ed at eh3.com Fri Feb 25 20:41:03 2005 From: ed at eh3.com (Ed Hill) Date: Fri, 25 Feb 2005 15:41:03 -0500 Subject: sponsorship for scientific computing stuff In-Reply-To: <1109087637.31372.65.camel@localhost.localdomain> References: <1109030513.30620.103.camel@localhost.localdomain> <1109087637.31372.65.camel@localhost.localdomain> Message-ID: <1109364063.18787.6.camel@localhost.localdomain> On Tue, 2005-02-22 at 09:53 -0600, Tom 'spot' Callaway wrote: > On Mon, 2005-02-21 at 19:01 -0500, Ed Hill wrote: > >Hi folks, > > > >My name is Ed Hill and I was one of the dozen or so FUDCon attendees who > >asked about CVS access. Given the rules posted at: > > > > http://fedoraproject.org/wiki/Extras/CvsAccess > > > >would anyone be kind enough to sponsor me? > > I'll sponsor you. Hi Spot, Thank you!!! I've completed the paperwork and will be sending it along shortly. Ed ps - Has anyone noticed that Item 5 within the PDF [1] on the CvsAccess page [2] says "atents" instead of "patents"? But no one ever actually ***reads*** these things, right? [1] http://fedoraproject.org/wikifiles/attachments/Extras_2fCvsAccess/attachments/Individual.pdf [2] http://fedoraproject.org/wiki/Extras/CvsAccess -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From skvidal at phy.duke.edu Fri Feb 25 20:57:33 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 15:57:33 -0500 Subject: sponsorship for scientific computing stuff In-Reply-To: <1109364063.18787.6.camel@localhost.localdomain> References: <1109030513.30620.103.camel@localhost.localdomain> <1109087637.31372.65.camel@localhost.localdomain> <1109364063.18787.6.camel@localhost.localdomain> Message-ID: <1109365053.23111.26.camel@cutter> - >ps - Has anyone noticed that Item 5 within the PDF [1] on the > CvsAccess page [2] says "atents" instead of "patents"? But > no one ever actually ***reads*** these things, right? > I read it and I just missed that line. I'll forward it on to the legal folks. -sv From skvidal at phy.duke.edu Fri Feb 25 21:10:11 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 16:10:11 -0500 Subject: 2nd Announcement: Updated Package: Gnome-Blog 0.8 In-Reply-To: <1109342632.25133.2.camel@shuttle.273piedmont.org> References: <1109173256.5664.6.camel@shuttle.273piedmont.org> <1109332414.23956.4.camel@shuttle.273piedmont.org> <1109337175.16521.77.camel@cutter> <1109342632.25133.2.camel@shuttle.273piedmont.org> Message-ID: <1109365812.23111.40.camel@cutter> On Fri, 2005-02-25 at 09:43 -0500, Brian Pepple wrote: >On Fri, 2005-02-25 at 08:12 -0500, seth vidal wrote: >> Have you sent in your key and legal form? >> >> -sv > >No, since based on this message (https://www.redhat.com/archives/fedora- >devel-list/2005-February/msg00910.html), it looked like it would be some >time before people got sponsored for CVS access. > I took a look at the package you sent - it's not a huge departure from the one in extras cvs right now. Did you check all the build deps though? I thought some of them changed from 0.7 to 0.8 -sv From skvidal at phy.duke.edu Fri Feb 25 21:10:30 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 16:10:30 -0500 Subject: using yum to get SRPMS In-Reply-To: References: <421EDF60.4080401@hhs.nl> Message-ID: <1109365830.23111.42.camel@cutter> On Fri, 2005-02-25 at 16:19 +0200, Panu Matilainen wrote: >On Fri, 25 Feb 2005, Hans de Goede wrote: > >> A small question (just for convience) can yum be used to install SRPMS? >> I've read the man page but it doesn't say anything about this. > >No, yum doesn't deal with SRPMS. The information is in the metadata >however ... http://laiskiainen.org/repoquery/repoquery.py > but you're going to be changing all that, right? :) -sv From bdpepple at ameritech.net Fri Feb 25 22:02:17 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Fri, 25 Feb 2005 17:02:17 -0500 Subject: 2nd Announcement: Updated Package: Gnome-Blog 0.8 In-Reply-To: <1109365812.23111.40.camel@cutter> References: <1109173256.5664.6.camel@shuttle.273piedmont.org> <1109332414.23956.4.camel@shuttle.273piedmont.org> <1109337175.16521.77.camel@cutter> <1109342632.25133.2.camel@shuttle.273piedmont.org> <1109365812.23111.40.camel@cutter> Message-ID: <1109368938.30118.5.camel@shuttle.273piedmont.org> On Fri, 2005-02-25 at 16:10 -0500, seth vidal wrote: > I took a look at the package you sent - it's not a huge departure from > the one in extras cvs right now. Did you check all the build deps > though? I thought some of them changed from 0.7 to 0.8 The only change is the package now requires gnome-python2-gnomevfs. None of the Build requirements changed. The rest of the changes in the spec had to do with clean up in regard to Python, and two patches (clean up the byte compiled path information within the python files, and the other to fix the x86_64 compilation). /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 shishz at hotpop.com Sat Feb 26 01:15:54 2005 From: shishz at hotpop.com (shishz at hotpop.com) Date: Fri, 25 Feb 2005 20:15:54 -0500 (EST) Subject: package review request: perl-XML-LibXSLT-1.57-1.src.rpm Message-ID: Hello folks, new perl module request for review: http://home.nycap.rr.com/nagaland/rpms/perl-XML-LibXSLT-1.57-1.src.rpm https://bugzilla.redhat.com/beta/show_bug.cgi?id=149766 thanks, zing From bugs.michael at gmx.net Sat Feb 26 01:20:52 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 26 Feb 2005 02:20:52 +0100 Subject: libdbi package In-Reply-To: <200502251055.15761@xcyb0rg> References: <200502251055.15761@xcyb0rg> Message-ID: <20050226022052.5d38b1aa.bugs.michael@gmx.net> On Fri, 25 Feb 2005 10:55:15 +0200, Mihai Maties wrote: > Is there a policy (like it was in > fedora.us) to not provide an extras package newer than the one in core ? Yes. Else it would compete with Fedora Core Updates and Fedora Core Development. From ville.skytta at iki.fi Sat Feb 26 09:45:30 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 26 Feb 2005 11:45:30 +0200 Subject: package review request: perl-XML-LibXSLT-1.57-1.src.rpm In-Reply-To: References: Message-ID: <1109411130.15854.137.camel@bobcat.mine.nu> On Fri, 2005-02-25 at 20:15 -0500, shishz at hotpop.com wrote: > Hello folks, > > new perl module request for review: > > http://home.nycap.rr.com/nagaland/rpms/perl-XML-LibXSLT-1.57-1.src.rpm > https://bugzilla.redhat.com/beta/show_bug.cgi?id=149766 I had packaged this too earlier (but not submitted anywhere IIRC): http://cachalot.mine.nu/3/SRPMS.extras/perl-XML-LibXSLT-1.57-0.fdr.1.src.rpm Not surprisingly, they're mostly the same, except: - The required version of XML::LibXML is >= 1.57 upstream, not > 1.57. - Also, that seems to be bogus, my package has a patch that lowers it to 1.56 so this can be rebuilt on FC2, FWIW. - Build dep is "libxslt-devel >= 1.0.6", not "libxslt". - benchmark.pl need not be installed, I packaged is at %doc. I suggest that you include these fixes in your package, otherwise it looks fine. Use your own judgement whether you want the FC2 compat patch in it too. From nphilipp at redhat.com Sat Feb 26 10:26:02 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 26 Feb 2005 11:26:02 +0100 Subject: Maintainership: bzflag In-Reply-To: <1109357220.5676.109.camel@arena.soho.bytebot.net> References: <1109299630.5676.23.camel@localhost.localdomain> <1109341599.17219.14.camel@gibraltar.stuttgart.redhat.com> <1109357220.5676.109.camel@arena.soho.bytebot.net> Message-ID: <1109413562.6937.1.camel@gibraltar.stuttgart.redhat.com> On Sat, 2005-02-26 at 02:47 +0800, Colin Charles wrote: > On Fri, 2005-02-25 at 15:26 +0100, Nils Philippsen wrote: > > (*): I'm still struggling with my CVS access -- I've sent my SSH > > pubkey, > > but I can't seem to checkout. Warren? > > Checkout can be done anonymously; check-in's are what require logins > (and that ssh key) I know. > Did you get a little e-mail message when your account got created? I didn't, but I don't know whether I'm supposed to having got one -- we had our Red Hat internal "who wants an Extras account" thing and I don't think it was quite that formal ;-). Anyway, I've Cc'ed the usual suspects, maybe one of them can tell me whether I have to re-apply or if the problem is just something else... Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nphilipp at redhat.com Sat Feb 26 11:46:53 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 26 Feb 2005 12:46:53 +0100 Subject: Maintainership: bzflag In-Reply-To: <1109413562.6937.1.camel@gibraltar.stuttgart.redhat.com> References: <1109299630.5676.23.camel@localhost.localdomain> <1109341599.17219.14.camel@gibraltar.stuttgart.redhat.com> <1109357220.5676.109.camel@arena.soho.bytebot.net> <1109413562.6937.1.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1109418413.6937.3.camel@gibraltar.stuttgart.redhat.com> Well, that one should have gone out to more people, so here it goes... On Sat, 2005-02-26 at 11:26 +0100, Nils Philippsen wrote: > On Sat, 2005-02-26 at 02:47 +0800, Colin Charles wrote: > > On Fri, 2005-02-25 at 15:26 +0100, Nils Philippsen wrote: > > > (*): I'm still struggling with my CVS access -- I've sent my SSH > > > pubkey, > > > but I can't seem to checkout. Warren? > > > > Checkout can be done anonymously; check-in's are what require logins > > (and that ssh key) > > I know. > > > Did you get a little e-mail message when your account got created? > > I didn't, but I don't know whether I'm supposed to having got one -- we > had our Red Hat internal "who wants an Extras account" thing and I don't > think it was quite that formal ;-). Anyway, I've Cc'ed the usual > suspects, maybe one of them can tell me whether I have to re-apply or if > the problem is just something else... > > Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nphilipp at redhat.com Sat Feb 26 11:49:14 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 26 Feb 2005 12:49:14 +0100 Subject: Maintainership: bzflag In-Reply-To: <1109418413.6937.3.camel@gibraltar.stuttgart.redhat.com> References: <1109299630.5676.23.camel@localhost.localdomain> <1109341599.17219.14.camel@gibraltar.stuttgart.redhat.com> <1109357220.5676.109.camel@arena.soho.bytebot.net> <1109413562.6937.1.camel@gibraltar.stuttgart.redhat.com> <1109418413.6937.3.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1109418554.6937.5.camel@gibraltar.stuttgart.redhat.com> Argh, it seems mailman is stripping Cc's so if you've got this posting twice or more times -- sorry. On Sat, 2005-02-26 at 12:46 +0100, Nils Philippsen wrote: > Well, that one should have gone out to more people, so here it goes... > > On Sat, 2005-02-26 at 11:26 +0100, Nils Philippsen wrote: > > On Sat, 2005-02-26 at 02:47 +0800, Colin Charles wrote: > > > On Fri, 2005-02-25 at 15:26 +0100, Nils Philippsen wrote: > > > > (*): I'm still struggling with my CVS access -- I've sent my SSH > > > > pubkey, > > > > but I can't seem to checkout. Warren? > > > > > > Checkout can be done anonymously; check-in's are what require logins > > > (and that ssh key) > > > > I know. > > > > > Did you get a little e-mail message when your account got created? > > > > I didn't, but I don't know whether I'm supposed to having got one -- we > > had our Red Hat internal "who wants an Extras account" thing and I don't > > think it was quite that formal ;-). Anyway, I've Cc'ed the usual > > suspects, maybe one of them can tell me whether I have to re-apply or if > > the problem is just something else... > > > > Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From svenwahl at web.de Sat Feb 26 13:16:57 2005 From: svenwahl at web.de (Sven Wahl) Date: Sat, 26 Feb 2005 14:16:57 +0100 Subject: Package dependency problem: grisbi <--> libofx Message-ID: <1109423817.5642.6.camel@lux.homenetwork> Red Hat published an update for the LibOFX library in FC3 the other day, which brings libofx from version 0.6.6 to version 0.7.0. Having grisbi from Fedora Extras installed, I stumbled across a package dependency problem when trying to update libofx: grisbi-0.5.5-1 requires libofx.so.0, which is provided by libofx-0.6.6, but the updated libofx in version 0.7.0 provides libofx.so.1 instead. From bugs.michael at gmx.net Sat Feb 26 14:29:27 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 26 Feb 2005 15:29:27 +0100 Subject: Package dependency problem: grisbi <--> libofx In-Reply-To: <1109423817.5642.6.camel@lux.homenetwork> References: <1109423817.5642.6.camel@lux.homenetwork> Message-ID: <20050226152927.52afb824.bugs.michael@gmx.net> On Sat, 26 Feb 2005 14:16:57 +0100, Sven Wahl wrote: > Red Hat published an update for the LibOFX library in FC3 the other day, > which brings libofx from version 0.6.6 to version 0.7.0. > > Having grisbi from Fedora Extras installed, I stumbled across a package > dependency problem when trying to update libofx: > grisbi-0.5.5-1 requires libofx.so.0, which is provided by libofx-0.6.6, > but the updated libofx in version 0.7.0 provides libofx.so.1 instead. Please be sure to report this at http://bugzilla.redhat.com Product is "Fedora Extras". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From svenwahl at web.de Sat Feb 26 15:47:58 2005 From: svenwahl at web.de (Sven Wahl) Date: Sat, 26 Feb 2005 16:47:58 +0100 Subject: Package dependency problem: grisbi <--> libofx In-Reply-To: <20050226152927.52afb824.bugs.michael@gmx.net> References: <1109423817.5642.6.camel@lux.homenetwork> <20050226152927.52afb824.bugs.michael@gmx.net> Message-ID: <1109432878.5642.13.camel@lux.homenetwork> > Please be sure to report this at http://bugzilla.redhat.com > Product is "Fedora Extras". Done: Bug 149778. Thanks! From gauret at free.fr Sat Feb 26 15:53:49 2005 From: gauret at free.fr (Aurelien Bompard) Date: Sat, 26 Feb 2005 16:53:49 +0100 Subject: Epoch policy Message-ID: Hi all In the new PackageNamingGuidelines, there is nothing about epochs. What is the new Extras policy regarding Epochs ? New packages should be created without Epochs, but what about Fedora.us imported packages ? Should I drop Epoch in the next releases ? Should I do it only for the devel branch ? Thanks Aur?lien -- http://gauret.free.fr ~~~~ Jabber : abompard at jabber.fr "Never test for an error condition you don't know how to handle." -- Steinbach's Guideline for Systems Programming From skvidal at phy.duke.edu Sat Feb 26 16:24:49 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 26 Feb 2005 11:24:49 -0500 Subject: Epoch policy In-Reply-To: References: Message-ID: <1109435089.27384.73.camel@cutter> On Sat, 2005-02-26 at 16:53 +0100, Aurelien Bompard wrote: >Hi all > >In the new PackageNamingGuidelines, there is nothing about epochs. What is >the new Extras policy regarding Epochs ? New packages should be created >without Epochs, but what about Fedora.us imported packages ? Should I drop >Epoch in the next releases ? Should I do it only for the devel branch ? 1. Look on the fedora-packaging list for the discussion 2. my guess is: a. if the fedora.us package had a non-zero epoch it needs to be maintained - just so users have an upgrade path b. if the fedora.us package had an Epoch: 0 drop it and remove %{epoch} from anyplace you have it in ver strings. I'm cc'ing the packaging list to see if that seems right to them. -sv From bugs.michael at gmx.net Sat Feb 26 16:28:49 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 26 Feb 2005 17:28:49 +0100 Subject: ANNOUNCE: cpan2rpm Message-ID: <20050226172849.01c6aceb.bugs.michael@gmx.net> http://fedoraproject.org/wiki/Extras/OrphanedPackages After three weeks of being listed as a "package without maintainer", the cpan2rpm package was picked up Gavin Henry , who volunteered to take care of it. [...] cpan2rpm generates RPM packages from Perl modules. It generates the required SPEC files and builds the packages using rpm. cpan2rpm automatically downloads the module from CPAN, or it can be built from local files. From bugs.michael at gmx.net Sat Feb 26 16:29:19 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 26 Feb 2005 17:29:19 +0100 Subject: ANNOUNCE: john Message-ID: <20050226172919.2f94d9c6.bugs.michael@gmx.net> http://fedoraproject.org/wiki/Extras/OrphanedPackages After three weeks of being listed as a "package without maintainer", the john package was picked up by Gavin Henry , who volunteered to take care of it. [...] John the Ripper is a fast password cracker. Its primary purpose is to detect weak Unix passwords, but a number of other hash types are supported as well. From bugs.michael at gmx.net Sat Feb 26 16:30:31 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 26 Feb 2005 17:30:31 +0100 Subject: ANNOUNCE: librsync, rdiff-backup Message-ID: <20050226173031.2941f04c.bugs.michael@gmx.net> http://fedoraproject.org/wiki/Extras/OrphanedPackages The following packages are believed to be without a maintainer for several months: librsync rdiff-backup The current owner's e-mail address is invalid, and there has not been a reply from a new address yet. Package ownership will be transferred after a final week of waiting for a reply. Gavin Henry volunteered to take over these packages. [...] librsync implements the "rsync" algorithm, which allows remote differencing of binary files. librsync computes a delta relative to a file's checksum, so the two files need not both be present to generate a delta. rdiff-backup is a script, written in Python, that backs up one directory to another and is intended to be run periodically (nightly from cron for instance). The target directory ends up a copy of the source directory, but extra reverse diffs are stored in the target directory, so you can still recover files lost some time ago. The idea is to combine the best features of a mirror and an incremental backup. rdiff-backup can also operate in a bandwidth efficient manner over a pipe, like rsync. Thus you can use rdiff-backup and ssh to securely back a hard drive up to a remote location, and only the differences from the previous backup will be transmitted. -- Bcc to current owner. From bugs.michael at gmx.net Sat Feb 26 16:34:28 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 26 Feb 2005 17:34:28 +0100 Subject: Epoch policy In-Reply-To: <1109435089.27384.73.camel@cutter> References: <1109435089.27384.73.camel@cutter> Message-ID: <20050226173428.78c51ef3.bugs.michael@gmx.net> On Sat, 26 Feb 2005 11:24:49 -0500, seth vidal wrote: > 1. Look on the fedora-packaging list for the discussion http://www.redhat.com/mailman/listinfo/fedora-packaging When/where was this list announced? From skvidal at phy.duke.edu Sat Feb 26 16:39:51 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 26 Feb 2005 11:39:51 -0500 Subject: Epoch policy In-Reply-To: <20050226173428.78c51ef3.bugs.michael@gmx.net> References: <1109435089.27384.73.camel@cutter> <20050226173428.78c51ef3.bugs.michael@gmx.net> Message-ID: <1109435992.27384.80.camel@cutter> On Sat, 2005-02-26 at 17:34 +0100, Michael Schwendt wrote: >On Sat, 26 Feb 2005 11:24:49 -0500, seth vidal wrote: > >> 1. Look on the fedora-packaging list for the discussion > >http://www.redhat.com/mailman/listinfo/fedora-packaging > >When/where was this list announced? > when? earlier this week where? I think on this list - by Spot. -sv From bugs.michael at gmx.net Sat Feb 26 16:41:10 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 26 Feb 2005 17:41:10 +0100 Subject: Epoch policy In-Reply-To: <1109435992.27384.80.camel@cutter> References: <1109435089.27384.73.camel@cutter> <20050226173428.78c51ef3.bugs.michael@gmx.net> <1109435992.27384.80.camel@cutter> Message-ID: <20050226174110.3b13b90c.bugs.michael@gmx.net> On Sat, 26 Feb 2005 11:39:51 -0500, seth vidal wrote: > On Sat, 2005-02-26 at 17:34 +0100, Michael Schwendt wrote: > >On Sat, 26 Feb 2005 11:24:49 -0500, seth vidal wrote: > > > >> 1. Look on the fedora-packaging list for the discussion > > > >http://www.redhat.com/mailman/listinfo/fedora-packaging > > > >When/where was this list announced? > > > > when? earlier this week > where? I think on this list - by Spot. Ah, I see: Subject: Re: DKMS into Fedora Extras :-( From ghenry at suretecsystems.com Sat Feb 26 17:24:58 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sat, 26 Feb 2005 17:24:58 +0000 Subject: ANNOUNCE: librsync, rdiff-backup In-Reply-To: <20050226173031.2941f04c.bugs.michael@gmx.net> References: <20050226173031.2941f04c.bugs.michael@gmx.net> Message-ID: <200502261724.59032.ghenry@suretecsystems.com> On Saturday 26 Feb 2005 16:30, Michael Schwendt wrote: > http://fedoraproject.org/wiki/Extras/OrphanedPackages > > The following packages are believed to be without a maintainer for several > months: > > librsync > rdiff-backup > > The current owner's e-mail address is invalid, and there has not been a > reply from a new address yet. Package ownership will be transferred > after a final week of waiting for a reply. > > Gavin Henry volunteered to take over these > packages. Thank you. > [...] > > librsync implements the "rsync" algorithm, which allows remote > differencing of binary files. librsync computes a delta relative to a > file's checksum, so the two files need not both be present to generate > a delta. > > rdiff-backup is a script, written in Python, that backs up one > directory to another and is intended to be run periodically (nightly > from cron for instance). The target directory ends up a copy of the > source directory, but extra reverse diffs are stored in the target > directory, so you can still recover files lost some time ago. The idea > is to combine the best features of a mirror and an incremental > backup. rdiff-backup can also operate in a bandwidth efficient manner > over a pipe, like rsync. Thus you can use rdiff-backup and ssh to > securely back a hard drive up to a remote location, and only the > differences from the previous backup will be transmitted. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From ghenry at suretecsystems.com Sat Feb 26 17:25:08 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sat, 26 Feb 2005 17:25:08 +0000 Subject: ANNOUNCE: john In-Reply-To: <20050226172919.2f94d9c6.bugs.michael@gmx.net> References: <20050226172919.2f94d9c6.bugs.michael@gmx.net> Message-ID: <200502261725.08758.ghenry@suretecsystems.com> On Saturday 26 Feb 2005 16:29, Michael Schwendt wrote: > http://fedoraproject.org/wiki/Extras/OrphanedPackages > > After three weeks of being listed as a "package without maintainer", the > > john > > package was picked up by Gavin Henry , who > volunteered to take care of it. Thank you. > > [...] > > John the Ripper is a fast password cracker. Its primary purpose is to > detect weak Unix passwords, but a number of other hash types are > supported as well. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From ghenry at suretecsystems.com Sat Feb 26 17:25:25 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sat, 26 Feb 2005 17:25:25 +0000 Subject: ANNOUNCE: cpan2rpm In-Reply-To: <20050226172849.01c6aceb.bugs.michael@gmx.net> References: <20050226172849.01c6aceb.bugs.michael@gmx.net> Message-ID: <200502261725.25766.ghenry@suretecsystems.com> On Saturday 26 Feb 2005 16:28, Michael Schwendt wrote: > http://fedoraproject.org/wiki/Extras/OrphanedPackages > > After three weeks of being listed as a "package without maintainer", the > > cpan2rpm > > package was picked up Gavin Henry , who > volunteered to take care of it. Thank you. > > [...] > > cpan2rpm generates RPM packages from Perl modules. It generates the > required SPEC files and builds the packages using rpm. cpan2rpm > automatically downloads the module from CPAN, or it can be built from > local files. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From gemi at bluewin.ch Sat Feb 26 19:36:17 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Sat, 26 Feb 2005 20:36:17 +0100 Subject: Request for package import: graveman Message-ID: <1109446577.27498.0.camel@scriabin.tannenrauch.ch> http://www.ifi.unizh.ch/staff/milmei/rpms/graveman-0.3.8-1.src.rpm Graveman! can burn audio cd (wav, ogg, mp3), data cd and dvd, duplicate cd, and clean rewritable cd and dvd. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From gemi at bluewin.ch Sat Feb 26 19:37:43 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Sat, 26 Feb 2005 20:37:43 +0100 Subject: Request for package import: abcm2ps and tclabc Message-ID: <1109446663.27498.2.camel@scriabin.tannenrauch.ch> http://www.ifi.unizh.ch/staff/milmei/rpms/abcm2ps-4.8.11-1.src.rpm Abcm2ps is a package which converts music tunes from ABC format to Postscript. Based on abc2ps version 1.2.5, it was developped mainly to print barock organ scores which have independant voices played on one or many keyboards and a pedal-board. Abcm2ps introduces many extensions to the ABC language that make it suitable for classical music. http://www.ifi.unizh.ch/staff/milmei/rpms/tclabc-0.18.5-1.src.rpm Tclabc is designed to help on writing music in ABC notation. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From gemi at bluewin.ch Sat Feb 26 19:38:36 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Sat, 26 Feb 2005 20:38:36 +0100 Subject: Request for package import: hugs98 Message-ID: <1109446716.27498.4.camel@scriabin.tannenrauch.ch> http://www.ifi.unizh.ch/staff/milmei/rpms/hugs98-200311-1.src.rpm Hugs 98 is an interpreter for Haskell, a lazy functional programming language. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From gemi at bluewin.ch Sat Feb 26 19:49:22 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Sat, 26 Feb 2005 20:49:22 +0100 Subject: Packages requiring bootstrapping Message-ID: <1109447362.27774.2.camel@scriabin.tannenrauch.ch> How are packages requiring bootstrapping going to be handled? I have currently packages for sbcl (a Lisp compiler), ghc and nhc98 (Haskell compilers) that require themselves installed to build. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From dwmw2 at infradead.org Sat Feb 26 20:03:24 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 26 Feb 2005 20:03:24 +0000 Subject: Packages requiring bootstrapping In-Reply-To: <1109447362.27774.2.camel@scriabin.tannenrauch.ch> References: <1109447362.27774.2.camel@scriabin.tannenrauch.ch> Message-ID: <1109448204.27107.2.camel@localhost.localdomain> On Sat, 2005-02-26 at 20:49 +0100, G?rard Milmeister wrote: >How are packages requiring bootstrapping going to be handled? I have >currently packages for sbcl (a Lisp compiler), ghc and nhc98 (Haskell >compilers) that require themselves installed to build. Modula-3 (used for cvsup) has the bootstrap compiler distributed in assembly form. For GHC Jens was talking about using the Debian binaries. For bonus points, contrive a way of shipping a bootstrap compiler in Java bytecode or something bizarre like that :) -- dwmw2 From pcompton at proteinmedia.com Sat Feb 26 20:28:48 2005 From: pcompton at proteinmedia.com (Phillip Compton) Date: Sat, 26 Feb 2005 15:28:48 -0500 Subject: Packages free to a good home Message-ID: <1109449728.13134.8.camel@darjeeling.compton.net> rekall http://bugzilla.fedora.us/show_bug.cgi?id=1012 http://phillip.compton.name/SRPMS/rekall-2.2.1-1.src.rpm gdesklets http://bugzilla.fedora.us/show_bug.cgi?id=2025 http://phillip.compton.name/SRPMS/gdesklets-0.30-0.fdr.1.src.rpm With a lack of spare time, I never finished pushing these through fedora.us QA. At this point they both need updates and a little love. I actually have the time at the moment, but with the prospect of maintaining packages for FC3 & FC4 for x86 x86_64 ppc and ppc64 (a pox on those pushing for ia64 too), I'd rather invest my time sponsoring someone new to maintain them. Please let me know if you are interested. Phil From pcompton at proteinmedia.com Sat Feb 26 20:38:04 2005 From: pcompton at proteinmedia.com (Phillip Compton) Date: Sat, 26 Feb 2005 15:38:04 -0500 Subject: Request for package import: graveman In-Reply-To: <1109446577.27498.0.camel@scriabin.tannenrauch.ch> References: <1109446577.27498.0.camel@scriabin.tannenrauch.ch> Message-ID: <1109450284.13134.13.camel@darjeeling.compton.net> On Sat, 2005-02-26 at 20:36 +0100, G?rard Milmeister wrote: > http://www.ifi.unizh.ch/staff/milmei/rpms/graveman-0.3.8-1.src.rpm Missing BR: libglade2-devel, gettext Otherwise, no problem here. I've been looking forward to trying graveman as k3b has given me stability trouble. Phil From pedro.lamarao at mndfck.org Sun Feb 27 00:46:56 2005 From: pedro.lamarao at mndfck.org (=?UTF-8?B?UGVkcm8gTGFtYXLDo28=?=) Date: Sat, 26 Feb 2005 21:46:56 -0300 Subject: Self Introduction: Pedro =?utf-8?q?Lamar=C3=A3o?= Message-ID: <42211880.6030201@mndfck.org> 1. Full Legal Name Pedro Lamar?o Rosa e Silva 2. Full Legal Name Pedro Lamar?o Rosa e Silva :) 3. Profession or student status Attending college, and working as trainee programmer. 4. Company or School Universidade do Estado do Rio de Janeiro (Rio de Janeiro's State University): http://www.uerj.br/ Intersix Technologies S.A.: http://www.intersix.com.br/ 5. Your Goals in the Fedora Project I use Fedora at home; there are some packages I use not present in the distribution that I'd like to contribute/maintain, like the "Off-The-Record Messaging" plugin for gaim. I would do QA on software I use. 6. Historical Qualifications Hm... I have a project in Sourceforge: http://socketstream.sf.net/ I'm skilled in C, C++, C# and Java. No particular reason why you should trust me. :) 7. GPG KEYID and fingerprint pub 1024D/A7B60E9D 2005-02-27 Pedro Lamar?o (Fedora) Impress?o da chave = D65E 0B28 2370 1DF5 E653 94DA AD95 EBB3 A7B6 0E9D sub 1024g/AF85A15C 2005-02-27 From shishz at hotpop.com Sat Feb 26 22:52:27 2005 From: shishz at hotpop.com (Zing) Date: Sat, 26 Feb 2005 17:52:27 -0500 Subject: package review request: perl-XML-LibXSLT-1.57-1.src.rpm References: <1109411130.15854.137.camel@bobcat.mine.nu> Message-ID: On Sat, 26 Feb 2005 11:45:30 +0200, Ville Skytt? wrote: > Not surprisingly, they're mostly the same, except: - The required version > of XML::LibXML is >= 1.57 upstream, not > 1.57. > - Also, that seems to be bogus, my package has a patch that lowers it to > 1.56 > so this can be rebuilt on FC2, FWIW. > - Build dep is "libxslt-devel >= 1.0.6", not "libxslt". - benchmark.pl > need not be installed, I packaged is at %doc. > > I suggest that you include these fixes in your package, otherwise it looks > fine. Use your own judgement whether you want the FC2 compat patch in it > too. Thanks for the qa. I've fixed up the package: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149766 If a FC2 extras cvs dir is created, i'd be willing to roll the compat patch in... btw, if you want to be the owner that's fine; i'm trying to push this through for snownews. thanks, zing From skvidal at phy.duke.edu Sun Feb 27 09:12:55 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 27 Feb 2005 04:12:55 -0500 Subject: Fedora Extras Ideas Sandbox Message-ID: <1109495575.27384.180.camel@cutter> Hey folks, some people were talking about extras a bit last night and had some ideas. I wanted to get them down somewhere non-transient before we forgot about them. So I put this page up: http://fedoraproject.org/wiki/Extras/IdeasSandbox The only idea there right now is just something that made a little bit of sense. comments/addendums, etc, welcome. -sv From byte at aeon.com.my Sun Feb 27 10:38:41 2005 From: byte at aeon.com.my (Colin Charles) Date: Sun, 27 Feb 2005 18:38:41 +0800 Subject: Packages free to a good home In-Reply-To: <1109449728.13134.8.camel@darjeeling.compton.net> References: <1109449728.13134.8.camel@darjeeling.compton.net> Message-ID: <1109500721.5676.292.camel@arena.soho.bytebot.net> On Sat, 2005-02-26 at 15:28 -0500, Phillip Compton wrote: > gdesklets > http://bugzilla.fedora.us/show_bug.cgi?id=2025 > http://phillip.compton.name/SRPMS/gdesklets-0.30-0.fdr.1.src.rpm Attached spec file bumps it up to 0.34 Any thoughts about doing QA on it before pushing it into the tree? Thanks -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi -------------- next part -------------- Name: gdesklets Version: 0.34 Release: 0 Summary: Advanced architecture for desktop applets Group: User Interface/Desktops License: GPL URL: http://gdesklets.gnomedesktop.org/ Source0: http://www.pycage.de/download/gdesklets/gDesklets-%{version}.tar.bz2 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildRequires: gtk2-devel BuildRequires: librsvg2-devel BuildRequires: libgtop2-devel BuildRequires: python-devel BuildRequires: pygtk2-devel BuildRequires: gnome-python2 BuildRequires: gnome-python2-gconf BuildRequires: swig BuildRequires: perl-XML-Parser BuildRequires: gettext BuildRequires: pyorbit-devel Requires: pygtk2 Requires: gnome-python2 Requires: gnome-python2-gconf Requires(post): GConf2 Requires(post): shared-mime-info Requires(postun): shared-mime-info %description gDesklets provides an advanced architecture for desktop applets - tiny displays sitting on your desktop in a symbiotic relationship of eye candy and usefulness. %prep %setup -q -n gDesklets-%{version} %build %configure \ --disable-dependency-tracking \ --disable-install-schemas make %{?_smp_mflags} %clean rm -rf ${RPM_BUILD_ROOT} %install rm -rf ${RPM_BUILD_ROOT} export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 make install DESTDIR=${RPM_BUILD_ROOT} unset GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL %find_lang %{name} %post export GCONF_CONFIG_SOURCE="$(gconftool-2 --get-default-source)" gconftool-2 --makefile-install-rule %{_sysconfdir}/gconf/schemas/%{name}.schemas &>/dev/null update-mime-database %{_datadir}/mime > /dev/null 2>&1 || : %postun update-mime-database %{_datadir}/mime > /dev/null 2>&1 || : %files -f %{name}.lang %defattr(-,root,root,-) %doc AUTHORS ChangeLog COPYING INSTALL NEWS README TODO %doc %{_mandir}/man?/* %config %{_sysconfdir}/gconf/schemas/gdesklets-display-thumbnail.schemas %{_bindir}/* #%{_datadir}/%{name} %{_datadir}/applications/* %{_datadir}/icons/gnome/48x48/mimetypes/*.png %{_datadir}/mime/application/* %{_datadir}/mime/packages/* %{_datadir}/pixmaps/*.png %{_libdir}/gdesklets/* %exclude %{_datadir}/mime/globs %exclude %{_datadir}/mime/magic %exclude %{_datadir}/mime/XMLnamespaces %changelog * Sun Feb 27 2005 Colin Charles - 0.34-0 - bump version to 0.34 - handle libraries, locales, add BuildRequires: pyorbit-devel * Mon Aug 16 2004 Phillip Compton - 0:0.30-0.fdr.1 - Initial Release. From bugs.michael at gmx.net Sun Feb 27 13:30:17 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 27 Feb 2005 14:30:17 +0100 Subject: Packages free to a good home In-Reply-To: <1109500721.5676.292.camel@arena.soho.bytebot.net> References: <1109449728.13134.8.camel@darjeeling.compton.net> <1109500721.5676.292.camel@arena.soho.bytebot.net> Message-ID: <20050227143017.0d1759a9.bugs.michael@gmx.net> On Sun, 27 Feb 2005 18:38:41 +0800, Colin Charles wrote: > On Sat, 2005-02-26 at 15:28 -0500, Phillip Compton wrote: > > gdesklets > > http://bugzilla.fedora.us/show_bug.cgi?id=2025 > > http://phillip.compton.name/SRPMS/gdesklets-0.30-0.fdr.1.src.rpm > > Attached spec file bumps it up to 0.34 > > Any thoughts about doing QA on it before pushing it into the tree? > Thanks No full review, just noticed that the postun script is missing the GConf2 schema uninstallation. And you can drop Epoch 0 for a new package. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.10-1.1154_FC4 loadavg: 0.28 0.49 0.65 From bugs.michael at gmx.net Sun Feb 27 15:33:33 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 27 Feb 2005 16:33:33 +0100 Subject: Request for package import: graveman In-Reply-To: <1109446577.27498.0.camel@scriabin.tannenrauch.ch> References: <1109446577.27498.0.camel@scriabin.tannenrauch.ch> Message-ID: <20050227163333.104a7e3a.bugs.michael@gmx.net> On Sat, 26 Feb 2005 20:36:17 +0100, G?rard Milmeister wrote: > http://www.ifi.unizh.ch/staff/milmei/rpms/graveman-0.3.8-1.src.rpm > > Graveman! can burn audio cd (wav, ogg, mp3), data cd and dvd, > duplicate cd, and clean rewritable cd and dvd. > To avoid any misunderstandings, I would change the description and take out the "mp3" in there. For instance: Graveman! provides a graphical user interface for handling common CD/DVD burning tasks. It can burn Audio CDs, Data CDs and DVDs, duplicate CDs, and clean rewritable CD/DVD media. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.10-1.1154_FC4 loadavg: 3.23 2.79 2.59 From gemi at bluewin.ch Sun Feb 27 15:52:39 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Sun, 27 Feb 2005 16:52:39 +0100 Subject: Request for package import: graveman In-Reply-To: <20050227163333.104a7e3a.bugs.michael@gmx.net> References: <1109446577.27498.0.camel@scriabin.tannenrauch.ch> <20050227163333.104a7e3a.bugs.michael@gmx.net> Message-ID: <1109519559.9674.2.camel@scriabin.tannenrauch.ch> On Sun, 2005-02-27 at 16:33 +0100, Michael Schwendt wrote: > On Sat, 26 Feb 2005 20:36:17 +0100, G?rard Milmeister wrote: > > > http://www.ifi.unizh.ch/staff/milmei/rpms/graveman-0.3.8-1.src.rpm > > > > Graveman! can burn audio cd (wav, ogg, mp3), data cd and dvd, > > duplicate cd, and clean rewritable cd and dvd. > > > > To avoid any misunderstandings, I would change the description and > take out the "mp3" in there. For instance: > > Graveman! provides a graphical user interface for handling common CD/DVD > burning tasks. It can burn Audio CDs, Data CDs and DVDs, duplicate CDs, > and clean rewritable CD/DVD media. > Done. Would it be possible that livna carry a version with mp3 enabled, that would override the version in Extras, if a user has the livna repo? -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From dwmw2 at infradead.org Sun Feb 27 16:09:48 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 27 Feb 2005 16:09:48 +0000 Subject: Request for package import: graveman In-Reply-To: <1109519559.9674.2.camel@scriabin.tannenrauch.ch> References: <1109446577.27498.0.camel@scriabin.tannenrauch.ch> <20050227163333.104a7e3a.bugs.michael@gmx.net> <1109519559.9674.2.camel@scriabin.tannenrauch.ch> Message-ID: <1109520588.27107.32.camel@localhost.localdomain> On Sun, 2005-02-27 at 16:52 +0100, G?rard Milmeister wrote: >Would it be possible that livna carry a version with mp3 enabled, that >would override the version in Extras, if a user has the livna repo? Or just make it use a plugin mp3 library _if_ such is available, like xmms does? -- dwmw2 From ivazquez at ivazquez.net Sun Feb 27 16:14:47 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 27 Feb 2005 11:14:47 -0500 Subject: Request for package import: graveman In-Reply-To: <1109520588.27107.32.camel@localhost.localdomain> References: <1109446577.27498.0.camel@scriabin.tannenrauch.ch> <20050227163333.104a7e3a.bugs.michael@gmx.net> <1109519559.9674.2.camel@scriabin.tannenrauch.ch> <1109520588.27107.32.camel@localhost.localdomain> Message-ID: <1109520887.19590.1.camel@localhost.localdomain> On Sun, 2005-02-27 at 16:09 +0000, David Woodhouse wrote: > On Sun, 2005-02-27 at 16:52 +0100, G?rard Milmeister wrote: > >Would it be possible that livna carry a version with mp3 enabled, that > >would override the version in Extras, if a user has the livna repo? > > Or just make it use a plugin mp3 library _if_ such is available, like > xmms does? Unfortunately it's not. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ -------------- next part -------------- A non-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 Feb 27 16:38:28 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 27 Feb 2005 17:38:28 +0100 Subject: Request for package import: graveman In-Reply-To: <1109519559.9674.2.camel@scriabin.tannenrauch.ch> References: <1109446577.27498.0.camel@scriabin.tannenrauch.ch> <20050227163333.104a7e3a.bugs.michael@gmx.net> <1109519559.9674.2.camel@scriabin.tannenrauch.ch> Message-ID: <20050227173828.3def382d.bugs.michael@gmx.net> On Sun, 27 Feb 2005 16:52:39 +0100, G?rard Milmeister wrote: > > > http://www.ifi.unizh.ch/staff/milmei/rpms/graveman-0.3.8-1.src.rpm > > > > > > Graveman! can burn audio cd (wav, ogg, mp3), data cd and dvd, > > > duplicate cd, and clean rewritable cd and dvd. > > > > > > > To avoid any misunderstandings, I would change the description and > > take out the "mp3" in there. For instance: > > > > Graveman! provides a graphical user interface for handling common CD/DVD > > burning tasks. It can burn Audio CDs, Data CDs and DVDs, duplicate CDs, > > and clean rewritable CD/DVD media. > > > Done. > Would it be possible that livna carry a version with mp3 enabled, that > would override the version in Extras, if a user has the livna repo? AFAICT, that shouldn't be a problem, provided that fixes and updates in Fedora Extras are tracked painstakingly. Else there might be a) an upgrade race between an mp3-disabled and an mp3-enabled version, or b) the mp3-enabled upgrade would lack fixes if it got out-of-sync with updates in Fedora Extras. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.10-1.1154_FC4 loadavg: 1.06 1.03 1.11 From terraformers at gmx.net Sun Feb 27 18:54:15 2005 From: terraformers at gmx.net (Lars) Date: Sun, 27 Feb 2005 19:54:15 +0100 Subject: vice in extras Message-ID: hello it would be nice to migrate the vice commodore emulator package from fedora.us to the official extras repo. in true oldschool-gaming-spirit, L From bugs.michael at gmx.net Sun Feb 27 19:03:32 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 27 Feb 2005 20:03:32 +0100 Subject: vice in extras In-Reply-To: References: Message-ID: <20050227200332.3bd3f9ca.bugs.michael@gmx.net> On Sun, 27 Feb 2005 19:54:15 +0100, Lars wrote: > hello > > it would be nice to migrate the vice commodore emulator package from > fedora.us to the official extras repo. > > in true oldschool-gaming-spirit, > L It was decided to not include VICE because of legal concerns. Without the various "kernal" and "basic" ROM images, the VICE suite would be useless. Including tools and docs for getting the images elsewhere (like Debian do it), would not remove the legal concerns. From skvidal at phy.duke.edu Sun Feb 27 19:52:39 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 27 Feb 2005 14:52:39 -0500 Subject: vice in extras In-Reply-To: References: Message-ID: <1109533959.27384.225.camel@cutter> On Sun, 2005-02-27 at 19:54 +0100, Lars wrote: >hello > >it would be nice to migrate the vice commodore emulator package from >fedora.us to the official extras repo. > >in true oldschool-gaming-spirit, vice was removed from fedora extras b/c of potential legal issues. -sv From terraformers at gmx.net Sun Feb 27 19:49:40 2005 From: terraformers at gmx.net (Lars) Date: Sun, 27 Feb 2005 20:49:40 +0100 Subject: vice in extras References: <20050227200332.3bd3f9ca.bugs.michael@gmx.net> Message-ID: Michael Schwendt wrote: > On Sun, 27 Feb 2005 19:54:15 +0100, Lars wrote: > >> hello >> >> it would be nice to migrate the vice commodore emulator package from >> fedora.us to the official extras repo. >> >> in true oldschool-gaming-spirit, >> L > > It was decided to not include VICE because of legal concerns. Without the > various "kernal" and "basic" ROM images, the VICE suite would be > useless. Including tools and docs for getting the images elsewhere (like > Debian do it), would not remove the legal concerns. sniff but hey, ...will make my own src.rpm then! its completely legal for *me*, because i bought the kernel/basic with my trusty c64(hardware) :) L From cra at WPI.EDU Sun Feb 27 20:39:14 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Sun, 27 Feb 2005 15:39:14 -0500 Subject: vice in extras In-Reply-To: <1109533959.27384.225.camel@cutter> References: <1109533959.27384.225.camel@cutter> Message-ID: <20050227203914.GM21024@angus.ind.WPI.EDU> On Sun, Feb 27, 2005 at 02:52:39PM -0500, seth vidal wrote: > On Sun, 2005-02-27 at 19:54 +0100, Lars wrote: > >hello > > > >it would be nice to migrate the vice commodore emulator package from > >fedora.us to the official extras repo. > > > >in true oldschool-gaming-spirit, > > vice was removed from fedora extras b/c of potential legal issues. Aww shucks. That rules out all vintage emulators, then, one of my favorite pasttimes :( Kegs, stella, uae, ... From tcallawa at redhat.com Sun Feb 27 20:52:13 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 27 Feb 2005 14:52:13 -0600 Subject: vice in extras In-Reply-To: <20050227203914.GM21024@angus.ind.WPI.EDU> References: <1109533959.27384.225.camel@cutter> <20050227203914.GM21024@angus.ind.WPI.EDU> Message-ID: <1109537533.7400.172.camel@localhost.localdomain> On Sun, 2005-02-27 at 15:39 -0500, Chuck R. Anderson wrote: >On Sun, Feb 27, 2005 at 02:52:39PM -0500, seth vidal wrote: >> On Sun, 2005-02-27 at 19:54 +0100, Lars wrote: >> >hello >> > >> >it would be nice to migrate the vice commodore emulator package from >> >fedora.us to the official extras repo. >> > >> >in true oldschool-gaming-spirit, >> >> vice was removed from fedora extras b/c of potential legal issues. > >Aww shucks. That rules out all vintage emulators, then, one of my >favorite pasttimes :( Kegs, stella, uae, ... Unless you can get written permission from the original trademark/copyright holders, they're all forbidden. :( Hey, maybe someday, they'll slip into the public domain. When I'm 370. ~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 Sun Feb 27 21:26:11 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 27 Feb 2005 22:26:11 +0100 Subject: vice in extras In-Reply-To: <1109537533.7400.172.camel@localhost.localdomain> References: <1109533959.27384.225.camel@cutter> <20050227203914.GM21024@angus.ind.WPI.EDU> <1109537533.7400.172.camel@localhost.localdomain> Message-ID: <20050227222611.0515bc56.bugs.michael@gmx.net> On Sun, 27 Feb 2005 14:52:13 -0600, Tom 'spot' Callaway wrote: > On Sun, 2005-02-27 at 15:39 -0500, Chuck R. Anderson wrote: > >On Sun, Feb 27, 2005 at 02:52:39PM -0500, seth vidal wrote: > >> On Sun, 2005-02-27 at 19:54 +0100, Lars wrote: > >> >hello > >> > > >> >it would be nice to migrate the vice commodore emulator package from > >> >fedora.us to the official extras repo. > >> > > >> >in true oldschool-gaming-spirit, > >> > >> vice was removed from fedora extras b/c of potential legal issues. > > > >Aww shucks. That rules out all vintage emulators, then, one of my > >favorite pasttimes :( Kegs, stella, uae, ... > > Unless you can get written permission from the original > trademark/copyright holders, they're all forbidden. :( > > Hey, maybe someday, they'll slip into the public domain. When I'm 370. Although I'm not aware of any legal actions against authors of Commodore home computer emulators, such as VICE or UAE, who include the original ROM contents, these emulators are a grey area. For the trademark/copyright holders, it's a trade-off between seeing the emulators, and the scene surrounding them, as advertizing (e.g. some either pretend or believe that there's still a real market, a target group of nostalgia fans, who buy new/related products and software for the old technology) and as infringement of copyrights or patents. Occasionally, there have been reports of a few cease-and-desist letters to web sites, which offer copyrighted games for download. Excerpt from an explanation I posted elsewhere: The copyright for these images is with Commodore International BV, a subsidiary of Tulip Computers, Netherlands. The old 'Commodore' trademark has been bought by Tulip, and recently they've signed a letter of intent with California based Yeahronimo Media Ventures Inc to sell their entire Commodore subsidiary. YMV's business model increases the likelihood of actions against emulator authors and copyright infringement. From j.w.r.degoede at hhs.nl Sun Feb 27 21:49:27 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 27 Feb 2005 22:49:27 +0100 Subject: vice in extras In-Reply-To: <20050227222611.0515bc56.bugs.michael@gmx.net> References: <1109533959.27384.225.camel@cutter> <20050227203914.GM21024@angus.ind.WPI.EDU> <1109537533.7400.172.camel@localhost.localdomain> <20050227222611.0515bc56.bugs.michael@gmx.net> Message-ID: <42224067.4020407@hhs.nl> 2 questions: 1a) Are vintage hardware emulators all dubbed grey-area and thus not distributable, or only those which need / are shipped with bios ROMS? 1b) And what about those for which the BIOS / ROMS have been set free explicitly? 2) Since atleast a number of emulators are dubbed gray area, is anyone willing to host a Fedora compatible (but not Fedora) RPMS repository like livna, but then specific for emulators? I'll gladly volunteer to maintain a couple of emulator packages, xmame comes to mind :) Regards, Hans p.s. I know this might be best discussed elsewhere due to legal concerns, so: - the above is strictly my personal opinion and in way related to RedHat and/or the Fedora project - please keep possible legal concerns in mind when replying and/or reply with a private mail. Michael Schwendt wrote: > On Sun, 27 Feb 2005 14:52:13 -0600, Tom 'spot' Callaway wrote: > > >>On Sun, 2005-02-27 at 15:39 -0500, Chuck R. Anderson wrote: >> >>>On Sun, Feb 27, 2005 at 02:52:39PM -0500, seth vidal wrote: >>> >>>>On Sun, 2005-02-27 at 19:54 +0100, Lars wrote: >>>> >>>>>hello >>>>> >>>>>it would be nice to migrate the vice commodore emulator package from >>>>>fedora.us to the official extras repo. >>>>> >>>>>in true oldschool-gaming-spirit, >>>> >>>>vice was removed from fedora extras b/c of potential legal issues. >>> >>>Aww shucks. That rules out all vintage emulators, then, one of my >>>favorite pasttimes :( Kegs, stella, uae, ... >> >>Unless you can get written permission from the original >>trademark/copyright holders, they're all forbidden. :( >> >>Hey, maybe someday, they'll slip into the public domain. When I'm 370. > > > Although I'm not aware of any legal actions against authors of Commodore > home computer emulators, such as VICE or UAE, who include the original ROM > contents, these emulators are a grey area. For the trademark/copyright > holders, it's a trade-off between seeing the emulators, and the scene > surrounding them, as advertizing (e.g. some either pretend or believe that > there's still a real market, a target group of nostalgia fans, who buy > new/related products and software for the old technology) and as > infringement of copyrights or patents. Occasionally, there have been > reports of a few cease-and-desist letters to web sites, which offer > copyrighted games for download. > > Excerpt from an explanation I posted elsewhere: > > The copyright for these images is with Commodore International BV, a > subsidiary of Tulip Computers, Netherlands. The old 'Commodore' trademark > has been bought by Tulip, and recently they've signed a letter of intent > with California based Yeahronimo Media Ventures Inc to sell their entire > Commodore subsidiary. YMV's business model increases the likelihood of > actions against emulator authors and copyright infringement. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From pcompton at proteinmedia.com Sun Feb 27 22:07:17 2005 From: pcompton at proteinmedia.com (Phillip Compton) Date: Sun, 27 Feb 2005 17:07:17 -0500 Subject: vice in extras In-Reply-To: <42224067.4020407@hhs.nl> References: <1109533959.27384.225.camel@cutter> <20050227203914.GM21024@angus.ind.WPI.EDU> <1109537533.7400.172.camel@localhost.localdomain> <20050227222611.0515bc56.bugs.michael@gmx.net> <42224067.4020407@hhs.nl> Message-ID: <1109542037.5262.3.camel@earlgrey.compton.net> On Sun, 2005-02-27 at 22:49 +0100, Hans de Goede wrote: > 2) Since atleast a number of emulators are dubbed gray area, is anyone > willing to host a Fedora compatible (but not Fedora) RPMS repository > like livna, but then specific for emulators? I'll gladly volunteer to > maintain a couple of emulator packages, xmame comes to mind :) Why not just host them at livna? I don't see reason to create yet another 3rd party repo. Phil From tcallawa at redhat.com Sun Feb 27 22:48:23 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 27 Feb 2005 16:48:23 -0600 Subject: vice in extras In-Reply-To: <42224067.4020407@hhs.nl> References: <1109533959.27384.225.camel@cutter> <20050227203914.GM21024@angus.ind.WPI.EDU> <1109537533.7400.172.camel@localhost.localdomain> <20050227222611.0515bc56.bugs.michael@gmx.net> <42224067.4020407@hhs.nl> Message-ID: <1109544504.7400.173.camel@localhost.localdomain> On Sun, 2005-02-27 at 22:49 +0100, Hans de Goede wrote: >1b) And what about those for which the BIOS / ROMS have been set free >explicitly? If its in writing, we can pass it through Red Hat legal. ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From rc040203 at freenet.de Mon Feb 28 07:09:28 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 28 Feb 2005 08:09:28 +0100 Subject: vice in extras In-Reply-To: <20050227200332.3bd3f9ca.bugs.michael@gmx.net> References: <20050227200332.3bd3f9ca.bugs.michael@gmx.net> Message-ID: <1109574569.15959.660.camel@mccallum.corsepiu.local> On Sun, 2005-02-27 at 20:03 +0100, Michael Schwendt wrote: > On Sun, 27 Feb 2005 19:54:15 +0100, Lars wrote: > > > hello > > > > it would be nice to migrate the vice commodore emulator package from > > fedora.us to the official extras repo. > > > > in true oldschool-gaming-spirit, > > L > > It was decided to not include VICE because of legal concerns. Without the > various "kernal" and "basic" ROM images, the VICE suite would be > useless. Including tools and docs for getting the images elsewhere (like > Debian do it), would not remove the legal concerns. How that? How can something be illegal for Fedora, if Debian doesn't consider it illegal? I always thought Debian was more religious about legal issues than Fedora? Could it be that I am wrong? Ralf From funkyres at gmail.com Mon Feb 28 07:12:54 2005 From: funkyres at gmail.com (Michael Peters) Date: Sun, 27 Feb 2005 23:12:54 -0800 Subject: vice in extras In-Reply-To: <1109574569.15959.660.camel@mccallum.corsepiu.local> References: <20050227200332.3bd3f9ca.bugs.michael@gmx.net> <1109574569.15959.660.camel@mccallum.corsepiu.local> Message-ID: <485bb88405022723123643beed@mail.gmail.com> On Mon, 28 Feb 2005 08:09:28 +0100, Ralf Corsepius wrote: > On Sun, 2005-02-27 at 20:03 +0100, Michael Schwendt wrote: > > On Sun, 27 Feb 2005 19:54:15 +0100, Lars wrote: > > > > > hello > > > > > > it would be nice to migrate the vice commodore emulator package from > > > fedora.us to the official extras repo. > > > > > > in true oldschool-gaming-spirit, > > > L > > > > It was decided to not include VICE because of legal concerns. Without the > > various "kernal" and "basic" ROM images, the VICE suite would be > > useless. Including tools and docs for getting the images elsewhere (like > > Debian do it), would not remove the legal concerns. > How that? > > How can something be illegal for Fedora, if Debian doesn't consider it > illegal? > > I always thought Debian was more religious about legal issues than > Fedora? Could it be that I am wrong? Debian's lawyers are not Fedora's lawyers. Anyway - I think Debian has some stuff that is distributed only from non US ftp servers to avoid US distribution laws. -- http://mpeters.us/ From j.w.r.degoede at hhs.nl Mon Feb 28 07:43:21 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 28 Feb 2005 08:43:21 +0100 Subject: vice in extras In-Reply-To: <1109542037.5262.3.camel@earlgrey.compton.net> References: <1109533959.27384.225.camel@cutter> <20050227203914.GM21024@angus.ind.WPI.EDU> <1109537533.7400.172.camel@localhost.localdomain> <20050227222611.0515bc56.bugs.michael@gmx.net> <42224067.4020407@hhs.nl> <1109542037.5262.3.camel@earlgrey.compton.net> Message-ID: <4222CB99.9020705@hhs.nl> Phillip Compton wrote: > On Sun, 2005-02-27 at 22:49 +0100, Hans de Goede wrote: > > >>2) Since atleast a number of emulators are dubbed gray area, is anyone >>willing to host a Fedora compatible (but not Fedora) RPMS repository >>like livna, but then specific for emulators? I'll gladly volunteer to >>maintain a couple of emulator packages, xmame comes to mind :) > > > Why not just host them at livna? I don't see reason to create yet > another 3rd party repo. > Because I've already asked there and the people of livna concider emulators legally more of a problem then patent encumbered software, since they live in the real free world (iow not the US) they might be right. Regards, Hans From wtogami at redhat.com Mon Feb 28 08:12:34 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 27 Feb 2005 22:12:34 -1000 Subject: vice in extras In-Reply-To: <4222CB99.9020705@hhs.nl> References: <1109533959.27384.225.camel@cutter> <20050227203914.GM21024@angus.ind.WPI.EDU> <1109537533.7400.172.camel@localhost.localdomain> <20050227222611.0515bc56.bugs.michael@gmx.net> <42224067.4020407@hhs.nl> <1109542037.5262.3.camel@earlgrey.compton.net> <4222CB99.9020705@hhs.nl> Message-ID: <4222D272.1050809@redhat.com> Hans de Goede wrote: >> > > Because I've already asked there and the people of livna concider > emulators legally more of a problem then patent encumbered software, > since they live in the real free world (iow not the US) they might be > right. Software patents and copyrights are entirely different. Warren Togami wtogami at redhat.com From adrian at lisas.de Mon Feb 28 08:20:53 2005 From: adrian at lisas.de (Adrian Reber) Date: Mon, 28 Feb 2005 09:20:53 +0100 Subject: Package proposal: vnstat In-Reply-To: <1109266345.5990.20.camel@localhost.localdomain> References: <20050224110355.GA30936@lisas.de> <1109266345.5990.20.camel@localhost.localdomain> Message-ID: <20050228082053.GA22226@lisas.de> Matthias, Thorsten, thanks for your feedback. I have made now a new version which can be found at: http://lisas.de/~adrian/rpm/vnstat-1.4-2.src.rpm I tried to address most of the points you mentioned: On Thu, Feb 24, 2005 at 12:55:41PM +0100, Matthias Saou wrote: > Also, maybe have the cron entry use a sysconfig file with a list of > interfaces to watch (defaulting to only eth0) would be a good idea? There is a now file in sysconfig to do the configuration. The cron entry doesn't now directly call the binary but a script which handles the file in sysconfig and executes vnstat with the defined options. On Thu, Feb 24, 2005 at 06:32:24PM +0100, Thorsten Leemhuis wrote: > Is the crontab entry really needed? Not everyone wants to monitor eth0. > Also if you accidentally create a database as root after install > (because you don't now yet that there is a vnstat user and the cron job) > the cron job will fail cause the database-files are owned by root... In the crontab and in the sysconfig file vnstat is now disabled as default. > Also the upstream documentation isn't very good AFAIK. The FAQ online > is a bit better -- maybe we should include it? The included file FAQ in > the %docs contains only a link to the faq online. But the FAQ is also > not perfect: I have included the online FAQ, the INSTALL file as well as the example cron and pppd files in %doc. Adrian -- Adrian Reber http://lisas.de/~adrian/ "Facts are meaningless. You could use facts to prove anything that's even remotely true!" -- Homer Simpson From j.w.r.degoede at hhs.nl Mon Feb 28 08:40:34 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 28 Feb 2005 09:40:34 +0100 Subject: vice in extras In-Reply-To: <4222D272.1050809@redhat.com> References: <1109533959.27384.225.camel@cutter> <20050227203914.GM21024@angus.ind.WPI.EDU> <1109537533.7400.172.camel@localhost.localdomain> <20050227222611.0515bc56.bugs.michael@gmx.net> <42224067.4020407@hhs.nl> <1109542037.5262.3.camel@earlgrey.compton.net> <4222CB99.9020705@hhs.nl> <4222D272.1050809@redhat.com> Message-ID: <4222D902.3040005@hhs.nl> Warren Togami wrote: > Hans de Goede wrote: > >>> >> >> Because I've already asked there and the people of livna concider >> emulators legally more of a problem then patent encumbered software, >> since they live in the real free world (iow not the US) they might be >> right. > > > Software patents and copyrights are entirely different. > Agreed, Distributing emulators with copyrighted rom images without permission isn't really gray anymore, but just plain wrong, but what about distributing emulators without any roms. Take for example xmame (x.mame.net) I know the license alone is enough reason not to distribute it (not for commercial use), but for the sake of the discussion lets pretend it has an osi approved license, since it doesn't come with any roms (the current license even explicitly forbids distributing it together with roms) could we distribute this? Notice, there are even a couple of roms which xmame can use which have been put in the public domain by their copyright holders. --- And what if we could get a written permession from the current copyright holders, I'm willing to try to find who currently owns the copyrights on the cbm roms, if I get a written waiver, could vice since it otherwise has an osi approved license be distributed then? --- And what if the current copyright holders can't be found? Commodore has been through a lot of hands? --- Please don't get me wrong I may seem to be trying to get Fedora to engage into legally gray activities but thats absolutly not what I want, I just want to establish where legally gray begins. And as a big fan of vintage computing / emulators I would like to get (some) emulators into Fedora Extras if this is legally ok. Regards, Hans From nicolas.mailhot at laposte.net Mon Feb 28 09:18:03 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 28 Feb 2005 10:18:03 +0100 (CET) Subject: vice in extras In-Reply-To: <4222D902.3040005@hhs.nl> References: <1109533959.27384.225.camel@cutter> <20050227203914.GM21024@angus.ind.WPI.EDU> <1109537533.7400.172.camel@localhost.localdomain> <20050227222611.0515bc56.bugs.michael@gmx.net> <42224067.4020407@hhs.nl> <1109542037.5262.3.camel@earlgrey.compton.net> <4222CB99.9020705@hhs.nl> <4222D272.1050809@redhat.com> <4222D902.3040005@hhs.nl> Message-ID: <35590.192.54.193.137.1109582283.squirrel@rousalka.dyndns.org> On Lun 28 f?vrier 2005 9:40, Hans de Goede a ?crit : > Take for example xmame (x.mame.net) I know the license alone is enough > reason not to distribute it (not for commercial use), but for the sake > of the discussion lets pretend it has an osi approved license, since it > doesn't come with any roms (the current license even explicitly forbids > distributing it together with roms) could we distribute this? To take a concrete example, I'm pretty sure there are at least a few 100% free games/demoes for the SNES out there (written by the same people who did translation work on a original japanese games) but I'm also sure distribution of any snes emulator even with bundled free roms would invite instant litigation (even if everyone knew it was baseless, just to harass console emulators distributors and make sure no one wants to do it) Regards, -- Nicolas Mailhot From bugs.michael at gmx.net Mon Feb 28 09:53:06 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 28 Feb 2005 10:53:06 +0100 Subject: vice in extras In-Reply-To: <485bb88405022723123643beed@mail.gmail.com> References: <20050227200332.3bd3f9ca.bugs.michael@gmx.net> <1109574569.15959.660.camel@mccallum.corsepiu.local> <485bb88405022723123643beed@mail.gmail.com> Message-ID: <20050228105306.3f0499b1.bugs.michael@gmx.net> On Sun, 27 Feb 2005 23:12:54 -0800, Michael Peters wrote: > > > > it would be nice to migrate the vice commodore emulator package from > > > > fedora.us to the official extras repo. > > > > > > > > in true oldschool-gaming-spirit, > > > > L > > > > > > It was decided to not include VICE because of legal concerns. Without the > > > various "kernal" and "basic" ROM images, the VICE suite would be > > > useless. Including tools and docs for getting the images elsewhere (like > > > Debian do it), would not remove the legal concerns. > > > > How that? > > > > How can something be illegal for Fedora, if Debian doesn't consider it > > illegal? > > > > I always thought Debian was more religious about legal issues than > > Fedora? Could it be that I am wrong? > > Debian's lawyers are not Fedora's lawyers. > Anyway - I think Debian has some stuff that is distributed only from > non US ftp servers to avoid US distribution laws. Well, no actual laywers were contacted with regard to VICE and Fedora Extras. The statement The ROM files in the `C128', `C64', `CBM-II', `DRIVES', `PET', `PLUS4' `PRINTER' and `VIC20' directories are Copyright C by Commodore Business Machines. at the end of a GPL header just doesn't cut it, if there is no written consent which permits redistribution, use of trademarks and possibly even use of the ROMs. What may work for the Debian people would only mean "a crippled application in Fedora Extras, which doesn't work out-of-the-box". In the worst case, with no accompanying documentation on where to get missing ROM image files and where to put them. That reduces the application's target group severely. The Debian package contains this note (somewhat out-of-date, see my previous message in this thread): + This package does not contain the various ROM images needed to + actually use the emulators but includes a script which will attempt + to download them from a number of well-known locations. A corporation + in the Netherlands called Tulip holds the copyrights to the ROM + images, and redistribution is not permitted; VICE itself is + unencumbered. Things like contributory infringement given, I don't think that linking an FTP site would be a good idea. Particularly not if the linked site explicitly points to another site which hosts copyrighted non-distributable game images. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.10-1.1154_FC4 loadavg: 0.01 0.08 0.08 From bugs.michael at gmx.net Mon Feb 28 10:05:43 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 28 Feb 2005 11:05:43 +0100 Subject: vice in extras In-Reply-To: <4222D902.3040005@hhs.nl> References: <1109533959.27384.225.camel@cutter> <20050227203914.GM21024@angus.ind.WPI.EDU> <1109537533.7400.172.camel@localhost.localdomain> <20050227222611.0515bc56.bugs.michael@gmx.net> <42224067.4020407@hhs.nl> <1109542037.5262.3.camel@earlgrey.compton.net> <4222CB99.9020705@hhs.nl> <4222D272.1050809@redhat.com> <4222D902.3040005@hhs.nl> Message-ID: <20050228110543.25870c76.bugs.michael@gmx.net> On Mon, 28 Feb 2005 09:40:34 +0100, Hans de Goede wrote: > Distributing emulators with copyrighted rom images without permission > isn't really gray anymore, but just plain wrong, but what about > distributing emulators without any roms. It's complicated if you cannot include documentation which contains pointers to the ROMs. Even including the emulator's home page might be a problem if it contains such pointers. The fact that most emulators are based on reengineering, is a problem already. You better support the upstream project itself and provide full-blown packages there. That would be enough to make the target group happy. > And what if we could get a written permession from the current copyright > holders, I'm willing to try to find who currently owns the copyrights on > the cbm roms, if I get a written waiver, could vice since it otherwise > has an osi approved license be distributed then? > > --- > > And what if the current copyright holders can't be found? Commodore has > been through a lot of hands? Try it. Find out what they say about it. See my message from yesterday. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.10-1.1154_FC4 loadavg: 0.34 0.32 0.18 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 28 10:16:02 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 28 Feb 2005 11:16:02 +0100 Subject: Package proposal: vnstat In-Reply-To: <20050228082053.GA22226@lisas.de> References: <20050224110355.GA30936@lisas.de> <1109266345.5990.20.camel@localhost.localdomain> <20050228082053.GA22226@lisas.de> Message-ID: <20050228111602.4b55239f@python2> Adrian Reber wrote : > thanks for your feedback. I have made now a new version which can be > found at: http://lisas.de/~adrian/rpm/vnstat-1.4-2.src.rpm Neat! One thing, though : I'd drop the VNSTAT_DISABLED option altogether, as having the cron job commented out by default is enough to not have it running unexpectedly, and keep the sysconfig entry jut for the options. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3.radeon Load : 1.37 1.71 1.45 From adrian at lisas.de Mon Feb 28 14:49:30 2005 From: adrian at lisas.de (Adrian Reber) Date: Mon, 28 Feb 2005 15:49:30 +0100 Subject: bug #149713 Message-ID: <20050228144930.GA9515@lisas.de> Maybe someone can give me some advice how to handle following bug: https://bugzilla.redhat.com/beta/show_bug.cgi?id=149713 The fix for this bug is trivial but I would like to here some input from others how to handle this situation. Do I just fix it? Should I contact upstream? Do ignore it, because it only happens with the Intel compiler? Adrian -- Adrian Reber http://lisas.de/~adrian/ "Wait a second, aren't you a member of the yacht club?" -Bender "My God, you're right. I'm a class 3 yacht." -Countess de la Roca From adrian at lisas.de Mon Feb 28 14:56:34 2005 From: adrian at lisas.de (Adrian Reber) Date: Mon, 28 Feb 2005 15:56:34 +0100 Subject: Package proposal: vnstat In-Reply-To: <20050228111602.4b55239f@python2> References: <20050224110355.GA30936@lisas.de> <1109266345.5990.20.camel@localhost.localdomain> <20050228082053.GA22226@lisas.de> <20050228111602.4b55239f@python2> Message-ID: <20050228145634.GA14946@lisas.de> On Mon, Feb 28, 2005 at 11:16:02AM +0100, Matthias Saou wrote: > > thanks for your feedback. I have made now a new version which can be > > found at: http://lisas.de/~adrian/rpm/vnstat-1.4-2.src.rpm > > Neat! > One thing, though : I'd drop the VNSTAT_DISABLED option altogether, as > having the cron job commented out by default is enough to not have it > running unexpectedly, and keep the sysconfig entry jut for the options. I dropped the VNSTAT_DISABLED option and will import following into CVS if there are no further objections: http://lisas.de/~adrian/rpm/vnstat-1.4-3.src.rpm Adrian From pmatilai at welho.com Mon Feb 28 15:05:45 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Mon, 28 Feb 2005 17:05:45 +0200 (EET) Subject: bug #149713 In-Reply-To: <20050228144930.GA9515@lisas.de> References: <20050228144930.GA9515@lisas.de> Message-ID: On Mon, 28 Feb 2005, Adrian Reber wrote: > > Maybe someone can give me some advice how to handle following bug: > > https://bugzilla.redhat.com/beta/show_bug.cgi?id=149713 > > The fix for this bug is trivial but I would like to here some input from > others how to handle this situation. Do I just fix it? Should I contact > upstream? Do ignore it, because it only happens with the Intel compiler? I've gotten a few similar bug reports from the same reporter and been wondering what to do with them as well :) IMHO these kind of fixes belong to upstream and that's where they should be reported to begin with, patching FE packages to shut up compiler warnings (especially when talking about a non FC compiler) isn't perhaps the most productive use of packagers' time. - Panu - From tcallawa at redhat.com Mon Feb 28 15:08:13 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 28 Feb 2005 09:08:13 -0600 Subject: bug #149713 In-Reply-To: References: <20050228144930.GA9515@lisas.de> Message-ID: <1109603293.7400.183.camel@localhost.localdomain> On Mon, 2005-02-28 at 17:05 +0200, Panu Matilainen wrote: >I've gotten a few similar bug reports from the same reporter and been >wondering what to do with them as well :) > >IMHO these kind of fixes belong to upstream and that's where they should >be reported to begin with I agree, ICC bugs should be redirected upstream, until that time that we build with ICC (or gcc starts triggering these bugs). ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From dwmw2 at infradead.org Mon Feb 28 15:13:50 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 28 Feb 2005 15:13:50 +0000 Subject: bug #149713 In-Reply-To: References: <20050228144930.GA9515@lisas.de> Message-ID: <1109603631.22578.10.camel@hades.cambridge.redhat.com> On Mon, 2005-02-28 at 17:05 +0200, Panu Matilainen wrote: > IMHO these kind of fixes belong to upstream and that's where they should > be reported to begin with, patching FE packages to shut up compiler > warnings (especially when talking about a non FC compiler) isn't perhaps > the most productive use of packagers' time. Some compiler warnings warn of harmless things, but this one looks like a real bug. As it happens, it looks like the references to gc[3] will actually affect the variable 'use_gc', with unpredictable results. Probably worth fixing and sending the patch upstream in this case. -- dwmw2 From bugs.michael at gmx.net Mon Feb 28 15:24:57 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 28 Feb 2005 16:24:57 +0100 Subject: bug #149713 In-Reply-To: <20050228144930.GA9515@lisas.de> References: <20050228144930.GA9515@lisas.de> Message-ID: <20050228162457.41e7ae11.bugs.michael@gmx.net> On Mon, 28 Feb 2005 15:49:30 +0100, Adrian Reber wrote: > > Maybe someone can give me some advice how to handle following bug: > > https://bugzilla.redhat.com/beta/show_bug.cgi?id=149713 > > The fix for this bug is trivial but I would like to here some input from > others how to handle this situation. Do I just fix it? Should I contact > upstream? Do ignore it, because it only happens with the Intel compiler? The answer is "Maybe" to all three questions. The reporter is trying to rebuild all of Extras, looking for compiler warnings. While compilers can be wrong (example: uninitialized variables passed by reference; another example: code which is compiled but never executed at run-time; another example: a missing catch-all rule in a function which is never called with arguments outside its well-defined domain), "array subscript out of range" can lead to memory corruption (write-access beyond array boundary) or undefined behaviour (read-access outside array range). After verifying the compiler's warnings, such reports should be forwarded to upstream developers and are worth fixing, if the code is executed. From tcallawa at redhat.com Mon Feb 28 15:30:35 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 28 Feb 2005 09:30:35 -0600 Subject: vice in extras In-Reply-To: <4222D902.3040005@hhs.nl> References: <1109533959.27384.225.camel@cutter> <20050227203914.GM21024@angus.ind.WPI.EDU> <1109537533.7400.172.camel@localhost.localdomain> <20050227222611.0515bc56.bugs.michael@gmx.net> <42224067.4020407@hhs.nl> <1109542037.5262.3.camel@earlgrey.compton.net> <4222CB99.9020705@hhs.nl> <4222D272.1050809@redhat.com> <4222D902.3040005@hhs.nl> Message-ID: <1109604636.7400.189.camel@localhost.localdomain> On Mon, 2005-02-28 at 09:40 +0100, Hans de Goede wrote: >Distributing emulators with copyrighted rom images without permission >isn't really gray anymore, but just plain wrong, but what about >distributing emulators without any roms. No. Because its still legal gray area. Contributory infringement is the very definition of "legal gray area". Unless you can get written approval for unlimited open source distribution from the trademark/copyright holders for both the machine being emulated and the ROMS it would run, it can't live here. I love vintage computing and emulation too, but unlike Debian, Red Hat CAN get sued. ~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 pmatilai at welho.com Mon Feb 28 15:40:10 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Mon, 28 Feb 2005 17:40:10 +0200 (EET) Subject: bug #149713 In-Reply-To: <20050228162457.41e7ae11.bugs.michael@gmx.net> References: <20050228144930.GA9515@lisas.de> <20050228162457.41e7ae11.bugs.michael@gmx.net> Message-ID: On Mon, 28 Feb 2005, Michael Schwendt wrote: > On Mon, 28 Feb 2005 15:49:30 +0100, Adrian Reber wrote: > >> >> Maybe someone can give me some advice how to handle following bug: >> >> https://bugzilla.redhat.com/beta/show_bug.cgi?id=149713 >> >> The fix for this bug is trivial but I would like to here some input from >> others how to handle this situation. Do I just fix it? Should I contact >> upstream? Do ignore it, because it only happens with the Intel compiler? > > The answer is "Maybe" to all three questions. > > The reporter is trying to rebuild all of Extras, looking for compiler > warnings. While compilers can be wrong (example: uninitialized variables > passed by reference; another example: code which is compiled but never > executed at run-time; another example: a missing catch-all rule in a > function which is never called with arguments outside its well-defined > domain), "array subscript out of range" can lead to memory corruption > (write-access beyond array boundary) or undefined behaviour (read-access > outside array range). > > After verifying the compiler's warnings, such reports should be forwarded > to upstream developers and are worth fixing, if the code is executed. I don't think we can expect an extras packager to fix upstream bugs in the code, packagers deal with *packaging* bugs. If the packager *can* fix bugs (and certainly many can, to some extent at least) then fine, but me thinks things like this can safely be closed with "please report upstream instead" unless the bug is caused by FE-specific changes to the software. - Panu - From dwmw2 at infradead.org Mon Feb 28 16:04:09 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 28 Feb 2005 16:04:09 +0000 Subject: bug #149713 In-Reply-To: References: <20050228144930.GA9515@lisas.de> <20050228162457.41e7ae11.bugs.michael@gmx.net> Message-ID: <1109606649.22578.20.camel@hades.cambridge.redhat.com> On Mon, 2005-02-28 at 17:40 +0200, Panu Matilainen wrote: > I don't think we can expect an extras packager to fix upstream bugs in the > code, packagers deal with *packaging* bugs. If the packager *can* fix bugs > (and certainly many can, to some extent at least) then fine, but me thinks > things like this can safely be closed with "please report upstream > instead" unless the bug is caused by FE-specific changes to the software. In the case of _real_ bugs, I disagree. Part of the job of packaging is to make sure bugs get fixed and fed upstream. It's not just grunt-work. -- dwmw2 From bugs.michael at gmx.net Mon Feb 28 16:11:30 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 28 Feb 2005 17:11:30 +0100 Subject: bug #149713 In-Reply-To: References: <20050228144930.GA9515@lisas.de> <20050228162457.41e7ae11.bugs.michael@gmx.net> Message-ID: <20050228171130.1c1ef4b9.bugs.michael@gmx.net> On Mon, 28 Feb 2005 17:40:10 +0200 (EET), Panu Matilainen wrote: > > After verifying the compiler's warnings, such reports should be forwarded > > to upstream developers and are worth fixing, if the code is executed. > > I don't think we can expect an extras packager to fix upstream bugs in the > code, packagers deal with *packaging* bugs. If the packager *can* fix bugs > (and certainly many can, to some extent at least) then fine, My definition of "packager" and "package maintainer" is different, and I've seen other community people see it like me. Enough insight into the code (or programming language) provided, a _package maintainer_ fixes bugs to improve the overall package. This ranges from fixes for C/C++ Standard issues (e.g. compiler rejecting older code) to fixes for bugs causing segmentation faults or other run-time defects. I'd rather increase the array size by one element than compile code which writes beyond the array boundary. > but me thinks > things like this can safely be closed with "please report upstream > instead" unless the bug is caused by FE-specific changes to the software. The reporter expects to reach package maintainers, who keep contact with the various upstream project developers. Otherwise he would not spend the time on doing these test builds. He would not look up the contact addresses or bug tracking databases for dozens (at the worst case several hundreds) of projects. If you expect him to report the bugs upstream and he doesn't do it, it may be that the same old bugs bite you in the future and cause run-time misbehaviour. This is his way of trying to help. Yes, I realise that it fans out the bug traffic. A single reporter in a single bug database -> many package maintainers forwarding the bugs to multiple upstream projects. -- Fedora Core release Rawhide (Rawhide) - Linux 2.6.10-1.1155_FC4 loadavg: 0.15 0.06 0.08 From rc040203 at freenet.de Mon Feb 28 16:44:05 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 28 Feb 2005 17:44:05 +0100 Subject: bug #149713 In-Reply-To: <1109606649.22578.20.camel@hades.cambridge.redhat.com> References: <20050228144930.GA9515@lisas.de> <20050228162457.41e7ae11.bugs.michael@gmx.net> <1109606649.22578.20.camel@hades.cambridge.redhat.com> Message-ID: <1109609045.15959.694.camel@mccallum.corsepiu.local> On Mon, 2005-02-28 at 16:04 +0000, David Woodhouse wrote: > On Mon, 2005-02-28 at 17:40 +0200, Panu Matilainen wrote: > > I don't think we can expect an extras packager to fix upstream bugs in the > > code, packagers deal with *packaging* bugs. If the packager *can* fix bugs > > (and certainly many can, to some extent at least) then fine, but me thinks > > things like this can safely be closed with "please report upstream > > instead" unless the bug is caused by FE-specific changes to the software. > > In the case of _real_ bugs, I disagree. Part of the job of packaging is > to make sure bugs get fixed and fed upstream. It's not just grunt-work. ACK. In this case (if the reporter's description is correct - I did not check the code.) it is a _real_ bug. Ralf From rc040203 at freenet.de Mon Feb 28 16:50:45 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 28 Feb 2005 17:50:45 +0100 Subject: vice in extras In-Reply-To: <1109604636.7400.189.camel@localhost.localdomain> References: <1109533959.27384.225.camel@cutter> <20050227203914.GM21024@angus.ind.WPI.EDU> <1109537533.7400.172.camel@localhost.localdomain> <20050227222611.0515bc56.bugs.michael@gmx.net> <42224067.4020407@hhs.nl> <1109542037.5262.3.camel@earlgrey.compton.net> <4222CB99.9020705@hhs.nl> <4222D272.1050809@redhat.com> <4222D902.3040005@hhs.nl> <1109604636.7400.189.camel@localhost.localdomain> Message-ID: <1109609445.15959.702.camel@mccallum.corsepiu.local> On Mon, 2005-02-28 at 09:30 -0600, Tom 'spot' Callaway wrote: > I love vintage computing and emulation too, but unlike Debian, Red Hat > CAN get sued. How that? Copyright holders also could sue the packager of the deb/rpm, the packager of the tarballs, the sites hosting the ROMs etc. There's no guarantee for not getting sued. Besides this, if emulators dynamically load rom images (IIRC, bochs and stonX do), one could ship these emulators without ROM images, because they do not contain the code being in question. Ralf From adrian at lisas.de Mon Feb 28 16:50:59 2005 From: adrian at lisas.de (Adrian Reber) Date: Mon, 28 Feb 2005 17:50:59 +0100 Subject: bug #149713 In-Reply-To: <1109606649.22578.20.camel@hades.cambridge.redhat.com> References: <20050228144930.GA9515@lisas.de> <20050228162457.41e7ae11.bugs.michael@gmx.net> <1109606649.22578.20.camel@hades.cambridge.redhat.com> Message-ID: <20050228165059.GA20154@lisas.de> On Mon, Feb 28, 2005 at 04:04:09PM +0000, David Woodhouse wrote: > > I don't think we can expect an extras packager to fix upstream bugs in the > > code, packagers deal with *packaging* bugs. If the packager *can* fix bugs > > (and certainly many can, to some extent at least) then fine, but me thinks > > things like this can safely be closed with "please report upstream > > instead" unless the bug is caused by FE-specific changes to the software. > > In the case of _real_ bugs, I disagree. Part of the job of packaging is > to make sure bugs get fixed and fed upstream. It's not just grunt-work. Thanks for all your feedback. As the bug in this case is pretty simple to fix I will just fix it and try to get feedback from the reporter. I am not sure if I will feed it upstream because in this special case the error is in the gtk2 smooth engine which is now already part of gtk2-engines-2.6.0 where this bugs seems to be fixed. In fact all theme engines from gnome-themes-extras will be in gtk2-engines for FC4/FE4. Adrian -- Adrian Reber http://lisas.de/~adrian/ We don't really understand it, so we'll give it to the programmers. From tcallawa at redhat.com Mon Feb 28 16:53:25 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 28 Feb 2005 10:53:25 -0600 Subject: vice in extras In-Reply-To: <1109609445.15959.702.camel@mccallum.corsepiu.local> References: <1109533959.27384.225.camel@cutter> <20050227203914.GM21024@angus.ind.WPI.EDU> <1109537533.7400.172.camel@localhost.localdomain> <20050227222611.0515bc56.bugs.michael@gmx.net> <42224067.4020407@hhs.nl> <1109542037.5262.3.camel@earlgrey.compton.net> <4222CB99.9020705@hhs.nl> <4222D272.1050809@redhat.com> <4222D902.3040005@hhs.nl> <1109604636.7400.189.camel@localhost.localdomain> <1109609445.15959.702.camel@mccallum.corsepiu.local> Message-ID: <1109609605.7400.206.camel@localhost.localdomain> On Mon, 2005-02-28 at 17:50 +0100, Ralf Corsepius wrote: >On Mon, 2005-02-28 at 09:30 -0600, Tom 'spot' Callaway wrote: > >> I love vintage computing and emulation too, but unlike Debian, Red Hat >> CAN get sued. >How that? > >Copyright holders also could sue the packager of the deb/rpm, the >packager of the tarballs, the sites hosting the ROMs etc. There's no >guarantee for not getting sued. Point. What I should have said is "Red Hat is much much more likely to get sued, since we are a corporate entity, and Debian is not". Besides this, if emulators dynamically load rom images (IIRC, bochs and >stonX do), one could ship these emulators without ROM images, because >they do not contain the code being in question. Yes, but they are tools designed solely to run "illegal" ROMs. They serve no purpose otherwise. Thus, contributory infringement. We'd be providing the tools to make the "illegal" ROMS go. And that's assuming that the emus don't violate copyright or trademarks themselves (or god forbid, patents). ~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 pmatilai at welho.com Mon Feb 28 17:13:40 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Mon, 28 Feb 2005 19:13:40 +0200 Subject: bug #149713 In-Reply-To: <20050228171130.1c1ef4b9.bugs.michael@gmx.net> References: <20050228144930.GA9515@lisas.de> <20050228162457.41e7ae11.bugs.michael@gmx.net> <20050228171130.1c1ef4b9.bugs.michael@gmx.net> Message-ID: <1109610821.21481.41.camel@chip.laiskiainen.org> On Mon, 2005-02-28 at 17:11 +0100, Michael Schwendt wrote: > On Mon, 28 Feb 2005 17:40:10 +0200 (EET), Panu Matilainen wrote: > > > > After verifying the compiler's warnings, such reports should be forwarded > > > to upstream developers and are worth fixing, if the code is executed. > > > > I don't think we can expect an extras packager to fix upstream bugs in the > > code, packagers deal with *packaging* bugs. If the packager *can* fix bugs > > (and certainly many can, to some extent at least) then fine, > > My definition of "packager" and "package maintainer" is different, and > I've seen other community people see it like me. Enough insight into the > code (or programming language) provided, a _package maintainer_ fixes bugs > to improve the overall package. This ranges from fixes for C/C++ Standard > issues (e.g. compiler rejecting older code) to fixes for bugs causing > segmentation faults or other run-time defects. If Extras packagers (for Core it's IMHO different since that's being done by paid professionals) are required to be able to fix bugs in the software they package I think it should be clearly communicated somewhere instead of being left up to people's own definitions of what consists of package maintainership. > I'd rather increase the array size by one element than compile code which > writes beyond the array boundary. > > > but me thinks > > things like this can safely be closed with "please report upstream > > instead" unless the bug is caused by FE-specific changes to the software. > > The reporter expects to reach package maintainers, who keep contact with > the various upstream project developers. Otherwise he would not spend the > time on doing these test builds. He would not look up the contact > addresses or bug tracking databases for dozens (at the worst case > several hundreds) of projects. > > If you expect him to report the bugs upstream and he doesn't do it, it may > be that the same old bugs bite you in the future and cause run-time > misbehaviour. > This is his way of trying to help. Yes, I realise that it fans out the > bug traffic. A single reporter in a single bug database -> many package > maintainers forwarding the bugs to multiple upstream projects. Then again I've seen more than a few cases of "please file to upstream (bugzilla)" comments from RH package maintainers in bug reports. Where do you draw the line? My line has always been "if it's caused by my changes it's obviously my responsibility to fix, otherwise complain upstream." If that's not considered enough I think I'm out here apart from the couple of projects where I actually contribute upstream. - Panu - From bugs.michael at gmx.net Mon Feb 28 18:53:24 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 28 Feb 2005 19:53:24 +0100 Subject: bug #149713 In-Reply-To: <1109610821.21481.41.camel@chip.laiskiainen.org> References: <20050228144930.GA9515@lisas.de> <20050228162457.41e7ae11.bugs.michael@gmx.net> <20050228171130.1c1ef4b9.bugs.michael@gmx.net> <1109610821.21481.41.camel@chip.laiskiainen.org> Message-ID: <20050228195324.7715c4a5.bugs.michael@gmx.net> On Mon, 28 Feb 2005 19:13:40 +0200, Panu Matilainen wrote: > If Extras packagers (for Core it's IMHO different since that's being > done by paid professionals) are required to be able to fix bugs in the > software they package I think it should be clearly communicated > somewhere instead of being left up to people's own definitions of what > consists of package maintainership. You are not "required" to do that. You are not required to spend an awful lot of time in a debugger, hunting down bugs and trying to fix what the upstream developers could have avoided or what they should fix with the next update. You are a volunteer. Do what you like to do and what you can do. Maybe you feel better if your package contains an additional fix which makes sense and which makes run-time misbehaviour less likely. > Then again I've seen more than a few cases of "please file to upstream > (bugzilla)" comments from RH package maintainers in bug reports. Yeah, and it sucks. Especially if it's a customer of some sort, who reports the bug. Some people bought Red Hat Linux boxes, some only downloaded it for free. Those who bought the boxes and found a bug, found the bug to be in Red Hat's product, a product they paid for. They don't care whether Red Hat packaged the software made by some other vendor. The inform Red Hat that Red Hat's product has a flaw, and they assume that Red Hat has interest in fixing the product or the next version of it. Now if the customer or user is told to report it somewhere else, it is assumed that his interest in big enough to go through the efforts of travelling upstream to report a bug there (bugzilla account creation, and and and). Some do, some don't. Maybe the next customer runs into the same old bug in the next release of the product and is disappointed. Maybe two hundred other customers are satisfied because instead of fixing a series of compiler warnings, developer time was spent on fixing/improving something more important instead. > Where > do you draw the line? My line has always been "if it's caused by my > changes it's obviously my responsibility to fix, otherwise complain > upstream." If that's not considered enough I think I'm out here apart > from the couple of projects where I actually contribute upstream. Again, if the original reporter is too lazy to report it upstream, maybe the bug hits back some day. Maybe some other member of the Fedora community has more interest in the same software and likes to help make it better. Bugzilla is open for everyone. Community contributors can define queries, e.g. with which to list ticket activity of the last two weeks and then join and help where they have interest. Team work would be ideal for maintaining packages in Fedora Extras. -- Fedora Core release 3 (Heidelberg) - Linux 2.6.10-1.766_FC3 loadavg: 1.81 1.37 1.09 From skvidal at phy.duke.edu Mon Feb 28 18:59:50 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 28 Feb 2005 13:59:50 -0500 Subject: Sponsor-needing-people Message-ID: <1109617190.21503.5.camel@cutter> Hey folks, I made a wiki page for all you folks who need sponsors for cvs access. Go here: http://fedoraproject.org/wiki/Extras/SponsorsNeeded You will need to make a wiki account first. This page is editable to anyone with an account in the wiki. Please list who you are a spam-protected email address and a link to contributions you'd like to make/add. Sponsors! If you pick someone up make sure you pull them off of this page. Thanks! -sv From kevin-fedora-extras at scrye.com Mon Feb 28 19:54:44 2005 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Mon, 28 Feb 2005 12:54:44 -0700 Subject: xfce status? Message-ID: <20050228195447.E1F3C43C45@voldemort.scrye.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings. I gather from fedora-devel that the xfce packages were part of the recent move from core->extras (also from http://fedoraproject.org/wiki/Extras/OrphanedPackages#core) Do they have a maintiner in extras yet? Having recently switched my main machine (laptop) to xfce 4.2 I would be interested in maintaining/helping maintain xfce in extras if no one has. Is there a way to look up the packages -> maintainer mapping? Perhaps something in bugzilla? (I note that the xfce packages aren't showing up in bugzilla for fedora-extras yet). While I am thinking about it, is there provision for packages having multiple maintainers? Or is it expected that each package will have one maintainer that will process all the work done on the package? thanks, kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 iD8DBQFCI3cH3imCezTjY0ERAsE9AJ92cCYwPtQy/e6gmbsT3Ut8M3Z+bgCeLd9s T9zB9Pr/EMwBR8A3MZoWKfA= =T9/j -----END PGP SIGNATURE----- From sopwith at redhat.com Mon Feb 28 19:56:40 2005 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 28 Feb 2005 14:56:40 -0500 (EST) Subject: xfce status? In-Reply-To: <20050228195447.E1F3C43C45@voldemort.scrye.com> References: <20050228195447.E1F3C43C45@voldemort.scrye.com> Message-ID: On Mon, 28 Feb 2005, Kevin Fenzi wrote: > While I am thinking about it, is there provision for packages having > multiple maintainers? Or is it expected that each package will have > one maintainer that will process all the work done on the package? It really is up to the people involved with that package - there's no right or wrong way. Please feel free to join in maintaining xfce! :) -- Elliot From toshio at tiki-lounge.com Mon Feb 28 21:08:41 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 28 Feb 2005 13:08:41 -0800 Subject: bug #149713 In-Reply-To: ; from pmatilai@welho.com on Mon, Feb 28, 2005 at 05:40:10PM +0200 References: <20050228144930.GA9515@lisas.de> <20050228162457.41e7ae11.bugs.michael@gmx.net> Message-ID: <20050228130841.A25748@tiki-lounge.com> On Mon, Feb 28, 2005 at 05:40:10PM +0200, Panu Matilainen wrote: > On Mon, 28 Feb 2005, Michael Schwendt wrote: > > The reporter is trying to rebuild all of Extras, looking for compiler > > warnings. While compilers can be wrong (example: uninitialized variables > > passed by reference; another example: code which is compiled but never > > executed at run-time; another example: a missing catch-all rule in a > > function which is never called with arguments outside its well-defined > > domain), "array subscript out of range" can lead to memory corruption > > (write-access beyond array boundary) or undefined behaviour (read-access > > outside array range). > > > > After verifying the compiler's warnings, such reports should be forwarded > > to upstream developers and are worth fixing, if the code is executed. > > I don't think we can expect an extras packager to fix upstream bugs in the > code, packagers deal with *packaging* bugs. If the packager *can* fix bugs > (and certainly many can, to some extent at least) then fine, but me thinks > things like this can safely be closed with "please report upstream > instead" unless the bug is caused by FE-specific changes to the software. > Personally, if I can't fix a bug myself, I still try to take the bug report upstream. After all, if I'm going to be packaging this software for the long term, then I'm going to be interested in watching the upstream bug report to know when it's resolved. If I don't understand a reported bug or can't reproduce it, that's where I hand responsibility to the reporter to take the issue upstream (I can't report a bug I can't create) So as a general rule I think packagers are better people to report bugs upstream rather than the original reporters. And they can also fix the problem and provide a patch upstream if they're able to. I don't know that I'd say any of this should be required of a packager, though, more of a "It's good form to do it like this." -Toshio From notting at redhat.com Mon Feb 28 21:18:06 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 28 Feb 2005 16:18:06 -0500 Subject: New package for review: aqhbci-qt-tools Message-ID: <20050228211806.GH10778@nostromo.devel.redhat.com> Contains a setup widget for the HBCI support in gnucash-1.8.10 and later. Bill From gemi at bluewin.ch Mon Feb 28 21:20:01 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 28 Feb 2005 22:20:01 +0100 Subject: vice in extras In-Reply-To: <20050228110543.25870c76.bugs.michael@gmx.net> References: <1109533959.27384.225.camel@cutter> <20050227203914.GM21024@angus.ind.WPI.EDU> <1109537533.7400.172.camel@localhost.localdomain> <20050227222611.0515bc56.bugs.michael@gmx.net> <42224067.4020407@hhs.nl> <1109542037.5262.3.camel@earlgrey.compton.net> <4222CB99.9020705@hhs.nl> <4222D272.1050809@redhat.com> <4222D902.3040005@hhs.nl> <20050228110543.25870c76.bugs.michael@gmx.net> Message-ID: <1109625602.11981.0.camel@scriabin.tannenrauch.ch> On Mon, 2005-02-28 at 11:05 +0100, Michael Schwendt wrote: > You better support the upstream project itself and provide full-blown > packages there. That would be enough to make the target group happy. There is always rpmforge, if they are willing to take the risk. freshrpms.net is well-known among Fedora users. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 28 21:32:05 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 28 Feb 2005 22:32:05 +0100 Subject: New package for review: aqhbci-qt-tools In-Reply-To: <20050228211806.GH10778@nostromo.devel.redhat.com> References: <20050228211806.GH10778@nostromo.devel.redhat.com> Message-ID: <20050228223205.7b5a23f4@python2> Bill Nottingham wrote : > Contains a setup widget for the HBCI support in gnucash-1.8.10 and later. After a quick go through the spec : - The summary probably shouldn't have a trailing dot (needs to be added to guidelines, no?) to get more uniform output. - The version doesn't follow the current guidelines (sent a reply directly to the commits list, whoops) - Is the "Prefix: %{_prefix}" really needed? This _is_ a relocatable package or something? - Having [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT is useless. The BuildRoot line makes sure it can't be "/" ever, so rm -rf $RPM_BUILD_ROOT (or with %{buildroot} ;-)) is enough, shorter and clearer. - The %defattr should also contain a directory. - When directories are listed in %files, it's nice to explicitly append a "/" to identify them more easily. - There is no %changelog, this definitely should be fixed. I'm trying to not be too pedantic, but it's hard, sorry! :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3.radeon Load : 0.14 0.20 0.39 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 28 21:47:04 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 28 Feb 2005 22:47:04 +0100 Subject: Mass trivial cleanups for devel branch? Message-ID: <20050228224704.6c67db2f@python2> Hi, I've just committed changes to a few files (all the ones I could find affected) that fix the presence of 80 space lines where newlines are expected, problem usually caused when copy/pasting text inside xterms and similar. This was definitely something that needed fixing, but now this is something a bit less important : There are 284 spec files that contain at least one space to end a line, when it's not needed. So I was wondering what should be done in this kind of case? With subversion and its atomic commits, I'd be less troubled since it would mean a single email sent out... but here, this does mean 284 emails to every single subscriber of the commits list, for a change that's totally invisible! (all - lines will appear identical to the + ones! ;-)). So... does anyone have suggestions about what to do? Have it done once and for all directly on the CVS server, then be careful from there on? Disable the mail script for that particular commit? Just not do it? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3.radeon Load : 0.79 0.51 0.42 From notting at redhat.com Mon Feb 28 21:54:23 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 28 Feb 2005 16:54:23 -0500 Subject: New package for review: aqhbci-qt-tools In-Reply-To: <20050228223205.7b5a23f4@python2> References: <20050228211806.GH10778@nostromo.devel.redhat.com> <20050228223205.7b5a23f4@python2> Message-ID: <20050228215422.GK10778@nostromo.devel.redhat.com> Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > > Contains a setup widget for the HBCI support in gnucash-1.8.10 and later. > > After a quick go through the spec : > - The summary probably shouldn't have a trailing dot (needs to be added to > guidelines, no?) to get more uniform output. > - The version doesn't follow the current guidelines (sent a reply directly > to the commits list, whoops) > - Is the "Prefix: %{_prefix}" really needed? This _is_ a relocatable > package or something? > - Having [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT is useless. > The BuildRoot line makes sure it can't be "/" ever, so rm -rf > $RPM_BUILD_ROOT (or with %{buildroot} ;-)) is enough, shorter and clearer. > - The %defattr should also contain a directory. > - When directories are listed in %files, it's nice to explicitly append a > "/" to identify them more easily. > - There is no %changelog, this definitely should be fixed. Fixed. Also, ldconfig calls removed (it doesn't package libraries in standard dirs...) Bill From bugs.michael at gmx.net Mon Feb 28 22:05:17 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 28 Feb 2005 23:05:17 +0100 Subject: New package for review: aqhbci-qt-tools In-Reply-To: <20050228215422.GK10778@nostromo.devel.redhat.com> References: <20050228211806.GH10778@nostromo.devel.redhat.com> <20050228223205.7b5a23f4@python2> <20050228215422.GK10778@nostromo.devel.redhat.com> Message-ID: <20050228230517.2c2fb2b2.bugs.michael@gmx.net> On Mon, 28 Feb 2005 16:54:23 -0500, Bill Nottingham wrote: > Fixed. Also, ldconfig calls removed (it doesn't package libraries in > standard dirs...) %{_libdir}/aqbanking/plugins/ With that, %_libdir/aqbanking is not owned by the package (unowned directories can be created with wrong permissions (umask!) and would not be deleted upon package removal). Better: %dir %{_libdir}/aqbanking/ %{_libdir}/aqbanking/plugins/ or just: %{_libdir}/aqbanking/ From jpo at di.uminho.pt Mon Feb 28 22:13:11 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Mon, 28 Feb 2005 22:13:11 +0000 Subject: Mass trivial cleanups for devel branch (user/group = build) In-Reply-To: <20050228224704.6c67db2f@python2> References: <20050228224704.6c67db2f@python2> Message-ID: <42239777.8000106@di.uminho.pt> Another problem is that there are several RPMS being shipped with files belonging to the build user (and build group). Examples: * synce-devel * torc-data-* A not so quick rpm -qplv *.rpm | grep "\bbuild\b" will certain reveal others. Shall I start opening bug reports for every package that I find? 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: 252 bytes Desc: OpenPGP digital signature URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 28 22:14:45 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 28 Feb 2005 23:14:45 +0100 Subject: New package for review: aqhbci-qt-tools In-Reply-To: <20050228230517.2c2fb2b2.bugs.michael@gmx.net> References: <20050228211806.GH10778@nostromo.devel.redhat.com> <20050228223205.7b5a23f4@python2> <20050228215422.GK10778@nostromo.devel.redhat.com> <20050228230517.2c2fb2b2.bugs.michael@gmx.net> Message-ID: <20050228231445.360108fe@python2> Michael Schwendt wrote : > On Mon, 28 Feb 2005 16:54:23 -0500, Bill Nottingham wrote: > > > Fixed. Also, ldconfig calls removed (it doesn't package libraries in > > standard dirs...) Good catch! > %{_libdir}/aqbanking/plugins/ > > With that, %_libdir/aqbanking is not owned by the package [...] And another one! Gee, this reviewing process actually seems to work quite well :-D Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3.radeon Load : 1.21 0.50 0.35 From bugs.michael at gmx.net Mon Feb 28 22:15:50 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 28 Feb 2005 23:15:50 +0100 Subject: New package for review: aqhbci-qt-tools In-Reply-To: <20050228230517.2c2fb2b2.bugs.michael@gmx.net> References: <20050228211806.GH10778@nostromo.devel.redhat.com> <20050228223205.7b5a23f4@python2> <20050228215422.GK10778@nostromo.devel.redhat.com> <20050228230517.2c2fb2b2.bugs.michael@gmx.net> Message-ID: <20050228231550.288258be.bugs.michael@gmx.net> On Mon, 28 Feb 2005 23:05:17 +0100, Michael Schwendt wrote: > On Mon, 28 Feb 2005 16:54:23 -0500, Bill Nottingham wrote: > > > Fixed. Also, ldconfig calls removed (it doesn't package libraries in > > standard dirs...) > > %{_libdir}/aqbanking/plugins/ > > With that, %_libdir/aqbanking is not owned by the package Scratch that. Dependency on aqbanking package in FC4 is most likely automatic. From notting at redhat.com Mon Feb 28 22:16:40 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 28 Feb 2005 17:16:40 -0500 Subject: New package for review: aqhbci-qt-tools In-Reply-To: <20050228230517.2c2fb2b2.bugs.michael@gmx.net> References: <20050228211806.GH10778@nostromo.devel.redhat.com> <20050228223205.7b5a23f4@python2> <20050228215422.GK10778@nostromo.devel.redhat.com> <20050228230517.2c2fb2b2.bugs.michael@gmx.net> Message-ID: <20050228221640.GN10778@nostromo.devel.redhat.com> Michael Schwendt (bugs.michael at gmx.net) said: > On Mon, 28 Feb 2005 16:54:23 -0500, Bill Nottingham wrote: > > > Fixed. Also, ldconfig calls removed (it doesn't package libraries in > > standard dirs...) > > %{_libdir}/aqbanking/plugins/ Already fixed in the first batch of changes - thanks! Bill From notting at redhat.com Mon Feb 28 22:17:09 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 28 Feb 2005 17:17:09 -0500 Subject: Mass trivial cleanups for devel branch (user/group = build) In-Reply-To: <42239777.8000106@di.uminho.pt> References: <20050228224704.6c67db2f@python2> <42239777.8000106@di.uminho.pt> Message-ID: <20050228221709.GO10778@nostromo.devel.redhat.com> Jos? Pedro Oliveira (jpo at di.uminho.pt) said: > Another problem is that there are several RPMS being shipped > with files belonging to the build user (and build group). > > Examples: > * synce-devel > * torc-data-* > > A not so quick > rpm -qplv *.rpm | grep "\bbuild\b" > will certain reveal others. > > Shall I start opening bug reports for every package that I find? Either that, or just commit the fixes. :) Bill From skvidal at phy.duke.edu Mon Feb 28 22:55:35 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 28 Feb 2005 17:55:35 -0500 Subject: 2nd Announcement: Updated Package: Gnome-Blog 0.8 In-Reply-To: <1109368938.30118.5.camel@shuttle.273piedmont.org> References: <1109173256.5664.6.camel@shuttle.273piedmont.org> <1109332414.23956.4.camel@shuttle.273piedmont.org> <1109337175.16521.77.camel@cutter> <1109342632.25133.2.camel@shuttle.273piedmont.org> <1109365812.23111.40.camel@cutter> <1109368938.30118.5.camel@shuttle.273piedmont.org> Message-ID: <1109631335.21503.55.camel@cutter> On Fri, 2005-02-25 at 17:02 -0500, Brian Pepple wrote: >On Fri, 2005-02-25 at 16:10 -0500, seth vidal wrote: >> I took a look at the package you sent - it's not a huge departure from >> the one in extras cvs right now. Did you check all the build deps >> though? I thought some of them changed from 0.7 to 0.8 > >The only change is the package now requires gnome-python2-gnomevfs. >None of the Build requirements changed. The rest of the changes in the >spec had to do with clean up in regard to Python, and two patches (clean >up the byte compiled path information within the python files, and the >other to fix the x86_64 compilation). > You need to add a buildrequires on libxml2-devel, I believe. When you try to build gnome-blog from that srpm in a bare buildroot it bails out in configure about that buildreq. thanks! -sv From funkyres at gmail.com Mon Feb 28 23:10:00 2005 From: funkyres at gmail.com (Michael Peters) Date: Mon, 28 Feb 2005 15:10:00 -0800 Subject: bug #149713 In-Reply-To: <20050228195324.7715c4a5.bugs.michael@gmx.net> References: <20050228144930.GA9515@lisas.de> <20050228162457.41e7ae11.bugs.michael@gmx.net> <20050228171130.1c1ef4b9.bugs.michael@gmx.net> <1109610821.21481.41.camel@chip.laiskiainen.org> <20050228195324.7715c4a5.bugs.michael@gmx.net> Message-ID: <485bb88405022815104d95ca3b@mail.gmail.com> On Mon, 28 Feb 2005 19:53:24 +0100, Michael Schwendt wrote: > > Yeah, and it sucks. Especially if it's a customer of some sort, who > reports the bug. Some people bought Red Hat Linux boxes, some only > downloaded it for free. Those who bought the boxes and found a bug, found > the bug to be in Red Hat's product, a product they paid for. They don't > care whether Red Hat packaged the software made by some other vendor. The > inform Red Hat that Red Hat's product has a flaw, and they assume that Red > Hat has interest in fixing the product or the next version of it. Yes - if a package maintainer can duplicate the bug but can not fix it, then the package maintainer should report the bug upstream, regardless of wether or not the reporter is a "paying" customer or not. Very often when a bug is reported upstream, the response from upstream is "fixed in CVS" That doesn't do joe user a lot of good, though it may provide a way for the package maintainer to backport the fix into current - which DOES the end user a lot of good. -- http://mpeters.us/ From ville.skytta at iki.fi Mon Feb 28 23:14:35 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 01 Mar 2005 01:14:35 +0200 Subject: bug #149713 In-Reply-To: <1109610821.21481.41.camel@chip.laiskiainen.org> References: <20050228144930.GA9515@lisas.de> <20050228162457.41e7ae11.bugs.michael@gmx.net> <20050228171130.1c1ef4b9.bugs.michael@gmx.net> <1109610821.21481.41.camel@chip.laiskiainen.org> Message-ID: <1109632475.15077.67.camel@bobcat.mine.nu> On Mon, 2005-02-28 at 19:13 +0200, Panu Matilainen wrote: > Where do you draw the line? The CLOSED UPSTREAM description in Bugzilla describes pretty well IMO: https://bugzilla.redhat.com/beta/page.cgi?id=bug_status.html#resolution From bdpepple at ameritech.net Mon Feb 28 23:19:06 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Mon, 28 Feb 2005 18:19:06 -0500 Subject: 2nd Announcement: Updated Package: Gnome-Blog 0.8 In-Reply-To: <1109631335.21503.55.camel@cutter> References: <1109173256.5664.6.camel@shuttle.273piedmont.org> <1109332414.23956.4.camel@shuttle.273piedmont.org> <1109337175.16521.77.camel@cutter> <1109342632.25133.2.camel@shuttle.273piedmont.org> <1109365812.23111.40.camel@cutter> <1109368938.30118.5.camel@shuttle.273piedmont.org> <1109631335.21503.55.camel@cutter> Message-ID: <1109632746.27432.12.camel@shuttle.273piedmont.org> On Mon, 2005-02-28 at 17:55 -0500, seth vidal wrote: > You need to add a buildrequires on libxml2-devel, I believe. When you > try to build gnome-blog from that srpm in a bare buildroot it bails out > in configure about that buildreq. You sure of that? My build machine was able to build it with no problem, and it only has the following devels installed: glib2-devel.i386 2.4.8-1.fc3 installed glibc-devel.i386 2.3.4-2.fc3 installed libstdc++-devel.i386 3.4.2-6.fc3 installed pygtk2-devel.i386 2.4.0-1 installed I've also attached the build results for your review. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.20163 Patch #1 (gnome-blog_makefile.patch): Patch #2 (gnome-blog-poster.patch): Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.29427 checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for gconftool-2... /usr/bin/gconftool-2 Using config source xml::/etc/gconf/gconf.xml.defaults for schema installation Using $(sysconfdir)/gconf/schemas as install directory for schema files checking for intltool >= 0.21... 0.31.2 found checking for perl... /usr/bin/perl checking for XML::Parser... ok checking for python... /usr/bin/python checking for python version... 2.3 checking for python platform... linux2 checking for python script directory... ${prefix}/lib/python2.3/site-packages checking for python extension module directory... ${exec_prefix}/lib/python2.3/site-packages checking for pkg-config... /usr/bin/pkg-config checking for pygtk-2.0... yes checking PYGTK_CFLAGS... -I/usr/include/pygtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include checking PYGTK_LIBS... -lgobject-2.0 -lglib-2.0 checking for style of include used by make... GNU checking for i686-redhat-linux-gnu-gcc... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking dependency style of gcc... none checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for LC_MESSAGES... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking for dgettext in libc... yes checking for bind_textdomain_codeset... yes checking for msgfmt... /usr/bin/msgfmt checking for dcgettext... yes checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for catalogs to be installed... az ca cs de en_CA en_GB es et fr hr ja ms nb nl no pl pt sq sr sr at Latn sv it pt_BR uk configure: creating ./config.status config.status: creating Makefile config.status: creating gnome_blog_globals.py config.status: creating gnome-blog.spec config.status: creating protocols/Makefile config.status: creating po/Makefile.in config.status: creating config.h config.status: executing default-1 commands config.status: executing depfiles commands config.status: executing default-2 commands make all-recursive make[1]: Entering directory `/home/bpepple/rpmbuild/BUILD/gnome-blog-0.8' Making all in protocols make[2]: Entering directory `/home/bpepple/rpmbuild/BUILD/gnome-blog-0.8/protocols' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/bpepple/rpmbuild/BUILD/gnome-blog-0.8/protocols' Making all in po make[2]: Entering directory `/home/bpepple/rpmbuild/BUILD/gnome-blog-0.8/po' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/bpepple/rpmbuild/BUILD/gnome-blog-0.8/po' make[2]: Entering directory `/home/bpepple/rpmbuild/BUILD/gnome-blog-0.8' LC_ALL=C ./intltool-merge -d -u -c ./po/.intltool-merge-cache ./po gnome-blog.desktop.in gnome-blog.desktop LC_ALL=C ./intltool-merge -s -u -c ./po/.intltool-merge-cache ./po gnomeblog.schemas.in gnomeblog.schemas LC_ALL=C ./intltool-merge -o -u -c ./po/.intltool-merge-cache ./po GNOME_BlogApplet.server.in GNOME_BlogApplet.server Generating and caching the translation database Generating and caching the translation database Generating and caching the translation database Merging translations into gnomeblog.schemas. Merging translations into gnome-blog.desktop. Merging translations into GNOME_BlogApplet.server. make[2]: Leaving directory `/home/bpepple/rpmbuild/BUILD/gnome-blog-0.8' make[1]: Leaving directory `/home/bpepple/rpmbuild/BUILD/gnome-blog-0.8' Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.81901 Making install in protocols make[1]: Entering directory `/home/bpepple/rpmbuild/BUILD/gnome-blog-0.8/protocols' make[2]: Entering directory `/home/bpepple/rpmbuild/BUILD/gnome-blog-0.8/protocols' make[2]: Nothing to be done for `install-exec-am'. test -z "/usr/lib/python2.3/site-packages/gnomeblog" || mkdir -p -- "/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/python2.3/site-packages/gnomeblog" /usr/bin/install -c -m 644 'bloggerAPI.py' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/python2.3/site-packages/gnomeblog/bloggerAPI.py' /usr/bin/install -c -m 644 'MetaWeblog.py' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/python2.3/site-packages/gnomeblog/MetaWeblog.py' /usr/bin/install -c -m 644 'advogato.py' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/python2.3/site-packages/gnomeblog/advogato.py' /usr/bin/install -c -m 644 'livejournal.py' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/python2.3/site-packages/gnomeblog/livejournal.py' Byte-compiling python modules... bloggerAPI.py MetaWeblog.py advogato.py livejournal.py Byte-compiling python modules (optimized versions) ... bloggerAPI.py MetaWeblog.py advogato.py livejournal.py make[2]: Leaving directory `/home/bpepple/rpmbuild/BUILD/gnome-blog-0.8/protocols' make[1]: Leaving directory `/home/bpepple/rpmbuild/BUILD/gnome-blog-0.8/protocols' Making install in po make[1]: Entering directory `/home/bpepple/rpmbuild/BUILD/gnome-blog-0.8/po' if test -r ".././mkinstalldirs"; then \ .././mkinstalldirs /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share; \ else \ /bin/sh ../mkinstalldirs /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share; \ fi mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/az/LC_MESSAGES installing az.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/az/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/ca/LC_MESSAGES installing ca.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/ca/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/cs/LC_MESSAGES installing cs.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/cs/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/de/LC_MESSAGES installing de.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/de/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/en_CA/LC_MESSAGES installing en_CA.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/en_CA/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/en_GB/LC_MESSAGES installing en_GB.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/en_GB/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/es/LC_MESSAGES installing es.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/es/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/et/LC_MESSAGES installing et.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/et/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/fr/LC_MESSAGES installing fr.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/fr/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/hr/LC_MESSAGES installing hr.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/hr/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/ja/LC_MESSAGES installing ja.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/ja/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/ms/LC_MESSAGES installing ms.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/ms/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/nb/LC_MESSAGES installing nb.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/nb/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/nl/LC_MESSAGES installing nl.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/nl/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/no/LC_MESSAGES installing no.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/no/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/pl/LC_MESSAGES installing pl.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/pl/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/pt/LC_MESSAGES installing pt.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/pt/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/sq/LC_MESSAGES installing sq.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/sq/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/sr/LC_MESSAGES installing sr.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/sr/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/sr at Latn/LC_MESSAGES installing sr at Latn.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/sr at Latn/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/sv/LC_MESSAGES installing sv.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/sv/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/it/LC_MESSAGES installing it.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/it/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/pt_BR/LC_MESSAGES installing pt_BR.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/pt_BR/LC_MESSAGES/gnome-blog.mo mkdir -p -- /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/uk/LC_MESSAGES installing uk.gmo as /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/locale/uk/LC_MESSAGES/gnome-blog.mo if test "gnome-blog" = "glib"; then \ if test -r ".././mkinstalldirs"; then \ .././mkinstalldirs /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/glib-2.0/gettext/po; \ else \ /bin/sh ../mkinstalldirs /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/glib-2.0/gettext/po; \ fi; \ /usr/bin/install -c -m 644 ./Makefile.in.in \ /var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/glib-2.0/gettext/po/Makefile.in.in; \ else \ : ; \ fi make[1]: Leaving directory `/home/bpepple/rpmbuild/BUILD/gnome-blog-0.8/po' make[1]: Entering directory `/home/bpepple/rpmbuild/BUILD/gnome-blog-0.8' make[2]: Entering directory `/home/bpepple/rpmbuild/BUILD/gnome-blog-0.8' test -z "/usr/bin" || mkdir -p -- "/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/bin" /usr/bin/install -c 'gnome-blog-poster' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/bin/gnome-blog-poster' test -z "/usr/libexec" || mkdir -p -- "/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/libexec" /usr/bin/install -c 'blog_applet.py' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/libexec/blog_applet.py' test -z "/usr/share/applications" || mkdir -p -- "/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/applications" /usr/bin/install -c -m 644 'gnome-blog.desktop' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/applications/gnome-blog.desktop' test -z "/usr/lib/python2.3/site-packages/gnomeblog" || mkdir -p -- "/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/python2.3/site-packages/gnomeblog" /usr/bin/install -c -m 644 '__init__.py' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/python2.3/site-packages/gnomeblog/__init__.py' /usr/bin/install -c -m 644 'blog_applet.py' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/python2.3/site-packages/gnomeblog/blog_applet.py' /usr/bin/install -c -m 644 'gnome-blog-poster' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/python2.3/site-packages/gnomeblog/gnome-blog-poster' /usr/bin/install -c -m 644 'blog_poster.py' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/python2.3/site-packages/gnomeblog/blog_poster.py' /usr/bin/install -c -m 644 'aligned_window.py' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/python2.3/site-packages/gnomeblog/aligned_window.py' /usr/bin/install -c -m 644 'hig_alert.py' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/python2.3/site-packages/gnomeblog/hig_alert.py' /usr/bin/install -c -m 644 'blogger_prefs.py' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/python2.3/site-packages/gnomeblog/blogger_prefs.py' /usr/bin/install -c -m 644 'gconf_widgets.py' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/python2.3/site-packages/gnomeblog/gconf_widgets.py' /usr/bin/install -c -m 644 'blog.py' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/python2.3/site-packages/gnomeblog/blog.py' /usr/bin/install -c -m 644 'rich_entry.py' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/python2.3/site-packages/gnomeblog/rich_entry.py' /usr/bin/install -c -m 644 'html_converter.py' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/python2.3/site-packages/gnomeblog/html_converter.py' /usr/bin/install -c -m 644 'gnome_blog_globals.py' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/python2.3/site-packages/gnomeblog/gnome_blog_globals.py' /usr/bin/install -c -m 644 'proxy.py' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/python2.3/site-packages/gnomeblog/proxy.py' Byte-compiling python modules... __init__.py blog_applet.py blog_poster.py aligned_window.py hig_alert.py blogger_prefs.py gconf_widgets.py blog.py rich_entry.py html_converter.py gnome_blog_globals.py proxy.py Byte-compiling python modules (optimized versions) ... __init__.py blog_applet.py blog_poster.py aligned_window.py hig_alert.py blogger_prefs.py gconf_widgets.py blog.py rich_entry.py html_converter.py gnome_blog_globals.py proxy.py test -z "/usr/share/pixmaps" || mkdir -p -- "/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/pixmaps" /usr/bin/install -c -m 644 'gnome-blog.png' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/pixmaps/gnome-blog.png' test -z "/etc/gconf/schemas" || mkdir -p -- "/var/tmp/gnome-blog-0.8-4-root-bpepple/etc/gconf/schemas" /usr/bin/install -c -m 644 'gnomeblog.schemas' '/var/tmp/gnome-blog-0.8-4-root-bpepple/etc/gconf/schemas/gnomeblog.schemas' test -z "/usr/lib/bonobo/servers" || mkdir -p -- "/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/bonobo/servers" /usr/bin/install -c -m 644 'GNOME_BlogApplet.server' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/lib/bonobo/servers/GNOME_BlogApplet.server' test -z "/usr/share/gnome-2.0/ui" || mkdir -p -- "/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/gnome-2.0/ui" /usr/bin/install -c -m 644 'GNOME_BlogApplet.xml' '/var/tmp/gnome-blog-0.8-4-root-bpepple/usr/share/gnome-2.0/ui/GNOME_BlogApplet.xml' make[2]: Leaving directory `/home/bpepple/rpmbuild/BUILD/gnome-blog-0.8' make[1]: Leaving directory `/home/bpepple/rpmbuild/BUILD/gnome-blog-0.8' Processing files: gnome-blog-0.8-4 Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.77064 Requires(interp): /bin/sh /bin/sh Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires(post): /bin/sh GConf2 Requires(preun): /bin/sh GConf2 Requires: /usr/bin/env gnome-python2-applet >= 0:1.99.13 gnome-python2-gconf >= 0:1.99.13 gnome-python2-gnomevfs >= 0:1.99.13 pygtk2 >= 0:1.99.13 python-abi = 2.3 Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/gnome-blog-0.8-4-root-bpepple Wrote: /home/bpepple/rpmbuild/SRPMS/gnome-blog-0.8-4.src.rpm Wrote: /home/bpepple/rpmbuild/RPMS/noarch/gnome-blog-0.8-4.noarch.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.24159 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: