From bugs.michael at gmx.net Wed Nov 1 00:03:02 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 1 Nov 2006 01:03:02 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <4547D733.3070807@redhat.com> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> <45460C41.7030007@poolshark.org> <20061030161826.f408f106.bugs.michael@gmx.net> <1162231246.16192.37.camel@rousalka.dyndns.org> <20061030200216.dbeca49b.bugs.michael@gmx.net> <1162239832.16192.89.camel@rousalka.dyndns.org> <20061030232640.b0029775.bugs.michael@gmx.net> <4546849D.8020600@redhat.com> <20061031003055.d6aae014.bugs.michael@gmx.net> <56640.192.54.193.51.1162288505.squirrel@rousalka.dyndns.org> <20061031115516.649b27a2.bugs.michael@gmx.net> <11721.192.54.193.51.1162296035.squirrel@rousalka.dyndns.org> <20061031134620.ac78b0df.bugs.michael@gmx.net> <45476BF5.7040300@redhat.com> <20061031170042.ee074675.bugs.michael@gmx.net> <4547D733.3070807@redhat.com> Message-ID: <20061101010302.1a3a7e04.bugs.michael@gmx.net> On Tue, 31 Oct 2006 18:07:31 -0500, Christopher Aillon wrote: > Michael Schwendt wrote: > > On Tue, 31 Oct 2006 10:29:57 -0500, Christopher Aillon wrote: > > > >> So > >> once it's approved and built, it is the package owner's discretion to > >> build a different version of a package, which may include so-called beta > >> software. > >> > > > > Yes, which is questionable and asks for adjusted guidelines. > > > wireless-tools-28-0.pre13.5.1 shipped in FC5 final because there was no > other version that would work with the shipped kernel + NM combination > and a "release" hadn't yet been made. Firefox in FC3 GOLD was shipped > as a beta (firefox-0.10.1-1.0PR1.20), as the default web browser even > when there were other web browsers which were not beta in the > distribution. NetworkManager in FC4 shipped as a beta > (NetworkManager-0.4-15.cvs20050404) because it worked better in Fedora > than the latest release. And those are just a small set of the packages > I own. Do you realise what you did here in all three examples? You tried to state the reason _why_ each pre-release was preferred over an older official release. This is very different from jumping to a new version without a comment. Never before have I asked for anything that would forbid beta releases in Fedora Extras. All I've asked for is that packagers ought to explain the rationale for choosing a pre-release (or snapshot) over an official release. Apart from that, we don't want to argue about how many of the Fedora Extras packagers are package maintainers and not just packagers. Maybe with a few polls we could analyse this a bit and get a picture of how many of the packagers believe they are familiar enough with an upstream project as to decide for their own whether a snapshot is "better" than the latest official release. We would find out that many rely on upstream decisions as well as upstream fixes. And, of course, there are counter-examples where work-in-progress code is more broken than a last official release and where even minor updates (which are advertised as "better") introduce serious regression. So, overall, you cannot avoid evaluating upstream products painstakingly. > I think this entire thread is tackling the wrong problem. It has drifted away from the original problem, unfortunately. > So, how do you address the real problem of making sure the software > isn't broken before it goes out? A single reviewer, who doesn't run any mandatory set of run-time tests, won't be able to assure that the software isn't broken. The Fedora Extras Review Process does only cover packaging issues. Reviewers (and packagers) are encouraged to evaluate the run-time readiness of the software, but none of that is mandatory. For instance, we've even had programs entering FE, which crashed immediately either during start or upon selecting popular menu items. In general, FE packages are affected by a variety of issues, which apparently have not been noticed during review and not by the package maintainer either. Just query bugzilla. This is enough reason to suggest that extra care ought to be applied when choosing "stuff that seems to work". > How about a Fedora QA/QE initiative? Would you like to expand on that? I mean, it's not the first time the words have been thrown in without any details. > Maybe build some automated tools to help. Like developing test suites for arbitrary libraries which crash when certain parts of an API are used? ;) From Christian.Iseli at licr.org Wed Nov 1 08:53:26 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 1 Nov 2006 09:53:26 +0100 Subject: xview anyone ? In-Reply-To: <20061030113934.GA3195@free.fr> References: <20061025004624.4320c333@ludwig-alpha.unil.ch> <20061025080639.GA2622@free.fr> <20061025111032.50812465@ludwig-alpha.unil.ch> <20061030113934.GA3195@free.fr> Message-ID: <20061101095326.5894f676@ludwig-alpha.unil.ch> Hi Pat, On Mon, 30 Oct 2006 12:39:35 +0100, Patrice Dumas wrote: > http://www.lmd.jussieu.fr/~pdlmd/xview-3.2-0.1.p4.src.rpm > > It was not an easy task, but now it's done. Normally, the imake files > are more or less FHS compliant now, and I even use them to do the > staged install of xview itself. However if treetool uses other variables > to construct the directories, you may have to modify paths in files in > config/XView.*. > > I had to install some fonts, that's a bit strange since they are listed in > the fonts.dir file in /usr/share/X11/fonts/misc. I tested a bit and it seemed > that using fontconfig didn't worked, that's why I also added the fonts to > /usr/share/X11/fonts/misc. The X and Xfs servers seems to have to be > restarted before those fonts are taken into account. Don't know if all that > is normal or if I did something wrong. > > I tested the ol*wm window managers, they seemed to work, and also the > clock program seems to be functionnal. > > The difference between this and the debian package are > * I put together the 2 ol*wm packages > * I put xview_xgettext and xview_msgfmt in xview-clients and not > xview-devel (the idea is to have multi lib parallel installable > devel package). Thanks a lot. I started to work on this, and after some further tweaks got xview to compile in mock for FC-5, and treetool too. I got treetool to work on i386 machines. There remains some problems though: on x86_64 the function copy_va_to_av goes into an infinite loop when dealing with pointers. Must be some 64-bit issue. This happens both using treetool and clock. I put my current working copy of the packages SRPMS in ftp://ftp.licr.org/pub/ Not quite ready for prime time yet. Cheers, C From j.w.r.degoede at hhs.nl Wed Nov 1 10:40:18 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 01 Nov 2006 11:40:18 +0100 Subject: xview anyone ? In-Reply-To: <20061101095326.5894f676@ludwig-alpha.unil.ch> References: <20061025004624.4320c333@ludwig-alpha.unil.ch> <20061025080639.GA2622@free.fr> <20061025111032.50812465@ludwig-alpha.unil.ch> <20061030113934.GA3195@free.fr> <20061101095326.5894f676@ludwig-alpha.unil.ch> Message-ID: <45487992.3040406@hhs.nl> Christian Iseli wrote: > Hi Pat, > > On Mon, 30 Oct 2006 12:39:35 +0100, Patrice Dumas wrote: >> http://www.lmd.jussieu.fr/~pdlmd/xview-3.2-0.1.p4.src.rpm >> >> It was not an easy task, but now it's done. Normally, the imake files >> are more or less FHS compliant now, and I even use them to do the >> staged install of xview itself. However if treetool uses other variables >> to construct the directories, you may have to modify paths in files in >> config/XView.*. >> >> I had to install some fonts, that's a bit strange since they are listed in >> the fonts.dir file in /usr/share/X11/fonts/misc. I tested a bit and it seemed >> that using fontconfig didn't worked, that's why I also added the fonts to >> /usr/share/X11/fonts/misc. The X and Xfs servers seems to have to be >> restarted before those fonts are taken into account. Don't know if all that >> is normal or if I did something wrong. >> >> I tested the ol*wm window managers, they seemed to work, and also the >> clock program seems to be functionnal. >> >> The difference between this and the debian package are >> * I put together the 2 ol*wm packages >> * I put xview_xgettext and xview_msgfmt in xview-clients and not >> xview-devel (the idea is to have multi lib parallel installable >> devel package). > > Thanks a lot. I started to work on this, and after some further tweaks > got xview to compile in mock for FC-5, and treetool too. > > I got treetool to work on i386 machines. > > There remains some problems though: on x86_64 the function > copy_va_to_av goes into an infinite loop when dealing with pointers. > Must be some 64-bit issue. This happens both using treetool and clock. > > I put my current working copy of the packages SRPMS in > ftp://ftp.licr.org/pub/ > 1) Have you checked Debian's packages of this (if they have any) usually with hard to package software its a good idea to start with all Debian's patches (or atleast thosw which seem to make sense) that might fix this. 2) If you can give me a shortlist of instructions howto reproduce this then I can take a look at my 64 bit machine at home (work doesn't have any 64 bit machines yet). As time permits of course. Regards, Hans From pertusus at free.fr Wed Nov 1 10:04:32 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 1 Nov 2006 11:04:32 +0100 Subject: xview anyone ? In-Reply-To: <20061101095326.5894f676@ludwig-alpha.unil.ch> References: <20061025004624.4320c333@ludwig-alpha.unil.ch> <20061025080639.GA2622@free.fr> <20061025111032.50812465@ludwig-alpha.unil.ch> <20061030113934.GA3195@free.fr> <20061101095326.5894f676@ludwig-alpha.unil.ch> Message-ID: <20061101100432.GA2294@free.fr> On Wed, Nov 01, 2006 at 09:53:26AM +0100, Christian Iseli wrote: > Hi Pat, > > There remains some problems though: on x86_64 the function > copy_va_to_av goes into an infinite loop when dealing with pointers. > Must be some 64-bit issue. This happens both using treetool and clock. I guess you ran into http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=228957 The debian maintainer doesn't seem to very optimistic about 64 bit readiness. Maybe you could contact him directly? -- Pat From Christian.Iseli at licr.org Wed Nov 1 10:21:43 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 1 Nov 2006 11:21:43 +0100 Subject: xview anyone ? In-Reply-To: <45487992.3040406@hhs.nl> References: <20061025004624.4320c333@ludwig-alpha.unil.ch> <20061025080639.GA2622@free.fr> <20061025111032.50812465@ludwig-alpha.unil.ch> <20061030113934.GA3195@free.fr> <20061101095326.5894f676@ludwig-alpha.unil.ch> <45487992.3040406@hhs.nl> Message-ID: <20061101112143.62227d36@ludwig-alpha.unil.ch> On Wed, 01 Nov 2006 11:40:18 +0100, Hans de Goede wrote: > 1) Have you checked Debian's packages of this (if they have any) usually with hard to package software > its a good idea to start with all Debian's patches (or atleast thosw which seem to make sense) that > might fix this. Yup, Pat basically used all the Debian stuff. > 2) If you can give me a shortlist of instructions howto reproduce this then I can take a look at my 64 > bit machine at home (work doesn't have any 64 bit machines yet). As time permits of course. Sure: - grab ftp://ftp.licr.org/pub/xview-3.2-0.1.p4.src.rpm - mock xview-3.2-0.1.p4.src.rpm on your 64-bit machine (for FC-[567]) - install xview, xview-clients, and xview-debuginfo - launch "clock" - watch it loop (it will not display anything, and use 100% CPU) - attach a gdb to the process Cheers, C From j.w.r.degoede at hhs.nl Wed Nov 1 11:40:23 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 01 Nov 2006 12:40:23 +0100 Subject: xview anyone ? In-Reply-To: <20061101112143.62227d36@ludwig-alpha.unil.ch> References: <20061025004624.4320c333@ludwig-alpha.unil.ch> <20061025080639.GA2622@free.fr> <20061025111032.50812465@ludwig-alpha.unil.ch> <20061030113934.GA3195@free.fr> <20061101095326.5894f676@ludwig-alpha.unil.ch> <45487992.3040406@hhs.nl> <20061101112143.62227d36@ludwig-alpha.unil.ch> Message-ID: <454887A7.5000105@hhs.nl> Christian Iseli wrote: > On Wed, 01 Nov 2006 11:40:18 +0100, Hans de Goede wrote: >> 1) Have you checked Debian's packages of this (if they have any) usually with hard to package software >> its a good idea to start with all Debian's patches (or atleast thosw which seem to make sense) that >> might fix this. > > Yup, Pat basically used all the Debian stuff. > :( (that Debian hasn't fixed the 64 bit stuff already) >> 2) If you can give me a shortlist of instructions howto reproduce this then I can take a look at my 64 >> bit machine at home (work doesn't have any 64 bit machines yet). As time permits of course. > > Sure: > - grab ftp://ftp.licr.org/pub/xview-3.2-0.1.p4.src.rpm > - mock xview-3.2-0.1.p4.src.rpm on your 64-bit machine (for FC-[567]) > - install xview, xview-clients, and xview-debuginfo > - launch "clock" > - watch it loop (it will not display anything, and use 100% CPU) > - attach a gdb to the process > > Cheers, > C Thanks I'll take a look at this (as time permits). Regards, Hans From j.w.r.degoede at hhs.nl Wed Nov 1 11:45:05 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 01 Nov 2006 12:45:05 +0100 Subject: xview anyone ? In-Reply-To: <20061101100432.GA2294@free.fr> References: <20061025004624.4320c333@ludwig-alpha.unil.ch> <20061025080639.GA2622@free.fr> <20061025111032.50812465@ludwig-alpha.unil.ch> <20061030113934.GA3195@free.fr> <20061101095326.5894f676@ludwig-alpha.unil.ch> <20061101100432.GA2294@free.fr> Message-ID: <454888C1.5070001@hhs.nl> Patrice Dumas wrote: > On Wed, Nov 01, 2006 at 09:53:26AM +0100, Christian Iseli wrote: >> Hi Pat, >> >> There remains some problems though: on x86_64 the function >> copy_va_to_av goes into an infinite loop when dealing with pointers. >> Must be some 64-bit issue. This happens both using treetool and clock. > > I guess you ran into > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=228957 > The debian maintainer doesn't seem to very optimistic about 64 bit > readiness. > Hmm, That all sounds real nasty, still I'll take a shot, but I might come to the same conclusion. Regards, Hans From Christian.Iseli at licr.org Wed Nov 1 10:49:57 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 1 Nov 2006 11:49:57 +0100 Subject: xview anyone ? In-Reply-To: <454887A7.5000105@hhs.nl> References: <20061025004624.4320c333@ludwig-alpha.unil.ch> <20061025080639.GA2622@free.fr> <20061025111032.50812465@ludwig-alpha.unil.ch> <20061030113934.GA3195@free.fr> <20061101095326.5894f676@ludwig-alpha.unil.ch> <45487992.3040406@hhs.nl> <20061101112143.62227d36@ludwig-alpha.unil.ch> <454887A7.5000105@hhs.nl> Message-ID: <20061101114957.7b5f9858@ludwig-alpha.unil.ch> On Wed, 01 Nov 2006 12:40:23 +0100, Hans de Goede wrote: > Thanks I'll take a look at this (as time permits). Cool :-) Thanks, C From Christian.Iseli at licr.org Wed Nov 1 10:54:19 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 1 Nov 2006 11:54:19 +0100 Subject: xview anyone ? In-Reply-To: <20061101100432.GA2294@free.fr> References: <20061025004624.4320c333@ludwig-alpha.unil.ch> <20061025080639.GA2622@free.fr> <20061025111032.50812465@ludwig-alpha.unil.ch> <20061030113934.GA3195@free.fr> <20061101095326.5894f676@ludwig-alpha.unil.ch> <20061101100432.GA2294@free.fr> Message-ID: <20061101115419.5f231d42@ludwig-alpha.unil.ch> On Wed, 1 Nov 2006 11:04:32 +0100, Patrice Dumas wrote: > I guess you ran into > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=228957 > The debian maintainer doesn't seem to very optimistic about 64 bit > readiness. Could be. > Maybe you could contact him directly? Hans said he'd take a look, and I'll take a look too as time permits. When I get a better feel of what's happening, I'll contact Martin... C From pertusus at free.fr Wed Nov 1 12:56:46 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 1 Nov 2006 13:56:46 +0100 Subject: xview anyone ? In-Reply-To: <45487992.3040406@hhs.nl> References: <20061025004624.4320c333@ludwig-alpha.unil.ch> <20061025080639.GA2622@free.fr> <20061025111032.50812465@ludwig-alpha.unil.ch> <20061030113934.GA3195@free.fr> <20061101095326.5894f676@ludwig-alpha.unil.ch> <45487992.3040406@hhs.nl> Message-ID: <20061101125646.GC2294@free.fr> On Wed, Nov 01, 2006 at 11:40:18AM +0100, Hans de Goede wrote: > > 1) Have you checked Debian's packages of this (if they have any) usually > with hard to package software > its a good idea to start with all Debian's patches (or atleast thosw > which seem to make sense) that > might fix this. As Christian said, it's allready applied. Moreover I used more or less the debian build process and also more or less debian split. One thing I do differently is that I install directly in the staged install dir, while in the debian things are installed in a temporary directory and then moved around. -- Pat From j.w.r.degoede at hhs.nl Wed Nov 1 14:18:51 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 01 Nov 2006 15:18:51 +0100 Subject: Free enough for FE Message-ID: <4548ACCB.1050706@hhs.nl> HI, I'm looking into packaging a game whose game data comes with the following license: 1) You may distribute this game for free on any medium, provided this readme and all associated copyright notices and disclaimers are left intact. 2) You may charge a reasonable copying fee for this archive, and may distribute it in aggregate as part of a larger & possibly commercial software distribution (such as a Linux distribution or magazine coverdisk). You must provide proper attribution and ensure this readme and all associated copyright notices, and disclaimers are left intact. 3) You may not charge a fee for the game itself. This includes reselling the game as an individual item. 4) You may modify the game as you wish. You may also distribute modified versions under the terms set forth in this license, but with the additional requirement that the work is marked with a prominent notice which states that it is a modified version. 5) All game content is (C) Revolution Software Ltd. The ScummVM engine is (C) The ScummVM Team (www.scummvm.org) 6) THE GAMEDATA IN THIS ARCHIVE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING AND NOT LIMITED TO ANY IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. I know this license isn't fully DFSG free, but we're talking about content here, and this is freely redistributable and may be included on compilation CD's etc. The only real distribution restriction is: "You may not charge a fee for the game itself. This includes reselling the game as an individual item." But I see no problem with this not for Fedora, nor for people who want to base something on Fedora. We've already allowed stuff with similar restrictions, for example artwork which may only be used as part of a certain game, and thus may not be distributed by itself, nor sold by itself. Regards, Hans From buildsys at fedoraproject.org Wed Nov 1 13:35:17 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 1 Nov 2006 08:35:17 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-01 Message-ID: <20061101133517.1CB37152139@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 36 abcMIDI-20061027-1.fc7 amarok-1.4.4-1.fc7 blender-2.42a-5.fc7 camE-1.9-8.fc7 cmake-2.4.3-4.fc7 dap-freeform_handler-3.7.2-3.fc7 dap-hdf4_handler-3.7.2-4.fc7 dap-netcdf_handler-3.7.3-3.fc7 dap-server-3.7.1-4.fc7 darcs-1.0.8-4.fc7 fbida-2.06-3.fc7 fwbackups-1.42.1-2.fc7 gkrellm-2.2.10-1.fc7 grads-1.9b4-18.fc7 grip-3.2.0-14.fc7 gtorrentviewer-0.2b-13.fc7 guiloader-2.8.1-1.fc7 jigdo-0.7.3-3.fc7 libdap-3.7.2-3.fc7 libnc-dap-3.6.2-5.fc7 libtunepimp-0.5.2-4.fc7 manaworld-0.0.21-2.fc7 mod_fcgid-2.0-1.fc7 moin-1.5.6-1.fc7 monodevelop-0.12-7.fc7 moodss-21.4-1.fc7 moomps-5.7-1.fc7 pyicq-t-0.8-1.fc7 python-dialog-2.7-5.fc7 python-zope-interface-3.0.1-6.fc7 q-7.5-2.fc7 quarry-0.1.20-1.fc7 scim-input-pad-0.1.1-7.fc7 w3c-markup-validator-0.7.3-2.fc7 xine-lib-1.1.2-17.fc7 yum-utils-1.0.1-1.fc7 Packages built and released for Fedora Extras 6: 17 abcMIDI-20061027-1.fc6 amarok-1.4.4-1.fc6 cmake-2.4.3-4.fc6 fbida-2.06-3.fc6 grip-3.2.0-14.fc6 monodevelop-0.12-7.fc6 moodss-21.4-1.fc6 moomps-5.7-1.fc6 pyicq-t-0.8-1.fc6 python-dialog-2.7-5.fc6 q-7.5-1.fc6 quarry-0.1.20-1.fc6 scim-input-pad-0.1.1-7.fc6 w3c-markup-validator-0.7.3-2.fc6 xine-lib-1.1.2-17.fc6 xmlrpc-c-1.06.06-1.fc6 yum-utils-1.0.1-1.fc6 Packages built and released for Fedora Extras 5: 16 abcMIDI-20061027-1.fc5 amarok-1.4.4-1.fc5 cmake-2.4.3-3.fc5 frozen-bubble-1.0.0-10.fc5 international-time-0.0.2-2.fc5.1.1 moodss-21.4-1.fc5 moomps-5.7-1.fc5 perl-SDL-2.1.3-3.fc5 pyicq-t-0.8-1.fc5 python-dialog-2.7-5.fc5 q-7.5-1.fc5 quarry-0.1.20-1.fc5 scim-input-pad-0.1.1-6.fc5 w3c-markup-validator-0.7.3-2.fc5 xine-lib-1.1.2-17.fc5 xmlrpc-c-1.06.06-1.fc5 Packages built and released for Fedora Extras 4: 3 cmake-2.4.3-3.fc4 pyicq-t-0.8-1.fc4 quarry-0.1.20-1.fc4 Packages built and released for Fedora Extras 3: 1 quarry-0.1.20-1.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From michel.salim at gmail.com Wed Nov 1 14:26:54 2006 From: michel.salim at gmail.com (Michel Salim) Date: Wed, 1 Nov 2006 09:26:54 -0500 Subject: Free enough for FE In-Reply-To: <4548ACCB.1050706@hhs.nl> References: <4548ACCB.1050706@hhs.nl> Message-ID: <883cfe6d0611010626k69c15605q60d102ebfc58a26b@mail.gmail.com> On 11/1/06, Hans de Goede wrote: > HI, > > I'm looking into packaging a game whose game data comes with the following license: > > 5) All game content is (C) Revolution Software Ltd. The ScummVM engine is (C) > The ScummVM Team (www.scummvm.org) > Ah. Beneath the Steel Sky? It'd be nice to have ScummVM be usable out-of-the-box. -- Michel Salim http://www.cs.indiana.edu/~msalim http://the-dubois-papers.blogspot.com/ From buildsys at fedoraproject.org Wed Nov 1 15:47:08 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 01 Nov 2006 15:47:08 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-01 Message-ID: <20061101154708.30751.52498@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 centericq - 4.21.0-8.fc6.ppc centericq - 4.21.0-8.fc6.x86_64 libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (4 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (4 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (4 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (4 days) orange - 0.3-3.cvs20051118.fc6.i386 (8 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (32 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (32 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (32 days) sylpheed-claws-plugins-gtkhtml2-viewer - 2.5.2-4.fc6.i386 sylpheed-claws-plugins-gtkhtml2-viewer - 2.5.2-4.fc6.ppc sylpheed-claws-plugins-gtkhtml2-viewer - 2.5.2-4.fc6.x86_64 sylpheed-claws-plugins-rssyl - 2.5.2-4.fc6.i386 sylpheed-claws-plugins-rssyl - 2.5.2-4.fc6.ppc sylpheed-claws-plugins-rssyl - 2.5.2-4.fc6.x86_64 sylpheed-claws-plugins-vcalendar - 2.5.2-4.fc6.i386 sylpheed-claws-plugins-vcalendar - 2.5.2-4.fc6.ppc sylpheed-claws-plugins-vcalendar - 2.5.2-4.fc6.x86_64 andreas AT bawue.net icecast - 2.3.1-3.fc6.i386 icecast - 2.3.1-3.fc6.ppc icecast - 2.3.1-3.fc6.x86_64 xmms-scrobbler - 0.3.8.1-2.fc6.i386 xmms-scrobbler - 0.3.8.1-2.fc6.ppc xmms-scrobbler - 0.3.8.1-2.fc6.x86_64 chabotc AT xs4all.nl rtorrent - 0.6.2-4.fc6.i386 rtorrent - 0.6.2-4.fc6.ppc rtorrent - 0.6.2-4.fc6.x86_64 chrisw AT redhat.com git-core - 1.4.2.4-1.fc6.i386 git-core - 1.4.2.4-1.fc6.ppc git-core - 1.4.2.4-1.fc6.x86_64 dakingun AT gmail.com gnomesword - 2.1.6-5.fc6.i386 gnomesword - 2.1.6-5.fc6.ppc gnomesword - 2.1.6-5.fc6.x86_64 sword - 1.5.8-10.fc6.i386 sword - 1.5.8-10.fc6.i386 sword - 1.5.8-10.fc6.ppc sword - 1.5.8-10.fc6.x86_64 dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (47 days) plague - 0.4.4.1-2.fc3.noarch (47 days) plague - 0.4.4.1-2.fc4.noarch (47 days) plague - 0.4.4.1-2.fc4.noarch (47 days) plague - 0.4.4.1-2.fc4.noarch (47 days) endur AT bennewitz.com streamtuner - 0.99.99-13.fc6.i386 streamtuner - 0.99.99-13.fc6.i386 streamtuner - 0.99.99-13.fc6.ppc streamtuner - 0.99.99-13.fc6.x86_64 enrico.scholz AT informatik.tu-chemnitz.de xmlrpc-c - 1.06.05-2.fc6.i386 xmlrpc-c - 1.06.05-2.fc6.i386 xmlrpc-c - 1.06.05-2.fc6.ppc xmlrpc-c - 1.06.05-2.fc6.x86_64 xmlrpc-c-apps - 1.06.05-2.fc6.i386 xmlrpc-c-apps - 1.06.05-2.fc6.ppc xmlrpc-c-apps - 1.06.05-2.fc6.x86_64 green AT redhat.com raptor - 1.4.9-5.fc6.i386 raptor - 1.4.9-5.fc6.i386 raptor - 1.4.9-5.fc6.ppc raptor - 1.4.9-5.fc6.x86_64 hamzy AT us.ibm.com sblim-wbemcli - 1.5.1-4.fc6.i386 sblim-wbemcli - 1.5.1-4.fc6.ppc sblim-wbemcli - 1.5.1-4.fc6.x86_64 hugo AT devin.com.br xmoto - 0.2.0-1.fc6.i386 xmoto - 0.2.0-1.fc6.ppc xmoto - 0.2.0-1.fc6.x86_64 imlinux AT gmail.com nagios-plugins-ide_smart - 1.4.3-20.fc4.i386 (7 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.ppc (7 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.x86_64 (7 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (23 days) linphone - 1.2.0-4.fc5.ppc (23 days) linphone - 1.2.0-4.fc5.x86_64 (23 days) linphone - 1.2.0-7.fc6.i386 (8 days) linphone - 1.2.0-7.fc6.ppc (8 days) linphone - 1.2.0-7.fc6.x86_64 (8 days) lmacken AT redhat.com deskbar-applet - 2.16.0-1.fc6.i386 (4 days) deskbar-applet - 2.16.0-1.fc6.ppc (4 days) deskbar-applet - 2.16.0-1.fc6.x86_64 (4 days) mr.ecik AT gmail.com kadu-miastoplusa_sms - 0.5.0-0.15.20060915svn.fc6.i386 kadu-miastoplusa_sms - 0.5.0-0.15.20060915svn.fc6.ppc kadu-miastoplusa_sms - 0.5.0-0.15.20060915svn.fc6.x86_64 nphilipp AT redhat.com bzflag - 2.0.8-3.fc6.i386 bzflag - 2.0.8-3.fc6.ppc bzflag - 2.0.8-3.fc6.x86_64 oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (13 days) syck-php - 0.55-9.fc5.ppc (13 days) syck-php - 0.55-9.fc5.x86_64 (13 days) qspencer AT ieee.org octave-forge - 2006.07.09-7.fc6.i386 octave-forge - 2006.07.09-7.fc6.ppc octave-forge - 2006.07.09-7.fc6.x86_64 rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (3 days) redhat-bugzilla AT camperquake.de audacious - 1.1.2-2.fc6.i386 audacious - 1.1.2-2.fc6.i386 audacious - 1.1.2-2.fc6.ppc audacious - 1.1.2-2.fc6.x86_64 stickster AT gmail.com drivel - 2.1.0-0.3.20060527cvs.fc6.i386 drivel - 2.1.0-0.3.20060527cvs.fc6.ppc drivel - 2.1.0-0.3.20060527cvs.fc6.x86_64 tcallawa AT redhat.com evolution-bogofilter - 0.2.0-3.fc6.i386 (4 days) evolution-bogofilter - 0.2.0-3.fc6.ppc (4 days) evolution-bogofilter - 0.2.0-3.fc6.x86_64 (4 days) gambas-gb-net-curl - 1.0.17-3.fc6.i386 (5 days) gambas-gb-net-curl - 1.0.17-3.fc6.ppc (5 days) gambas-runtime - 1.0.17-3.fc6.i386 (5 days) gambas-runtime - 1.0.17-3.fc6.ppc (5 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- audacious-1.1.2-2.fc6.ppc requires libcurl.so.3 bzflag-2.0.8-3.fc6.ppc requires libcurl.so.3 centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 deskbar-applet-2.16.0-1.fc6.ppc requires libedataserver-1.2.so.7 drivel-2.1.0-0.3.20060527cvs.fc6.ppc requires libcurl.so.3 evolution-bogofilter-0.2.0-3.fc6.ppc requires libedataserver-1.2.so.7 gambas-gb-net-curl-1.0.17-3.fc6.ppc requires libcurl.so.3 gambas-runtime-1.0.17-3.fc6.ppc requires libgettextlib-0.14.6.so git-core-1.4.2.4-1.fc6.ppc requires libcurl.so.3 gnomesword-2.1.6-5.fc6.ppc requires libcurl.so.3 icecast-2.3.1-3.fc6.ppc requires libcurl.so.3 kadu-miastoplusa_sms-0.5.0-0.15.20060915svn.fc6.ppc requires libcurl.so.3 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 octave-forge-2006.07.09-7.fc6.ppc requires libcurl.so.3 raptor-1.4.9-5.fc6.ppc requires libcurl.so.3 rtorrent-0.6.2-4.fc6.ppc requires libcurl.so.3 sblim-wbemcli-1.5.1-4.fc6.ppc requires libcurl.so.3 streamtuner-0.99.99-13.fc6.ppc requires libcurl.so.3 sword-1.5.8-10.fc6.ppc requires libcurl.so.3 sylpheed-claws-plugins-gtkhtml2-viewer-2.5.2-4.fc6.ppc requires libcurl.so.3 sylpheed-claws-plugins-rssyl-2.5.2-4.fc6.ppc requires libcurl.so.3 sylpheed-claws-plugins-vcalendar-2.5.2-4.fc6.ppc requires libcurl.so.3 xmlrpc-c-1.06.05-2.fc6.ppc requires libcurl.so.3 xmlrpc-c-apps-1.06.05-2.fc6.ppc requires libcurl.so.3 xmms-scrobbler-0.3.8.1-2.fc6.ppc requires libcurl.so.3 xmoto-0.2.0-1.fc6.ppc requires libcurl.so.3 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- audacious-1.1.2-2.fc6.i386 requires libcurl.so.3 audacious-1.1.2-2.fc6.x86_64 requires libcurl.so.3()(64bit) bzflag-2.0.8-3.fc6.x86_64 requires libcurl.so.3()(64bit) centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) deskbar-applet-2.16.0-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) drivel-2.1.0-0.3.20060527cvs.fc6.x86_64 requires libcurl.so.3()(64bit) evolution-bogofilter-0.2.0-3.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 git-core-1.4.2.4-1.fc6.x86_64 requires libcurl.so.3()(64bit) gnomesword-2.1.6-5.fc6.x86_64 requires libcurl.so.3()(64bit) icecast-2.3.1-3.fc6.x86_64 requires libcurl.so.3()(64bit) kadu-miastoplusa_sms-0.5.0-0.15.20060915svn.fc6.x86_64 requires libcurl.so.3()(64bit) libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) octave-forge-2006.07.09-7.fc6.x86_64 requires libcurl.so.3()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 raptor-1.4.9-5.fc6.i386 requires libcurl.so.3 raptor-1.4.9-5.fc6.x86_64 requires libcurl.so.3()(64bit) rtorrent-0.6.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) sblim-wbemcli-1.5.1-4.fc6.x86_64 requires libcurl.so.3()(64bit) streamtuner-0.99.99-13.fc6.i386 requires libcurl.so.3 streamtuner-0.99.99-13.fc6.x86_64 requires libcurl.so.3()(64bit) sword-1.5.8-10.fc6.i386 requires libcurl.so.3 sword-1.5.8-10.fc6.x86_64 requires libcurl.so.3()(64bit) sylpheed-claws-plugins-gtkhtml2-viewer-2.5.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) sylpheed-claws-plugins-rssyl-2.5.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) sylpheed-claws-plugins-vcalendar-2.5.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) xmlrpc-c-1.06.05-2.fc6.i386 requires libcurl.so.3 xmlrpc-c-1.06.05-2.fc6.x86_64 requires libcurl.so.3()(64bit) xmlrpc-c-apps-1.06.05-2.fc6.x86_64 requires libcurl.so.3()(64bit) xmms-scrobbler-0.3.8.1-2.fc6.x86_64 requires libcurl.so.3()(64bit) xmoto-0.2.0-1.fc6.x86_64 requires libcurl.so.3()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- audacious-1.1.2-2.fc6.i386 requires libcurl.so.3 bzflag-2.0.8-3.fc6.i386 requires libcurl.so.3 centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 deskbar-applet-2.16.0-1.fc6.i386 requires libedataserver-1.2.so.7 drivel-2.1.0-0.3.20060527cvs.fc6.i386 requires libcurl.so.3 evolution-bogofilter-0.2.0-3.fc6.i386 requires libedataserver-1.2.so.7 gambas-gb-net-curl-1.0.17-3.fc6.i386 requires libcurl.so.3 gambas-runtime-1.0.17-3.fc6.i386 requires libgettextlib-0.14.6.so git-core-1.4.2.4-1.fc6.i386 requires libcurl.so.3 gnomesword-2.1.6-5.fc6.i386 requires libcurl.so.3 icecast-2.3.1-3.fc6.i386 requires libcurl.so.3 kadu-miastoplusa_sms-0.5.0-0.15.20060915svn.fc6.i386 requires libcurl.so.3 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 octave-forge-2006.07.09-7.fc6.i386 requires libcurl.so.3 raptor-1.4.9-5.fc6.i386 requires libcurl.so.3 rtorrent-0.6.2-4.fc6.i386 requires libcurl.so.3 sblim-wbemcli-1.5.1-4.fc6.i386 requires libcurl.so.3 streamtuner-0.99.99-13.fc6.i386 requires libcurl.so.3 sword-1.5.8-10.fc6.i386 requires libcurl.so.3 sylpheed-claws-plugins-gtkhtml2-viewer-2.5.2-4.fc6.i386 requires libcurl.so.3 sylpheed-claws-plugins-rssyl-2.5.2-4.fc6.i386 requires libcurl.so.3 sylpheed-claws-plugins-vcalendar-2.5.2-4.fc6.i386 requires libcurl.so.3 xmlrpc-c-1.06.05-2.fc6.i386 requires libcurl.so.3 xmlrpc-c-apps-1.06.05-2.fc6.i386 requires libcurl.so.3 xmms-scrobbler-0.3.8.1-2.fc6.i386 requires libcurl.so.3 xmoto-0.2.0-1.fc6.i386 requires libcurl.so.3 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.ppc requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.x86_64 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.i386 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 From j.w.r.degoede at hhs.nl Wed Nov 1 16:55:04 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 01 Nov 2006 17:55:04 +0100 Subject: Free enough for FE In-Reply-To: <883cfe6d0611010626k69c15605q60d102ebfc58a26b@mail.gmail.com> References: <4548ACCB.1050706@hhs.nl> <883cfe6d0611010626k69c15605q60d102ebfc58a26b@mail.gmail.com> Message-ID: <4548D168.5070800@hhs.nl> Michel Salim wrote: > On 11/1/06, Hans de Goede wrote: >> HI, >> >> I'm looking into packaging a game whose game data comes with the >> following license: >> > >> 5) All game content is (C) Revolution Software Ltd. The ScummVM >> engine is (C) >> The ScummVM Team (www.scummvm.org) >> > Ah. Beneath the Steel Sky? It'd be nice to have ScummVM be usable > out-of-the-box. > Yes and Yes. Regards, Hans From kevin.kofler at chello.at Wed Nov 1 16:55:39 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 1 Nov 2006 16:55:39 +0000 (UTC) Subject: Free enough for FE References: <4548ACCB.1050706@hhs.nl> Message-ID: Hans de Goede writes: > The only real distribution restriction is: "You may not charge a fee for the game > itself. This includes reselling the game as an individual item." IMHO, this is essentially the same as the Bitstream Vera license. "The Font Software may be sold as part of a larger software package but no copy of one or more of the Font Software typefaces may be sold by itself." (from /usr/share/doc/dejavu-lgc-fonts-2.10/LICENSE) But of course IANAL. :-) Kevin Kofler From rdieter at math.unl.edu Wed Nov 1 17:45:34 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 01 Nov 2006 11:45:34 -0600 Subject: Free enough for FE References: <4548ACCB.1050706@hhs.nl> Message-ID: Kevin Kofler wrote: > Hans de Goede writes: >> The only real distribution restriction is: "You may not charge a fee for >> the > game >> itself. This includes reselling the game as an individual item." > > IMHO, this is essentially the same as the Bitstream Vera license. > "The Font Software may be sold as part of a larger software package but no > copy of one or more of the Font Software typefaces may be sold by itself." > (from /usr/share/doc/dejavu-lgc-fonts-2.10/LICENSE) That was the only cause that raised my eyebrow, but what's good for the goose (bitstream-vera) is good for the gander (here). -- Rex From nicolas.mailhot at laposte.net Wed Nov 1 18:50:41 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 01 Nov 2006 19:50:41 +0100 Subject: Free enough for FE In-Reply-To: References: <4548ACCB.1050706@hhs.nl> Message-ID: <1162407042.29648.11.camel@rousalka.dyndns.org> Le mercredi 01 novembre 2006 ? 11:45 -0600, Rex Dieter a ?crit : > Kevin Kofler wrote: > > > Hans de Goede writes: > >> The only real distribution restriction is: "You may not charge a fee for > >> the > > game > >> itself. This includes reselling the game as an individual item." > > > > IMHO, this is essentially the same as the Bitstream Vera license. > > "The Font Software may be sold as part of a larger software package but no > > copy of one or more of the Font Software typefaces may be sold by itself." > > (from /usr/share/doc/dejavu-lgc-fonts-2.10/LICENSE) > > That was the only cause that raised my eyebrow, but what's good for the > goose (bitstream-vera) is good for the gander (here). I Vera's case Bitstream clarified they consider the rpm itself a "larger software package". So I'm not sure at all the precedent applies (you should probably just add a R to something else so your rpm is never installable standalone) -- Nicolas Mailhot From j.w.r.degoede at hhs.nl Wed Nov 1 20:39:55 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 01 Nov 2006 21:39:55 +0100 Subject: Free enough for FE In-Reply-To: <1162407042.29648.11.camel@rousalka.dyndns.org> References: <4548ACCB.1050706@hhs.nl> <1162407042.29648.11.camel@rousalka.dyndns.org> Message-ID: <4549061B.2000300@hhs.nl> Nicolas Mailhot wrote: > Le mercredi 01 novembre 2006 ? 11:45 -0600, Rex Dieter a ?crit : >> Kevin Kofler wrote: >> >>> Hans de Goede writes: >>>> The only real distribution restriction is: "You may not charge a fee for >>>> the >>> game >>>> itself. This includes reselling the game as an individual item." >>> IMHO, this is essentially the same as the Bitstream Vera license. >>> "The Font Software may be sold as part of a larger software package but no >>> copy of one or more of the Font Software typefaces may be sold by itself." >>> (from /usr/share/doc/dejavu-lgc-fonts-2.10/LICENSE) >> That was the only cause that raised my eyebrow, but what's good for the >> goose (bitstream-vera) is good for the gander (here). > > I Vera's case Bitstream clarified they consider the rpm itself a "larger > software package". So I'm not sure at all the precedent applies > > (you should probably just add a R to something else so your rpm is never > installable standalone) > I will it will require scummvm, which in turn will require several libs. So if I'm reading this correct then there are no objections? I'll let this thread "run" for a couple of more days and if there are still no objections then, then I'll start working on a package. Regards, Hans From mmcgrath at fedoraproject.org Wed Nov 1 21:08:54 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 1 Nov 2006 15:08:54 -0600 Subject: Builders are down Message-ID: <3237e4410611011308k3fa71231kf47f14750a11acb8@mail.gmail.com> The builders are down for maintanence for the moment, They should be back shortly. -Mike From tcallawa at redhat.com Thu Nov 2 05:50:35 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 01 Nov 2006 23:50:35 -0600 Subject: Free enough for FE In-Reply-To: <4549061B.2000300@hhs.nl> References: <4548ACCB.1050706@hhs.nl> <1162407042.29648.11.camel@rousalka.dyndns.org> <4549061B.2000300@hhs.nl> Message-ID: <1162446636.7933.436.camel@dhcp-32-122.ord.redhat.com> On Wed, 2006-11-01 at 21:39 +0100, Hans de Goede wrote: > So if I'm reading this correct then there are no objections? > > I'll let this thread "run" for a couple of more days and if there are still no objections then, then I'll start working on a package. I asked the FSF on this one (they're usually pretty responsive) and their initial feedback is that this should be ok. This maps up with my feelings on it too, so go ahead and package it. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From a.badger at gmail.com Thu Nov 2 07:28:37 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 01 Nov 2006 23:28:37 -0800 Subject: Fedora Extras Meeting Minutes 2006-10-26 Message-ID: <1162452517.5230.0.camel@localhost> = 2006 October 26 FESCo Meeting = == Members == === Present === * thl * bpepple * abadger1999 * rdieter * ch4chris * tibbs * dgilmore * scop * warren * jeremy * spot * jwb (late) === Absent === * awjb == Summary == === When to Touch Other People's Packages === * Approved the proposal: http://www.fedoraproject.org/wiki/Extras/Schedule/FixStuffThatNeedsFixing === EPEL === * The name is not liked in all corners but no better name has been proposed so we're proceeding as is for now. === Packaging Committee Report === * Voting to stop using the X-Fedora category in the desktop file is currently underway via email. === Meeting Time === * "Daylight Savings" occurs this weekend so the meeting will be 18:00UTC starting next weel. === Sponsor Nominations === * cwickert approved as sponsor. * Mamoru Tasaka approved as sponsor after some debate. * silug and pfj to be discussed on the list. === Sponsor Criteria === * "Does the person understand packaging" proposed as the criteria for giving sponsor status. * warren brought up that we need to make a proposal to officially recognize other paths to get "higher ranks" within the project. (such as sponsor status, sponsored for cvsextras/fedorabugs, etc) * Example: having someone who is bilingual in English and another language being responsible for sponsoring other contributers who speak the other language but not English. * comaintainership may help guide people. * Further discussion to take place on list. === Approve KMods === * rt2x00-kmod -- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202528 * Given the go ahead to package as it satisfies the "going into upstream kernel" requirement. * Encouraging the packager to coordinate with linville about actual packaging as it touches on stuff in the netdev tree. === Maintainer Responsibilities === * bpepple will work on driving this forward. === Misc === ==== Coverity ==== * It is inappropropriate for Coverity to be used on Fedora Infrastructure. Removing from the schedule. ==== Core + Extras Merge ==== * The merge is just beginning to take concrete steps (due to getting FC6 and RHEL5 out). * jeremy proposed taking things step by step: 1. Common VCS 2. Unify the build infrastructure. == Log == {{{ (10:00:46) thl has changed the topic to: FESCO meeting -- init (10:00:50) thl: Hi (10:00:55) ***thl looks around (10:00:57) ***bpepple is here. (10:00:58) abadger1999: greetings (10:00:58) thl: anyone here? (10:01:01) rdieter: here (10:01:28) ***jima is here-but-rabble. (10:01:34) ***c4chris is here (10:01:47) thl: mmcgrath, are you around? (10:02:08) c4chris: you've got mail... (10:02:46) thl: hmmm, let's start slowly (10:02:51) tibbs: I'm around. (10:03:00) thl has changed the topic to: FESCO meeting -- Enhance AWOL (10:03:27) thl: tibbs, are these the changes we need to discuss? http://www.fedoraproject.org/wiki/Extras/Schedule/EnhanceAWOL?action=diff&rev2=5&rev1=3 (10:03:33) tibbs: thl: It has been a very bad couple of weeks for me; did you get all the information you needed from me on this item? (10:04:00) thl: tibbs, np, it nothing that needs to be solved today (10:04:21) thl: I'd just like to know if above wiki link contains all the changes in question (10:04:30) ***dgilmore is here (10:04:31) thl: or if there is still something missing (10:05:01) scop [n=scop] entered the room. (10:05:19) thl: tibbs ? (10:05:42) tibbs: Just checking my mail archive. (10:05:55) ***jeremy is trying to watch here, fwiw (10:06:16) tibbs: Yes, that has the additional "notes for mass orphaning" section and the change to the Coverage section. (10:06:25) tibbs: Those were the two changes I proposed. (10:06:40) tibbs: Well, mjk proposed them and I wrote them up. (10:06:53) thl: okay; then I'd say we give all FESCo members a chance to look at it in the next week (10:07:01) thl: and we vote on it next week (10:07:05) thl: that okay for everybody? (10:07:11) bpepple: fine by me. (10:07:14) rdieter: ok. (10:07:18) c4chris: k (10:07:37) thl has changed the topic to: FESCO meeting -- When to moidify other peoples packages (10:07:50) thl: k, what do people think? (10:07:57) thl: do we want to wait another week? (10:08:07) c4chris: looks fine to me as is (10:08:09) thl: discussion on f-e-l was smaller than I expected (10:08:23) warren [i=warren] entered the room. (10:08:37) rdieter: fine, I'm +1 (now, no need to wait) (10:08:37) c4chris: the only conflictual part has been removed... (10:08:37) tibbs: I think it's fine; we can always tweak it if there are problems. (10:08:42) bpepple: looks good to me also. The only complaint I heard was about FESCO members being sponsors. (10:08:47) warren: Sorry folks, i'm here now (10:09:13) jeremy: it looked fine to me too (10:09:32) thl: okay, so then let's do a final vote (10:09:42) c4chris: +1 (10:09:43) thl: +1 for the proposal in http://www.fedoraproject.org/wiki/Extras/Schedule/FixStuffThatNeedsFixing (10:09:44) bpepple: +1 (10:09:46) spot: +1 (10:09:55) jeremy: +1 (10:09:56) scop: +1 (10:10:01) rdieter: +1 (still) (10:10:08) abadger1999: +1 (10:10:16) tibbs: +1 (10:10:25) thl: hey, that was easy (10:10:28) thl: settled (10:10:32) thl: moving on (10:10:47) c4chris: wow, 9 total :) (10:10:49) thl has changed the topic to: FESCO meeting -- Enterprise Extras (10:11:08) thl: so, have all read jeremy's mail? (10:11:14) thl: he sent it 20 minutes ago (10:11:14) bpepple: yup. (10:11:16) c4chris: yup (10:11:18) jeremy has changed the topic to: FESCO meeting -- EPEL (10:11:20) green_ [n=green] entered the room. (10:11:20) tibbs: Yes. (10:11:23) rdieter: rock. (10:11:24) abadger1999: yes (10:11:32) tibbs: They don't like the name? (10:12:06) jeremy: tibbs: there's a bit of an impossible quandry in naming. we can't do fedora, we can't do rhel, we can't do centos... so I think we're to as good as we can get (10:12:19) jeremy: but if someone has other ideas, I'm more than willing to try to run with them (10:13:06) tibbs: I guess it's up to those who don't like it to suggest something that would make them happier. (10:13:28) giallu left the room (quit: Connection timed out). (10:13:44) dgilmore: tibbs: +1 (10:13:47) jeremy: tibbs: I tend to agree... and that's what I told the marketing people. if they can come up with something better, I'll run with it to this side too :) (10:14:40) tibbs: So where do we go from here? (10:14:43) thl: jeremy, btw, didn#t they like the short version (EPEL) or the long one (10:15:03) thl: tibbs, I think we proceed as planed (10:15:03) jeremy: thl: the short version went over better for the most part (10:15:08) jeremy: and yeah, proceed as planned (10:15:23) dgilmore: jeremy: so you can get us started with branches? (10:15:25) thl: that means: dgilmore and mmcgrath look into branching some packages in cvs (10:15:33) thl: test the buildsys (10:16:01) thl: build some packages (10:16:02) kushal [n=kd] entered the room. (10:16:07) thl: if that's done some of the FESCo members start to build their packages (10:16:13) jeremy: dgilmore: yeah, you and/or mmcgrath can catch up with me and we'll make it happen (10:16:27) dgilmore: jeremy: :) ill grab you latter about it (10:16:28) thl: jeremy, your opinion please: where to upload packages? (10:16:32) a16556dw left the room (quit: Read error: 104 (Connection reset by peer)). (10:17:00) thl: jeremy, would something like http://download.fedora.redhat.com/pub/epel work? (10:17:14) dgilmore: thl: /pub/fedora/extras/epel// (10:17:15) jeremy: thl: maybe. let me think for a little bit (10:17:28) thl: jeremy, thx (10:17:47) thl: dgilmore, some mirror admins didn#t like that to much (10:18:02) thl: they want it seperated from the fedora extras stuff (10:18:04) thl: afaics (10:18:22) thl: any further question regarding epel? (10:18:27) warren: none here (10:18:58) thl has changed the topic to: FESCO meeting -- Packaging Committee Report (10:19:06) thl: spot, abadger1999, rdieter, tibbs, scop ? (10:19:10) tibbs: No meeting this week. (10:19:20) drpixel [n=drpixel] entered the room. (10:19:22) abadger1999: And meetings are happening on Tuesdays (10:19:25) tibbs: The time is changing; next meeting will be Tuesday. (10:19:33) nim-nim [n=nim-nim] entered the room. (10:19:33) abadger1999: So we can email changes to the list. (10:19:38) spot: we're nuking X-Fedora though. (10:19:47) bpepple: That make sense. (10:20:06) thl: okay (10:20:09) warren: BTW, timezone is shifting soon (10:20:09) tibbs: spot: Did we get sufficient votes? I haven't checked my mail. (10:20:22) warren: we should plan next week's meeting time explicitly so people aren't confused (10:20:25) spot: tibbs: i think so, i havent voted yet, but i'm +1 (10:20:33) tibbs: That would do it, then. (10:20:34) thl has changed the topic to: FESCO meeting -- time zone (10:20:48) thl: so next week is then 18:00 UTC ? (10:21:01) dgilmore: thl: sure (10:21:01) warren: I'm not sure about the implications yet. (10:21:05) ***thl always get confused by that timeshifts (10:21:11) rdieter: worksforme (10:21:24) thl: I think that was the agreement this spring (10:21:33) thl: 17:00 UTC during summers and 18:00 during winters (10:21:44) thl: so the effective time stays the same for most people (10:21:48) thl: afaik (10:21:51) bpepple: sounds good. (10:21:53) Belegdol [n=jsikorsk entered the room. (10:21:54) warren: when does the european timezone shift? (10:21:58) c4chris: sounds fine to me (10:21:58) thl: Saturday (10:22:07) warren: and we're sunday (10:22:15) warren: so nothing apparent changes for us =) (10:22:24) thl: warren, well, in fact it's early Sunday here, too (10:22:35) warren: OK, let's move forward. (10:22:45) thl has changed the topic to: FESCO meeting -- Sponsorship nominations (10:22:53) thl: cwickert ? (10:22:58) warren: One question first (10:23:03) thl: warren, shoot (10:23:09) warren: Only FESCO members vote for sponsorship nominations count right? (10:23:16) ***jwb is here (10:23:20) thl: warren, yes (10:23:29) warren: ok, proceed (10:23:41) thl: okay, so cwickert again (10:23:47) thl: he recieved some +1 on the list (10:23:54) thl: and no one complained afaics (10:23:55) thl: so +1 (10:23:59) warren: +1 (10:24:00) c4chris: +1 (10:24:03) bpepple: +1 (10:24:09) spot: +1 (10:24:16) abadger1999: +1 (10:24:35) thl: okay, accepted (10:24:54) tibbs: I abstained because I'm not familiar enough with his work. (10:25:01) scop: ditto (10:25:05) thl: so, what about "Mamoru Tasaka" ? (10:25:12) warren: +1 (10:25:13) thl: you've seen the discussions on the list (10:25:15) warren: Yes (10:25:25) bpepple: +1 (10:25:35) thl: I'm not to familiar with his work, but he get's a +1 from me, too (10:25:43) jwb: i'll abstain (10:25:45) warren: I think his intentions and loyalties are in the right place. (10:25:55) thl: warren, agreed (10:25:59) ***spot abstains (10:26:05) tibbs: Well, Ralf objects, but I'm not sure to what he objects. (10:26:13) warren: Is Ralf on FESCO? (10:26:21) tibbs: No, but he is a sponsor (10:26:23) jwb: warren, that doesn't matter (10:26:23) rdieter: no (10:26:34) scop: +0.5, but I think waiting a bit wouldn't hurt (10:26:34) tibbs: His opinion does matter. (10:26:38) jwb: he is a sponsor and we should at least investigate some of his concerns (10:26:40) warren: Ralf objects to a lot of things (10:26:45) thl: tibbs, sure (10:26:57) c4chris: I'd prefer to wait a bit... +0.5 (10:27:00) jwb: warren, yes. some of them accurately (10:27:03) tibbs: Well, that's the problem with Ralf. He objects often, and doesn't often give concrete examples. (10:27:23) tibbs: The problem is that we're neglecting to approve someone who has a body of reviews, and have just approved someone who has few. (10:27:33) c4chris: warren, I was going to say exactly the same... :-) (10:27:43) ***dgilmore abstains also (10:27:53) dgilmore: but ralf objects to everything (10:28:09) thl: let's not discuss ralf here (10:28:14) tibbs: Do note that the PackageStatus report has a link to all of Mamoru's reviews. (10:28:24) thl: "Mamoru Tasaka" is on topic here (10:28:31) warren: What damage can really happen here? We'll work through any difficulty if it happens. (10:28:47) warren: Nobody in FESCO is against it, let's just move forward. (10:29:05) thl: I tend to think the same (10:29:09) bpepple: warren: +1 (10:29:13) thl: that were 3 +1, 2 +0.5 (10:29:19) spot: ehh, i'll +1 (10:29:23) spot: give him the benefit of the doubt (10:29:25) tibbs: Well, I nominated him, and he has actually expressed interest in becoming a sponsor. (10:29:33) warren: and he's pretty productive (10:29:33) c4chris: k, +1 then (10:29:45) nbecker left the room (quit: Read error: 101 (Network is unreachable)). (10:29:47) tibbs: So obviously +1 from me. (10:29:48) dgilmore: +1 on tibbs recomendation (10:29:54) ***warren got some useful patches for Core from him too. (10:29:55) thl: 7x+1, 2x0.5 (10:30:12) thl: means accepted (10:30:23) thl: tibbs, what's his username? (10:30:53) thl: btw, didn't re nominate a thir person last week? (10:31:00) thl: s/re/we/ (10:31:02) thl: third (10:31:07) ***bpepple thought it was only the two. (10:31:07) thl: steven? (10:31:20) tibbs: Yes, silug was also mentioned. (10:31:29) tibbs: Lots of packages, not many reviews. (10:31:38) c4chris: I think there's still the case of pfj... (10:31:41) tibbs: He had come up a couple ofmonths ago as well. (10:31:44) thl: okay, I'll propose him on the list (10:31:56) cwickert [n=chris] entered the room. (10:31:56) tibbs: And yes, we really should reconsider pfj. (10:32:13) thl: can anyone propose them on the sponsors-list? (10:32:16) warren: BTW, another topic that we need to discuss sometime (maybe not today) is to formally create other paths to gain higher ranks in the project. (10:32:25) warren: (Initial sponsorship especially) (10:32:36) thl: then we can discuss those two in the next with all sponsors (including ralf) (10:32:43) thl: and vote on it next week (10:32:57) bpepple: warren: Doesn't that tie into co-maintainership a bit? (10:33:43) thl: bpepple, maybe (10:33:49) tibbs: Folks, the account system is behaving badly for me at the moment; I think Mamoru's ID is mtasaka. (10:33:50) thl: warren, or do you have any ideas? (10:34:04) c4chris: brb (10:34:46) thl: seems not (10:35:07) thl: does anybody know pfj and silug quite well and can nominate them on the sponsors list? (10:35:29) warren: bpepple, not exactly (10:35:42) thl: hey, come one; do I have to do this as well? (10:35:43) tibbs: I have worked with both of them; I'm just not sure that silug meets the criteria because I'm no longer sure what the criteria are. (10:36:04) warren: tibbs, that is part of what i'm talking about. (10:36:04) tibbs: pfj I will happily nominate. (10:36:19) abadger1999: Does he understand packaging. (10:36:24) Finalzone left the room (quit: "Leaving."). (10:36:27) thl has changed the topic to: FESCo meeting -- sponsorship criteria (10:36:37) tibbs: abadger1999: Yes, he understands packaging. (10:36:38) abadger1999: I think that being able to demonstrate that is the short version. (10:36:40) warren: We've began to promote people to sponsorship status who didn't fill the past role of "active reviewer". Some were only very active packagers but didn't do much reviewing. (10:36:57) ***thl for example (10:37:04) tibbs: In fact, he's directly or indirectly (via cpanspec) responsible for most of the Perl module stuff in Extras. (10:37:19) jwb: i think i fit that bill (10:37:30) warren: We also need to create a formal way to get people into the first rank (sponsored) without necessarily submitting packages, like if they are clearly qualified and want to maintain 17 orphans, and an existing sponsor is willing to accept responsibility for their education and fixing their mistakes. (10:37:50) warren: We need to formalize multiple possible paths to gain ranks. (10:37:56) warren: and write them down (10:38:06) Finalzone [n=luya] entered the room. (10:38:17) thl: warren, agreed, but the co-maintainershipt should help the "take over orphans" things, too (10:38:30) bpepple: thl: That's what I was sorta thinking. (10:38:56) warren: Another example is one Fedora contributor and community leader in Japan. He wants to build a fedora contributing community in Japan, but they aren't able to effectively communicate in English. I want to eventually give him sponsorship status and he can be responsible for bringing in non-english contributors, educating and being accountable to their mistakes. (10:39:25) jwb: warren, i've been wondering about that as well (10:39:29) thl: warren, can you write your ideas doen a bit? (10:39:34) tibbs: Conveniently, Mamoru may be able to help with that. (10:39:35) thl: warren, I can prepare a page in hte wiki (10:39:36) warren: Yeah, I should start this on-list. (10:39:44) thl: warren, thx (10:39:51) warren: Yeah, Mamoru could help Dairiki. (10:39:56) Belegdol: what's the difference between dajavu-fonts (Extras) and dejavu-lgc-fonts (Core)? (10:40:06) warren: Belegdol, off-topic, we're in a meeting here. (10:40:20) Belegdol: oh, sorry. did not know that (10:40:24) thl: do we want want to discuss this further now? (10:40:36) warren: Not really, need to expand this. Will go on extras-list (10:40:49) warren: Where are the existing co-maintainership proposed plans? (10:40:51) warren: I can fold that in (10:41:03) thl has changed the topic to: FESCo meeting -- approve kmod's (10:41:11) bpepple: warren: http://fedoraproject.org/wiki/Extras/Schedule/Comaintainership (10:41:18) warren: thx (10:41:19) thl: warren, everything should be linked from the schedule page in the wiki always (10:41:51) thl: rt2x00-kmod still on the list (10:41:59) warren: part of my ideas here is to also create a numbered ranking structure, like FD0, FD1, FD2, FD3, etc. This will be useful as we merge Core + Extras + Legacy and form subsets of ACL groups. (10:41:59) thl: jwb, what do you think? (10:42:11) Belegdol left the room (quit: "Leaving"). (10:42:17) ***cweyl grabs his rabble seat a touch late (10:42:34) jwb: thl, it troubles me... but i cannot vote against it at the moment (10:42:53) warren: bug #? (10:42:54) thl: I think the code is clearly on the road to the kenrnel (10:43:03) f13: warren: oh come on, you want to do a level based system right? level 1 packager, level 2 packager, level 4 reviewer, and of course, the level 20 release maintainer (10:43:08) thl: so it's acceptable for the kmod rules (10:43:10) bpepple: warren: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202528 (10:43:19) jwb: thl, yes i can agree with that (10:43:22) thl: the other stuff is a matter of the review IMHO (10:43:27) thl: (mostly) (10:43:33) ***f13 weilds his +4 specslicer (10:43:43) thl: but I'm sure jwb, scop and I will watch the kmod packages (10:43:45) jima: f13: i knew this thread was on its way to a d&d joke. (10:43:52) spot: can i have a mountain dew? (10:44:04) warren: f13, it was just an idea, we can discuss options. (10:44:05) dgilmore: spot: nope (10:44:11) warren: f13, (later) (10:44:17) jima: spot: we're out of everything but coke here :( (10:44:18) thl: so I'm inclined to allow rt2x00-kmod (and the devicescape stack that's part of it) (10:44:37) tibbs: Has anyone talked to Linville about this? (10:44:50) thl: don't think so (10:44:54) tibbs: He probably has a better handle on what's happening with wireless than we do. (10:45:17) thl: tibbs, good idea, I'll ask him (10:45:22) tibbs: For all we know, he already has it in his kernels. (10:45:54) thl: and in the netdev-tree with the other devicescape stuff (10:45:59) scop: my +1 for the package unless Linville yells (10:46:01) thl: that's planed to get merged sooner or later (10:46:05) warren: +1 for scop (10:46:10) jwb: scop, +1 (10:46:14) abadger1999: scop: +1 (10:46:15) rdieter: scop +1 (10:46:17) thl: scop, +1 (10:46:22) bpepple: scop: +1 (10:46:24) c4chris: +1 (10:46:29) tibbs: +1 (10:46:38) thl: okay, nearly accepted (I'll ask Linville) (10:46:44) dgilmore: +1 (10:46:53) thl has changed the topic to: FESCo meeting -- Maintainer Responsibility Policy (10:46:59) thl: sorry, to much work atm (10:47:08) thl: anyone interested in drivering this forward? (10:47:18) warren: I can ask linville (10:47:26) |DrJef| [n=jefrey] entered the room. (10:47:32) thl: e.g. kick of a discussion on f-e-l, write a proposal, discuss it again, ... ? (10:47:39) tibbs: I would really like to see this driven forward. (10:47:40) warren: oh (10:47:55) thl: warren, thx for asking linville (10:47:58) tibbs: I just don't know if I can drive it at the moment. Maybe in a few days. (10:47:59) c4chris: no time atm (winter term starting here...) (10:48:23) bpepple: I can work on it. (10:48:58) thl: bpepple, k, thx, you'll be the future owner on the schedule page (10:49:04) bpepple: np (10:49:11) thl has changed the topic to: FESCo meeting -- free discussion around extras (10:49:28) thl: anyone interested in one of the other items from the schedule? (10:49:33) thl: Comaintainership (10:49:38) thl: Package Database (10:49:45) jwb: how's the merge going? (10:49:45) thl: Use comps.xml properly (10:49:46) c4chris: any news from the Coverity thing ? (10:50:01) warren: I thought we shot down the Coverity thing? (10:50:04) thl: jwb, merge? (10:50:08) cweyl: thl: is there a comaintainership proposal written up somewhere? (10:50:16) warren: I made it very clear that it is inappropriate for Fedora to do anything with Coverity. (10:50:19) c4chris: jwb, ? (10:50:22) jwb: thl, core+extras merge (10:50:31) bpepple: cweyl: http://fedoraproject.org/wiki/Extras/Schedule/Comaintainership (10:50:34) thl: cweyl, comaintainership mostly waits for a new VCS and the package database (10:50:35) cweyl: bpepple: thx :) (10:50:47) c4chris: warren, k, then we should remove this from the schedule page... (10:51:11) thl: c4chris, it it still there? (10:51:23) ***thl can't locate it (10:51:23) c4chris: MISC -long term (10:51:38) thl: ohh, thx (10:51:56) thl: well, I can't rememebr if it was shot down completely, but if it was (10:51:59) thl: then I'll remove it (10:52:05) thl: and it looks like it was (10:52:21) thl has changed the topic to: FESCo meeting -- core+extras merge (10:52:26) thl: warren, jeremy, f13 (10:52:33) thl: everybody is talking about it now and then (10:52:50) thl: but we outside of RH don't know much about it (10:52:55) thl: is that on purpose? (10:53:04) thl: or is that a "we need to get some work done" (10:53:10) warren: thl, people have been pretty stressed out with FC6 and RHEL5 fires lately, little time to work on merge (10:53:18) thl: or "we need the package database and the new VCS first"? (10:53:24) jwb: warren, how do we enable non-RH people to work on it? (10:53:31) warren: good question.... (10:53:49) warren: jeremy, f13: have time to talk about our next steps this week? (10:54:20) warren: jeremy earlier this week had an interesting idea that I hadn't considered before regarding merge. (10:54:28) thl: there is also still the question: do we switch to real relases for extras whith the merge? (10:54:35) warren: That the necessary pieces are huge and numerous, and we should take this step-by-step instead. (10:54:37) f13: warren: possibly, there is some discussion happening in the Fedora Board right now. (10:54:47) jima: thl: i suspect so. (10:54:48) warren: f13, ok (10:55:05) thl: jima, /me, too, that's why I'm asking ;) (10:55:18) f13: thl: I suspect that we'll have two teams going. One team is concentrating on the Package Universe as a whole and keeping things going, while there will also be a Release team that will set a freeze time and manage the branching for the release. (10:55:44) |DrJef|: thl, i think at the end of the day... both core and extras will have to shift a little in release model... to mini-releases (10:55:51) jwb: i'm only interested in the VCS merge at the moment (10:55:55) warren: thl, we inside have a little room to breathe now that FC6 is out, I suspect we'll have a better clue by next week's meeting. (10:55:56) jwb: i view that as step 1 (10:56:00) f13: devel/ will ever be rolling, while releases are actual releases with actual 'updates' issued. (10:56:01) |DrJef|: thl, not unlike what fedora unity respins are doing already (10:56:12) warren: Yes indeed, jeremy suggested that as step 1. (10:56:22) jima: jwb: is step 2 buildsys unity? (10:56:25) warren: and to even use CVS at first because we KNOW how it works, and we can migrate off of it later. (10:56:26) ***f13 is making some progress with mercurial. (10:56:35) |DrJef|: thl, but 'end of the day' is a ways off (10:56:49) jwb: jima, not sure (10:56:52) warren: f13, did you adapt the package dir makefiles to it? (10:57:36) Tjikkun_ left the room (quit: "Ex-Chat"). (10:57:37) thl: |DrJef|, I think the respins from unity are something good (but of course hard to support) (10:57:37) sureshot [n=sureshot] entered the room. (10:58:03) warren: thl, No objection from linville regarding that kmod, although he is confused about "it looks like his spec is pulling the stack from somewhere other than wireless-dev" (10:58:11) jima: pungi (if it takes off) ought to be nice for fedora unity's respins. (10:58:29) sureshot left the room ("Konversation terminated!"). (10:58:32) thl: warren, k, noted; somebody should mention it in the bug (10:58:46) thl: warren, maybe it's the rt2x00 project that did it (10:58:49) warren: thl, I'll have him follow-up through bugzilla. (10:58:54) thl: warren, great (10:59:02) jwb: thl, i think is the case (10:59:05) f13: warren: haven't made quite that much progress, more like getting the xen box setup for it. (10:59:21) thl: well, seems we're at the the end of the "merge" debatte for now (10:59:24) f13: warren: I have done some personal migrations of CVS to Xen, complete with some Makefile adjustments for tagging. (10:59:32) |DrJef|: thl, im not saying spin up isos.. on the master server with every iso release.. what im saying is.. there is gonna need to be some timestamping so we can point to a consistent universe of packages in coxtras that can be spun up by community members with tools like the thing f13 is pimping lately (10:59:35) warren: f13, we have a mercurial testbed in the fedora xen too, not sure if any progress happened there after I left for Asia though. (10:59:39) thl: I'll put it on the schedule so we talk about it now and then in future meetings (10:59:52) |DrJef|: thl, timestamping like quarterly (10:59:56) warren: We'll follow up on this next week. (11:00:06) f13: warren: test1 was handed to me for mecurial testing. (11:00:15) thl: |DrJef|, yeah, might be a good idea (11:00:18) warren: f13, ah ok (11:00:47) thl has changed the topic to: FESCo meeting -- free discussion regarding extras (11:00:50) thl: anything else? (11:01:02) c4chris: nope (11:01:41) ***thl will close the meeting in 60 (11:02:04) dgilmore: Just want to say thanks for the paitence with the buildsys outages (11:02:09) ***thl will close the meeting in 30 (11:02:15) thl: dgilmore, thx for your work (11:02:22) thl: on the buildsys (11:02:29) jwb: indeed. thank you (11:02:31) ***thl will close the meeting in 10 (11:02:41) thl: -- MARK -- Meeting end }}} -------------- next part -------------- A non-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 Thu Nov 2 07:54:37 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 02 Nov 2006 08:54:37 +0100 Subject: Fedora Extras Meeting Minutes 2006-10-26 In-Reply-To: <1162452517.5230.0.camel@localhost> References: <1162452517.5230.0.camel@localhost> Message-ID: <1162454077.23713.40.camel@mccallum.corsepiu.local> On Wed, 2006-11-01 at 23:28 -0800, Toshio Kuratomi wrote: > = 2006 October 26 FESCo Meeting = > (10:26:05) tibbs: Well, Ralf objects, but I'm not sure to what he > objects. I objected to making this person a sponsor ATM (!), because I do not think he is qualified *yet* and needs some more time to learn and gain experience. > (10:26:13) warren: Is Ralf on FESCO? > (10:26:21) tibbs: No, but he is a sponsor > (10:26:23) jwb: warren, that doesn't matter Wasn't FESCo about to change something about the nomiation and election procedures? Seems to me as if this attempt has even failed before it begun. > (10:28:24) thl: "Mamoru Tasaka" is on topic here > (10:28:31) warren: What damage can really happen here? We'll work > through any difficulty if it happens. What happens, is this person having going too far and overengineering packages. As a consequence of this, he now is blocking reviews. In case of xtide (His own submission), he missed to notice how his changes lack sustainability and conflict/break with upstream. IMO, this is a masterpiece of a review, having failed due to lack of qualification. Fortunately, in this particular case, upstream seems to react, which probably will resolve the xtide review failures in not too distant future. > (10:28:47) warren: Nobody in FESCO is against it, let's just move > forward. On the discussion preceeding your meeting, others also had preliminaries against him (IIRC, comprising at least one FESCo member). Also note the persons being involved in the xtide review. At least one person being involved there, at least shares some aspects of my opinions. Anyway, this all is a dead horse, and it really doesn't make any sense to further discuss this. Ralf From j.w.r.degoede at hhs.nl Thu Nov 2 09:51:37 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 02 Nov 2006 10:51:37 +0100 Subject: Free enough for FE In-Reply-To: <1162446636.7933.436.camel@dhcp-32-122.ord.redhat.com> References: <4548ACCB.1050706@hhs.nl> <1162407042.29648.11.camel@rousalka.dyndns.org> <4549061B.2000300@hhs.nl> <1162446636.7933.436.camel@dhcp-32-122.ord.redhat.com> Message-ID: <4549BFA9.2060100@hhs.nl> Tom 'spot' Callaway wrote: > On Wed, 2006-11-01 at 21:39 +0100, Hans de Goede wrote: > >> So if I'm reading this correct then there are no objections? >> >> I'll let this thread "run" for a couple of more days and if there are still no objections then, then I'll start working on a package. > > I asked the FSF on this one (they're usually pretty responsive) and > their initial feedback is that this should be ok. > > This maps up with my feelings on it too, so go ahead and package it. > Great! I assume / hope that this means it is ok to move scummvm from that other repo to FE too? Since AFAIK the rule for emulators (interpreter in this case really), is that when there is free content to use them with it is ok. The license I posted is from the "Beneath a Steel Sky" and "Flight of the Amazon Queen" data files now released by their owners under this license, these are two games of a short list of games which were written for other operating systems using a virtual machine kinda setup for easy portability. ScummVM is a re-implementation of that virtual machine for a brother range of operating systems including Linux. ScummVM itself is licensed under the GPL In the case of "Beneath a Steel Sky", the scummvm support for this title (there were severant different revisions of the scumm virtual machine) has been added with support of the original copyright holders, they even gave the scummvm team access to the sources of the original game to help them support it! So I assume this means that scummvm is ok for FE? Regards, Hans From giallu at gmail.com Thu Nov 2 12:46:21 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 2 Nov 2006 14:46:21 +0200 Subject: failing kmod build for FC-6 Message-ID: I am trying to update a kmodule I maintain (sysprof-kmod) but "make tag" fails because the tag it is trying to apply on the FC-6 branch was already used for building the -devel one. This seems to be the result of having a .fc6 kernel package in the development repo, whereas I expectd to find one with a .fc7 dist tag. How can I fix the situation? What could have been done to prevent me from falling in this trap? Thanks a lot for any insight Gianluca From paul at city-fan.org Thu Nov 2 12:56:19 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 02 Nov 2006 12:56:19 +0000 Subject: failing kmod build for FC-6 In-Reply-To: References: Message-ID: <4549EAF3.9020006@city-fan.org> Gianluca Sforna wrote: > I am trying to update a kmodule I maintain (sysprof-kmod) but "make > tag" fails because the tag it is trying to apply on the FC-6 branch > was already used for building the -devel one. > This seems to be the result of having a .fc6 kernel package in the > development repo, whereas I expectd to find one with a .fc7 dist tag. > > How can I fix the situation? What could have been done to prevent me > from falling in this trap? > > Thanks a lot for any insight Did you do a "cvs update" in your extras cvs checkout area (including for the "common" module? Paul. From dtimms at iinet.net.au Thu Nov 2 14:04:53 2006 From: dtimms at iinet.net.au (David Timms) Date: Fri, 03 Nov 2006 01:04:53 +1100 Subject: extras package that simplifies installation of vmware packages ? Message-ID: <4549FB05.10608@iinet.net.au> Hi I am thinking of creating a package called vmware-server-prerequisites. This could have requires of the rpms that need to be installed for vmware to be able to run. It could also include the any-any patch {although some people are saying it isn't need with k-2.6.18 / fc6}. Perhaps also a sub package called vmware-server-console-prerequisites, that has any packages that it might need. My understanding is that to be part of fedora-extras, I could not require the vmware package itself, ie I could only require packages in core or extras. Without knowing any details about dkms I would imagine that some trickery could be performed so that a kernel update causes a vmware module recompile. Any thoughts on possibilities and on incorporating such in extras ? DaveT. From fedora at leemhuis.info Thu Nov 2 14:37:01 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 02 Nov 2006 15:37:01 +0100 Subject: extras package that simplifies installation of vmware packages ? In-Reply-To: <4549FB05.10608@iinet.net.au> References: <4549FB05.10608@iinet.net.au> Message-ID: <454A028D.30503@leemhuis.info> Hi! David Timms schrieb: > Hi I am thinking of creating a package called vmware-server-prerequisites. > This could have requires of the rpms that need to be installed for > vmware to be able to run. It could also include the any-any patch > {although some people are saying it isn't need with k-2.6.18 / fc6}. > Perhaps also a sub package called vmware-server-console-prerequisites, > that has any packages that it might need. > > My understanding is that to be part of fedora-extras, I could not > require the vmware package itself, ie I could only require packages in > core or extras. Correct. > Without knowing any details about dkms I would imagine that some > trickery could be performed so that a kernel update causes a vmware > module recompile. No, the vmware modules are not acceptable for extras afaik as they might have similar (not directly identical) problems as the nvidia or ati drivers -- see the recent ndiswrapper discussion on lkml and/or http://lwn.net/Articles/205644/. And I don't know if the vmware license even allows to ship only the kernel modules. > Any thoughts on possibilities and on incorporating such in extras ? I don't think it's possible or makes to much sense in Extras. Maybe you have more luck in one of the 3rd party repos. CU thl From fedora at leemhuis.info Thu Nov 2 14:38:29 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 02 Nov 2006 15:38:29 +0100 Subject: failing kmod build for FC-6 In-Reply-To: References: Message-ID: <454A02E5.2020408@leemhuis.info> Gianluca Sforna schrieb: > I am trying to update a kmodule I maintain (sysprof-kmod) but "make > tag" fails because the tag it is trying to apply on the FC-6 branch > was already used for building the -devel one. > This seems to be the result of having a .fc6 kernel package in the > development repo, whereas I expectd to find one with a .fc7 dist tag. > > How can I fix the situation? Showing us the exact error message might help us to give a proper answer. > What could have been done to prevent me > from falling in this trap? Do you have a .rpmmacros and ~/rpmbuild on the machine where you tried to tag? Is kmodtool available from where you tag? Cu thl From Christian.Iseli at licr.org Thu Nov 2 16:23:36 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 2 Nov 2006 17:23:36 +0100 Subject: FE Package Status of Nov 2, 2006 Message-ID: <20061102172336.1f28a4b1@ludwig-alpha.unil.ch> Hi folks, This week's edition just landed in the wiki. I did some cleanup of the comps.xml files for FC-6 and FC-devel. They should now contain packages actually available in the repo. I'll try to take a look why we have 23 closed FE-ACCEPT tickets with no corresponding package in the repo (unless someone beats me to it, that is :-) ) There are several missing entries in owners.list, too... Cheers, C ---- FE Package Status of Nov 2, 2006 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 2463 packages - 114 orphans - 16 packages not available in extras devel or release 3rdshift at comcast dot net libassa 3rdshift at comcast dot net granule andreas at bawue dot net e2tools andreas at bawue dot net ddrescue bdpepple at ameritech dot net galago-filesystem cweyl at alumni dot drew dot edu perl-GStreamer gemi at bluewin dot ch TeXmacs ghenry at suretecsystems dot com john j dot w dot r dot degoede at hhs dot nl MagicPoint matthias at rpmforge dot net SDL_pango miker5slow at grandecom dot net ruby-bdb orion at cora dot nwra dot com freefont paul at all-the-johnsons dot co dot uk mysql-connector-net paul at all-the-johnsons dot co dot uk gconvert paul at all-the-johnsons dot co dot uk gtksharp pertusus at free dot fr ivman - 3 packages not available in extras devel but present in release cweyl at alumni dot drew dot edu gaim-gaym miker5slow at grandecom dot net fluxstyle twaugh at redhat dot com international-time - 6 packages which have not yet been FE-APPROVE'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=203864,209870,211626,211763 tripwire fedora at theholbrooks.org prozilla kushaldas at gmail.com xtide mtasaka at ioa.s.u-tokyo.ac.jp jikes paul at all-the-johnsons.co.uk https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=198644,212704 new pb at bieringer.de manedit mtasaka at ioa.s.u-tokyo.ac.jp - 9 packages present in the development repo which have no owners entry SDL_Pango crossvc gtk-sharp itpp ktechlab php-pecl-Fileinfo pygpgme system-switch-im toped - 19 orphaned packages, yet available in extras devel FreeWnn aspell-mi buildbot doctorj fltk gdk-pixbuf gnofract4d gnome-password-generator gnome-themes-extras gurlchecker imlib leafpad libedit lostirc pam_mount pam_mysql pam_script python-cvstoys screem - 43 packages that moved to core FE-ACCEPT packages stats: - 1481 accepted, closed package reviews - 23 accepted, closed package reviews not in repo - 17 accepted, closed package reviews not in owners - 11 accepted, open package reviews older than 4 weeks; - 8 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 87 open tickets - 16 tickets with no activity in eight weeks - 21 tickets with no activity in four weeks - 5 closed tickets FE-NEW packages stats: - 163 open tickets - 27 tickets with no activity in eight weeks - 34 tickets with no activity in four weeks FE-NEEDSPONSOR packages stats: - 42 open tickets - 5 tickets with no activity in eight weeks - 9 tickets with no activity in four weeks FE-LEGAL packages stats: - 1 open tickets FE-GUIDELINES packages stats: - 2 open tickets - 1 tickets with no activity in eight weeks - 1 tickets with no activity in four weeks OPEN-BUGS packages stats: - 248 open tickets - 94 tickets with no activity in eight weeks - 35 tickets with no activity in four weeks CVS stats: - 2461 packages with a devel directory - 9 packages with no owners entry SDL_Pango crossvc eclipse-emf gtk-sharp itpp ktechlab php-pecl-Fileinfo pygpgme toped - 193 packages were dropped from extras Maintainers stats: - 230 maintainers - 1 inactive maintainers with open bugs - 2 inactive maintainers Dropped FC packages: - 283 packages were dropped from core since FC 1 Comps.xml files stats: - 821 packages in comps-fe7 file - 447 packages missing from comps-fe7 file - 821 packages in comps-fe6 file - 448 packages missing from comps-fe6 file From tcallawa at redhat.com Thu Nov 2 16:37:35 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 02 Nov 2006 10:37:35 -0600 Subject: Free enough for FE In-Reply-To: <4549BFA9.2060100@hhs.nl> References: <4548ACCB.1050706@hhs.nl> <1162407042.29648.11.camel@rousalka.dyndns.org> <4549061B.2000300@hhs.nl> <1162446636.7933.436.camel@dhcp-32-122.ord.redhat.com> <4549BFA9.2060100@hhs.nl> Message-ID: <1162485456.8918.11.camel@dhcp-32-122.ord.redhat.com> On Thu, 2006-11-02 at 10:51 +0100, Hans de Goede wrote: > Tom 'spot' Callaway wrote: > > On Wed, 2006-11-01 at 21:39 +0100, Hans de Goede wrote: > > > >> So if I'm reading this correct then there are no objections? > >> > >> I'll let this thread "run" for a couple of more days and if there are still no objections then, then I'll start working on a package. > > > > I asked the FSF on this one (they're usually pretty responsive) and > > their initial feedback is that this should be ok. > > > > This maps up with my feelings on it too, so go ahead and package it. > > > > Great! > > I assume / hope that this means it is ok to move scummvm from that other repo to FE > too? Since AFAIK the rule for emulators (interpreter in this case really), is that > when there is free content to use them with it is ok. > > The license I posted is from the "Beneath a Steel Sky" and "Flight of the Amazon Queen" > data files now released by their owners under this license, these are two games of a > short list of games which were written for other operating systems using a virtual > machine kinda setup for easy portability. ScummVM is a re-implementation of that virtual > machine for a brother range of operating systems including Linux. ScummVM itself is > licensed under the GPL > > In the case of "Beneath a Steel Sky", the scummvm support for this title (there were > severant different revisions of the scumm virtual machine) has been added with support > of the original copyright holders, they even gave the scummvm team access to the sources > of the original game to help them support it! So I assume this means that scummvm is ok > for FE? Agreed. It meets the necessary criteria: - emulator is free/open source - content is available for emulator which is freely redistributable ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From pertusus at free.fr Thu Nov 2 16:41:03 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 2 Nov 2006 17:41:03 +0100 Subject: FE Package Status of Nov 2, 2006 In-Reply-To: <20061102172336.1f28a4b1@ludwig-alpha.unil.ch> References: <20061102172336.1f28a4b1@ludwig-alpha.unil.ch> Message-ID: <20061102164103.GB2440@free.fr> On Thu, Nov 02, 2006 at 05:23:36PM +0100, Christian Iseli wrote: > - 16 packages not available in extras devel or release > pertusus at free dot fr ivman That's on purpose, I'd like to have some changes to ease updates, but upstream hasn't still responded. > - 6 packages which have not yet been FE-APPROVE'd... > https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=203864,209870,211626,211763 > xtide mtasaka at ioa.s.u-tokyo.ac.jp > manedit mtasaka at ioa.s.u-tokyo.ac.jp That's normal these are re-reviews; Maybe the script could check that there is no dead.package file (not a big deal). Also how could it be possible to blacklist some packages that are not to be in comps but don't have library or anything else to find it automatically (it is the case for the dap-*_handler packages I maintain)? -- Pat From Christian.Iseli at licr.org Thu Nov 2 17:20:25 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 2 Nov 2006 18:20:25 +0100 Subject: FE Package Status of Nov 2, 2006 In-Reply-To: <20061102164103.GB2440@free.fr> References: <20061102172336.1f28a4b1@ludwig-alpha.unil.ch> <20061102164103.GB2440@free.fr> Message-ID: <20061102182025.5f8ded45@ludwig-alpha.unil.ch> On Thu, 2 Nov 2006 17:41:03 +0100, Patrice Dumas wrote: > Maybe the script could check that there is no dead.package file (not a big deal). Added to the TODO items. > Also how could it be possible to blacklist some packages that are not to > be in comps but don't have library or anything else to find it automatically > (it is the case for the dap-*_handler packages I maintain)? Still unresolved. Someone once mentioned the possibility to put *all* packages in comps, by providing a group of packages that should not be presented to the user... Dunno how that would fare. There are also mumblings of putting comps related info in the upcoming package database, but we haven't looked deeply into the implications yet. C From a.badger at gmail.com Thu Nov 2 20:35:31 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 02 Nov 2006 12:35:31 -0800 Subject: FESCo Meeting Summary Nov 02 2006 Message-ID: <1162499731.2964.0.camel@localhost> = 2006 October 26 FESCo Meeting = == Members == === Present === * warren * thl * bpepple * tibbs * ch4chris * rdieter * abadger1999 * spot * scop * dgilmore === Absent === * awjb * jwb * jeremy == Summary == === Enhance AWOL === * Approved the proposal: http://www.fedoraproject.org/wiki/Extras/Schedule/EnhanceAWOL?action=diff&rev2=7&rev1=4 * Will discuss on fedora-extras-list whether to add a note about (non-mandatory) trying to track people down through other channels. === EPEL === * warren to help create the new EL4 and EL5 branch so dgilmore can start branching packages. === Packaging Committee Report === * http://fedoraproject.org/wiki/Packaging/Minutes20061031 * This is the first week that the packaging committee was able to meet on Tuesday and discuss things before the FESCo meeting. * Future minutes of the meetings will be sent to the fedora-maintainers[AT]redhat.com list. * FESCo had no objections to the proposals at this time. * FESCo agrees to approve requests to include static libraries for packages in Extras. === Sponsor Nominations === * Steven Pritchard (silug) and Paul F. Johnson (pfj aka nodoid) to be discussed on the sponsors list. bpepple will send out proposals. === Sponsor Criteria === * Need to document what the criteria is. * This week we'd like to have sponsors add their ideas for criteria to: http://fedoraproject.org/wiki/Extras/Schedule/SponsorCriteria * Discussion about the list that gets compiled on that page can take place on fedora-extras-list. * Ralf Corsepius's point about some sponsors not being qualified when accepted should be discussed on the list. * Warren is still working on the proposal for alternative paths to membership (besides package submission/review). === Misc === ==== Maintainer Announce ==== * Adminstratively, the list has been approved for creation. * jkeating has expressed concerns that having another list won't help. Core maintainers are disregarding fedora-maintainers for reasons that can't be solved by having another list. * ATM, Core maintainers would not be subscribed to (or required to subscribe to) a maintainers-announce list. * Concern expressed that having maintainer-announce-list without having Core maintainers subscribed will only lead to crossposting to maintainer-announce and maintainers; defeating part of the purpose. * Problem with maintainers-list is that currently not all Extras Maintainers are on maintainer-list. If we want that to be successful we need to automate adding maintainers to the list from the account system. * Some people feel maintainers is starting to have "too much" discussion. * There seems to be agreement that a moderated announce list with all maintainers from Core and Extras subscribed would have real value. Many people feel there is value even if Core maintainers do not subscribe. * Decided to talk to jkeating about this and get back to this next week. ==== Core + Extras Merge ==== * Internal face-to-face Red Hat meeting on Nov 12th-15th will hopefully resolve most of the non-technical hurdles to this. * Helping to build and test the next generation VCS (of which, f13's Mercurial repo is the most promising) is looking like the best way to help out on the technical end. ==== comps.xml ==== * We didn't push comps for FC-6 yet because of problems in the scripts to generate it. * mschwendt sent email about fixing things so "make comps" works again. ==== Static Libraries ==== * http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196393 * svr-core is a package necessary for Fedora Directory Server. It only builds static libraries. * We are upstream. * warren talked the Fedora Directory Server team into making it build shared libraries as well. ==== Maintainer Responsibilities ==== * Some arguments have been added to http://www.fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy from the email threads. * It was brought up that some of this may be in http://fedoraproject.org/wiki/Extras/Policy/EOL * Some of Policy/EOL was contentious at that time as well and some people think that certain clauses there were written to allow maintaining for older releases by primary packagers to be optional. * Proposal to get options from Extras Maintainers and then run a vote for which option to go with. Since the packagers are doing the work, it makes sense to let them decide. * Current options: 1. Maintain FE as long as Legacy maintains FC. 2. Maintain FE as long as Active Core releases. Drop thereafter (currently, <= FC4). 3. Primary packagers maintain as long as Active Core releases, an Extras Legacy Team maintains thereafter. ==== Changes to the Meeting Summary ==== * mschwendt has some ideas for improving post-meeting summaries: * https://www.redhat.com/archives/fedora-maintainers/2006-October/msg00336.html * https://www.redhat.com/archives/fedora-maintainers/2006-October/msg00376.html * The main goal seems to be to make it easier to understand what each FESCo member is trying to accomplish. * This is important as FESCo is a representative elected body. Knowing what FESCo members will vote for allows us to decide who we will vote for in future FESCo elections. * Concern was expressed that more formal voting might hinder getting things done. * Most people like the enhancements to the FESCo meeting summary he proposes but no one feels they have the time to implement them. == Log == {{{ (09:59:57) ***warren here. (10:00:04) thl has changed the topic to: FESCo meeting -- init (10:00:07) ***bpepple__ is here. (10:00:10) ***jima (rabble) here (10:00:13) sankarshan [n=sankarsh] entered the room. (10:00:17) thl: hi everyone! (10:00:22) jima: hi thl! (10:00:23) tibbs: Howdy. (10:00:31) thl: seems freenode has some problems today (10:00:37) jima: thl: quite. (10:00:45) thl: well, hopefully we can run our meeting nevertheless (10:00:53) thl: who's around? (10:00:54) jima: everyone put on your water wings! (10:01:24) warren: cool... looks like fedora directory server is close to being packagable (10:01:31) jima: oooOOOooo (10:01:33) c4chris: hey gang (10:01:36) warren: I'm trying to direct them to go through an Extras package review (10:01:47) rdieter: warren: +1 (: (10:01:48) ***thl counts warren, tibbs, c4chris , scop, bpepple (10:01:50) rdieter: here. (10:01:52) ***thl counts warren, tibbs, c4chris , scop, bpepple, rdieter (10:01:58) ***abadger1999 here (10:01:58) jima: warren: that seems like a good approach. (10:02:02) ***thl counts warren, tibbs, c4chris , scop, bpepple, rdieter, abadger1999 (10:02:03) ***spot is here, but "supposed" to be training (10:02:12) ***scop wakes up (10:02:22) thl: well, then let's start slowly (10:02:33) thl has changed the topic to: FESCo meeting -- Enterprise Extras (10:02:37) thl: ping mmcgrath, dgilmore (10:02:39) ***spot can multitask. :) (10:02:40) thl: any news? (10:02:52) ***cweyl is here, in his rabble seat (10:03:17) ***thl will move on for now and get back to EPEL later (10:03:28) thl has changed the topic to: FESCo meeting -- Enhance AWOL (10:03:59) thl: that's the diff afaics http://www.fedoraproject.org/wiki/Extras/Schedule/EnhanceAWOL?action=diff&rev2=7&rev1=4 (10:04:19) thl: bpepple, do we need to wait for further discussion on the list? (10:04:28) nman64 [n=n-man] entered the room. (10:04:29) bpepple__: I don't think so. (10:04:47) thl: well, we get further enhance it at any time if we want to (10:04:55) rdieter: worksforme. (10:05:02) thl: so everything fine with http://www.fedoraproject.org/wiki/Extras/Schedule/EnhanceAWOL?action=diff&rev2=7&rev1=4 ? (10:05:08) tibbs: Fine with me. (10:05:09) spot: looks good to me. (10:05:10) rdieter: fine: +1 (10:05:11) c4chris: yup (10:05:15) bpepple__: +1 (10:05:24) tibbs: The only issue that was brought up is whether we should try to track folks down. (10:05:26) bpepple left the room (quit: Connection timed out). (10:05:37) tibbs: I don't think that anyone should assume that we will, (10:05:43) tibbs: although it never hurts us to try. (10:05:47) bpepple__ is now known as bpepple (10:06:11) thl: well, do we want to add a quick note that "try to track folks down on other ways can't hurt"? (10:06:25) jima: maybe a SHOULD, but not a MUST? (10:06:33) abadger1999: track down as in find phone numbers, ask if anyone knows them personally, google the web, etc? (10:06:37) thl: jima, I'd consider that a "should" (10:06:42) tibbs: Not even a SHOULD. (10:06:47) tibbs: IMHO, of course. (10:06:48) thl: tibbs, agreed (10:06:56) thl: abadger1999, "google the web" (10:06:59) c4chris: NOTE +1 (10:07:13) tibbs: People should not assume that we will try to track them down. (10:07:15) dgilmore: thl: waiting on cvs branches (10:07:29) rdieter: COULD, MAYBE, SORTA-KINDA? (: (note++) (10:07:40) thl: dgilmore, are you around for some minutes? then well get back to it soon thl thomasvs (10:07:42) c4chris: tibbs, agreed (10:07:43) spot: IFBORED (10:07:53) dgilmore: thl: i should be (10:07:58) bpepple: Personally, I don't think it's really worth even adding to the page. (10:08:01) thl: I'd say we aceeppt the policy as it is (10:08:11) thl: and work out a small add on note during the week (10:08:16) thl: and add it next week (10:08:18) thl: okay? (10:08:19) tibbs: +1 (10:08:21) rdieter: ok (10:08:21) bpepple: thl: +1 (10:08:23) c4chris: +1 (10:08:24) spot: +1 (10:08:24) scop: ok (10:08:24) abadger1999: +1 (10:08:30) thl: bpepple, tibbs, can you work out that small note? (10:08:34) bpepple: Sure. (10:08:37) tibbs: OK. (10:08:38) thl: bpepple, can you move the new policy in place? (10:08:45) bpepple: Yup. (10:08:48) thl: k, thx (10:08:56) thl has changed the topic to: FESCo meeting -- Enterprise Extras (10:09:02) thl: dgilmore, what are we waiting for? (10:09:17) thl: dgilmore, I thought jeremy allowed the branches now (10:09:25) thl: so why can you or mmcgrath just create them? (10:09:26) dgilmore: thl: we are waiting on jeremy to do cvs branches so we can test builds (10:09:43) dgilmore: thl: we dont have the acl's to do that (10:10:13) warren: cvs branches on cvs.fedora? (10:10:16) warren: I can do it. (10:10:32) warren: branch what dist to what dist? (10:10:32) bpepple_ left the room (quit: Read error: 110 (Connection timed out)). (10:10:42) c4chris: warren, tag, you'te the wolf now :-) (10:10:47) thl: dgilmore, can you sort that out with jeremy and warren please? (10:10:53) warren: are these branches in /cvs/extras ? (10:10:54) thl: dgilmore, poke them once a day please (10:10:56) dgilmore: warren: we need a new dist of EL4 and EL5 (10:11:04) dgilmore: warren: yeah (10:11:05) thl: until we got the early steps done (10:11:13) dgilmore: thl: will do (10:11:14) ***thl is getting impatient (10:11:19) thl: dgilmore, thx (10:11:20) warren: FC-3 -> RHEL-4 FC-6 -> RHEL-5? (10:11:35) thl: warren, yes (10:11:36) dgilmore: warren: not really (10:11:41) thl: but only for package we request it for (10:11:48) dgilmore: warren: its not a wholesale branching (10:11:53) warren: give me a list then? (10:12:01) thl: warren, dgilmore will (10:12:05) warren: k (10:12:23) warren: but... dgilmore being one of the top infrastructure people should theoretically have access to this already... (10:12:26) thl: k, anything else regarding epel that needs to be discussed? (10:12:53) craigt left the room (quit: Remote closed the connection). (10:13:06) thl: dgilmore ? (10:13:13) dgilmore: warren: mmcgrath and I could do it as we have root on the box but did not want to as our users dont have the rights to do it (10:13:24) dgilmore: thl: i have nothing further to add (10:13:33) thl: k (10:13:56) thl has changed the topic to: FESCo meeting -- Packaging Committee Report (10:14:06) warren: dgilmore, we'll fix that problem too then. (10:14:08) thl: anythin we need to discuss from the report? (10:14:21) thl: I can#t see anything (10:14:26) c4chris: sounded all sane to me (10:14:32) ***thl will move on soon (10:14:38) tibbs: One point. (10:15:03) tibbs: Does FESCo want to decide on the acceptability of -static packages? (10:15:27) thl: well, someone should decide afaics (10:15:31) tibbs: Our idea was that when a package came up for review, the committee would consider it as they (we) do with kmods now. (10:15:46) dgilmore: tibbs: fesco or packaging committee should decide (10:15:54) tibbs: It's pretty rare to see packages where folks want static libs, but it does happen. (10:15:55) thl: tibbs, I think that's okay; but why can't the packaging committee handle that, too? (10:16:12) tibbs: Because it's really an extras issue, not a PC issue. (10:16:21) tibbs: Otherwise the PC could decide on kmods. (10:16:33) thl: point (10:16:38) thl: k, the FESCo decides (10:16:43) thl: okay for everybody? (10:16:51) c4chris: yup (10:16:51) thl: s/the/then/ (10:16:55) ***bpepple is fine with it. (10:17:04) dgilmore: sure (10:17:21) thl has changed the topic to: FESCo meeting -- Sponsorship nominations (10:17:24) tibbs: OK, we'll write that into the guideline. (10:17:25) warren: BTW, do we have any example compat-db packages? (10:17:43) thl has changed the topic to: FESCo meeting -- compat (10:17:55) thl: warren, I don't think so (10:18:11) thl: warren, but please bring that up to the PC (10:18:20) thl: warren, that okay? (10:18:23) warren: k (10:18:28) thl has changed the topic to: FESCo meeting -- Sponsorship nominations (10:18:39) thl: k, listed in the wiki are nominations for (10:18:42) thl: * (10:18:42) thl: Paul F. Johnson (pfj/nodoid) (10:18:42) thl: * (10:18:42) thl: Steven Pritchard (steve aka silug) (10:18:54) thl: but they didn't get forwareded to the list iirc (10:19:06) ***c4chris didn't see any discussion on the sponsors list (10:19:18) thl: I don't think we should discuss tnem here without a discussion on the sponsors list (10:19:25) bpepple: thl: Agreed. (10:19:27) rdieter: thl: +1 (10:19:29) c4chris: right (10:19:38) thl: does anyone want to propose them on the list? (10:19:45) thl: or better: (10:19:54) thl: can anybody please propose them on the list? (10:19:59) bpepple: I can. (10:20:03) thl: bpepple, thx (10:20:09) thl: any other nominations? (10:20:49) thl: tibbs, btw, last week you said something like "I'm not certain what our criterias for sponsors are" (10:20:52) thl: tibbs, I agree (10:20:57) thl: that needs to be documented (10:21:06) thl: but nobody did that yet (10:21:10) spot: must pay spot $500 US. (10:21:19) thl: and that a typical issue where someone just needs to start it (10:21:59) thl: red hat pays spot probably more the $500 (but not for work on Extras) (10:22:28) abadger1999: I take it you think "Must understand packaging for Fedora" is too vague? (10:22:45) thl: abadger1999, well, I prefer easy rules (10:22:46) tibbs: http://fedoraproject.org/wiki/Extras/Schedule/SponsorCriteria ? (10:22:50) dgilmore: spot: i think they should pay me that $500 (10:22:53) ***spot wishes rhat would pay me $500 per package. ;) (10:22:55) tibbs: Kind of slim at the moment, though... (10:22:57) thl: but we probably need a extended version, too (10:24:08) thl: well, maybe everynbody can add some thougs to http://fedoraproject.org/wiki/Extras/Schedule/SponsorCriteria until next week (10:24:22) tibbs: The only criteria I have ever looked at is the number of quality reviews done. (10:24:30) thl: abadger1999, please mention in the summarie that sponsors are invided to post some ideas on http://fedoraproject.org/wiki/Extras/Schedule/SponsorCriteria, too (10:24:43) thl: tibbs, summary (10:24:45) abadger1999: thl: k. (10:24:46) c4chris: one bullet point each :-) (10:24:47) thl: bah (10:24:50) thl: tibbs, sorry (10:25:02) thl: abadger1999, thx (10:25:03) tibbs: I don't know what the other criteria should be, so folks with different opinions should add them to that page. (10:25:25) thl: tibbs, having a "good feeling" is important, too IMHO (10:26:01) thl: k, anything else regarding sponsoring? (10:26:08) thl: no other nominations? (10:26:13) sankarshan left the room (quit: "/me goes off to take a break"). (10:26:24) tibbs: Should we discuss Ralf's comment on extras-list? (10:26:51) thl: tibbs, well, here and now: probably no (10:26:58) thl: tibbs, on the list: if you want to, sure (10:27:46) thl: discussing them here and now without preparation will take a lot of time (10:27:51) tibbs: Well, I surely don't want to. But it is a valid topic for discussion. (10:28:00) thl: tibbs, but if there is a special point from hist mail now: shoot (10:28:01) tibbs: I'm happy to do that elsewhere so we can move on. (10:28:04) warren: Sorry folks, I meant to write proposals to define alternative paths of membership advancement... (10:28:39) thl has changed the topic to: FESCo meeting -- MISC (10:28:50) thl: warren, np, as long as you don#t forget about it (10:29:03) thl: warren, I'll add it somewhere to the schedule to make sure it does not get forgotten (10:29:09) warren: I'm working on the fedora directory server guys currently... (10:29:14) warren: thl, thanks (10:29:17) warren: keep pressure on me on this. (10:29:18) thl: warren, but I'd be more interested in: what's the status of maintainer-announce-list ? (10:29:30) warren: I don't remember this at all (10:29:33) warren: what is this? (10:29:46) thl: ohhh boy... (10:29:49) warren: oh wait (10:29:53) thl: warren, let's talk after the meeting (10:29:55) ***thl waits (10:30:00) warren: we created it, but it was rejected for Core (10:30:05) warren: I remember now (10:30:12) warren: I have to figure out where I got stuck (10:30:22) thl: rejected? why that? (10:30:25) ***rdieter remembers too. jkeating squashed it. (: (10:30:41) thl: why? (10:30:45) warren: I don't exactly agree with jkeating on this (10:30:58) thl: well, maintainer-list doesn't work anymore (10:31:02) warren: jkeating thinks that core maintainers need to be paying better attention in general, and yet another list wont help. (10:31:04) thl: so we need something better (10:31:09) warren: I agree. (10:31:17) ***spot has a board with a rusty nail in it (10:31:18) warren: I think maintainer-announce-list is fine for Extras (10:31:37) warren: I'll move forward on this, thanks for the reminder. (10:31:47) thl: warren, k (10:31:59) abadger1999: If maintainer-announce is only for Extras, does it help? (10:32:08) rdieter: imo, not really. (10:32:13) thl: abadger1999, a bit (10:32:16) abadger1999: Because then we have to crosspost to maintainers and maintainers-announce (10:32:24) abadger1999: if we realy want to hit all maintainers. (10:32:30) dgilmore: there is way too much cross posting now (10:32:32) thl: abadger1999, but not all extras maintainers are on maintainers-list (10:32:32) spot: abadger1999: +1 thl thomasvs (10:32:41) thl: and I can understand that (10:32:42) spot: thl: thats the problem we need to fix. :) (10:32:50) rdieter: spot++ (10:32:55) thl: there is to much discussion these days (10:32:56) abadger1999: spot: +1 (10:33:20) thl: well, how to fix it? (10:33:24) rdieter: part of the problem is that there's too much discusion on maintainers that *should* be done elsewhere more appropriate. (10:33:28) tibbs: Someone should define what is on-topic for maintainers-list. (10:33:40) c4chris: maintainers is pretty low traffic IMHO (10:33:42) thl: tibbs, that won't help as long as it's unmoderated (10:34:11) thl: c4chris, still to much for some poeple afaics (10:34:12) ***spot can easily keep up with maintainers, fedora-list, not so much. :) (10:34:13) tibbs: I believe it would help. Some people actually do pay attention to things like that. (10:34:37) c4chris: thl, :-( (10:34:46) ***thl still would like a moderated annouce list (10:35:00) thl: were everyone get's subscribed by a script (10:35:04) rdieter: why not moderate maintainers-list then? (10:35:06) thl: directly from the accounts system (10:35:11) bpepple: thl: +1 (10:35:17) abadger1999: thl: I agree where everyone includes Core people. (10:35:31) warren: Would this be a good time to ask about allowing a static library for directory server? (10:35:33) jima: and split off a maintainers-discussion list or something? (10:35:40) thl: let talk to mr jkeating and get back to it next week (10:35:43) spot: warren: *thwap* (10:35:44) thl: that okay for now? thl thomasvs (10:36:00) c4chris: thl, yes (10:36:03) abadger1999: thl: +1 (10:36:13) bpepple: thl: +1 (10:36:22) spot: +1 (10:36:24) thl: k (10:36:35) thl has changed the topic to: FESCo meeting -- Merge Core and Extras (10:36:46) thl: warren, jeremy, f13 , any news from the core cabal? (10:37:07) warren: thl, we have a meeting scheduled Oct 12th-15th with max, notting and greg coming to Westford. (10:37:16) thl: Oct? (10:37:16) lutter [i=dlutter] entered the room. (10:37:25) warren: There are a number of political considerations we have to beat in order to move forward, we can't discuss this in public. (10:37:30) warren: Oops (10:37:32) warren: November (10:37:45) thl: warren, k, then let's get back to them after that (10:37:47) spot: /msg warren be careful! they'll figure out we have the Red Hat Time Machine working again (10:37:55) warren: Meanwhile I think testing f13's mercurial based repo is a good step forward. (10:37:55) thl: e.g. in two week (10:38:03) thl: s (10:38:06) warren: spot, no, that was on hammer3 along with the orbital laser control panel. (10:38:20) jima: well, oct 12-15 is dec 10-13 (10:38:37) warren: May I ask this group's feelings about this? (10:38:39) warren: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196393 (10:38:40) thl: dec? quite late.... (10:38:43) warren: I don't know how to proceed. (10:39:08) warren: Final Word on Core + Extras merge: please help f13 on the mercurial based repo + plague tests. (10:39:15) thl: warren, can you post stuff like http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196393 to the list before the meeting? (10:39:25) thl: such stuff slows down the meeting a lot :-/ (10:39:35) Belegdol left the room (quit: "Leaving"). (10:39:40) warren: right... ok (10:39:54) thl: warren, thx (10:40:26) thl: so, let's move on (10:40:38) thl has changed the topic to: FESCo meeting -- free discussion around extras (10:40:46) thl: Package Database ? (10:40:54) thl: ohh, wait (10:40:59) thl has changed the topic to: FESCo meeting -- comps.xml (10:41:00) ***spot will believe it when i see it (10:41:08) thl: that stucks (10:41:23) thl: dgilmore, did we push a new comps.xml for FC6? (10:41:38) thl: c4chris and the contributors had a lot of work getting it up to date (10:41:49) dgilmore: thl: no i havent had a chance to work out why make comps is not working (10:41:49) f13: spot: believe what? (10:41:53) thl: and it seems we failed to push it from CVS to the repo (10:42:12) c4chris: dgilmore, I think the Makefile is fixed now (10:42:13) thl: dgilmore, did you see mschwendts comment? (10:42:15) spot: f13: in fairies, santa claus, or the Fedora Package Database. (10:42:23) f13: spot: ah. (10:42:25) dgilmore: c4chris:ok (10:42:33) dgilmore: thl: i missed them (10:42:57) thl: dgilmore, I also asked mschwendt if he could look into integrating pushing of comps.xml into the push scripts (10:43:05) thl: he did not respond yet (10:43:10) c4chris: dgilmore, we can have a little chat later about comps if you wish (10:43:13) thl: dgilmore, please take a look (10:43:18) dgilmore: thl: ok (10:43:23) dgilmore: c4chris: lets do that (10:43:35) thl: dgilmore, otherwies support for installing Extrsa directly from anaconda is a bit useless (10:43:49) dgilmore: thl: yup i fully agree. (10:43:59) thl: dgilmore, thx (10:44:10) thl has changed the topic to: FESCo meeting -- free discussion around extras (10:44:18) thl: well, remaining things on the schedule: (10:44:22) thl: Package Database (10:44:30) thl: Comaintainership (10:44:38) thl: Maintainer Responsibility Policy (10:44:45) thl: Feature support in Extras (10:44:54) tibbs: Some new stuff in the responsibility policy page today. (10:44:56) warren: My static question? I need opinions. (10:45:02) warren: tibbs, URL? (10:45:04) abadger1999: I added to the Maintainer Responsibility Policy just before the meeting. (10:45:04) spot: warren: i say no. (10:45:20) tibbs: I think after a bit more stweing it should be ready to discuss. (10:45:20) spot: their reason for static libs is essentially "because we're lazy" (10:45:25) abadger1999: warren: Are we upstream? (10:45:27) bpepple: abadger1999: Yeah, I saw that. (10:45:37) bpepple: abadger1999: Isn (10:45:44) rdieter: spot: +1, can they at least make an attempt at non static libs? (10:45:53) warren: spot, I think so. (10:45:57) bpepple: abadger1999: Isn't that bit already decided in the EOL policy? (10:46:03) spot: not a valid reason, IMHO. (10:46:04) tibbs: warren: I like the last comment on that review ticket. (10:46:11) thl has changed the topic to: FESCo meeting -- Maintainer Responsibility Policy (10:46:42) thl: bpepple, it is in the EOL policy iirc (10:46:53) spot: warren: "we hope to have other apps use it in the future" should be a motivator to do it right (shared) (10:46:58) thl: bpepple, but it seem people didn't like the current scheme (10:47:27) abadger1999: What's in EOL where? (10:47:34) abadger1999: http://www.fedoraproject.org/wiki/Extras/PackageEndOfLife (10:47:38) bpepple: abadger1999: http://fedoraproject.org/wiki/Extras/Policy/EOL (10:47:45) warren: Could you please post your comments in that report? (10:47:52) abadger1999: bpepple: Let me check there :-) (10:48:47) thl: quiet quiet.... (10:48:58) thl: it it worth discussing here and now? (10:48:59) abadger1999: yeah -- 1) Not everyone agrees with it. (10:49:09) ***thl waits for abadger1999 (10:49:21) bpepple: Probably we should discuss it on the FESCO list. (10:49:32) abadger1999: 2) ISTR when it was drafted, the "security response team" portion was meant to catch when packagers didn't want to do this. (10:49:40) thl: bpepple, or directly on f-e-l (10:49:48) abadger1999: So it's more optional, rather than a "You must maintain for legacy releases" (10:49:51) bpepple: that's fine. (10:50:04) abadger1999: thl: +1 f-e-l (10:50:23) thl: abadger1999, someone just nees to start a discussion there (10:50:42) ***thl is to busy with other stuff (10:50:49) thl: I also somehow like the curret status (10:50:55) abadger1999: k. Last time I threw it out on f-e-l people wanted it in the wiki instead... (10:51:05) thl: Currently it's not that easy to get rid of packages for older dists (10:51:08) abadger1999: I'll throw it onto the list again, though. (10:51:26) thl: if it would be easy then a lot of packages would dump FC3 and FC4 now (10:51:42) thl: so in other words we wouldn't have anything for FC3 and FC4 (10:51:42) abadger1999: then maybe we should. (10:51:58) tibbs: I think the point is that they already have dumped those releases. (10:52:18) tibbs: Sometimes it takes a bit of coersion to get folks to push a fix to FC4 or FC3. (10:52:23) thl: tibbs, well, that's okay for me as long as there are no security problem (10:52:39) tibbs: scop has been doing some coersion lately. (10:52:58) tibbs: Actually it's mostly scop keeping up with Extras security issues these days. (10:53:20) thl: well, the alternative is to officially EOL FE3 and FE4 (10:53:48) thl: or give a small number of contributors free hand in FE3 and FE4 if they are intersted to maintain it (10:53:53) abadger1999: thl: Perhaps we should ask f-e-l for options that maintainers can vote on. (10:54:03) bpepple: abadger1999: +1 (10:54:10) thl: abadger1999, vote? (10:54:29) thl: but yeah, why not (10:55:05) abadger1999: We've expressed three options so far: 1) Maintain as long as Legacy, 2) maintain as long as Active Core w/ EOL for previous 3) maintain as long as active core with an Extras Legacy team (10:55:26) abadger1999: For 2 or 3 there have to be packagers who are willing to do the work. (10:55:40) thl: and that will be problematic (10:55:40) xris [n=xris] entered the room. (10:55:43) abadger1999: So it makes sense to let the packagers decide which they want to do. (10:55:50) thl: sure (10:56:00) thl: well, let's stop with this topic today (10:56:06) thl: and bring it to f-e-l (10:56:22) abadger1999: k (10:56:25) thl has changed the topic to: FESCo meeting -- free discussion around Extras (10:56:30) thl: what elaes is left? (10:56:32) thl: else (10:56:39) Rathann [n=rathann] entered the room. (10:57:03) c4chris: nothing much here (10:57:04) thl: the proposal from mschwendt for the style of the meeting summaries/the vote parts? (10:57:06) abadger1999: warren, spot: the only thing about the static question I see is that we already let packages in with static libs (10:57:21) abadger1999: If upstream doesn't build dynamic libs. (10:57:31) c4chris: thl, let's see what jwb comes up with (10:57:42) thl: c4chris, k (10:57:47) c4chris: for the voting: not sure (10:57:48) spot: abadger1999: given that this is upstream, i think it is not unreasonable for us to be harder on them (10:57:53) abadger1999: If we're upstream then it complicates matters a little bit as we have the power to make the change at the correct level. (10:58:05) spot: also, making shared libs for most items is not terribly difficult (10:58:13) ***spot has done it for several of his packages (10:58:51) thl: well, we're slowing down (10:58:55) spot: and... if upstream doesn't want to do shared libs, they presumably have a good reason (10:59:00) thl: seems we discussed all the important things for today (10:59:06) ***thl will close the meeting in 60 (10:59:06) c4chris: I'm not sure having +1 and -1 votes is really that much different from having +1 and 0 (10:59:10) dgilmore: spot: as its a Fedora/Red Hat product is all the more reason to push the issue and force shared libs c4chris c4chris|w (10:59:30) abadger1999: c4chris: I think he wants to just have summaries. (10:59:39) abadger1999: So you can tell what someone's "voting record" is. (10:59:44) thl: c4chris, I think abadger1999 is withgt with that (10:59:50) thl: abadger1999, I'm okay with that (10:59:51) spot: yeah, how else can we make negative campaign ads? (10:59:59) thl: abadger1999, but it should not make the meeting more complicated (11:00:02) c4chris: abadger1999, oh right, that part (11:00:03) abadger1999: I like mschwendt's ideas but don't have the time to really implement them :-( (11:00:14) thl: abadger1999, that's the problem with the idea (11:00:16) spot: "spot voted against static libs. is this a man you want deciding your children's edutainment?" (11:00:21) thl: someone has to do the work (11:00:29) jima: spot: oh god, not more of those (11:00:30) thl: and writing summaries is quite hard already (11:00:31) c4chris: thl, exactly (11:00:41) ***jima tried watching tv last night. what a mistake! (11:00:46) thl: abadger1999, thx for writing them normally (11:00:47) warren: abadger1999, I'm winning them over to make this into a dynamic lib, because they are upstream. (11:00:51) dgilmore: spot: you have paid way to much attention at the upcoming Illinois election (11:00:57) ***rdieter likes my tivo more and more everyday. (11:00:59) thl: abadger1999, many thanks acutally (11:01:07) bpepple: abadger1999: +1 (11:01:08) abadger1999: warren: Cool. (11:01:15) jima: rdieter: sadly, we were watching something live. an activity i hate more and more every day. (11:01:19) ***abadger1999 remembers the times before libtool and shudders. (11:01:28) ***jima applauds abadger1999 on his reports. :) (11:01:47) dgilmore: spot: "dgilmore voted against static libs. Whats he thinking?" (11:01:49) abadger1999: heh sorry I've been so late in getting them out lately (night before the next meeting) (11:01:50) ***thl will close the meeting in 60 (second try) (11:02:15) ***spot goes back to paying attention to his training course (11:02:24) ***thl will close the meeting in 30 (second (11:02:29) ***thl will close the meeting in 30 (11:02:56) ***thl will close the meeting in 10 (11:03:06) thl: -- MARK -- Meeting End }}} -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dtimms at iinet.net.au Thu Nov 2 21:13:02 2006 From: dtimms at iinet.net.au (David Timms) Date: Fri, 03 Nov 2006 08:13:02 +1100 Subject: extras package that simplifies installation of vmware packages ? In-Reply-To: <454A028D.30503@leemhuis.info> References: <4549FB05.10608@iinet.net.au> <454A028D.30503@leemhuis.info> Message-ID: <454A5F5E.7040201@iinet.net.au> Thorsten Leemhuis wrote: > Hi! > > David Timms schrieb: >> Hi I am thinking of creating a package called vmware-server-prerequisites. >> This could have requires of the rpms that need to be installed for >> vmware to be able to run. It could also include the any-any patch >> {although some people are saying it isn't need with k-2.6.18 / fc6}. >> Perhaps also a sub package called vmware-server-console-prerequisites, >> that has any packages that it might need. >> >> My understanding is that to be part of fedora-extras, I could not >> require the vmware package itself, ie I could only require packages in >> core or extras. > > Correct. > >> Without knowing any details about dkms I would imagine that some >> trickery could be performed so that a kernel update causes a vmware >> module recompile. > > No, the vmware modules are not acceptable for extras afaik as they might > have similar (not directly identical) problems as the nvidia or ati > drivers -- see the recent ndiswrapper discussion on lkml and/or > http://lwn.net/Articles/205644/. Thanks for this direct reference, I'll take a look. > And I don't know if the vmware license even allows to ship only the > kernel modules. I was thinking that the user would still use the normal route to get vmware's software, and hence be abiding by their software license. The basic problem with vmware's package {vmware-server-1.0.1...} is that it doesn't require other packages {and hence force them to be installed} that are needed before the kernel modules can be compiled on a particular distro such as our foss only fedora. I can see that after a new kernel and reboot, vmware detects that {I believe} it can no longer load it's kernel modules, and warns that the user needs to recompile them. I was thinking more of a way in which the {prerequisites} package could trigger the running of the supplied config script, if it finds it already installed. If the script isn't already installed, then it would do nothing. >> Any thoughts on possibilities and on incorporating such in extras ? > > I don't think it's possible or makes to much sense in Extras. Is that because it would give the end user the impression that the package is vmware itself ? Or because it isn't FOSS ? {and xen is coming along nicely} Or because it doesn't really do anything in itself ? {I vaguely remember someone mentioned that this sort of thing makes more sense to be done in groups files within a repo} > Maybe you have more luck in one of the 3rd party repos. Good point. Or my,our internal repo. > CU > thl Thanks for your input :) In reading between the lines, I guess it would make more sense to encourage vmware to insert the correct dependencies for compilation, or provide a -devel package that requires the bits needed to recompile their modules. Having not tried other rpm based distros for a long time, is there much common in the way redhat/fedora package compared to say suse etc ? DaveT. From eric.tanguy at univ-nantes.fr Thu Nov 2 21:29:02 2006 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Thu, 02 Nov 2006 22:29:02 +0100 Subject: camstream in extras Message-ID: <1162502942.3089.7.camel@bureau.maison> camstream is a dead extra package. I tried to contact the maintainer without any success so i tried to rebuild locally the fc5 package for fc6 but i have errors that i can't understand and mailing upstream have no answers at this time. So if someone could help me to solve this : g++ -g -c -o video_asm.o video_asm.S In file included from video_asm.S:4: video_def.h:2:27: error: linux/linkage.h: No such file or directory make[2]: *** [video_asm.o] Error 1 Thanks Eric From wart at kobold.org Thu Nov 2 21:31:47 2006 From: wart at kobold.org (Michael Thomas) Date: Thu, 02 Nov 2006 13:31:47 -0800 Subject: camstream in extras In-Reply-To: <1162502942.3089.7.camel@bureau.maison> References: <1162502942.3089.7.camel@bureau.maison> Message-ID: <454A63C3.2050704@kobold.org> Tanguy Eric wrote: > camstream is a dead extra package. I tried to contact the maintainer > without any success so i tried to rebuild locally the fc5 package for > fc6 but i have errors that i can't understand and mailing upstream have > no answers at this time. > So if someone could help me to solve this : > > g++ -g -c -o video_asm.o video_asm.S > In file included from video_asm.S:4: > video_def.h:2:27: error: linux/linkage.h: No such file or directory > make[2]: *** [video_asm.o] Error 1 linux/linkage.h is part of the kernel-devel package. Do you have BuildRequires: kernel-devel in the spec file? --Wart -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From giallu at gmail.com Thu Nov 2 21:33:37 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 2 Nov 2006 22:33:37 +0100 Subject: camstream in extras In-Reply-To: <1162502942.3089.7.camel@bureau.maison> References: <1162502942.3089.7.camel@bureau.maison> Message-ID: On 11/2/06, Tanguy Eric wrote: > camstream is a dead extra package. I tried to contact the maintainer > without any success so i tried to rebuild locally the fc5 package for > fc6 but i have errors that i can't understand and mailing upstream have > no answers at this time. > So if someone could help me to solve this : > > g++ -g -c -o video_asm.o video_asm.S > In file included from video_asm.S:4: > video_def.h:2:27: error: linux/linkage.h: No such file or directory > make[2]: *** [video_asm.o] Error 1 > What if you remove the line #include from video_def.h ? From michel.salim at gmail.com Thu Nov 2 21:33:00 2006 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 2 Nov 2006 16:33:00 -0500 Subject: gemi yum repository rebuilt for FC6 In-Reply-To: <1162325906.14333.2.camel@scriabin.tannenrauch.ch> References: <1162325906.14333.2.camel@scriabin.tannenrauch.ch> Message-ID: <883cfe6d0611021333t2846c49cl400ba6907d98af9a@mail.gmail.com> On 10/31/06, G?rard Milmeister wrote: > The packages in the gemi repository at > http://math.ifi.unizh.ch/fedora/ > have been rebuilt for FC6. > They are waiting for being picked up and submitted to FE. Some packages, > such as Squeak, would have to go to livna or dribble, however. I thought Squeak is now free enough to be included with OLPC? It should be fine for Extras. -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From paul at all-the-johnsons.co.uk Thu Nov 2 21:34:54 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 02 Nov 2006 21:34:54 +0000 Subject: ppc64 buildsys problem? Message-ID: <1162503294.5103.98.camel@T7.Linux> Hi, Just sent autogen-5.8.7-3 to build for FC-5 and the ppc64 buildsys has thrown a wobbler. Can someone check where the problem is with this? TTFN Paul 8--> gcc -std=gnu99 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -o .libs/autogen autogen-ag.o -Wl,--export-dynamic ../autoopts/.libs/libopts.so ../snprintfv/.libs/libsnprintfv.a /usr/lib/libguile.so -L/builddir/build/BUILD/guile-1.6.7/libguile/.libs /usr/lib/libguile-ltdl.so -lcrypt -lm -ldl gcc -std=gnu99 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -o .libs/columns cols.o ../autoopts/.libs/libopts.so /usr/lib/libguile.so -L/builddir/build/BUILD/guile-1.6.7/libguile/.libs /usr/lib/libguile-ltdl.so -lcrypt -lm -ldl creating columns /usr/lib/gcc/ppc64-redhat-linux/4.1.1/../../../../lib/crt1.o:(.rodata +0x4): undefined reference to `main' <--8 http://buildsys.fedoraproject.org/logs/fedora-5-extras/20784-autogen-5.8.7-3.fc5/ -- "Der einzige Weg, Leute zu kontrollieren ist sie anzul?gen" - L. Ron "Ich kann kein Science-Fiction schreiben" Hubbard; L?gner, Betr?ger, Fixer und Wohlt?ter zu niemandem -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From giallu at gmail.com Thu Nov 2 21:38:23 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 2 Nov 2006 22:38:23 +0100 Subject: failing kmod build for FC-6 In-Reply-To: <454A02E5.2020408@leemhuis.info> References: <454A02E5.2020408@leemhuis.info> Message-ID: On 11/2/06, Thorsten Leemhuis wrote: > Showing us the exact error message might help us to give a proper answer. Sorry for the rushed report, I was at work with little time to write it better. So, here is the steps I performed: 1. remove the old sandbox for sysprof-kmod (rm -rf sysprof-kmod) 2. download a new sandbox ( cvs co sysprof-kmod ) In devel subdir: 3. imported new sources ( make new-sources FILES="sysprof-1.0.5.tar.gz") 4. edited and committed .spec for the new release 5. make tag build this was OK (or at least, buildsys was happy with it...) now in FC-6 subdir: 6. imported new sources ( make new-sources FILES="sysprof-1.0.5.tar.gz") 7. edited and committed .spec for the new release 8. "make tag build" fails with: [giallu at hal9001 FC-6]$ make tag build cvs tag -c sysprof-kmod-1_0_5-1_2_6_18_1_2798_fc6 For more information on using the Fedora source code repositories, please visit http://fedoraproject.org/wiki/UsingCvs ERROR: The tag sysprof-kmod-1_0_5-1_2_6_18_1_2798_fc6 is already applied on a different branch ERROR: You can not forcibly move tags between branches sysprof-kmod-1_0_3-1_2_6_18_1_2689_fc6:devel:giallu:1159979253 sysprof-kmod-1_0_3-1_2_6_18_1_2726_fc6:devel:giallu:1159998972 sysprof-kmod-1_0_3-2_2_6_18_1_2726_fc6:devel:giallu:1159999645 sysprof-kmod-1_0_3-3_2_6_18_1_2726_fc6:devel:giallu:1160000514 sysprof-kmod-1_0_3-3_2_6_17_1_2187_FC5:FC-5:giallu:1160173663 sysprof-kmod-1_0_3-4_2_6_18_1_2747_fc6:devel:giallu:1160343329 sysprof-kmod-1_0_3-5_2_6_18_1_2747_fc6:devel:giallu:1160345322 sysprof-kmod-1_0_3-5_2_6_18_1_2747_fc6:devel:giallu:1160346293 sysprof-kmod-1_0_3-3_kernel_2_6_18_1_2200_fc5:FC-5:giallu:1161013509 sysprof-kmod-1_0_3-3_2_6_18_1_2200_fc5:FC-5:giallu:1161016035 sysprof-kmod-1_0_3-5_2_6_18_1_2798_fc6:devel:giallu:1161087192 sysprof-kmod-1_0_5-1_2_6_18_1_2798_fc6:devel:giallu:1162421622 cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first! make: *** [tag] Error 1 I hope this makes everything clearer. if not, feel free to ask me any other relevant info > > > What could have been done to prevent me > > from falling in this trap? > > Do you have a .rpmmacros and ~/rpmbuild on the machine where you tried > to tag? Is kmodtool available from where you tag? > Yes and yes. From gemi at bluewin.ch Thu Nov 2 21:39:02 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Thu, 02 Nov 2006 22:39:02 +0100 Subject: gemi yum repository rebuilt for FC6 In-Reply-To: <883cfe6d0611021333t2846c49cl400ba6907d98af9a@mail.gmail.com> References: <1162325906.14333.2.camel@scriabin.tannenrauch.ch> <883cfe6d0611021333t2846c49cl400ba6907d98af9a@mail.gmail.com> Message-ID: <1162503542.17149.6.camel@scriabin.tannenrauch.ch> On Thu, 2006-11-02 at 16:33 -0500, Michel Salim wrote: > On 10/31/06, G?rard Milmeister wrote: > > The packages in the gemi repository at > > http://math.ifi.unizh.ch/fedora/ > > have been rebuilt for FC6. > > They are waiting for being picked up and submitted to FE. Some packages, > > such as Squeak, would have to go to livna or dribble, however. > > I thought Squeak is now free enough to be included with OLPC? It > should be fine for Extras. Some time ago I asked on this list, and then the license was thought to be too restricted... -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From cfeist at redhat.com Thu Nov 2 21:46:59 2006 From: cfeist at redhat.com (Chris Feist) Date: Thu, 02 Nov 2006 15:46:59 -0600 Subject: Requesting sponsorship for gfs-utils & gfs-kmod for FC6 Extras Message-ID: <454A6753.8020306@redhat.com> Are any sponsors available to sponsor gfs-utils & gfs-kmod for FC6 Extras? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198816 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201077 Thanks! Chris From wolfy at nobugconsulting.ro Thu Nov 2 21:48:58 2006 From: wolfy at nobugconsulting.ro (lonely wolf) Date: Thu, 02 Nov 2006 23:48:58 +0200 Subject: camstream in extras In-Reply-To: <454A63C3.2050704@kobold.org> References: <1162502942.3089.7.camel@bureau.maison> <454A63C3.2050704@kobold.org> Message-ID: <454A67CA.8090000@nobugconsulting.ro> Michael Thomas wrote: > Tanguy Eric wrote: > >> camstream is a dead extra package. I tried to contact the maintainer >> without any success so i tried to rebuild locally the fc5 package for >> fc6 but i have errors that i can't understand and mailing upstream have >> no answers at this time. >> So if someone could help me to solve this : >> >> g++ -g -c -o video_asm.o video_asm.S >> In file included from video_asm.S:4: >> video_def.h:2:27: error: linux/linkage.h: No such file or directory >> make[2]: *** [video_asm.o] Error 1 >> > > linux/linkage.h is part of the kernel-devel package. Do you have > BuildRequires: kernel-devel in the spec file? > > --Wart > more precisely, in FC5 the file was provided by glibc-kernheaders, but in FC6 is part of kernel-devel. So you should modify the BuildRequires and ask for one package or the other depending on the value of %dist From j.w.r.degoede at hhs.nl Thu Nov 2 22:03:46 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 02 Nov 2006 23:03:46 +0100 Subject: please do not sign and push scorched3d update Message-ID: <454A6B42.3050407@hhs.nl> Hi, I've just build a new upstream version of scorched3d, and when checking the buildlog I saw that this new version now can play ogg files (for module addons which want to use these). Something which they maybe could have mentioned in the changelog? GRRR. However the current build doesn't support this as I didn't add the necessary BR's. Since scorched3d is rather huge (55 MB) a kind request not to sign and push todays scorched3d builds. I'll do a new version, with a new e-v-r tomorrow with this fixed. Thanks & Regards, Hans p.s. What would be the proper channel for requests like this? From jwboyer at jdub.homelinux.org Thu Nov 2 22:13:12 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 02 Nov 2006 16:13:12 -0600 Subject: FESCo Meeting Summary Nov 02 2006 In-Reply-To: <1162499731.2964.0.camel@localhost> References: <1162499731.2964.0.camel@localhost> Message-ID: <1162505592.11351.25.camel@zod.rchland.ibm.com> On Thu, 2006-11-02 at 12:35 -0800, Toshio Kuratomi wrote: > ==== Changes to the Meeting Summary ==== > * mschwendt has some ideas for improving post-meeting summaries: > * > https://www.redhat.com/archives/fedora-maintainers/2006-October/msg00336.html > * > https://www.redhat.com/archives/fedora-maintainers/2006-October/msg00376.html > * The main goal seems to be to make it easier to understand what each > FESCo member is trying to accomplish. > * This is important as FESCo is a representative elected body. > Knowing what FESCo members will vote for allows us to decide who we will > vote for in future FESCo elections. > * Concern was expressed that more formal voting might hinder getting > things done. > * Most people like the enhancements to the FESCo meeting summary he > proposes but no one feels they have the time to implement them. Slightly wrong. I said I would try to come up with something soon for this. Stay tuned... josh From fedora-extras-list.listman at linuxnetz.de Thu Nov 2 22:53:18 2006 From: fedora-extras-list.listman at linuxnetz.de (Robert Scheck) Date: Thu, 2 Nov 2006 23:53:18 +0100 Subject: Static library in librsync-devel Message-ID: <20061102225318.GA21093@hurricane.linuxnetz.de> Hello folks, does anybody of you require the static library shipped in librsync-devel package? If nobody requires /usr/lib/librsync.a, I would remove the file from the package as per Packaging Guidelines section "Exclusion of Static Libraries"; https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213780 Greetings, Robert From Christian.Iseli at licr.org Thu Nov 2 23:15:36 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 3 Nov 2006 00:15:36 +0100 Subject: comps comps-fe5.xml.in, 1.184, 1.185 comps-fe6.xml.in, 1.208, 1.209 comps-fe7.xml.in, 1.6, 1.7 In-Reply-To: <200611021848.kA2ImlBa022226@cvs-int.fedora.redhat.com> References: <200611021848.kA2ImlBa022226@cvs-int.fedora.redhat.com> Message-ID: <20061103001536.3a504a54@ludwig-alpha.unil.ch> Hi Jochen, On Thu, 2 Nov 2006 11:48:47 -0700, Jochen Schmitt (s4504kr) wrote: > Log Message: > Add crossvc in comps.xml > ... > > lightning > - lincvs Was the removal of lincvs intended ? C From michel.salim at gmail.com Fri Nov 3 02:21:39 2006 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 2 Nov 2006 21:21:39 -0500 Subject: gemi yum repository rebuilt for FC6 In-Reply-To: <1162503542.17149.6.camel@scriabin.tannenrauch.ch> References: <1162325906.14333.2.camel@scriabin.tannenrauch.ch> <883cfe6d0611021333t2846c49cl400ba6907d98af9a@mail.gmail.com> <1162503542.17149.6.camel@scriabin.tannenrauch.ch> Message-ID: <883cfe6d0611021821p24f31ab7s22acb11f433900f@mail.gmail.com> On 11/2/06, G?rard Milmeister wrote: > On Thu, 2006-11-02 at 16:33 -0500, Michel Salim wrote: > > On 10/31/06, G?rard Milmeister wrote: > > > The packages in the gemi repository at > > > http://math.ifi.unizh.ch/fedora/ > > > have been rebuilt for FC6. > > > They are waiting for being picked up and submitted to FE. Some packages, > > > such as Squeak, would have to go to livna or dribble, however. > > > > I thought Squeak is now free enough to be included with OLPC? It > > should be fine for Extras. > Some time ago I asked on this list, and then the license was thought to > be too restricted... Found the reference to the license change: http://weeklysqueak.wordpress.com/2006/10/19/squeak-foundation-board-meeting-notes-october-18th-2006/ It seems that the new license is not ready yet, but hopefully would not take too long (thinking of MySQL 4) -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From peter at thecodergeek.com Fri Nov 3 03:21:14 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 02 Nov 2006 19:21:14 -0800 Subject: comps comps-fe5.xml.in, 1.184, 1.185 comps-fe6.xml.in, 1.208, 1.209 comps-fe7.xml.in, 1.6, 1.7 In-Reply-To: <20061103001536.3a504a54@ludwig-alpha.unil.ch> References: <200611021848.kA2ImlBa022226@cvs-int.fedora.redhat.com> <20061103001536.3a504a54@ludwig-alpha.unil.ch> Message-ID: <1162524074.4635.17.camel@tuxhugger> On Fri, 2006-11-03 at 00:15 +0100, Christian Iseli wrote: > On Thu, 2 Nov 2006 11:48:47 -0700, Jochen Schmitt (s4504kr) wrote: > > Log Message: > > Add crossvc in comps.xml > > > ... > > > > lightning > > - lincvs > > Was the removal of lincvs intended ? I would say Yes. According to its dead.package entry, lincvs was moved to crossvc upstream, so this appears valid. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From eric.tanguy at univ-nantes.fr Fri Nov 3 07:10:47 2006 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Fri, 03 Nov 2006 08:10:47 +0100 Subject: camstream in extras In-Reply-To: <454A63C3.2050704@kobold.org> References: <1162502942.3089.7.camel@bureau.maison> <454A63C3.2050704@kobold.org> Message-ID: <1162537847.3043.2.camel@bureau.maison> Le jeudi 02 novembre 2006 ? 13:31 -0800, Michael Thomas a ?crit : > Tanguy Eric wrote: > > camstream is a dead extra package. I tried to contact the maintainer > > without any success so i tried to rebuild locally the fc5 package for > > fc6 but i have errors that i can't understand and mailing upstream have > > no answers at this time. > > So if someone could help me to solve this : > > > > g++ -g -c -o video_asm.o video_asm.S > > In file included from video_asm.S:4: > > video_def.h:2:27: error: linux/linkage.h: No such file or directory > > make[2]: *** [video_asm.o] Error 1 > > linux/linkage.h is part of the kernel-devel package. Do you have > BuildRequires: kernel-devel in the spec file? > > --Wart Buildrequires: kernel-devel is in spec file (i'm in fc6). and i find linkage.h in /usr/src/kernels/2.6.18-1.2798.fc6-i686/include/linux/linkage.h no more ideas ! Thanks Eric From eric.tanguy at univ-nantes.fr Fri Nov 3 07:12:01 2006 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Fri, 03 Nov 2006 08:12:01 +0100 Subject: camstream in extras In-Reply-To: References: <1162502942.3089.7.camel@bureau.maison> Message-ID: <1162537921.3043.4.camel@bureau.maison> Le jeudi 02 novembre 2006 ? 22:33 +0100, Gianluca Sforna a ?crit : > On 11/2/06, Tanguy Eric wrote: > > camstream is a dead extra package. I tried to contact the maintainer > > without any success so i tried to rebuild locally the fc5 package for > > fc6 but i have errors that i can't understand and mailing upstream have > > no answers at this time. > > So if someone could help me to solve this : > > > > g++ -g -c -o video_asm.o video_asm.S > > In file included from video_asm.S:4: > > video_def.h:2:27: error: linux/linkage.h: No such file or directory > > make[2]: *** [video_asm.o] Error 1 > > > > What if you remove the line > > #include > > from video_def.h ? > Not better : gcc -g -c -o video_asm.o video_asm.S video_asm.S: Assembler messages: video_asm.S:18: Error: invalid character '(' in mnemonic video_asm.S:46: Error: invalid character '(' in mnemonic video_asm.S:90: Error: invalid character '(' in mnemonic video_asm.S:117: Error: invalid character '(' in mnemonic make[2]: *** [video_asm.o] Erreur 1 From Christian.Iseli at licr.org Fri Nov 3 07:20:01 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 3 Nov 2006 08:20:01 +0100 Subject: comps comps-fe5.xml.in, 1.184, 1.185 comps-fe6.xml.in, 1.208, 1.209 comps-fe7.xml.in, 1.6, 1.7 In-Reply-To: <1162524074.4635.17.camel@tuxhugger> References: <200611021848.kA2ImlBa022226@cvs-int.fedora.redhat.com> <20061103001536.3a504a54@ludwig-alpha.unil.ch> <1162524074.4635.17.camel@tuxhugger> Message-ID: <20061103082001.38041c5a@ludwig-alpha.unil.ch> On Thu, 02 Nov 2006 19:21:14 -0800, Peter Gordon wrote: > On Fri, 2006-11-03 at 00:15 +0100, Christian Iseli wrote: > > On Thu, 2 Nov 2006 11:48:47 -0700, Jochen Schmitt (s4504kr) wrote: > > > Log Message: > > > Add crossvc in comps.xml > > > > > ... > > > > > > lightning > > > - lincvs > > > > Was the removal of lincvs intended ? > > I would say Yes. According to its dead.package entry, lincvs was moved > to crossvc upstream, so this appears valid. You're probably right. I was confused by the log message... :-) C From eric.tanguy at univ-nantes.fr Fri Nov 3 07:21:50 2006 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Fri, 03 Nov 2006 08:21:50 +0100 Subject: pb with livna's update ? In-Reply-To: <1162479475.3486.0.camel@bureau.maison> References: <1162479475.3486.0.camel@bureau.maison> Message-ID: <1162538510.3043.8.camel@bureau.maison> Le jeudi 02 novembre 2006 ? 15:57 +0100, Tanguy Eric a ?crit : > Today i have problems with livna updates : > Resolving Dependencies > --> Populating transaction set with selected packages. Please wait. > ---> Package ffmpeg.i386 0:0.4.9-0.25.20061030.lvn6 set to be updated > ---> Package xine.i386 0:0.99.4-8.lvn6 set to be updated > ---> Package lame.i386 0:3.97-3.lvn6 set to be updated > ---> Package lame-libs.i386 0:3.97-3.lvn6 set to be updated > ---> Package xine-lib-extras-nonfree.i386 0:1.1.2-3.lvn6 set to be > updated > ---> Downloading header for totem-xine to pack into transaction set. > totem-xine-2.16.2-2.lvn6. 100% |=========================| 36 kB > 00:00 > ---> Package totem-xine.i386 0:2.16.2-2.lvn6 set to be updated > --> Running transaction check > --> Processing Dependency: libxine.so.1 for package: > xine-lib-extras-nonfree > --> Processing Dependency: libxine.so.1 for package: totem-xine > --> Processing Dependency: libx264.so.54 for package: ffmpeg > --> Processing Dependency: xine-lib = 1.1.2 for package: > xine-lib-extras-nonfree > --> Processing Dependency: libxine.so.1 for package: xine > --> Finished Dependency Resolution > Error: Missing Dependency: libxine.so.1 is needed by package > xine-lib-extras-nonfree > Error: Missing Dependency: libxine.so.1 is needed by package totem-xine > Error: Missing Dependency: libx264.so.54 is needed by package ffmpeg > Error: Missing Dependency: xine-lib = 1.1.2 is needed by package > xine-lib-extras-nonfree > Error: Missing Dependency: libxine.so.1 is needed by package xine > > Someone could explain me how to solve this ? > > Thanks I managed to solve some dependency problems but i still have some : Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package ffmpeg.i386 0:0.4.9-0.25.20061030.lvn6 set to be updated ---> Package xine-lib-extras-nonfree.i386 0:1.1.2-3.lvn6 set to be updated --> Running transaction check --> Processing Dependency: libxine.so.1 for package: xine-lib-extras-nonfree --> Processing Dependency: libxine.so.1 for package: totem-xine --> Processing Dependency: libx264.so.54 for package: ffmpeg --> Processing Dependency: xine-lib = 1.1.2 for package: xine-lib-extras-nonfree --> Processing Dependency: libxine.so.1 for package: xine --> Finished Dependency Resolution Error: Missing Dependency: libxine.so.1 is needed by package xine-lib-extras-nonfree Error: Missing Dependency: libx264.so.54 is needed by package ffmpeg Error: Missing Dependency: xine-lib = 1.1.2 is needed by package xine-lib-extras-nonfree Someone could confirm this to know if this is a problem from my machine or a problem from livna repo. Thanks Eric From paul at all-the-johnsons.co.uk Fri Nov 3 09:07:27 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Fri, 03 Nov 2006 09:07:27 +0000 Subject: Another buildsys oddity? Message-ID: <1162544847.5103.120.camel@T7.Linux> Hi, I've submitted gDeskCal to the buildsys and while it works fine under mock on my test rig, it's failing on the RH build sys. The logs are here http://buildsys.fedoraproject.org/logs/fedora-development-extras/20794-gdeskcal-1.0-8.fc7/ Can anyone spot the problem? I could really do with getting this package submitted. The failure also occurs on FC6 and FC5 (though that one has an additional oddity which is possibly not related to the buildsys). TTFN Paul -- "Der einzige Weg, Leute zu kontrollieren ist sie anzul?gen" - L. Ron "Ich kann kein Science-Fiction schreiben" Hubbard; L?gner, Betr?ger, Fixer und Wohlt?ter zu niemandem -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From gemi at bluewin.ch Fri Nov 3 09:14:00 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Fri, 03 Nov 2006 10:14:00 +0100 Subject: Another buildsys oddity? In-Reply-To: <1162544847.5103.120.camel@T7.Linux> References: <1162544847.5103.120.camel@T7.Linux> Message-ID: <1162545240.3859.0.camel@scriabin.tannenrauch.ch> On Fri, 2006-11-03 at 09:07 +0000, Paul wrote: > Hi, > > I've submitted gDeskCal to the buildsys and while it works fine under > mock on my test rig, it's failing on the RH build sys. > > The logs are here > > http://buildsys.fedoraproject.org/logs/fedora-development-extras/20794-gdeskcal-1.0-8.fc7/ > > Can anyone spot the problem? I could really do with getting this package > submitted. You probably need to BR: gettext -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From mtasaka at ioa.s.u-tokyo.ac.jp Fri Nov 3 09:16:13 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 03 Nov 2006 18:16:13 +0900 Subject: Another buildsys oddity? In-Reply-To: <1162544847.5103.120.camel@T7.Linux> References: <1162544847.5103.120.camel@T7.Linux> Message-ID: <454B08DD.2080903@ioa.s.u-tokyo.ac.jp> Paul wrote: > Hi, > > I've submitted gDeskCal to the buildsys and while it works fine under > mock on my test rig, it's failing on the RH build sys. > > The logs are here > > http://buildsys.fedoraproject.org/logs/fedora-development-extras/20794-gdeskcal-1.0-8.fc7/ > Perhaps you should add "gettext" to BuildRequires. Mamoru From paul at city-fan.org Fri Nov 3 09:30:09 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 03 Nov 2006 09:30:09 +0000 Subject: failing kmod build for FC-6 In-Reply-To: References: <454A02E5.2020408@leemhuis.info> Message-ID: <454B0C21.3070602@city-fan.org> Gianluca Sforna wrote: > On 11/2/06, Thorsten Leemhuis wrote: >> Showing us the exact error message might help us to give a proper answer. > > > Sorry for the rushed report, I was at work with little time to write it > better. > So, here is the steps I performed: > > 1. remove the old sandbox for sysprof-kmod (rm -rf sysprof-kmod) > 2. download a new sandbox ( cvs co sysprof-kmod ) > In devel subdir: > 3. imported new sources ( make new-sources FILES="sysprof-1.0.5.tar.gz") > 4. edited and committed .spec for the new release > 5. make tag build > > this was OK (or at least, buildsys was happy with it...) > > now in FC-6 subdir: > 6. imported new sources ( make new-sources FILES="sysprof-1.0.5.tar.gz") > 7. edited and committed .spec for the new release > 8. "make tag build" fails with: > > [giallu at hal9001 FC-6]$ make tag build > cvs tag -c sysprof-kmod-1_0_5-1_2_6_18_1_2798_fc6 > For more information on using the Fedora source code repositories, > please visit http://fedoraproject.org/wiki/UsingCvs > ERROR: The tag sysprof-kmod-1_0_5-1_2_6_18_1_2798_fc6 is already > applied on a different branch > ERROR: You can not forcibly move tags between branches > sysprof-kmod-1_0_3-1_2_6_18_1_2689_fc6:devel:giallu:1159979253 > sysprof-kmod-1_0_3-1_2_6_18_1_2726_fc6:devel:giallu:1159998972 > sysprof-kmod-1_0_3-2_2_6_18_1_2726_fc6:devel:giallu:1159999645 > sysprof-kmod-1_0_3-3_2_6_18_1_2726_fc6:devel:giallu:1160000514 > sysprof-kmod-1_0_3-3_2_6_17_1_2187_FC5:FC-5:giallu:1160173663 > sysprof-kmod-1_0_3-4_2_6_18_1_2747_fc6:devel:giallu:1160343329 > sysprof-kmod-1_0_3-5_2_6_18_1_2747_fc6:devel:giallu:1160345322 > sysprof-kmod-1_0_3-5_2_6_18_1_2747_fc6:devel:giallu:1160346293 > sysprof-kmod-1_0_3-3_kernel_2_6_18_1_2200_fc5:FC-5:giallu:1161013509 > sysprof-kmod-1_0_3-3_2_6_18_1_2200_fc5:FC-5:giallu:1161016035 > sysprof-kmod-1_0_3-5_2_6_18_1_2798_fc6:devel:giallu:1161087192 > sysprof-kmod-1_0_5-1_2_6_18_1_2798_fc6:devel:giallu:1162421622 > cvs tag: Pre-tag check failed > cvs [tag aborted]: correct the above errors first! > make: *** [tag] Error 1 > > > I hope this makes everything clearer. if not, feel free to ask me any > other relevant info I think you need to update the "common" module as well as the "sysprof-kmod" one; your devel branch should have nad a "fc7" tag, not a "fc6" one. Once you've done that, bump the release number in your spec for both FC-6 and devel, commit them, and try tagging again. Paul. From buildsys at fedoraproject.org Fri Nov 3 10:10:56 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 3 Nov 2006 05:10:56 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-03 Message-ID: <20061103101056.6F7A415213B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 39 CGAL-3.2.1-19.fc7 amsn-0.96-1.fc7 asymptote-1.17-1.fc7 autogen-5.8.7-3.fc7 awstats-6.6-0.4.beta.fc7 cacti-0.8.6i-3.fc7 csound-5.03.0-8.fc7 ctorrent-1.3.4-3.dnh2.1.fc7 e2tools-0.0.16-5.fc7 fluxstyle-1.0.1-1.fc7 freefont-20060126-3.fc7 gambas-1.0.17-6.fc7 gg2-2.3.0-1.fc7 ghc-6.6-1.fc7 guiloader-c++-2.8.1-1.fc7 haddock-0.8-1.fc7 jd-1.8.0-0.4.cvs061102.fc7 kadu-0.5.0-0.18.20060915svn.fc7 kdegraphics-extras-3.5.5-1.fc7 kdemultimedia-extras-3.5.5-0.3.fc7 kdesvn-0.11.0-1.fc7 kdetoys-3.5.5-1.fc7 libibverbs-1.0.4-1.fc7 magicor-1.0-0.1.rc1.fc7 mantis-1.0.6-1.fc7 ntfs-3g-0-0.5.20070920.fc7 pcsc-perl-1.4.4-2.fc7 perl-File-Remove-0.33-1.fc7 perl-Params-Util-0.22-1.fc7 perl-Test-LongString-0.10-1.fc7 perl-Tree-Simple-1.17-1.fc7 pgp-tools-0.4.9-1.fc7 plplot-5.6.1-8.fc7 rxvt-unicode-8.0-1.fc7 scorched3d-40.1c-2.fc7 scribes-0.2.9.91-1.fc7 sysprof-1.0.5-1.fc7 sysprof-kmod-1.0.5-1.2.6.18_1.2798.fc6 tetex-tex4ht-1.0.2006_10_28_1705-1.fc7 Packages built and released for Fedora Extras 6: 30 CGAL-3.2.1-19.fc6 amsn-0.96-1.fc6 asymptote-1.17-1.fc6 autogen-5.8.7-3.fc6 awstats-6.6-0.4.beta.fc6 cacti-0.8.6i-3.fc6 csound-5.03.0-8.fc6 ctorrent-1.3.4-3.dnh2.1.fc6 freefont-20060126-3.fc6 gg2-2.3.0-1.fc6 kdegraphics-extras-3.5.5-1.fc6 kdemultimedia-extras-3.5.5-0.3.fc6 kdesvn-0.11.0-1.fc6 kdetoys-3.5.5-1.fc6 libibverbs-1.0.4-1.fc6 magicor-1.0-0.1.rc1.fc6 mantis-1.0.6-1.fc6 mediawiki-1.8.2-5.fc6 ntfs-3g-0-0.5.20070920.fc6 perl-File-Remove-0.33-1.fc6 perl-Params-Util-0.22-1.fc6 perl-Test-LongString-0.10-1.fc6 perl-Tree-Simple-1.17-1.fc6 pgp-tools-0.4.9-1.fc6 php-pear-Date-Holidays-0.16.1-1.fc6 plplot-5.6.1-8.fc6 python-zope-interface-3.0.1-6.fc6 rxvt-unicode-8.0-1.fc6 scribes-0.2.9.91-1.fc6 sysprof-1.0.5-1.fc6 Packages built and released for Fedora Extras 5: 27 CGAL-3.2.1-19.fc5 Invalid rebuild: gtksourceview-sharp-2.0-24.fc5 amsn-0.96-1.fc5 anjuta-gdl-0.6.1-5.fc5 asymptote-1.17-1.fc5 awstats-6.5-7.fc5 cacti-0.8.6i-3.fc5 ctorrent-1.3.4-2.dnh2.1.fc5 freefont-20060126-3.fc5 gg2-2.3.0-1.fc5 kdemultimedia-extras-3.5.5-0.3.fc5 kdesvn-0.11.0-1.fc5 kdetoys-3.5.5-1.fc5 libFoundation-1.1.3-10.fc5 libibverbs-1.0.4-1.fc5 magicor-1.0-0.1.rc1.fc5 mantis-1.0.6-1.fc5 ntfs-3g-0-0.5.20070920.fc5 perl-File-Remove-0.33-1.fc5 perl-Params-Util-0.22-1.fc5 perl-Test-LongString-0.10-1.fc5 perl-Tree-Simple-1.17-1.fc5 pgp-tools-0.4.9-1.fc5 php-pear-Date-Holidays-0.16.1-1.fc5 plplot-5.6.1-6.fc5 python-zope-interface-3.0.1-6.fc5 rxvt-unicode-8.0-1.fc5 Packages built and released for Fedora Extras 4: 9 asymptote-1.17-1.fc4 cacti-0.8.6i-2.fc4 ctorrent-1.3.4-1.dnh2.1.fc4 libibverbs-1.0.4-1.fc4 perl-File-Remove-0.33-1.fc4 perl-Params-Util-0.22-1.fc4 perl-Test-LongString-0.10-1.fc4 pgp-tools-0.4.9-1.fc4 rxvt-unicode-8.0-1.fc4 Packages built and released for Fedora Extras 3: 2 cacti-0.8.6i-2.fc3 rxvt-unicode-8.0-1.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri Nov 3 11:14:44 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 03 Nov 2006 11:14:44 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-03 Message-ID: <20061103111444.24386.79495@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 (3 days) centericq - 4.21.0-8.fc6.ppc (3 days) centericq - 4.21.0-8.fc6.x86_64 (3 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (6 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (6 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (6 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (6 days) orange - 0.3-3.cvs20051118.fc6.i386 (10 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (34 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (34 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (34 days) sylpheed-claws-plugins-gtkhtml2-viewer - 2.5.2-4.fc6.i386 (3 days) sylpheed-claws-plugins-gtkhtml2-viewer - 2.5.2-4.fc6.ppc (3 days) sylpheed-claws-plugins-gtkhtml2-viewer - 2.5.2-4.fc6.x86_64 (3 days) sylpheed-claws-plugins-rssyl - 2.5.2-4.fc6.i386 (3 days) sylpheed-claws-plugins-rssyl - 2.5.2-4.fc6.ppc (3 days) sylpheed-claws-plugins-rssyl - 2.5.2-4.fc6.x86_64 (3 days) sylpheed-claws-plugins-vcalendar - 2.5.2-4.fc6.i386 (3 days) sylpheed-claws-plugins-vcalendar - 2.5.2-4.fc6.ppc (3 days) sylpheed-claws-plugins-vcalendar - 2.5.2-4.fc6.x86_64 (3 days) andreas AT bawue.net icecast - 2.3.1-3.fc6.i386 (3 days) icecast - 2.3.1-3.fc6.ppc (3 days) icecast - 2.3.1-3.fc6.x86_64 (3 days) xmms-scrobbler - 0.3.8.1-2.fc6.i386 (3 days) xmms-scrobbler - 0.3.8.1-2.fc6.ppc (3 days) xmms-scrobbler - 0.3.8.1-2.fc6.x86_64 (3 days) chabotc AT xs4all.nl rtorrent - 0.6.2-4.fc6.i386 (3 days) rtorrent - 0.6.2-4.fc6.ppc (3 days) rtorrent - 0.6.2-4.fc6.x86_64 (3 days) chrisw AT redhat.com git-core - 1.4.2.4-1.fc6.i386 (3 days) git-core - 1.4.2.4-1.fc6.ppc (3 days) git-core - 1.4.2.4-1.fc6.x86_64 (3 days) dakingun AT gmail.com gnomesword - 2.1.6-5.fc6.i386 (3 days) gnomesword - 2.1.6-5.fc6.ppc (3 days) gnomesword - 2.1.6-5.fc6.x86_64 (3 days) sword - 1.5.8-10.fc6.i386 (3 days) sword - 1.5.8-10.fc6.i386 (3 days) sword - 1.5.8-10.fc6.ppc (3 days) sword - 1.5.8-10.fc6.x86_64 (3 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (49 days) plague - 0.4.4.1-2.fc3.noarch (49 days) plague - 0.4.4.1-2.fc4.noarch (49 days) plague - 0.4.4.1-2.fc4.noarch (49 days) plague - 0.4.4.1-2.fc4.noarch (49 days) endur AT bennewitz.com streamtuner - 0.99.99-13.fc6.i386 (3 days) streamtuner - 0.99.99-13.fc6.i386 (3 days) streamtuner - 0.99.99-13.fc6.ppc (3 days) streamtuner - 0.99.99-13.fc6.x86_64 (3 days) enrico.scholz AT informatik.tu-chemnitz.de xmlrpc-c - 1.06.05-2.fc6.i386 (3 days) xmlrpc-c - 1.06.05-2.fc6.i386 (3 days) xmlrpc-c - 1.06.05-2.fc6.ppc (3 days) xmlrpc-c - 1.06.05-2.fc6.x86_64 (3 days) xmlrpc-c-apps - 1.06.05-2.fc6.i386 (3 days) xmlrpc-c-apps - 1.06.05-2.fc6.ppc (3 days) xmlrpc-c-apps - 1.06.05-2.fc6.x86_64 (3 days) giallu AT gmail.com sysprof - 1.0.5-1.fc6.i386 sysprof - 1.0.5-1.fc6.x86_64 green AT redhat.com raptor - 1.4.9-5.fc6.i386 (3 days) raptor - 1.4.9-5.fc6.i386 (3 days) raptor - 1.4.9-5.fc6.ppc (3 days) raptor - 1.4.9-5.fc6.x86_64 (3 days) hamzy AT us.ibm.com sblim-wbemcli - 1.5.1-4.fc6.i386 (3 days) sblim-wbemcli - 1.5.1-4.fc6.ppc (3 days) sblim-wbemcli - 1.5.1-4.fc6.x86_64 (3 days) hugo AT devin.com.br xmoto - 0.2.0-1.fc6.i386 (3 days) xmoto - 0.2.0-1.fc6.ppc (3 days) xmoto - 0.2.0-1.fc6.x86_64 (3 days) imlinux AT gmail.com nagios-plugins-ide_smart - 1.4.3-20.fc4.i386 (9 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.ppc (9 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.x86_64 (9 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (25 days) linphone - 1.2.0-4.fc5.ppc (25 days) linphone - 1.2.0-4.fc5.x86_64 (25 days) linphone - 1.2.0-7.fc6.i386 (10 days) linphone - 1.2.0-7.fc6.ppc (10 days) linphone - 1.2.0-7.fc6.x86_64 (10 days) lmacken AT redhat.com deskbar-applet - 2.16.0-1.fc6.i386 (6 days) deskbar-applet - 2.16.0-1.fc6.ppc (6 days) deskbar-applet - 2.16.0-1.fc6.x86_64 (6 days) nphilipp AT redhat.com bzflag - 2.0.8-3.fc6.i386 (3 days) bzflag - 2.0.8-3.fc6.ppc (3 days) bzflag - 2.0.8-3.fc6.x86_64 (3 days) oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (15 days) syck-php - 0.55-9.fc5.ppc (15 days) syck-php - 0.55-9.fc5.x86_64 (15 days) petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 ghc-gtk2hs - 0.9.10-4.fc6.ppc ghc-gtk2hs - 0.9.10-4.fc6.x86_64 ghc642-gtk2hs - 0.9.10-4.fc6.i386 ghc642-gtk2hs - 0.9.10-4.fc6.ppc ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 qspencer AT ieee.org octave-forge - 2006.07.09-7.fc6.i386 (3 days) octave-forge - 2006.07.09-7.fc6.ppc (3 days) octave-forge - 2006.07.09-7.fc6.x86_64 (3 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (5 days) redhat-bugzilla AT camperquake.de audacious - 1.1.2-2.fc6.i386 (3 days) audacious - 1.1.2-2.fc6.i386 (3 days) audacious - 1.1.2-2.fc6.ppc (3 days) audacious - 1.1.2-2.fc6.x86_64 (3 days) stickster AT gmail.com drivel - 2.1.0-0.3.20060527cvs.fc6.i386 (3 days) drivel - 2.1.0-0.3.20060527cvs.fc6.ppc (3 days) drivel - 2.1.0-0.3.20060527cvs.fc6.x86_64 (3 days) tcallawa AT redhat.com evolution-bogofilter - 0.2.0-3.fc6.i386 (6 days) evolution-bogofilter - 0.2.0-3.fc6.ppc (6 days) evolution-bogofilter - 0.2.0-3.fc6.x86_64 (6 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- audacious-1.1.2-2.fc6.ppc requires libcurl.so.3 bzflag-2.0.8-3.fc6.ppc requires libcurl.so.3 centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 deskbar-applet-2.16.0-1.fc6.ppc requires libedataserver-1.2.so.7 drivel-2.1.0-0.3.20060527cvs.fc6.ppc requires libcurl.so.3 evolution-bogofilter-0.2.0-3.fc6.ppc requires libedataserver-1.2.so.7 ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 git-core-1.4.2.4-1.fc6.ppc requires libcurl.so.3 gnomesword-2.1.6-5.fc6.ppc requires libcurl.so.3 icecast-2.3.1-3.fc6.ppc requires libcurl.so.3 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 octave-forge-2006.07.09-7.fc6.ppc requires libcurl.so.3 raptor-1.4.9-5.fc6.ppc requires libcurl.so.3 rtorrent-0.6.2-4.fc6.ppc requires libcurl.so.3 sblim-wbemcli-1.5.1-4.fc6.ppc requires libcurl.so.3 streamtuner-0.99.99-13.fc6.ppc requires libcurl.so.3 sword-1.5.8-10.fc6.ppc requires libcurl.so.3 sylpheed-claws-plugins-gtkhtml2-viewer-2.5.2-4.fc6.ppc requires libcurl.so.3 sylpheed-claws-plugins-rssyl-2.5.2-4.fc6.ppc requires libcurl.so.3 sylpheed-claws-plugins-vcalendar-2.5.2-4.fc6.ppc requires libcurl.so.3 xmlrpc-c-1.06.05-2.fc6.ppc requires libcurl.so.3 xmlrpc-c-apps-1.06.05-2.fc6.ppc requires libcurl.so.3 xmms-scrobbler-0.3.8.1-2.fc6.ppc requires libcurl.so.3 xmoto-0.2.0-1.fc6.ppc requires libcurl.so.3 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- audacious-1.1.2-2.fc6.i386 requires libcurl.so.3 audacious-1.1.2-2.fc6.x86_64 requires libcurl.so.3()(64bit) bzflag-2.0.8-3.fc6.x86_64 requires libcurl.so.3()(64bit) centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) deskbar-applet-2.16.0-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) drivel-2.1.0-0.3.20060527cvs.fc6.x86_64 requires libcurl.so.3()(64bit) evolution-bogofilter-0.2.0-3.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 git-core-1.4.2.4-1.fc6.x86_64 requires libcurl.so.3()(64bit) gnomesword-2.1.6-5.fc6.x86_64 requires libcurl.so.3()(64bit) icecast-2.3.1-3.fc6.x86_64 requires libcurl.so.3()(64bit) libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) octave-forge-2006.07.09-7.fc6.x86_64 requires libcurl.so.3()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 raptor-1.4.9-5.fc6.i386 requires libcurl.so.3 raptor-1.4.9-5.fc6.x86_64 requires libcurl.so.3()(64bit) rtorrent-0.6.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) sblim-wbemcli-1.5.1-4.fc6.x86_64 requires libcurl.so.3()(64bit) streamtuner-0.99.99-13.fc6.i386 requires libcurl.so.3 streamtuner-0.99.99-13.fc6.x86_64 requires libcurl.so.3()(64bit) sword-1.5.8-10.fc6.i386 requires libcurl.so.3 sword-1.5.8-10.fc6.x86_64 requires libcurl.so.3()(64bit) sylpheed-claws-plugins-gtkhtml2-viewer-2.5.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) sylpheed-claws-plugins-rssyl-2.5.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) sylpheed-claws-plugins-vcalendar-2.5.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) xmlrpc-c-1.06.05-2.fc6.i386 requires libcurl.so.3 xmlrpc-c-1.06.05-2.fc6.x86_64 requires libcurl.so.3()(64bit) xmlrpc-c-apps-1.06.05-2.fc6.x86_64 requires libcurl.so.3()(64bit) xmms-scrobbler-0.3.8.1-2.fc6.x86_64 requires libcurl.so.3()(64bit) xmoto-0.2.0-1.fc6.x86_64 requires libcurl.so.3()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- audacious-1.1.2-2.fc6.i386 requires libcurl.so.3 bzflag-2.0.8-3.fc6.i386 requires libcurl.so.3 centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 deskbar-applet-2.16.0-1.fc6.i386 requires libedataserver-1.2.so.7 drivel-2.1.0-0.3.20060527cvs.fc6.i386 requires libcurl.so.3 evolution-bogofilter-0.2.0-3.fc6.i386 requires libedataserver-1.2.so.7 ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 git-core-1.4.2.4-1.fc6.i386 requires libcurl.so.3 gnomesword-2.1.6-5.fc6.i386 requires libcurl.so.3 icecast-2.3.1-3.fc6.i386 requires libcurl.so.3 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 octave-forge-2006.07.09-7.fc6.i386 requires libcurl.so.3 raptor-1.4.9-5.fc6.i386 requires libcurl.so.3 rtorrent-0.6.2-4.fc6.i386 requires libcurl.so.3 sblim-wbemcli-1.5.1-4.fc6.i386 requires libcurl.so.3 streamtuner-0.99.99-13.fc6.i386 requires libcurl.so.3 sword-1.5.8-10.fc6.i386 requires libcurl.so.3 sylpheed-claws-plugins-gtkhtml2-viewer-2.5.2-4.fc6.i386 requires libcurl.so.3 sylpheed-claws-plugins-rssyl-2.5.2-4.fc6.i386 requires libcurl.so.3 sylpheed-claws-plugins-vcalendar-2.5.2-4.fc6.i386 requires libcurl.so.3 xmlrpc-c-1.06.05-2.fc6.i386 requires libcurl.so.3 xmlrpc-c-apps-1.06.05-2.fc6.i386 requires libcurl.so.3 xmms-scrobbler-0.3.8.1-2.fc6.i386 requires libcurl.so.3 xmoto-0.2.0-1.fc6.i386 requires libcurl.so.3 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) sysprof-1.0.5-1.fc6.x86_64 requires kmod-sysprof >= 0:1.0.5 Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.i386 requires libortp.so.2 sysprof-1.0.5-1.fc6.i386 requires kmod-sysprof >= 0:1.0.5 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.ppc requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.x86_64 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.i386 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: giallu AT gmail.com package: sysprof - 1.0.5-1.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: kmod-sysprof >= 0:1.0.5 package: sysprof - 1.0.5-1.fc6.i386 from fedora-extras-6-i386 unresolved deps: kmod-sysprof >= 0:1.0.5 ====================================================================== New report for: oliver AT linux-kernel.at package: syck-php - 0.55-9.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.4 package: syck-php - 0.55-9.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.4 package: syck-php - 0.55-9.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.4 ====================================================================== New report for: petersen AT redhat.com package: ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: /usr/bin/ghc-pkg-6.4.2 ghc642 package: ghc642-gtk2hs - 0.9.10-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: /usr/bin/ghc-pkg-6.4.2 ghc642 package: ghc-gtk2hs - 0.9.10-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: ghc = 0:6.4.2 package: ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: /usr/bin/ghc-pkg-6.4.2 ghc642 package: ghc-gtk2hs - 0.9.10-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: ghc = 0:6.4.2 package: ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: /usr/bin/ghc-pkg-6.4.2 ghc642 package: ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: /usr/bin/ghc-pkg-6.4.2 ghc642 package: ghc-gtk2hs - 0.9.10-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: ghc = 0:6.4.2 package: ghc642-gtk2hs - 0.9.10-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: /usr/bin/ghc-pkg-6.4.2 ghc642 From fedora at leemhuis.info Fri Nov 3 11:19:55 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 03 Nov 2006 12:19:55 +0100 Subject: extras package that simplifies installation of vmware packages ? In-Reply-To: <454A5F5E.7040201@iinet.net.au> References: <4549FB05.10608@iinet.net.au> <454A028D.30503@leemhuis.info> <454A5F5E.7040201@iinet.net.au> Message-ID: <454B25DB.9010909@leemhuis.info> David Timms schrieb: > Thorsten Leemhuis wrote: >> David Timms schrieb: >> And I don't know if the vmware license even allows to ship only the >> kernel modules. > I was thinking that the user would still use the normal route to get > vmware's software, and hence be abiding by their software license. The > basic problem with vmware's package {vmware-server-1.0.1...} is that it > doesn't require other packages {and hence force them to be installed} > that are needed before the kernel modules can be compiled on a > particular distro such as our foss only fedora. > > I can see that after a new kernel and reboot, vmware detects that {I > believe} it can no longer load it's kernel modules, and warns that the > user needs to recompile them. I was thinking more of a way in which the > {prerequisites} package could trigger the running of the supplied config > script, if it finds it already installed. If the script isn't already > installed, then it would do nothing. Sounds nice, but I really doubt a bit that Extras is the proper place for this. Just my 2 cent. The same is true for the answers below: >>> Any thoughts on possibilities and on incorporating such in extras ? >> I don't think it's possible or makes to much sense in Extras. > Is that because it would give the end user the impression that the > package is vmware itself ? Well, it will be confusing as you can't even have a a dep on the vmware rpm. I think that might be acceptable in a 3rd party repo. > Or because it isn't FOSS ? That's part of the reason. > {and xen is coming along nicely} /me uses vmware on one machine currently as xen doesn't support cpufreq yet in Fedora's kernel > Or because it doesn't really do anything in itself ? {I vaguely remember > someone mentioned that this sort of thing makes more sense to be done > in groups files within a repo} No, I think that's no problem. >> Maybe you have more luck in one of the 3rd party repos. > Good point. Or my,our internal repo. > > Thanks for your input :) > > In reading between the lines, I guess it would make more sense to > encourage vmware to insert the correct dependencies for compilation, or > provide a -devel package that requires the bits needed to recompile > their modules. The best for everyone would probably: ask vmware to ship the kernel modules (patches for the latest kernel with any-any) and/or the complete RPM in 3rd party add-on repos. That would make using the stuff much easier. > Having not tried other rpm based distros for a long time, > is there much common in the way redhat/fedora package compared to say > suse etc ? Different package names and layouts for the same/similar packages are probably the biggest problems. But I might be wrong on that, I have never packaged much for other dists. Cu thl From giallu at gmail.com Fri Nov 3 11:57:47 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 3 Nov 2006 12:57:47 +0100 Subject: failing kmod build for FC-6 In-Reply-To: <454B0C21.3070602@city-fan.org> References: <454A02E5.2020408@leemhuis.info> <454B0C21.3070602@city-fan.org> Message-ID: On 11/3/06, Paul Howarth wrote: > > I think you need to update the "common" module as well as the > "sysprof-kmod" one; your devel branch should have nad a "fc7" tag, not a > "fc6" one. > > Once you've done that, bump the release number in your spec for both > FC-6 and devel, commit them, and try tagging again. In general, you are right. The point here is that, as of today, the kernel in development repo is kernel-2.6.18-1.2798.fc6; this means AFAIK I have to stick with this line in the spec: %{!?kversion: %define kversion 2.6.18-1.2798.fc6} which, despite being in devel, gives a version for the module: 1.0.5-1.2.6.18_1.2798.fc6 I am afraid there is no easy way out of this, unless I ask for removal of sysprof from -devel or a new kernel labeled .fc7 come out From bugs.michael at gmx.net Fri Nov 3 14:55:05 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 3 Nov 2006 15:55:05 +0100 Subject: please do not sign and push scorched3d update In-Reply-To: <454A6B42.3050407@hhs.nl> References: <454A6B42.3050407@hhs.nl> Message-ID: <20061103155505.c8f41322.bugs.michael@gmx.net> On Thu, 02 Nov 2006 23:03:46 +0100, Hans de Goede wrote: > Hi, > > I've just build a new upstream version of scorched3d, and when checking > the buildlog I saw that this new version now can play ogg files (for > module addons which want to use these). Something which they maybe could > have mentioned in the changelog? GRRR. However the current build doesn't > support this as I didn't add the necessary BR's. Since scorched3d is > rather huge (55 MB) a kind request not to sign and push todays > scorched3d builds. I'll do a new version, with a new e-v-r tomorrow with > this fixed. Preventing such builds from being pushed is trivial to do. I did that when I saw this message yesterday, but I was distracted when preparing a reply. > p.s. > > What would be the proper channel for requests like this? extras-signers@ with an obvious domain name appended. From triad at df.lth.se Fri Nov 3 16:05:21 2006 From: triad at df.lth.se (Linus Walleij) Date: Fri, 3 Nov 2006 17:05:21 +0100 (CET) Subject: Free enough for FE In-Reply-To: <4548ACCB.1050706@hhs.nl> References: <4548ACCB.1050706@hhs.nl> Message-ID: On Wed, 1 Nov 2006, Hans de Goede wrote: > 2) You may charge a reasonable copying fee for this archive, (...) FE currently allows you to charge unreasonable fees for copies of it. (Not that I care much about that particular freedom though.) Linus From triad at df.lth.se Fri Nov 3 16:09:35 2006 From: triad at df.lth.se (Linus Walleij) Date: Fri, 3 Nov 2006 17:09:35 +0100 (CET) Subject: Free enough for FE In-Reply-To: References: <4548ACCB.1050706@hhs.nl> Message-ID: On Fri, 3 Nov 2006, Linus Walleij wrote: > On Wed, 1 Nov 2006, Hans de Goede wrote: > >> 2) You may charge a reasonable copying fee for this archive, (...) > > FE currently allows you to charge unreasonable fees for copies of it. Oh not for the archive itself though, being the source. Sorry, me == idiot. Linus From vonbrand at inf.utfsm.cl Fri Nov 3 16:27:21 2006 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 03 Nov 2006 13:27:21 -0300 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-03 In-Reply-To: Message from Fedora Extras repoclosure of "Fri, 03 Nov 2006 11:14:44 -0000." <20061103111444.24386.79495@extras64.linux.duke.edu> Message-ID: <200611031627.kA3GRLZw015188@laptop13.inf.utfsm.cl> Fedora Extras repoclosure wrote: > Summary of broken packages (by owner): > ---------------------------------------------------------------------- [...] > chrisw AT redhat.com > git-core - 1.4.2.4-1.fc6.i386 (3 days) > git-core - 1.4.2.4-1.fc6.ppc (3 days) > git-core - 1.4.2.4-1.fc6.x86_64 (3 days) Should just grab 1.4.3.3 SRPM upstream and rebuild against new libcurl. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From eric.tanguy at univ-nantes.fr Fri Nov 3 16:56:00 2006 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Fri, 03 Nov 2006 17:56:00 +0100 Subject: camstream in extras In-Reply-To: <1162537847.3043.2.camel@bureau.maison> References: <1162502942.3089.7.camel@bureau.maison> <454A63C3.2050704@kobold.org> <1162537847.3043.2.camel@bureau.maison> Message-ID: <1162572960.3073.12.camel@bureau.maison> Le vendredi 03 novembre 2006 ? 08:10 +0100, Tanguy Eric a ?crit : > Le jeudi 02 novembre 2006 ? 13:31 -0800, Michael Thomas a ?crit : > > Tanguy Eric wrote: > > > camstream is a dead extra package. I tried to contact the maintainer > > > without any success so i tried to rebuild locally the fc5 package for > > > fc6 but i have errors that i can't understand and mailing upstream have > > > no answers at this time. > > > So if someone could help me to solve this : > > > > > > g++ -g -c -o video_asm.o video_asm.S > > > In file included from video_asm.S:4: > > > video_def.h:2:27: error: linux/linkage.h: No such file or directory > > > make[2]: *** [video_asm.o] Error 1 > > > > linux/linkage.h is part of the kernel-devel package. Do you have > > BuildRequires: kernel-devel in the spec file? > > > > --Wart > Buildrequires: kernel-devel is in spec file (i'm in fc6). > and i find linkage.h > in /usr/src/kernels/2.6.18-1.2798.fc6-i686/include/linux/linkage.h > > no more ideas ! Ok doing ln -s /usr/src/kernels/2.6.18-1.2798.fc6-i686/include/asm/linkage.h /usr/include/asm/inkage.h and ln -s /usr/src/kernels/2.6.18-1.2798.fc6-i686/include/asm/linkage.h /usr/include/linux/inkage.h did the trick but i don't know why i need to do this. Eric From kevin.kofler at chello.at Fri Nov 3 19:35:51 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 3 Nov 2006 19:35:51 +0000 (UTC) Subject: State of multilib development update References: <4541C56A.5070903@hhs.nl> Message-ID: I just found another one: setarch i386 kde-config --libsuffix returns 64 on x86_64. Kevin Kofler From rdieter at math.unl.edu Fri Nov 3 19:46:30 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 03 Nov 2006 13:46:30 -0600 Subject: State of multilib development update References: <4541C56A.5070903@hhs.nl> Message-ID: Kevin Kofler wrote: > I just found another one: > > setarch i386 kde-config --libsuffix > returns 64 on x86_64. Since kde-config is a 64bit binary, I'm a little surprised it to worked at all via 'setarch i386'. -- Rex From j.w.r.degoede at hhs.nl Fri Nov 3 20:33:15 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 03 Nov 2006 21:33:15 +0100 Subject: please do not sign and push scorched3d update In-Reply-To: <20061103155505.c8f41322.bugs.michael@gmx.net> References: <454A6B42.3050407@hhs.nl> <20061103155505.c8f41322.bugs.michael@gmx.net> Message-ID: <454BA78B.9000201@hhs.nl> Michael Schwendt wrote: > On Thu, 02 Nov 2006 23:03:46 +0100, Hans de Goede wrote: > >> Hi, >> >> I've just build a new upstream version of scorched3d, and when checking >> the buildlog I saw that this new version now can play ogg files (for >> module addons which want to use these). Something which they maybe could >> have mentioned in the changelog? GRRR. However the current build doesn't >> support this as I didn't add the necessary BR's. Since scorched3d is >> rather huge (55 MB) a kind request not to sign and push todays >> scorched3d builds. I'll do a new version, with a new e-v-r tomorrow with >> this fixed. > > Preventing such builds from being pushed is trivial to do. I did that when > I saw this message yesterday, but I was distracted when preparing a reply. > I already noticed it didn't get pushed, thanks! Regards, Hans From jwboyer at jdub.homelinux.org Fri Nov 3 20:47:49 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 03 Nov 2006 14:47:49 -0600 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-03 In-Reply-To: <200611031627.kA3GRLZw015188@laptop13.inf.utfsm.cl> References: <200611031627.kA3GRLZw015188@laptop13.inf.utfsm.cl> Message-ID: <1162586869.11259.23.camel@zod.rchland.ibm.com> On Fri, 2006-11-03 at 13:27 -0300, Horst H. von Brand wrote: > Fedora Extras repoclosure wrote: > > Summary of broken packages (by owner): > > ---------------------------------------------------------------------- > > [...] > > > chrisw AT redhat.com > > git-core - 1.4.2.4-1.fc6.i386 (3 days) > > git-core - 1.4.2.4-1.fc6.ppc (3 days) > > git-core - 1.4.2.4-1.fc6.x86_64 (3 days) > > Should just grab 1.4.3.3 SRPM upstream and rebuild against new libcurl. A bug has already been filed for this. josh From kevin.kofler at chello.at Fri Nov 3 22:31:47 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 3 Nov 2006 22:31:47 +0000 (UTC) Subject: State of multilib development update References: <4541C56A.5070903@hhs.nl> Message-ID: Rex Dieter writes: > Since kde-config is a 64bit binary, I'm a little surprised it to worked at > all via 'setarch i386'. It's the same as for all the other binaries Hans de Goede tried with setarch and found not multilib-ready. ;-) setarch i386 won't break 64-bit binaries, but it won't make them magically find the 32-bit multilibs either unless they're specifically coded for it. Sadly, this doesn't seem to be the case for the current versions of several central development tools in Fedora, and kde-config appears to be one of the offenders. By the way, for the record, I tested this in a qemu-system-x86_64 running on my 32-bit Pentium 4. ;-) Kevin Kofler From rdieter at math.unl.edu Sat Nov 4 04:26:28 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 03 Nov 2006 22:26:28 -0600 Subject: pb with livna's update ? In-Reply-To: <1162538510.3043.8.camel@bureau.maison> References: <1162479475.3486.0.camel@bureau.maison> <1162538510.3043.8.camel@bureau.maison> Message-ID: Tanguy Eric wrote: > Error: Missing Dependency: libxine.so.1 is needed by package > xine-lib-extras-nonfree > Error: Missing Dependency: libx264.so.54 is needed by package ffmpeg > Error: Missing Dependency: xine-lib = 1.1.2 is needed by package > xine-lib-extras-nonfree > > Someone could confirm this to know if this is a problem from my machine > or a problem from livna repo. xine-lib is (now) in Extras. Maybe your Extras mirror hasn't picked it up yet. -- Rex From j.w.r.degoede at hhs.nl Sat Nov 4 08:06:49 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 04 Nov 2006 09:06:49 +0100 Subject: State of multilib development update In-Reply-To: References: <4541C56A.5070903@hhs.nl> Message-ID: <454C4A19.1080503@hhs.nl> Kevin Kofler wrote: > Rex Dieter writes: >> Since kde-config is a 64bit binary, I'm a little surprised it to worked at >> all via 'setarch i386'. > > It's the same as for all the other binaries Hans de Goede tried with setarch > and found not multilib-ready. ;-) setarch i386 won't break 64-bit binaries, but > it won't make them magically find the 32-bit multilibs either unless they're > specifically coded for it. Sadly, this doesn't seem to be the case for the > current versions of several central development tools in Fedora, and kde-config > appears to be one of the offenders. > > By the way, for the record, I tested this in a qemu-system-x86_64 running on my > 32-bit Pentium 4. ;-) > As a wrokaround you could grab the kde-config from the i386 package manually and drop it in a special dir (for example rpmbuild-i386) and then add this dir to the fron of your PATH when you want to build i386 binaries. Regards, Hans From dragoran at feuerpokemon.de Sat Nov 4 08:29:33 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 04 Nov 2006 09:29:33 +0100 Subject: State of multilib development update In-Reply-To: <4541C56A.5070903@hhs.nl> References: <4541C56A.5070903@hhs.nl> Message-ID: <454C4F6D.1050102@feuerpokemon.de> I would like to add this: i386-devel packages do not create the symlinks needed by ld to find a lib. ld -lX11 will search for libX11.so If you have libX11-devel.x86_64 installed there will be a symlink /usr/lib64/libX11.so -> /usr/lib64/libX11.so.6.2.0 which is ok and works. But if you have installed libX11-devel.i386 there is no symlink which results into ld is unable to find the lib. libX11 was just an example, this happens with ALL i386-devel packages. From ville.skytta at iki.fi Sat Nov 4 09:23:46 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 04 Nov 2006 11:23:46 +0200 Subject: rpms/mock/FC-5 arch-specific-repo.patch, NONE, 1.1 mock.spec, 1.23, 1.24 In-Reply-To: <200611032113.kA3LD0H4015584@cvs-int.fedora.redhat.com> References: <200611032113.kA3LD0H4015584@cvs-int.fedora.redhat.com> Message-ID: <1162632227.29663.3.camel@viper.local> On Fri, 2006-11-03 at 14:13 -0700, Jesse Keating wrote: > --- NEW FILE arch-specific-repo.patch --- > --- etc/fedora-4-ppc-core.cfg.jk 2006-11-03 15:16:00.000000000 -0500 > +++ etc/fedora-4-ppc-core.cfg 2006-11-03 15:30:39.000000000 -0500 [...] > +baseurl=http://download.fedoraproject.org/pub/fedora/linux/core/4/x86_64/os > +baseurl=http://download.fedoraproject.org/pub/fedora/linux/core/updates/4/x86_64 > +baseurl=http://download.fedoraproject.org/pub/fedora/linux/extras/4/x86_64 Hm, x86_64 in fedora-4-ppc-core.cfg? From j.w.r.degoede at hhs.nl Sat Nov 4 10:22:02 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 04 Nov 2006 11:22:02 +0100 Subject: State of multilib development update In-Reply-To: <454C4F6D.1050102@feuerpokemon.de> References: <4541C56A.5070903@hhs.nl> <454C4F6D.1050102@feuerpokemon.de> Message-ID: <454C69CA.5070605@hhs.nl> dragoran wrote: > I would like to add this: > i386-devel packages do not create the symlinks needed by ld to find a lib. > ld -lX11 will search for libX11.so > If you have libX11-devel.x86_64 installed there will be a symlink > /usr/lib64/libX11.so -> /usr/lib64/libX11.so.6.2.0 which is ok and works. > But if you have installed libX11-devel.i386 there is no symlink which > results into ld is unable to find the lib. > libX11 was just an example, this happens with ALL i386-devel packages. > Wrong, The foo-devel packages does install the symlink and it requires foo to ensure that the target of the symlink is there, however since foo.x86_64 is already installed, the requires: foo will be fullfilled and foo.i386 won't get installed. The trick is to learn yourself todo: yum -y install foo.i386 foo-devel.i386 instead of just: yum -y install foo-devel.i386 The same must be done for x86_64 btw, because otherwise if foo-devel.x86_64 is newer then the installed foo.x86_64, then the requires: foo = %{version}-%{release} will not be met and thus foo.x86_64 will get updated and foo.i386 will get installed (since yum doesn't know which if these 2 foo's to install to match the requires it installs both). Thus the proper way to install a foo-devel.x86_64 is: yum -y install foo.x86_64 foo-devel.x86_64 Otherwise foo.i386 might get installed as an unwanted side effect. I think we really should put this all in the wiki somewhere, suggestions where? Regards, Hans From andreas.bierfert at lowlatency.de Sat Nov 4 10:59:30 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sat, 4 Nov 2006 11:59:30 +0100 Subject: wine apps menu entries Message-ID: <20061104115930.673732ef@alkaid.a.lan> Hi, after thinking about this for some time now I would like to get the community involved with this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205024. It states the the wine apps provided by the wine-tools package fill up the normal fedora menu and asks for a wine submenu. I would like to add a wine submenu but first want to know what you folks think about this... gather some pro and cons and so on :) Thanks, Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chitlesh at fedoraproject.org Sat Nov 4 11:22:33 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sat, 4 Nov 2006 12:22:33 +0100 Subject: wine apps menu entries In-Reply-To: <20061104115930.673732ef@alkaid.a.lan> References: <20061104115930.673732ef@alkaid.a.lan> Message-ID: <13dbfe4f0611040322h68383ecamf12eb353d00e9ae6@mail.gmail.com> On 11/4/06, Andreas Bierfert < hidden > wrote: > normal fedora menu and asks for a wine submenu. I would like to add a wine > submenu but first want to know what you folks think about this... gather some > pro and cons and so on :) I'm for, however when installing all wine packages from FE, there are some icons missing on KDE chitlesh -- http://clunixchit.blogspot.com From andreas.bierfert at lowlatency.de Sat Nov 4 11:39:18 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sat, 4 Nov 2006 12:39:18 +0100 Subject: wine apps menu entries In-Reply-To: <13dbfe4f0611040322h68383ecamf12eb353d00e9ae6@mail.gmail.com> References: <20061104115930.673732ef@alkaid.a.lan> <13dbfe4f0611040322h68383ecamf12eb353d00e9ae6@mail.gmail.com> Message-ID: <20061104123918.506c627f@alkaid.a.lan> On Sat, 4 Nov 2006 12:22:33 +0100 "Chitlesh GOORAH" wrote: > I'm for, however when installing all wine packages from FE, there are > some icons missing on KDE Could you be more precise which ones are missing so I can take a look. Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Sat Nov 4 12:54:32 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 4 Nov 2006 07:54:32 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-04 Message-ID: <20061104125432.7E8B015212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 32 R-2.4.0-2.fc7 SoQt-1.4.1-2.fc7 alex4-1.0-2.fc7 audacity-1.2.5-2.fc7 codeblocks-1.0-0.12.20061102svn3170.fc7 evolution-bogofilter-0.2.0-4.fc7 fwfstab-0.01.1-1.fc7 gaim-gaym-0.96-3.4.290svn.fc7 gaim-rhythmbox-2.0-0.4.beta4.fc7 gdeskcal-1.0-9.fc7 geda-examples-20061020-1.fc7 geda-gattrib-20061020-1.fc7 geda-gnetlist-20061020-1.fc7 geda-gschem-20061020-1.fc7 geda-symbols-20061020-1.fc7 geda-utils-20061020-1.fc7 jd-1.8.0-0.5.beta061103.fc7 kdmtheme-1.1.2-4.fc7 kmenu-gnome-0.6.1-2.fc7 libgeda-20061020-1.fc7 lilypond-2.8.8-1.fc7 mock-0.6.8-2.fc7 nyquist-2.31-3.fc7 perl-Archive-Extract-0.14-1.fc7 perl-DateTime-0.35-1.fc7 perl-Event-1.08-1.fc7 perl-IPC-Cmd-0.34-1.fc7 perl-Net-SCP-0.07-5.fc7 perl-Term-UI-0.14-1.fc7 php-pecl-zip-1.8.0-1.fc7 plone-2.5.1-3.fc7 raptor-1.4.9-6.fc7 Packages built and released for Fedora Extras 6: 23 R-2.4.0-2.fc6 SoQt-1.4.1-2.fc6 audacity-1.2.5-2.fc6 codeblocks-1.0-0.12.20061102svn3170.fc6 gaim-gaym-0.96-3.4.290svn.fc6 gaim-rhythmbox-2.0-0.4.beta4.fc6 gdeskcal-1.0-9.fc6 geda-examples-20061020-1.fc6 geda-gattrib-20061020-1.fc6 geda-gnetlist-20061020-1.fc6 geda-gschem-20061020-1.fc6 geda-symbols-20061020-1.fc6 geda-utils-20061020-1.fc6 jd-1.8.0-0.5.beta061103.fc6 kdmtheme-1.1.2-4.fc6 kmenu-gnome-0.6.1-2.fc6 libgeda-20061020-1.fc6 lighttpd-1.4.13-2.fc6 mock-0.6.8-2.fc6 nyquist-2.31-3.fc6 php-pecl-zip-1.8.0-1.fc6 plone-2.5.1-3.fc6 scorched3d-40.1c-2.fc6 Packages built and released for Fedora Extras 5: 20 R-2.4.0-2.fc5 SoQt-1.4.1-2.fc5 audacity-1.2.5-2.fc5 codeblocks-1.0-0.12.20061102svn3170.fc5 geda-examples-20061020-1.fc5 geda-gattrib-20061020-1.fc5 geda-gnetlist-20061020-1.fc5 geda-gschem-20061020-1.fc5 geda-symbols-20061020-1.fc5 geda-utils-20061020-1.fc5 jd-1.8.0-0.5.beta061103.fc5 kdmtheme-1.1.2-4.fc5 kmenu-gnome-0.6.1-2.fc5 libgeda-20061020-1.fc5 mock-0.6.8-2.fc5 nyquist-2.31-3.fc5 perl-Event-1.08-1.fc5 php-pecl-zip-1.8.0-1.fc5 scorched3d-40.1c-2.fc5 soundconverter-0.9.3-1.fc5 Packages built and released for Fedora Extras 4: 3 R-2.4.0-2.fc4.1 SoQt-1.4.1-2.fc4 soundconverter-0.9.3-1.fc4 Packages built and released for Fedora Extras 3: 1 SoQt-1.4.1-2.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From jkeating at redhat.com Sat Nov 4 13:00:38 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 4 Nov 2006 08:00:38 -0500 Subject: rpms/mock/FC-5 arch-specific-repo.patch, NONE, 1.1 mock.spec, 1.23, 1.24 In-Reply-To: <1162632227.29663.3.camel@viper.local> References: <200611032113.kA3LD0H4015584@cvs-int.fedora.redhat.com> <1162632227.29663.3.camel@viper.local> Message-ID: <200611040800.43652.jkeating@redhat.com> On Saturday 04 November 2006 04:23, Ville Skytt? wrote: > > +baseurl=http://download.fedoraproject.org/pub/fedora/linux/core/4/x86_64 > >/os > > +baseurl=http://download.fedoraproject.org/pub/fedora/linux/core/updates/ > >4/x86_64 > > +baseurl=http://download.fedoraproject.org/pub/fedora/linux/extras/4/x86_ > >64 > > Hm, x86_64 in fedora-4-ppc-core.cfg? Oh bother. I knew i was going to get one wrong... thanks for catching that. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From giallu at gmail.com Sat Nov 4 13:33:11 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sat, 4 Nov 2006 14:33:11 +0100 Subject: wine apps menu entries In-Reply-To: <20061104115930.673732ef@alkaid.a.lan> References: <20061104115930.673732ef@alkaid.a.lan> Message-ID: On 11/4/06, Andreas Bierfert wrote: > Hi, > > after thinking about this for some time now I would like to get the community > involved with this bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205024. > It states the the wine apps provided by the wine-tools package fill up the > normal fedora menu and asks for a wine submenu. I would like to add a wine > submenu but first want to know what you folks think about this... gather some > pro and cons and so on :) > Count me in as a +1. I also considered reporting that myself when I first saw how many icons were added to the menu... From Lam at Lam.pl Sat Nov 4 13:40:50 2006 From: Lam at Lam.pl (Leszek Matok) Date: Sat, 04 Nov 2006 14:40:50 +0100 Subject: wine apps menu entries In-Reply-To: <20061104123918.506c627f@alkaid.a.lan> References: <20061104115930.673732ef@alkaid.a.lan> <13dbfe4f0611040322h68383ecamf12eb353d00e9ae6@mail.gmail.com> <20061104123918.506c627f@alkaid.a.lan> Message-ID: <1162647650.3206.1.camel@pensja.lam.pl> Dnia 04-11-2006, sob o godzinie 12:39 +0100, Andreas Bierfert napisa?(a): > Could you be more precise which ones are missing so I can take a look. $ grep Icon /usr/share/applications/fedora-wine* $ This is wine-core-0.9.24-1.fc6 Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From buildsys at fedoraproject.org Sat Nov 4 14:01:38 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 04 Nov 2006 14:01:38 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-04 Message-ID: <20061104140138.29659.61384@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 (4 days) centericq - 4.21.0-8.fc6.ppc (4 days) centericq - 4.21.0-8.fc6.x86_64 (4 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (7 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (7 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (7 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (7 days) orange - 0.3-3.cvs20051118.fc6.i386 (11 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (35 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (35 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (35 days) sylpheed-claws-plugins-gtkhtml2-viewer - 2.5.2-4.fc6.i386 (4 days) sylpheed-claws-plugins-gtkhtml2-viewer - 2.5.2-4.fc6.ppc (4 days) sylpheed-claws-plugins-gtkhtml2-viewer - 2.5.2-4.fc6.x86_64 (4 days) sylpheed-claws-plugins-rssyl - 2.5.2-4.fc6.i386 (4 days) sylpheed-claws-plugins-rssyl - 2.5.2-4.fc6.ppc (4 days) sylpheed-claws-plugins-rssyl - 2.5.2-4.fc6.x86_64 (4 days) sylpheed-claws-plugins-vcalendar - 2.5.2-4.fc6.i386 (4 days) sylpheed-claws-plugins-vcalendar - 2.5.2-4.fc6.ppc (4 days) sylpheed-claws-plugins-vcalendar - 2.5.2-4.fc6.x86_64 (4 days) andreas AT bawue.net icecast - 2.3.1-3.fc6.i386 (4 days) icecast - 2.3.1-3.fc6.ppc (4 days) icecast - 2.3.1-3.fc6.x86_64 (4 days) xmms-scrobbler - 0.3.8.1-2.fc6.i386 (4 days) xmms-scrobbler - 0.3.8.1-2.fc6.ppc (4 days) xmms-scrobbler - 0.3.8.1-2.fc6.x86_64 (4 days) cgoorah AT yahoo.com.au geda-gsymcheck - 20060906-1.fc5.i386 geda-gsymcheck - 20060906-1.fc5.ppc geda-gsymcheck - 20060906-1.fc5.x86_64 geda-gsymcheck - 20060906-2.fc6.i386 geda-gsymcheck - 20060906-2.fc6.i386 geda-gsymcheck - 20060906-2.fc6.ppc geda-gsymcheck - 20060906-2.fc6.ppc geda-gsymcheck - 20060906-2.fc6.x86_64 geda-gsymcheck - 20060906-2.fc6.x86_64 chabotc AT xs4all.nl rtorrent - 0.6.2-4.fc6.i386 (4 days) rtorrent - 0.6.2-4.fc6.ppc (4 days) rtorrent - 0.6.2-4.fc6.x86_64 (4 days) chrisw AT redhat.com git-core - 1.4.2.4-1.fc6.i386 (4 days) git-core - 1.4.2.4-1.fc6.ppc (4 days) git-core - 1.4.2.4-1.fc6.x86_64 (4 days) dakingun AT gmail.com gnomesword - 2.1.6-5.fc6.i386 (4 days) gnomesword - 2.1.6-5.fc6.ppc (4 days) gnomesword - 2.1.6-5.fc6.x86_64 (4 days) sword - 1.5.8-10.fc6.i386 (4 days) sword - 1.5.8-10.fc6.i386 (4 days) sword - 1.5.8-10.fc6.ppc (4 days) sword - 1.5.8-10.fc6.x86_64 (4 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (50 days) plague - 0.4.4.1-2.fc3.noarch (50 days) plague - 0.4.4.1-2.fc4.noarch (50 days) plague - 0.4.4.1-2.fc4.noarch (50 days) plague - 0.4.4.1-2.fc4.noarch (50 days) endur AT bennewitz.com streamtuner - 0.99.99-13.fc6.i386 (4 days) streamtuner - 0.99.99-13.fc6.i386 (4 days) streamtuner - 0.99.99-13.fc6.ppc (4 days) streamtuner - 0.99.99-13.fc6.x86_64 (4 days) enrico.scholz AT informatik.tu-chemnitz.de xmlrpc-c - 1.06.05-2.fc6.i386 (4 days) xmlrpc-c - 1.06.05-2.fc6.i386 (4 days) xmlrpc-c - 1.06.05-2.fc6.ppc (4 days) xmlrpc-c - 1.06.05-2.fc6.x86_64 (4 days) xmlrpc-c-apps - 1.06.05-2.fc6.i386 (4 days) xmlrpc-c-apps - 1.06.05-2.fc6.ppc (4 days) xmlrpc-c-apps - 1.06.05-2.fc6.x86_64 (4 days) giallu AT gmail.com sysprof - 1.0.5-1.fc6.i386 sysprof - 1.0.5-1.fc6.x86_64 hamzy AT us.ibm.com sblim-wbemcli - 1.5.1-4.fc6.i386 (4 days) sblim-wbemcli - 1.5.1-4.fc6.ppc (4 days) sblim-wbemcli - 1.5.1-4.fc6.x86_64 (4 days) hugo AT devin.com.br xmoto - 0.2.0-1.fc6.i386 (4 days) xmoto - 0.2.0-1.fc6.ppc (4 days) xmoto - 0.2.0-1.fc6.x86_64 (4 days) imlinux AT gmail.com nagios-plugins-ide_smart - 1.4.3-20.fc4.i386 (10 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.ppc (10 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.x86_64 (10 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (26 days) linphone - 1.2.0-4.fc5.ppc (26 days) linphone - 1.2.0-4.fc5.x86_64 (26 days) linphone - 1.2.0-7.fc6.i386 (11 days) linphone - 1.2.0-7.fc6.ppc (11 days) linphone - 1.2.0-7.fc6.x86_64 (11 days) lmacken AT redhat.com deskbar-applet - 2.16.0-1.fc6.i386 (7 days) deskbar-applet - 2.16.0-1.fc6.ppc (7 days) deskbar-applet - 2.16.0-1.fc6.x86_64 (7 days) nphilipp AT redhat.com bzflag - 2.0.8-3.fc6.i386 (4 days) bzflag - 2.0.8-3.fc6.ppc (4 days) bzflag - 2.0.8-3.fc6.x86_64 (4 days) oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (16 days) syck-php - 0.55-9.fc5.ppc (16 days) syck-php - 0.55-9.fc5.x86_64 (16 days) petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 ghc-gtk2hs - 0.9.10-4.fc6.ppc ghc-gtk2hs - 0.9.10-4.fc6.x86_64 ghc642-gtk2hs - 0.9.10-4.fc6.i386 ghc642-gtk2hs - 0.9.10-4.fc6.ppc ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 qspencer AT ieee.org octave-forge - 2006.07.09-7.fc6.i386 (4 days) octave-forge - 2006.07.09-7.fc6.ppc (4 days) octave-forge - 2006.07.09-7.fc6.x86_64 (4 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (6 days) redhat-bugzilla AT camperquake.de audacious - 1.1.2-2.fc6.i386 (4 days) audacious - 1.1.2-2.fc6.i386 (4 days) audacious - 1.1.2-2.fc6.ppc (4 days) audacious - 1.1.2-2.fc6.x86_64 (4 days) stickster AT gmail.com drivel - 2.1.0-0.3.20060527cvs.fc6.i386 (4 days) drivel - 2.1.0-0.3.20060527cvs.fc6.ppc (4 days) drivel - 2.1.0-0.3.20060527cvs.fc6.x86_64 (4 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- audacious-1.1.2-2.fc6.ppc requires libcurl.so.3 bzflag-2.0.8-3.fc6.ppc requires libcurl.so.3 centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 deskbar-applet-2.16.0-1.fc6.ppc requires libedataserver-1.2.so.7 drivel-2.1.0-0.3.20060527cvs.fc6.ppc requires libcurl.so.3 geda-gsymcheck-20060906-2.fc6.ppc requires libgeda.so.26 ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 git-core-1.4.2.4-1.fc6.ppc requires libcurl.so.3 gnomesword-2.1.6-5.fc6.ppc requires libcurl.so.3 icecast-2.3.1-3.fc6.ppc requires libcurl.so.3 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 octave-forge-2006.07.09-7.fc6.ppc requires libcurl.so.3 rtorrent-0.6.2-4.fc6.ppc requires libcurl.so.3 sblim-wbemcli-1.5.1-4.fc6.ppc requires libcurl.so.3 streamtuner-0.99.99-13.fc6.ppc requires libcurl.so.3 sword-1.5.8-10.fc6.ppc requires libcurl.so.3 sylpheed-claws-plugins-gtkhtml2-viewer-2.5.2-4.fc6.ppc requires libcurl.so.3 sylpheed-claws-plugins-rssyl-2.5.2-4.fc6.ppc requires libcurl.so.3 sylpheed-claws-plugins-vcalendar-2.5.2-4.fc6.ppc requires libcurl.so.3 xmlrpc-c-1.06.05-2.fc6.ppc requires libcurl.so.3 xmlrpc-c-apps-1.06.05-2.fc6.ppc requires libcurl.so.3 xmms-scrobbler-0.3.8.1-2.fc6.ppc requires libcurl.so.3 xmoto-0.2.0-1.fc6.ppc requires libcurl.so.3 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- audacious-1.1.2-2.fc6.i386 requires libcurl.so.3 audacious-1.1.2-2.fc6.x86_64 requires libcurl.so.3()(64bit) bzflag-2.0.8-3.fc6.x86_64 requires libcurl.so.3()(64bit) centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) deskbar-applet-2.16.0-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) drivel-2.1.0-0.3.20060527cvs.fc6.x86_64 requires libcurl.so.3()(64bit) geda-gsymcheck-20060906-2.fc6.x86_64 requires libgeda.so.26()(64bit) ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 git-core-1.4.2.4-1.fc6.x86_64 requires libcurl.so.3()(64bit) gnomesword-2.1.6-5.fc6.x86_64 requires libcurl.so.3()(64bit) icecast-2.3.1-3.fc6.x86_64 requires libcurl.so.3()(64bit) libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) octave-forge-2006.07.09-7.fc6.x86_64 requires libcurl.so.3()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 rtorrent-0.6.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) sblim-wbemcli-1.5.1-4.fc6.x86_64 requires libcurl.so.3()(64bit) streamtuner-0.99.99-13.fc6.i386 requires libcurl.so.3 streamtuner-0.99.99-13.fc6.x86_64 requires libcurl.so.3()(64bit) sword-1.5.8-10.fc6.i386 requires libcurl.so.3 sword-1.5.8-10.fc6.x86_64 requires libcurl.so.3()(64bit) sylpheed-claws-plugins-gtkhtml2-viewer-2.5.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) sylpheed-claws-plugins-rssyl-2.5.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) sylpheed-claws-plugins-vcalendar-2.5.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) xmlrpc-c-1.06.05-2.fc6.i386 requires libcurl.so.3 xmlrpc-c-1.06.05-2.fc6.x86_64 requires libcurl.so.3()(64bit) xmlrpc-c-apps-1.06.05-2.fc6.x86_64 requires libcurl.so.3()(64bit) xmms-scrobbler-0.3.8.1-2.fc6.x86_64 requires libcurl.so.3()(64bit) xmoto-0.2.0-1.fc6.x86_64 requires libcurl.so.3()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- audacious-1.1.2-2.fc6.i386 requires libcurl.so.3 bzflag-2.0.8-3.fc6.i386 requires libcurl.so.3 centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 deskbar-applet-2.16.0-1.fc6.i386 requires libedataserver-1.2.so.7 drivel-2.1.0-0.3.20060527cvs.fc6.i386 requires libcurl.so.3 geda-gsymcheck-20060906-2.fc6.i386 requires libgeda.so.26 ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 git-core-1.4.2.4-1.fc6.i386 requires libcurl.so.3 gnomesword-2.1.6-5.fc6.i386 requires libcurl.so.3 icecast-2.3.1-3.fc6.i386 requires libcurl.so.3 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 octave-forge-2006.07.09-7.fc6.i386 requires libcurl.so.3 rtorrent-0.6.2-4.fc6.i386 requires libcurl.so.3 sblim-wbemcli-1.5.1-4.fc6.i386 requires libcurl.so.3 streamtuner-0.99.99-13.fc6.i386 requires libcurl.so.3 sword-1.5.8-10.fc6.i386 requires libcurl.so.3 sylpheed-claws-plugins-gtkhtml2-viewer-2.5.2-4.fc6.i386 requires libcurl.so.3 sylpheed-claws-plugins-rssyl-2.5.2-4.fc6.i386 requires libcurl.so.3 sylpheed-claws-plugins-vcalendar-2.5.2-4.fc6.i386 requires libcurl.so.3 xmlrpc-c-1.06.05-2.fc6.i386 requires libcurl.so.3 xmlrpc-c-apps-1.06.05-2.fc6.i386 requires libcurl.so.3 xmms-scrobbler-0.3.8.1-2.fc6.i386 requires libcurl.so.3 xmoto-0.2.0-1.fc6.i386 requires libcurl.so.3 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- geda-gsymcheck-20060906-2.fc6.ppc requires libgeda.so.26 linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- geda-gsymcheck-20060906-2.fc6.x86_64 requires libgeda.so.26()(64bit) linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) sysprof-1.0.5-1.fc6.x86_64 requires kmod-sysprof >= 0:1.0.5 Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- geda-gsymcheck-20060906-2.fc6.i386 requires libgeda.so.26 linphone-1.2.0-7.fc6.i386 requires libortp.so.2 sysprof-1.0.5-1.fc6.i386 requires kmod-sysprof >= 0:1.0.5 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- geda-gsymcheck-20060906-1.fc5.ppc requires libgeda.so.26 linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- geda-gsymcheck-20060906-1.fc5.x86_64 requires libgeda.so.26()(64bit) linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- geda-gsymcheck-20060906-1.fc5.i386 requires libgeda.so.26 linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.ppc requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.x86_64 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.i386 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: cgoorah AT yahoo.com.au package: geda-gsymcheck - 20060906-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgeda.so.26 package: geda-gsymcheck - 20060906-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgeda.so.26()(64bit) package: geda-gsymcheck - 20060906-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgeda.so.26 package: geda-gsymcheck - 20060906-2.fc6.ppc from fedora-extras-6-ppc unresolved deps: libgeda.so.26 package: geda-gsymcheck - 20060906-2.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: libgeda.so.26()(64bit) package: geda-gsymcheck - 20060906-2.fc6.i386 from fedora-extras-6-i386 unresolved deps: libgeda.so.26 package: geda-gsymcheck - 20060906-1.fc5.ppc from fedora-extras-5-ppc unresolved deps: libgeda.so.26 package: geda-gsymcheck - 20060906-1.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libgeda.so.26()(64bit) package: geda-gsymcheck - 20060906-1.fc5.i386 from fedora-extras-5-i386 unresolved deps: libgeda.so.26 From chitlesh at fedoraproject.org Sat Nov 4 14:10:21 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sat, 4 Nov 2006 15:10:21 +0100 Subject: wine apps menu entries In-Reply-To: <20061104123918.506c627f@alkaid.a.lan> References: <20061104115930.673732ef@alkaid.a.lan> <13dbfe4f0611040322h68383ecamf12eb353d00e9ae6@mail.gmail.com> <20061104123918.506c627f@alkaid.a.lan> Message-ID: <13dbfe4f0611040610w70656035p1cce53b3e08e8d8a@mail.gmail.com> On 11/4/06, Andreas Bierfert < hidden > wrote: > Could you be more precise which ones are missing so I can take a look. winemine notepad regedit wine file wine configuration wine help wine software uninstaller -- http://clunixchit.blogspot.com From jkeating at redhat.com Sat Nov 4 15:37:31 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 4 Nov 2006 10:37:31 -0500 Subject: State of multilib development update In-Reply-To: <454C69CA.5070605@hhs.nl> References: <4541C56A.5070903@hhs.nl> <454C4F6D.1050102@feuerpokemon.de> <454C69CA.5070605@hhs.nl> Message-ID: <200611041037.32305.jkeating@redhat.com> On Saturday 04 November 2006 05:22, Hans de Goede wrote: > The foo-devel packages does install the symlink and it requires foo to > ensure that the target of the symlink is there, however since foo.x86_64 > is already installed, the requires: foo will be fullfilled and foo.i386 > ?won't get installed. The trick is to learn yourself todo: > yum -y install foo.i386 foo-devel.i386 > instead of just: > yum -y install foo-devel.i386 Hrm, the patch we added to rpm should have made this happen automatically... Jeremy? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Sat Nov 4 21:24:26 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 04 Nov 2006 22:24:26 +0100 Subject: State of multilib development update In-Reply-To: <200611041037.32305.jkeating@redhat.com> References: <4541C56A.5070903@hhs.nl> <454C4F6D.1050102@feuerpokemon.de> <454C69CA.5070605@hhs.nl> <200611041037.32305.jkeating@redhat.com> Message-ID: <454D050A.4000605@hhs.nl> Jesse Keating wrote: > On Saturday 04 November 2006 05:22, Hans de Goede wrote: >> The foo-devel packages does install the symlink and it requires foo to >> ensure that the target of the symlink is there, however since foo.x86_64 >> is already installed, the requires: foo will be fullfilled and foo.i386 >> won't get installed. The trick is to learn yourself todo: >> yum -y install foo.i386 foo-devel.i386 >> instead of just: >> yum -y install foo-devel.i386 > > Hrm, the patch we added to rpm should have made this happen automatically... > Since when is that patch in rpm? I'm speaking from past experience, so this might be fixed now. Regards, Hans From jkeating at redhat.com Sat Nov 4 21:33:03 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 4 Nov 2006 16:33:03 -0500 Subject: State of multilib development update In-Reply-To: <454D050A.4000605@hhs.nl> References: <4541C56A.5070903@hhs.nl> <200611041037.32305.jkeating@redhat.com> <454D050A.4000605@hhs.nl> Message-ID: <200611041633.03427.jkeating@redhat.com> On Saturday 04 November 2006 16:24, Hans de Goede wrote: > Since when is that patch in rpm? I'm speaking from past experience, so > this might be fixed now. It went in during the FC6 development cycle. I don't recall exactly when. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Sun Nov 5 18:00:18 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 5 Nov 2006 13:00:18 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-05 Message-ID: <20061105180018.8CBA615212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 21 WindowMaker-0.92.0-10.fc7 amsn-0.96-2.fc7 geda-gsymcheck-20061020-1.fc7 gnome-theme-clearlooks-bigpack-0.6-3.fc7 gnubiff-2.2.3-1.fc7 gqview-2.0.3-1.fc7 gramps-2.2.2-1.fc7 katapult-0.3.1.4-3.fc7 keychain-2.6.8-2.fc7 kphotobymail-0.4-1.fc7 mail-notification-3.0-9.fc7 mock-0.6.8-3.fc7 moomps-5.7-2.fc7 pan-0.118-1.fc7 perl-Apache-LogRegex-1.4-1.fc7 python-4Suite-XML-1.0-1 scribes-0.3-1.fc7 tcl-thread-2.6.5-2.fc7 telepathy-gabble-0.4.3-1.fc7 vdr-1.4.4-1.fc7 zeroinstall-injector-0.24-1.fc7 Packages built and released for Fedora Extras 6: 16 WindowMaker-0.92.0-10.fc6 amsn-0.96-2.fc6 fwfstab-0.01.1-1.fc6 geda-gsymcheck-20061020-1.fc6 gnome-theme-clearlooks-bigpack-0.6-3.fc6 gnubiff-2.2.3-1.fc6 katapult-0.3.1.4-3.fc6 keychain-2.6.8-1.fc6 mock-0.6.8-3.fc6 moomps-5.7-2.fc6 pan-0.118-1.fc6 perl-Event-1.08-1.fc6 scribes-0.3-1.fc6 tcl-thread-2.6.5-2.fc6 vdr-1.4.4-1.fc6 zeroinstall-injector-0.24-1.fc6 Packages built and released for Fedora Extras 5: 11 amsn-0.96-2.fc5 fwfstab-0.01.1-1.fc5 gaim-rhythmbox-1.5.0.1-1.fc5 geda-gsymcheck-20061020-1.fc5 gnubiff-2.2.3-1.fc5 katapult-0.3.1.4-3.fc5 keychain-2.6.8-1.fc5 mock-0.6.8-3.fc5 moomps-5.7-2.fc5 tcl-thread-2.6.5-2.fc5 zeroinstall-injector-0.24-1.fc5 Packages built and released for Fedora Extras 4: 1 zeroinstall-injector-0.24-1.fc4 Packages built and released for Fedora Extras 3: 1 zeroinstall-injector-0.24-1.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From gauret at free.fr Sun Nov 5 18:29:59 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 05 Nov 2006 19:29:59 +0100 Subject: Orphaning zope, plone, mpc and gmpc Message-ID: Hi .*, I'm orphaning 4 packages. The first two will probably find a new home quickly : zope and plone. I don't use them anymore, so I'm sure other people will be able to give them more love. I'm also orphaning mpc and gmpc, client applications for the Music Player Daemon. The mpd can't be in Extras because it ships mp3 decoding code, and has no plugin infrastructure to split it like the xine-lib package. I don't use mpd anymore, so I'm not interested in maintaining the client apps. Please step forward if you want to maintain any of these. Thanks Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." -- Rich Cook From buildsys at fedoraproject.org Sun Nov 5 19:02:03 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 05 Nov 2006 19:02:03 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-05 Message-ID: <20061105190203.20080.59561@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 (5 days) centericq - 4.21.0-8.fc6.ppc (5 days) centericq - 4.21.0-8.fc6.x86_64 (5 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (8 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (8 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (8 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (8 days) orange - 0.3-3.cvs20051118.fc6.i386 (12 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (36 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (36 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (36 days) sylpheed-claws-plugins-gtkhtml2-viewer - 2.5.2-4.fc6.i386 (5 days) sylpheed-claws-plugins-gtkhtml2-viewer - 2.5.2-4.fc6.ppc (5 days) sylpheed-claws-plugins-gtkhtml2-viewer - 2.5.2-4.fc6.x86_64 (5 days) sylpheed-claws-plugins-rssyl - 2.5.2-4.fc6.i386 (5 days) sylpheed-claws-plugins-rssyl - 2.5.2-4.fc6.ppc (5 days) sylpheed-claws-plugins-rssyl - 2.5.2-4.fc6.x86_64 (5 days) sylpheed-claws-plugins-vcalendar - 2.5.2-4.fc6.i386 (5 days) sylpheed-claws-plugins-vcalendar - 2.5.2-4.fc6.ppc (5 days) sylpheed-claws-plugins-vcalendar - 2.5.2-4.fc6.x86_64 (5 days) andreas AT bawue.net icecast - 2.3.1-3.fc6.i386 (5 days) icecast - 2.3.1-3.fc6.ppc (5 days) icecast - 2.3.1-3.fc6.x86_64 (5 days) xmms-scrobbler - 0.3.8.1-2.fc6.i386 (5 days) xmms-scrobbler - 0.3.8.1-2.fc6.ppc (5 days) xmms-scrobbler - 0.3.8.1-2.fc6.x86_64 (5 days) chabotc AT xs4all.nl rtorrent - 0.6.2-4.fc6.i386 (5 days) rtorrent - 0.6.2-4.fc6.ppc (5 days) rtorrent - 0.6.2-4.fc6.x86_64 (5 days) chrisw AT redhat.com git-core - 1.4.2.4-1.fc6.i386 (5 days) git-core - 1.4.2.4-1.fc6.ppc (5 days) git-core - 1.4.2.4-1.fc6.x86_64 (5 days) dakingun AT gmail.com gnomesword - 2.1.6-5.fc6.i386 (5 days) gnomesword - 2.1.6-5.fc6.ppc (5 days) gnomesword - 2.1.6-5.fc6.x86_64 (5 days) sword - 1.5.8-10.fc6.i386 (5 days) sword - 1.5.8-10.fc6.i386 (5 days) sword - 1.5.8-10.fc6.ppc (5 days) sword - 1.5.8-10.fc6.x86_64 (5 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (51 days) plague - 0.4.4.1-2.fc3.noarch (51 days) plague - 0.4.4.1-2.fc4.noarch (51 days) plague - 0.4.4.1-2.fc4.noarch (51 days) plague - 0.4.4.1-2.fc4.noarch (51 days) endur AT bennewitz.com streamtuner - 0.99.99-13.fc6.i386 (5 days) streamtuner - 0.99.99-13.fc6.i386 (5 days) streamtuner - 0.99.99-13.fc6.ppc (5 days) streamtuner - 0.99.99-13.fc6.x86_64 (5 days) enrico.scholz AT informatik.tu-chemnitz.de xmlrpc-c - 1.06.05-2.fc6.i386 (5 days) xmlrpc-c - 1.06.05-2.fc6.i386 (5 days) xmlrpc-c - 1.06.05-2.fc6.ppc (5 days) xmlrpc-c - 1.06.05-2.fc6.x86_64 (5 days) xmlrpc-c-apps - 1.06.05-2.fc6.i386 (5 days) xmlrpc-c-apps - 1.06.05-2.fc6.ppc (5 days) xmlrpc-c-apps - 1.06.05-2.fc6.x86_64 (5 days) giallu AT gmail.com sysprof - 1.0.5-1.fc6.i386 (2 days) sysprof - 1.0.5-1.fc6.x86_64 (2 days) hamzy AT us.ibm.com sblim-wbemcli - 1.5.1-4.fc6.i386 (5 days) sblim-wbemcli - 1.5.1-4.fc6.ppc (5 days) sblim-wbemcli - 1.5.1-4.fc6.x86_64 (5 days) hugo AT devin.com.br xmoto - 0.2.0-1.fc6.i386 (5 days) xmoto - 0.2.0-1.fc6.ppc (5 days) xmoto - 0.2.0-1.fc6.x86_64 (5 days) imlinux AT gmail.com nagios-plugins-ide_smart - 1.4.3-20.fc4.i386 (11 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.ppc (11 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.x86_64 (11 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (27 days) linphone - 1.2.0-4.fc5.ppc (27 days) linphone - 1.2.0-4.fc5.x86_64 (27 days) linphone - 1.2.0-7.fc6.i386 (12 days) linphone - 1.2.0-7.fc6.ppc (12 days) linphone - 1.2.0-7.fc6.x86_64 (12 days) lmacken AT redhat.com deskbar-applet - 2.16.0-1.fc6.i386 (8 days) deskbar-applet - 2.16.0-1.fc6.ppc (8 days) deskbar-applet - 2.16.0-1.fc6.x86_64 (8 days) nphilipp AT redhat.com bzflag - 2.0.8-3.fc6.i386 (5 days) bzflag - 2.0.8-3.fc6.ppc (5 days) bzflag - 2.0.8-3.fc6.x86_64 (5 days) oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (17 days) syck-php - 0.55-9.fc5.ppc (17 days) syck-php - 0.55-9.fc5.x86_64 (17 days) petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 (2 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (2 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (2 days) ghc642-gtk2hs - 0.9.10-4.fc6.i386 (2 days) ghc642-gtk2hs - 0.9.10-4.fc6.ppc (2 days) ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 (2 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 (2 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc (2 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 (2 days) qspencer AT ieee.org octave-forge - 2006.07.09-7.fc6.i386 (5 days) octave-forge - 2006.07.09-7.fc6.ppc (5 days) octave-forge - 2006.07.09-7.fc6.x86_64 (5 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (7 days) redhat-bugzilla AT camperquake.de audacious - 1.1.2-2.fc6.i386 (5 days) audacious - 1.1.2-2.fc6.i386 (5 days) audacious - 1.1.2-2.fc6.ppc (5 days) audacious - 1.1.2-2.fc6.x86_64 (5 days) stickster AT gmail.com drivel - 2.1.0-0.3.20060527cvs.fc6.i386 (5 days) drivel - 2.1.0-0.3.20060527cvs.fc6.ppc (5 days) drivel - 2.1.0-0.3.20060527cvs.fc6.x86_64 (5 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- audacious-1.1.2-2.fc6.ppc requires libcurl.so.3 bzflag-2.0.8-3.fc6.ppc requires libcurl.so.3 centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 deskbar-applet-2.16.0-1.fc6.ppc requires libedataserver-1.2.so.7 drivel-2.1.0-0.3.20060527cvs.fc6.ppc requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 git-core-1.4.2.4-1.fc6.ppc requires libcurl.so.3 gnomesword-2.1.6-5.fc6.ppc requires libcurl.so.3 icecast-2.3.1-3.fc6.ppc requires libcurl.so.3 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 octave-forge-2006.07.09-7.fc6.ppc requires libcurl.so.3 rtorrent-0.6.2-4.fc6.ppc requires libcurl.so.3 sblim-wbemcli-1.5.1-4.fc6.ppc requires libcurl.so.3 streamtuner-0.99.99-13.fc6.ppc requires libcurl.so.3 sword-1.5.8-10.fc6.ppc requires libcurl.so.3 sylpheed-claws-plugins-gtkhtml2-viewer-2.5.2-4.fc6.ppc requires libcurl.so.3 sylpheed-claws-plugins-rssyl-2.5.2-4.fc6.ppc requires libcurl.so.3 sylpheed-claws-plugins-vcalendar-2.5.2-4.fc6.ppc requires libcurl.so.3 xmlrpc-c-1.06.05-2.fc6.ppc requires libcurl.so.3 xmlrpc-c-apps-1.06.05-2.fc6.ppc requires libcurl.so.3 xmms-scrobbler-0.3.8.1-2.fc6.ppc requires libcurl.so.3 xmoto-0.2.0-1.fc6.ppc requires libcurl.so.3 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- audacious-1.1.2-2.fc6.i386 requires libcurl.so.3 audacious-1.1.2-2.fc6.x86_64 requires libcurl.so.3()(64bit) bzflag-2.0.8-3.fc6.x86_64 requires libcurl.so.3()(64bit) centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) deskbar-applet-2.16.0-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) drivel-2.1.0-0.3.20060527cvs.fc6.x86_64 requires libcurl.so.3()(64bit) ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 git-core-1.4.2.4-1.fc6.x86_64 requires libcurl.so.3()(64bit) gnomesword-2.1.6-5.fc6.x86_64 requires libcurl.so.3()(64bit) icecast-2.3.1-3.fc6.x86_64 requires libcurl.so.3()(64bit) libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) octave-forge-2006.07.09-7.fc6.x86_64 requires libcurl.so.3()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 rtorrent-0.6.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) sblim-wbemcli-1.5.1-4.fc6.x86_64 requires libcurl.so.3()(64bit) streamtuner-0.99.99-13.fc6.i386 requires libcurl.so.3 streamtuner-0.99.99-13.fc6.x86_64 requires libcurl.so.3()(64bit) sword-1.5.8-10.fc6.i386 requires libcurl.so.3 sword-1.5.8-10.fc6.x86_64 requires libcurl.so.3()(64bit) sylpheed-claws-plugins-gtkhtml2-viewer-2.5.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) sylpheed-claws-plugins-rssyl-2.5.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) sylpheed-claws-plugins-vcalendar-2.5.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) xmlrpc-c-1.06.05-2.fc6.i386 requires libcurl.so.3 xmlrpc-c-1.06.05-2.fc6.x86_64 requires libcurl.so.3()(64bit) xmlrpc-c-apps-1.06.05-2.fc6.x86_64 requires libcurl.so.3()(64bit) xmms-scrobbler-0.3.8.1-2.fc6.x86_64 requires libcurl.so.3()(64bit) xmoto-0.2.0-1.fc6.x86_64 requires libcurl.so.3()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- audacious-1.1.2-2.fc6.i386 requires libcurl.so.3 bzflag-2.0.8-3.fc6.i386 requires libcurl.so.3 centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 deskbar-applet-2.16.0-1.fc6.i386 requires libedataserver-1.2.so.7 drivel-2.1.0-0.3.20060527cvs.fc6.i386 requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 git-core-1.4.2.4-1.fc6.i386 requires libcurl.so.3 gnomesword-2.1.6-5.fc6.i386 requires libcurl.so.3 icecast-2.3.1-3.fc6.i386 requires libcurl.so.3 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 octave-forge-2006.07.09-7.fc6.i386 requires libcurl.so.3 rtorrent-0.6.2-4.fc6.i386 requires libcurl.so.3 sblim-wbemcli-1.5.1-4.fc6.i386 requires libcurl.so.3 streamtuner-0.99.99-13.fc6.i386 requires libcurl.so.3 sword-1.5.8-10.fc6.i386 requires libcurl.so.3 sylpheed-claws-plugins-gtkhtml2-viewer-2.5.2-4.fc6.i386 requires libcurl.so.3 sylpheed-claws-plugins-rssyl-2.5.2-4.fc6.i386 requires libcurl.so.3 sylpheed-claws-plugins-vcalendar-2.5.2-4.fc6.i386 requires libcurl.so.3 xmlrpc-c-1.06.05-2.fc6.i386 requires libcurl.so.3 xmlrpc-c-apps-1.06.05-2.fc6.i386 requires libcurl.so.3 xmms-scrobbler-0.3.8.1-2.fc6.i386 requires libcurl.so.3 xmoto-0.2.0-1.fc6.i386 requires libcurl.so.3 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) sysprof-1.0.5-1.fc6.x86_64 requires kmod-sysprof >= 0:1.0.5 Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.i386 requires libortp.so.2 sysprof-1.0.5-1.fc6.i386 requires kmod-sysprof >= 0:1.0.5 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.ppc requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.x86_64 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.i386 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 From jnovy at redhat.com Mon Nov 6 08:59:14 2006 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 06 Nov 2006 09:59:14 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-05 In-Reply-To: <20061105190203.20080.59561@extras64.linux.duke.edu> References: <20061105190203.20080.59561@extras64.linux.duke.edu> Message-ID: <1162803554.2267.5.camel@redhat.usu> Hi, I'm going to rebuild Extras packages dependent on old libcurl.3 today to not to see Extras broken forewer ;-) All Core ones are already rebuilt. If you are a maintainer of one of these packages and don't want to have your package rebuilt for some reason, then drop me an email. Jindrich > Broken packages in fedora-extras-development-i386: > ---------------------------------------------------------------------- > audacious-1.1.2-2.fc6.i386 requires libcurl.so.3 > bzflag-2.0.8-3.fc6.i386 requires libcurl.so.3 > centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 > drivel-2.1.0-0.3.20060527cvs.fc6.i386 requires libcurl.so.3 > git-core-1.4.2.4-1.fc6.i386 requires libcurl.so.3 > gnomesword-2.1.6-5.fc6.i386 requires libcurl.so.3 > icecast-2.3.1-3.fc6.i386 requires libcurl.so.3 > octave-forge-2006.07.09-7.fc6.i386 requires libcurl.so.3 > rtorrent-0.6.2-4.fc6.i386 requires libcurl.so.3 > sblim-wbemcli-1.5.1-4.fc6.i386 requires libcurl.so.3 > streamtuner-0.99.99-13.fc6.i386 requires libcurl.so.3 > sword-1.5.8-10.fc6.i386 requires libcurl.so.3 > sylpheed-claws-plugins-gtkhtml2-viewer-2.5.2-4.fc6.i386 requires libcurl.so.3 > sylpheed-claws-plugins-rssyl-2.5.2-4.fc6.i386 requires libcurl.so.3 > sylpheed-claws-plugins-vcalendar-2.5.2-4.fc6.i386 requires libcurl.so.3 > xmlrpc-c-1.06.05-2.fc6.i386 requires libcurl.so.3 > xmlrpc-c-apps-1.06.05-2.fc6.i386 requires libcurl.so.3 > xmms-scrobbler-0.3.8.1-2.fc6.i386 requires libcurl.so.3 > xmoto-0.2.0-1.fc6.i386 requires libcurl.so.3 -- Jindrich Novy , http://people.redhat.com/jnovy/ (o_ _o) //\ The worst evil in the world is refusal to think. //\ V_/_ _\_V From mtasaka at ioa.s.u-tokyo.ac.jp Mon Nov 6 14:57:59 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 06 Nov 2006 23:57:59 +0900 Subject: rpms/gnupg2/devel .cvsignore, 1.15, 1.16 gnupg2.spec, 1.54, 1.55 sources, 1.17, 1.18 In-Reply-To: <200611061317.kA6DHGxf018398@cvs-int.fedora.redhat.com> References: <200611061317.kA6DHGxf018398@cvs-int.fedora.redhat.com> Message-ID: <454F4D77.4050603@ioa.s.u-tokyo.ac.jp> Rex Dieter (rdieter) wrote: > Author: rdieter > > Update of /cvs/extras/rpms/gnupg2/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv18378 > > Modified Files: > .cvsignore gnupg2.spec sources > Log Message: > * Mon Nov 06 2006 Rex Dieter 1.9.95-1 > - 1.9.95 > Well, I see the following. Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= gnupg2 i386 1.9.95-1.fc7 buildsys-extras 2.1 M Transaction Summary ============================================================================= Install 0 Package(s) Update 16 Package(s) Remove 0 Package(s) Finished Transaction Test Transaction Check Error: file /usr/share/gnupg/FAQ from install of gnupg2-1.9.95-1.fc7 conflicts with file from package gnupg-1.4.5-5 file /usr/share/gnupg/faq.html from install of gnupg2-1.9.95-1.fc7 conflicts with file from package gnupg-1.4.5-5 Thanks in advance. Mamoru Tasaka From rdieter at math.unl.edu Mon Nov 6 16:56:12 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 06 Nov 2006 10:56:12 -0600 Subject: rpms/gnupg2/devel .cvsignore, 1.15, 1.16 gnupg2.spec, 1.54, 1.55 sources, 1.17, 1.18 References: <200611061317.kA6DHGxf018398@cvs-int.fedora.redhat.com> <454F4D77.4050603@ioa.s.u-tokyo.ac.jp> Message-ID: Mamoru Tasaka wrote: > Transaction Check Error: ? file /usr/share/gnupg/FAQ from install of > gnupg2-1.9.95-1.fc7 conflicts with file from package gnupg-1.4.5-5 > file /usr/share/gnupg/faq.html from install of gnupg2-1.9.95-1.fc7 > conflicts with file from package gnupg-1.4.5-5 Thanks, fixed in gnupg2-1.9.95-2 -- Rex From michel.salim at gmail.com Mon Nov 6 18:21:58 2006 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 6 Nov 2006 13:21:58 -0500 Subject: Further to the Mono discussion: review request for vala Message-ID: <883cfe6d0611061021h7b37dd24sad8e496581da9942@mail.gmail.com> There is some concern over the future status of the Mono stack in Fedora, given the Novell-Microsoft agreement. Developers who like C# as a language might be interested in exploring this new 'language', Vala: http://vala.paldo.org. Vala is a language with C#-like syntax, built around GObject. The compiler generates C code that can then be compiled against the standard GNOME libraries as usual. One of the text editors for GNOME, Scratchpad, has already been ported from C# to Vala: http://dborg.wordpress.com/2006/09/27/scratchpad-meets-vala/ If you're interested, please take the time and review the Vala package for Fedora Extras: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214227 Many thanks, -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From buildsys at fedoraproject.org Mon Nov 6 18:23:37 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 6 Nov 2006 13:23:37 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-06 Message-ID: <20061106182337.53CF815212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 32 PyQt-qscintilla-3.16-7.fc7 abcMIDI-20061103-1.fc7 abiword-2.4.6-1.fc7 asymptote-1.18-1.fc7 audacious-1.1.2-4.fc7 bluefish-1.0.7-1.fc7 bzflag-2.0.8-4.fc7 clamav-0.88.6-1.fc7 ctapi-cyberjack-2.0.12-1.fc7 deskbar-applet-2.16.1-3.fc7 drivel-2.1.0-0.4.20060527cvs.fc7 git-1.4.2.4-2.fc7 gnupg2-1.9.95-1.fc7 icecast-2.3.1-4.fc7 jd-1.8.0-0.5.cvs061106.fc7 libassa-3.4.2-4 libtasn1-0.3.6-1.fc7 lighttpd-1.4.13-3.fc7 mediawiki-1.8.2-5.fc7 mock-0.6.8-4.fc7 opencdk-0.5.11-1.fc7 perl-Data-Compare-0.14-2.fc7 rtorrent-0.6.2-5.fc7 sblim-wbemcli-1.5.1-5.fc7 sparse-0-0.1.20061026git.fc7 streamtuner-0.99.99-14.fc7 sylpheed-claws-plugins-2.5.2-5.fc7 xaos-3.2.2-1.fc7 xdg-utils-1.0.1-1.fc7 xmlrpc-c-1.06.05-3.fc7 xmms-scrobbler-0.3.8.1-3.fc7 xmoto-0.2.0-2.fc7 Packages built and released for Fedora Extras 6: 18 PyQt-qscintilla-3.16-7.fc6 abcMIDI-20061103-1.fc6 abiword-2.4.6-1.fc6 asymptote-1.18-1.fc6 bluefish-1.0.7-1.fc6 clamav-0.88.6-1.fc6 ctapi-cyberjack-2.0.12-1.fc6 libassa-3.4.2-4 libtasn1-0.3.6-1.fc6 lighttpd-1.4.13-3.fc6 mock-0.6.8-4.fc6 opencdk-0.5.11-1.fc6 perl-Data-Compare-0.14-1.fc6 ruby-bdb-0.5.9-6.fc6 sparse-0-0.1.20061026git.fc6 xaos-3.2.2-1.fc6 xdg-utils-1.0.1-1.fc6 yakuake-2.7.5-4.fc6 Packages built and released for Fedora Extras 5: 16 PyQt-qscintilla-3.15-4.fc5 abcMIDI-20061103-1.fc5 abiword-2.4.6-1.fc5 asymptote-1.18-1.fc5 bluefish-1.0.7-1.fc5 clamav-0.88.6-1.fc5 libtasn1-0.3.6-1.fc5 lighttpd-1.4.13-3.fc5 mock-0.6.8-4.fc5 opencdk-0.5.11-1.fc5 perl-Data-Compare-0.14-1.fc5 ruby-bdb-0.5.9-6.fc5 sparse-0-0.1.20061026git.fc5 xaos-3.2.2-1.fc5 xdg-utils-1.0.1-1.fc5 yakuake-2.7.5-4.fc5 Packages built and released for Fedora Extras 4: 5 abiword-2.4.6-1.fc4 asymptote-1.18-1.fc4 bluefish-1.0.7-1.fc4 clamav-0.88.6-1.fc4 xdg-utils-1.0.1-1.fc4 Packages built and released for Fedora Extras 3: 1 clamav-0.88.6-1.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From michel.salim at gmail.com Mon Nov 6 18:21:58 2006 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 6 Nov 2006 13:21:58 -0500 Subject: Further to the Mono discussion: review request for vala Message-ID: <883cfe6d0611061021h7b37dd24sad8e496581da9942@mail.gmail.com> There is some concern over the future status of the Mono stack in Fedora, given the Novell-Microsoft agreement. Developers who like C# as a language might be interested in exploring this new 'language', Vala: http://vala.paldo.org. Vala is a language with C#-like syntax, built around GObject. The compiler generates C code that can then be compiled against the standard GNOME libraries as usual. One of the text editors for GNOME, Scratchpad, has already been ported from C# to Vala: http://dborg.wordpress.com/2006/09/27/scratchpad-meets-vala/ If you're interested, please take the time and review the Vala package for Fedora Extras: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214227 Many thanks, -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From jeff at ocjtech.us Mon Nov 6 19:32:54 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Mon, 06 Nov 2006 13:32:54 -0600 Subject: Further to the Mono discussion: review request for vala In-Reply-To: <883cfe6d0611061021h7b37dd24sad8e496581da9942@mail.gmail.com> References: <883cfe6d0611061021h7b37dd24sad8e496581da9942@mail.gmail.com> Message-ID: <1162841574.3321.5.camel@lt21223.campus.dmacc.edu> On Mon, 2006-11-06 at 13:21 -0500, Michel Salim wrote: > > If you're interested, please take the time and review the Vala package > for Fedora Extras: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214227 Done... Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Mon Nov 6 19:35:06 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 6 Nov 2006 20:35:06 +0100 Subject: Extras + Legacy or not? Message-ID: <20061106203506.d02d897d.bugs.michael@gmx.net> http://fedoraproject.org/wiki/Extras/Schedule/ActivateLegacyInBuildroots Are Fedora Legacy Updates for FC3 and FC4 active in the Fedora Extras buildsys or not? Here, ppc is missing: http://download.fedoralegacy.org/fedora/4/updates/ Is one supposed to enable Fedora Core Released Updates in addition to Fedora Legacy Updates? It seems so (looking at the package legacy-yumconf-4-2.fc4.noarch.rpm) But what does the buildsys do? (The reason I ask is that I want repoclosure to use the same combination of repositories.) From jkeating at redhat.com Mon Nov 6 19:51:36 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 6 Nov 2006 14:51:36 -0500 Subject: Extras + Legacy or not? In-Reply-To: <20061106203506.d02d897d.bugs.michael@gmx.net> References: <20061106203506.d02d897d.bugs.michael@gmx.net> Message-ID: <200611061451.36349.jkeating@redhat.com> On Monday 06 November 2006 14:35, Michael Schwendt wrote: > re Fedora Legacy Updates for FC3 and FC4 active in the Fedora Extras > buildsys or not? > > Here, ppc is missing: > > ? http://download.fedoralegacy.org/fedora/4/updates/ > > Is one supposed to enable Fedora Core Released Updates in addition to > Fedora Legacy Updates? It seems so (looking at the package > legacy-yumconf-4-2.fc4.noarch.rpm) > > But what does the buildsys do? > > (The reason I ask is that I want repoclosure to use the same combination > of repositories.) Legacy is not quite yet using the Extras build system. We're working up toward that. And currently we haven't produced any ppc updates, when we make the move over, we'd resubmit what we've released for FL4 for ppc building. Things mostly holding us up from moving is an update tool to make use of the builds that land out of Extras' plague setup. If Luke doesn't envision this happening anytime soon, we'll need a 'push' system that pushes the builds back out to legacy staging infrastructure so that Legacy can sign / push / prepare emails like we're currently doing with our own plague setup. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Mon Nov 6 19:58:53 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 6 Nov 2006 13:58:53 -0600 Subject: Extras + Legacy or not? In-Reply-To: <200611061451.36349.jkeating@redhat.com> References: <20061106203506.d02d897d.bugs.michael@gmx.net> <200611061451.36349.jkeating@redhat.com> Message-ID: <200611061358.53737.dennis@ausil.us> On Monday 06 November 2006 13:51, Jesse Keating wrote: > On Monday 06 November 2006 14:35, Michael Schwendt wrote: > > re Fedora Legacy Updates for FC3 and FC4 active in the Fedora Extras > > buildsys or not? > > > > Here, ppc is missing: > > > > ? http://download.fedoralegacy.org/fedora/4/updates/ yes the buildsystem is using legacy. i populated the ppc tree with fc4 updates. but everywhere else the tree is from legacy. > > Is one supposed to enable Fedora Core Released Updates in addition to > > Fedora Legacy Updates? It seems so (looking at the package > > legacy-yumconf-4-2.fc4.noarch.rpm) > > > > But what does the buildsys do? > > > > (The reason I ask is that I want repoclosure to use the same combination > > of repositories.) > Legacy is not quite yet using the Extras build system. We're working up > toward that. And currently we haven't produced any ppc updates, when we > make the move over, we'd resubmit what we've released for FL4 for ppc > building. > > Things mostly holding us up from moving is an update tool to make use of > the builds that land out of Extras' plague setup. If Luke doesn't envision > this happening anytime soon, we'll need a 'push' system that pushes the > builds back out to legacy staging infrastructure so that Legacy can sign / > push / prepare emails like we're currently doing with our own plague setup. we can make use of extras push scripts or just rsync legacy updates to your existing staging location I guess the main difference between extras and legacy is legacy has one email per package and extras one email per push -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v From buildsys at fedoraproject.org Mon Nov 6 20:32:34 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 06 Nov 2006 20:32:34 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-06 Message-ID: <20061106203234.28151.36304@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 (6 days) centericq - 4.21.0-8.fc6.ppc (6 days) centericq - 4.21.0-8.fc6.x86_64 (6 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (9 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (9 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (9 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (9 days) orange - 0.3-3.cvs20051118.fc6.i386 (13 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (37 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (37 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (37 days) dakingun AT gmail.com gnomesword - 2.1.6-5.fc6.i386 (6 days) gnomesword - 2.1.6-5.fc6.ppc (6 days) gnomesword - 2.1.6-5.fc6.x86_64 (6 days) sword - 1.5.8-10.fc6.i386 (6 days) sword - 1.5.8-10.fc6.i386 (6 days) sword - 1.5.8-10.fc6.ppc (6 days) sword - 1.5.8-10.fc6.x86_64 (6 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (52 days) plague - 0.4.4.1-2.fc3.noarch (52 days) plague - 0.4.4.1-2.fc4.noarch (52 days) plague - 0.4.4.1-2.fc4.noarch (52 days) plague - 0.4.4.1-2.fc4.noarch (52 days) denis AT poolshark.org galeon - 2.0.0-1.fc3.i386 galeon - 2.0.0-1.fc3.x86_64 giallu AT gmail.com sysprof - 1.0.5-1.fc6.i386 (3 days) sysprof - 1.0.5-1.fc6.x86_64 (3 days) imlinux AT gmail.com nagios-plugins-ide_smart - 1.4.3-20.fc4.i386 (12 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.ppc (12 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.x86_64 (12 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (28 days) linphone - 1.2.0-4.fc5.ppc (28 days) linphone - 1.2.0-4.fc5.x86_64 (28 days) linphone - 1.2.0-7.fc6.i386 (13 days) linphone - 1.2.0-7.fc6.ppc (13 days) linphone - 1.2.0-7.fc6.x86_64 (13 days) oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (18 days) syck-php - 0.55-9.fc5.ppc (18 days) syck-php - 0.55-9.fc5.x86_64 (18 days) petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 (3 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (3 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (3 days) ghc642-gtk2hs - 0.9.10-4.fc6.i386 (3 days) ghc642-gtk2hs - 0.9.10-4.fc6.ppc (3 days) ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 (3 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 (3 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc (3 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 (3 days) qspencer AT ieee.org octave-forge - 2006.07.09-7.fc6.i386 (6 days) octave-forge - 2006.07.09-7.fc6.ppc (6 days) octave-forge - 2006.07.09-7.fc6.x86_64 (6 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (8 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 gnomesword-2.1.6-5.fc6.ppc requires libcurl.so.3 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 octave-forge-2006.07.09-7.fc6.ppc requires libcurl.so.3 sword-1.5.8-10.fc6.ppc requires libcurl.so.3 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 gnomesword-2.1.6-5.fc6.x86_64 requires libcurl.so.3()(64bit) libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) octave-forge-2006.07.09-7.fc6.x86_64 requires libcurl.so.3()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 sword-1.5.8-10.fc6.i386 requires libcurl.so.3 sword-1.5.8-10.fc6.x86_64 requires libcurl.so.3()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 gnomesword-2.1.6-5.fc6.i386 requires libcurl.so.3 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 octave-forge-2006.07.09-7.fc6.i386 requires libcurl.so.3 sword-1.5.8-10.fc6.i386 requires libcurl.so.3 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) sysprof-1.0.5-1.fc6.x86_64 requires kmod-sysprof >= 0:1.0.5 Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.i386 requires libortp.so.2 sysprof-1.0.5-1.fc6.i386 requires kmod-sysprof >= 0:1.0.5 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.ppc requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.x86_64 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.i386 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- galeon-2.0.0-1.fc3.x86_64 requires mozilla = 37:1.7.12 plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- galeon-2.0.0-1.fc3.i386 requires mozilla = 37:1.7.12 plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: jeff AT ocjtech.us package: linphone - 1.2.0-4.fc5.ppc from fedora-extras-5-ppc unresolved deps: libortp.so.2 package: linphone - 1.2.0-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libortp.so.2()(64bit) package: linphone - 1.2.0-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libortp.so.2 ====================================================================== New report for: denis AT poolshark.org package: galeon - 2.0.0-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: mozilla = 37:1.7.12 package: galeon - 2.0.0-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: mozilla = 37:1.7.12 From jkeating at redhat.com Mon Nov 6 20:51:37 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 6 Nov 2006 15:51:37 -0500 Subject: Extras + Legacy or not? In-Reply-To: <200611061358.53737.dennis@ausil.us> References: <20061106203506.d02d897d.bugs.michael@gmx.net> <200611061451.36349.jkeating@redhat.com> <200611061358.53737.dennis@ausil.us> Message-ID: <200611061551.37532.jkeating@redhat.com> On Monday 06 November 2006 14:58, Dennis Gilmore wrote: > we can make use of extras push scripts ?or ?just rsync ?legacy updates to > your existing staging location ?I guess the main difference between extras > and legacy ?is legacy has one email per package ?and extras one email per > push Well and where to put things. Legacy now has the authority to publish our updates into the existing updates/ directories on the master mirror, but getting the content there is a challenge. And yeah, the email is one per package, and there is extra information about that package, like why we're issuing the update. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From andreas.bierfert at lowlatency.de Tue Nov 7 01:37:42 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Tue, 7 Nov 2006 02:37:42 +0100 Subject: wine apps menu entries In-Reply-To: <13dbfe4f0611040610w70656035p1cce53b3e08e8d8a@mail.gmail.com> References: <20061104115930.673732ef@alkaid.a.lan> <13dbfe4f0611040322h68383ecamf12eb353d00e9ae6@mail.gmail.com> <20061104123918.506c627f@alkaid.a.lan> <13dbfe4f0611040610w70656035p1cce53b3e08e8d8a@mail.gmail.com> Message-ID: <20061107023742.47c0932f@alkaid.a.lan> On Sat, 4 Nov 2006 15:10:21 +0100 "Chitlesh GOORAH" wrote: > On 11/4/06, Andreas Bierfert < hidden > wrote: > > Could you be more precise which ones are missing so I can take a look. > > winemine > notepad > regedit > wine file > wine configuration > wine help > wine software uninstaller > Darn you were talking about icons. Missing icons is an issue I reported upstream so we will see when and if they get back with something. Up till then I will leave the entries without icons. As nobody voted against having a wine submenu I will include this with the next wine upgrade. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From giallu at gmail.com Tue Nov 7 09:49:25 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 7 Nov 2006 10:49:25 +0100 Subject: Democracy player anyone? Message-ID: Hi, I saw the democracy player [1] was submitted for review on livna[2], but now that xine-lib landed in Extras, we could include it directly here. Is there anyone already working on this? If not, I have an older spec file I could bash in shape for review. cheers Gianluca [1] http://www.getdemocracy.org [2] http://bugzilla.livna.org/show_bug.cgi?id=911 From bugs.michael at gmx.net Tue Nov 7 12:06:36 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 7 Nov 2006 13:06:36 +0100 Subject: rpms/granule/devel granule.spec,1.2,1.3 In-Reply-To: <200611070347.kA73lmAP009552@cvs-int.fedora.redhat.com> References: <200611070347.kA73lmAP009552@cvs-int.fedora.redhat.com> Message-ID: <20061107130636.80be1b60.bugs.michael@gmx.net> On Mon, 6 Nov 2006 20:47:48 -0700, Vladislav Grinchenko (vlg) wrote: > Author: vlg > > Update of /cvs/extras/rpms/granule/devel > Log Message: > Two tags of the same name collide? Yes, since what they point to must be unique in CVS and when published in form of packages. > +* Wed Nov 06 2006 Vladislav Grinchenko - 1.2.3-4 > - Removed libtool call. That doesn't match the applied changes, however. From ndbecker2 at gmail.com Tue Nov 7 12:12:14 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 07 Nov 2006 07:12:14 -0500 Subject: Democracy player anyone? References: Message-ID: Gianluca Sforna wrote: > Hi, > I saw the democracy player [1] was submitted for review on livna[2], > but now that xine-lib landed in Extras, we could include it directly > here. > > Is there anyone already working on this? > If not, I have an older spec file I could bash in shape for review. > > cheers > Gianluca > > [1] http://www.getdemocracy.org > [2] http://bugzilla.livna.org/show_bug.cgi?id=911 > Current release crashes on start on x86_64. Wait for next. From giallu at gmail.com Tue Nov 7 12:19:58 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 7 Nov 2006 13:19:58 +0100 Subject: Democracy player anyone? In-Reply-To: References: Message-ID: On 11/7/06, Neal Becker wrote: > Current release crashes on start on x86_64. Wait for next. > well. I just tested my package and it also crashes here (centrino laptop running FC6) but had no time to investigate why. From michel.salim at gmail.com Tue Nov 7 14:47:00 2006 From: michel.salim at gmail.com (Michel Salim) Date: Tue, 7 Nov 2006 09:47:00 -0500 Subject: Democracy player anyone? In-Reply-To: References: Message-ID: <883cfe6d0611070647l665292cfq428bc93a8e17a1a7@mail.gmail.com> On 11/7/06, Neal Becker wrote: > Gianluca Sforna wrote: > > > Hi, > > I saw the democracy player [1] was submitted for review on livna[2], > > but now that xine-lib landed in Extras, we could include it directly > > here. > > > > Is there anyone already working on this? > > If not, I have an older spec file I could bash in shape for review. > > > > cheers > > Gianluca > > > > [1] http://www.getdemocracy.org > > [2] http://bugzilla.livna.org/show_bug.cgi?id=911 > > > > Current release crashes on start on x86_64. Wait for next. > How about starting with the previous release, if that works cross-platform? -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From somlo at cmu.edu Tue Nov 7 15:10:36 2006 From: somlo at cmu.edu (Gabriel L. Somlo) Date: Tue, 7 Nov 2006 10:10:36 -0500 Subject: Anyone remember aumix ? Message-ID: <20061107151036.GA5208@hedwig.net.cmu.edu> When I switched from FC2 to FC4, aumix was orphaned, so I just built my own rpm and didn't think much about it. Now that I'm moving from FC4 to FC6, I'd be interested in a command-line and/or curses based mixer that would go with a minimalist setup (e.g., with something like the wmx window manager :) ). Is there another text-based mixer in FC or Extras already that I can use ? If not, does anyone remember the story behind aumix, and why it doesn't show up on the Orphans or Retired pages in the wiki anymore ? Thanks much, Gabriel From notting at redhat.com Tue Nov 7 15:15:57 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Nov 2006 10:15:57 -0500 Subject: Anyone remember aumix ? In-Reply-To: <20061107151036.GA5208@hedwig.net.cmu.edu> References: <20061107151036.GA5208@hedwig.net.cmu.edu> Message-ID: <20061107151557.GA23256@nostromo.devel.redhat.com> Gabriel L. Somlo (somlo at cmu.edu) said: > When I switched from FC2 to FC4, aumix was orphaned, so I just built > my own rpm and didn't think much about it. > > Now that I'm moving from FC4 to FC6, I'd be interested in a > command-line and/or curses based mixer that would go with a minimalist > setup (e.g., with something like the wmx window manager :) ). > > Is there another text-based mixer in FC or Extras already that I can > use ? If not, does anyone remember the story behind aumix, and why it > doesn't show up on the Orphans or Retired pages in the wiki anymore ? alsamixer? Bill From adrian at lisas.de Tue Nov 7 16:09:04 2006 From: adrian at lisas.de (Adrian Reber) Date: Tue, 7 Nov 2006 17:09:04 +0100 Subject: Orphaning zope, plone, mpc and gmpc In-Reply-To: References: Message-ID: <20061107160904.GA14965@lisas.de> On Sun, Nov 05, 2006 at 07:29:59PM +0100, Aurelien Bompard wrote: > I'm also orphaning mpc and gmpc, client applications for the Music Player > Daemon. The mpd can't be in Extras because it ships mp3 decoding code, and > has no plugin infrastructure to split it like the xine-lib package. > I don't use mpd anymore, so I'm not interested in maintaining the client > apps. I will take mpc and gmpc. Adrian From Christian.Iseli at licr.org Tue Nov 7 16:54:12 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 7 Nov 2006 17:54:12 +0100 Subject: Anyone remember aumix ? In-Reply-To: <20061107151036.GA5208@hedwig.net.cmu.edu> References: <20061107151036.GA5208@hedwig.net.cmu.edu> Message-ID: <20061107175412.4e3c192c@ludwig-alpha.unil.ch> On Tue, 7 Nov 2006 10:10:36 -0500, Gabriel L. Somlo wrote: > If not, does anyone remember the story behind aumix, and why it > doesn't show up on the Orphans or Retired pages in the wiki anymore ? FWIW, aumix is still in Core's CVS repo. The last changelog entry is: * Thu Dec 23 2004 Mike A. Harris 2.8-12 - Updated aumix-fix-crackrock.patch to include errno.h, or build fails now Probably no reason why I couldn't be submitted to Extras... C From somlo at cmu.edu Tue Nov 7 17:12:05 2006 From: somlo at cmu.edu (Gabriel L. Somlo) Date: Tue, 7 Nov 2006 12:12:05 -0500 Subject: Anyone remember aumix ? In-Reply-To: <20061107175412.4e3c192c@ludwig-alpha.unil.ch> References: <20061107170034.EA25E73A7B@hormel.redhat.com> Message-ID: <20061107171205.GB5208@hedwig.net.cmu.edu> On Tue, 7 Nov 2006 17:54:12 +0100, Christian Iseli wrote: > FWIW, aumix is still in Core's CVS repo. The last changelog entry is: > * Thu Dec 23 2004 Mike A. Harris 2.8-12 > - Updated aumix-fix-crackrock.patch to include errno.h, or build fails now > > Probably no reason why I couldn't be submitted to Extras... I'll do that... alsamixer looks a tad clunky by comparison :) +----------------------------------------------------[AlsaMixer v1.0.10 (Pr | Card: Intel ICH6 | Chip: Analog Devices AD1981B | View: [Playback] Capture All | Item: Master [Off] | +--+ +--+ +--+ +--+ +--+ +--+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |##| |##| | | | | | | | | | |##| |##| | | | | | | | | | |##| |##| | | | | | | | | | |##| |##| | | | | | +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ | |MM| |MM| |OO| |MM| |OO| |MM| |MM| |MM| | +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ | 0<>0 0 65<>65 65<>65 0<>0 0<>0 | < Master >Master M Headphon Headphon PCM Line Line Jac CD +-------------------------------------------------------------------------- ess Escape to quit)]-----------------------------------------------------+ | | | | +--+ +--+ +--+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mic1 | | | | Mix | +--+ +--+ +--+ +--+ +--+ +--+ | |MM| |MM| |MM| |MM| |MM| |MM| | +--+ +--+ +--+ +--+ +--+ +--+ | 0 0 0<>0 | Mic Mic Boos Mic Sele Phone Aux Mono Out External Stereo M | -------------------------------------------------------------------------+ ...as opposed to this: aumix R0+++++++++++++++++++++++++ References: <20061107170034.EA25E73A7B@hormel.redhat.com> <20061107171205.GB5208@hedwig.net.cmu.edu> Message-ID: <20061107171440.GA24672@nostromo.devel.redhat.com> Gabriel L. Somlo (somlo at cmu.edu) said: > I'll do that... alsamixer looks a tad clunky by comparison :) Note that alsamixer is showing the actual mixer channels exposed by the driver - aumix is just exposing a set of channels that are mapped by the ALSA OSS emulation to the 'real' channels. Bill From ndbecker2 at gmail.com Tue Nov 7 17:24:06 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 07 Nov 2006 12:24:06 -0500 Subject: Democracy player anyone? References: <883cfe6d0611070647l665292cfq428bc93a8e17a1a7@mail.gmail.com> Message-ID: Michel Salim wrote: > On 11/7/06, Neal Becker > wrote: >> Gianluca Sforna wrote: >> >> > Hi, >> > I saw the democracy player [1] was submitted for review on livna[2], >> > but now that xine-lib landed in Extras, we could include it directly >> > here. >> > >> > Is there anyone already working on this? >> > If not, I have an older spec file I could bash in shape for review. >> > >> > cheers >> > Gianluca >> > >> > [1] http://www.getdemocracy.org >> > [2] http://bugzilla.livna.org/show_bug.cgi?id=911 >> > >> >> Current release crashes on start on x86_64. Wait for next. >> > How about starting with the previous release, if that works > cross-platform? > > Previous was OK On mail list, someone said they had a patch, so I figured I'd wait. From j.w.r.degoede at hhs.nl Tue Nov 7 21:14:42 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 07 Nov 2006 22:14:42 +0100 Subject: State of multilib development update In-Reply-To: <200611041633.03427.jkeating@redhat.com> References: <4541C56A.5070903@hhs.nl> <200611041037.32305.jkeating@redhat.com> <454D050A.4000605@hhs.nl> <200611041633.03427.jkeating@redhat.com> Message-ID: <4550F742.1010309@hhs.nl> Jesse Keating wrote: > On Saturday 04 November 2006 16:24, Hans de Goede wrote: >> Since when is that patch in rpm? I'm speaking from past experience, so >> this might be fixed now. > > It went in during the FC6 development cycle. I don't recall exactly when. > This indeed seems fixed now, and in a nice way too! Great! Regards, Hans From j.w.r.degoede at hhs.nl Wed Nov 8 09:21:25 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 08 Nov 2006 10:21:25 +0100 Subject: Looking for some easy to fix code (not packaging) bugs Message-ID: <4551A195.3030305@hhs.nl> Hi, As you all know by now I'm a CS teacher as my daytime job. I'm currently working on a practicum where I want students to practice with / experience debugging / fault tracing. For this I'm looking for some bugs, which are 100% reproducable (no race conditions and other hard stuff) and should be relatively easy to fix. Basicly I'm looking for code bugs where lack of time is the most important reason for not fixing them. So please report any bugs in this thread or to my private email, thanks! Regards, Hans From paul at city-fan.org Wed Nov 8 11:20:11 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 08 Nov 2006 11:20:11 +0000 Subject: Looking for some easy to fix code (not packaging) bugs In-Reply-To: <4551A195.3030305@hhs.nl> References: <4551A195.3030305@hhs.nl> Message-ID: <4551BD6B.8080805@city-fan.org> Hans de Goede wrote: > Hi, > > As you all know by now I'm a CS teacher as my daytime job. I'm currently > working on a practicum where I want students to practice with / > experience debugging / fault tracing. For this I'm looking for some > bugs, which are 100% reproducable (no race conditions and other hard > stuff) and should be relatively easy to fix. Basicly I'm looking for > code bugs where lack of time is the most important reason for not fixing > them. > > So please report any bugs in this thread or to my private email, thanks! Not sure if these are easy enough bugs but they're still open and upstream doesn't seem terribly interested: bittorrent takes an unreasonable amount of memory and has a memory leak https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204622 bittorrent is not utf-8 aware https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189295 Paul. From bugs.michael at gmx.net Wed Nov 8 11:35:20 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 8 Nov 2006 12:35:20 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-06 In-Reply-To: <20061106203234.28151.36304@extras64.linux.duke.edu> References: <20061106203234.28151.36304@extras64.linux.duke.edu> Message-ID: <20061108123520.b6b8db62.bugs.michael@gmx.net> On Mon, 06 Nov 2006 20:32:34 -0000, Fedora Extras repoclosure wrote: > New report for: denis AT poolshark.org > > package: galeon - 2.0.0-1.fc3.x86_64 from fedora-extras-3-x86_64 > unresolved deps: > mozilla = 37:1.7.12 > > package: galeon - 2.0.0-1.fc3.i386 from fedora-extras-3-i386 > unresolved deps: > mozilla = 37:1.7.12 > Verified. This is only _with_ Fedora Legacy, who have released a Mozilla 1.7.13 update in May. From dtimms at iinet.net.au Wed Nov 8 12:31:16 2006 From: dtimms at iinet.net.au (David Timms) Date: Wed, 08 Nov 2006 23:31:16 +1100 Subject: Estimate the size of extras ? Message-ID: <4551CE14.1050809@iinet.net.au> I have been talking about getting extras mirrored with some local mirror admins and was asked what space would be required for an extras mirror. My guesstimate is: one extras version ~2GB - currently two active versions two/three architectures: Hence about 2GB*2*3 = 12 GB. Would someone know a more realistic answer, or could run du -sh extras/* on their mirror and post back ? Thanks, DaveT. From buildsys at fedoraproject.org Wed Nov 8 12:34:03 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 8 Nov 2006 07:34:03 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-08 Message-ID: <20061108123403.AD68C15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 37 MegaMek-0.30.11-1.fc7 SIBsim4-0.14-1.fc7 audacious-1.1.2-7.fc7 azureus-2.5.0.0-9.fc7 bzr-0.12-1.fc7 bzrtools-0.12.2-2.fc7 dnsmasq-2.35-2.fc7 eclipse-emf-2.2.1-3.fc7 eclipse-gef-3.2.1-3.fc7 gcompris-8.2-1.fc7 gnupg2-1.9.95-2.fc7 granule-1.2.3-3 libetpan-0.48-1.fc7 mftrace-1.2.5-1.fc7 mpc-0.12.0-1.fc7 octave-forge-2006.07.09-8.fc7 openal-0.0.9-0.9.20060204cvs.fc7 perl-Class-InsideOut-1.03-1.fc7 perl-Class-MOP-0.36-1.fc7 perl-Moose-0.15-1.fc7 php-pear-Console-Getargs-1.3.3-1.fc7 php-pear-HTTP-Request-1.4.0-1.fc7 php-pear-Net-FTP-1.3.2-1.fc7 php-pear-Net-URL-1.0.14-1.fc7 php-pear-Pager-2.4.2-1.fc7 qiv-2.0-7.fc7 rssowl-1.2.2-7.fc7 scummvm-0.9.1-1.fc7 shorewall-3.2.5-1.fc7 soundconverter-0.9.3-2.fc7 sylpheed-claws-2.6.0-1.fc7 tbcload-1.4-3.20061030cvs.fc7 tclcompiler-1.5-2.20061030cvs.fc7 tile-0.7.8-1.fc7 vala-0.0.5-1.fc7 vpnc-0.3.3-13.fc7 xmms-1.2.10-29.fc7 Packages built and released for Fedora Extras 6: 24 SIBsim4-0.14-1.fc6 alex4-1.0-2.fc6 audacious-1.1.2-4.fc6 bzr-0.12-1.fc6 bzrtools-0.12.2-2.fc6 dnsmasq-2.35-2.fc6 gcompris-8.2-1.fc6 gdesklets-0.35.4-1.fc6 granule-1.2.3-3.fc6 libetpan-0.48-1.fc6 lilypond-2.8.8-1.fc6 mftrace-1.2.5-1.fc6 openal-0.0.9-0.9.20060204cvs.fc6 perl-Class-InsideOut-1.03-1.fc6 perl-Class-MOP-0.36-1.fc6 perl-Moose-0.15-1.fc6 php-pear-Console-Getargs-1.3.3-1.fc6 qiv-2.0-7.fc6 shorewall-3.2.5-1.fc6 soundconverter-0.9.3-2.fc6 sylpheed-claws-2.6.0-1.fc6 tile-0.7.8-1.fc6 vpnc-0.3.3-13.fc6 xmms-1.2.10-29.fc6 Packages built and released for Fedora Extras 5: 18 SIBsim4-0.14-1.fc5 alex4-1.0-2.fc5 bzr-0.12-1.fc5 bzrtools-0.12.2-2.fc5 dnsmasq-2.35-2.fc5 gcompris-8.2-1.fc5 gdesklets-0.35.4-1.fc5 libetpan-0.48-1.fc5 lilypond-2.8.8-1.fc5 mftrace-1.2.5-1.fc5 openal-0.0.9-0.7.20060204cvs.fc5 perl-Class-InsideOut-1.03-1.fc5 perl-Class-MOP-0.36-1.fc5 perl-Moose-0.15-1.fc5 php-pear-Console-Getargs-1.3.3-1.fc5 shorewall-3.2.5-1.fc5 soundconverter-0.9.3-2.fc5 sylpheed-claws-2.6.0-1.fc5 Packages built and released for Fedora Extras 4: 6 gdesklets-0.35.4-1.fc4 libetpan-0.48-1.fc4 openal-0.0.9-0.6.20060204cvs.fc4 shorewall-3.2.5-1.fc4 soundconverter-0.9.3-2.fc4 sylpheed-claws-2.6.0-1.fc4 Packages built and released for Fedora Extras 3: 2 libetpan-0.48-1.fc3 openal-0.0.9-0.6.20060204cvs.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From adrian at lisas.de Wed Nov 8 12:40:17 2006 From: adrian at lisas.de (Adrian Reber) Date: Wed, 8 Nov 2006 13:40:17 +0100 Subject: Estimate the size of extras ? In-Reply-To: <4551CE14.1050809@iinet.net.au> References: <4551CE14.1050809@iinet.net.au> Message-ID: <20061108124016.GA5639@lisas.de> On Wed, Nov 08, 2006 at 11:31:16PM +1100, David Timms wrote: > I have been talking about getting extras mirrored with some local mirror > admins and was asked what space would be required for an extras mirror. > > My guesstimate is: > one extras version ~2GB > - currently two active versions > two/three architectures: > > Hence about 2GB*2*3 = 12 GB. > > Would someone know a more realistic answer, or could run du -sh extras/* > on their mirror and post back ? $ du -sh extras/* 7.1G extras/3 23G extras/4 31G extras/5 22G extras/6 4.1G extras/development This is with debuginfo packages. Adrian From limb at jcomserv.net Wed Nov 8 12:40:19 2006 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 8 Nov 2006 06:40:19 -0600 (CST) Subject: Estimate the size of extras ? In-Reply-To: <4551CE14.1050809@iinet.net.au> References: <4551CE14.1050809@iinet.net.au> Message-ID: <35677.65.192.24.190.1162989619.squirrel@mail.jcomserv.net> My FC6 mirror with current updates. . . 3.2G base 4.4G extras 808M updates > I have been talking about getting extras mirrored with some local mirror > admins and was asked what space would be required for an extras mirror. > > My guesstimate is: > one extras version ~2GB > - currently two active versions > two/three architectures: > > Hence about 2GB*2*3 = 12 GB. > > Would someone know a more realistic answer, or could run du -sh extras/* > on their mirror and post back ? > > Thanks, DaveT. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- novus ordo absurdum From rtlm10 at gmail.com Wed Nov 8 13:24:56 2006 From: rtlm10 at gmail.com (Russell Harrison) Date: Wed, 8 Nov 2006 08:24:56 -0500 Subject: Looking for some easy to fix code (not packaging) bugs In-Reply-To: <4551A195.3030305@hhs.nl> References: <4551A195.3030305@hhs.nl> Message-ID: <1ed4a0130611080524l2989ccb6p4ca3d50ddf18b12f@mail.gmail.com> On 11/8/06, Hans de Goede wrote: > > Hi, > > As you all know by now I'm a CS teacher as my daytime job. I'm currently > working on a practicum where I want students to practice with / experience > debugging / fault tracing. For this I'm looking for some bugs, which are > 100% reproducable (no race conditions and other hard stuff) and should be > relatively easy to fix. Basicly I'm looking for code bugs where lack of time > is the most important reason for not fixing them. > > You may want to look at the GnomeLove initiative. >From their own introduction: *"GnomeLove is an initiative that aims to help people who want to get started contributing to GNOME. This page offers a collection of links to useful resources for aspiring developers, testers, documenters or simply GNOME enthusiasts."* The initiative is focused towards smaller projects / bugs that need some "Love" in Gnome. You should be able to find some bugs there that are fairly simple to knock out, as well as some beginner projects that no one else seems to want to do. RTLM -------------- next part -------------- An HTML attachment was scrubbed... URL: From buildsys at fedoraproject.org Wed Nov 8 13:42:18 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 08 Nov 2006 13:42:18 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-08 Message-ID: <20061108134218.10551.68590@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 (8 days) centericq - 4.21.0-8.fc6.ppc (8 days) centericq - 4.21.0-8.fc6.x86_64 (8 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (11 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (11 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (11 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (11 days) orange - 0.3-3.cvs20051118.fc6.i386 (15 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (39 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (39 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (39 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc5.i386 sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc5.ppc sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc5.x86_64 sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc6.i386 sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc6.ppc sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc6.x86_64 sylpheed-claws-plugins-etpan-privacy - 2.5.2-5.fc7.i386 sylpheed-claws-plugins-etpan-privacy - 2.5.2-5.fc7.ppc sylpheed-claws-plugins-etpan-privacy - 2.5.2-5.fc7.x86_64 dakingun AT gmail.com gnomesword - 2.1.6-5.fc6.i386 (8 days) gnomesword - 2.1.6-5.fc6.ppc (8 days) gnomesword - 2.1.6-5.fc6.x86_64 (8 days) sword - 1.5.8-10.fc6.i386 (8 days) sword - 1.5.8-10.fc6.i386 (8 days) sword - 1.5.8-10.fc6.ppc (8 days) sword - 1.5.8-10.fc6.x86_64 (8 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (54 days) plague - 0.4.4.1-2.fc3.noarch (54 days) plague - 0.4.4.1-2.fc4.noarch (54 days) plague - 0.4.4.1-2.fc4.noarch (54 days) plague - 0.4.4.1-2.fc4.noarch (54 days) denis AT poolshark.org galeon - 2.0.0-1.fc3.i386 (2 days) galeon - 2.0.0-1.fc3.x86_64 (2 days) giallu AT gmail.com sysprof - 1.0.5-1.fc6.i386 (5 days) sysprof - 1.0.5-1.fc6.x86_64 (5 days) imlinux AT gmail.com nagios-plugins-ide_smart - 1.4.3-20.fc4.i386 (14 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.ppc (14 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.x86_64 (14 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (30 days) linphone - 1.2.0-4.fc5.ppc (30 days) linphone - 1.2.0-4.fc5.x86_64 (30 days) linphone - 1.2.0-7.fc6.i386 (15 days) linphone - 1.2.0-7.fc6.ppc (15 days) linphone - 1.2.0-7.fc6.x86_64 (15 days) oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (20 days) syck-php - 0.55-9.fc5.ppc (20 days) syck-php - 0.55-9.fc5.x86_64 (20 days) petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 (5 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (5 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (5 days) ghc642-gtk2hs - 0.9.10-4.fc6.i386 (5 days) ghc642-gtk2hs - 0.9.10-4.fc6.ppc (5 days) ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 (5 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 (5 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc (5 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 (5 days) rdieter AT math.unl.edu PyKDE - 3.16.0-2.fc6.i386 PyKDE - 3.16.0-2.fc6.i386 PyKDE - 3.16.0-2.fc6.ppc PyKDE - 3.16.0-2.fc6.x86_64 PyQt-qscintilla - 3.16-7.fc7.i386 PyQt-qscintilla - 3.16-7.fc7.i386 PyQt-qscintilla - 3.16-7.fc7.ppc PyQt-qscintilla - 3.16-7.fc7.x86_64 eric - 3.9.1-3.fc6.noarch eric - 3.9.1-3.fc6.noarch eric - 3.9.1-3.fc6.noarch gift - 0.11.8.1-6.fc7.i386 (10 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- PyKDE-3.16.0-2.fc6.ppc requires PyQt = 0:3.16 PyQt-qscintilla-3.16-7.fc7.ppc requires PyQt = 0:3.16 centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 eric-3.9.1-3.fc6.noarch requires PyQt = 0:3.16 ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 gnomesword-2.1.6-5.fc6.ppc requires libcurl.so.3 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 sword-1.5.8-10.fc6.ppc requires libcurl.so.3 sylpheed-claws-plugins-etpan-privacy-2.5.2-5.fc7.ppc requires libetpan.so.8 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- PyKDE-3.16.0-2.fc6.i386 requires PyQt = 0:3.16 PyKDE-3.16.0-2.fc6.x86_64 requires PyQt = 0:3.16 PyQt-qscintilla-3.16-7.fc7.i386 requires PyQt = 0:3.16 PyQt-qscintilla-3.16-7.fc7.x86_64 requires PyQt = 0:3.16 centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) eric-3.9.1-3.fc6.noarch requires PyQt = 0:3.16 ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 gnomesword-2.1.6-5.fc6.x86_64 requires libcurl.so.3()(64bit) libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 sword-1.5.8-10.fc6.i386 requires libcurl.so.3 sword-1.5.8-10.fc6.x86_64 requires libcurl.so.3()(64bit) sylpheed-claws-plugins-etpan-privacy-2.5.2-5.fc7.x86_64 requires libetpan.so.8()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- PyKDE-3.16.0-2.fc6.i386 requires PyQt = 0:3.16 PyQt-qscintilla-3.16-7.fc7.i386 requires PyQt = 0:3.16 centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 eric-3.9.1-3.fc6.noarch requires PyQt = 0:3.16 ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 gnomesword-2.1.6-5.fc6.i386 requires libcurl.so.3 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 sword-1.5.8-10.fc6.i386 requires libcurl.so.3 sylpheed-claws-plugins-etpan-privacy-2.5.2-5.fc7.i386 requires libetpan.so.8 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.ppc requires libortp.so.2 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc6.ppc requires libetpan.so.8 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc6.x86_64 requires libetpan.so.8()(64bit) sysprof-1.0.5-1.fc6.x86_64 requires kmod-sysprof >= 0:1.0.5 Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.i386 requires libortp.so.2 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc6.i386 requires libetpan.so.8 sysprof-1.0.5-1.fc6.i386 requires kmod-sysprof >= 0:1.0.5 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc5.ppc requires libetpan.so.8 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc5.x86_64 requires libetpan.so.8()(64bit) Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc5.i386 requires libetpan.so.8 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.ppc requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.x86_64 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.i386 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- galeon-2.0.0-1.fc3.x86_64 requires mozilla = 37:1.7.12 plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- galeon-2.0.0-1.fc3.i386 requires mozilla = 37:1.7.12 plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: jeff AT ocjtech.us package: linphone - 1.2.0-7.fc6.ppc from fedora-extras-6-ppc unresolved deps: libortp.so.2 package: linphone - 1.2.0-7.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: libortp.so.2()(64bit) package: linphone - 1.2.0-7.fc6.i386 from fedora-extras-6-i386 unresolved deps: libortp.so.2 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: sylpheed-claws-plugins-etpan-privacy - 2.5.2-5.fc7.ppc from fedora-extras-development-ppc unresolved deps: libetpan.so.8 package: sylpheed-claws-plugins-etpan-privacy - 2.5.2-5.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libetpan.so.8()(64bit) package: orange - 0.3-3.cvs20051118.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libmagic.so.1 package: sylpheed-claws-plugins-etpan-privacy - 2.5.2-5.fc7.i386 from fedora-extras-development-i386 unresolved deps: libetpan.so.8 package: sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc6.ppc from fedora-extras-6-ppc unresolved deps: libetpan.so.8 package: sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: libetpan.so.8()(64bit) package: sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc6.i386 from fedora-extras-6-i386 unresolved deps: libetpan.so.8 package: sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc5.ppc from fedora-extras-5-ppc unresolved deps: libetpan.so.8 package: sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libetpan.so.8()(64bit) package: sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libetpan.so.8 ====================================================================== New report for: imlinux AT gmail.com package: nagios-plugins-ide_smart - 1.4.3-20.fc4.ppc from fedora-extras-4-ppc unresolved deps: nagios-plugins = 0:1.4.3-20.fc4 package: nagios-plugins-ide_smart - 1.4.3-20.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: nagios-plugins = 0:1.4.3-20.fc4 package: nagios-plugins-ide_smart - 1.4.3-20.fc4.i386 from fedora-extras-4-i386 unresolved deps: nagios-plugins = 0:1.4.3-20.fc4 ====================================================================== New report for: rdieter AT math.unl.edu package: PyKDE - 3.16.0-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: PyQt = 0:3.16 package: PyQt-qscintilla - 3.16-7.fc7.ppc from fedora-extras-development-ppc unresolved deps: PyQt = 0:3.16 package: eric - 3.9.1-3.fc6.noarch from fedora-extras-development-ppc unresolved deps: PyQt = 0:3.16 package: PyQt-qscintilla - 3.16-7.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: PyQt = 0:3.16 package: eric - 3.9.1-3.fc6.noarch from fedora-extras-development-x86_64 unresolved deps: PyQt = 0:3.16 package: PyKDE - 3.16.0-2.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: PyQt = 0:3.16 package: PyKDE - 3.16.0-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: PyQt = 0:3.16 package: PyQt-qscintilla - 3.16-7.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: PyQt = 0:3.16 package: PyKDE - 3.16.0-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: PyQt = 0:3.16 package: eric - 3.9.1-3.fc6.noarch from fedora-extras-development-i386 unresolved deps: PyQt = 0:3.16 package: PyQt-qscintilla - 3.16-7.fc7.i386 from fedora-extras-development-i386 unresolved deps: PyQt = 0:3.16 From jeff at ocjtech.us Wed Nov 8 13:45:33 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 08 Nov 2006 07:45:33 -0600 Subject: Estimate the size of extras ? In-Reply-To: <4551CE14.1050809@iinet.net.au> References: <4551CE14.1050809@iinet.net.au> Message-ID: <1162993533.3317.12.camel@lt21223.campus.dmacc.edu> On Wed, 2006-11-08 at 23:31 +1100, David Timms wrote: > I have been talking about getting extras mirrored with some local mirror > admins and was asked what space would be required for an extras mirror. > > Would someone know a more realistic answer, or could run du -sh extras/* > on their mirror and post back ? # du -sh extras/*/* 6.9G extras/4/i386 6.8G extras/4/x86_64 9.7G extras/5/i386 9.5G extras/5/x86_64 6.9G extras/6/i386 6.8G extras/6/x86_64 6.4G extras/development/i386 8.1G extras/development/x86_64 That includes the debuginfo packages but not SRPMS. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at camperquake.de Wed Nov 8 14:07:02 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 8 Nov 2006 15:07:02 +0100 Subject: Circular dependencies Message-ID: <20061108150702.0fb2f6b2@nausicaa.camperquake.de> Hi. Is it "legal" to have two packages which Require: each other (explicitly or implicitly)? -- Experience varies directly with equipment ruined. From enrico.scholz at informatik.tu-chemnitz.de Wed Nov 8 14:40:35 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 08 Nov 2006 15:40:35 +0100 Subject: Looking for some easy to fix code (not packaging) bugs In-Reply-To: <4551A195.3030305@hhs.nl> (Hans de Goede's message of "Wed, 08 Nov 2006 10:21:25 +0100") References: <4551A195.3030305@hhs.nl> Message-ID: <878ximf1cs.fsf@fc5.bigo.ensc.de> j.w.r.degoede at hhs.nl (Hans de Goede) writes: > As you all know by now I'm a CS teacher as my daytime job. I'm > currently working on a practicum where I want students to practice > with / experience debugging / fault tracing. For this I'm looking > for some bugs, which are 100% reproducable (no race conditions and > other hard stuff) and should be relatively easy to fix. Basicly I'm > looking for code bugs where lack of time is the most important > reason for not fixing them. | -- CMakeLists.txt -- | include(foo.cmake) | foo() | | -- foo.cmake -- | macro(foo) | message(SEND_ERROR "foo") | endmacro(foo) | | $ cmake CMakeLists.txt | ... | Segmentation fault (core dumped) with Extra's cmake-2.4.3-3.fc5 I did not had time yet to test it with recent cmake version. Enrico From denis at poolshark.org Wed Nov 8 15:00:16 2006 From: denis at poolshark.org (Denis Leroy) Date: Wed, 08 Nov 2006 16:00:16 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-06 In-Reply-To: <20061108123520.b6b8db62.bugs.michael@gmx.net> References: <20061106203234.28151.36304@extras64.linux.duke.edu> <20061108123520.b6b8db62.bugs.michael@gmx.net> Message-ID: <4551F100.8050300@poolshark.org> Michael Schwendt wrote: > On Mon, 06 Nov 2006 20:32:34 -0000, Fedora Extras repoclosure wrote: > >> New report for: denis AT poolshark.org >> >> package: galeon - 2.0.0-1.fc3.x86_64 from fedora-extras-3-x86_64 >> unresolved deps: >> mozilla = 37:1.7.12 >> >> package: galeon - 2.0.0-1.fc3.i386 from fedora-extras-3-i386 >> unresolved deps: >> mozilla = 37:1.7.12 >> > > Verified. > > This is only _with_ Fedora Legacy, who have released a Mozilla 1.7.13 > update in May. The problem is that when compiled against mozilla, galeon has an explicit Requires to its mozilla version number. That means that if I push an update, it will *only* work for people who use Fedora Legacy updates... My other problem is that mock FC-3 seems borked at the moment. From peter at thecodergeek.com Wed Nov 8 15:16:41 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 8 Nov 2006 07:16:41 -0800 (PST) Subject: Circular dependencies In-Reply-To: <20061108150702.0fb2f6b2@nausicaa.camperquake.de> References: <20061108150702.0fb2f6b2@nausicaa.camperquake.de> Message-ID: <8902.65.223.36.19.1162999001.squirrel@thecodergeek.com> Ralf Ertzinger wrote: > Is it "legal" to have two packages which Require: each other (explicitly or > implicitly)? As I understand it, that is acceptable. They would merely need to be installed or removed, etc. within the same single RPM transaction. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From fedora at camperquake.de Wed Nov 8 15:20:44 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 8 Nov 2006 16:20:44 +0100 Subject: Circular dependencies In-Reply-To: <8902.65.223.36.19.1162999001.squirrel@thecodergeek.com> References: <20061108150702.0fb2f6b2@nausicaa.camperquake.de> <8902.65.223.36.19.1162999001.squirrel@thecodergeek.com> Message-ID: <20061108162044.2d9ea4c9@nausicaa.camperquake.de> Hi. "Peter Gordon" wrote: > As I understand it, that is acceptable. They would merely need to be > installed or removed, etc. within the same single RPM transaction. That I am aware of. Will packages doing this pass review, however? -- "In our world, software has to be small, has to be debugged, has to ship as part of a major initiative, has to avoid compatibility problems, has to avoid end user calls." -- Bill Gates From jkeating at redhat.com Wed Nov 8 15:22:01 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 8 Nov 2006 10:22:01 -0500 Subject: Circular dependencies In-Reply-To: <20061108150702.0fb2f6b2@nausicaa.camperquake.de> References: <20061108150702.0fb2f6b2@nausicaa.camperquake.de> Message-ID: <200611081022.01471.jkeating@redhat.com> On Wednesday 08 November 2006 09:07, Ralf Ertzinger wrote: > Is it "legal" to have two packages which Require: each other (explicitly or > implicitly)? It is OK as rpm/yum can sort this out at install / update / removal time provided that both packages are in the transaction list. The fun part comes in BUILDING them. If they are a buildrequires of eachother, how do you get them into the build system to build in the first place? Some bootstrapping may have to happen. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at camperquake.de Wed Nov 8 15:25:16 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 8 Nov 2006 16:25:16 +0100 Subject: Circular dependencies In-Reply-To: <200611081022.01471.jkeating@redhat.com> References: <20061108150702.0fb2f6b2@nausicaa.camperquake.de> <200611081022.01471.jkeating@redhat.com> Message-ID: <20061108162516.62a2c0da@nausicaa.camperquake.de> Hi. Jesse Keating wrote: > It is OK as rpm/yum can sort this out at install / update / removal > time provided that both packages are in the transaction list. The fun > part comes in BUILDING them. Thankfully it's just a runtime dependency. -- "We are birds who, though we may spit up blood, will go on flying beyond that morning on and on! To live is to change. The Ohmu, the mold, the grasses and trees, we human beings...we will all go on changing. And the Sea of Corruption will live on with us." Nausica? of the valley of wind From rdieter at math.unl.edu Wed Nov 8 15:38:10 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 08 Nov 2006 09:38:10 -0600 Subject: Circular dependencies References: <20061108150702.0fb2f6b2@nausicaa.camperquake.de> <8902.65.223.36.19.1162999001.squirrel@thecodergeek.com> <20061108162044.2d9ea4c9@nausicaa.camperquake.de> Message-ID: Ralf Ertzinger wrote: > "Peter Gordon" wrote: > >> As I understand it, that is acceptable. They would merely need to be >> installed or removed, etc. within the same single RPM transaction. > > That I am aware of. Will packages doing this pass review, however? Shouldn't be a blocker, afaict. -- Rex From bugs.michael at gmx.net Wed Nov 8 17:20:59 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 8 Nov 2006 18:20:59 +0100 Subject: galeon - Re: Summary - Broken dependencies in Fedora Extras - 2006-11-06 In-Reply-To: <4551F100.8050300@poolshark.org> References: <20061106203234.28151.36304@extras64.linux.duke.edu> <20061108123520.b6b8db62.bugs.michael@gmx.net> <4551F100.8050300@poolshark.org> Message-ID: <20061108182059.9062919a.bugs.michael@gmx.net> On Wed, 08 Nov 2006 16:00:16 +0100, Denis Leroy wrote: > > On Mon, 06 Nov 2006 20:32:34 -0000, Fedora Extras repoclosure wrote: > > > >> New report for: denis AT poolshark.org > >> > >> package: galeon - 2.0.0-1.fc3.x86_64 from fedora-extras-3-x86_64 > >> unresolved deps: > >> mozilla = 37:1.7.12 > >> > >> package: galeon - 2.0.0-1.fc3.i386 from fedora-extras-3-i386 > >> unresolved deps: > >> mozilla = 37:1.7.12 > >> > > > > Verified. > > > > This is only _with_ Fedora Legacy, who have released a Mozilla 1.7.13 > > update in May. > > The problem is that when compiled against mozilla, galeon has an > explicit Requires to its mozilla version number. That means that if I > push an update, it will *only* work for people who use Fedora Legacy > updates... Well, the Fedora Extras buildsys uses Fedora Legacy, too. That's FESCo policy for FE3 and FE4. > My other problem is that mock FC-3 seems borked at the moment. From dimitris at glezos.com Wed Nov 8 21:00:04 2006 From: dimitris at glezos.com (Dimitris Glezos) Date: Wed, 08 Nov 2006 21:00:04 +0000 Subject: Circular dependencies In-Reply-To: <20061108150702.0fb2f6b2@nausicaa.camperquake.de> References: <20061108150702.0fb2f6b2@nausicaa.camperquake.de> Message-ID: <45524554.2090504@glezos.com> Ralf Ertzinger wrote: > Is it "legal" to have two packages which Require: each other > (explicitly or implicitly)? Speaking in general graph theory (dependencies can be seen as nodes connected with directed arrows producing a directed graph), it becomes more tricky when one allows circles, ie jump from Directed Acyclic Graphs (DAGs) to cyclic ones. I can't imagine how this could currently affect our tools but it could become a thorn if we ever need to do smart handling of the dependency graph. For example, Directed Acyclic Graphs have topological orders [1] (which might be useful for, or is already used by yum), simpler/faster search algorithms (depth-first search) etc. Don't know if this "potential" is worth the effort of circumventing the mutual dependency though (for example, by creating a dummy "parent" dependency package that both package will depend on, etc). I would say *it is*, because it keeps things simple and keeps some potentials open, but then again, I am neither a maintainer nor the specialist on the internals of rpm/yum, or even on graph theory. :) -d [1]: http://en.wikipedia.org/wiki/Topological_sort -- Dimitris Glezos Jabber ID: glezos at jabber.org, PGP: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From bugs.michael at gmx.net Wed Nov 8 21:11:00 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 8 Nov 2006 22:11:00 +0100 Subject: Circular dependencies In-Reply-To: <20061108162516.62a2c0da@nausicaa.camperquake.de> References: <20061108150702.0fb2f6b2@nausicaa.camperquake.de> <200611081022.01471.jkeating@redhat.com> <20061108162516.62a2c0da@nausicaa.camperquake.de> Message-ID: <20061108221100.d8e86f00.bugs.michael@gmx.net> On Wed, 8 Nov 2006 16:25:16 +0100, Ralf Ertzinger wrote: > > It is OK as rpm/yum can sort this out at install / update / removal > > time provided that both packages are in the transaction list. The fun > > part comes in BUILDING them. > > Thankfully it's just a runtime dependency. The key question this raises is _why_ can't both packages be combined into one? From roozbeh at farsiweb.info Wed Nov 8 20:30:17 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Thu, 09 Nov 2006 00:00:17 +0330 Subject: Orphaning three packages officially Message-ID: <1163017817.4615.24.camel@shalil.farsiweb.info> Hi all. After my laptop was stolen, I asked for the removal of my access from Fedora Extras as there were copies of the keys on the laptop and brute-force attempts could have been used against them to get the password and then compromise things on Extras. Thanks to Thorsten, I now have the access back. In the meanwhile, FC6 was getting released and I could not rebuild my packages for the deadline. Some of you helped rebuild these, and some even took maintainership, for which I would like to thank you for. I just de-orphaned the packages that were automatically orphaned because of my keylessness, but will need to orphan three of them anyway, as two appear to be silent upstream and I don't use them anymore, and one is specific to my lost Sony VAIO laptops. The packages orphaned are: gtranslator spicctrl ttf2pt1 Also, if anyone wants to take maintainership of t1lib and t1utils (Jos??) please feel free. I don't use these much and would appreciate someone more familiar with them to take care of them. Roozbeh From michel.salim at gmail.com Wed Nov 8 22:15:16 2006 From: michel.salim at gmail.com (Michel Salim) Date: Wed, 8 Nov 2006 17:15:16 -0500 Subject: Orphaning three packages officially In-Reply-To: <1163017817.4615.24.camel@shalil.farsiweb.info> References: <1163017817.4615.24.camel@shalil.farsiweb.info> Message-ID: <883cfe6d0611081415x180c5925m8af5a7b49069f246@mail.gmail.com> On 11/8/06, Roozbeh Pournader wrote: > > The packages orphaned are: > gtranslator > spicctrl > ttf2pt1 > I'm expecting delivery of my VAIO laptop today, so I'll take over spicctrl. -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From wart at kobold.org Thu Nov 9 01:02:57 2006 From: wart at kobold.org (Michael Thomas) Date: Wed, 08 Nov 2006 17:02:57 -0800 Subject: Circular dependencies In-Reply-To: <20061108221100.d8e86f00.bugs.michael@gmx.net> References: <20061108150702.0fb2f6b2@nausicaa.camperquake.de> <200611081022.01471.jkeating@redhat.com> <20061108162516.62a2c0da@nausicaa.camperquake.de> <20061108221100.d8e86f00.bugs.michael@gmx.net> Message-ID: <45527E41.5040508@kobold.org> Michael Schwendt wrote: > On Wed, 8 Nov 2006 16:25:16 +0100, Ralf Ertzinger wrote: > >>> It is OK as rpm/yum can sort this out at install / update / removal >>> time provided that both packages are in the transaction list. The fun >>> part comes in BUILDING them. >> Thankfully it's just a runtime dependency. > > The key question this raises is _why_ can't both packages be combined > into one? If one of the packages contains large, static data files that don't change often (such as game data), while the second package contains the application code that depends on the existence of the first (such as a game engine). You don't want to push updates of a 50MB+ data file that doesn't change for every minor bugfix in the engine. Most of the large games in Fedora, however, don't do this with a circular dependency, but rather by having the game data require the game engine (or sometimes vice versa). --Wart From bugs.michael at gmx.net Thu Nov 9 01:48:29 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 9 Nov 2006 02:48:29 +0100 Subject: Circular dependencies In-Reply-To: <45527E41.5040508@kobold.org> References: <20061108150702.0fb2f6b2@nausicaa.camperquake.de> <200611081022.01471.jkeating@redhat.com> <20061108162516.62a2c0da@nausicaa.camperquake.de> <20061108221100.d8e86f00.bugs.michael@gmx.net> <45527E41.5040508@kobold.org> Message-ID: <20061109024829.6ccbfcec.bugs.michael@gmx.net> On Wed, 08 Nov 2006 17:02:57 -0800, Michael Thomas wrote: > Michael Schwendt wrote: > > On Wed, 8 Nov 2006 16:25:16 +0100, Ralf Ertzinger wrote: > > > >>> It is OK as rpm/yum can sort this out at install / update / removal > >>> time provided that both packages are in the transaction list. The fun > >>> part comes in BUILDING them. > >> Thankfully it's just a runtime dependency. > > > > The key question this raises is _why_ can't both packages be combined > > into one? > > If one of the packages contains large, static data files that don't > change often (such as game data), while the second package contains the > application code that depends on the existence of the first (such as a > game engine). You don't want to push updates of a 50MB+ data file that > doesn't change for every minor bugfix in the engine. > > Most of the large games in Fedora, however, don't do this with a > circular dependency, but rather by having the game data require the game > engine (or sometimes vice versa). Well, there is no reason why game data actually "requires" the game program before it could be _installed_. The important direction of the dependency is "game program needs data, since else it would fail at run-time" and not "data need a program". Think of it like a collection of images without an image viewer. You would not make a wallpaper package require an image viewer package, not even via a dependency on a virtual capability. [Same with libraries, btw. ;-)] A circular dependency is the wrong way of thinking here. Probably it's only applied because end-users are confronted with data package names and might try low-level commands like "yum install somegame-data" instead of telling an installer to add/remove "somegame". (In networked multi-machine installations it would even be plausible to remove the dependency on the game data package, as it might be installed only on a file server.) From j.w.r.degoede at hhs.nl Thu Nov 9 07:11:02 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 09 Nov 2006 08:11:02 +0100 Subject: xview anyone ? In-Reply-To: <20061101112143.62227d36@ludwig-alpha.unil.ch> References: <20061025004624.4320c333@ludwig-alpha.unil.ch> <20061025080639.GA2622@free.fr> <20061025111032.50812465@ludwig-alpha.unil.ch> <20061030113934.GA3195@free.fr> <20061101095326.5894f676@ludwig-alpha.unil.ch> <45487992.3040406@hhs.nl> <20061101112143.62227d36@ludwig-alpha.unil.ch> Message-ID: <4552D486.1010107@hhs.nl> Christian Iseli wrote: > On Wed, 01 Nov 2006 11:40:18 +0100, Hans de Goede wrote: >> 1) Have you checked Debian's packages of this (if they have any) usually with hard to package software >> its a good idea to start with all Debian's patches (or atleast thosw which seem to make sense) that >> might fix this. > > Yup, Pat basically used all the Debian stuff. > >> 2) If you can give me a shortlist of instructions howto reproduce this then I can take a look at my 64 >> bit machine at home (work doesn't have any 64 bit machines yet). As time permits of course. > > Sure: > - grab ftp://ftp.licr.org/pub/xview-3.2-0.1.p4.src.rpm > - mock xview-3.2-0.1.p4.src.rpm on your 64-bit machine (for FC-[567]) > - install xview, xview-clients, and xview-debuginfo > - launch "clock" > - watch it loop (it will not display anything, and use 100% CPU) > - attach a gdb to the process > > Cheers, > C Well, I've spend some hours taking a look and I've come to the same conclusion as the Debian maintainer, this is very hard to fix for 64 bit. More then that fixing probably will also include fixing / changing all xview using clients! Luckily all 64 bit platforms we support also have a 32 bit compatibility option, so I think we should just not build xview (and apps using it) for x86_64 / ppc64. It would be a good idea IMHO in cases like this to add xview + deps + packages using it to a list of packages to copy over to the x86_64 repo from the i386 repo, so that it will be readily available for those who want it. My taking a look started with suse since they had x86_64 packages of xview in their repo, but appearantly these have had the famous suse QA done do them (iow none). I did find some other interesting patches in there, which I have bundled in a smaller one with possible real fixes and a larger one which fixes a load of warnings (but no where near all warnings). I also have a patch which fixes some 64 bit related warnings by adding the necessary prototypes, which isn't enough to get this running but IMHO still should be applied / send upstream (Debian claims to be upstream these days) as it is an improvement. I wanted to attach these patches to the review request but I can't find it. Let me know where you want them send. Regards, Hans From eric.tanguy at univ-nantes.fr Thu Nov 9 07:17:32 2006 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Thu, 09 Nov 2006 08:17:32 +0100 Subject: Pb with plague Message-ID: <1163056652.3097.1.camel@bureau.maison> I just tried to launch a new build using make plague after using make tag without any problem and i obtain this error : $ make plague /usr/bin/plague-client build gperiodic gperiodic-2_0_8-5_fc7 devel Traceback (most recent call last): File "/usr/bin/plague-client", line 420, in ? cli = PlagueClient(os.path.expanduser(cfg_file)) File "/usr/bin/plague-client", line 85, in __init__ self._check_api_version(self._server) File "/usr/bin/plague-client", line 90, in _check_api_version server_ver = server.api_version() File "/usr/lib/python2.4/xmlrpclib.py", line 1096, in __call__ return self.__send(self.__name, args) File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request verbose=self.__verbose File "/usr/lib/python2.4/xmlrpclib.py", line 1129, in request self.send_content(h, request_body) File "/usr/lib/python2.4/xmlrpclib.py", line 1243, in send_content connection.endheaders() File "/usr/lib/python2.4/httplib.py", line 798, in endheaders self._send_output() File "/usr/lib/python2.4/httplib.py", line 679, in _send_output self.send(msg) File "/usr/lib/python2.4/httplib.py", line 658, in send self.sock.sendall(str) File "/usr/lib/python2.4/site-packages/plague/SSLConnection.py", line 110, in sendall sent = con.send(data, flags) OpenSSL.SSL.Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl handshake failure')] make: *** [plague] Erreur 1 Someone could explain me what is the problem ? Thanks Eric From giallu at gmail.com Thu Nov 9 07:48:28 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 9 Nov 2006 08:48:28 +0100 Subject: Pb with plague In-Reply-To: <1163056652.3097.1.camel@bureau.maison> References: <1163056652.3097.1.camel@bureau.maison> Message-ID: On 11/9/06, Tanguy Eric wrote: > OpenSSL.SSL.Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert > certificate expired'), ^^^^^^^^^^^^^^^ > Someone could explain me what is the problem ? > The certificate expired? get a new one From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Nov 9 09:05:54 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 9 Nov 2006 10:05:54 +0100 Subject: Circular dependencies In-Reply-To: <20061109024829.6ccbfcec.bugs.michael@gmx.net> References: <20061108150702.0fb2f6b2@nausicaa.camperquake.de> <200611081022.01471.jkeating@redhat.com> <20061108162516.62a2c0da@nausicaa.camperquake.de> <20061108221100.d8e86f00.bugs.michael@gmx.net> <45527E41.5040508@kobold.org> <20061109024829.6ccbfcec.bugs.michael@gmx.net> Message-ID: <20061109100554.61808de1@python3.es.egwn.lan> Michael Schwendt wrote : > A circular dependency is the wrong way of thinking here. Probably it's > only applied because end-users are confronted with data package names and > might try low-level commands like "yum install somegame-data" instead of > telling an installer to add/remove "somegame". Well, one might argue that without a circular dependency, end-users are confronted with a possibly unexpected behaviour : yum install gamename (pulls-in huge gamename-data) yum remove gamename (leaves huge gamename-data installed...) I'm not saying that a circular dependency is the right solution, but it is indeed the only easy one I see. Matthias > (In networked multi-machine installations it would even be plausible to > remove the dependency on the game data package, as it might be installed > only on a file server.) And see bug reports flowing in... for anyone who might be facing that scenario, I'd suggest either installing with --nodeps or installing the game itself anyway :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.18-1.2835.fc6 Load : 0.33 0.29 0.26 From bugs.michael at gmx.net Thu Nov 9 10:02:15 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 9 Nov 2006 11:02:15 +0100 Subject: Circular dependencies In-Reply-To: <20061109100554.61808de1@python3.es.egwn.lan> References: <20061108150702.0fb2f6b2@nausicaa.camperquake.de> <200611081022.01471.jkeating@redhat.com> <20061108162516.62a2c0da@nausicaa.camperquake.de> <20061108221100.d8e86f00.bugs.michael@gmx.net> <45527E41.5040508@kobold.org> <20061109024829.6ccbfcec.bugs.michael@gmx.net> <20061109100554.61808de1@python3.es.egwn.lan> Message-ID: <20061109110215.7db4a57a.bugs.michael@gmx.net> On Thu, 9 Nov 2006 10:05:54 +0100, Matthias Saou wrote: > Michael Schwendt wrote : > > > A circular dependency is the wrong way of thinking here. Probably it's > > only applied because end-users are confronted with data package names and > > might try low-level commands like "yum install somegame-data" instead of > > telling an installer to add/remove "somegame". > > Well, one might argue that without a circular dependency, end-users are > confronted with a possibly unexpected behaviour : > > yum install gamename (pulls-in huge gamename-data) > yum remove gamename (leaves huge gamename-data installed...) Why doesn't "yum remove" suggest to remove also leaf packages which are a direct dependency of the thing to remove? > > (In networked multi-machine installations it would even be plausible to > > remove the dependency on the game data package, as it might be installed > > only on a file server.) > > And see bug reports flowing in... for anyone who might be facing that > scenario, I'd suggest either installing with --nodeps or installing the > game itself anyway :-) Yes, of course, but --nodeps is forgotten once the next automated nightly yum update kicks in, because missing deps are resolved automatically. From Christian.Iseli at licr.org Thu Nov 9 10:02:09 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 9 Nov 2006 11:02:09 +0100 Subject: xview anyone ? In-Reply-To: <4552D486.1010107@hhs.nl> References: <20061025004624.4320c333@ludwig-alpha.unil.ch> <20061025080639.GA2622@free.fr> <20061025111032.50812465@ludwig-alpha.unil.ch> <20061030113934.GA3195@free.fr> <20061101095326.5894f676@ludwig-alpha.unil.ch> <45487992.3040406@hhs.nl> <20061101112143.62227d36@ludwig-alpha.unil.ch> <4552D486.1010107@hhs.nl> Message-ID: <20061109110209.2f6d37b2@ludwig-alpha.unil.ch> Hi Hans, On Thu, 09 Nov 2006 08:11:02 +0100, Hans de Goede wrote: > I've spend some hours taking a look and I've come to the same conclusion > as the Debian maintainer, this is very hard to fix for 64 bit. More then > that fixing probably will also include fixing / changing all xview using > clients! > > Luckily all 64 bit platforms we support also have a 32 bit compatibility > option, so I think we should just not build xview (and apps using it) > for x86_64 / ppc64. It would be a good idea IMHO in cases like this to > add xview + deps + packages using it to a list of packages to copy over > to the x86_64 repo from the i386 repo, so that it will be readily > available for those who want it. > > My taking a look started with suse since they had x86_64 packages of > xview in their repo, but appearantly these have had the famous suse QA > done do them (iow none). I did find some other interesting patches in > there, which I have bundled in a smaller one with possible real fixes > and a larger one which fixes a load of warnings (but no where near all > warnings). I also have a patch which fixes some 64 bit related warnings > by adding the necessary prototypes, which isn't enough to get this > running but IMHO still should be applied / send upstream (Debian claims > to be upstream these days) as it is an improvement. > > I wanted to attach these patches to the review request but I can't find > it. Let me know where you want them send. I opened a review request now: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214751 Please put your patches there. Thanks for your help. I think this package can be useful to at least a few of us. And who knows, maybe this becomes one of those vintage craze :-) C From j.w.r.degoede at hhs.nl Thu Nov 9 11:01:12 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 09 Nov 2006 12:01:12 +0100 Subject: Disturbing lack of FE security updates announcements! Message-ID: <45530A78.7040908@hhs.nl> Hi All, This morning I've been working on fixing several security flaws in imlib2. When I was done with fixing and building these, I started writing a security update notification mail to send to fedora-package-announce at redhat.com In the usual format for updates send to this list. The Fedora Extras updates have there own numbering scheme seperate of that of FC, so I started looking through the archives for the last update to give mine the next free number, much to my shock the idenitifier for this security update is: FEDORA-EXTRAS-2006-004 IOW, this is the 4th security announcement send on behalve of FE this year, that is really BAD! Even worse, FEDORA-EXTRAS-2006-003 the previous announcement was also send to the list by me? Am I the only one taking the trouble to announce security updates?? When magazine XXX is going todo security stats on FE the will use the official announcements to determine our response time and this will make us look bad, not to mention the fact that this is really bad communication to our end users! FESco, can you please mandate sending a mail to fedora-package-announce at redhat.com for security related updates? Regards, Hans From fedora at camperquake.de Thu Nov 9 11:00:26 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 9 Nov 2006 12:00:26 +0100 Subject: Circular dependencies In-Reply-To: <20061108221100.d8e86f00.bugs.michael@gmx.net> References: <20061108150702.0fb2f6b2@nausicaa.camperquake.de> <200611081022.01471.jkeating@redhat.com> <20061108162516.62a2c0da@nausicaa.camperquake.de> <20061108221100.d8e86f00.bugs.michael@gmx.net> Message-ID: <20061109120026.3d40e952@nausicaa.camperquake.de> Hi. Michael Schwendt wrote: > The key question this raises is _why_ can't both packages be combined > into one? For one, I have worked around this one, so circular deps are no longer required. The package(s) in question here are audacious and audacious-plugins, where the latter requires the former (in terms of libraries and header files), and the former is not much use without the latter, so users installing audacious (or upgrading from an older version where the plugins were included in the main package) have to get audacious-plugins, too. Both packages are clearly separated, with separate configure steps and all. It may be possible to build both in the same spec file, but it would not be pretty. However, this is solved cleanly now. -- "This isn't all true." -- Steven Wright From fedora at leemhuis.info Thu Nov 9 11:34:05 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 09 Nov 2006 12:34:05 +0100 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <45530A78.7040908@hhs.nl> References: <45530A78.7040908@hhs.nl> Message-ID: <4553122D.7020604@leemhuis.info> https://www.redhat.com/archives/fedora-extras-list/2006-November/msg00148.html Hans de Goede schrieb: > This morning I've been working on fixing several security flaws in imlib2. > When I was done with fixing and building these, I started writing a > security update notification mail to send to fedora-package-announce at redhat.com > In the usual format for updates send to this list. > [...] > FESco, can you please mandate sending a mail to fedora-package-announce at redhat.com for > security related updates? I agree with the idea. Hans, can you or maybe someone else (from the Security SIG, sorry, Response Team?) work out a proposal an integrate it into http://www.fedoraproject.org/wiki/Extras/Schedule/SecurityAnnoucements (that will be later moved to http://www.fedoraproject.org/wiki/Extras/Policy ) In an ideal world it would look a bit like http://www.fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages e.g. a *short* section in the beginning that allows new contributors to get an idea of our processes and rules without wasting to much time reading details. Then a more detailed section witch describes the thing (Why? How?) in detail. thx CU thl From bugs.michael at gmx.net Thu Nov 9 11:59:40 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 9 Nov 2006 12:59:40 +0100 Subject: imlib2 - Re: Disturbing lack of FE security updates announcements! In-Reply-To: <45530A78.7040908@hhs.nl> References: <45530A78.7040908@hhs.nl> Message-ID: <20061109125940.aa4993ca.bugs.michael@gmx.net> On Thu, 09 Nov 2006 12:01:12 +0100, Hans de Goede wrote: > Hi All, > > This morning I've been working on fixing several security flaws in imlib2. Off-topic, but upstream still has not updated the ChangeLog since 2004. :( From bressers at redhat.com Thu Nov 9 12:15:17 2006 From: bressers at redhat.com (Josh Bressers) Date: Thu, 09 Nov 2006 07:15:17 -0500 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <4553122D.7020604@leemhuis.info> References: <45530A78.7040908@hhs.nl> <4553122D.7020604@leemhuis.info> Message-ID: <200611091215.kA9CFH4Y003978@devserv.devel.redhat.com> > https://www.redhat.com/archives/fedora-extras-list/2006-November/msg00148.html > > Hans de Goede schrieb: > > This morning I've been working on fixing several security flaws in imlib2. > > When I was done with fixing and building these, I started writing a > > security update notification mail to send to fedora-package-announce at redhat.com > > In the usual format for updates send to this list. > > [...] > > FESco, can you please mandate sending a mail to fedora-package-announce at redhat.com for > > security related updates? > > I agree with the idea. Hans, can you or maybe someone else (from the > Security SIG, sorry, Response Team?) work out a proposal an integrate it > into > http://www.fedoraproject.org/wiki/Extras/Schedule/SecurityAnnoucements > (that will be later moved to > http://www.fedoraproject.org/wiki/Extras/Policy ) > > In an ideal world it would look a bit like > http://www.fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages > e.g. a *short* section in the beginning that allows new contributors to > get an idea of our processes and rules without wasting to much time > reading details. Then a more detailed section witch describes the thing > (Why? How?) in detail. > This is currently a non trivial problem to solve. We lack the man power to modify the various problem packages ourselves, so the obvious solution is to let the owner do the work and the security team would only have to step in when the owner is MIA. As soon as the owner builds the new package is magically appears as part of FE. We don't have an easy way to determine when something has been pushed live. The right way to solve this problem is to send announcements for every FE update (security or not), and to let the security team edit security advisories to ensure the proper information is included. -- JB From j.w.r.degoede at hhs.nl Thu Nov 9 12:41:36 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 09 Nov 2006 13:41:36 +0100 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <200611091215.kA9CFH4Y003978@devserv.devel.redhat.com> References: <45530A78.7040908@hhs.nl> <4553122D.7020604@leemhuis.info> <200611091215.kA9CFH4Y003978@devserv.devel.redhat.com> Message-ID: <45532200.5020807@hhs.nl> Josh Bressers wrote: >> https://www.redhat.com/archives/fedora-extras-list/2006-November/msg00148.html >> >> Hans de Goede schrieb: >>> This morning I've been working on fixing several security flaws in imlib2. >>> When I was done with fixing and building these, I started writing a >>> security update notification mail to send to fedora-package-announce at redhat.com >>> In the usual format for updates send to this list. >>> [...] >>> FESco, can you please mandate sending a mail to fedora-package-announce at redhat.com for >>> security related updates? >> I agree with the idea. Hans, can you or maybe someone else (from the >> Security SIG, sorry, Response Team?) work out a proposal an integrate it >> into >> http://www.fedoraproject.org/wiki/Extras/Schedule/SecurityAnnoucements >> (that will be later moved to >> http://www.fedoraproject.org/wiki/Extras/Policy ) >> >> In an ideal world it would look a bit like >> http://www.fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages >> e.g. a *short* section in the beginning that allows new contributors to >> get an idea of our processes and rules without wasting to much time >> reading details. Then a more detailed section witch describes the thing >> (Why? How?) in detail. >> > > This is currently a non trivial problem to solve. We lack the man power to > modify the various problem packages ourselves, so the obvious solution is > to let the owner do the work and the security team would only have to step > in when the owner is MIA. As soon as the owner builds the new package is > magically appears as part of FE. We don't have an easy way to determine > when something has been pushed live. > > The right way to solve this problem is to send announcements for every FE > update (security or not), and to let the security team edit security > advisories to ensure the proper information is included. > That is one solution, but given the rolling release model of FE, that are going to be a lot of announcements. Why not ask FE package maintainers to send a security announcement out when they push an update which has security implications / fixes? Regards, Hans From bressers at redhat.com Thu Nov 9 13:05:34 2006 From: bressers at redhat.com (Josh Bressers) Date: Thu, 09 Nov 2006 08:05:34 -0500 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <45532200.5020807@hhs.nl> References: <45530A78.7040908@hhs.nl> <4553122D.7020604@leemhuis.info> <200611091215.kA9CFH4Y003978@devserv.devel.redhat.com> <45532200.5020807@hhs.nl> Message-ID: <200611091305.kA9D5Yxx007122@devserv.devel.redhat.com> > > > > The right way to solve this problem is to send announcements for every FE > > update (security or not), and to let the security team edit security > > advisories to ensure the proper information is included. > > > > That is one solution, but given the rolling release model of FE, that are going to > be a lot of announcements. Why not ask FE package maintainers to send a security > announcement out when they push an update which has security implications / fixes? > I don't believe this will work, but if you think so, write up your idea with some technical details and send it to the fedora security list for discussion. The fundamental flaw with this I see is what happens when someone decides to ignore the request? With the sheer number of extras packages we don't have a terribly good way of tracking what's getting fixed and when. As crazy as this sounds, no security advisories is a better situation that half assed security advisories. Security advisories should be all or none lest we just create more problems than we already have. I would rather see a lot of FE announcements than the current lack of announcements. Right now I run a yum update, and I have no idea what the extras updates are fixing. This annoys me to no end, and I would be very surprised if I'm the only one. -- JB From j.w.r.degoede at hhs.nl Thu Nov 9 13:36:50 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 09 Nov 2006 14:36:50 +0100 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <200611091305.kA9D5Yxx007122@devserv.devel.redhat.com> References: <45530A78.7040908@hhs.nl> <4553122D.7020604@leemhuis.info> <200611091215.kA9CFH4Y003978@devserv.devel.redhat.com> <45532200.5020807@hhs.nl> <200611091305.kA9D5Yxx007122@devserv.devel.redhat.com> Message-ID: <45532EF2.6030809@hhs.nl> Josh Bressers wrote: >>> The right way to solve this problem is to send announcements for every FE >>> update (security or not), and to let the security team edit security >>> advisories to ensure the proper information is included. >>> >> That is one solution, but given the rolling release model of FE, that are going to >> be a lot of announcements. Why not ask FE package maintainers to send a security >> announcement out when they push an update which has security implications / fixes? >> > > I don't believe this will work, but if you think so, write up your idea > with some technical details and send it to the fedora security list for > discussion. > Hmm, I'm not all that fond on writing proposals esp. this early in the process, I'll first let this thread run a couple of days to get some more input and then I'll try to write something for FESco / the security list. > The fundamental flaw with this I see is what happens when someone decides > to ignore the request? With the sheer number of extras packages we don't > have a terribly good way of tracking what's getting fixed and when. As > crazy as this sounds, no security advisories is a better situation that half > assed security advisories. Security advisories should be all or none lest > we just create more problems than we already have. > Agreed. Regards, Hans From bugs.michael at gmx.net Thu Nov 9 14:10:38 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 9 Nov 2006 15:10:38 +0100 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <200611091305.kA9D5Yxx007122@devserv.devel.redhat.com> References: <45530A78.7040908@hhs.nl> <4553122D.7020604@leemhuis.info> <200611091215.kA9CFH4Y003978@devserv.devel.redhat.com> <45532200.5020807@hhs.nl> <200611091305.kA9D5Yxx007122@devserv.devel.redhat.com> Message-ID: <20061109151038.55ad01ea.bugs.michael@gmx.net> On Thu, 09 Nov 2006 08:05:34 -0500, Josh Bressers wrote: > I would rather see a lot of FE announcements than the current lack of > announcements. Right now I run a yum update, and I have no idea what the > extras updates are fixing. This annoys me to no end, and I would be very > surprised if I'm the only one. If the Fedora Infofeed were not broken (ticket #2006110910000031), you could subscribe to a feed like http://fedoraproject.org/infofeed/inputs/development-extras.xml and get the package %changelogs. The corresponding feed for FC6 is missing, however: http://fedoraproject.org/infofeed/inputs/fc6-extras.xml The home page for the feeds is linked at the bottom of every FE build report: http://fedoraproject.org/infofeed/ From rc040203 at freenet.de Thu Nov 9 14:17:51 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 09 Nov 2006 15:17:51 +0100 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <45532200.5020807@hhs.nl> References: <45530A78.7040908@hhs.nl> <4553122D.7020604@leemhuis.info> <200611091215.kA9CFH4Y003978@devserv.devel.redhat.com> <45532200.5020807@hhs.nl> Message-ID: <1163081871.7601.93.camel@mccallum.corsepiu.local> On Thu, 2006-11-09 at 13:41 +0100, Hans de Goede wrote: > Josh Bressers wrote: > >> https://www.redhat.com/archives/fedora-extras-list/2006-November/msg00148.html > >> > >> Hans de Goede schrieb: > > This is currently a non trivial problem to solve. We lack the man power to > > modify the various problem packages ourselves, so the obvious solution is > > to let the owner do the work and the security team would only have to step > > in when the owner is MIA. As soon as the owner builds the new package is > > magically appears as part of FE. We don't have an easy way to determine > > when something has been pushed live. > > > > The right way to solve this problem is to send announcements for every FE > > update (security or not), and to let the security team edit security > > advisories to ensure the proper information is included. > > > > That is one solution, but given the rolling release model of FE, that are going to > be a lot of announcements. Why not ask FE package maintainers to send a security > announcement out when they push an update which has security implications / fixes? Let me turn this thing around: Why should they? I don't see why filing a PR and then giving maintainers a chance to react should not work. Whether they will be able to react, whether they will be able to react in reasonable time is a different question. Ralf From buildsys at fedoraproject.org Thu Nov 9 14:20:12 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 9 Nov 2006 09:20:12 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-09 Message-ID: <20061109142013.04ECA15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 23 PyKDE-3.16.0-3.fc7 PyQt-qscintilla-3.17-1.fc7 anjuta-2.0.2-10.fc7 bugzilla-2.22.1-1.fc7 csound-5.03.0-9.fc7 doulos-fonts-4.0.14-3.fc7 eric-3.9.1-4.fc7 fonttools-2.0-0.8.20050624cvs.fc7 gkrellm-2.2.10-2.fc7 gnome-theme-clearlooks-bigpack-0.6-4.fc7 gnomesword-2.1.8-3.fc7 imlib2-1.3.0-3.fc7 jd-1.8.0-0.5.rc061108.fc7 kadu-0.5.0-0.19.rc1.fc7 libopm-0.1-3.20050731cvs.fc7 mail-notification-3.0-10.fc7 mimedefang-2.58-1.fc7 multican-0.0.4-1.fc7 php-eaccelerator-5.1.6_0.9.5-2.fc7 python-nltk-1.4.4-3.fc7 qt4-qsa-1.2.1-20.fc7 sword-1.5.9-1.fc7 translate-toolkit-0.8-2.fc7 Packages built and released for Fedora Extras 6: 26 anjuta-2.0.2-10.fc6 bugzilla-2.22-7.fc6 csound-5.03.0-9.fc6 doulos-fonts-4.0.14-3.fc6 eclipse-subclipse-1.1.8-2.fc6 eric-3.9.1-4.fc6 fonttools-2.0-0.8.20050624cvs.fc6 galeon-2.0.3-4.fc6 ghc-6.6-1.fc6 gnome-theme-clearlooks-bigpack-0.6-4.fc6 gqview-2.0.3-1.fc6 haddock-0.8-1.fc6 imlib2-1.3.0-3.fc6 jd-1.8.0-0.5.rc061108.fc6 kadu-0.5.0-0.16.rc1.fc6 libopm-0.1-3.20050731cvs.fc6 mail-notification-3.0-10.fc6 maxima-5.10.0-7.fc6 mimedefang-2.58-1.fc6 mod_fcgid-2.0-1.fc6 qt4-qsa-1.2.1-20.fc6 sbcl-0.9.18-1.fc6 tbcload-1.4-3.20061030cvs.fc6 tclcompiler-1.5-2.20061030cvs.fc6 translate-toolkit-0.8-2.fc6 vala-0.0.5-1.fc6 Packages built and released for Fedora Extras 5: 17 bugzilla-2.22-7.fc5 eric-3.9.1-4.fc5 gqview-2.0.3-1.fc5 imlib2-1.3.0-3.fc5 jd-1.8.0-0.5.rc061108.fc5 kadu-0.5.0-0.11.rc1.fc5 libopm-0.1-3.20050731cvs.fc5 maxima-5.10.0-7.fc5 mimedefang-2.58-1.fc5 mod_fcgid-2.0-1.fc5 python-nltk-1.4.4-3.fc5 qt4-qsa-1.2.1-17.fc5 sbcl-0.9.18-1.fc5 taskjuggler-2.3.0-1.fc5 tbcload-1.4-3.20061030cvs.fc5 tclcompiler-1.5-2.20061030cvs.fc5 vala-0.0.5-1.fc5 Packages built and released for Fedora Extras 4: 3 gqview-2.0.3-1.fc4 imlib2-1.2.1-2.fc4 python-nltk-1.4.4-3.fc4 Packages built and released for Fedora Extras 3: 3 galeon-2.0.0-2.fc3 imlib2-1.2.1-2.fc3 python-nltk-1.4.4-3.1.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From michel.salim at gmail.com Thu Nov 9 14:41:11 2006 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 9 Nov 2006 09:41:11 -0500 Subject: Maintenance policy for older releases Message-ID: <883cfe6d0611090641y42844390reebf4412134daab2@mail.gmail.com> Hi, I notice that with certain packages, only the FC-6 tree carries the latest release. The FC-5 release would be stuck at the last release of the software that was out before the release of FC-6, likewise with FC-4, ... . Since FC-5 is still being supported in Core, what is the official line of what Extras need to support? I can understand a maintainer being uncomfortable releasing something he has not tested himself, but for essentially bugfix releases it's probably better than nothing (and that's what bug reports are for anyway). On the other extreme, is it OK to keep pushing updates for deprecated releases, if the packages do not have other packages depending on them? (So it won't trigger the need to rebuild other, potentially-unmaintained, packages) Thanks, -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From buildsys at fedoraproject.org Thu Nov 9 15:28:45 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 09 Nov 2006 15:28:45 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-09 Message-ID: <20061109152845.18230.45515@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 (9 days) centericq - 4.21.0-8.fc6.ppc (9 days) centericq - 4.21.0-8.fc6.x86_64 (9 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (12 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (12 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (12 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (12 days) orange - 0.3-3.cvs20051118.fc6.i386 (16 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (40 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (40 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (40 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc5.i386 sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc5.ppc sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc5.x86_64 sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc6.i386 sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc6.ppc sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc6.x86_64 sylpheed-claws-plugins-etpan-privacy - 2.5.2-5.fc7.i386 sylpheed-claws-plugins-etpan-privacy - 2.5.2-5.fc7.ppc sylpheed-claws-plugins-etpan-privacy - 2.5.2-5.fc7.x86_64 bdpepple AT ameritech.net liferea - 1.0.25-1.fc6.i386 liferea - 1.0.25-1.fc6.ppc liferea - 1.0.25-1.fc6.x86_64 dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (55 days) plague - 0.4.4.1-2.fc3.noarch (55 days) plague - 0.4.4.1-2.fc4.noarch (55 days) plague - 0.4.4.1-2.fc4.noarch (55 days) plague - 0.4.4.1-2.fc4.noarch (55 days) giallu AT gmail.com sysprof - 1.0.5-1.fc6.i386 (6 days) sysprof - 1.0.5-1.fc6.x86_64 (6 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (31 days) linphone - 1.2.0-4.fc5.ppc (31 days) linphone - 1.2.0-4.fc5.x86_64 (31 days) linphone - 1.2.0-7.fc6.i386 (16 days) linphone - 1.2.0-7.fc6.ppc (16 days) linphone - 1.2.0-7.fc6.x86_64 (16 days) michel.salim AT gmail.com python-nltk - 1.4.4-3.1.fc3.noarch python-nltk - 1.4.4-3.1.fc3.noarch oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (21 days) syck-php - 0.55-9.fc5.ppc (21 days) syck-php - 0.55-9.fc5.x86_64 (21 days) petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 ghc-gtk2hs - 0.9.10-4.fc6.i386 ghc-gtk2hs - 0.9.10-4.fc6.ppc ghc-gtk2hs - 0.9.10-4.fc6.ppc ghc-gtk2hs - 0.9.10-4.fc6.x86_64 ghc-gtk2hs - 0.9.10-4.fc6.x86_64 ghc642-gtk2hs - 0.9.10-4.fc6.i386 (6 days) ghc642-gtk2hs - 0.9.10-4.fc6.ppc (6 days) ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 (6 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 (6 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc (6 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 (6 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (11 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 sylpheed-claws-plugins-etpan-privacy-2.5.2-5.fc7.ppc requires libetpan.so.8 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 sylpheed-claws-plugins-etpan-privacy-2.5.2-5.fc7.x86_64 requires libetpan.so.8()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 sylpheed-claws-plugins-etpan-privacy-2.5.2-5.fc7.i386 requires libetpan.so.8 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 liferea-1.0.25-1.fc6.ppc requires firefox = 0:1.5.0.7 linphone-1.2.0-7.fc6.ppc requires libortp.so.2 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc6.ppc requires libetpan.so.8 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 liferea-1.0.25-1.fc6.x86_64 requires firefox = 0:1.5.0.7 linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc6.x86_64 requires libetpan.so.8()(64bit) sysprof-1.0.5-1.fc6.x86_64 requires kmod-sysprof >= 0:1.0.5 Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 liferea-1.0.25-1.fc6.i386 requires firefox = 0:1.5.0.7 linphone-1.2.0-7.fc6.i386 requires libortp.so.2 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc6.i386 requires libetpan.so.8 sysprof-1.0.5-1.fc6.i386 requires kmod-sysprof >= 0:1.0.5 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc5.ppc requires libetpan.so.8 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc5.x86_64 requires libetpan.so.8()(64bit) Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc5.i386 requires libetpan.so.8 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 python-nltk-1.4.4-3.1.fc3.noarch requires python-numarray Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 python-nltk-1.4.4-3.1.fc3.noarch requires python-numarray ====================================================================== New report for: michel.salim AT gmail.com package: python-nltk - 1.4.4-3.1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: python-numarray package: python-nltk - 1.4.4-3.1.fc3.noarch from fedora-extras-3-i386 unresolved deps: python-numarray ====================================================================== New report for: petersen AT redhat.com package: ghc-gtk2hs - 0.9.10-4.fc6.ppc from fedora-extras-6-ppc unresolved deps: ghc = 0:6.4.2 package: ghc-gtk2hs - 0.9.10-4.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: ghc = 0:6.4.2 package: ghc-gtk2hs - 0.9.10-4.fc6.i386 from fedora-extras-6-i386 unresolved deps: ghc = 0:6.4.2 ====================================================================== New report for: bdpepple AT ameritech.net package: liferea - 1.0.25-1.fc6.ppc from fedora-extras-6-ppc unresolved deps: firefox = 0:1.5.0.7 package: liferea - 1.0.25-1.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: firefox = 0:1.5.0.7 package: liferea - 1.0.25-1.fc6.i386 from fedora-extras-6-i386 unresolved deps: firefox = 0:1.5.0.7 From j.w.r.degoede at hhs.nl Thu Nov 9 15:38:45 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 09 Nov 2006 16:38:45 +0100 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <1163081871.7601.93.camel@mccallum.corsepiu.local> References: <45530A78.7040908@hhs.nl> <4553122D.7020604@leemhuis.info> <200611091215.kA9CFH4Y003978@devserv.devel.redhat.com> <45532200.5020807@hhs.nl> <1163081871.7601.93.camel@mccallum.corsepiu.local> Message-ID: <45534B85.6020105@hhs.nl> Ralf Corsepius wrote: > On Thu, 2006-11-09 at 13:41 +0100, Hans de Goede wrote: >> Josh Bressers wrote: >>>> https://www.redhat.com/archives/fedora-extras-list/2006-November/msg00148.html >>>> >>>> Hans de Goede schrieb: > >>> This is currently a non trivial problem to solve. We lack the man power to >>> modify the various problem packages ourselves, so the obvious solution is >>> to let the owner do the work and the security team would only have to step >>> in when the owner is MIA. As soon as the owner builds the new package is >>> magically appears as part of FE. We don't have an easy way to determine >>> when something has been pushed live. >>> >>> The right way to solve this problem is to send announcements for every FE >>> update (security or not), and to let the security team edit security >>> advisories to ensure the proper information is included. >>> >> That is one solution, but given the rolling release model of FE, that are going to >> be a lot of announcements. Why not ask FE package maintainers to send a security >> announcement out when they push an update which has security implications / fixes? > Let me turn this thing around: Why should they? > > I don't see why filing a PR and then giving maintainers a chance to > react should not work. Whether they will be able to react, whether they > will be able to react in reasonable time is a different question. > How and by whom the issue is getting fixed is not the question / problem here. AFAIK the fixing is done by the maintainer in a reasonable amount of time in most cases. The problem I'm trying to address here is that there is no way for end users to find out about FE package updates which are security related. This is BAD, hence my suggestion to ask maintainers to send a security update announcement (in a predefined format / template) to fedora-packages-announce when there is a security related update of an FE package they (the maintainers) maintain. Regards, Hans From icon at fedoraproject.org Thu Nov 9 15:39:46 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Thu, 9 Nov 2006 10:39:46 -0500 Subject: Notice: New maintainer for QScintilla Message-ID: Hi, all: Since I no longer use qscintilla, and have little interest in maintaining it, Rex Dieter has graciously agreed to take over as maintainer. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214192 -- Konstantin Ryabitsev Montr?al, Qu?bec From michel.salim at gmail.com Thu Nov 9 15:43:56 2006 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 9 Nov 2006 10:43:56 -0500 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <45534B85.6020105@hhs.nl> References: <45530A78.7040908@hhs.nl> <4553122D.7020604@leemhuis.info> <200611091215.kA9CFH4Y003978@devserv.devel.redhat.com> <45532200.5020807@hhs.nl> <1163081871.7601.93.camel@mccallum.corsepiu.local> <45534B85.6020105@hhs.nl> Message-ID: <883cfe6d0611090743w703f39e2r2dae7b5e58aeb7dc@mail.gmail.com> On 11/9/06, Hans de Goede wrote: > Ralf Corsepius wrote: > > On Thu, 2006-11-09 at 13:41 +0100, Hans de Goede wrote: > >> Josh Bressers wrote: > >>>> https://www.redhat.com/archives/fedora-extras-list/2006-November/msg00148.html > >>>> > >>>> Hans de Goede schrieb: > > > >>> This is currently a non trivial problem to solve. We lack the man power to > >>> modify the various problem packages ourselves, so the obvious solution is > >>> to let the owner do the work and the security team would only have to step > >>> in when the owner is MIA. As soon as the owner builds the new package is > >>> magically appears as part of FE. We don't have an easy way to determine > >>> when something has been pushed live. > >>> > >>> The right way to solve this problem is to send announcements for every FE > >>> update (security or not), and to let the security team edit security > >>> advisories to ensure the proper information is included. > >>> > >> That is one solution, but given the rolling release model of FE, that are going to > >> be a lot of announcements. Why not ask FE package maintainers to send a security > >> announcement out when they push an update which has security implications / fixes? > > Let me turn this thing around: Why should they? > > > > I don't see why filing a PR and then giving maintainers a chance to > > react should not work. Whether they will be able to react, whether they > > will be able to react in reasonable time is a different question. > > > > How and by whom the issue is getting fixed is not the question / problem here. AFAIK > the fixing is done by the maintainer in a reasonable amount of time in most cases. > > The problem I'm trying to address here is that there is no way for end users > to find out about FE package updates which are security related. This is BAD, hence my > suggestion to ask maintainers to send a security update announcement (in a predefined > format / template) to fedora-packages-announce when there is a security related update of > an FE package they (the maintainers) maintain. > Having a Makefile target for it would be nice. So you do 'make secbuild' or something similar, and then get prompted for a notice. -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From rc040203 at freenet.de Thu Nov 9 15:58:20 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 09 Nov 2006 16:58:20 +0100 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <45534B85.6020105@hhs.nl> References: <45530A78.7040908@hhs.nl> <4553122D.7020604@leemhuis.info> <200611091215.kA9CFH4Y003978@devserv.devel.redhat.com> <45532200.5020807@hhs.nl> <1163081871.7601.93.camel@mccallum.corsepiu.local> <45534B85.6020105@hhs.nl> Message-ID: <1163087901.26926.30.camel@mccallum.corsepiu.local> On Thu, 2006-11-09 at 16:38 +0100, Hans de Goede wrote: > Ralf Corsepius wrote: > > On Thu, 2006-11-09 at 13:41 +0100, Hans de Goede wrote: > >> Josh Bressers wrote: > >>>> https://www.redhat.com/archives/fedora-extras-list/2006-November/msg00148.html > >>>> > >>>> Hans de Goede schrieb: > > > >>> This is currently a non trivial problem to solve. We lack the man power to > >>> modify the various problem packages ourselves, so the obvious solution is > >>> to let the owner do the work and the security team would only have to step > >>> in when the owner is MIA. As soon as the owner builds the new package is > >>> magically appears as part of FE. We don't have an easy way to determine > >>> when something has been pushed live. > >>> > >>> The right way to solve this problem is to send announcements for every FE > >>> update (security or not), and to let the security team edit security > >>> advisories to ensure the proper information is included. > >>> > >> That is one solution, but given the rolling release model of FE, that are going to > >> be a lot of announcements. Why not ask FE package maintainers to send a security > >> announcement out when they push an update which has security implications / fixes? > > Let me turn this thing around: Why should they? > > > > I don't see why filing a PR and then giving maintainers a chance to > > react should not work. Whether they will be able to react, whether they > > will be able to react in reasonable time is a different question. > > > > How and by whom the issue is getting fixed is not the question / problem here. AFAIK > the fixing is done by the maintainer in a reasonable amount of time in most cases. > > The problem I'm trying to address here is that there is no way for end users > to find out about FE package updates which are security related. This is BAD, Why? The only thing that counts to end-users is receiving fixes in timely manners - not users being actively notified about a maintainer claiming to have addressed a particular CVE. The only thing that counts to maintainers is being notified about bugs his packages might suffer from, so he can react upon it and push fixed packages as soon as possible/necessary. The only thing that counts to FE as a whole is somebody taking actioning in reasonable fashion to security related bugs, once somebody gets knowledge about one. > hence my > suggestion to ask maintainers to send a security update announcement (in a predefined > format / template) to fedora-packages-announce when there is a security related update of > an FE package they (the maintainers) maintain. Wasn't it you who recently complained about bureaucracy? To me, what you are doing is asking to increase the bureaucratic burdon to maintainers. Ralf From jkeating at redhat.com Thu Nov 9 15:59:45 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 9 Nov 2006 10:59:45 -0500 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <45534B85.6020105@hhs.nl> References: <45530A78.7040908@hhs.nl> <1163081871.7601.93.camel@mccallum.corsepiu.local> <45534B85.6020105@hhs.nl> Message-ID: <200611091059.48736.jkeating@redhat.com> On Thursday 09 November 2006 10:38, Hans de Goede wrote: > The problem I'm trying to address here is that there is no way for end > users to find out about FE package updates which are security related. This > is BAD, hence my suggestion to ask maintainers to send a security update > announcement (in a predefined format / template) to > fedora-packages-announce when there is a security related update of an FE > package they (the maintainers) maintain. Luke Macken, and others of the infrastructure group, are working on a tool that will facilitate this, and take the guess work out of much of the formatting and the manual bug closing, etc... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Nov 9 16:07:01 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 9 Nov 2006 11:07:01 -0500 Subject: Maintenance policy for older releases In-Reply-To: <883cfe6d0611090641y42844390reebf4412134daab2@mail.gmail.com> References: <883cfe6d0611090641y42844390reebf4412134daab2@mail.gmail.com> Message-ID: <200611091107.01284.jkeating@redhat.com> On Thursday 09 November 2006 09:41, Michel Salim wrote: > Since FC-5 is still being supported in Core, what is the official line > of what Extras need to support? I can understand a maintainer being > uncomfortable releasing something he has not tested himself, but for > essentially bugfix releases it's probably better than nothing (and > that's what bug reports are for anyway). > > On the other extreme, is it OK to keep pushing updates for deprecated > releases, if the packages do not have other packages depending on > them? (So it won't trigger the need to rebuild other, > potentially-unmaintained, packages) Yes, until a release reaches 'maintenance' mode in which only severe bugfixes or security fixes should be issued. See http://fedoraproject.org/wiki/Extras/Policy/EOL -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Nov 9 16:10:51 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 9 Nov 2006 11:10:51 -0500 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <1163087901.26926.30.camel@mccallum.corsepiu.local> References: <45530A78.7040908@hhs.nl> <45534B85.6020105@hhs.nl> <1163087901.26926.30.camel@mccallum.corsepiu.local> Message-ID: <200611091110.52072.jkeating@redhat.com> On Thursday 09 November 2006 10:58, Ralf Corsepius wrote: > The only thing that counts to end-users is receiving fixes in timely > manners - not users being actively notified about a maintainer claiming > to have addressed a particular CVE. There are many users of Fedora in general that wish to only take in security fixes and not 'random update maintainer thought was cool'. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gemi at bluewin.ch Thu Nov 9 16:30:17 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Thu, 09 Nov 2006 17:30:17 +0100 Subject: Maintenance policy for older releases In-Reply-To: <883cfe6d0611090641y42844390reebf4412134daab2@mail.gmail.com> References: <883cfe6d0611090641y42844390reebf4412134daab2@mail.gmail.com> Message-ID: <1163089817.6738.5.camel@scriabin.tannenrauch.ch> On Thu, 2006-11-09 at 09:41 -0500, Michel Salim wrote: > I notice that with certain packages, only the FC-6 tree carries the > latest release. The FC-5 release would be stuck at the last release of > the software that was out before the release of FC-6, likewise with > FC-4, ... . Related to this, I noticed that many new packages are built for development only, and not for FC-6, let alone FC-5. I think that new packages should be built at least for FC-6, unless, of course, there are dependency issues, such as the package depending on a newer package from Core. Another way to look at it is this: if a new package is in FC-6 (and FC-5), bugs are spotted much sooner. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From michel.salim at gmail.com Thu Nov 9 16:52:01 2006 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 9 Nov 2006 11:52:01 -0500 Subject: Maintenance policy for older releases In-Reply-To: <200611091107.01284.jkeating@redhat.com> References: <883cfe6d0611090641y42844390reebf4412134daab2@mail.gmail.com> <200611091107.01284.jkeating@redhat.com> Message-ID: <883cfe6d0611090852g4863fed3l4ddcd78944027c87@mail.gmail.com> On 11/9/06, Jesse Keating wrote: > On Thursday 09 November 2006 09:41, Michel Salim wrote: > > Since FC-5 is still being supported in Core, what is the official line > > of what Extras need to support? I can understand a maintainer being > > uncomfortable releasing something he has not tested himself, but for > > essentially bugfix releases it's probably better than nothing (and > > that's what bug reports are for anyway). > > > > On the other extreme, is it OK to keep pushing updates for deprecated > > releases, if the packages do not have other packages depending on > > them? (So it won't trigger the need to rebuild other, > > potentially-unmaintained, packages) > > Yes, until a release reaches 'maintenance' mode in which only severe bugfixes > or security fixes should be issued. > Thanks for the clarification. > See http://fedoraproject.org/wiki/Extras/Policy/EOL This only states what /not/ to do: if the release is in maintenance state, only security updates should be issued. Is it stated anywhere that for non-maintenance releases, packages should be kept in sync? If not, which document in the Wiki should this be entered in? I could add a reminder in the EOL page if it's needed. Thanks, -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From michel.salim at gmail.com Thu Nov 9 16:52:01 2006 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 9 Nov 2006 11:52:01 -0500 Subject: Maintenance policy for older releases In-Reply-To: <200611091107.01284.jkeating@redhat.com> References: <883cfe6d0611090641y42844390reebf4412134daab2@mail.gmail.com> <200611091107.01284.jkeating@redhat.com> Message-ID: <883cfe6d0611090852g4863fed3l4ddcd78944027c87@mail.gmail.com> On 11/9/06, Jesse Keating wrote: > On Thursday 09 November 2006 09:41, Michel Salim wrote: > > Since FC-5 is still being supported in Core, what is the official line > > of what Extras need to support? I can understand a maintainer being > > uncomfortable releasing something he has not tested himself, but for > > essentially bugfix releases it's probably better than nothing (and > > that's what bug reports are for anyway). > > > > On the other extreme, is it OK to keep pushing updates for deprecated > > releases, if the packages do not have other packages depending on > > them? (So it won't trigger the need to rebuild other, > > potentially-unmaintained, packages) > > Yes, until a release reaches 'maintenance' mode in which only severe bugfixes > or security fixes should be issued. > Thanks for the clarification. > See http://fedoraproject.org/wiki/Extras/Policy/EOL This only states what /not/ to do: if the release is in maintenance state, only security updates should be issued. Is it stated anywhere that for non-maintenance releases, packages should be kept in sync? If not, which document in the Wiki should this be entered in? I could add a reminder in the EOL page if it's needed. Thanks, -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From kevin.kofler at chello.at Thu Nov 9 17:15:08 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 9 Nov 2006 17:15:08 +0000 (UTC) Subject: Disturbing lack of FE security updates announcements! References: <45530A78.7040908@hhs.nl> <4553122D.7020604@leemhuis.info> <200611091215.kA9CFH4Y003978@devserv.devel.redhat.com> <45532200.5020807@hhs.nl> <200611091305.kA9D5Yxx007122@devserv.devel.redhat.com> Message-ID: Josh Bressers writes: > I would rather see a lot of FE announcements than the current lack of > announcements. Right now I run a yum update, and I have no idea what the > extras updates are fixing. This annoys me to no end, and I would be very > surprised if I'm the only one. My "solution" to this problem is to look at the changelog snippets in the repoview. Kevin Kofler From pertusus at free.fr Thu Nov 9 17:52:08 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 9 Nov 2006 18:52:08 +0100 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <200611091110.52072.jkeating@redhat.com> References: <45530A78.7040908@hhs.nl> <45534B85.6020105@hhs.nl> <1163087901.26926.30.camel@mccallum.corsepiu.local> <200611091110.52072.jkeating@redhat.com> Message-ID: <20061109175208.GA2457@free.fr> On Thu, Nov 09, 2006 at 11:10:51AM -0500, Jesse Keating wrote: > On Thursday 09 November 2006 10:58, Ralf Corsepius wrote: > > The only thing that counts to end-users is receiving fixes in timely > > manners - not users being actively notified about a maintainer claiming > > to have addressed a particular CVE. > > There are many users of Fedora in general that wish to only take in security > fixes and not 'random update maintainer thought was cool'. Maybe the best would be to have the infrastructure that allows interested users to do the notification themselves easily without disturbing those who don't care. * if they are maintainers there could be tools such that it is easy to send out an advisory avec a rebuild * for other people there could be a way to watch out the changes in fedora extras packages (%changelogs) and an easy way to issue an advisory based on that. And of course all that should be documented in the wiki. Nothing should be mandatory for the package maintainers, in my opinion. -- From roozbeh at farsiweb.info Thu Nov 9 17:28:08 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Thu, 09 Nov 2006 20:58:08 +0330 Subject: Orphaning two more packages (Re: Orphaning three packages officially) In-Reply-To: <1163017817.4615.24.camel@shalil.farsiweb.info> References: <1163017817.4615.24.camel@shalil.farsiweb.info> Message-ID: <1163093288.3424.25.camel@shalil.farsiweb.info> On Thu, 2006-11-09 at 00:00 +0330, Roozbeh Pournader wrote: > Also, if anyone wants to take maintainership of t1lib and t1utils > (Jos??) please feel free. I don't use these much and would appreciate > someone more familiar with them to take care of them. Apparently I don't seem to have the time for these, so I am also orphaning the two (t1lib and t1utils). Roozbeh From rc040203 at freenet.de Thu Nov 9 18:30:29 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 09 Nov 2006 19:30:29 +0100 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <200611091110.52072.jkeating@redhat.com> References: <45530A78.7040908@hhs.nl> <45534B85.6020105@hhs.nl> <1163087901.26926.30.camel@mccallum.corsepiu.local> <200611091110.52072.jkeating@redhat.com> Message-ID: <1163097030.26926.32.camel@mccallum.corsepiu.local> On Thu, 2006-11-09 at 11:10 -0500, Jesse Keating wrote: > On Thursday 09 November 2006 10:58, Ralf Corsepius wrote: > > The only thing that counts to end-users is receiving fixes in timely > > manners - not users being actively notified about a maintainer claiming > > to have addressed a particular CVE. > > There are many users of Fedora in general that wish to only take in security > fixes and not 'random update maintainer thought was cool'. Urban legend: Fedora user run yum, therefore they get what is being pushed - If they don't run yum, they doen't even get it running. Ralf From rc040203 at freenet.de Thu Nov 9 18:35:15 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 09 Nov 2006 19:35:15 +0100 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <20061109175208.GA2457@free.fr> References: <45530A78.7040908@hhs.nl> <45534B85.6020105@hhs.nl> <1163087901.26926.30.camel@mccallum.corsepiu.local> <200611091110.52072.jkeating@redhat.com> <20061109175208.GA2457@free.fr> Message-ID: <1163097316.26926.38.camel@mccallum.corsepiu.local> On Thu, 2006-11-09 at 18:52 +0100, Patrice Dumas wrote: > On Thu, Nov 09, 2006 at 11:10:51AM -0500, Jesse Keating wrote: > > On Thursday 09 November 2006 10:58, Ralf Corsepius wrote: > > > The only thing that counts to end-users is receiving fixes in timely > > > manners - not users being actively notified about a maintainer claiming > > > to have addressed a particular CVE. > > > > There are many users of Fedora in general that wish to only take in security > > fixes and not 'random update maintainer thought was cool'. > > Maybe the best would be to have the infrastructure that allows interested > users to do the notification themselves easily without disturbing those who > don't care. c.f. my previous posting. We are discussion a non-argument here. If you want a "security only" update medium, this should be integrated into yum. The fundamental question would be how that would be useful and how to separate "security updates" from "ordinary updates". Also consider that many FE maintainers don't really care about security, many "simply package". Also consider that many of the packages in Fedora qualify as "exotic niche packages" which don't have a real "security monitoring" record. Ralf From michel.salim at gmail.com Thu Nov 9 18:48:13 2006 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 9 Nov 2006 13:48:13 -0500 Subject: Package removal request? Message-ID: <883cfe6d0611091048p1b0c54fi36455ca5f269dfd6@mail.gmail.com> I accidentally pushed python-nltk-1.4.4-3.1 for Fedora Extras 3 when updating the package to comply with the new Python packaging policy. It depends at runtime on python-numarray, which is Fedora >= 4 only. Could this offending package be removed from the repository? Also, python-nltk-1.4.2 might have to be removed from FE3 - upstream claimed it only depends on python-numeric, but on closer examination I found a file that depends on numarray as well. If there's a more appropriate channel for this request, please advise, and I'll use it if I need to request the removal of 1.4.2 as well. Thanks, -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From j.w.r.degoede at hhs.nl Thu Nov 9 19:16:46 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 09 Nov 2006 20:16:46 +0100 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <200611091110.52072.jkeating@redhat.com> References: <45530A78.7040908@hhs.nl> <45534B85.6020105@hhs.nl> <1163087901.26926.30.camel@mccallum.corsepiu.local> <200611091110.52072.jkeating@redhat.com> Message-ID: <45537E9E.90807@hhs.nl> Jesse Keating wrote: > On Thursday 09 November 2006 10:58, Ralf Corsepius wrote: >> The only thing that counts to end-users is receiving fixes in timely >> manners - not users being actively notified about a maintainer claiming >> to have addressed a particular CVE. > > There are many users of Fedora in general that wish to only take in security > fixes and not 'random update maintainer thought was cool'. > Exactly Regards, Hans From j.w.r.degoede at hhs.nl Thu Nov 9 19:19:12 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 09 Nov 2006 20:19:12 +0100 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <1163087901.26926.30.camel@mccallum.corsepiu.local> References: <45530A78.7040908@hhs.nl> <4553122D.7020604@leemhuis.info> <200611091215.kA9CFH4Y003978@devserv.devel.redhat.com> <45532200.5020807@hhs.nl> <1163081871.7601.93.camel@mccallum.corsepiu.local> <45534B85.6020105@hhs.nl> <1163087901.26926.30.camel@mccallum.corsepiu.local> Message-ID: <45537F30.8070501@hhs.nl> Ralf Corsepius wrote: >> The problem I'm trying to address here is that there is no way for end users >> to find out about FE package updates which are security related. This is BAD, > Why? > > The only thing that counts to end-users is receiving fixes in timely > manners - not users being actively notified about a maintainer claiming > to have addressed a particular CVE. > More conservative users may only want to upgrade because either they want a new feature / bugfix, or because of a security issue. For those users knowing this is important. > Wasn't it you who recently complained about bureaucracy? To me, what you > are doing is asking to increase the bureaucratic burdon to maintainers. > I maintain 80 + packages, yet I have done only 3 security fixes this whole year. Aaiee sending 3 announcements mails every year the sheer horror :) No, seriously I'm very much against bureaucracy and this and this aint it. Regards, Hans From j.w.r.degoede at hhs.nl Thu Nov 9 19:20:41 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 09 Nov 2006 20:20:41 +0100 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <200611091059.48736.jkeating@redhat.com> References: <45530A78.7040908@hhs.nl> <1163081871.7601.93.camel@mccallum.corsepiu.local> <45534B85.6020105@hhs.nl> <200611091059.48736.jkeating@redhat.com> Message-ID: <45537F89.1030900@hhs.nl> Jesse Keating wrote: > On Thursday 09 November 2006 10:38, Hans de Goede wrote: >> The problem I'm trying to address here is that there is no way for end >> users to find out about FE package updates which are security related. This >> is BAD, hence my suggestion to ask maintainers to send a security update >> announcement (in a predefined format / template) to >> fedora-packages-announce when there is a security related update of an FE >> package they (the maintainers) maintain. > > Luke Macken, and others of the infrastructure group, are working on a tool > that will facilitate this, and take the guess work out of much of the > formatting and the manual bug closing, etc... > > GOOD! ETA? Regards, Hans From nicolas.mailhot at laposte.net Thu Nov 9 19:15:58 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 09 Nov 2006 20:15:58 +0100 Subject: Maintenance policy for older releases In-Reply-To: <883cfe6d0611090852g4863fed3l4ddcd78944027c87@mail.gmail.com> References: <883cfe6d0611090641y42844390reebf4412134daab2@mail.gmail.com> <200611091107.01284.jkeating@redhat.com> <883cfe6d0611090852g4863fed3l4ddcd78944027c87@mail.gmail.com> Message-ID: <1163099762.13735.13.camel@rousalka.dyndns.org> Le jeudi 09 novembre 2006 ? 11:52 -0500, Michel Salim a ?crit : > > See http://fedoraproject.org/wiki/Extras/Policy/EOL > This only states what /not/ to do: if the release is in maintenance > state, only security updates should be issued. Is it stated anywhere > that for non-maintenance releases, packages should be kept in sync? If > not, which document in the Wiki should this be entered in? Some maintainers like to sync all non-maintenance releases. My understanding is it's a maintainer preference, neither officially frowned upon nor actively encouraged. The wiki accurately reflects this. Please note while it would be possible to forbid syncing in the absence of a problem in the current package, forcing syncing is impossible since some updates depend on changes in other packages (including core ones which are *not* synced). Also, 100% syncing would basically mean everyone is running rawhide. For those reasons I personally feel we'll move to a release model closer to Core for Extras once the QA pressure mounts enough. Pushing packages directly from devel to last release means they don't get good testing. Once you accept the need for staging releases Fedora cycles are short enough people who don't which to live on the bleeding edge can wait for the next release for updates (and people who do want the bleeding edge can run devel) -- Nicolas Mailhot From bugs.michael at gmx.net Thu Nov 9 21:08:30 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 9 Nov 2006 22:08:30 +0100 Subject: Package removal request? In-Reply-To: <883cfe6d0611091048p1b0c54fi36455ca5f269dfd6@mail.gmail.com> References: <883cfe6d0611091048p1b0c54fi36455ca5f269dfd6@mail.gmail.com> Message-ID: <20061109220830.dfb80eac.bugs.michael@gmx.net> On Thu, 9 Nov 2006 13:48:13 -0500, Michel Salim wrote: > I accidentally pushed python-nltk-1.4.4-3.1 for Fedora Extras 3 when > updating the package to comply with the new Python packaging policy. > It depends at runtime on python-numarray, which is Fedora >= 4 only. > > Could this offending package be removed from the repository? Also, > python-nltk-1.4.2 might have to be removed from FE3 - upstream claimed > it only depends on python-numeric, but on closer examination I found a > file that depends on numarray as well. > > If there's a more appropriate channel for this request, please advise, > and I'll use it if I need to request the removal of 1.4.2 as well. > > Thanks, http://fedoraproject.org/wiki/Extras/RepoRequests (linked from the Extras main page) From bugs.michael at gmx.net Fri Nov 10 00:14:10 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 10 Nov 2006 01:14:10 +0100 Subject: rpms/seamonkey/FC-5 dead.package, NONE, 1.1 Makefile, 1.1, NONE find-external-requires, 1.1, NONE firefox-0.7.3-default-plugin-less-annoying.patch, 1.1, NONE firefox-0.7.3-psfonts.patch, 1.1, NONE firefox-1.0-prdtoa.patch, 1.1, NONE firefox-1.1-nss-system-nspr.patch, 1.1, NONE firefox-1.1-uriloader.patch, 1.1, NONE firefox-1.1-visibility.patch, 1.1, NONE firefox-1.5-with-system-nss.patch, 1.1, NONE firefox-1.5.0.1-dumpstack.patch, 1.1, NONE mozilla-1.4.1-ppc64.patch, 1.1, NONE mozilla-1.7.3-gnome-vfs-default-app.patch, 1.1, NONE mozilla-1.7.5-g-application-name.patch, 1.1, NONE mozilla-nspr-packages.patch, 1.1, NONE mozilla-psm-exclude-list, 1.1, NONE mozilla-xpcom-exclude-list, 1.1, NONE pango-cairo.patch, 1.1, NONE seamonkey-1.0.1-dumpstack.patch, 1.1, NONE seamonkey-cairo-bug5136.patch, 1.1, NONE seamonkey-configure.patch, 1.4, NONE seamonkey-disable-visibility.patch, 1.1, NONE seamonkey-fedora-default-bookmarks.html, 1.1, NONE seamonkey-fedora-default-prefs.js, 1.2, NONE seamonkey-fedora-home-page.patch, 1.1, NONE seamonkey-icon.png, 1.1, NONE seamonkey-mail-icon.png, 1.1, NONE seamonkey-mail.desktop, 1.1, NONE seamonkey-make-package.pl, 1.1, NONE seamonkey-mozconfig, 1.1, NONE seamonkey.desktop, 1.1, NONE seamonkey.sh.in, 1.1, NONE seamonkey.spec, 1.7, NONE sources, 1.6, NONE thunderbird-0.7.3-gnome-uriloader.patch, 1.1, NONE thunderbird-1.5-bug304720.patch, 1.1, NONE In-Reply-To: <200611091805.kA9I5Phg015046@cvs-int.fedora.redhat.com> References: <200611091805.kA9I5Phg015046@cvs-int.fedora.redhat.com> Message-ID: <20061110011410.8c262d3f.bugs.michael@gmx.net> On Thu, 9 Nov 2006 11:05:25 -0700, Kai Engert (kengert) wrote: > Author: kengert > > Update of /cvs/extras/rpms/seamonkey/FC-5 > Added Files: > dead.package > Log Message: > The SeaMonkey Fedora Extras package for FC5 > will be moved to Fedora Core > and it will made to obsolete the Mozilla package. Please clarify! 1.) Package is still alive in Fedora Extras branches "FC-6" and "devel". 2.) If the package is moved to Core (= Rawhide = FC7 devel), you are supposed to mark it dead in FE "devel", not in the FC-5 branch. 3.) What happens to the FE5 and FE6 packages? Remember, FE5 and FE6 are stable branches of Fedora Extras! This is a rather crude way of using Extras as a testbed, then moving a package to Core and discontinueing it in Extras. From sundaram at fedoraproject.org Fri Nov 10 00:15:03 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 10 Nov 2006 05:45:03 +0530 Subject: rpms/seamonkey/FC-5 dead.package, NONE, 1.1 Makefile, 1.1, NONE find-external-requires, 1.1, NONE firefox-0.7.3-default-plugin-less-annoying.patch, 1.1, NONE firefox-0.7.3-psfonts.patch, 1.1, NONE firefox-1.0-prdtoa.patch, 1.1, NONE firefox-1.1-nss-system-nspr.patch, 1.1, NONE firefox-1.1-uriloader.patch, 1.1, NONE firefox-1.1-visibility.patch, 1.1, NONE firefox-1.5-with-system-nss.patch, 1.1, NONE firefox-1.5.0.1-dumpstack.patch, 1.1, NONE mozilla-1.4.1-ppc64.patch, 1.1, NONE mozilla-1.7.3-gnome-vfs-default-app.patch, 1.1, NONE mozilla-1.7.5-g-application-name.patch, 1.1, NONE mozilla-nspr-packages.patch, 1.1, NONE mozilla-psm-exclude-list, 1.1, NONE mozilla-xpcom-exclude-list, 1.1, NONE pango-cairo.patch, 1.1, NONE seamonkey-1.0.1-dumpstack.patch, 1.1, NONE seamonkey-cairo-bug5136.patch, 1.1, NONE seamonkey-configure.patch, 1.4, NONE seamonkey-disable-visibility.patch, 1.1, NONE seamonkey-fedora-default-bookmarks.html, 1.1, NONE seamonkey-fedora-default-prefs.js, 1.2, NONE seamonkey-fedora-home-page.patch, 1.1, NONE seamonkey-icon.png, 1.1, NONE seamonkey-mail-icon.png, 1.1, NONE seamonkey-mail.desktop, 1.1, NONE seamonkey-make-package.pl, 1.1, NONE seamonkey-mozconfig, 1.1, NONE seamonkey.desktop, 1.1, NONE seamonkey.sh.in, 1.1, NONE seamonkey.spec, 1.7, NONE sources, 1.6, NONE thunderbird-0.7.3-gnome-uriloader.patch, 1.1, NONE thunderbird-1.5-bug304720.patch, 1.1, NONE In-Reply-To: <20061110011410.8c262d3f.bugs.michael@gmx.net> References: <200611091805.kA9I5Phg015046@cvs-int.fedora.redhat.com> <20061110011410.8c262d3f.bugs.michael@gmx.net> Message-ID: <4553C487.10508@fedoraproject.org> Michael Schwendt wrote: > On Thu, 9 Nov 2006 11:05:25 -0700, Kai Engert (kengert) wrote: > >> Author: kengert >> >> Update of /cvs/extras/rpms/seamonkey/FC-5 > >> Added Files: >> dead.package > >> Log Message: >> The SeaMonkey Fedora Extras package for FC5 >> will be moved to Fedora Core >> and it will made to obsolete the Mozilla package. > > Please clarify! > > 1.) Package is still alive in Fedora Extras branches "FC-6" and "devel". > > 2.) If the package is moved to Core (= Rawhide = FC7 devel), you are > supposed to mark it dead in FE "devel", not in the FC-5 branch. > > 3.) What happens to the FE5 and FE6 packages? Remember, FE5 and FE6 > are stable branches of Fedora Extras! > > This is a rather crude way of using Extras as a testbed, then moving a > package to Core and discontinueing it in Extras. ... and since we are working on eliminating the differences between these two repositories, it is completely unnecessary to do package movements at this point. Where was this discussed anyway? Rahul From sundaram at fedoraproject.org Fri Nov 10 00:21:33 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 10 Nov 2006 05:51:33 +0530 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <45537F89.1030900@hhs.nl> References: <45530A78.7040908@hhs.nl> <1163081871.7601.93.camel@mccallum.corsepiu.local> <45534B85.6020105@hhs.nl> <200611091059.48736.jkeating@redhat.com> <45537F89.1030900@hhs.nl> Message-ID: <4553C60D.2090203@fedoraproject.org> Hans de Goede wrote: > > Jesse Keating wrote: >> On Thursday 09 November 2006 10:38, Hans de Goede wrote: >>> The problem I'm trying to address here is that there is no way for end >>> users to find out about FE package updates which are security related. This >>> is BAD, hence my suggestion to ask maintainers to send a security update >>> announcement (in a predefined format / template) to >>> fedora-packages-announce when there is a security related update of an FE >>> package they (the maintainers) maintain. >> Luke Macken, and others of the infrastructure group, are working on a tool >> that will facilitate this, and take the guess work out of much of the >> formatting and the manual bug closing, etc... >> >> > > GOOD! ETA? See https://www.redhat.com/archives/fedora-devel-list/2006-November/msg00149.html Rahul From michel.salim at gmail.com Fri Nov 10 00:27:31 2006 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 9 Nov 2006 19:27:31 -0500 Subject: Package removal request? In-Reply-To: <20061109220830.dfb80eac.bugs.michael@gmx.net> References: <883cfe6d0611091048p1b0c54fi36455ca5f269dfd6@mail.gmail.com> <20061109220830.dfb80eac.bugs.michael@gmx.net> Message-ID: <883cfe6d0611091627i4fec06ebh999131ca19111ac3@mail.gmail.com> On 11/9/06, Michael Schwendt wrote: > On Thu, 9 Nov 2006 13:48:13 -0500, Michel Salim wrote: > > > I accidentally pushed python-nltk-1.4.4-3.1 for Fedora Extras 3 when > > updating the package to comply with the new Python packaging policy. > > It depends at runtime on python-numarray, which is Fedora >= 4 only. > > > > Could this offending package be removed from the repository? Also, > > python-nltk-1.4.2 might have to be removed from FE3 - upstream claimed > > it only depends on python-numeric, but on closer examination I found a > > file that depends on numarray as well. > > > > If there's a more appropriate channel for this request, please advise, > > and I'll use it if I need to request the removal of 1.4.2 as well. > > > > Thanks, > > http://fedoraproject.org/wiki/Extras/RepoRequests > (linked from the Extras main page) > Ah yes. Sorry for not noticing that. Incidentally, what constitutes an update? Would pushing a new package with a lower version number do it, or would a manual removal be required in this case. Thanks, -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From bugs.michael at gmx.net Fri Nov 10 00:47:46 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 10 Nov 2006 01:47:46 +0100 Subject: Package removal request? In-Reply-To: <883cfe6d0611091627i4fec06ebh999131ca19111ac3@mail.gmail.com> References: <883cfe6d0611091048p1b0c54fi36455ca5f269dfd6@mail.gmail.com> <20061109220830.dfb80eac.bugs.michael@gmx.net> <883cfe6d0611091627i4fec06ebh999131ca19111ac3@mail.gmail.com> Message-ID: <20061110014746.cabce594.bugs.michael@gmx.net> On Thu, 9 Nov 2006 19:27:31 -0500, Michel Salim wrote: > > On Thu, 9 Nov 2006 13:48:13 -0500, Michel Salim wrote: > > > > > I accidentally pushed python-nltk-1.4.4-3.1 for Fedora Extras 3 when > > > updating the package to comply with the new Python packaging policy. > > > It depends at runtime on python-numarray, which is Fedora >= 4 only. > > > > > > Could this offending package be removed from the repository? Also, > > > python-nltk-1.4.2 might have to be removed from FE3 - upstream claimed > > > it only depends on python-numeric, but on closer examination I found a > > > file that depends on numarray as well. > > > > > > If there's a more appropriate channel for this request, please advise, > > > and I'll use it if I need to request the removal of 1.4.2 as well. > > > > > > Thanks, > > > > http://fedoraproject.org/wiki/Extras/RepoRequests > > (linked from the Extras main page) > > > Ah yes. Sorry for not noticing that. Incidentally, what constitutes an > update? Would pushing a new package with a lower version number do it, > or would a manual removal be required in this case. Publishing packages with a lower version number is an invalid operation, even if the current release may refuse to install due to bad dependencies. Remember, highest EVR wins, so your old package would not even be seen after the usual RPM version comparison as long as the newer one is also in the repository. Just request package removal (I could do it based on what you write above, but you're not clear about python-nltk). It's not complicated to remove packages. Removing the src.rpm will suffice. The binaries are killed automatically when they lose their mother src.rpm package. From kevin.kofler at chello.at Fri Nov 10 01:16:41 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 10 Nov 2006 01:16:41 +0000 (UTC) Subject: Seamonkey Message-ID: > ... and since we are working on eliminating the differences between these two > repositories, it is completely unnecessary to do package movements at this > point. Where was this discussed anyway? Look at the fedora-legacy-list archives. RHEL already got Seamonkey as a replacement for Mozilla months ago. Now there's yet another set of security holes, apparently rated critical (in addition to all the pending ones!). So it's urgent to do something about this, waiting for Core and Extras to merge is not a good idea. Legacy is going to push Seamonkey as a Mozilla replacement for FC3 and FC4, so it only makes sense for FC5 to get the same treatment. FC6 and FC7 are NOT affected because they don't ship the vulnerable Mozilla Suite 1.7.x, so Seamonkey is (AFAIK) not going to move to Core for these releases. Ask Michal Jaegermann from Legacy and Christopher Aillon from Core for details. Kevin Kofler From jkeating at redhat.com Fri Nov 10 03:40:55 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 9 Nov 2006 22:40:55 -0500 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <1163097030.26926.32.camel@mccallum.corsepiu.local> References: <45530A78.7040908@hhs.nl> <200611091110.52072.jkeating@redhat.com> <1163097030.26926.32.camel@mccallum.corsepiu.local> Message-ID: <200611092240.59260.jkeating@redhat.com> On Thursday 09 November 2006 13:30, Ralf Corsepius wrote: > > There are many users of Fedora in general that wish to only take in > > security fixes and not 'random update maintainer thought was cool'. > > Urban legend: Fedora user run yum, therefore they get what is being > pushed - If they don't run yum, they doen't even get it running. With a proper update tool, you can mark an update as being a security update, and it will show as such in things like pirut. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Nov 10 03:44:15 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 9 Nov 2006 22:44:15 -0500 Subject: Maintenance policy for older releases In-Reply-To: <1163089817.6738.5.camel@scriabin.tannenrauch.ch> References: <883cfe6d0611090641y42844390reebf4412134daab2@mail.gmail.com> <1163089817.6738.5.camel@scriabin.tannenrauch.ch> Message-ID: <200611092244.15197.jkeating@redhat.com> On Thursday 09 November 2006 11:30, G?rard Milmeister wrote: > Related to this, I noticed that many new packages are built for > development only, and not for FC-6, let alone FC-5. I think that > new packages should be built at least for FC-6, unless, of course, > there are dependency issues, such as the package depending on a newer > package from Core. Another way to look at it is this: if a new package > is in FC-6 (and FC-5), bugs are spotted much sooner. However, FC-6 and FC-5 are not your beta testers. Development is the place to test things, users of development are used to or at least expect breakage. Just lobbing packages over the wall to stable releases is just pissing on the users. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Fri Nov 10 04:45:42 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 10 Nov 2006 05:45:42 +0100 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <200611092240.59260.jkeating@redhat.com> References: <45530A78.7040908@hhs.nl> <200611091110.52072.jkeating@redhat.com> <1163097030.26926.32.camel@mccallum.corsepiu.local> <200611092240.59260.jkeating@redhat.com> Message-ID: <1163133942.456.33.camel@mccallum.corsepiu.local> On Thu, 2006-11-09 at 22:40 -0500, Jesse Keating wrote: > On Thursday 09 November 2006 13:30, Ralf Corsepius wrote: > > > There are many users of Fedora in general that wish to only take in > > > security fixes and not 'random update maintainer thought was cool'. > > > > Urban legend: Fedora user run yum, therefore they get what is being > > pushed - If they don't run yum, they doen't even get it running. > > With a proper update tool, you can mark an update as being a security update, > and it will show as such in things like pirut. How does pirut access other sources of information than yum does (repos and rpms)? Ralf From jkeating at redhat.com Fri Nov 10 04:52:39 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 9 Nov 2006 23:52:39 -0500 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <1163133942.456.33.camel@mccallum.corsepiu.local> References: <45530A78.7040908@hhs.nl> <200611092240.59260.jkeating@redhat.com> <1163133942.456.33.camel@mccallum.corsepiu.local> Message-ID: <200611092352.40096.jkeating@redhat.com> On Thursday 09 November 2006 23:45, Ralf Corsepius wrote: > How does pirut access other sources of information than yum does (repos > and rpms)? It doesn't, the info would be available to yum too, it would be embedded in the repodata. Pirut is just a decent way of displaying the information. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Nov 10 04:53:28 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 10 Nov 2006 10:23:28 +0530 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <1163133942.456.33.camel@mccallum.corsepiu.local> References: <45530A78.7040908@hhs.nl> <200611091110.52072.jkeating@redhat.com> <1163097030.26926.32.camel@mccallum.corsepiu.local> <200611092240.59260.jkeating@redhat.com> <1163133942.456.33.camel@mccallum.corsepiu.local> Message-ID: <455405C8.9040103@fedoraproject.org> Ralf Corsepius wrote: > On Thu, 2006-11-09 at 22:40 -0500, Jesse Keating wrote: >> On Thursday 09 November 2006 13:30, Ralf Corsepius wrote: >>>> There are many users of Fedora in general that wish to only take in >>>> security fixes and not 'random update maintainer thought was cool'. >>> Urban legend: Fedora user run yum, therefore they get what is being >>> pushed - If they don't run yum, they doen't even get it running. >> With a proper update tool, you can mark an update as being a security update, >> and it will show as such in things like pirut. > > How does pirut access other sources of information than yum does (repos > and rpms)? It doesnt have to. The metadata is already there. Luke did that work at http://people.redhat.com/lmacken/metadata/ Rahul From bugs.michael at gmx.net Fri Nov 10 10:07:15 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 10 Nov 2006 11:07:15 +0100 Subject: Seamonkey In-Reply-To: References: Message-ID: <20061110110715.ac0cd6e3.bugs.michael@gmx.net> On Fri, 10 Nov 2006 01:16:41 +0000 (UTC), Kevin Kofler wrote: > > ... and since we are working on eliminating the differences between these two > > repositories, it is completely unnecessary to do package movements at this > > point. Where was this discussed anyway? > > Look at the fedora-legacy-list archives. RHEL already got Seamonkey as a > replacement for Mozilla months ago. Now there's yet another set of security > holes, apparently rated critical (in addition to all the pending ones!). So > it's urgent to do something about this, waiting for Core and Extras to merge is > not a good idea. Legacy is going to push Seamonkey as a Mozilla replacement for > FC3 and FC4, so it only makes sense for FC5 to get the same treatment. FC6 and > FC7 are NOT affected because they don't ship the vulnerable Mozilla Suite > 1.7.x, so Seamonkey is (AFAIK) not going to move to Core for these releases. > Ask Michal Jaegermann from Legacy and Christopher Aillon from Core for details. > Aha. So, the message in the "dead.package" file could have read: The SeaMonkey Fedora Extras package for FC5 will be moved to Fedora Core _5_ <-- (!) and it will made to obsolete the Mozilla package. IMO, it's somewhat intimidating that in order to learn about the background of such package movement it is pointed to _another_ mailing-list. I would have expected this to be a topic on fedora-devel-list. From fedora at leemhuis.info Fri Nov 10 10:39:22 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 10 Nov 2006 11:39:22 +0100 Subject: Maintenance policy for older releases In-Reply-To: <1163099762.13735.13.camel@rousalka.dyndns.org> References: <883cfe6d0611090641y42844390reebf4412134daab2@mail.gmail.com> <200611091107.01284.jkeating@redhat.com> <883cfe6d0611090852g4863fed3l4ddcd78944027c87@mail.gmail.com> <1163099762.13735.13.camel@rousalka.dyndns.org> Message-ID: <455456DA.5000005@leemhuis.info> Nicolas Mailhot schrieb: > Le jeudi 09 novembre 2006 ? 11:52 -0500, Michel Salim a ?crit : > [...] > Also, 100% syncing would basically mean > everyone is running rawhide. Exactly. That's why I normally build my packages for devel first and some days later for FC(current), and normally not for FC(current-1) as I assume that those that still run FC(current-1) are more interested in running stable packages. > For those reasons I personally feel we'll move to a release model closer > to Core for Extras once [...] ...once they merge, and that's currently the rough plan that exactly that might happen by FC7. By then we also probably should use the same tools for pushing updates out (and security notices, too). And a updates-testing either for the whole Fedora Package Universe, or nowhere. And similar rules for Updates in the whole Fedora Package Universe. Much to think about/discuss and implement. CU thl From j.w.r.degoede at hhs.nl Fri Nov 10 11:09:47 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 10 Nov 2006 12:09:47 +0100 Subject: Buildsys troubles Message-ID: <45545DFB.5010207@hhs.nl> Hi, I wanted to report this through the infrastructure bugtracker, but I couldn't find a link to it and don't know the URL, perhaps putting a link to this on http://buildsys.fedoraproject.org/ is a good idea? Anyways, my builds are failing consistently with the following error: Waiting for repository to unlock before starting the build... Job waited too long for repo to unlock. Killing it... Killing build process... Cleaning up the buildroot... /usr/bin/setarch ppc32 /usr/bin/mock clean --uniqueext=243e07168c8d639c4b40180c4a4f0d89a5c7ae6f -r fedora-development-ppc-core Killed. Waiting for child process 17173 to exit. Regards, Hans From mtasaka at ioa.s.u-tokyo.ac.jp Fri Nov 10 11:19:37 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 10 Nov 2006 20:19:37 +0900 Subject: Buildsys troubles In-Reply-To: <45545DFB.5010207@hhs.nl> References: <45545DFB.5010207@hhs.nl> Message-ID: <45546049.1060902@ioa.s.u-tokyo.ac.jp> Hans de Goede wrote: > Hi, > > I wanted to report this through the infrastructure bugtracker, but I > couldn't find a link to it and don't know the URL, perhaps putting a > link to this on http://buildsys.fedoraproject.org/ is a good idea? There was a bugzilla entry for Fedora infrastructure, however it seems to have disappeared...... My bugzilla entry is: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200616 Mamoru Tasaka From buildsys at fedoraproject.org Fri Nov 10 12:03:40 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 10 Nov 2006 07:03:40 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-10 Message-ID: <20061110120340.9B6CE15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 24 PyKDE-3.16.0-5.fc7 PyQt-qscintilla-3.17-2.fc7 audacious-1.1.2-8.fc7 beneath-a-steel-sky-0.0348-2 cacti-0.8.6i-4.fc7 ccrtp-1.5.0-1.fc7 charis-fonts-4.0.02-3.fc7 commoncpp2-1.5.0-1.fc7 dd_rescue-1.12-4.fc7 doulos-fonts-4.0.14-4.fc7 fonttools-2.0-0.9.20060223cvs.fc7 galeon-2.0.3-4.fc7 ganglia-3.0.3-11.fc7 gentium-fonts-1.02-5.fc7 gperiodic-2.0.8-5.fc7 libapreq2-2.09-0.rc2.1.fc7 libmthca-1.0.3-1.fc7 mboxgrep-0.7.9-4.fc7 mod_suphp-0.6.1-4.fc7 pungi-0.1.0-1.fc7 qscintilla-1.7-1.fc7 sparse-0.1-1.fc7 subversion-api-docs-1.4.2-2.fc7 translate-toolkit-0.10.1-1.fc7 Packages built and released for Fedora Extras 6: 23 Invalid rebuild: gperiodic-2.0.8-5.fc7 PyKDE-3.16.0-5.fc6 cacti-0.8.6i-4.fc6 ccrtp-1.5.0-1.fc6 commoncpp2-1.5.0-1.fc6 dd_rescue-1.12-4.fc6 doulos-fonts-4.0.14-4.fc6 ganglia-3.0.3-11.fc6 libapreq2-2.09-0.rc2.1.fc6 libmthca-1.0.3-1.fc6 liferea-1.0.25-2.fc6 linphone-1.5.0-2.fc6 mboxgrep-0.7.9-4.fc6 mod_suphp-0.6.1-4.fc6 php-pear-HTTP-Request-1.4.0-1.fc6 php-pear-Net-FTP-1.3.2-1.fc6.1 php-pear-Net-URL-1.0.14-1.fc6 php-pear-Pager-2.4.2-1.fc6 scummvm-0.9.1-1.fc6 sparse-0.1-1.fc6 tracker-0.5.1-1.fc6 translate-toolkit-0.10.1-1.fc6 yumex-1.2.0-1.0.fc6 Packages built and released for Fedora Extras 5: 17 cacti-0.8.6i-4.fc5 ccrtp-1.5.0-1.fc5 commoncpp2-1.5.0-1.fc5 doulos-fonts-4.0.14-4.fc5 ganglia-3.0.3-8.fc5 gperiodic-2.0.8-5.fc5 libmthca-1.0.3-1.fc5 mboxgrep-0.7.9-4.fc5 mod_suphp-0.6.1-4.fc5 php-pear-HTTP-Request-1.4.0-1.fc5 php-pear-Net-FTP-1.3.2-1.fc5 php-pear-Net-URL-1.0.14-1.fc5 php-pear-Pager-2.4.2-1.fc5 scummvm-0.9.1-1.fc5 sparse-0.1-1.fc5 tracker-0.5.1-1.fc5 translate-toolkit-0.10.1-1.fc5 Packages built and released for Fedora Extras 4: 3 bugzilla-2.22-7.fc4 cacti-0.8.6i-4.fc4 libmthca-1.0.3-1.fc4 Packages built and released for Fedora Extras 3: 1 cacti-0.8.6i-4.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From Christian.Iseli at licr.org Fri Nov 10 12:47:31 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 10 Nov 2006 13:47:31 +0100 Subject: Buildsys troubles In-Reply-To: <45545DFB.5010207@hhs.nl> References: <45545DFB.5010207@hhs.nl> Message-ID: <20061110134731.499b86c8@ludwig-alpha.unil.ch> Hi Hans, On Fri, 10 Nov 2006 12:09:47 +0100, Hans de Goede wrote: > I wanted to report this through the infrastructure bugtracker, but I couldn't find a link to it and don't know the URL, perhaps putting a link to this on > http://buildsys.fedoraproject.org/ is a good idea? Probably a link there would be useful: http://fedoraproject.org/wiki/Infrastructure/Tickets The ticket system itself lives here: https://admin.fedoraproject.org/tickets/ Cheers, C From bugs.michael at gmx.net Fri Nov 10 12:57:45 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 10 Nov 2006 13:57:45 +0100 Subject: Fedora Extras Package Build Report 2006-11-10 In-Reply-To: <20061110120340.9B6CE15212E@buildsys.fedoraproject.org> References: <20061110120340.9B6CE15212E@buildsys.fedoraproject.org> Message-ID: <20061110135745.3091fbe7.bugs.michael@gmx.net> On Fri, 10 Nov 2006 07:03:40 -0500 (EST), buildsys at fedoraproject.org wrote: > Packages built and released for Fedora Extras 6: 23 > > Invalid rebuild: gperiodic-2.0.8-5.fc7 Caution! Something weird here again. .fc6 rebuilds with a .fc7 build job name: http://buildsys.fedoraproject.org/plague-results/fedora-6-extras/gperiodic/2.0.8-5.fc7/ And here FC-6 build with .fc7 src.rpm: http://buildsys.fedoraproject.org/logs/fedora-6-extras/21283-gperiodic-2.0.8-5.fc7/ No time to examine whether it's user mistake or buildsys confusion. I'm glad we block such builds from entering the repo. From buildsys at fedoraproject.org Fri Nov 10 13:10:29 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 10 Nov 2006 13:10:29 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-10 Message-ID: <20061110131029.17264.68967@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 (10 days) centericq - 4.21.0-8.fc6.ppc (10 days) centericq - 4.21.0-8.fc6.x86_64 (10 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (13 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (13 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (13 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (13 days) orange - 0.3-3.cvs20051118.fc6.i386 (17 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (41 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (41 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (41 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc5.i386 (2 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc5.ppc (2 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc5.x86_64 (2 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc6.i386 (2 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc6.ppc (2 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc6.x86_64 (2 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-5.fc7.i386 (2 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-5.fc7.ppc (2 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-5.fc7.x86_64 (2 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (56 days) plague - 0.4.4.1-2.fc3.noarch (56 days) plague - 0.4.4.1-2.fc4.noarch (56 days) plague - 0.4.4.1-2.fc4.noarch (56 days) plague - 0.4.4.1-2.fc4.noarch (56 days) giallu AT gmail.com sysprof - 1.0.5-1.fc6.i386 (7 days) sysprof - 1.0.5-1.fc6.x86_64 (7 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (32 days) linphone - 1.2.0-4.fc5.ppc (32 days) linphone - 1.2.0-4.fc5.x86_64 (32 days) kevin AT tummy.com twinkle - 0.8.1-2.fc5.i386 twinkle - 0.8.1-2.fc5.ppc twinkle - 0.8.1-2.fc5.x86_64 twinkle - 0.8.1-2.fc6.i386 twinkle - 0.8.1-2.fc6.i386 twinkle - 0.8.1-2.fc6.ppc twinkle - 0.8.1-2.fc6.ppc twinkle - 0.8.1-2.fc6.x86_64 twinkle - 0.8.1-2.fc6.x86_64 michel.salim AT gmail.com python-nltk - 1.4.4-3.1.fc3.noarch python-nltk - 1.4.4-3.1.fc3.noarch oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (22 days) syck-php - 0.55-9.fc5.ppc (22 days) syck-php - 0.55-9.fc5.x86_64 (22 days) petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 ghc-gtk2hs - 0.9.10-4.fc6.i386 ghc-gtk2hs - 0.9.10-4.fc6.ppc ghc-gtk2hs - 0.9.10-4.fc6.ppc ghc-gtk2hs - 0.9.10-4.fc6.x86_64 ghc-gtk2hs - 0.9.10-4.fc6.x86_64 ghc642-gtk2hs - 0.9.10-4.fc6.i386 (7 days) ghc642-gtk2hs - 0.9.10-4.fc6.ppc (7 days) ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 (7 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 (7 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc (7 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 (7 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (12 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 sylpheed-claws-plugins-etpan-privacy-2.5.2-5.fc7.ppc requires libetpan.so.8 twinkle-0.8.1-2.fc6.ppc requires libccgnu2-1.4.so.0 twinkle-0.8.1-2.fc6.ppc requires libccext2-1.4.so.0 twinkle-0.8.1-2.fc6.ppc requires libccrtp1-1.4.so.0 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 sylpheed-claws-plugins-etpan-privacy-2.5.2-5.fc7.x86_64 requires libetpan.so.8()(64bit) twinkle-0.8.1-2.fc6.x86_64 requires libccrtp1-1.4.so.0()(64bit) twinkle-0.8.1-2.fc6.x86_64 requires libccext2-1.4.so.0()(64bit) twinkle-0.8.1-2.fc6.x86_64 requires libccgnu2-1.4.so.0()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 sylpheed-claws-plugins-etpan-privacy-2.5.2-5.fc7.i386 requires libetpan.so.8 twinkle-0.8.1-2.fc6.i386 requires libccgnu2-1.4.so.0 twinkle-0.8.1-2.fc6.i386 requires libccext2-1.4.so.0 twinkle-0.8.1-2.fc6.i386 requires libccrtp1-1.4.so.0 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc6.ppc requires libetpan.so.8 twinkle-0.8.1-2.fc6.ppc requires libccgnu2-1.4.so.0 twinkle-0.8.1-2.fc6.ppc requires libccext2-1.4.so.0 twinkle-0.8.1-2.fc6.ppc requires libccrtp1-1.4.so.0 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc6.x86_64 requires libetpan.so.8()(64bit) sysprof-1.0.5-1.fc6.x86_64 requires kmod-sysprof >= 0:1.0.5 twinkle-0.8.1-2.fc6.x86_64 requires libccrtp1-1.4.so.0()(64bit) twinkle-0.8.1-2.fc6.x86_64 requires libccext2-1.4.so.0()(64bit) twinkle-0.8.1-2.fc6.x86_64 requires libccgnu2-1.4.so.0()(64bit) Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc6.i386 requires libetpan.so.8 sysprof-1.0.5-1.fc6.i386 requires kmod-sysprof >= 0:1.0.5 twinkle-0.8.1-2.fc6.i386 requires libccgnu2-1.4.so.0 twinkle-0.8.1-2.fc6.i386 requires libccext2-1.4.so.0 twinkle-0.8.1-2.fc6.i386 requires libccrtp1-1.4.so.0 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc5.ppc requires libetpan.so.8 twinkle-0.8.1-2.fc5.ppc requires libccrtp1-1.3.so.0 twinkle-0.8.1-2.fc5.ppc requires libccext2-1.3.so.1 twinkle-0.8.1-2.fc5.ppc requires libccgnu2-1.3.so.1 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc5.x86_64 requires libetpan.so.8()(64bit) twinkle-0.8.1-2.fc5.x86_64 requires libccgnu2-1.3.so.1()(64bit) twinkle-0.8.1-2.fc5.x86_64 requires libccrtp1-1.3.so.0()(64bit) twinkle-0.8.1-2.fc5.x86_64 requires libccext2-1.3.so.1()(64bit) Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc5.i386 requires libetpan.so.8 twinkle-0.8.1-2.fc5.i386 requires libccrtp1-1.3.so.0 twinkle-0.8.1-2.fc5.i386 requires libccext2-1.3.so.1 twinkle-0.8.1-2.fc5.i386 requires libccgnu2-1.3.so.1 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 python-nltk-1.4.4-3.1.fc3.noarch requires python-numarray Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 python-nltk-1.4.4-3.1.fc3.noarch requires python-numarray ====================================================================== New report for: kevin AT tummy.com package: twinkle - 0.8.1-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libccgnu2-1.4.so.0 libccext2-1.4.so.0 libccrtp1-1.4.so.0 package: twinkle - 0.8.1-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libccrtp1-1.4.so.0()(64bit) libccext2-1.4.so.0()(64bit) libccgnu2-1.4.so.0()(64bit) package: twinkle - 0.8.1-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libccgnu2-1.4.so.0 libccext2-1.4.so.0 libccrtp1-1.4.so.0 package: twinkle - 0.8.1-2.fc6.ppc from fedora-extras-6-ppc unresolved deps: libccgnu2-1.4.so.0 libccext2-1.4.so.0 libccrtp1-1.4.so.0 package: twinkle - 0.8.1-2.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: libccrtp1-1.4.so.0()(64bit) libccext2-1.4.so.0()(64bit) libccgnu2-1.4.so.0()(64bit) package: twinkle - 0.8.1-2.fc6.i386 from fedora-extras-6-i386 unresolved deps: libccgnu2-1.4.so.0 libccext2-1.4.so.0 libccrtp1-1.4.so.0 package: twinkle - 0.8.1-2.fc5.ppc from fedora-extras-5-ppc unresolved deps: libccrtp1-1.3.so.0 libccext2-1.3.so.1 libccgnu2-1.3.so.1 package: twinkle - 0.8.1-2.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libccgnu2-1.3.so.1()(64bit) libccrtp1-1.3.so.0()(64bit) libccext2-1.3.so.1()(64bit) package: twinkle - 0.8.1-2.fc5.i386 from fedora-extras-5-i386 unresolved deps: libccrtp1-1.3.so.0 libccext2-1.3.so.1 libccgnu2-1.3.so.1 From eamitdey at yahoo.com Fri Nov 10 14:13:20 2006 From: eamitdey at yahoo.com (Amit Dey) Date: Fri, 10 Nov 2006 06:13:20 -0800 (PST) Subject: Need some ideas for small project Message-ID: <20061110141320.53005.qmail@web36807.mail.mud.yahoo.com> Hello everyone. I am a newbie to Linux development and I am looking for a small project. I have a done a reasonable amount Windows development (Applications, Windows Services, Libraries, Games) using languages like C,C++,Java and more recently C#. But I would like to start developing in linux. I already have very basic knowledge of networking, databases(MySQL), threads, processes, gui designn ( GTK+, GLADE ) and some other stuff in linux ( Note that i am saying very basic ). Can you guys suggest me some good project to start with. I am willing to give 4-5 hours for about 2-3 weeks to the project. If required then I am willing to learn some other stuff for the project. I must tell you that this project is not for my college. I want do this just to gain some linux development experience. Although If possible then I would like to submit it to fedora extras. Thanks a lot. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcbw at redhat.com Fri Nov 10 14:35:23 2006 From: dcbw at redhat.com (Dan Williams) Date: Fri, 10 Nov 2006 09:35:23 -0500 Subject: Buildsys troubles In-Reply-To: <45545DFB.5010207@hhs.nl> References: <45545DFB.5010207@hhs.nl> Message-ID: <1163169323.2662.3.camel@localhost.localdomain> On Fri, 2006-11-10 at 12:09 +0100, Hans de Goede wrote: > Hi, > > I wanted to report this through the infrastructure bugtracker, but I couldn't find a link to it and don't know the URL, perhaps putting a link to this on > http://buildsys.fedoraproject.org/ is a good idea? > > Anyways, my builds are failing consistently with the following error: > > Waiting for repository to unlock before starting the build... > Job waited too long for repo to unlock. Killing it... > Killing build process... > Cleaning up the buildroot... > /usr/bin/setarch ppc32 /usr/bin/mock clean --uniqueext=243e07168c8d639c4b40180c4a4f0d89a5c7ae6f -r fedora-development-ppc-core > Killed. > Waiting for child process 17173 to exit. Server has been kicked and problem has been fixed in the buildsys code. Thanks! Dan > Regards, > > Hans > From esr at thyrsus.com Fri Nov 10 14:35:55 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 10 Nov 2006 09:35:55 -0500 Subject: Need some ideas for small project In-Reply-To: <20061110141320.53005.qmail@web36807.mail.mud.yahoo.com> References: <20061110141320.53005.qmail@web36807.mail.mud.yahoo.com> Message-ID: <20061110143555.GA31785@thyrsus.com> Amit Dey : > I am a newbie to Linux development and I am looking for a small project. I've got a possibility for you. I run a project called 'gpsd'. It's a daemon that monitors GPSes attached to your machine. It automatically recognizes and translates all the funky protocols they use and publishes location information in a simple format on port 2947. Project site at . The gpsd distribution includes test clients. One of our users suggested that the test clients should emit audio cues when the GPS acquires or loses lock. This is a nice idea for operation while driving. I have it marked on my TODO list as a good small project for a newbie. gpsd is not in Fedora Extras or any other well-known repo, AFAIK. It probably should be, as a number of well-known projects (pyGPS, Kismet, GPSdrive, gpeGPS, position and roadmap) use it. We have a specfile all debugged and tested. It's a fun project -- eight very capable core developers, a bright user community, and a moderately active mailing list. Because I'm running it and I'm kind of obsessive about such things, we have a well-developed set of tools and procedures for regression testing and code auditing -- good things for a newbie to learn. -- Eric S. Raymond From rdieter at math.unl.edu Fri Nov 10 14:34:20 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 10 Nov 2006 08:34:20 -0600 Subject: repoclosure, multilib, and gift pkg References: <20061110131029.17264.68967@extras64.linux.duke.edu> Message-ID: Fedora Extras repoclosure wrote: > rdieter AT math.unl.edu > gift - 0.11.8.1-6.fc7.i386 (12 days) ... > Broken packages in fedora-extras-development-x86_64: > ---------------------------------------------------------------------- > gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 This is multilib at work methinks. What to do about it? plan a: * split gift shlibs and giftd daemon (which links against libmagic) into separate pkgs. CON: gift-using apps no longer (automatically) pull-in giftd as a dependency. WORKAROUND: add Requires: gift-daemon (or whatever new pkg name is) to said apps. plan b: * hmm... can't think of a plan b. Suggestions? -- Rex From rdieter at math.unl.edu Fri Nov 10 15:03:38 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 10 Nov 2006 09:03:38 -0600 Subject: repoclosure, multilib, and gift pkg References: <20061110131029.17264.68967@extras64.linux.duke.edu> Message-ID: Rex Dieter wrote: > Fedora Extras repoclosure wrote: > >> rdieter AT math.unl.edu >> gift - 0.11.8.1-6.fc7.i386 (12 days) > ... >> Broken packages in fedora-extras-development-x86_64: >> ---------------------------------------------------------------------- >> gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 > > This is multilib at work methinks. What to do about it? > > plan a: > * split gift shlibs and giftd daemon (which links against libmagic) into > separate pkgs. > CON: gift-using apps no longer (automatically) pull-in giftd as a > dependency. WORKAROUND: add Requires: gift-daemon (or whatever new pkg > name is) to said apps. > > plan b: > * hmm... can't think of a plan b. Suggestions? Got it! plan b: the "file" pkg/rpm which provides libmagic doesn't have a -devel pkg for its header file(s) and libmagic.so. If it *did* then it would be pulled into the multilib mix too. bugzilla here I come! http://bugzilla.redhat.com/214992 -- Rex From jima at beer.tclug.org Fri Nov 10 16:20:18 2006 From: jima at beer.tclug.org (Jima) Date: Fri, 10 Nov 2006 10:20:18 -0600 (CST) Subject: Need some ideas for small project In-Reply-To: <20061110143555.GA31785@thyrsus.com> References: <20061110141320.53005.qmail@web36807.mail.mud.yahoo.com> <20061110143555.GA31785@thyrsus.com> Message-ID: On Fri, 10 Nov 2006, Eric S. Raymond wrote: > gpsd is not in Fedora Extras or any other well-known repo, AFAIK. It > probably should be, as a number of well-known projects (pyGPS, Kismet, > GPSdrive, gpeGPS, position and roadmap) use it. We have a specfile > all debugged and tested. As an on-again, off-again GPSdrive user, this sounds like it could be useful. Cool. Now if I only had more time (or, for that matter, programming skills)... Jima From kevin-fedora-extras at scrye.com Fri Nov 10 17:52:34 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Fri, 10 Nov 2006 10:52:34 -0700 (MST) Subject: Fedora Extras Package Build Report 2006-11-10 References: <20061110120340.9B6CE15212E@buildsys.fedoraproject.org> <20061110135745.3091fbe7.bugs.michael@gmx.net> Message-ID: <20061110.105234.123836151.kevin@scrye.com> >>>>> "Michael" == Michael Schwendt writes: Michael> On Fri, 10 Nov 2006 07:03:40 -0500 (EST), Michael> buildsys at fedoraproject.org wrote: >> Packages built and released for Fedora Extras 6: 23 >> >> Invalid rebuild: gperiodic-2.0.8-5.fc7 Michael> Caution! Something weird here again. .fc6 rebuilds with a Michael> .fc7 build job name: Michael> http://buildsys.fedoraproject.org/plague-results/fedora-6-extras/gperiodic/2.0.8-5.fc7/ Michael> And here FC-6 build with .fc7 src.rpm: Michael> http://buildsys.fedoraproject.org/logs/fedora-6-extras/21283-gperiodic-2.0.8-5.fc7/ Michael> No time to examine whether it's user mistake or buildsys Michael> confusion. I'm glad we block such builds from entering the Michael> repo. It looks to me like this push might not have pushed any of the devel packages. I can't see any of them on: http://download.fedora.redhat.com/pub/fedora/linux/extras/development/ The fc6 ones all appear ok. I noticed this as I was trying to build a new twinkle package, which requires the new ccrtp, and the build for devel is failing with: http://buildsys.fedoraproject.org/plague-results/fedora-development-extras/ccrtp/1.5.0-1.fc7/x86_64/ccrtp-1.5.0-1.fc7.x86_64.rpm: [Errno 12] Timeout: Trying other mirror. Error: failure: ccrtp/1.5.0-1.fc7/x86_64/ccrtp-1.5.0-1.fc7.x86_64.rpm from local: [Errno 256] No more mirrors to try. Cleaning up... Which seems like ccrtp is pushed, but not pushed, so it can't find it? Anyone have any ideas on how to fix this? kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From caillon at redhat.com Fri Nov 10 18:24:39 2006 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 10 Nov 2006 13:24:39 -0500 Subject: rpms/seamonkey/FC-5 dead.package, NONE, 1.1 Makefile, 1.1, NONE find-external-requires, 1.1, NONE firefox-0.7.3-default-plugin-less-annoying.patch, 1.1, NONE firefox-0.7.3-psfonts.patch, 1.1, NONE firefox-1.0-prdtoa.patch, 1.1, NONE firefox-1.1-nss-system-nspr.patch, 1.1, NONE firefox-1.1-uriloader.patch, 1.1, NONE firefox-1.1-visibility.patch, 1.1, NONE firefox-1.5-with-system-nss.patch, 1.1, NONE firefox-1.5.0.1-dumpstack.patch, 1.1, NONE mozilla-1.4.1-ppc64.patch, 1.1, NONE mozilla-1.7.3-gnome-vfs-default-app.patch, 1.1, NONE mozilla-1.7.5-g-application-name.patch, 1.1, NONE mozilla-nspr-packages.patch, 1.1, NONE mozilla-psm-exclude-list, 1.1, NONE mozilla-xpcom-exclude-list, 1.1, NONE pango-cairo.patch, 1.1, NONE seamonkey-1.0.1-dumpstack.patch, 1.1, NONE seamonkey-cairo-bug5136.patch, 1.1, NONE seamonkey-configure.patch, 1.4, NONE seamonkey-disable-visibility.patch, 1.1, NONE seamonkey-fedora-default-bookmarks.html, 1.1, NONE seamonkey-fedora-default-prefs.js, 1.2, NONE seamonkey-fedora-home-page.patch, 1.1, NONE seamonkey-icon.png, 1.1, NONE seamonkey-mail-icon.png, 1.1, NONE seamonkey-mail.desktop, 1.1, NONE seamonkey-make-package.pl, 1.1, NONE seamonkey-mozconfig, 1.1, NONE seamonkey.desktop, 1.1, NONE seamonkey.sh.in, 1.1, NONE seamonkey.spec, 1.7, NONE sources, 1.6, NONE thunderbird-0.7.3-gnome-uriloader.patch, 1.1, NONE thunderbird-1.5-bug304720.patch, 1.1, NONE In-Reply-To: <20061110011410.8c262d3f.bugs.michael@gmx.net> References: <200611091805.kA9I5Phg015046@cvs-int.fedora.redhat.com> <20061110011410.8c262d3f.bugs.michael@gmx.net> Message-ID: <4554C3E7.5030907@redhat.com> Michael Schwendt wrote: > On Thu, 9 Nov 2006 11:05:25 -0700, Kai Engert (kengert) wrote: > >> Author: kengert >> >> Update of /cvs/extras/rpms/seamonkey/FC-5 > >> Added Files: >> dead.package > >> Log Message: >> The SeaMonkey Fedora Extras package for FC5 >> will be moved to Fedora Core >> and it will made to obsolete the Mozilla package. > > Please clarify! This is moving to Core in FC5 to obsolete the Mozilla package. It is not intended to move to Core in later releases which do not have the Mozilla package. > > 1.) Package is still alive in Fedora Extras branches "FC-6" and "devel". Yup. > > 2.) If the package is moved to Core (= Rawhide = FC7 devel), you are > supposed to mark it dead in FE "devel", not in the FC-5 branch. It is not dead in devel or FC6. > > 3.) What happens to the FE5 and FE6 packages? Remember, FE5 and FE6 > are stable branches of Fedora Extras! FE5 gets removed, Core packages get added. FE6 stays the same. > This is a rather crude way of using Extras as a testbed, then moving a > package to Core and discontinueing it in Extras. If you don't like that, then think of RHEL as the testbed. We are porting the RHEL specs over to seamonkey into FC5. From caillon at redhat.com Fri Nov 10 18:34:42 2006 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 10 Nov 2006 13:34:42 -0500 Subject: rpms/seamonkey/FC-5 dead.package, NONE, 1.1 Makefile, 1.1, NONE find-external-requires, 1.1, NONE firefox-0.7.3-default-plugin-less-annoying.patch, 1.1, NONE firefox-0.7.3-psfonts.patch, 1.1, NONE firefox-1.0-prdtoa.patch, 1.1, NONE firefox-1.1-nss-system-nspr.patch, 1.1, NONE firefox-1.1-uriloader.patch, 1.1, NONE firefox-1.1-visibility.patch, 1.1, NONE firefox-1.5-with-system-nss.patch, 1.1, NONE firefox-1.5.0.1-dumpstack.patch, 1.1, NONE mozilla-1.4.1-ppc64.patch, 1.1, NONE mozilla-1.7.3-gnome-vfs-default-app.patch, 1.1, NONE mozilla-1.7.5-g-application-name.patch, 1.1, NONE mozilla-nspr-packages.patch, 1.1, NONE mozilla-psm-exclude-list, 1.1, NONE mozilla-xpcom-exclude-list, 1.1, NONE pango-cairo.patch, 1.1, NONE seamonkey-1.0.1-dumpstack.patch, 1.1, NONE seamonkey-cairo-bug5136.patch, 1.1, NONE seamonkey-configure.patch, 1.4, NONE seamonkey-disable-visibility.patch, 1.1, NONE seamonkey-fedora-default-bookmarks.html, 1.1, NONE seamonkey-fedora-default-prefs.js, 1.2, NONE seamonkey-fedora-home-page.patch, 1.1, NONE seamonkey-icon.png, 1.1, NONE seamonkey-mail-icon.png, 1.1, NONE seamonkey-mail.desktop, 1.1, NONE seamonkey-make-package.pl, 1.1, NONE seamonkey-mozconfig, 1.1, NONE seamonkey.desktop, 1.1, NONE seamonkey.sh.in, 1.1, NONE seamonkey.spec, 1.7, NONE sources, 1.6, NONE thunderbird-0.7.3-gnome-uriloader.patch, 1.1, NONE thunderbird-1.5-bug304720.patch, 1.1, NONE In-Reply-To: <4554C3E7.5030907@redhat.com> References: <200611091805.kA9I5Phg015046@cvs-int.fedora.redhat.com> <20061110011410.8c262d3f.bugs.michael@gmx.net> <4554C3E7.5030907@redhat.com> Message-ID: <4554C642.7060703@redhat.com> Christopher Aillon wrote: > If you don't like that, then think of RHEL as the testbed. We are > porting the RHEL specs over to seamonkey into FC5. And after I sent this, I realized this had some connotations I didn't mean to use. RHEL seamonkey packages were tested heavily by many many people before releasing this to customers. On top of that, it's been in RHEL for a few months now and has worked great. From eamitdey at yahoo.com Fri Nov 10 18:52:02 2006 From: eamitdey at yahoo.com (Amit Dey) Date: Fri, 10 Nov 2006 10:52:02 -0800 (PST) Subject: About GPSdrive Message-ID: <20061110185202.91677.qmail@web36806.mail.mud.yahoo.com> I appreciate your giving me the idea of GPSdrive. I actually didn't know what it was ? So i searched and discovered that it has got something to do with GPS and wire-less networks. But I frankly don't have access to any GPS device or wireless network. But I have connection to a wired LAN. So can u suggest something else maybe something for my LAN. Thanks. --------------------------------- Everyone is raving about the all-new Yahoo! Mail beta. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugs.michael at gmx.net Fri Nov 10 19:25:56 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 10 Nov 2006 20:25:56 +0100 Subject: rpms/seamonkey/FC-5 dead.package, NONE, 1.1 Makefile, 1.1, NONE find-external-requires, 1.1, NONE firefox-0.7.3-default-plugin-less-annoying.patch, 1.1, NONE firefox-0.7.3-psfonts.patch, 1.1, NONE firefox-1.0-prdtoa.patch, 1.1, NONE firefox-1.1-nss-system-nspr.patch, 1.1, NONE firefox-1.1-uriloader.patch, 1.1, NONE firefox-1.1-visibility.patch, 1.1, NONE firefox-1.5-with-system-nss.patch, 1.1, NONE firefox-1.5.0.1-dumpstack.patch, 1.1, NONE mozilla-1.4.1-ppc64.patch, 1.1, NONE mozilla-1.7.3-gnome-vfs-default-app.patch, 1.1, NONE mozilla-1.7.5-g-application-name.patch, 1.1, NONE mozilla-nspr-packages.patch, 1.1, NONE mozilla-psm-exclude-list, 1.1, NONE mozilla-xpcom-exclude-list, 1.1, NONE pango-cairo.patch, 1.1, NONE seamonkey-1.0.1-dumpstack.patch, 1.1, NONE seamonkey-cairo-bug5136.patch, 1.1, NONE seamonkey-configure.patch, 1.4, NONE seamonkey-disable-visibility.patch, 1.1, NONE seamonkey-fedora-default-bookmarks.html, 1.1, NONE seamonkey-fedora-default-prefs.js, 1.2, NONE seamonkey-fedora-home-page.patch, 1.1, NONE seamonkey-icon.png, 1.1, NONE seamonkey-mail-icon.png, 1.1, NONE seamonkey-mail.desktop, 1.1, NONE seamonkey-make-package.pl, 1.1, NONE seamonkey-mozconfig, 1.1, NONE seamonkey.desktop, 1.1, NONE seamonkey.sh.in, 1.1, NONE seamonkey.spec, 1.7, NONE sources, 1.6, NONE thunderbird-0.7.3-gnome-uriloader.patch, 1.1, NONE thunderbird-1.5-bug304720.patch, 1.1, NONE In-Reply-To: <4554C3E7.5030907@redhat.com> References: <200611091805.kA9I5Phg015046@cvs-int.fedora.redhat.com> <20061110011410.8c262d3f.bugs.michael@gmx.net> <4554C3E7.5030907@redhat.com> Message-ID: <20061110202556.90ad9ee6.bugs.michael@gmx.net> On Fri, 10 Nov 2006 13:24:39 -0500, Christopher Aillon wrote: > > 3.) What happens to the FE5 and FE6 packages? Remember, FE5 and FE6 > > are stable branches of Fedora Extras! > > FE5 gets removed, Core packages get added. FE6 stays the same. > > > > This is a rather crude way of using Extras as a testbed, then moving a > > package to Core and discontinueing it in Extras. > > > If you don't like that, then think of RHEL as the testbed. We are > porting the RHEL specs over to seamonkey into FC5. https://www.redhat.com/archives/fedora-extras-list/2006-November/msg00192.html From bugs.michael at gmx.net Fri Nov 10 19:36:41 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 10 Nov 2006 20:36:41 +0100 Subject: Fedora Extras Package Build Report 2006-11-10 In-Reply-To: <20061110.105234.123836151.kevin@scrye.com> References: <20061110120340.9B6CE15212E@buildsys.fedoraproject.org> <20061110135745.3091fbe7.bugs.michael@gmx.net> <20061110.105234.123836151.kevin@scrye.com> Message-ID: <20061110203641.853828aa.bugs.michael@gmx.net> On Fri, 10 Nov 2006 10:52:34 -0700 (MST), Kevin Fenzi wrote: > It looks to me like this push might not have pushed any of the devel > packages. I can't see any of them on: > > http://download.fedora.redhat.com/pub/fedora/linux/extras/development/ You can see them on http://fedoraproject.org/extras/ where they have been pushed. From there they are mirrored automatically, which may take some time. When you see a build report, packages are available at the fp.org repo immediately. > I noticed this as I was trying to build a new twinkle package, which > requires the new ccrtp, and the build for devel is failing with: > > http://buildsys.fedoraproject.org/plague-results/fedora-development-extras/ccrtp/1.5.0-1.fc7/x86_64/ccrtp-1.5.0-1.fc7.x86_64.rpm: [Errno 12] Timeout: > Trying other mirror. > Error: failure: ccrtp/1.5.0-1.fc7/x86_64/ccrtp-1.5.0-1.fc7.x86_64.rpm from local: [Errno 256] No more mirrors to try. > Cleaning up... > > Which seems like ccrtp is pushed, but not pushed, so it can't find it? > > Anyone have any ideas on how to fix this? The time-out is weird, it is during access to the needsign repository where the packages are kept for two days after a push. This is the window during which they should be available at fedora.redhat.com, too. From kevin-fedora-extras at scrye.com Fri Nov 10 19:49:47 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Fri, 10 Nov 2006 12:49:47 -0700 (MST) Subject: Fedora Extras Package Build Report 2006-11-10 References: <20061110120340.9B6CE15212E@buildsys.fedoraproject.org> <20061110135745.3091fbe7.bugs.michael@gmx.net> <20061110.105234.123836151.kevin@scrye.com> <20061110203641.853828aa.bugs.michael@gmx.net> Message-ID: <20061110.124947.115358005.kevin@scrye.com> >>>>> "Michael" == Michael Schwendt writes: Michael> On Fri, 10 Nov 2006 10:52:34 -0700 (MST), Kevin Fenzi wrote: >> It looks to me like this push might not have pushed any of the >> devel packages. I can't see any of them on: >> >> http://download.fedora.redhat.com/pub/fedora/linux/extras/development/ Michael> You can see them on http://fedoraproject.org/extras/ Michael> where they have been pushed. From there they are mirrored Michael> automatically, which may take some time. Ok. Would there be any reason that the devel packages were not mirrored while the fc6/fc5 ones at least were? Michael> When you see a build report, packages are available at the Michael> fp.org repo immediately. Right. >> I noticed this as I was trying to build a new twinkle package, >> which requires the new ccrtp, and the build for devel is failing >> with: >> >> http://buildsys.fedoraproject.org/plague-results/fedora-development-extras/ccrtp/1.5.0-1.fc7/x86_64/ccrtp-1.5.0-1.fc7.x86_64.rpm: >> [Errno 12] Timeout: Trying other mirror. >> Error: failure: >> ccrtp/1.5.0-1.fc7/x86_64/ccrtp-1.5.0-1.fc7.x86_64.rpm from local: >> [Errno 256] No more mirrors to try. Cleaning up... >> >> Which seems like ccrtp is pushed, but not pushed, so it can't find >> it? >> >> Anyone have any ideas on how to fix this? Michael> The time-out is weird, it is during access to the needsign Michael> repository where the packages are kept for two days after a Michael> push. This is the window during which they should be Michael> available at fedora.redhat.com, too. Yeah. I was thinking since they had been pushed that it would pull them from the regular download repo, but it wasn't. A subsequent build worked with the local plague-results repo on the builders. No idea why it failed with the timeout before. ;( kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Fri Nov 10 20:51:24 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 10 Nov 2006 22:51:24 +0200 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <200611091215.kA9CFH4Y003978@devserv.devel.redhat.com> References: <45530A78.7040908@hhs.nl> <4553122D.7020604@leemhuis.info> <200611091215.kA9CFH4Y003978@devserv.devel.redhat.com> Message-ID: <1163191884.3072.64.camel@viper.local> On Thu, 2006-11-09 at 07:15 -0500, Josh Bressers wrote: > This is currently a non trivial problem to solve. We lack the man power to > modify the various problem packages ourselves, so the obvious solution is > to let the owner do the work and the security team would only have to step > in when the owner is MIA. I can't help noting that the lack *and inactivity* of manpower who takes care or even tracks FE issues in the security response team or elsewhere worries me much more than the lack of announcements. Of course that doesn't mean that the announcement part shouldn't be fixed too. From michel.salim at gmail.com Fri Nov 10 21:34:59 2006 From: michel.salim at gmail.com (Michel Salim) Date: Fri, 10 Nov 2006 16:34:59 -0500 Subject: Quick review needed Message-ID: <883cfe6d0611101334n64438128yaa72d3b4b08bd4fc@mail.gmail.com> One of the package, python-nltk I maintain has become discontinued upstream, replaced by another package, python-nltk_lite, that is currently awaiting review. I plan to request the removal of the original python-nltk for the "current" versions (FE-5 and FE-6) soon after python-nltk_lite lands, so hopefully that won't be too long in the future. The changes in packaging are very minor (the obvious name change, and the names of the Python modules). So if you've been meaning to review but not been able to find the time, please take a look if you can. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213192 Many thanks, -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From jamatos at fc.up.pt Fri Nov 10 21:46:41 2006 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Fri, 10 Nov 2006 21:46:41 +0000 Subject: Quick review needed In-Reply-To: <883cfe6d0611101334n64438128yaa72d3b4b08bd4fc@mail.gmail.com> References: <883cfe6d0611101334n64438128yaa72d3b4b08bd4fc@mail.gmail.com> Message-ID: <200611102146.41647.jamatos@fc.up.pt> On Friday 10 November 2006 9:34 pm, Michel Salim wrote: > The changes in packaging are very minor (the obvious name change, and > the names of the Python modules). So if you've been meaning to review > but not been able to find the time, please take a look if you can. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213192 > > Many thanks, I will have a look into it. > -- > Michel Salim > > Don't worry about avoiding temptation -- as you grow older, it starts > avoiding you. > -- The Old Farmer's Almanac -- Jos? Ab?lio From j.w.r.degoede at hhs.nl Fri Nov 10 23:08:34 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 11 Nov 2006 00:08:34 +0100 Subject: gnome application menu troubles Message-ID: <45550672.9030109@hhs.nl> Hi, I just received a bug report titled: "ScummVM is in the Other menu instead of the Games menu", see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215097 Which reminds me that I wanted to bring up some issues with the gnome applications menu: 1) Applications which have a Catagories=Emulators; show up on the other menu while Emulators is a valid freedesktop Catagory, dribble fixes this with a special dribble-menus package which adds an Emulator submenu to the applications menu. Would it be ok to move this package to FE and require it from packages like scummvm and hatari, or should this be posted as a patch against the core gnome package? See: dribble.org.uk 2) The games menu doesn't have submenu's like the kde one has, which makes it harder to use then necessary when you've got lots of games installed. Questions: 2a) Is it possible to create submenu's under the Games menu using the similar techniques as used in the dribble-menus package 2b) Would it be ok to use this to create a seperate gnome-games-sub-menus package, as I don't think we want this to be the default in the core gnome menus package. 2c) Or can this be done in such a way that the submenus only get enabled if the number of games exceed a treshold? Regards, Hans From giallu at gmail.com Sat Nov 11 09:06:28 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sat, 11 Nov 2006 10:06:28 +0100 Subject: Democracy player anyone? In-Reply-To: References: <883cfe6d0611070647l665292cfq428bc93a8e17a1a7@mail.gmail.com> Message-ID: On 11/7/06, Neal Becker wrote: > Michel Salim wrote: > > > On 11/7/06, Neal Becker > > wrote: > >> Gianluca Sforna wrote: > >> > >> > Hi, > >> > I saw the democracy player [1] was submitted for review on livna[2], > >> > but now that xine-lib landed in Extras, we could include it directly > >> > here. > >> > > >> > Is there anyone already working on this? > >> > If not, I have an older spec file I could bash in shape for review. > >> > > >> > cheers > >> > Gianluca > >> > > >> > [1] http://www.getdemocracy.org > >> > [2] http://bugzilla.livna.org/show_bug.cgi?id=911 > >> > > >> > >> Current release crashes on start on x86_64. Wait for next. > >> > > How about starting with the previous release, if that works > > cross-platform? > > > > > > Previous was OK > > On mail list, someone said they had a patch, so I figured I'd wait. > > -- In the meanwhile, I tried older releases (all of them crash in my FC6) and finally decided to package the svn HEAD. FC6 build seems functional; have a look if you want: http://giallu.homelinux.org/fedora/democracy.spec http://giallu.homelinux.org/fedora/democracy-0.9.1-0.1.20061111svn3684.src.rpm From bugs.michael at gmx.net Sat Nov 11 10:42:50 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 11 Nov 2006 11:42:50 +0100 Subject: Packagers, use: plague-client requeue ... Message-ID: <20061111114250.0a6eb334.bugs.michael@gmx.net> There are still commit messages where a packager increases "Release" in the spec file just to rebuild the package after it had failed due to temporary buildsys problems. In the spec %changelog there is a comment that the buildsys failed. Sometimes this is done for multiple branches to keep EVR of all releases in sync. This is unnecessary. Run: plague-client requeue instead of doing the "bump, commit, make tag, make build" dance. You can requeue failed/killed build jobs until they succeed. And so far, the buildsys would not even care if you simply asked it to build the same tag once more. From jonathan.underwood at gmail.com Sat Nov 11 11:55:13 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 11 Nov 2006 11:55:13 +0000 Subject: Packagers, use: plague-client requeue ... In-Reply-To: <20061111114250.0a6eb334.bugs.michael@gmx.net> References: <20061111114250.0a6eb334.bugs.michael@gmx.net> Message-ID: <645d17210611110355y5b42fccdya6e48e3079dd4075@mail.gmail.com> On 11/11/06, Michael Schwendt wrote: > There are still commit messages where a packager increases "Release" in > the spec file just to rebuild the package after it had failed due to > temporary buildsys problems. In the spec %changelog there is a comment > that the buildsys failed. Sometimes this is done for multiple branches to > keep EVR of all releases in sync. > > This is unnecessary. Run: > > plague-client requeue > > instead of doing the "bump, commit, make tag, make build" dance. You can > requeue failed/killed build jobs until they succeed. > > And so far, the buildsys would not even care if you simply asked it > to build the same tag once more. Useful information. I wonder if we should have a wiki page about plague-client useage? From joost.soeterbroek at gmail.com Sat Nov 11 12:18:41 2006 From: joost.soeterbroek at gmail.com (Joost Soeterbroek) Date: Sat, 11 Nov 2006 13:18:41 +0100 Subject: Change of e-mail address, not able to submit plague build jobs Message-ID: Hi, I have recently lost the e-mail address I used for all fedora extras related activities. I have changed to my new e-mail address in owners.list, fedora account system, bugzilla, and ~/.plague-client.cfg file. I have also generated/downloaded new certs. My CVS account is still working, but when submitting plague build job I got an error: "Insufficient privileges". Can anyone help me to remedy this? Regards, Joost From fedora at leemhuis.info Sat Nov 11 12:33:37 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 11 Nov 2006 13:33:37 +0100 Subject: Packagers, use: plague-client requeue ... In-Reply-To: <645d17210611110355y5b42fccdya6e48e3079dd4075@mail.gmail.com> References: <20061111114250.0a6eb334.bugs.michael@gmx.net> <645d17210611110355y5b42fccdya6e48e3079dd4075@mail.gmail.com> Message-ID: <4555C321.8010909@leemhuis.info> (side note: all this cross posting sucks) Jonathan Underwood schrieb: > On 11/11/06, Michael Schwendt wrote: >> This is unnecessary. Run: >> plague-client requeue >> instead of doing the "bump, commit, make tag, make build" dance. You can >> requeue failed/killed build jobs until they succeed. >> And so far, the buildsys would not even care if you simply asked it >> to build the same tag once more. > Useful information. I wonder if we should have a wiki page about > plague-client useage? Agreed, this is one of the many thing that's documented lousily in the wiki. Someone needs to just do it. Probably a new page similar to http://www.fedoraproject.org/wiki/Extras/UsingCvsFaq or add a note on http://www.fedoraproject.org/wiki/Extras/BuildSystemClientSetup could help. CU thl From dan at danny.cz Sat Nov 11 13:48:32 2006 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Sat, 11 Nov 2006 14:48:32 +0100 Subject: package for tailor - a VCS repository conversion tool Message-ID: <1163252912.3513.14.camel@eagle.danny.cz> Hello, I have packaged the current version of tailor (VCS repository conversion tool). If enough interest or even a co-maintainer would be found, I will submit it for Extras. SRPM URL: http://fedora.danny.cz/tailor-0.9.26-1.src.rpm spec URL: http://fedora.danny.cz/tailor.spec The package is based on the ATrpms one. Dan From buildsys at fedoraproject.org Sat Nov 11 14:06:41 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 11 Nov 2006 09:06:41 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-11 Message-ID: <20061111140641.D412F15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 45 Terminal-0.2.5.8-0.1.rc2.fc7 Thunar-0.5.0-0.1.rc2.fc7 beneath-a-steel-sky-cd-0.0372-1 bogl-0.1.18-13 ccache-2.4-7.fc7 cfengine-2.1.21-3.fc7 codeblocks-1.0-0.13.20061110svn3202.fc7 exo-0.3.1.12-0.1.rc2.fc7 flight-of-the-amazon-queen-1.0-1 fuse-2.6.0-1.fc7 grhino-0.15.2-4.1.fc7 gtk-xfce-engine-2.3.99.2-1.fc7 gwget-0.98.2-1.fc7 kcometen3-1.1-4.fc7 libxfce4mcs-4.3.99.2-1.fc7 libxfce4util-4.3.99.2-1.fc7 libxfcegui4-4.3.99.2-1.fc7 mousepad-0.2.10-1.fc7 orage-4.3.99.2-1.fc7 p0f-2.0.8-1.fc7 pachi-1.0-1.fc7 php-pear-XML-RSS-0.9.10-2.fc7 phpMyAdmin-2.9.1-1alpha poedit-1.3.6-1.1.fc7 python-nltk_lite-0.6.6-1.fc7 qgit-1.5.3-1.fc7 scribus-1.3.3.5-1.fc7 seamonkey-1.0.6-2.fc7 synce-0.9.1-9.fc7 theora-exp-0.0.1-0.1.svn12061.fc7 tracker-0.5.1-1.fc7 twinkle-0.9-2.fc7 vdradmin-am-3.5.0-1.fc7 xfce-mcs-manager-4.3.99.2-1.fc7 xfce-mcs-plugins-4.3.99.2-1.fc7 xfce-utils-4.3.99.2-1.fc7 xfce4-appfinder-4.3.99.2-1.fc7 xfce4-icon-theme-4.3.99.2-1.fc7 xfce4-mixer-4.3.99.2-1.fc7 xfce4-panel-4.3.99.2-1.fc7 xfce4-session-4.3.99.2-1.fc7 xfdesktop-4.3.99.2-1.fc7 xfprint-4.3.99.2-1.fc7 xfwm4-4.3.99.2-1.fc7 xfwm4-themes-4.3.99.2-1.fc7 Packages built and released for Fedora Extras 6: 14 ccache-2.4-7.fc6 codeblocks-1.0-0.13.20061110svn3202.fc6 em8300-kmod-0.16.0-0.3.rc2.2.6.18_1.2798.fc6 gperiodic-2.0.8-6.fc6 grhino-0.15.2-4.1.fc6 kcometen3-1.1-4.fc6 p0f-2.0.8-1.fc6 qgit-1.5.3-1.fc6 scribus-1.3.3.5-1.fc6 seamonkey-1.0.6-0.6.2.fc6 sylpheed-claws-plugins-2.6.0-1.fc6 synce-0.9.1-9.fc6 theora-exp-0.0.1-0.1.svn12061.fc6 twinkle-0.9-2.fc6 Packages built and released for Fedora Extras 5: 8 codeblocks-1.0-0.13.20061110svn3202.fc5 em8300-kmod-0.16.0-0.0.rc2.2.6.18_1.2239.fc5 grhino-0.15.2-4.1.fc5 kcometen3-1.1-4.fc5 p0f-2.0.8-1.fc5 qgit-1.5.3-1.fc5 theora-exp-0.0.1-0.1.svn12061.fc5 twinkle-0.9-2.fc5 Packages built and released for Fedora Extras 4: 2 grhino-0.15.2-4.1.fc4 qgit-1.5.3-1.fc4 Packages built and released for Fedora Extras 3: 1 grhino-0.15.2-4.1.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat Nov 11 15:18:02 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 11 Nov 2006 15:18:02 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-11 Message-ID: <20061111151802.23600.29955@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 (11 days) centericq - 4.21.0-8.fc6.ppc (11 days) centericq - 4.21.0-8.fc6.x86_64 (11 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (14 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (14 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (14 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (14 days) orange - 0.3-3.cvs20051118.fc6.i386 (18 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (42 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (42 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (42 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc5.i386 (3 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc5.ppc (3 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc5.x86_64 (3 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-5.fc7.i386 (3 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-5.fc7.ppc (3 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-5.fc7.x86_64 (3 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (57 days) plague - 0.4.4.1-2.fc3.noarch (57 days) plague - 0.4.4.1-2.fc4.noarch (57 days) plague - 0.4.4.1-2.fc4.noarch (57 days) plague - 0.4.4.1-2.fc4.noarch (57 days) giallu AT gmail.com sysprof - 1.0.5-1.fc6.i386 (8 days) sysprof - 1.0.5-1.fc6.x86_64 (8 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (33 days) linphone - 1.2.0-4.fc5.ppc (33 days) linphone - 1.2.0-4.fc5.x86_64 (33 days) oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (23 days) syck-php - 0.55-9.fc5.ppc (23 days) syck-php - 0.55-9.fc5.x86_64 (23 days) petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 (2 days) ghc-gtk2hs - 0.9.10-4.fc6.i386 (2 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (2 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (2 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (2 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (2 days) ghc642-gtk2hs - 0.9.10-4.fc6.i386 (8 days) ghc642-gtk2hs - 0.9.10-4.fc6.ppc (8 days) ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 (8 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 (8 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc (8 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 (8 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (13 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 sylpheed-claws-plugins-etpan-privacy-2.5.2-5.fc7.ppc requires libetpan.so.8 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 sylpheed-claws-plugins-etpan-privacy-2.5.2-5.fc7.x86_64 requires libetpan.so.8()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 sylpheed-claws-plugins-etpan-privacy-2.5.2-5.fc7.i386 requires libetpan.so.8 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 sysprof-1.0.5-1.fc6.x86_64 requires kmod-sysprof >= 0:1.0.5 Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 sysprof-1.0.5-1.fc6.i386 requires kmod-sysprof >= 0:1.0.5 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc5.ppc requires libetpan.so.8 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc5.x86_64 requires libetpan.so.8()(64bit) Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc5.i386 requires libetpan.so.8 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: dcbw AT redhat.com package: plague - 0.4.4.1-2.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-2.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-2.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-2.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-2.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: libopensync-plugin-evolution2 - 0.19-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libedataserver-1.2.so.7 package: libopensync-plugin-evolution2 - 0.19-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libedataserver-1.2.so.7 package: libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libedataserver-1.2.so.7()(64bit) package: libopensync-plugin-evolution2 - 0.19-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libedataserver-1.2.so.7 package: sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: libetpan.so.6 package: sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libetpan.so.6()(64bit) package: sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: libetpan.so.6 From ndbecker2 at gmail.com Sat Nov 11 19:50:06 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 11 Nov 2006 14:50:06 -0500 Subject: Democracy player anyone? References: <883cfe6d0611070647l665292cfq428bc93a8e17a1a7@mail.gmail.com> Message-ID: Gianluca Sforna wrote: > On 11/7/06, Neal Becker > wrote: >> Michel Salim wrote: >> >> > On 11/7/06, Neal Becker >> > wrote: >> >> Gianluca Sforna wrote: >> >> >> >> > Hi, >> >> > I saw the democracy player [1] was submitted for review on livna[2], >> >> > but now that xine-lib landed in Extras, we could include it directly >> >> > here. >> >> > >> >> > Is there anyone already working on this? >> >> > If not, I have an older spec file I could bash in shape for review. >> >> > >> >> > cheers >> >> > Gianluca >> >> > >> >> > [1] http://www.getdemocracy.org >> >> > [2] http://bugzilla.livna.org/show_bug.cgi?id=911 >> >> > >> >> >> >> Current release crashes on start on x86_64. Wait for next. >> >> >> > How about starting with the previous release, if that works >> > cross-platform? >> > >> > >> >> Previous was OK >> >> On mail list, someone said they had a patch, so I figured I'd wait. >> >> -- > > In the meanwhile, I tried older releases (all of them crash in my FC6) > and finally decided to package the svn HEAD. > FC6 build seems functional; have a look if you want: > > http://giallu.homelinux.org/fedora/democracy.spec > http://giallu.homelinux.org/fedora/democracy-0.9.1-0.1.20061111svn3684.src.rpm > Thanks. I tried building this on FC6 x86_64. Good news is, it does build, and it does start. But, that's the end of the good news. Almost anything I do with it causes it to freeze. I tried rm -rf ~/.democrary. I don't think this one is usable on x86_64 at all. From michel.salim at gmail.com Sun Nov 12 07:16:01 2006 From: michel.salim at gmail.com (Michel Salim) Date: Sun, 12 Nov 2006 02:16:01 -0500 Subject: Democracy player anyone? In-Reply-To: References: <883cfe6d0611070647l665292cfq428bc93a8e17a1a7@mail.gmail.com> Message-ID: <883cfe6d0611112316y2ffd9bedrf8879f59e5c81335@mail.gmail.com> On 11/11/06, Gianluca Sforna wrote: > On 11/7/06, Neal Becker wrote: > > Michel Salim wrote: > > > > > On 11/7/06, Neal Becker > > > wrote: > > >> Gianluca Sforna wrote: > > >> > > >> > Hi, > > >> > I saw the democracy player [1] was submitted for review on livna[2], > > >> > but now that xine-lib landed in Extras, we could include it directly > > >> > here. > > >> > > > >> > Is there anyone already working on this? > > >> > If not, I have an older spec file I could bash in shape for review. > > >> > > > >> > cheers > > >> > Gianluca > > >> > > > >> > [1] http://www.getdemocracy.org > > >> > [2] http://bugzilla.livna.org/show_bug.cgi?id=911 > > >> > > > >> > > >> Current release crashes on start on x86_64. Wait for next. > > >> > > > How about starting with the previous release, if that works > > > cross-platform? > > > > > > > > > > Previous was OK > > > > On mail list, someone said they had a patch, so I figured I'd wait. > > > > -- > > In the meanwhile, I tried older releases (all of them crash in my FC6) > and finally decided to package the svn HEAD. > FC6 build seems functional; have a look if you want: > > http://giallu.homelinux.org/fedora/democracy.spec > http://giallu.homelinux.org/fedora/democracy-0.9.1-0.1.20061111svn3684.src.rpm > I tried using %find_lang, but it's bizarre how it could not pick up the localization files. Not sure what to do with the dependency on libfame, which 1) is not kosher 2) is a hardcoded dependency, so rpmlint is unhappy I did some cleanup (permission errors and the CREDITS file being Windows-formatted), feel free to incorporate the changes. Regards, -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac -------------- next part -------------- A non-text attachment was scrubbed... Name: Democracy.spec Type: application/octet-stream Size: 3332 bytes Desc: not available URL: From dtimms at iinet.net.au Sun Nov 12 09:19:48 2006 From: dtimms at iinet.net.au (David Timms) Date: Sun, 12 Nov 2006 20:19:48 +1100 Subject: Estimate the size of extras ? In-Reply-To: <1162993533.3317.12.camel@lt21223.campus.dmacc.edu> References: <4551CE14.1050809@iinet.net.au> <1162993533.3317.12.camel@lt21223.campus.dmacc.edu> Message-ID: <4556E734.5090606@iinet.net.au> Jeffrey C. Ollie wrote: > On Wed, 2006-11-08 at 23:31 +1100, David Timms wrote: >> I have been talking about getting extras mirrored with some local mirror >> admins and was asked what space would be required for an extras mirror. >> >> Would someone know a more realistic answer, or could run du -sh extras/* >> on their mirror and post back ? > > # du -sh extras/*/* > 6.9G extras/4/i386 > 6.8G extras/4/x86_64 > 9.7G extras/5/i386 > 9.5G extras/5/x86_64 > 6.9G extras/6/i386 > 6.8G extras/6/x86_64 > 6.4G extras/development/i386 > 8.1G extras/development/x86_64 > > That includes the debuginfo packages but not SRPMS. Thanks Adrian, Jon and Jeff for your efforts. I was severely underestimating the size, oops; now to convince my local mirror admin that it's a good value repository to mirror! DaveT. From bugs.michael at gmx.net Sun Nov 12 10:29:16 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 12 Nov 2006 11:29:16 +0100 Subject: Democracy player anyone? In-Reply-To: <883cfe6d0611112316y2ffd9bedrf8879f59e5c81335@mail.gmail.com> References: <883cfe6d0611070647l665292cfq428bc93a8e17a1a7@mail.gmail.com> <883cfe6d0611112316y2ffd9bedrf8879f59e5c81335@mail.gmail.com> Message-ID: <20061112112916.bf528d24.bugs.michael@gmx.net> On Sun, 12 Nov 2006 02:16:01 -0500, Michel Salim wrote: > I tried using %find_lang, but it's bizarre how it could not pick up > the localization files. The first parameter of %find_lang serves two purposes: 1) it's a file name prefix, which will be prepended to ".lang", resulting in the file which contains a generated fragment for the %files section 2) it's a regular expression, used when searching for message object files So, when the package is called "Democracy" and the .mo files are called "democracyplayer.mo", the regexp pattern fails, since you cannot simply use "%find_lang %name" anymore. You would need "%find_lang democracyplayer" or a hack-ish regexp pattern, which also gives a working filename. From j.w.r.degoede at hhs.nl Sun Nov 12 11:27:20 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 12 Nov 2006 12:27:20 +0100 Subject: Reviewer wanted for freetype1 Message-ID: <45570518.6050404@hhs.nl> Hi all, With FC-6 freetype1 compatibility has been dropped from FC, I've gotten involved in the freetype1 review request and I am now going to be the maintainer. But currently this review isn't going anywhere as there is no reviewer :( I would like to see this reviewed soon as this is currently blocking me from unorphaning MagicPoint and thus from closing a slew of Magicpoint bugs. So can anyone review freetype1 for me, or maybe we can swap reviews? : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198836 Thanks and Regards, Hans From buildsys at fedoraproject.org Sun Nov 12 12:07:57 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 12 Nov 2006 07:07:57 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-12 Message-ID: <20061112120757.45DAE15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 34 audacity-1.2.5-3.fc7 deskbar-applet-2.17.2-1.fc7 eiciel-0.9.2-8.fc7 gaim-gaym-0.96-3.5.291svn.fc7 gdesklets-0.35.4-3.fc7 glitz-0.5.6-5.fc7 gperiodic-2.0.8-7.fc7 granule-1.2.3-4.fc7 gtkdatabox-0.7.0.0-4.fc7 libatomic_ops-1.2-1.fc7 monotone-0.31-1.fc7 ochusha-0.5.99.63.3-0.2.cvs061112.fc7 openct-0.6.10-1.fc7 pan-0.119-1.fc7 panelfm-1.1-2.fc7 perl-Alien-wxWidgets-0.25-1.fc7 perl-Cairo-1.021-1.fc7 perl-Email-Address-1.880-1.fc7 perl-Module-ScanDeps-0.69-1.fc7 perl-Perl-Critic-0.21-1.fc7 perl-Set-Scalar-1.20-1.fc7 perl-Sub-Uplevel-0.14-1.fc7 perl-Test-Perl-Critic-0.08-1.fc7 perl-Wx-0.60-1.fc7 php-pear-Cache-1.5.5-0.1.RC4.fc7 php-pear-Net-DIME-0.3-1.fc7 trac-0.10.1-1.fc7 vdr-osdteletext-0.5.1-26.fc7 vdr-subtitles-0.4.0-6.fc7 xfce4-battery-plugin-0.4.90.3-1.fc7 xfce4-dev-tools-4.3.99.2-1.fc7 xfce4-eyes-plugin-4.3.99.1-2.fc7 xfce4-genmon-plugin-3.0-2.fc7 zeroinstall-injector-0.24-2.fc7 Packages built and released for Fedora Extras 6: 42 Terminal-0.2.5.8-0.1.rc2.fc6 Thunar-0.5.0-0.1.rc2.fc6 audacity-1.2.5-3.fc6 exo-0.3.1.12-0.1.rc2.fc6 gaim-gaym-0.96-3.5.291svn.fc6 glitz-0.5.6-5.fc6 gperiodic-2.0.8-7.fc6 gtk-xfce-engine-2.3.99.2-1.fc6 gtkdatabox-0.7.0.0-4.fc6 gwget-0.98.2-1.fc6 libatomic_ops-1.2-1.fc6 libxfce4mcs-4.3.99.2-1.fc6 libxfce4util-4.3.99.2-1.fc6 libxfcegui4-4.3.99.2-1.fc6 mousepad-0.2.10-1.fc6 openct-0.6.10-1.fc6 orage-4.3.99.2-1.fc6 pan-0.119-1.fc6 perl-Alien-wxWidgets-0.25-1.fc6 perl-Cairo-1.02-1.fc6 perl-Email-Address-1.880-1.fc6 perl-Module-ScanDeps-0.69-1.fc6 perl-Sub-Uplevel-0.14-1.fc6 perl-Wx-0.60-1.fc6 php-pear-Cache-1.5.5-0.1.RC4.fc6.1 php-pear-XML-RSS-0.9.10-2.fc6 trac-0.10.1-1.fc6 xfce-mcs-manager-4.3.99.2-1.fc6 xfce-mcs-plugins-4.3.99.2-1.fc6 xfce-utils-4.3.99.2-1.fc6 xfce4-appfinder-4.3.99.2-1.fc6 xfce4-battery-plugin-0.4.90.3-1.fc6 xfce4-dev-tools-4.3.99.2-1.fc6 xfce4-genmon-plugin-3.0-2.fc6 xfce4-icon-theme-4.3.99.2-1.fc6 xfce4-mixer-4.3.99.2-1.fc6 xfce4-panel-4.3.99.2-1.fc6 xfce4-session-4.3.99.2-1.fc6 xfdesktop-4.3.99.2-1.fc6 xfprint-4.3.99.2-1.fc6 xfwm4-4.3.99.2-1.fc6 xfwm4-themes-4.3.99.2-1.fc6 Packages built and released for Fedora Extras 5: 18 audacity-1.2.5-3.fc5 glitz-0.5.6-5.fc5 gperiodic-2.0.8-7.fc5 gtkdatabox-0.7.0.0-4.fc5 libatomic_ops-1.2-1.fc5 monotone-0.31-1.fc5 perl-Alien-wxWidgets-0.25-1.fc5 perl-Cairo-1.02-1.fc5 perl-Email-Address-1.880-1.fc5 perl-Module-ScanDeps-0.69-1.fc5 perl-Sub-Uplevel-0.14-1.fc5 perl-Wx-0.60-1.fc5 php-pear-Cache-1.5.5-0.1.RC4.fc5 php-pear-XML-RSS-0.9.10-2.fc5 sysprof-1.0.5-1.fc5 sysprof-kmod-1.0.5-1.2.6.18_1.2239.fc5 trac-0.10.1-1.fc5 zeroinstall-injector-0.24-2.fc5 Packages built and released for Fedora Extras 4: 3 gtkdatabox-0.7.0.0-4.fc4 trac-0.10.1-1.fc4 zeroinstall-injector-0.24-2.fc4 Packages built and released for Fedora Extras 3: 1 zeroinstall-injector-0.24-2.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun Nov 12 13:18:32 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 12 Nov 2006 13:18:32 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-12 Message-ID: <20061112131832.14788.95792@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 (12 days) centericq - 4.21.0-8.fc6.ppc (12 days) centericq - 4.21.0-8.fc6.x86_64 (12 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (15 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (15 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (15 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (15 days) orange - 0.3-3.cvs20051118.fc6.i386 (19 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (43 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (43 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (43 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc5.i386 (4 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc5.ppc (4 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-4.fc5.x86_64 (4 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-5.fc7.i386 (4 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-5.fc7.ppc (4 days) sylpheed-claws-plugins-etpan-privacy - 2.5.2-5.fc7.x86_64 (4 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (58 days) plague - 0.4.4.1-2.fc3.noarch (58 days) plague - 0.4.4.1-2.fc4.noarch (58 days) plague - 0.4.4.1-2.fc4.noarch (58 days) plague - 0.4.4.1-2.fc4.noarch (58 days) giallu AT gmail.com sysprof - 1.0.5-1.fc6.i386 (9 days) sysprof - 1.0.5-1.fc6.x86_64 (9 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (34 days) linphone - 1.2.0-4.fc5.ppc (34 days) linphone - 1.2.0-4.fc5.x86_64 (34 days) oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (24 days) syck-php - 0.55-9.fc5.ppc (24 days) syck-php - 0.55-9.fc5.x86_64 (24 days) petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 (3 days) ghc-gtk2hs - 0.9.10-4.fc6.i386 (3 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (3 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (3 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (3 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (3 days) ghc642-gtk2hs - 0.9.10-4.fc6.i386 (9 days) ghc642-gtk2hs - 0.9.10-4.fc6.ppc (9 days) ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 (9 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 (9 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc (9 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 (9 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (14 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 sylpheed-claws-plugins-etpan-privacy-2.5.2-5.fc7.ppc requires libetpan.so.8 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 sylpheed-claws-plugins-etpan-privacy-2.5.2-5.fc7.x86_64 requires libetpan.so.8()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 sylpheed-claws-plugins-etpan-privacy-2.5.2-5.fc7.i386 requires libetpan.so.8 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 sysprof-1.0.5-1.fc6.x86_64 requires kmod-sysprof >= 0:1.0.5 Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 sysprof-1.0.5-1.fc6.i386 requires kmod-sysprof >= 0:1.0.5 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc5.ppc requires libetpan.so.8 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc5.x86_64 requires libetpan.so.8()(64bit) Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc5.i386 requires libetpan.so.8 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: rdieter AT math.unl.edu package: gift - 0.11.8.1-6.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libmagic.so.1 From giallu at gmail.com Sun Nov 12 15:15:26 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 12 Nov 2006 16:15:26 +0100 Subject: Democracy player anyone? In-Reply-To: <20061112112916.bf528d24.bugs.michael@gmx.net> References: <883cfe6d0611070647l665292cfq428bc93a8e17a1a7@mail.gmail.com> <883cfe6d0611112316y2ffd9bedrf8879f59e5c81335@mail.gmail.com> <20061112112916.bf528d24.bugs.michael@gmx.net> Message-ID: On 11/12/06, Michael Schwendt wrote: > On Sun, 12 Nov 2006 02:16:01 -0500, Michel Salim wrote: > > > I tried using %find_lang, but it's bizarre how it could not pick up > > the localization files. > > The first parameter of %find_lang serves two purposes: > > 1) it's a file name prefix, which will be prepended to ".lang", resulting > in the file which contains a generated fragment for the %files section > > 2) it's a regular expression, used when searching for message object files > > So, when the package is called "Democracy" and the .mo files are called > "democracyplayer.mo", the regexp pattern fails, since you cannot simply > use "%find_lang %name" anymore. You would need "%find_lang democracyplayer" > or a hack-ish regexp pattern, which also gives a working filename. > Question: IIRC in the wiki there was a reference to some BRs to add for using the %find_lang macro, but now I can not find anything like that. Is anything at all needed for it to work? From bugs.michael at gmx.net Sun Nov 12 15:46:15 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 12 Nov 2006 16:46:15 +0100 Subject: find_lang macro (was: Re: Democracy player anyone?) In-Reply-To: References: <883cfe6d0611070647l665292cfq428bc93a8e17a1a7@mail.gmail.com> <883cfe6d0611112316y2ffd9bedrf8879f59e5c81335@mail.gmail.com> <20061112112916.bf528d24.bugs.michael@gmx.net> Message-ID: <20061112164615.2d820445.bugs.michael@gmx.net> On Sun, 12 Nov 2006 16:15:26 +0100, Gianluca Sforna wrote: > Question: IIRC in the wiki there was a reference to some BRs to add > for using the %find_lang macro, but now I can not find anything like > that. > > Is anything at all needed for it to work? The macro itself needs nothing else than "find". You can examine it in /usr/lib/rpm/redhat/find-lang.sh But in order to (re-)build message object files, you either need BR gettext [most often] or BR intltool or BR perl(XML::Parser) [the latter only if a copy of intltool is included with a tarball]. When either of the first two is search for by a configure script, you see corresponding status messages about what is found or missing. From giallu at gmail.com Sun Nov 12 15:52:01 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 12 Nov 2006 16:52:01 +0100 Subject: find_lang macro (was: Re: Democracy player anyone?) In-Reply-To: <20061112164615.2d820445.bugs.michael@gmx.net> References: <883cfe6d0611070647l665292cfq428bc93a8e17a1a7@mail.gmail.com> <883cfe6d0611112316y2ffd9bedrf8879f59e5c81335@mail.gmail.com> <20061112112916.bf528d24.bugs.michael@gmx.net> <20061112164615.2d820445.bugs.michael@gmx.net> Message-ID: On 11/12/06, Michael Schwendt wrote: > On Sun, 12 Nov 2006 16:15:26 +0100, Gianluca Sforna wrote: > > > Question: IIRC in the wiki there was a reference to some BRs to add > > for using the %find_lang macro, but now I can not find anything like > > that. > > > > Is anything at all needed for it to work? > > The macro itself needs nothing else than "find". You can examine it > in /usr/lib/rpm/redhat/find-lang.sh > > But in order to (re-)build message object files, you either need > BR gettext [most often] or BR intltool or BR perl(XML::Parser) > [the latter only if a copy of intltool is included with a tarball]. > When either of the first two is search for by a configure script, > you see corresponding status messages about what is found or missing. > Thanks a lot for the clarification: maybe the packaging guidelines could be amended with this info From michel.salim at gmail.com Sun Nov 12 18:47:35 2006 From: michel.salim at gmail.com (Michel Salim) Date: Sun, 12 Nov 2006 13:47:35 -0500 Subject: Democracy player anyone? In-Reply-To: <20061112112916.bf528d24.bugs.michael@gmx.net> References: <883cfe6d0611070647l665292cfq428bc93a8e17a1a7@mail.gmail.com> <883cfe6d0611112316y2ffd9bedrf8879f59e5c81335@mail.gmail.com> <20061112112916.bf528d24.bugs.michael@gmx.net> Message-ID: <883cfe6d0611121047w2b617160j9694d5908368286e@mail.gmail.com> On 11/12/06, Michael Schwendt wrote: > On Sun, 12 Nov 2006 02:16:01 -0500, Michel Salim wrote: > > > I tried using %find_lang, but it's bizarre how it could not pick up > > the localization files. > > The first parameter of %find_lang serves two purposes: > > 1) it's a file name prefix, which will be prepended to ".lang", resulting > in the file which contains a generated fragment for the %files section > > 2) it's a regular expression, used when searching for message object files > > So, when the package is called "Democracy" and the .mo files are called > "democracyplayer.mo", the regexp pattern fails, since you cannot simply > use "%find_lang %name" anymore. You would need "%find_lang democracyplayer" > or a hack-ish regexp pattern, which also gives a working filename. > Tried that. Even tried using /usr/lib/rpm/find-lang.sh $RPM_BUILD_ROOT %name --all-name, which /should/ pick up every .mo file under the build root, right? -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From bugs.michael at gmx.net Sun Nov 12 19:45:05 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 12 Nov 2006 20:45:05 +0100 Subject: Democracy player anyone? In-Reply-To: <883cfe6d0611121047w2b617160j9694d5908368286e@mail.gmail.com> References: <883cfe6d0611070647l665292cfq428bc93a8e17a1a7@mail.gmail.com> <883cfe6d0611112316y2ffd9bedrf8879f59e5c81335@mail.gmail.com> <20061112112916.bf528d24.bugs.michael@gmx.net> <883cfe6d0611121047w2b617160j9694d5908368286e@mail.gmail.com> Message-ID: <20061112204505.6fa2cd59.bugs.michael@gmx.net> On Sun, 12 Nov 2006 13:47:35 -0500, Michel Salim wrote: > > > I tried using %find_lang, but it's bizarre how it could not pick up > > > the localization files. > > > > The first parameter of %find_lang serves two purposes: > > > > 1) it's a file name prefix, which will be prepended to ".lang", resulting > > in the file which contains a generated fragment for the %files section > > > > 2) it's a regular expression, used when searching for message object files > > > > So, when the package is called "Democracy" and the .mo files are called > > "democracyplayer.mo", the regexp pattern fails, since you cannot simply > > use "%find_lang %name" anymore. You would need "%find_lang democracyplayer" > > or a hack-ish regexp pattern, which also gives a working filename. > > > Tried that. Even tried using /usr/lib/rpm/find-lang.sh $RPM_BUILD_ROOT > %name --all-name, which /should/ pick up every .mo file under the > build root, right? A common mistake is to run "%find_lang SOMETHING", but forget to do %files -f SOMETHING.lang ... Just a guess. From peter at thecodergeek.com Sun Nov 12 19:45:19 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 12 Nov 2006 11:45:19 -0800 Subject: Potential Orphans: obconf, obmenu, and openbox Message-ID: <1163360719.3399.15.camel@tuxhugger> Hi, all. I've added obconf, obmenu, and openbox to the "Potential Unmaintained" category on the Extras/OrphanedPackages wiki page [1]. I no longer actively use any of these; and I believe that these packages would benefit from having a new maintainer who does. Thanks. [1] http://fedoraproject.org/wiki/Extras/OrphanedPackages -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at fedoraproject.org Sun Nov 12 20:08:46 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 12 Nov 2006 15:08:46 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-12 Message-ID: <20061112200846.24A2D15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 4 flight-of-the-amazon-queen-cd-1.0-1 moomps-5.7-3.fc7 pyserial-2.2-4.fc7 tinyca2-0.7.5-3.fc7 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From lmacken at redhat.com Sun Nov 12 21:21:09 2006 From: lmacken at redhat.com (Luke Macken) Date: Sun, 12 Nov 2006 16:21:09 -0500 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <455405C8.9040103@fedoraproject.org> References: <45530A78.7040908@hhs.nl> <200611091110.52072.jkeating@redhat.com> <1163097030.26926.32.camel@mccallum.corsepiu.local> <200611092240.59260.jkeating@redhat.com> <1163133942.456.33.camel@mccallum.corsepiu.local> <455405C8.9040103@fedoraproject.org> Message-ID: <20061112212108.GC7378@tomservo.rh.rit.edu> On Fri, Nov 10, 2006 at 10:23:28AM +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > >On Thu, 2006-11-09 at 22:40 -0500, Jesse Keating wrote: > >>On Thursday 09 November 2006 13:30, Ralf Corsepius wrote: > >>>>There are many users of Fedora in general that wish to only take in > >>>>security fixes and not 'random update maintainer thought was cool'. > >>>Urban legend: Fedora user run yum, therefore they get what is being > >>>pushed - If they don't run yum, they doen't even get it running. > >>With a proper update tool, you can mark an update as being a security > >>update, and it will show as such in things like pirut. > > > >How does pirut access other sources of information than yum does (repos > >and rpms)? > > It doesnt have to. The metadata is already there. Luke did that work at > http://people.redhat.com/lmacken/metadata/ The code on that page is actually from the original prototype, which used createrepo to pull down the update metadata from a central location. I have since removed that code from createrepo, and now the update system uses modifyrepo[0] to insert this metadata into the repository. >From here, the client tools use the yum.update_md module to utilize this metadata. I just took my people.redhat.com/lmacken/metadata page down as to not cause any more confusion :) luke [0]: https://lists.dulug.duke.edu/pipermail/rpm-metadata/2006-August/000687.html From lmacken at redhat.com Sun Nov 12 21:27:52 2006 From: lmacken at redhat.com (Luke Macken) Date: Sun, 12 Nov 2006 16:27:52 -0500 Subject: Disturbing lack of FE security updates announcements! In-Reply-To: <45537F89.1030900@hhs.nl> References: <45530A78.7040908@hhs.nl> <1163081871.7601.93.camel@mccallum.corsepiu.local> <45534B85.6020105@hhs.nl> <200611091059.48736.jkeating@redhat.com> <45537F89.1030900@hhs.nl> Message-ID: <20061112212752.GD7378@tomservo.rh.rit.edu> On Thu, Nov 09, 2006 at 08:20:41PM +0100, Hans de Goede wrote: > > > Jesse Keating wrote: > > On Thursday 09 November 2006 10:38, Hans de Goede wrote: > >> The problem I'm trying to address here is that there is no way for end > >> users to find out about FE package updates which are security related. This > >> is BAD, hence my suggestion to ask maintainers to send a security update > >> announcement (in a predefined format / template) to > >> fedora-packages-announce when there is a security related update of an FE > >> package they (the maintainers) maintain. > > > > Luke Macken, and others of the infrastructure group, are working on a tool > > that will facilitate this, and take the guess work out of much of the > > formatting and the manual bug closing, etc... > > > > > > GOOD! ETA? Soon. This is going to be my top priority in about a week. There are screenshots of the current update system that I wrote a couple of summers ago on the wiki[0], and some notes for the new system. I checked in the first bits of the new version into cvs today. It doesn't do much, but it defines the database model and a few controllers, and lots of TODO comments. If anyone is interested in helping out with this project, please let me know. I will be laying out some detailed tasks in the near future that people can work on. luke [0]: http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem From michel.salim at gmail.com Sun Nov 12 21:45:19 2006 From: michel.salim at gmail.com (Michel Salim) Date: Sun, 12 Nov 2006 16:45:19 -0500 Subject: Democracy player anyone? In-Reply-To: <20061112204505.6fa2cd59.bugs.michael@gmx.net> References: <883cfe6d0611070647l665292cfq428bc93a8e17a1a7@mail.gmail.com> <883cfe6d0611112316y2ffd9bedrf8879f59e5c81335@mail.gmail.com> <20061112112916.bf528d24.bugs.michael@gmx.net> <883cfe6d0611121047w2b617160j9694d5908368286e@mail.gmail.com> <20061112204505.6fa2cd59.bugs.michael@gmx.net> Message-ID: <883cfe6d0611121345g4bab2fb0w86bb3a778517c8a2@mail.gmail.com> On 11/12/06, Michael Schwendt wrote: > A common mistake is to run "%find_lang SOMETHING", but forget to do > > %files -f SOMETHING.lang > ... > Another (common?) mistake is to have a 'cd' command within the %install section, not realizing that the x.lang file ends up in a different directory than the source root. New spec with %find_lang, and the offending cd replaced by pushd / popd. Does anyone know where the player actually make use of libfame? Grepping the source for fame only yields setup.cfg and README. -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac -------------- next part -------------- A non-text attachment was scrubbed... Name: Democracy.spec Type: application/octet-stream Size: 3337 bytes Desc: not available URL: From giallu at gmail.com Sun Nov 12 23:00:04 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 13 Nov 2006 00:00:04 +0100 Subject: Democracy player anyone? In-Reply-To: <883cfe6d0611121345g4bab2fb0w86bb3a778517c8a2@mail.gmail.com> References: <883cfe6d0611070647l665292cfq428bc93a8e17a1a7@mail.gmail.com> <883cfe6d0611112316y2ffd9bedrf8879f59e5c81335@mail.gmail.com> <20061112112916.bf528d24.bugs.michael@gmx.net> <883cfe6d0611121047w2b617160j9694d5908368286e@mail.gmail.com> <20061112204505.6fa2cd59.bugs.michael@gmx.net> <883cfe6d0611121345g4bab2fb0w86bb3a778517c8a2@mail.gmail.com> Message-ID: On 11/12/06, Michel Salim wrote: > On 11/12/06, Michael Schwendt wrote: > > > A common mistake is to run "%find_lang SOMETHING", but forget to do > > > > %files -f SOMETHING.lang > > ... > > > Another (common?) mistake is to have a 'cd' command within the > %install section, not realizing that the x.lang file ends up in a > different directory than the source root. > > New spec with %find_lang, and the offending cd replaced by pushd / > popd. Does anyone know where the player actually make use of libfame? > Grepping the source for fame only yields setup.cfg and README. I don't really know: it's there because I saw it in their own spec. What I know is that the player works even when I "yum remove libfame" Salim, are you going to submit this for review? From peter at thecodergeek.com Sun Nov 12 23:34:53 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 12 Nov 2006 15:34:53 -0800 Subject: Potential Orphans: obconf, obmenu, and openbox In-Reply-To: <1163360719.3399.15.camel@tuxhugger> References: <1163360719.3399.15.camel@tuxhugger> Message-ID: <1163374493.8617.9.camel@tuxhugger> On Sun, 2006-11-12 at 11:45 -0800, Peter Gordon wrote: > Hi, all. > > I've added obconf, obmenu, and openbox to the "Potential Unmaintained" > category on the Extras/OrphanedPackages wiki page [1]. I no longer > actively use any of these; and I believe that these packages would > benefit from having a new maintainer who does. A couple of people on IRC (#openbox) asked me to clarify this for them, so I'll post it here also to clear up any potential misunderstandings. I see myself as a steward for these packages at this time. I intend to keep them updated and continue to help triage their bugs, etc.; but I feel that a maintainer who actually and actively uses these packages would be more receptive and helpful to these ends. Thanks. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From michel.salim at gmail.com Sun Nov 12 23:45:05 2006 From: michel.salim at gmail.com (Michel Salim) Date: Sun, 12 Nov 2006 18:45:05 -0500 Subject: Democracy player anyone? In-Reply-To: References: <883cfe6d0611070647l665292cfq428bc93a8e17a1a7@mail.gmail.com> <883cfe6d0611112316y2ffd9bedrf8879f59e5c81335@mail.gmail.com> <20061112112916.bf528d24.bugs.michael@gmx.net> <883cfe6d0611121047w2b617160j9694d5908368286e@mail.gmail.com> <20061112204505.6fa2cd59.bugs.michael@gmx.net> <883cfe6d0611121345g4bab2fb0w86bb3a778517c8a2@mail.gmail.com> Message-ID: <883cfe6d0611121545k24dd7fccmc5e803a1a5eaff77@mail.gmail.com> On 11/12/06, Gianluca Sforna wrote: > I don't really know: it's there because I saw it in their own spec. > What I know is that the player works even when I "yum remove libfame" > > Salim, are you going to submit this for review? I can do it if it's OK with you, or I can review your submission. As Neal said, though, I'd want to wait until there is a stable x86_64 version. Unless we agree to ExcludeArch x86_64 for now? Or perhaps even make it an ix86 ExclusiveArch, if it's (as is probable) not working on PPC either -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From giallu at gmail.com Mon Nov 13 00:45:53 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 13 Nov 2006 01:45:53 +0100 Subject: Democracy player anyone? In-Reply-To: <883cfe6d0611121545k24dd7fccmc5e803a1a5eaff77@mail.gmail.com> References: <883cfe6d0611112316y2ffd9bedrf8879f59e5c81335@mail.gmail.com> <20061112112916.bf528d24.bugs.michael@gmx.net> <883cfe6d0611121047w2b617160j9694d5908368286e@mail.gmail.com> <20061112204505.6fa2cd59.bugs.michael@gmx.net> <883cfe6d0611121345g4bab2fb0w86bb3a778517c8a2@mail.gmail.com> <883cfe6d0611121545k24dd7fccmc5e803a1a5eaff77@mail.gmail.com> Message-ID: On 11/13/06, Michel Salim wrote: > On 11/12/06, Gianluca Sforna wrote: > > I don't really know: it's there because I saw it in their own spec. > > What I know is that the player works even when I "yum remove libfame" > > > > Salim, are you going to submit this for review? > > I can do it if it's OK with you, or I can review your submission. My primary interest is seeing this into extras: if you have spare cycles to maintain the package I am more than happy stop having a look at it (apart, of course, if you will need an official review). > As > Neal said, though, I'd want to wait until there is a stable x86_64 > version. Unless we agree to ExcludeArch x86_64 for now? Or perhaps > even make it an ix86 ExclusiveArch, if it's (as is probable) not > working on PPC either I can't test PPC, but if deps are in the repo, I think there are more chances for PPC to work than for x86_64 However, waiting for the new release or going for the review is your call: I'd wait for the next release in order to decide which path is better From tjb at unh.edu Mon Nov 13 01:57:34 2006 From: tjb at unh.edu (Thomas J. Baker) Date: Sun, 12 Nov 2006 20:57:34 -0500 Subject: Tracker? Message-ID: <1163383054.4888.4.camel@continuity> I thought an update to mikmod was supposed to allow me to install tracker? When I try, yum always wants to install mikmod from core, even if I have mikmod from updates already installed. I know I could fix this with an exclude from core but I thought I read this should be fixed without that. 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 michel.salim at gmail.com Mon Nov 13 01:58:51 2006 From: michel.salim at gmail.com (Michel Salim) Date: Sun, 12 Nov 2006 20:58:51 -0500 Subject: Python naming clarification Message-ID: <883cfe6d0611121758h1b39a8b2g80aeb593f5971b35@mail.gmail.com> According to the Package Naming Guidelines, python-dependent packages should be named python-%{name}, unless the name contains py or Py. I'm looking at packaging Django, which is a web application framework similar to TurboGears, and I note that the latter is in Fedora under the name of, yes, TurboGears. Are application frameworks considered large enough to be exempted from the naming requirement? If not, what is the capitalization rule that apply - python-Django (ugly) or python-django? Thanks, -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From michel.salim at gmail.com Mon Nov 13 02:12:51 2006 From: michel.salim at gmail.com (Michel Salim) Date: Sun, 12 Nov 2006 21:12:51 -0500 Subject: Democracy player anyone? In-Reply-To: References: <883cfe6d0611112316y2ffd9bedrf8879f59e5c81335@mail.gmail.com> <20061112112916.bf528d24.bugs.michael@gmx.net> <883cfe6d0611121047w2b617160j9694d5908368286e@mail.gmail.com> <20061112204505.6fa2cd59.bugs.michael@gmx.net> <883cfe6d0611121345g4bab2fb0w86bb3a778517c8a2@mail.gmail.com> <883cfe6d0611121545k24dd7fccmc5e803a1a5eaff77@mail.gmail.com> Message-ID: <883cfe6d0611121812m6587150bh7f57c7f32fcb76e4@mail.gmail.com> On 11/12/06, Gianluca Sforna wrote: > On 11/13/06, Michel Salim wrote: > > On 11/12/06, Gianluca Sforna wrote: > > > I don't really know: it's there because I saw it in their own spec. > > > What I know is that the player works even when I "yum remove libfame" > > > > > > Salim, are you going to submit this for review? > > > > I can do it if it's OK with you, or I can review your submission. > > My primary interest is seeing this into extras: if you have spare > cycles to maintain the package I am more than happy stop having a look > at it (apart, of course, if you will need an official review). > I'll take up your review offer, thanks. > However, waiting for the new release or going for the review is your > call: I'd wait for the next release in order to decide which path is > better > I think I'll do that. Meanwhile, I'll stress-test the i386 version once mock finishes building it, so that the review can go up once the next version is out. Regards, -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From bugs.michael at gmx.net Mon Nov 13 02:48:01 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 13 Nov 2006 03:48:01 +0100 Subject: Tracker? In-Reply-To: <1163383054.4888.4.camel@continuity> References: <1163383054.4888.4.camel@continuity> Message-ID: <20061113034801.e09981ce.bugs.michael@gmx.net> On Sun, 12 Nov 2006 20:57:34 -0500, Thomas J. Baker wrote: > I thought an update to mikmod was supposed to allow me to install > tracker? When I try, yum always wants to install mikmod from core, even > if I have mikmod from updates already installed. I know I could fix this > with an exclude from core but I thought I read this should be fixed > without that. Smells a bit like the old "shortest name wins" behaviour of Yum when multiple packages provide the same thing. Because mikmod in Core still provides "tracker", non-versioned, and "mikmod" is 6 characters, "tracker" is 7 characters. Using non-versioned Provides to create virtual packages is evil. From kevin.kofler at chello.at Mon Nov 13 03:57:10 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 13 Nov 2006 03:57:10 +0000 (UTC) Subject: Tracker? References: <1163383054.4888.4.camel@continuity> Message-ID: Thomas J. Baker writes: > I thought an update to mikmod was supposed to allow me to install > tracker? When I try, yum always wants to install mikmod from core, even > if I have mikmod from updates already installed. I know I could fix this > with an exclude from core but I thought I read this should be fixed > without that. Synaptic does the right thing. Kevin Kofler From jkeating at redhat.com Mon Nov 13 03:58:34 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 12 Nov 2006 22:58:34 -0500 Subject: Python naming clarification In-Reply-To: <883cfe6d0611121758h1b39a8b2g80aeb593f5971b35@mail.gmail.com> References: <883cfe6d0611121758h1b39a8b2g80aeb593f5971b35@mail.gmail.com> Message-ID: <200611122258.37263.jkeating@redhat.com> On Sunday 12 November 2006 20:58, Michel Salim wrote: > According to the Package Naming Guidelines, python-dependent packages > should be named python-%{name}, unless the name contains py or Py. I'm > looking at packaging Django, which is a web application framework > similar to TurboGears, and I note that the latter is in Fedora under > the name of, yes, TurboGears. I thought it was python module packages that needed to be python-foo or pyfoo or foopy. Applications that happen to be written or partially written in python are exempt from this, or so I assumed (as I just submitted and built pungi, an application that is written in python, and has its own python module (pypungi)). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Mon Nov 13 04:47:39 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 12 Nov 2006 23:47:39 -0500 Subject: Tracker? In-Reply-To: References: <1163383054.4888.4.camel@continuity> Message-ID: <1163393259.9312.36.camel@cutter> On Mon, 2006-11-13 at 03:57 +0000, Kevin Kofler wrote: > Thomas J. Baker writes: > > I thought an update to mikmod was supposed to allow me to install > > tracker? When I try, yum always wants to install mikmod from core, even > > if I have mikmod from updates already installed. I know I could fix this > > with an exclude from core but I thought I read this should be fixed > > without that. > > Synaptic does the right thing. how is installing a package which something you have installed obsoletes the 'right thing'? -sv From michel.salim at gmail.com Mon Nov 13 04:47:07 2006 From: michel.salim at gmail.com (Michel Salim) Date: Sun, 12 Nov 2006 23:47:07 -0500 Subject: Python naming clarification In-Reply-To: <200611122258.37263.jkeating@redhat.com> References: <883cfe6d0611121758h1b39a8b2g80aeb593f5971b35@mail.gmail.com> <200611122258.37263.jkeating@redhat.com> Message-ID: <883cfe6d0611122047r79a5406elfdb051f7f7d2fde@mail.gmail.com> On 11/12/06, Jesse Keating wrote: > On Sunday 12 November 2006 20:58, Michel Salim wrote: > > According to the Package Naming Guidelines, python-dependent packages > > should be named python-%{name}, unless the name contains py or Py. I'm > > looking at packaging Django, which is a web application framework > > similar to TurboGears, and I note that the latter is in Fedora under > > the name of, yes, TurboGears. > > I thought it was python module packages that needed to be python-foo or pyfoo > or foopy. Applications that happen to be written or partially written in > python are exempt from this, or so I assumed (as I just submitted and built > pungi, an application that is written in python, and has its own python > module (pypungi)). > Ah, good. I just submitted it as Django: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215267 -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From dakingun at gmail.com Mon Nov 13 05:22:47 2006 From: dakingun at gmail.com (Deji Akingunola) Date: Mon, 13 Nov 2006 00:22:47 -0500 Subject: Tracker? In-Reply-To: <1163393259.9312.36.camel@cutter> References: <1163383054.4888.4.camel@continuity> <1163393259.9312.36.camel@cutter> Message-ID: On 11/12/06, seth vidal wrote: > On Mon, 2006-11-13 at 03:57 +0000, Kevin Kofler wrote: > > Thomas J. Baker writes: > > > I thought an update to mikmod was supposed to allow me to install > > > tracker? When I try, yum always wants to install mikmod from core, even > > > if I have mikmod from updates already installed. I know I could fix this > > > with an exclude from core but I thought I read this should be fixed > > > without that. > > > > Synaptic does the right thing. > > how is installing a package which something you have installed obsoletes > the 'right thing'? > There's a newer mikmod in FC-6 updates that doesn't obsoletes tracker anymore. Despite having the newer mikmod, yum is still wanting to grab the old mikmod in the core repository when asked to newly install tracker. > -sv > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From michel.salim at gmail.com Mon Nov 13 05:24:57 2006 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 13 Nov 2006 00:24:57 -0500 Subject: Tracker? In-Reply-To: <1163393259.9312.36.camel@cutter> References: <1163383054.4888.4.camel@continuity> <1163393259.9312.36.camel@cutter> Message-ID: <883cfe6d0611122124r4d2c5d8cmdb79ad2624092b49@mail.gmail.com> On 11/12/06, seth vidal wrote: > On Mon, 2006-11-13 at 03:57 +0000, Kevin Kofler wrote: > > Thomas J. Baker writes: > > > I thought an update to mikmod was supposed to allow me to install > > > tracker? When I try, yum always wants to install mikmod from core, even > > > if I have mikmod from updates already installed. I know I could fix this > > > with an exclude from core but I thought I read this should be fixed > > > without that. > > > > Synaptic does the right thing. > > how is installing a package which something you have installed obsoletes > the 'right thing'? > Because the mikmod from updates have a higher version, and should cause mikmod from core to be ignored completely? -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From skvidal at linux.duke.edu Mon Nov 13 05:44:16 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 13 Nov 2006 00:44:16 -0500 Subject: Tracker? In-Reply-To: References: <1163383054.4888.4.camel@continuity> <1163393259.9312.36.camel@cutter> Message-ID: <1163396656.9312.43.camel@cutter> On Mon, 2006-11-13 at 00:22 -0500, Deji Akingunola wrote: > On 11/12/06, seth vidal wrote: > > On Mon, 2006-11-13 at 03:57 +0000, Kevin Kofler wrote: > > > Thomas J. Baker writes: > > > > I thought an update to mikmod was supposed to allow me to install > > > > tracker? When I try, yum always wants to install mikmod from core, even > > > > if I have mikmod from updates already installed. I know I could fix this > > > > with an exclude from core but I thought I read this should be fixed > > > > without that. > > > > > > Synaptic does the right thing. > > > > how is installing a package which something you have installed obsoletes > > the 'right thing'? > > > There's a newer mikmod in FC-6 updates that doesn't obsoletes tracker > anymore. Despite having the newer mikmod, yum is still wanting to grab > the old mikmod in the core repository when asked to newly install > tracker. If the old one is still there then it still obsoletes tracker. -sv From giallu at gmail.com Mon Nov 13 07:49:49 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 13 Nov 2006 08:49:49 +0100 Subject: Tracker? In-Reply-To: References: <1163383054.4888.4.camel@continuity> <1163393259.9312.36.camel@cutter> Message-ID: On 11/13/06, Deji Akingunola wrote: > On 11/12/06, seth vidal wrote: > > On Mon, 2006-11-13 at 03:57 +0000, Kevin Kofler wrote: > > > Thomas J. Baker writes: > > > > I thought an update to mikmod was supposed to allow me to install > > > > tracker? When I try, yum always wants to install mikmod from core, even > > > > if I have mikmod from updates already installed. I know I could fix this > > > > with an exclude from core but I thought I read this should be fixed > > > > without that. > > > > > > Synaptic does the right thing. > > > > how is installing a package which something you have installed obsoletes > > the 'right thing'? > > > There's a newer mikmod in FC-6 updates that doesn't obsoletes tracker > anymore. Despite having the newer mikmod, yum is still wanting to grab > the old mikmod in the core repository when asked to newly install > tracker. And the strangest is "yum install tracker" works for me on FC5... From fedora at camperquake.de Mon Nov 13 08:58:16 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 13 Nov 2006 09:58:16 +0100 Subject: Tracker? In-Reply-To: <1163396656.9312.43.camel@cutter> References: <1163383054.4888.4.camel@continuity> <1163393259.9312.36.camel@cutter> <1163396656.9312.43.camel@cutter> Message-ID: <20061113095816.75585582@yareena.int.addix.net> Hi. On Mon, 13 Nov 2006 00:44:16 -0500, seth vidal wrote: > If the old one is still there then it still obsoletes tracker. So if I have packages A and B, where B obsoletes A. Now there is a rpm-newer version of B (B-new) in another repo (updates) which no longer obsoletes A. So as long as B exists anywhere I can not install A using yum, because yum still considers the obsolete from B, even though it is no longer relevant in any way? From paul at city-fan.org Mon Nov 13 11:55:25 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 13 Nov 2006 11:55:25 +0000 Subject: Tracker? In-Reply-To: <20061113095816.75585582@yareena.int.addix.net> References: <1163383054.4888.4.camel@continuity> <1163393259.9312.36.camel@cutter> <1163396656.9312.43.camel@cutter> <20061113095816.75585582@yareena.int.addix.net> Message-ID: <45585D2D.4080700@city-fan.org> Ralf Ertzinger wrote: > Hi. > > On Mon, 13 Nov 2006 00:44:16 -0500, seth vidal wrote: > >> If the old one is still there then it still obsoletes tracker. > > So if I have packages A and B, where B obsoletes A. Now there is a rpm-newer > version of B (B-new) in another repo (updates) which no longer obsoletes A. > > So as long as B exists anywhere I can not install A using yum, because > yum still considers the obsolete from B, even though it is no longer relevant > in any way? This looks very much like: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213260 Similar issue, different packages. Paul. From skvidal at linux.duke.edu Mon Nov 13 13:21:24 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 13 Nov 2006 08:21:24 -0500 Subject: Tracker? In-Reply-To: <20061113095816.75585582@yareena.int.addix.net> References: <1163383054.4888.4.camel@continuity> <1163393259.9312.36.camel@cutter> <1163396656.9312.43.camel@cutter> <20061113095816.75585582@yareena.int.addix.net> Message-ID: <1163424084.4862.19.camel@cutter> On Mon, 2006-11-13 at 09:58 +0100, Ralf Ertzinger wrote: > Hi. > > On Mon, 13 Nov 2006 00:44:16 -0500, seth vidal wrote: > > > If the old one is still there then it still obsoletes tracker. > > So if I have packages A and B, where B obsoletes A. Now there is a rpm-newer > version of B (B-new) in another repo (updates) which no longer obsoletes A. > > So as long as B exists anywhere I can not install A using yum, because > yum still considers the obsolete from B, even though it is no longer relevant > in any way? When I was working on the obs vs updates code I kept asking about this. The answer I repeatedly got was that obsoletes trumps updates no matter what. -sv From paul at city-fan.org Mon Nov 13 13:28:09 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 13 Nov 2006 13:28:09 +0000 Subject: Tracker? In-Reply-To: <1163424084.4862.19.camel@cutter> References: <1163383054.4888.4.camel@continuity> <1163393259.9312.36.camel@cutter> <1163396656.9312.43.camel@cutter> <20061113095816.75585582@yareena.int.addix.net> <1163424084.4862.19.camel@cutter> Message-ID: <455872E9.5050903@city-fan.org> seth vidal wrote: > On Mon, 2006-11-13 at 09:58 +0100, Ralf Ertzinger wrote: >> Hi. >> >> On Mon, 13 Nov 2006 00:44:16 -0500, seth vidal wrote: >> >>> If the old one is still there then it still obsoletes tracker. >> So if I have packages A and B, where B obsoletes A. Now there is a rpm-newer >> version of B (B-new) in another repo (updates) which no longer obsoletes A. >> >> So as long as B exists anywhere I can not install A using yum, because >> yum still considers the obsolete from B, even though it is no longer relevant >> in any way? > > When I was working on the obs vs updates code I kept asking about this. > The answer I repeatedly got was that obsoletes trumps updates no matter > what. Was there a reason given for this? What breaks if it's the other way around? Paul. From skvidal at linux.duke.edu Mon Nov 13 13:38:39 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 13 Nov 2006 08:38:39 -0500 Subject: Tracker? In-Reply-To: <455872E9.5050903@city-fan.org> References: <1163383054.4888.4.camel@continuity> <1163393259.9312.36.camel@cutter> <1163396656.9312.43.camel@cutter> <20061113095816.75585582@yareena.int.addix.net> <1163424084.4862.19.camel@cutter> <455872E9.5050903@city-fan.org> Message-ID: <1163425119.4862.21.camel@cutter> On Mon, 2006-11-13 at 13:28 +0000, Paul Howarth wrote: > seth vidal wrote: > > On Mon, 2006-11-13 at 09:58 +0100, Ralf Ertzinger wrote: > >> Hi. > >> > >> On Mon, 13 Nov 2006 00:44:16 -0500, seth vidal wrote: > >> > >>> If the old one is still there then it still obsoletes tracker. > >> So if I have packages A and B, where B obsoletes A. Now there is a rpm-newer > >> version of B (B-new) in another repo (updates) which no longer obsoletes A. > >> > >> So as long as B exists anywhere I can not install A using yum, because > >> yum still considers the obsolete from B, even though it is no longer relevant > >> in any way? > > > > When I was working on the obs vs updates code I kept asking about this. > > The answer I repeatedly got was that obsoletes trumps updates no matter > > what. > > Was there a reason given for this? What breaks if it's the other way around? mainly that an obsoleted package should stay obsoleted. -sv From skvidal at linux.duke.edu Mon Nov 13 14:05:19 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 13 Nov 2006 09:05:19 -0500 Subject: Tracker? In-Reply-To: <1163425119.4862.21.camel@cutter> References: <1163383054.4888.4.camel@continuity> <1163393259.9312.36.camel@cutter> <1163396656.9312.43.camel@cutter> <20061113095816.75585582@yareena.int.addix.net> <1163424084.4862.19.camel@cutter> <455872E9.5050903@city-fan.org> <1163425119.4862.21.camel@cutter> Message-ID: <1163426719.4862.23.camel@cutter> On Mon, 2006-11-13 at 08:38 -0500, seth vidal wrote: > On Mon, 2006-11-13 at 13:28 +0000, Paul Howarth wrote: > > seth vidal wrote: > > > On Mon, 2006-11-13 at 09:58 +0100, Ralf Ertzinger wrote: > > >> Hi. > > >> > > >> On Mon, 13 Nov 2006 00:44:16 -0500, seth vidal wrote: > > >> > > >>> If the old one is still there then it still obsoletes tracker. > > >> So if I have packages A and B, where B obsoletes A. Now there is a rpm-newer > > >> version of B (B-new) in another repo (updates) which no longer obsoletes A. > > >> > > >> So as long as B exists anywhere I can not install A using yum, because > > >> yum still considers the obsolete from B, even though it is no longer relevant > > >> in any way? > > > > > > When I was working on the obs vs updates code I kept asking about this. > > > The answer I repeatedly got was that obsoletes trumps updates no matter > > > what. > > > > Was there a reason given for this? What breaks if it's the other way around? > > mainly that an obsoleted package should stay obsoleted. > Having said that I'm inclined to agree that older pkgs shouldn't be included but I was going along with opinion at that time. -sv From fedora at camperquake.de Mon Nov 13 14:08:43 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 13 Nov 2006 15:08:43 +0100 Subject: Tracker? In-Reply-To: <1163426719.4862.23.camel@cutter> References: <1163383054.4888.4.camel@continuity> <1163393259.9312.36.camel@cutter> <1163396656.9312.43.camel@cutter> <20061113095816.75585582@yareena.int.addix.net> <1163424084.4862.19.camel@cutter> <455872E9.5050903@city-fan.org> <1163425119.4862.21.camel@cutter> <1163426719.4862.23.camel@cutter> Message-ID: <20061113150843.3351a901@yareena.int.addix.net> Hi. On Mon, 13 Nov 2006 09:05:19 -0500, seth vidal wrote: > Having said that I'm inclined to agree that older pkgs shouldn't be > included but I was going along with opinion at that time. This would mean that yum (given my example above) may have to update B if I ask it to install A and already have B installed? From paul at city-fan.org Mon Nov 13 14:16:00 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 13 Nov 2006 14:16:00 +0000 Subject: Tracker? In-Reply-To: <1163425119.4862.21.camel@cutter> References: <1163383054.4888.4.camel@continuity> <1163393259.9312.36.camel@cutter> <1163396656.9312.43.camel@cutter> <20061113095816.75585582@yareena.int.addix.net> <1163424084.4862.19.camel@cutter> <455872E9.5050903@city-fan.org> <1163425119.4862.21.camel@cutter> Message-ID: <45587E20.2040700@city-fan.org> seth vidal wrote: > On Mon, 2006-11-13 at 13:28 +0000, Paul Howarth wrote: >> seth vidal wrote: >>> On Mon, 2006-11-13 at 09:58 +0100, Ralf Ertzinger wrote: >>>> Hi. >>>> >>>> On Mon, 13 Nov 2006 00:44:16 -0500, seth vidal wrote: >>>> >>>>> If the old one is still there then it still obsoletes tracker. >>>> So if I have packages A and B, where B obsoletes A. Now there is a rpm-newer >>>> version of B (B-new) in another repo (updates) which no longer obsoletes A. >>>> >>>> So as long as B exists anywhere I can not install A using yum, because >>>> yum still considers the obsolete from B, even though it is no longer relevant >>>> in any way? >>> When I was working on the obs vs updates code I kept asking about this. >>> The answer I repeatedly got was that obsoletes trumps updates no matter >>> what. >> Was there a reason given for this? What breaks if it's the other way around? > > mainly that an obsoleted package should stay obsoleted. However, that means that if somebody carelessly uses an unversioned obsolete in a package that goes into a distribution release (i.e. the core repo), it is impossible to fix that error by issuing an update that removes the obsolete. Take for instance the selinux-policy package in FC5. The version in the core repo obsoletes selinux-policy-devel, which was fair enough at the time of the release as there was no separate selinux-policy-devel package in Fedora. However, during FC5's lifetime, it became apparent that having an selinux-policy-devel package was desirable from the point of view of managing dependencies, and so the selinux-policy package was split into selinux-policy and selinux-policy-devel. This worked just fine on FC5 and is working fine on FC6 too, where there has been an selinux-policy-devel package in the core repo. Where there is a problem is in building packages targeting FC5 using mock on FC6. The version of yum in FC6 behaves differently to the version in FC5, and decides that a buildreq of selinux-policy-devel (which should be picked up from the updates repo) is obsoleted by the selinux-policy package in the core repo and can be replaced by it. However, that package is buggy and cannot in fact be used to build things. So it's not possible to build packages requiring a buildreq of selinux-policy-devel for FC5 targets on an FC6 host without excluding selinux-policy from the core repo. Coming back to the "an obsoleted package should stay obsoleted" theme, couldn't it be argued that version n of a package is obsoleted by version n+1 of the same package, and hence version n of a package should be ignored in the presence of version n+1? Paul. From buildsys at fedoraproject.org Mon Nov 13 16:02:49 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 13 Nov 2006 11:02:49 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-13 Message-ID: <20061113160249.8EC3815212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 16 blogtk-1.1-7.fc7 eiciel-0.9.4-1.fc7 fillets-ng-data-0.7.1-2 jd-1.8.0-0.6.cvs061112.fc7 manedit-0.7.1-5.fc7 nickle-2.54-2.fc7 ochusha-0.5.99.63.3-0.2.cvs061113.fc7 php-pear-HTML-Common-1.2.3-2.fc7 php-pear-HTML-Table-1.7.5-1.fc7 scummvm-0.9.1-2.fc7 ssmtp-2.61-8.fc7 sylpheed-claws-plugins-2.6.0-1.fc7 torcs-1.3.0-1.fc7 torcs-data-1.3.0-1 xfce4-dict-plugin-0.2.0-2.fc7 xmoto-0.2.2-1.fc7 Packages built and released for Fedora Extras 6: 7 blogtk-1.1-7.fc6 em8300-kmod-0.16.0-0.4.rc2.2.6.18_1.2849.fc6 scummvm-0.9.1-2.fc6 sysprof-kmod-1.0.5-1.2.6.18_1.2849.fc6 tor-0.1.1.25-1.fc6 xmoto-0.2.2-1.fc6 zeroinstall-injector-0.24-2.fc6 Packages built and released for Fedora Extras 5: 5 blogtk-1.1-7.fc5 scummvm-0.9.1-2.fc5 sylpheed-claws-plugins-2.6.0-1.fc5 tor-0.1.1.25-1.fc5 xmoto-0.2.2-1.fc5 Packages built and released for Fedora Extras 4: 1 blogtk-1.1-7.fc4 Packages built and released for Fedora Extras 3: 1 blogtk-1.1-7.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon Nov 13 17:12:04 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 13 Nov 2006 17:12:04 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-13 Message-ID: <20061113171204.13368.50950@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 (13 days) centericq - 4.21.0-8.fc6.ppc (13 days) centericq - 4.21.0-8.fc6.x86_64 (13 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (16 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (16 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (16 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (16 days) orange - 0.3-3.cvs20051118.fc6.i386 (20 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (44 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (44 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (44 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (59 days) plague - 0.4.4.1-2.fc3.noarch (59 days) plague - 0.4.4.1-2.fc4.noarch (59 days) plague - 0.4.4.1-2.fc4.noarch (59 days) plague - 0.4.4.1-2.fc4.noarch (59 days) giallu AT gmail.com kmod-sysprof - 1.0.5-1.2.6.18_1.2798.fc6.i586 kmod-sysprof - 1.0.5-1.2.6.18_1.2798.fc6.i686 kmod-sysprof - 1.0.5-1.2.6.18_1.2798.fc6.x86_64 kmod-sysprof-PAE - 1.0.5-1.2.6.18_1.2798.fc6.i686 kmod-sysprof-kdump - 1.0.5-1.2.6.18_1.2798.fc6.i686 kmod-sysprof-kdump - 1.0.5-1.2.6.18_1.2798.fc6.x86_64 kmod-sysprof-xen - 1.0.5-1.2.6.18_1.2798.fc6.i686 kmod-sysprof-xen - 1.0.5-1.2.6.18_1.2798.fc6.x86_64 jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (35 days) linphone - 1.2.0-4.fc5.ppc (35 days) linphone - 1.2.0-4.fc5.x86_64 (35 days) oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (25 days) syck-php - 0.55-9.fc5.ppc (25 days) syck-php - 0.55-9.fc5.x86_64 (25 days) petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 (4 days) ghc-gtk2hs - 0.9.10-4.fc6.i386 (4 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (4 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (4 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (4 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (4 days) ghc642-gtk2hs - 0.9.10-4.fc6.i386 (10 days) ghc642-gtk2hs - 0.9.10-4.fc6.ppc (10 days) ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 (10 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 (10 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc (10 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 (10 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (15 days) ville.skytta AT iki.fi kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2798.fc6.i586 kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2798.fc6.i686 kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2798.fc6.ppc kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2798.fc6.x86_64 kmod-em8300-PAE - 0.16.0-0.3.rc1.2.6.18_1.2798.fc6.i686 kmod-em8300-kdump - 0.16.0-0.3.rc1.2.6.18_1.2798.fc6.i686 kmod-em8300-kdump - 0.16.0-0.3.rc1.2.6.18_1.2798.fc6.x86_64 kmod-em8300-smp - 0.16.0-0.3.rc1.2.6.18_1.2798.fc6.ppc kmod-em8300-xen - 0.16.0-0.3.rc1.2.6.18_1.2798.fc6.i686 kmod-em8300-xen - 0.16.0-0.3.rc1.2.6.18_1.2798.fc6.x86_64 Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2798.fc6.ppc requires kernel-ppc = 0:2.6.18-1.2798.fc6 kmod-em8300-smp-0.16.0-0.3.rc1.2.6.18_1.2798.fc6.ppc requires kernel-ppc = 0:2.6.18-1.2798.fc6smp libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2798.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2798.fc6 kmod-em8300-kdump-0.16.0-0.3.rc1.2.6.18_1.2798.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2798.fc6kdump kmod-em8300-xen-0.16.0-0.3.rc1.2.6.18_1.2798.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2798.fc6xen kmod-sysprof-1.0.5-1.2.6.18_1.2798.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2798.fc6 kmod-sysprof-kdump-1.0.5-1.2.6.18_1.2798.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2798.fc6kdump kmod-sysprof-xen-1.0.5-1.2.6.18_1.2798.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2798.fc6xen libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2798.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2798.fc6 kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2798.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2798.fc6 kmod-em8300-PAE-0.16.0-0.3.rc1.2.6.18_1.2798.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2798.fc6PAE kmod-em8300-kdump-0.16.0-0.3.rc1.2.6.18_1.2798.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2798.fc6kdump kmod-em8300-xen-0.16.0-0.3.rc1.2.6.18_1.2798.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2798.fc6xen kmod-sysprof-1.0.5-1.2.6.18_1.2798.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2798.fc6 kmod-sysprof-1.0.5-1.2.6.18_1.2798.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2798.fc6 kmod-sysprof-PAE-1.0.5-1.2.6.18_1.2798.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2798.fc6PAE kmod-sysprof-kdump-1.0.5-1.2.6.18_1.2798.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2798.fc6kdump kmod-sysprof-xen-1.0.5-1.2.6.18_1.2798.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2798.fc6xen libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: giallu AT gmail.com package: kmod-sysprof - 1.0.5-1.2.6.18_1.2798.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.18-1.2798.fc6 package: kmod-sysprof-xen - 1.0.5-1.2.6.18_1.2798.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.18-1.2798.fc6xen package: kmod-sysprof-kdump - 1.0.5-1.2.6.18_1.2798.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.18-1.2798.fc6kdump package: kmod-sysprof-kdump - 1.0.5-1.2.6.18_1.2798.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2798.fc6kdump package: kmod-sysprof-PAE - 1.0.5-1.2.6.18_1.2798.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2798.fc6PAE package: kmod-sysprof - 1.0.5-1.2.6.18_1.2798.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2798.fc6 package: kmod-sysprof-xen - 1.0.5-1.2.6.18_1.2798.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2798.fc6xen package: kmod-sysprof - 1.0.5-1.2.6.18_1.2798.fc6.i586 from fedora-extras-development-i386 unresolved deps: kernel-i586 = 0:2.6.18-1.2798.fc6 ====================================================================== New report for: ville.skytta AT iki.fi package: kmod-em8300-smp - 0.16.0-0.3.rc1.2.6.18_1.2798.fc6.ppc from fedora-extras-development-ppc unresolved deps: kernel-ppc = 0:2.6.18-1.2798.fc6smp package: kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2798.fc6.ppc from fedora-extras-development-ppc unresolved deps: kernel-ppc = 0:2.6.18-1.2798.fc6 package: kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2798.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.18-1.2798.fc6 package: kmod-em8300-xen - 0.16.0-0.3.rc1.2.6.18_1.2798.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.18-1.2798.fc6xen package: kmod-em8300-kdump - 0.16.0-0.3.rc1.2.6.18_1.2798.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.18-1.2798.fc6kdump package: kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2798.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2798.fc6 package: kmod-em8300-kdump - 0.16.0-0.3.rc1.2.6.18_1.2798.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2798.fc6kdump package: kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2798.fc6.i586 from fedora-extras-development-i386 unresolved deps: kernel-i586 = 0:2.6.18-1.2798.fc6 package: kmod-em8300-PAE - 0.16.0-0.3.rc1.2.6.18_1.2798.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2798.fc6PAE package: kmod-em8300-xen - 0.16.0-0.3.rc1.2.6.18_1.2798.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2798.fc6xen From a.badger at gmail.com Mon Nov 13 17:18:31 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 13 Nov 2006 09:18:31 -0800 Subject: Python naming clarification In-Reply-To: <883cfe6d0611122047r79a5406elfdb051f7f7d2fde@mail.gmail.com> References: <883cfe6d0611121758h1b39a8b2g80aeb593f5971b35@mail.gmail.com> <200611122258.37263.jkeating@redhat.com> <883cfe6d0611122047r79a5406elfdb051f7f7d2fde@mail.gmail.com> Message-ID: <1163438311.7125.26.camel@localhost.localdomain> On Sun, 2006-11-12 at 23:47 -0500, Michel Salim wrote: > On 11/12/06, Jesse Keating wrote: > > On Sunday 12 November 2006 20:58, Michel Salim wrote: > > > According to the Package Naming Guidelines, python-dependent packages > > > should be named python-%{name}, unless the name contains py or Py. I'm > > > looking at packaging Django, which is a web application framework > > > similar to TurboGears, and I note that the latter is in Fedora under > > > the name of, yes, TurboGears. > > > > I thought it was python module packages that needed to be python-foo or pyfoo > > or foopy. Applications that happen to be written or partially written in > > python are exempt from this, or so I assumed (as I just submitted and built > > pungi, an application that is written in python, and has its own python > > module (pypungi)). > > > Ah, good. I just submitted it as Django: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215267 Jesse is right about modules vs applications but turbogears is definitely a module so I would argue that TurboGears was misnamed when it got in. You use TurboGears in you website using: import turbogears Thus its a module with lowercase import name so it should be named: python-turbogears If Django is also imported it should follow a similar convention: import Django => python-Django import django => python-django -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 sundaram at fedoraproject.org Mon Nov 13 17:31:01 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 13 Nov 2006 23:01:01 +0530 Subject: Fedora Extras Package Build Report 2006-11-13 In-Reply-To: <20061113160249.8EC3815212E@buildsys.fedoraproject.org> References: <20061113160249.8EC3815212E@buildsys.fedoraproject.org> Message-ID: <4558ABD5.3000204@fedoraproject.org> buildsys at fedoraproject.org wrote: > Packages built and released for Fedora Extras development: 16 > > blogtk-1.1-7.fc7 > eiciel-0.9.4-1.fc7 > fillets-ng-data-0.7.1-2 > jd-1.8.0-0.6.cvs061112.fc7 > manedit-0.7.1-5.fc7 > nickle-2.54-2.fc7 > ochusha-0.5.99.63.3-0.2.cvs061113.fc7 > php-pear-HTML-Common-1.2.3-2.fc7 > php-pear-HTML-Table-1.7.5-1.fc7 > scummvm-0.9.1-2.fc7 > ssmtp-2.61-8.fc7 > sylpheed-claws-plugins-2.6.0-1.fc7 > torcs-1.3.0-1.fc7 > torcs-data-1.3.0-1 > xfce4-dict-plugin-0.2.0-2.fc7 > xmoto-0.2.2-1.fc7 Would it be possible to differentiate between NEW and just updated packages? I would like to quickly see how many new packages have been added over a week or month's time. How do I do that easily? Rahul From jwboyer at jdub.homelinux.org Mon Nov 13 17:46:24 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 13 Nov 2006 11:46:24 -0600 Subject: Fedora Extras Package Build Report 2006-11-13 In-Reply-To: <4558ABD5.3000204@fedoraproject.org> References: <20061113160249.8EC3815212E@buildsys.fedoraproject.org> <4558ABD5.3000204@fedoraproject.org> Message-ID: <1163439984.4075.19.camel@zod.rchland.ibm.com> On Mon, 2006-11-13 at 23:01 +0530, Rahul Sundaram wrote: > buildsys at fedoraproject.org wrote: > > Packages built and released for Fedora Extras development: 16 > > > > blogtk-1.1-7.fc7 > > eiciel-0.9.4-1.fc7 > > fillets-ng-data-0.7.1-2 > > jd-1.8.0-0.6.cvs061112.fc7 > > manedit-0.7.1-5.fc7 > > nickle-2.54-2.fc7 > > ochusha-0.5.99.63.3-0.2.cvs061113.fc7 > > php-pear-HTML-Common-1.2.3-2.fc7 > > php-pear-HTML-Table-1.7.5-1.fc7 > > scummvm-0.9.1-2.fc7 > > ssmtp-2.61-8.fc7 > > sylpheed-claws-plugins-2.6.0-1.fc7 > > torcs-1.3.0-1.fc7 > > torcs-data-1.3.0-1 > > xfce4-dict-plugin-0.2.0-2.fc7 > > xmoto-0.2.2-1.fc7 > > Would it be possible to differentiate between NEW and just updated > packages? I would like to quickly see how many new packages have been > added over a week or month's time. How do I do that easily? You can look in bugzilla and keep your query limited to a single month. There was once a movement to get such statistics gathered for easy consumption. I have no idea where that went. josh From michel.salim at gmail.com Mon Nov 13 17:57:56 2006 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 13 Nov 2006 12:57:56 -0500 Subject: Python naming clarification In-Reply-To: <1163438311.7125.26.camel@localhost.localdomain> References: <883cfe6d0611121758h1b39a8b2g80aeb593f5971b35@mail.gmail.com> <200611122258.37263.jkeating@redhat.com> <883cfe6d0611122047r79a5406elfdb051f7f7d2fde@mail.gmail.com> <1163438311.7125.26.camel@localhost.localdomain> Message-ID: <883cfe6d0611130957j1f0d7498ga323c90321d294a4@mail.gmail.com> On 11/13/06, Toshio Kuratomi wrote: > On Sun, 2006-11-12 at 23:47 -0500, Michel Salim wrote: > > On 11/12/06, Jesse Keating wrote: > > > On Sunday 12 November 2006 20:58, Michel Salim wrote: > > > > According to the Package Naming Guidelines, python-dependent packages > > > > should be named python-%{name}, unless the name contains py or Py. I'm > > > > looking at packaging Django, which is a web application framework > > > > similar to TurboGears, and I note that the latter is in Fedora under > > > > the name of, yes, TurboGears. > > > > > > I thought it was python module packages that needed to be python-foo or pyfoo > > > or foopy. Applications that happen to be written or partially written in > > > python are exempt from this, or so I assumed (as I just submitted and built > > > pungi, an application that is written in python, and has its own python > > > module (pypungi)). > > > > > Ah, good. I just submitted it as Django: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215267 > > > Jesse is right about modules vs applications but turbogears is > definitely a module so I would argue that TurboGears was misnamed when > it got in. You use TurboGears in you website using: > import turbogears > > Thus its a module with lowercase import name so it should be named: > python-turbogears > That was my source of confusion, yes. On the other hand, both TurboGears and Django provide scripts for managing your web application, and in fact the interaction between the developer and the framework is through these scripts, so perhaps they can be considered applications? -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From Christian.Iseli at licr.org Mon Nov 13 18:14:03 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Mon, 13 Nov 2006 19:14:03 +0100 Subject: Fedora Extras Package Build Report 2006-11-13 In-Reply-To: <1163439984.4075.19.camel@zod.rchland.ibm.com> References: <20061113160249.8EC3815212E@buildsys.fedoraproject.org> <4558ABD5.3000204@fedoraproject.org> <1163439984.4075.19.camel@zod.rchland.ibm.com> Message-ID: <20061113191403.2595cfb1@ludwig-alpha.unil.ch> On Mon, 13 Nov 2006 11:46:24 -0600, Josh Boyer wrote: > There was once a movement to get such statistics gathered for easy > consumption. I have no idea where that went. I have a couple very rough scripts in: http://cvs.fedora.redhat.com/viewcvs/status-report-scripts/?root=fedora named grabBZstats and bzstat.gp Here is the current result of: $ ./grabBZstats >bzstat.data $ ./bzstat.gp Cheers, C -------------- next part -------------- A non-text attachment was scrubbed... Name: bzstat.data Type: application/octet-stream Size: 1383 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bzstat.png Type: image/png Size: 15980 bytes Desc: not available URL: From ndbecker2 at gmail.com Mon Nov 13 22:48:41 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 13 Nov 2006 17:48:41 -0500 Subject: Democracy player anyone? References: Message-ID: I just tried your spec file with Democracy-2006-11-14.tar.gz. So far so good. From Christian.Iseli at licr.org Mon Nov 13 23:18:01 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 14 Nov 2006 00:18:01 +0100 Subject: Fedora Extras related open tasks Message-ID: <20061114001801.46bd7411@ludwig-alpha.unil.ch> Hi folks, Going fishing here... :-) Here is a list of tasks that can be undertaken by any Fedora Extras contributor. If you have some brain cycles available, please consider contributing some loving care to one or more of them. The principle is quite simple: add your name in the appropriate subpage of http://fedoraproject.org/wiki/Extras/Schedule, discuss things on f-e-l if needed, and report your progress on f-e-l and on the schedule pages itself. You can also find some help on IRC #fedora-extras (and depending on the tasks: #fedora-admin). Please try to keep all discussions related to the tasks public on this mailing list. Tasks: - help the whole EPEL framework lift off - develop kmod support in the buildsys - prepare proposals to have alternative paths of membership advancement - prepare proposals for a "Maintainer Responsibilities" policy - test proposed alternative VCSs - prepare list of criteria to be made a sponsor - help develop and test the package database Of course, please feel free to bring up new "task". For example, there are many ideas that linger around without progress in the wiki container: http://www.fedoraproject.org/wiki/Extras/Schedule/IdeasContainer Please make sure to coordinate with the infrastructure team where needed (see http://fedoraproject.org/wiki/Infrastructure/Schedule). I intend to post those "tasks" mails every couple weeks. I'll do my best to monitor tasks related traffic on f-e-l and summarize progress in the upcoming mails. Let's see if we can cover some ground this way... Cheers, C From peter at thecodergeek.com Tue Nov 14 05:44:52 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 13 Nov 2006 21:44:52 -0800 Subject: Anyone Working on Packaging Labyrinth? Message-ID: <1163483092.3489.6.camel@tuxhugger> Hi, all. I recently started needing to do mind-mapping stuff for school and I found Labyrinth [1] on the Extras/WishList wiki page which I've found very useful for this, so I plan to get submit this for an Extras review; however before I do I'd like to know if anyone is working on such a package already. A search on Bugzilla didn't return anything; but I'd prevent to prevent myself from redoing a lot of the work if it's already in progress, and I could simply help with it. Thanks. [1] http://www.gnome.org/~dscorgie/labyrinth.html -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From peter at thecodergeek.com Tue Nov 14 05:56:50 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 13 Nov 2006 21:56:50 -0800 Subject: Anyone Working on Packaging Labyrinth? In-Reply-To: <1163483092.3489.6.camel@tuxhugger> References: <1163483092.3489.6.camel@tuxhugger> Message-ID: <1163483810.25327.5.camel@tuxhugger> I found that Nick posted to the labyrinth-devel list about packaging this as well. I'll CC: him in case he isn't subcribed this list. Nick: Are you still interested in doing this? If so, may I email you off-list about the current work-in-progress? Thanks. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pmatilai at laiskiainen.org Tue Nov 14 07:59:52 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 14 Nov 2006 09:59:52 +0200 (EET) Subject: Tracker? In-Reply-To: <1163425119.4862.21.camel@cutter> References: <1163383054.4888.4.camel@continuity> <1163393259.9312.36.camel@cutter> <1163396656.9312.43.camel@cutter> <20061113095816.75585582@yareena.int.addix.net> <1163424084.4862.19.camel@cutter> <455872E9.5050903@city-fan.org> <1163425119.4862.21.camel@cutter> Message-ID: On Mon, 13 Nov 2006, seth vidal wrote: > On Mon, 2006-11-13 at 13:28 +0000, Paul Howarth wrote: >> seth vidal wrote: >>> On Mon, 2006-11-13 at 09:58 +0100, Ralf Ertzinger wrote: >>>> Hi. >>>> >>>> On Mon, 13 Nov 2006 00:44:16 -0500, seth vidal wrote: >>>> >>>>> If the old one is still there then it still obsoletes tracker. >>>> So if I have packages A and B, where B obsoletes A. Now there is a rpm-newer >>>> version of B (B-new) in another repo (updates) which no longer obsoletes A. >>>> >>>> So as long as B exists anywhere I can not install A using yum, because >>>> yum still considers the obsolete from B, even though it is no longer relevant >>>> in any way? >>> >>> When I was working on the obs vs updates code I kept asking about this. >>> The answer I repeatedly got was that obsoletes trumps updates no matter >>> what. >> >> Was there a reason given for this? What breaks if it's the other way around? > > mainly that an obsoleted package should stay obsoleted. If an obsoleted package need to stay obsoleted, then it's the job of the *package* to maintain the obsolete statement, not the depsolver. By including old packages in the consideration you remove the possibility of fixing packaging bugs, and cases like this where new software with the same name comes along. It's not the first time, and probably not the last one either :) - Panu - From sim at noisygecko.com Tue Nov 14 19:13:02 2006 From: sim at noisygecko.com (Sim Harbert) Date: Tue, 14 Nov 2006 19:13:02 +0000 (UTC) Subject: Orphaning zope, plone, mpc and gmpc References: Message-ID: Aurelien Bompard writes: > > Hi .*, > > I'm orphaning 4 packages. The first two will probably find a new home > quickly : zope and plone. I don't use them anymore, so I'm sure other > people will be able to give them more love. > ... > > Please step forward if you want to maintain any of these. > > Thanks > > Aur?lien I am not totally sure what it entails, but I should be able to handle Zope/Plone. Currently I am only running Core 3 and Core 5, so it may be trickier to test out things to make sure they work on Core 6. But I am guessing that isn't a big deal. What do I need to do to get activated into the system and all? -Sim From mjc at avtechpulse.com Tue Nov 14 20:06:05 2006 From: mjc at avtechpulse.com (Dr. Michael J. Chudobiak) Date: Tue, 14 Nov 2006 15:06:05 -0500 Subject: Orphaning zope, plone, mpc and gmpc In-Reply-To: References: Message-ID: <455A21AD.2010301@avtechpulse.com> Sim Harbert wrote: > I am not totally sure what it entails, but I should be able to handle > Zope/Plone. Currently I am only running Core 3 and Core 5, so it may be trickier > to test out things to make sure they work on Core 6. But I am guessing that > isn't a big deal. > > What do I need to do to get activated into the system and all? > > -Sim Sim, start here: http://fedoraproject.org/wiki/Extras/OrphanedPackages, and contact Aurelien directly (gauret at free.fr) - Mike From buildsys at fedoraproject.org Tue Nov 14 23:34:40 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 14 Nov 2006 18:34:40 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-14 Message-ID: <20061114233440.20DCF15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 49 Pound-2.1.6-2.fc7 Ri-li-2.0.0-1.fc7 abcm2ps-5.1.2-1.fc7 aumix-2.8-1.fc7 compat-libosip2-2.2.2-8.fc7 cups-pdf-2.4.2-2.fc7 dirmngr-0.9.6-2.fc7 dvdisaster-0.70.2-2.fc7 eric-3.9.2-1.fc7 espeak-1.16-4.fc7 flite-1.3-8.fc7 frozen-bubble-2.0.0-1.fc7 gauche-0.8.8-2.fc7 gauche-gl-0.4.2-1.fc7 gauche-gtk-0.4.1-9.fc7 gnomesword-2.1.9-1.fc7 gnupg2-2.0.0-3.fc7 gpsim-0.22.0-1.fc7 gtk-gnutella-0.96.3-2.fc7 gtkwave-3.0.16-1.fc7 gutenprint-5.0.0-0.16.fc7 jd-1.8.0-1.fc7 kadu-0.5.0-0.20.rc1.fc7 kaffeine-0.8.2-5.fc7 knetworkmanager-0.1-0.5.svn20061113.fc7 lib3ds-1.2.0-10.fc7 libassuan-1.0.0-1.fc7 libosip2-3.0.1-1.fc7 lilypond-2.10.0-1.fc7 listen-0.5-9.beta1.fc7.4 logserial-0.4.2-4.fc7 maxima-5.10.0-8.fc7 ochusha-0.5.99.63.3-0.2.cvs061114.fc7 perl-Moose-Policy-0.02-2.fc7 perl-WWW-Babelfish-0.15-2.fc7 perl-Wx-0.62-1.fc7 php-pear-HTML-QuickForm-3.2.7-2.fc7 php-pear-Structures-DataGrid-0.7.2-1.fc7 piklab-0.12.2-1.fc7 proftpd-1.3.0-8.fc7 puppet-0.20.1-1.fc7 qemu-0.8.2-4.fc7 rrdtool-1.2.15-6.fc7 ruby-activesupport-1.3.1-3.fc7 sbcl-0.9.18-2.fc7 spicctrl-1.9-5.fc7 stellarium-0.8.2-3.fc7 xmoto-0.2.2-2.fc7 yumex-1.2.0-1.0.fc7 Packages built and released for Fedora Extras 6: 47 Pound-2.1.6-2.fc6 abcm2ps-5.1.2-1.fc6 aumix-2.8-1.fc6 cobbler-0.3.3-1.fc6 eiciel-0.9.4-1.fc6 espeak-1.16-4.fc6 frozen-bubble-2.0.0-1.fc6 gauche-0.8.8-2.fc6 gauche-gl-0.4.2-1.fc6.1 gauche-gtk-0.4.1-9.fc6 gpsim-0.22.0-1.fc6 gtk-gnutella-0.96.3-2.fc6 gtkwave-3.0.16-1.fc6 gutenprint-5.0.0-0.16.fc6 jd-1.8.0-1.fc6 kadu-0.5.0-0.17.rc1.fc6 knetworkmanager-0.1-0.5.svn20061113.fc6 libassuan-1.0.0-1.fc6 lilypond-2.10.0-1.fc6 listen-0.5-9.beta1.fc6.4 manedit-0.7.1-5.fc6 maxima-5.10.0-8.fc6 muine-0.8.6-1.fc6 pachi-1.0-1.fc6 panelfm-1.1-2.fc6 perl-Moose-Policy-0.02-2.fc6 perl-Perl-Critic-0.21-1.fc6 perl-Set-Scalar-1.20-1.fc6 perl-Test-Perl-Critic-0.08-1.fc6 perl-WWW-Babelfish-0.15-2.fc6 php-pear-HTML-Common-1.2.3-2.fc6 php-pear-HTML-Table-1.7.5-1.fc6 php-pear-Net-DIME-0.3-1.fc6.1 piklab-0.12.2-1.fc6 puppet-0.20.1-1.fc6 qemu-0.8.2-4.fc6 rrdtool-1.2.15-6.fc6 sbcl-0.9.18-2.fc6 spicctrl-1.9-5.fc6 ssmtp-2.61-8.fc6 stellarium-0.8.2-3.fc6 torcs-1.3.0-1.fc6 vdr-osdteletext-0.5.1-26.fc6 vdr-subtitles-0.4.0-6.fc6 xfce4-dict-plugin-0.2.0-2.fc6 xfce4-eyes-plugin-4.3.99.1-2.fc6 xmoto-0.2.2-2.fc6 Packages built and released for Fedora Extras 5: 40 Pound-2.1.6-2.fc5 abcm2ps-5.1.2-1.fc5 aumix-2.8-1.fc5 cobbler-0.3.3-1.fc5 eiciel-0.9.4-1.fc5 espeak-1.16-4.fc5 frozen-bubble-2.0.0-1.fc5 gauche-0.8.8-2.fc5 gauche-gl-0.4.2-1.fc5 gauche-gtk-0.4.1-9.fc5 gpsim-0.22.0-1.fc5 gtk-gnutella-0.96.3-2.fc5 gtkwave-3.0.16-1.fc5 jd-1.8.0-1.fc5 kadu-0.5.0-0.12.rc1.fc5 listen-0.5-9.beta1.fc5.4 manedit-0.7.1-5.fc5 maxima-5.10.0-8.fc5 muine-0.8.6-1.fc5 pachi-1.0-1.fc5 panelfm-1.1-2.fc5 perl-Moose-Policy-0.02-2.fc5 perl-Perl-Critic-0.21-1.fc5 perl-Set-Scalar-1.20-1.fc5 perl-Test-Perl-Critic-0.08-1.fc5 perl-WWW-Babelfish-0.15-2.fc5 php-pear-HTML-Common-1.2.3-2.fc5 php-pear-HTML-Table-1.7.5-1.fc5 php-pear-Net-DIME-0.3-1.fc5 piklab-0.12.2-1.1.fc5 puppet-0.20.1-1.fc5 qemu-0.8.2-4.fc5 rrdtool-1.2.15-6.fc5 sbcl-0.9.18-2.fc5 ssmtp-2.61-8.fc5 stellarium-0.8.2-3.fc5 torcs-1.3.0-1.fc5 vdr-osdteletext-0.5.1-26.fc5 vdr-subtitles-0.4.0-6.fc5 xmoto-0.2.2-2.fc5 Packages built and released for Fedora Extras 4: 2 gpsim-0.22.0-1.fc4 gtkwave-3.0.16-1.fc4 Packages built and released for Fedora Extras 3: 1 gpsim-0.22.0-1.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed Nov 15 00:48:13 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 15 Nov 2006 00:48:13 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-14 Message-ID: <20061115004813.7173.29493@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 (14 days) centericq - 4.21.0-8.fc6.ppc (14 days) centericq - 4.21.0-8.fc6.x86_64 (14 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (17 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (17 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (17 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (17 days) orange - 0.3-3.cvs20051118.fc6.i386 (21 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (45 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (45 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (45 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (60 days) plague - 0.4.4.1-2.fc3.noarch (60 days) plague - 0.4.4.1-2.fc4.noarch (60 days) plague - 0.4.4.1-2.fc4.noarch (60 days) plague - 0.4.4.1-2.fc4.noarch (60 days) giallu AT gmail.com kmod-sysprof - 1.0.5-1.2.6.18_1.2798.fc6.i586 kmod-sysprof - 1.0.5-1.2.6.18_1.2798.fc6.i686 kmod-sysprof - 1.0.5-1.2.6.18_1.2798.fc6.x86_64 kmod-sysprof-PAE - 1.0.5-1.2.6.18_1.2798.fc6.i686 kmod-sysprof-kdump - 1.0.5-1.2.6.18_1.2798.fc6.i686 kmod-sysprof-kdump - 1.0.5-1.2.6.18_1.2798.fc6.x86_64 kmod-sysprof-xen - 1.0.5-1.2.6.18_1.2798.fc6.i686 kmod-sysprof-xen - 1.0.5-1.2.6.18_1.2798.fc6.x86_64 jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (36 days) linphone - 1.2.0-4.fc5.ppc (36 days) linphone - 1.2.0-4.fc5.x86_64 (36 days) oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (26 days) syck-php - 0.55-9.fc5.ppc (26 days) syck-php - 0.55-9.fc5.x86_64 (26 days) petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 (5 days) ghc-gtk2hs - 0.9.10-4.fc6.i386 (5 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (5 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (5 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (5 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (5 days) ghc642-gtk2hs - 0.9.10-4.fc6.i386 (11 days) ghc642-gtk2hs - 0.9.10-4.fc6.ppc (11 days) ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 (11 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 (11 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc (11 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 (11 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (16 days) triad AT df.lth.se gnome-phone-manager - 0.8-4.fc7.i386 gnome-phone-manager - 0.8-4.fc7.ppc gnome-phone-manager - 0.8-4.fc7.x86_64 Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 gnome-phone-manager-0.8-4.fc7.ppc requires libbtctl.so.2 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 gnome-phone-manager-0.8-4.fc7.x86_64 requires libbtctl.so.2()(64bit) kmod-sysprof-1.0.5-1.2.6.18_1.2798.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2798.fc6 kmod-sysprof-kdump-1.0.5-1.2.6.18_1.2798.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2798.fc6kdump kmod-sysprof-xen-1.0.5-1.2.6.18_1.2798.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2798.fc6xen libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 gnome-phone-manager-0.8-4.fc7.i386 requires libbtctl.so.2 kmod-sysprof-1.0.5-1.2.6.18_1.2798.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2798.fc6 kmod-sysprof-1.0.5-1.2.6.18_1.2798.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2798.fc6 kmod-sysprof-PAE-1.0.5-1.2.6.18_1.2798.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2798.fc6PAE kmod-sysprof-kdump-1.0.5-1.2.6.18_1.2798.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2798.fc6kdump kmod-sysprof-xen-1.0.5-1.2.6.18_1.2798.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2798.fc6xen libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: centericq - 4.21.0-8.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: centericq - 4.21.0-8.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: centericq - 4.21.0-8.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: triad AT df.lth.se package: gnome-phone-manager - 0.8-4.fc7.ppc from fedora-extras-development-ppc unresolved deps: libbtctl.so.2 package: gnome-phone-manager - 0.8-4.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libbtctl.so.2()(64bit) package: gnome-phone-manager - 0.8-4.fc7.i386 from fedora-extras-development-i386 unresolved deps: libbtctl.so.2 From lostson at lostsonsvault.org Wed Nov 15 01:42:08 2006 From: lostson at lostsonsvault.org (lostson) Date: Tue, 14 Nov 2006 19:42:08 -0600 Subject: Orphaning zope, plone, mpc and gmpc In-Reply-To: References: Message-ID: <1163554928.14851.1.camel@localhost.localdomain> On Tue, 2006-11-14 at 19:13 +0000, Sim Harbert wrote: > Aurelien Bompard writes: > > > > > Hi .*, > > > > I'm orphaning 4 packages. The first two will probably find a new home > > quickly : zope and plone. I don't use them anymore, so I'm sure other > > people will be able to give them more love. > > ... > > > > Please step forward if you want to maintain any of these. > > > > Thanks > > > > Aur?lien > > I am not totally sure what it entails, but I should be able to handle > Zope/Plone. Currently I am only running Core 3 and Core 5, so it may be trickier > to test out things to make sure they work on Core 6. But I am guessing that > isn't a big deal. > > What do I need to do to get activated into the system and all? > > -Sim > Did anyone pick up mpc and gmpc ?? LostSon From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Nov 15 10:18:12 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 15 Nov 2006 11:18:12 +0100 Subject: Orphaning udftools Message-ID: <20061115111812.5fc921a6@python3.es.egwn.lan> Hi, The udftools package seems to have been broken for a while : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168111 I'm not interested in maintaining a package from a dead upstream project (last release is from 2004 and open bugs have been piling up ever since), so I would like to offer it to someone else, or if no one is interested... have it removed entirely from Extras for now. Project page : http://sourceforge.net/projects/linux-udf/ Possible start point to get it back into shape : http://packages.debian.org/testing/source/udftools (as you can see, the Debian patch is larger than the original sources...) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.18-1.2835.fc6 Load : 0.37 0.32 0.31 From rdieter at math.unl.edu Thu Nov 16 05:11:43 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 15 Nov 2006 23:11:43 -0600 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-14 In-Reply-To: <20061115004813.7173.29493@extras64.linux.duke.edu> References: <20061115004813.7173.29493@extras64.linux.duke.edu> Message-ID: <455BF30F.8040603@math.unl.edu> Fedora Extras repoclosure wrote: > Summary of broken packages (by owner): > ---------------------------------------------------------------------- > rdieter AT math.unl.edu > gift - 0.11.8.1-6.fc7.i386 (16 days) > Broken packages in fedora-extras-development-x86_64: > ---------------------------------------------------------------------- > gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 FYI, waiting on file-devel RFE: http://bugzilla.redhat.com/214992 -- Rex From rc040203 at freenet.de Thu Nov 16 07:11:39 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 16 Nov 2006 08:11:39 +0100 Subject: rpms/mlton/FC-6 .cvsignore, 1.2, 1.3 mlton-debuginfo.patch, 1.1, 1.2 mlton.spec, 1.3, 1.4 sources, 1.2, 1.3 In-Reply-To: <200611160626.kAG6QjIT018186@cvs-int.fedora.redhat.com> References: <200611160626.kAG6QjIT018186@cvs-int.fedora.redhat.com> Message-ID: <1163661100.7059.10.camel@mccallum.corsepiu.local> On Wed, 2006-11-15 at 23:26 -0700, Adam Goode wrote: > Author: agoode > > Update of /cvs/extras/rpms/mlton/FC-6 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv18161 > +--- mlton-20061107~/bytecode/Makefile 2006-05-13 17:11:02.000000000 -0400 > ++++ mlton-20061107/bytecode/Makefile 2006-11-14 23:18:42.000000000 -0500 > @@ -10,7 +10,7 @@ > all: interpret.o interpret-gdb.o print-opcodes > > CC = gcc -std=gnu99 > -CFLAGS = -fomit-frame-pointer -I../runtime -I../include -Wall > +CFLAGS = -fomit-frame-pointer -g -I../runtime -I../include -Wall Could you elaborate this? This doesn't seem right to me. Why don't you propagate RPM_OPT_FLAGS into this Makefile? Ralf From jamatos at fc.up.pt Thu Nov 16 10:27:32 2006 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Thu, 16 Nov 2006 10:27:32 +0000 Subject: Orphaning three packages officially In-Reply-To: <1163017817.4615.24.camel@shalil.farsiweb.info> References: <1163017817.4615.24.camel@shalil.farsiweb.info> Message-ID: <200611161027.33009.jamatos@fc.up.pt> On Wednesday 08 November 2006 8:30 pm, Roozbeh Pournader wrote: > Also, if anyone wants to take maintainership of t1lib and t1utils > (Jos??) please feel free. I don't use these much and would appreciate > someone more familiar with them to take care of them. I will do it. > Roozbeh PS: I will also take a look into ttf2pt1. Is this one of the projects where you says that is silent upstream? -- Jos? Ab?lio From pertusus at free.fr Thu Nov 16 11:53:47 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 16 Nov 2006 12:53:47 +0100 Subject: R modules packaging? Message-ID: <20061116115347.GA2784@free.fr> Hello, I have proposed a spectemplate file for rpmdevtools here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215927 I'd like to use some R packages, but I haven't used R before, so maybe it would be better if other packagers took them. I am interested in mFilter and dependencies: mFilter tseries pastecs locfit tseriesChaos RTisean tsDyn forecast Anybody willing to maintain some of them in extras? -- Pat From jamatos at fc.up.pt Thu Nov 16 12:05:34 2006 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Thu, 16 Nov 2006 12:05:34 +0000 Subject: R modules packaging? In-Reply-To: <20061116115347.GA2784@free.fr> References: <20061116115347.GA2784@free.fr> Message-ID: <200611161205.34226.jamatos@fc.up.pt> On Thursday 16 November 2006 11:53 am, Patrice Dumas wrote: > Hello, > > I have proposed a spectemplate file for rpmdevtools here: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215927 > > I'd like to use some R packages, but I haven't used R before, so maybe > it would be better if other packagers took them. I am interested in mFilter > and dependencies: I wrote a script to create a srpm from an R package: http://www.fc.up.pt/pessoas/jamatos/R/cran2rpmspec > mFilter tseries pastecs locfit tseriesChaos RTisean tsDyn forecast > > Anybody willing to maintain some of them in extras? I have some of them in my to do list. > -- > Pat -- Jos? Ab?lio From buildsys at fedoraproject.org Thu Nov 16 17:51:10 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 16 Nov 2006 12:51:10 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-16 Message-ID: <20061116175110.8F4B315212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 29 amavisd-new-2.4.3-4.fc7 anjuta-2.0.2-11.fc7 beryl-core-0.1.2-4.fc7 beryl-manager-0.1.2-2.fc7 beryl-plugins-0.1.2-2.fc7 beryl-settings-0.1.2-2.fc7 brasero-0.5.1-1.fc7 compat-libosip2-2.2.2-9.fc7 dar-2.3.1-4.fc7 emerald-0.1.2-3.fc7 emerald-themes-0.1.2-2.fc7 gcin-1.2.9-1.fc7 grads-1.9b4-19.fc7 libeXosip2-3.0.1-1.fc7 mlton-20061107-1.fc7 ncview-1.92e-10.fc7 perl-Module-Build-0.2805-3.fc7 php-pear-SOAP-0.9.4-1.fc7 php-pear-Structures-DataGrid-Renderer-Pager-0.1.0-1.fc7 php-pear-Structures-DataGrid-Renderer-Smarty-0.1.2-1.fc7 phpMyAdmin-2.9.1-3alpha.fc7 proftpd-1.3.0-9.fc7 python-musicbrainz2-0.4.0-1.fc7 qt4-4.2.1-3.fc7 rosegarden4-1.4.0-1.fc7 smb4k-0.7.4-1.fc7 w3c-markup-validator-0.7.4-1.fc7 wcstools-3.6.6-1.fc7 wine-0.9.25-1.fc7 Packages built and released for Fedora Extras 6: 22 amavisd-new-2.4.3-4.fc6 anjuta-2.0.2-11.fc6 beryl-core-0.1.2-4.fc6 brasero-0.5.1-1.fc6 compat-libosip2-2.2.2-9.fc6 cups-pdf-2.4.2-2.fc6 flite-1.3-8.fc6 gcin-1.2.9-1.fc6 gtk2hs-0.9.10.2-0.1.fc6 kaffeine-0.8.2-5.fc6 libeXosip2-3.0.1-1.fc6 libosip2-3.0.1-1.fc6 mlton-20061107-1.fc6 ncview-1.92e-10.fc6 php-pear-Structures-DataGrid-0.7.2-1.fc6 phpMyAdmin-2.9.1-3alpha.fc6 python-musicbrainz2-0.4.0-1.fc6 rosegarden4-1.4.0-1.fc6 smb4k-0.7.4-1.fc6 w3c-markup-validator-0.7.4-1.fc6 wcstools-3.6.6-1.fc6 wine-0.9.25-1.fc6 Packages built and released for Fedora Extras 5: 14 amavisd-new-2.4.3-4.fc5 compat-libosip2-2.2.2-9.fc5 cups-pdf-2.4.2-2.fc5 flite-1.3-8.fc5 gcin-1.2.9-1.fc5 kaffeine-0.8.2-5.fc5 libeXosip2-3.0.1-1.fc5 libosip2-3.0.1-1.fc5 ncview-1.92e-10.fc5 php-pear-Structures-DataGrid-0.7.2-1.fc5 phpMyAdmin-2.9.1-3alpha.fc5 smb4k-0.7.4-1.fc5 uuid-1.5.1-2.fc5 wcstools-3.6.6-1.fc5 Packages built and released for Fedora Extras 4: 2 gcin-1.2.9-1.fc4 uuid-1.5.1-2.fc4 Packages built and released for Fedora Extras 3: 1 gcin-1.2.9-2.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From paul at city-fan.org Thu Nov 16 18:33:52 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 16 Nov 2006 18:33:52 +0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-14 In-Reply-To: <20061115004813.7173.29493@extras64.linux.duke.edu> References: <20061115004813.7173.29493@extras64.linux.duke.edu> Message-ID: <1163702032.19188.3.camel@metropolis.intra.city-fan.org> On Wed, 2006-11-15 at 00:48 +0000, Fedora Extras repoclosure wrote: > Summary of broken packages (by owner): I think it would be a good idea for this report, like the "Package EVR Problems" report, to include FC+updates and be posted to fedora-maintainers. That way, it would pick up the broken deps in the i386 FC6 updates packages in the x86_64 repo of bind-devel (mentioned in #214208) and kdeedu (#215970). Paul. From buildsys at fedoraproject.org Thu Nov 16 19:02:59 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 16 Nov 2006 19:02:59 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-16 Message-ID: <20061116190259.23674.5869@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 (16 days) centericq - 4.21.0-8.fc6.ppc (16 days) centericq - 4.21.0-8.fc6.x86_64 (16 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (19 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (19 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (19 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (19 days) orange - 0.3-3.cvs20051118.fc6.i386 (23 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (47 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (47 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (47 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (62 days) plague - 0.4.4.1-2.fc3.noarch (62 days) plague - 0.4.4.1-2.fc4.noarch (62 days) plague - 0.4.4.1-2.fc4.noarch (62 days) plague - 0.4.4.1-2.fc4.noarch (62 days) giallu AT gmail.com kmod-sysprof - 1.0.5-1.2.6.18_1.2798.fc6.i586 (3 days) kmod-sysprof - 1.0.5-1.2.6.18_1.2798.fc6.i686 (3 days) kmod-sysprof - 1.0.5-1.2.6.18_1.2798.fc6.x86_64 (3 days) kmod-sysprof-PAE - 1.0.5-1.2.6.18_1.2798.fc6.i686 (3 days) kmod-sysprof-kdump - 1.0.5-1.2.6.18_1.2798.fc6.i686 (3 days) kmod-sysprof-kdump - 1.0.5-1.2.6.18_1.2798.fc6.x86_64 (3 days) kmod-sysprof-xen - 1.0.5-1.2.6.18_1.2798.fc6.i686 (3 days) kmod-sysprof-xen - 1.0.5-1.2.6.18_1.2798.fc6.x86_64 (3 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (38 days) linphone - 1.2.0-4.fc5.ppc (38 days) linphone - 1.2.0-4.fc5.x86_64 (38 days) jwilson AT redhat.com beryl - 0.1.2-4.fc6.i386 beryl - 0.1.2-4.fc6.ppc beryl - 0.1.2-4.fc6.x86_64 beryl - 0.1.2-4.fc7.i386 beryl - 0.1.2-4.fc7.ppc beryl - 0.1.2-4.fc7.x86_64 beryl-gnome - 0.1.2-4.fc6.i386 beryl-gnome - 0.1.2-4.fc6.ppc beryl-gnome - 0.1.2-4.fc6.x86_64 beryl-gnome - 0.1.2-4.fc7.i386 beryl-gnome - 0.1.2-4.fc7.ppc beryl-gnome - 0.1.2-4.fc7.x86_64 beryl-kde - 0.1.2-4.fc6.i386 beryl-kde - 0.1.2-4.fc6.ppc beryl-kde - 0.1.2-4.fc6.x86_64 beryl-kde - 0.1.2-4.fc7.i386 beryl-kde - 0.1.2-4.fc7.ppc beryl-kde - 0.1.2-4.fc7.x86_64 matthias AT rpmforge.net php-eaccelerator - 5.1.6_0.9.5-2.fc7.i386 php-eaccelerator - 5.1.6_0.9.5-2.fc7.ppc php-eaccelerator - 5.1.6_0.9.5-2.fc7.x86_64 oliver AT linux-kernel.at syck-php - 0.55-10.fc6.i386 syck-php - 0.55-10.fc6.ppc syck-php - 0.55-10.fc6.x86_64 syck-php - 0.55-9.fc5.i386 (28 days) syck-php - 0.55-9.fc5.ppc (28 days) syck-php - 0.55-9.fc5.x86_64 (28 days) pertusus AT free.fr grads - 1.9b4-19.fc7.i386 grads - 1.9b4-19.fc7.ppc grads - 1.9b4-19.fc7.x86_64 petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 (13 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (13 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (13 days) ghc642-gtk2hs - 0.9.10-4.fc6.i386 (13 days) ghc642-gtk2hs - 0.9.10-4.fc6.ppc (13 days) ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 (13 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 (13 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc (13 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 (13 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (18 days) triad AT df.lth.se gnome-phone-manager - 0.8-4.fc7.i386 (2 days) gnome-phone-manager - 0.8-4.fc7.ppc (2 days) gnome-phone-manager - 0.8-4.fc7.x86_64 (2 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- beryl-0.1.2-4.fc7.ppc requires bdock >= 0:0.1.2 beryl-gnome-0.1.2-4.fc7.ppc requires heliodor >= 0:0.1.2 beryl-gnome-0.1.2-4.fc7.ppc requires beryl-vidcap >= 0:0.1.2 beryl-gnome-0.1.2-4.fc7.ppc requires beryl-dbus >= 0:0.1.2 beryl-kde-0.1.2-4.fc7.ppc requires beryl-vidcap >= 0:0.1.2 beryl-kde-0.1.2-4.fc7.ppc requires aquamarine >= 0:0.1.2 centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 gnome-phone-manager-0.8-4.fc7.ppc requires libbtctl.so.2 grads-1.9b4-19.fc7.ppc requires wgrib libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 php-eaccelerator-5.1.6_0.9.5-2.fc7.ppc requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.ppc requires php = 0:5.1.6 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- beryl-0.1.2-4.fc7.x86_64 requires bdock >= 0:0.1.2 beryl-gnome-0.1.2-4.fc7.x86_64 requires heliodor >= 0:0.1.2 beryl-gnome-0.1.2-4.fc7.x86_64 requires beryl-vidcap >= 0:0.1.2 beryl-gnome-0.1.2-4.fc7.x86_64 requires beryl-dbus >= 0:0.1.2 beryl-kde-0.1.2-4.fc7.x86_64 requires beryl-vidcap >= 0:0.1.2 beryl-kde-0.1.2-4.fc7.x86_64 requires aquamarine >= 0:0.1.2 centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 gnome-phone-manager-0.8-4.fc7.x86_64 requires libbtctl.so.2()(64bit) grads-1.9b4-19.fc7.x86_64 requires wgrib kmod-sysprof-1.0.5-1.2.6.18_1.2798.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2798.fc6 kmod-sysprof-kdump-1.0.5-1.2.6.18_1.2798.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2798.fc6kdump kmod-sysprof-xen-1.0.5-1.2.6.18_1.2798.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2798.fc6xen libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 php-eaccelerator-5.1.6_0.9.5-2.fc7.x86_64 requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.x86_64 requires php = 0:5.1.6 Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- beryl-0.1.2-4.fc7.i386 requires bdock >= 0:0.1.2 beryl-gnome-0.1.2-4.fc7.i386 requires heliodor >= 0:0.1.2 beryl-gnome-0.1.2-4.fc7.i386 requires beryl-vidcap >= 0:0.1.2 beryl-gnome-0.1.2-4.fc7.i386 requires beryl-dbus >= 0:0.1.2 beryl-kde-0.1.2-4.fc7.i386 requires beryl-vidcap >= 0:0.1.2 beryl-kde-0.1.2-4.fc7.i386 requires aquamarine >= 0:0.1.2 centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 gnome-phone-manager-0.8-4.fc7.i386 requires libbtctl.so.2 grads-1.9b4-19.fc7.i386 requires wgrib kmod-sysprof-1.0.5-1.2.6.18_1.2798.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2798.fc6 kmod-sysprof-1.0.5-1.2.6.18_1.2798.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2798.fc6 kmod-sysprof-PAE-1.0.5-1.2.6.18_1.2798.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2798.fc6PAE kmod-sysprof-kdump-1.0.5-1.2.6.18_1.2798.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2798.fc6kdump kmod-sysprof-xen-1.0.5-1.2.6.18_1.2798.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2798.fc6xen libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 php-eaccelerator-5.1.6_0.9.5-2.fc7.i386 requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.i386 requires php = 0:5.1.6 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- beryl-0.1.2-4.fc6.ppc requires bdock >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.ppc requires beryl-plugins >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.ppc requires beryl-manager >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.ppc requires heliodor >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.ppc requires beryl-settings >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.ppc requires beryl-vidcap >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.ppc requires beryl-dbus >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.ppc requires emerald-themes >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.ppc requires emerald >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.ppc requires beryl-plugins >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.ppc requires beryl-manager >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.ppc requires beryl-settings >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.ppc requires beryl-vidcap >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.ppc requires emerald-themes >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.ppc requires aquamarine >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.ppc requires emerald >= 0:0.1.2 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- beryl-0.1.2-4.fc6.x86_64 requires bdock >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.x86_64 requires beryl-plugins >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.x86_64 requires beryl-manager >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.x86_64 requires heliodor >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.x86_64 requires beryl-settings >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.x86_64 requires beryl-vidcap >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.x86_64 requires beryl-dbus >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.x86_64 requires emerald-themes >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.x86_64 requires emerald >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.x86_64 requires beryl-plugins >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.x86_64 requires beryl-manager >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.x86_64 requires beryl-settings >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.x86_64 requires beryl-vidcap >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.x86_64 requires emerald-themes >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.x86_64 requires aquamarine >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.x86_64 requires emerald >= 0:0.1.2 Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- beryl-0.1.2-4.fc6.i386 requires bdock >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.i386 requires beryl-plugins >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.i386 requires beryl-manager >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.i386 requires heliodor >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.i386 requires beryl-settings >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.i386 requires beryl-vidcap >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.i386 requires beryl-dbus >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.i386 requires emerald-themes >= 0:0.1.2 beryl-gnome-0.1.2-4.fc6.i386 requires emerald >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.i386 requires beryl-plugins >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.i386 requires beryl-manager >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.i386 requires beryl-settings >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.i386 requires beryl-vidcap >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.i386 requires emerald-themes >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.i386 requires aquamarine >= 0:0.1.2 beryl-kde-0.1.2-4.fc6.i386 requires emerald >= 0:0.1.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: jwilson AT redhat.com package: beryl-gnome - 0.1.2-4.fc7.ppc from fedora-extras-development-ppc unresolved deps: heliodor >= 0:0.1.2 beryl-vidcap >= 0:0.1.2 beryl-dbus >= 0:0.1.2 package: beryl - 0.1.2-4.fc7.ppc from fedora-extras-development-ppc unresolved deps: bdock >= 0:0.1.2 package: beryl-kde - 0.1.2-4.fc7.ppc from fedora-extras-development-ppc unresolved deps: beryl-vidcap >= 0:0.1.2 aquamarine >= 0:0.1.2 package: beryl - 0.1.2-4.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: bdock >= 0:0.1.2 package: beryl-kde - 0.1.2-4.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: beryl-vidcap >= 0:0.1.2 aquamarine >= 0:0.1.2 package: beryl-gnome - 0.1.2-4.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: heliodor >= 0:0.1.2 beryl-vidcap >= 0:0.1.2 beryl-dbus >= 0:0.1.2 package: beryl-kde - 0.1.2-4.fc7.i386 from fedora-extras-development-i386 unresolved deps: beryl-vidcap >= 0:0.1.2 aquamarine >= 0:0.1.2 package: beryl - 0.1.2-4.fc7.i386 from fedora-extras-development-i386 unresolved deps: bdock >= 0:0.1.2 package: beryl-gnome - 0.1.2-4.fc7.i386 from fedora-extras-development-i386 unresolved deps: heliodor >= 0:0.1.2 beryl-vidcap >= 0:0.1.2 beryl-dbus >= 0:0.1.2 package: beryl-gnome - 0.1.2-4.fc6.ppc from fedora-extras-6-ppc unresolved deps: beryl-plugins >= 0:0.1.2 beryl-manager >= 0:0.1.2 heliodor >= 0:0.1.2 beryl-settings >= 0:0.1.2 beryl-vidcap >= 0:0.1.2 beryl-dbus >= 0:0.1.2 emerald-themes >= 0:0.1.2 emerald >= 0:0.1.2 package: beryl - 0.1.2-4.fc6.ppc from fedora-extras-6-ppc unresolved deps: bdock >= 0:0.1.2 package: beryl-kde - 0.1.2-4.fc6.ppc from fedora-extras-6-ppc unresolved deps: beryl-plugins >= 0:0.1.2 beryl-manager >= 0:0.1.2 beryl-settings >= 0:0.1.2 beryl-vidcap >= 0:0.1.2 emerald-themes >= 0:0.1.2 aquamarine >= 0:0.1.2 emerald >= 0:0.1.2 package: beryl - 0.1.2-4.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: bdock >= 0:0.1.2 package: beryl-gnome - 0.1.2-4.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: beryl-plugins >= 0:0.1.2 beryl-manager >= 0:0.1.2 heliodor >= 0:0.1.2 beryl-settings >= 0:0.1.2 beryl-vidcap >= 0:0.1.2 beryl-dbus >= 0:0.1.2 emerald-themes >= 0:0.1.2 emerald >= 0:0.1.2 package: beryl-kde - 0.1.2-4.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: beryl-plugins >= 0:0.1.2 beryl-manager >= 0:0.1.2 beryl-settings >= 0:0.1.2 beryl-vidcap >= 0:0.1.2 emerald-themes >= 0:0.1.2 aquamarine >= 0:0.1.2 emerald >= 0:0.1.2 package: beryl-kde - 0.1.2-4.fc6.i386 from fedora-extras-6-i386 unresolved deps: beryl-plugins >= 0:0.1.2 beryl-manager >= 0:0.1.2 beryl-settings >= 0:0.1.2 beryl-vidcap >= 0:0.1.2 emerald-themes >= 0:0.1.2 aquamarine >= 0:0.1.2 emerald >= 0:0.1.2 package: beryl-gnome - 0.1.2-4.fc6.i386 from fedora-extras-6-i386 unresolved deps: beryl-plugins >= 0:0.1.2 beryl-manager >= 0:0.1.2 heliodor >= 0:0.1.2 beryl-settings >= 0:0.1.2 beryl-vidcap >= 0:0.1.2 beryl-dbus >= 0:0.1.2 emerald-themes >= 0:0.1.2 emerald >= 0:0.1.2 package: beryl - 0.1.2-4.fc6.i386 from fedora-extras-6-i386 unresolved deps: bdock >= 0:0.1.2 ====================================================================== New report for: oliver AT linux-kernel.at package: syck-php - 0.55-10.fc6.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.6 package: syck-php - 0.55-10.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.6 package: syck-php - 0.55-10.fc6.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.6 ====================================================================== New report for: pertusus AT free.fr package: grads - 1.9b4-19.fc7.ppc from fedora-extras-development-ppc unresolved deps: wgrib package: grads - 1.9b4-19.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: wgrib package: grads - 1.9b4-19.fc7.i386 from fedora-extras-development-i386 unresolved deps: wgrib ====================================================================== New report for: matthias AT rpmforge.net package: php-eaccelerator - 5.1.6_0.9.5-2.fc7.ppc from fedora-extras-development-ppc unresolved deps: php-common = 0:5.1.6 package: php-eaccelerator - 5.1.6_0.9.5-2.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: php-common = 0:5.1.6 package: php-eaccelerator - 5.1.6_0.9.5-2.fc7.i386 from fedora-extras-development-i386 unresolved deps: php-common = 0:5.1.6 From bugs.michael at gmx.net Thu Nov 16 19:43:11 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 16 Nov 2006 20:43:11 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-14 In-Reply-To: <1163702032.19188.3.camel@metropolis.intra.city-fan.org> References: <20061115004813.7173.29493@extras64.linux.duke.edu> <1163702032.19188.3.camel@metropolis.intra.city-fan.org> Message-ID: <20061116204311.96881e29.bugs.michael@gmx.net> On Thu, 16 Nov 2006 18:33:52 +0000, Paul Howarth wrote: > On Wed, 2006-11-15 at 00:48 +0000, Fedora Extras repoclosure wrote: > > Summary of broken packages (by owner): > > I think it would be a good idea for this report, like the "Package EVR > Problems" report, to include FC+updates and be posted to > fedora-maintainers. That way, it would pick up the broken deps in the > i386 FC6 updates packages in the x86_64 repo of bind-devel (mentioned in > #214208) and kdeedu (#215970). It detects _all_ broken deps in Core + Extras, but doesn't report anything for Core, since I believe there is an internal report already. [...] source rpm: kdeutils-3.5.5-0.1.fc6.src.rpm package: kdeutils-devel - 6:3.5.5-0.1.fc6.i386 from fedora-core-updates-6-x86_64 unresolved deps: libkmilo.so.1 libkregexpeditorcommon.so.1 libksimcore.so.1 libkhexeditcommon.so.0 libkcmlaptop.so.0 source rpm: kdeedu-3.5.5-0.1.fc6.src.rpm package: kdeedu - 3.5.5-0.1.fc6.i386 from fedora-core-updates-6-x86_64 unresolved deps: libpython2.4.so.1.0 source rpm: bind-9.3.3-6.fc6.src.rpm package: bind-devel - 30:9.3.3-6.fc6.i386 from fedora-core-updates-6-x86_64 unresolved deps: libdns.so.22 libisc.so.11 libisccc.so.0 liblwres.so.9 libisccfg.so.1 libbind9.so.0 From j.w.r.degoede at hhs.nl Thu Nov 16 20:14:32 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 16 Nov 2006 21:14:32 +0100 Subject: Progress reports of my students fixing bugs Message-ID: <455CC6A8.5060400@hhs.nl> Hi all, About a week ago I announced I wanted some relatively easy to fix bugs to use in a lab lesson for students to teach them / let them practice with systematical fault searching. Many thanks to those who posted bugs, although I did find the response a bit lacking. Since I want to continue with these lessons next week and need a few new bug here is a progress report on the bugs which I gave to my students: --- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206873 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206874 Problem found and fix-patch attached to bug --- http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214745 Really 2 bugs, first ImageMagick creates a corrupt .ico and then it crashes reading it, debugging the crash reading it is in progress and I expect the students to come up with a fix next week. --- | -- CMakeLists.txt -- | include(foo.cmake) | foo() | | -- foo.cmake -- | macro(foo) | message(SEND_ERROR "foo") | endmacro(foo) | | $ cmake CMakeLists.txt | ... | Segmentation fault (core dumped) In progress, the segfault happens because the code tries to access element 0 / [0] of an empty STL vector, why its empty is not clear though. --- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213212 This is really many bugs with mc ftpfs after the ipv6 support patch, my students have pinpointed the problems with passive ipv4 connections and also have figured out how to fix it, I expect them to write a fix for the passive problem this wednesday. --- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203336 Torcs segfaults after a short while when using "openal" for the sound, but not when using "plib". I just tried in 1.3.0 and there is still the same problem... either it's in torcs itself (which BTW exits when /dev/dsp is busy, not very user friendly!) or in openal, dunno. My Students failed to reproduce this on FC-6 and have requested the reporter to try to see if he can reproduce it. --- So as you can see my students are doing good work, and I / they need more relatively easy bugs to keep up there good work! So please send me more bugs. I need bugs (do I?) :) Regards, Hans From mjc at avtechpulse.com Thu Nov 16 20:20:35 2006 From: mjc at avtechpulse.com (Dr. Michael J. Chudobiak) Date: Thu, 16 Nov 2006 15:20:35 -0500 Subject: Progress reports of my students fixing bugs In-Reply-To: <455CC6A8.5060400@hhs.nl> References: <455CC6A8.5060400@hhs.nl> Message-ID: <455CC813.6070506@avtechpulse.com> Hans de Goede wrote: > Hi all, > > About a week ago I announced I wanted some relatively easy to fix bugs > to use in a lab lesson for students to teach them / let them practice > with systematical fault searching. > > Many thanks to those who posted bugs, although I did find the response a > bit lacking. Since I want to continue with these lessons next week and > need a few new bug here is a progress report on the bugs which I gave to > my students: Try http://bugzilla.gnome.org/reports/keyword-search.cgi?keyword=gnome-love for "easy" bugs. - Mike From j.w.r.degoede at hhs.nl Thu Nov 16 20:58:34 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 16 Nov 2006 21:58:34 +0100 Subject: Progress reports of my students fixing bugs In-Reply-To: <455CC813.6070506@avtechpulse.com> References: <455CC6A8.5060400@hhs.nl> <455CC813.6070506@avtechpulse.com> Message-ID: <455CD0FA.4040302@hhs.nl> Dr. Michael J. Chudobiak wrote: > Hans de Goede wrote: >> Hi all, >> >> About a week ago I announced I wanted some relatively easy to fix bugs >> to use in a lab lesson for students to teach them / let them practice >> with systematical fault searching. >> >> Many thanks to those who posted bugs, although I did find the response a >> bit lacking. Since I want to continue with these lessons next week and >> need a few new bug here is a progress report on the bugs which I gave to >> my students: > > Try > http://bugzilla.gnome.org/reports/keyword-search.cgi?keyword=gnome-love > for "easy" bugs. > I already looked at those and those are only easy if you are deeply into gnome already and / or they are documentation bugs / change requests not code bugs which is what I'm looking for. Regards, Hans From mattdm at mattdm.org Thu Nov 16 20:56:25 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 16 Nov 2006 15:56:25 -0500 Subject: Progress reports of my students fixing bugs In-Reply-To: <455CD0FA.4040302@hhs.nl> References: <455CC6A8.5060400@hhs.nl> <455CC813.6070506@avtechpulse.com> <455CD0FA.4040302@hhs.nl> Message-ID: <20061116205625.GA26597@jadzia.bu.edu> On Thu, Nov 16, 2006 at 09:58:34PM +0100, Hans de Goede wrote: > I already looked at those and those are only easy if you are deeply into > gnome already and / or they are documentation bugs / change requests > not code bugs which is what I'm looking for. Define "easy". There's a bug in the Icebreaker game I wrote in 2001 that is probably trivial but I can't figure out. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From limb at jcomserv.net Thu Nov 16 20:58:38 2006 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 16 Nov 2006 14:58:38 -0600 (CST) Subject: Progress reports of my students fixing bugs In-Reply-To: <20061116205625.GA26597@jadzia.bu.edu> References: <455CC6A8.5060400@hhs.nl> <455CC813.6070506@avtechpulse.com> <455CD0FA.4040302@hhs.nl> <20061116205625.GA26597@jadzia.bu.edu> Message-ID: <26488.65.192.24.190.1163710718.squirrel@mail.jcomserv.net> Provide bug and source code, please. I'm curious. I'm in that sort of mindset right now, as I'm working on a reimplementation of Datastorm in NCurses. :) > On Thu, Nov 16, 2006 at 09:58:34PM +0100, Hans de Goede wrote: >> I already looked at those and those are only easy if you are deeply into >> gnome already and / or they are documentation bugs / change requests >> not code bugs which is what I'm looking for. > > Define "easy". There's a bug in the Icebreaker game I wrote in 2001 that > is > probably trivial but I can't figure out. :) > > > -- > 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 > -- novus ordo absurdum From j.w.r.degoede at hhs.nl Thu Nov 16 21:13:45 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 16 Nov 2006 22:13:45 +0100 Subject: Progress reports of my students fixing bugs In-Reply-To: <20061116205625.GA26597@jadzia.bu.edu> References: <455CC6A8.5060400@hhs.nl> <455CC813.6070506@avtechpulse.com> <455CD0FA.4040302@hhs.nl> <20061116205625.GA26597@jadzia.bu.edu> Message-ID: <455CD489.4080303@hhs.nl> Matthew Miller wrote: > On Thu, Nov 16, 2006 at 09:58:34PM +0100, Hans de Goede wrote: >> I already looked at those and those are only easy if you are deeply into >> gnome already and / or they are documentation bugs / change requests >> not code bugs which is what I'm looking for. > > Define "easy". There's a bug in the Icebreaker game I wrote in 2001 that is > probably trivial but I can't figure out. :) > > Well thats sorta hard to define, not easy is maybe easier, not easy is: -race conditions -memory corruption leading to random crashes -only reproducable on certain hardware To be easy a bug would need to be: -100% reproducable, without special means and without needing a certain timing (iow not bugs: if you do this and then continue working it will crash eventually type of bugs) If you say its probably trivial and you can describe it well and in a reproducable manner then I'm more then willing to feed it to my students :) Regards, hans From limb at jcomserv.net Thu Nov 16 21:03:24 2006 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 16 Nov 2006 15:03:24 -0600 (CST) Subject: Progress reports of my students fixing bugs In-Reply-To: <455CD489.4080303@hhs.nl> References: <455CC6A8.5060400@hhs.nl> <455CC813.6070506@avtechpulse.com> <455CD0FA.4040302@hhs.nl> <20061116205625.GA26597@jadzia.bu.edu> <455CD489.4080303@hhs.nl> Message-ID: <27009.65.192.24.190.1163711004.squirrel@mail.jcomserv.net> And I promise, if I fix it, not to tell anyone but Matthew Miller until I get the all clear, so as not to spoil the surprise. :) > > > Matthew Miller wrote: >> On Thu, Nov 16, 2006 at 09:58:34PM +0100, Hans de Goede wrote: >>> I already looked at those and those are only easy if you are deeply >>> into >>> gnome already and / or they are documentation bugs / change requests >>> not code bugs which is what I'm looking for. >> >> Define "easy". There's a bug in the Icebreaker game I wrote in 2001 that >> is >> probably trivial but I can't figure out. :) >> >> > > Well thats sorta hard to define, not easy is maybe easier, not easy is: > -race conditions > -memory corruption leading to random crashes > -only reproducable on certain hardware > > To be easy a bug would need to be: > -100% reproducable, without special means and without needing > a certain timing (iow not bugs: if you do this and then continue > working it will crash eventually type of bugs) > > If you say its probably trivial and you can describe it well and in a > reproducable manner then I'm more then willing to feed it to my students > :) > > Regards, > > hans > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- novus ordo absurdum From pertusus at free.fr Thu Nov 16 21:20:37 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 16 Nov 2006 22:20:37 +0100 Subject: R modules packaging? In-Reply-To: <20061116115347.GA2784@free.fr> References: <20061116115347.GA2784@free.fr> Message-ID: <20061116212037.GA2803@free.fr> On Thu, Nov 16, 2006 at 12:53:47PM +0100, Patrice Dumas wrote: > Hello, > > Anybody willing to maintain some of them in extras? Thanks to Jose script and a wrapper to do the download, I could package the modules, and it turned out that the R packages have a lot of interdependencies, sometimes interdependencies which seem wrong. If somebody wants to package some of them here are all those were needed (or with inter-dependencies to check): mFilter pastecs locfit tseriesChaos RTisean tsDyn odesolve chron zoo its tseries strucchange DAAG leaps oz sandwich car lmtest Ecdat e1071 mlbench randomForest SparseM xtable scatterplot3d dynlm systemfit sem fCalendar fEcofin Hmisc acepack Design tkrplot TeachingDemos maptools spatstat PBSmapping maps gpclib RArcInfo sp RColorBrewer sm deldir akima gam mapproj rgl qcc sgeostat Here is the list of the package which have inter-dependencies. the arrow points to the one the other should depend on in my opinion: mlbench <- e1071 Ecdat <- lmtest sandwich dynlm -> lmtest sandwich lmtest - sandwich sandwich <- strucchange lmtest dynlm strucchange -> zoo sandwich -> zoo zoo <- tseries PBSmapping -> maptools maps <- mapproj Hmisc <- Design There are some license issues: gpclib non free mapproj non free R-akima.spec:License: Fortran code: ACM, free for non-commercial use, R functions GPL R-e1071.spec:License: GPL-2. See COPYRIGHT.svm.cpp for the copyright of the svm C++ code. R-acepack.spec:License: avas is public domain, ace is on Statlib -- Pat From a.badger at gmail.com Thu Nov 16 22:14:35 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 16 Nov 2006 14:14:35 -0800 Subject: Subscribing to -maintainers list Message-ID: <1163715275.14029.61.camel@localhost.localdomain> Hi guys, For quite a while we've had a fedora-maintainers mailing list for everyone with at least one package in Core or Extras. This was supposed to allow us to have a low traffic list for information relevant to all packagers. When the list was first created, maintainers were automatically added and for a while some of us thought that the list of maintainers would continue to be pulled automatically from owners.list or the account system. That turns out to not be true. New maintainers have to subscribe to the list manually. In addition, since the list is for maintainers-only, a list admin needs to confirm the email address belongs to a packager and approve the subscription. So, if any of you are maintaining packages and not subscribed to that list, please sign up now. If you're trying to sign up and keep getting rejected, please let us know so one of the list admins can match email address to packager and get you subscribed. 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 mattdm at mattdm.org Thu Nov 16 23:08:40 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 16 Nov 2006 18:08:40 -0500 Subject: Progress reports of my students fixing bugs In-Reply-To: <26488.65.192.24.190.1163710718.squirrel@mail.jcomserv.net> References: <455CC6A8.5060400@hhs.nl> <455CC813.6070506@avtechpulse.com> <455CD0FA.4040302@hhs.nl> <20061116205625.GA26597@jadzia.bu.edu> <26488.65.192.24.190.1163710718.squirrel@mail.jcomserv.net> Message-ID: <20061116230840.GA31585@jadzia.bu.edu> On Thu, Nov 16, 2006 at 02:58:38PM -0600, Jon Ciesla wrote: > Provide bug and source code, please. I'm curious. Mostly, Latest code at: although there's some stuff languishing in CVS that I haven't touched for a while. The bug is: sometimes, when you complete a line, area which includes a penguin is calculated as not including one. It's probably a stupid off-by-one error or something, but I beat my head against it for a while and stopped. Caveat: this is code from several years ago and my pride in it is mixed. It was the first decent-sized C program I wrote on Linux, and I was a little intimidated, so I did some clearly odd things, like avoiding allocating dynamic memory. Plus, the code to make the whole entry screen is very kludgy and causes other kludges. :) And please don't mention how the spec file needs cleaning up. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Thu Nov 16 23:09:11 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 16 Nov 2006 18:09:11 -0500 Subject: Progress reports of my students fixing bugs In-Reply-To: <455CD489.4080303@hhs.nl> References: <455CC6A8.5060400@hhs.nl> <455CC813.6070506@avtechpulse.com> <455CD0FA.4040302@hhs.nl> <20061116205625.GA26597@jadzia.bu.edu> <455CD489.4080303@hhs.nl> Message-ID: <20061116230911.GB31585@jadzia.bu.edu> On Thu, Nov 16, 2006 at 10:13:45PM +0100, Hans de Goede wrote: > To be easy a bug would need to be: > -100% reproducable, without special means and without needing > a certain timing (iow not bugs: if you do this and then continue > working it will crash eventually type of bugs) Ah, no, that's exactly the problem with this one. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jamatos at fc.up.pt Fri Nov 17 00:12:40 2006 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Fri, 17 Nov 2006 00:12:40 +0000 Subject: R modules packaging? In-Reply-To: <20061116212037.GA2803@free.fr> References: <20061116115347.GA2784@free.fr> <20061116212037.GA2803@free.fr> Message-ID: <200611170012.40508.jamatos@fc.up.pt> On Thursday 16 November 2006 9:20 pm, Patrice Dumas wrote: > On Thu, Nov 16, 2006 at 12:53:47PM +0100, Patrice Dumas wrote: > > Hello, > > > > Anybody willing to maintain some of them in extras? > > Thanks to Jose script and a wrapper to do the download, I could package > the modules, and it turned out that the R packages have a lot of > interdependencies, sometimes interdependencies which seem wrong. I noticed that too. :-) I think that a given time I read that Scientific Linux had the R packages in rpm. Google is not friend so I have been unable to find such a reference. > If somebody wants to package some of them here are all those were > needed (or with inter-dependencies to check): > > mFilter > pastecs locfit tseriesChaos RTisean tsDyn odesolve chron zoo its > tseries strucchange DAAG leaps oz sandwich car lmtest Ecdat e1071 > mlbench randomForest SparseM xtable scatterplot3d dynlm systemfit sem > fCalendar fEcofin Hmisc acepack Design tkrplot TeachingDemos maptools > spatstat PBSmapping maps gpclib RArcInfo sp RColorBrewer sm deldir > akima gam mapproj rgl qcc sgeostat I think that I will add this dependency resolution to my script. :-) > Here is the list of the package which have inter-dependencies. the arrow > points to the one the other should depend on in my opinion: Clearly your simultaneous use of -> and <- betrays your extreme exposure to R. ;-) > mlbench <- e1071 > Ecdat <- lmtest sandwich > dynlm -> lmtest sandwich > lmtest - sandwich > sandwich <- strucchange lmtest dynlm > strucchange -> zoo > sandwich -> zoo > zoo <- tseries > PBSmapping -> maptools > maps <- mapproj > Hmisc <- Design > > There are some license issues: You are right some of the packages are plagued with some non-free licenses. > -- > Pat -- Jos? Ab?lio From adam at spicenitz.org Fri Nov 17 00:34:03 2006 From: adam at spicenitz.org (Adam Goode) Date: Thu, 16 Nov 2006 19:34:03 -0500 Subject: rpms/mlton/FC-6 .cvsignore, 1.2, 1.3 mlton-debuginfo.patch, 1.1, 1.2 mlton.spec, 1.3, 1.4 sources, 1.2, 1.3 In-Reply-To: <1163661100.7059.10.camel@mccallum.corsepiu.local> References: <200611160626.kAG6QjIT018186@cvs-int.fedora.redhat.com> <1163661100.7059.10.camel@mccallum.corsepiu.local> Message-ID: <455D037B.7090406@spicenitz.org> Ralf Corsepius wrote: > On Wed, 2006-11-15 at 23:26 -0700, Adam Goode wrote: >> Author: agoode >> >> Update of /cvs/extras/rpms/mlton/FC-6 >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv18161 > > >> +--- mlton-20061107~/bytecode/Makefile 2006-05-13 17:11:02.000000000 -0400 >> ++++ mlton-20061107/bytecode/Makefile 2006-11-14 23:18:42.000000000 -0500 >> @@ -10,7 +10,7 @@ >> all: interpret.o interpret-gdb.o print-opcodes >> >> CC = gcc -std=gnu99 >> -CFLAGS = -fomit-frame-pointer -I../runtime -I../include -Wall >> +CFLAGS = -fomit-frame-pointer -g -I../runtime -I../include -Wall > > Could you elaborate this? This doesn't seem right to me. > > Why don't you propagate RPM_OPT_FLAGS into this Makefile? > I've been thinking along these lines, but have not yet tried it. This stuff is for the MLton runtime, which might be sensitive to foreign optimization flags. (The code does garbage collection and stack manipulation since this is the runtime for Standard ML.) I'll try it and see if anything breaks! Thanks, Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From fedora at leemhuis.info Fri Nov 17 06:21:53 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 17 Nov 2006 07:21:53 +0100 Subject: Subscribing to -maintainers list In-Reply-To: <1163715275.14029.61.camel@localhost.localdomain> References: <1163715275.14029.61.camel@localhost.localdomain> Message-ID: <455D5501.5070003@leemhuis.info> Hi! Toshio, thanks for this mail. A small add-on: Toshio Kuratomi schrieb: > [...] > So, if any of you are maintaining packages and not subscribed to that > list, please sign up now. If you're trying to sign up and keep getting > rejected, please let us know so one of the list admins can match email > address to packager and get you subscribed. Please note that most of the discussions around "Merge Core and Extras" aka "Opening Core" (see http://fedoraproject.org/wiki/FedoraSummit/OpeningCore and http://wtogami.livejournal.com/11707.html for more details) will happen on fedora-maintainers-list and not on this list. Sooner or later we'll probably also merge some of the lists into to avoid confusion. CU thl From giallu at gmail.com Fri Nov 17 07:48:02 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 17 Nov 2006 08:48:02 +0100 Subject: Progress reports of my students fixing bugs In-Reply-To: <20061116230840.GA31585@jadzia.bu.edu> References: <455CC6A8.5060400@hhs.nl> <455CC813.6070506@avtechpulse.com> <455CD0FA.4040302@hhs.nl> <20061116205625.GA26597@jadzia.bu.edu> <26488.65.192.24.190.1163710718.squirrel@mail.jcomserv.net> <20061116230840.GA31585@jadzia.bu.edu> Message-ID: On 11/17/06, Matthew Miller wrote: > The bug is: sometimes, when you complete a line, area which includes a > penguin is calculated as not including one. It's probably a stupid > off-by-one error or something, but I beat my head against it for a while and > stopped. > I'm sure you already tried this but, just in case: I found mudflap a very effective tool for unveiling problems like that: it's output at first could be intimidating but, once you understand how to read it, the info exposed are invaluable. http://gcc.gnu.org/wiki/Mudflap%20Pointer%20Debugging http://gcc.fyxm.net/summit/2003/mudflap.pdf From mattdm at mattdm.org Fri Nov 17 13:42:35 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 17 Nov 2006 08:42:35 -0500 Subject: icebreaker In-Reply-To: References: <455CC6A8.5060400@hhs.nl> <455CC813.6070506@avtechpulse.com> <455CD0FA.4040302@hhs.nl> <20061116205625.GA26597@jadzia.bu.edu> <26488.65.192.24.190.1163710718.squirrel@mail.jcomserv.net> <20061116230840.GA31585@jadzia.bu.edu> Message-ID: <20061117134235.GA30194@jadzia.bu.edu> On Fri, Nov 17, 2006 at 08:48:02AM +0100, Gianluca Sforna wrote: > I'm sure you already tried this but, just in case: > I found mudflap a very effective tool for unveiling problems like > that: it's output at first could be intimidating but, once you > understand how to read it, the info exposed are invaluable. I hadn't, but I think it's a logic bug rather than a pointer one. I did find some embarrassing pointer errors, though. I'll have to put out a 1.9.9 release. (I'm saving 2.0 for having solved the actual problem.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mmcgrath at fedoraproject.org Fri Nov 17 15:19:43 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 17 Nov 2006 09:19:43 -0600 Subject: CVS is busted Message-ID: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> As of about 8:40 today the CVS box threw a SMART error regarding one of its drives. As a result most of the CVS box is presently mounted read only. We are working to correct this issue but expect CVS to be up and down today. -Mike From mmcgrath at fedoraproject.org Fri Nov 17 16:30:03 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 17 Nov 2006 10:30:03 -0600 Subject: CVS is busted In-Reply-To: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> References: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> Message-ID: <3237e4410611170830l6d2d2edn45db8323c133825a@mail.gmail.com> On 11/17/06, Mike McGrath wrote: > As of about 8:40 today the CVS box threw a SMART error regarding one > of its drives. As a result most of the CVS box is presently mounted > read only. We are working to correct this issue but expect CVS to be > up and down today. > Dell has been dispatched and will arrive in 4 hours. CVS will be down until further notice. -Mike From seandarcy2 at gmail.com Fri Nov 17 18:17:59 2006 From: seandarcy2 at gmail.com (sean) Date: Fri, 17 Nov 2006 13:17:59 -0500 Subject: where's gutenprint-plugin ? Message-ID: I'm looking for the gimp2 print plugin from gutenprint. I see in the specfile it was taken out of gutenprint-extras, and packaged in gutenprint-plugins. But I can't find gutenprint-plugins. ??? sean From kevin-fedora-extras at scrye.com Fri Nov 17 20:28:11 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Fri, 17 Nov 2006 13:28:11 -0700 (MST) Subject: where's gutenprint-plugin ? References: Message-ID: <20061117.132811.05771257.kevin@scrye.com> >>>>> "sean" == sean writes: sean> I'm looking for the gimp2 print plugin from gutenprint. I see in sean> the specfile it was taken out of gutenprint-extras, and packaged sean> in gutenprint-plugins. sean> But I can't find gutenprint-plugins. sean> ??? The gimp2 print plugin in gutenprint conflicts with the plugin in the gimp-print package in core. :( So, since core and extras can't conflict, there is no gimp2 plugin available for gutenprint at this time. sean> sean kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at fedoraproject.org Sat Nov 18 01:55:14 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 17 Nov 2006 19:55:14 -0600 Subject: CVS is busted In-Reply-To: <3237e4410611170830l6d2d2edn45db8323c133825a@mail.gmail.com> References: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> <3237e4410611170830l6d2d2edn45db8323c133825a@mail.gmail.com> Message-ID: <3237e4410611171755pb39e43ay9c80e9d6e01d1570@mail.gmail.com> On 11/17/06, Mike McGrath wrote: > On 11/17/06, Mike McGrath wrote: > > As of about 8:40 today the CVS box threw a SMART error regarding one > > of its drives. As a result most of the CVS box is presently mounted > > read only. We are working to correct this issue but expect CVS to be > > up and down today. > > > > > Dell has been dispatched and will arrive in 4 hours. CVS will be down > until further notice. Further notice will go well into tonight and probably into tomorow. The drives are pretty messed up and mgalgoci has done great work to get the array's rebuilt but we aren't confident the filesystem will be in working order, we may have to restore from backup. -Mike From buildsys at fedoraproject.org Sat Nov 18 14:51:40 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 18 Nov 2006 09:51:40 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-18 Message-ID: <20061118145140.42D0F15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 23 Terminal-0.2.5.8-0.2.rc2.fc7 aumix-2.8-10.fc7 beryl-core-0.1.2-5.fc7 dejavu-fonts-2.12-0.2.rc1.fc7 exo-0.3.1.12-0.2.rc2.fc7 gcin-1.2.9-3.fc7 gnome-phone-manager-0.8-5.fc7 gnupg2-2.0.0-4.fc7 gossip-0.19-1.fc7 iksemel-1.2-13.fc7 jd-1.8.1-0.1.cvs061116.fc7 lilypond-doc-2.10.0-1.fc7 ochusha-0.5.99.63.3-0.2.cvs061116.fc7 perl-File-MimeInfo-0.13-3.fc7 perl-File-Remove-0.34-1.fc7 perl-Moose-0.17-2.fc7 stratagus-2.1-10.fc7 swaks-20061116.0-1.fc7 sylpheed-2.2.10-1.fc7 telepathy-butterfly-0.1.3-1.fc7 telepathy-gabble-0.4.5-1.fc7 unshield-0.5-6.fc7 xfce-mcs-manager-4.3.99.2-2.fc7 Packages built and released for Fedora Extras 6: 18 Ri-li-2.0.0-1.fc6 Terminal-0.2.5.8-0.2.rc2.fc6 aumix-2.8-10.fc6 beryl-core-0.1.2-5.fc6 exo-0.3.1.12-0.2.rc2.fc6 gcin-1.2.9-2.fc6 gnupg2-2.0.0-4.fc6 iksemel-1.2-13.fc6 logserial-0.4.2-4.fc6 perl-File-MimeInfo-0.13-3.fc6 perl-File-Remove-0.34-1.fc6 perl-Moose-0.17-2.fc6 php-pear-SOAP-0.9.4-1.fc6.1 qt4-4.2.1-3.fc6 stratagus-2.1-10.fc6 subversion-api-docs-1.4.2-1.fc6 unshield-0.5-6.fc6 xfce-mcs-manager-4.3.99.2-2.fc6 Packages built and released for Fedora Extras 5: 12 Ri-li-2.0.0-1.fc5 aumix-2.8-10.fc5 gcin-1.2.9-2.fc5 iksemel-1.2-13.fc5 logserial-0.4.2-4.fc5 mlton-20061107-1.fc5 perl-File-MimeInfo-0.13-3.fc5 perl-File-Remove-0.34-1.fc5 perl-Moose-0.17-2.fc5 php-pear-SOAP-0.9.4-1.fc5 stratagus-2.1-10.fc5 unshield-0.5-4.fc5 Packages built and released for Fedora Extras 4: 5 gcin-1.2.9-2.fc4 iksemel-1.2-13.fc4 perl-File-Remove-0.34-1.fc4 stratagus-2.1-10.fc4 unshield-0.5-3.fc4 Packages built and released for Fedora Extras 3: 1 unshield-0.5-3.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From tibbs at math.uh.edu Sat Nov 18 15:31:26 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 18 Nov 2006 09:31:26 -0600 Subject: CVS is busted In-Reply-To: <455EBFA7.3070400@argo.co.il> References: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> <455EBFA7.3070400@argo.co.il> Message-ID: >>>>> "AK" == Avi Kivity writes: AK> Just curious: why the read-only mount? shouldn't the RAID have AK> continued in degraded mode? Probably because something else bad happened that just completely screwed up the SCSI bus and corrupted data on multiple disks. - J< From roozbeh at farsiweb.info Sat Nov 18 15:13:14 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Sat, 18 Nov 2006 18:43:14 +0330 Subject: Orphaning three packages officially In-Reply-To: <200611161027.33009.jamatos@fc.up.pt> References: <1163017817.4615.24.camel@shalil.farsiweb.info> <200611161027.33009.jamatos@fc.up.pt> Message-ID: <1163862794.3357.25.camel@shalil.farsiweb.info> On Thu, 2006-11-16 at 10:27 +0000, Jos? Matos wrote: > PS: I will also take a look into ttf2pt1. Is this one of the projects where > you says that is silent upstream? Yes. Last release has been in 2003, while last CVS commit has been in Feb 2005. Roozbeh From mmcgrath at fedoraproject.org Sat Nov 18 17:28:17 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sat, 18 Nov 2006 11:28:17 -0600 Subject: CVS is busted In-Reply-To: References: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> <455EBFA7.3070400@argo.co.il> Message-ID: <3237e4410611180928q94fa51fx7f77fdee3f3a0a55@mail.gmail.com> On 18 Nov 2006 09:31:26 -0600, Jason L Tibbitts III wrote: > >>>>> "AK" == Avi Kivity writes: > > AK> Just curious: why the read-only mount? shouldn't the RAID have > AK> continued in degraded mode? > > Probably because something else bad happened that just completely > screwed up the SCSI bus and corrupted data on multiple disks. > > - J< > We're talking about multiple failures across multiple drives, possibly a backplane. Here's the current plan. 1) Move proxy 3-4 into the f.rh.c cluster so we can take our new dells back. 2) Grab one of the new Dells and build the new cvs box. This will allow us to A) trust the hardware (we're all a little wary about the current cvs box) and B) build a new box with atleast access to the old box if we're missing something. It will also allow us greater capacity with regards to future growth and the whole FC+FC=Fedora thing. 3) Restore backups to the new cvs box. 4) test test test 5) Release to the wild and fix bugs as needed. 6) Take the old cvs box and run full diagnostics before we rebuild it (it'll be come one of our db servers, either primary or backup) Right now mgalgoci is working working on steps 1 and 2. When they are done I'll be on step 3 and we'll need a few people for 4. We'll probably discuss in #fedora-extras when the time comes. Bottom line, this sucks but we're working on it. Should be up and better than ever by Monday. -Mike From twaugh at redhat.com Sat Nov 18 21:01:18 2006 From: twaugh at redhat.com (Tim Waugh) Date: Sat, 18 Nov 2006 21:01:18 +0000 Subject: where's gutenprint-plugin ? In-Reply-To: <20061117.132811.05771257.kevin@scrye.com> References: <20061117.132811.05771257.kevin@scrye.com> Message-ID: <1163883678.4671.12.camel@cyberelk.elk> On Fri, 2006-11-17 at 13:28 -0700, Kevin Fenzi wrote: > The gimp2 print plugin in gutenprint conflicts with the plugin in the > gimp-print package in core. :( > > So, since core and extras can't conflict, there is no gimp2 plugin > available for gutenprint at this time. I hesitate to suggest it, but is there any point in trying to use the 'alternatives' mechanism to overcome this, as well as the other command filters? Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From triad at df.lth.se Sat Nov 18 21:15:19 2006 From: triad at df.lth.se (Linus Walleij) Date: Sat, 18 Nov 2006 22:15:19 +0100 (CET) Subject: Progress reports of my students fixing bugs In-Reply-To: <455CC6A8.5060400@hhs.nl> References: <455CC6A8.5060400@hhs.nl> Message-ID: Here is a bug that requires a mobile phone which accepts extended AT-commands over Bluetooth (such as an Ericsson or a Motorola) to find: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212362 Linus From j.w.r.degoede at hhs.nl Sat Nov 18 23:03:26 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 19 Nov 2006 00:03:26 +0100 Subject: Is this content license free enough for FE? Message-ID: <455F913E.7010003@hhs.nl> Hi all, I just stumbled over this english translation of a manga game, which is "freely" distributed on the internet, and for which an GPL interpreter is available: http://narcissu.insani.org/ The readme talks about this being distributed under the PFSL, of which I managed to find a copy here (strange location): http://www.customtoolbarbuttons.com/en_google_toolbar_buttons/PFSL This license tries to limit charging for the "script" itself, but does allow for charging for media costs when distributing it on CD etc, it does disallow charging for downloads. So its all a bit vague, thus my question, does this constitute freely redistributable, as is the requirement for content? The relevant quote from the readme is: "You are allowed to redistribute this work to your heart's content so long as you do not modify its contents.", which sounds great, but then later it says: "The localization work is licensed under the PFSL" And I'm not sure if the PFSL is free enough, so what do you think? Regards, Hans From clive at vacuumtube.org.uk Sun Nov 19 15:49:45 2006 From: clive at vacuumtube.org.uk (Clive Messer) Date: Sun, 19 Nov 2006 15:49:45 +0000 Subject: beryl: missing deps Message-ID: <200611191549.45960.clive@vacuumtube.org.uk> Hi, It looks like only some of beryl has been pushed to repo ....... Error: Missing Dependency: bdock >= 0.1.2 is needed by package beryl Error: Missing Dependency: beryl-manager >= 0.1.2 is needed by package beryl-gnome Error: Missing Dependency: beryl-plugins >= 0.1.2 is needed by package beryl-gnome Error: Missing Dependency: beryl-manager >= 0.1.2 is needed by package beryl-kde Error: Missing Dependency: beryl-plugins >= 0.1.2 is needed by package beryl-kde Error: Missing Dependency: beryl-dbus >= 0.1.2 is needed by package beryl-gnome Error: Missing Dependency: emerald >= 0.1.2 is needed by package beryl-kde Error: Missing Dependency: heliodor >= 0.1.2 is needed by package beryl-gnome Error: Missing Dependency: beryl-settings >= 0.1.2 is needed by package beryl-kde Error: Missing Dependency: emerald >= 0.1.2 is needed by package beryl-gnome Error: Missing Dependency: emerald-themes >= 0.1.2 is needed by package beryl-kde Error: Missing Dependency: beryl-vidcap >= 0.1.2 is needed by package beryl-kde Error: Missing Dependency: emerald-themes >= 0.1.2 is needed by package beryl-gnome Error: Missing Dependency: beryl-vidcap >= 0.1.2 is needed by package beryl-gnome Error: Missing Dependency: beryl-settings >= 0.1.2 is needed by package beryl-gnome Error: Missing Dependency: aquamarine >= 0.1.2 is needed by package beryl-kde Clive -- Clive Messer From mtasaka at ioa.s.u-tokyo.ac.jp Sun Nov 19 15:57:29 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 20 Nov 2006 00:57:29 +0900 Subject: beryl: missing deps In-Reply-To: <200611191549.45960.clive@vacuumtube.org.uk> References: <200611191549.45960.clive@vacuumtube.org.uk> Message-ID: <45607EE9.4030003@ioa.s.u-tokyo.ac.jp> Clive Messer wrote: > Hi, > > It looks like only some of beryl has been pushed to repo ....... > Missing deps are under FE-Review or are waiting for FE CVS to come back again to be rebuilt. Mamoru Tasaka From fedora at leemhuis.info Sun Nov 19 16:33:34 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 19 Nov 2006 17:33:34 +0100 Subject: beryl: missing deps In-Reply-To: <45607EE9.4030003@ioa.s.u-tokyo.ac.jp> References: <200611191549.45960.clive@vacuumtube.org.uk> <45607EE9.4030003@ioa.s.u-tokyo.ac.jp> Message-ID: <4560875E.2020704@leemhuis.info> CCing jwilson at redhat.com, owner of beryl Mamoru Tasaka schrieb: > Clive Messer wrote: >> It looks like only some of beryl has been pushed to repo ....... > Missing deps are under FE-Review or are waiting for FE CVS to > come back again to be rebuilt. Then why the heck was beryl build for FC-6 if it was known that some hardcoded deps were not yet in cvs and not ready to be build? People will run into issues that way when using yum and thus the it's just a totally stupid thing to do in a stable branch (and even quite bad in the deel-branch, too). /me is getting more and more annoyed with all those broken deps and broken upgrade paths (some of them for months)... CU thl From sundaram at fedoraproject.org Sun Nov 19 16:35:26 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 19 Nov 2006 22:05:26 +0530 Subject: beryl: missing deps In-Reply-To: <4560875E.2020704@leemhuis.info> References: <200611191549.45960.clive@vacuumtube.org.uk> <45607EE9.4030003@ioa.s.u-tokyo.ac.jp> <4560875E.2020704@leemhuis.info> Message-ID: <456087CE.5070107@fedoraproject.org> Thorsten Leemhuis wrote: > CCing jwilson at redhat.com, owner of beryl > > Mamoru Tasaka schrieb: >> Clive Messer wrote: >>> It looks like only some of beryl has been pushed to repo ....... >> Missing deps are under FE-Review or are waiting for FE CVS to >> come back again to be rebuilt. > > Then why the heck was beryl build for FC-6 if it was known that some > hardcoded deps were not yet in cvs and not ready to be build? People > will run into issues that way when using yum and thus the it's just a > totally stupid thing to do in a stable branch (and even quite bad in the > deel-branch, too). > > /me is getting more and more annoyed with all those broken deps and > broken upgrade paths (some of them for months)... It would be better to automate checks so that packages without dependencies dont get pushed out in the repositories. It might still be useful to build it and check on occasions. Rahul From mtasaka at ioa.s.u-tokyo.ac.jp Sun Nov 19 16:51:57 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 20 Nov 2006 01:51:57 +0900 Subject: beryl: missing deps In-Reply-To: <4560875E.2020704@leemhuis.info> References: <200611191549.45960.clive@vacuumtube.org.uk> <45607EE9.4030003@ioa.s.u-tokyo.ac.jp> <4560875E.2020704@leemhuis.info> Message-ID: <45608BAD.1060709@ioa.s.u-tokyo.ac.jp> Thorsten Leemhuis wrote: > CCing jwilson at redhat.com, owner of beryl > > Mamoru Tasaka schrieb: >> Clive Messer wrote: >>> It looks like only some of beryl has been pushed to repo ....... >> Missing deps are under FE-Review or are waiting for FE CVS to >> come back again to be rebuilt. > > Then why the heck was beryl build for FC-6 if it was known that some > hardcoded deps were not yet in cvs and not ready to be build? This is because beryl-{gnome,kde} was added _after_ beryl-core srpm was approved. beryl-{gnome,kde} is rebuilt from beryl-core srpm, however, they depend on other packages. Please check the details on: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209259 Mamoru From jwilson at redhat.com Sun Nov 19 18:13:07 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Sun, 19 Nov 2006 13:13:07 -0500 Subject: beryl: missing deps In-Reply-To: <4560875E.2020704@leemhuis.info> References: <200611191549.45960.clive@vacuumtube.org.uk> <45607EE9.4030003@ioa.s.u-tokyo.ac.jp> <4560875E.2020704@leemhuis.info> Message-ID: <1163959987.20110.10.camel@chronos.wilsonet.com> On Sun, 2006-11-19 at 17:33 +0100, Thorsten Leemhuis wrote: > CCing jwilson at redhat.com, owner of beryl > > Mamoru Tasaka schrieb: > > Clive Messer wrote: > >> It looks like only some of beryl has been pushed to repo ....... > > Missing deps are under FE-Review or are waiting for FE CVS to > > come back again to be rebuilt. > > Then why the heck was beryl build for FC-6 if it was known that some > hardcoded deps were not yet in cvs and not ready to be build? People > will run into issues that way when using yum and thus the it's just a > totally stupid thing to do in a stable branch (and even quite bad in the > deel-branch, too). > > /me is getting more and more annoyed with all those broken deps and > broken upgrade paths (some of them for months)... The only hard-coded deps that can't be met at the moment are on the meta-packages for installing all the beryl bits. As mentioned, the initial beryl-core package had no unresolved deps, but subsequent discussion while reviewing other beryl components led to the creation of some meta-packages to make installing all beryl bits easier for end-users. I guess I wasn't thinking when I pushed the beryl-core build w/the meta-packages enabled. My apologies for being "totally stupid". Of course, this would be (mostly) moot by now had cvs not taken a nose-dive... :) -- Jarod Wilson jwilson at redhat.com From fedora at leemhuis.info Sun Nov 19 18:37:17 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 19 Nov 2006 19:37:17 +0100 Subject: beryl: missing deps In-Reply-To: <456087CE.5070107@fedoraproject.org> References: <200611191549.45960.clive@vacuumtube.org.uk> <45607EE9.4030003@ioa.s.u-tokyo.ac.jp> <4560875E.2020704@leemhuis.info> <456087CE.5070107@fedoraproject.org> Message-ID: <4560A45D.9090708@leemhuis.info> Rahul Sundaram schrieb: > Thorsten Leemhuis wrote: >> CCing jwilson at redhat.com, owner of beryl >> Mamoru Tasaka schrieb: >>> Clive Messer wrote: >>>> It looks like only some of beryl has been pushed to repo ....... >>> Missing deps are under FE-Review or are waiting for FE CVS to >>> come back again to be rebuilt. >> Then why the heck was beryl build for FC-6 if it was known that some >> hardcoded deps were not yet in cvs and not ready to be build? People >> will run into issues that way when using yum and thus the it's just a >> totally stupid thing to do in a stable branch (and even quite bad in the >> deel-branch, too). >> /me is getting more and more annoyed with all those broken deps and >> broken upgrade paths (some of them for months)... > It would be better to automate checks so that packages without > dependencies dont get pushed out in the repositories. [...] Sure, but that's easier said then implemented ;) Especially now that we might need to merge the Extras and Core push scripts... CU thl From fedora at leemhuis.info Sun Nov 19 18:38:33 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 19 Nov 2006 19:38:33 +0100 Subject: beryl: missing deps In-Reply-To: <45608BAD.1060709@ioa.s.u-tokyo.ac.jp> References: <200611191549.45960.clive@vacuumtube.org.uk> <45607EE9.4030003@ioa.s.u-tokyo.ac.jp> <4560875E.2020704@leemhuis.info> <45608BAD.1060709@ioa.s.u-tokyo.ac.jp> Message-ID: <4560A4A9.7050605@leemhuis.info> Mamoru Tasaka schrieb: > Thorsten Leemhuis wrote: >> CCing jwilson at redhat.com, owner of beryl >> >> Mamoru Tasaka schrieb: >>> Clive Messer wrote: >>>> It looks like only some of beryl has been pushed to repo ....... >>> Missing deps are under FE-Review or are waiting for FE CVS to >>> come back again to be rebuilt. >> Then why the heck was beryl build for FC-6 if it was known that some >> hardcoded deps were not yet in cvs and not ready to be build? > This is because beryl-{gnome,kde} was added _after_ beryl-core srpm > was approved. I know, otherwise I'd might have complained about the review ;) CU thl From fedora at leemhuis.info Sun Nov 19 18:43:40 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 19 Nov 2006 19:43:40 +0100 Subject: beryl: missing deps In-Reply-To: <1163959987.20110.10.camel@chronos.wilsonet.com> References: <200611191549.45960.clive@vacuumtube.org.uk> <45607EE9.4030003@ioa.s.u-tokyo.ac.jp> <4560875E.2020704@leemhuis.info> <1163959987.20110.10.camel@chronos.wilsonet.com> Message-ID: <4560A5DC.3060709@leemhuis.info> Jarod Wilson schrieb: > On Sun, 2006-11-19 at 17:33 +0100, Thorsten Leemhuis wrote: >> CCing jwilson at redhat.com, owner of beryl >> Mamoru Tasaka schrieb: >>> Clive Messer wrote: >>>> It looks like only some of beryl has been pushed to repo ....... >>> Missing deps are under FE-Review or are waiting for FE CVS to >>> come back again to be rebuilt. >> Then why the heck was beryl build for FC-6 if it was known that some >> hardcoded deps were not yet in cvs and not ready to be build? People >> will run into issues that way when using yum and thus the it's just a >> totally stupid thing to do in a stable branch (and even quite bad in the >> deel-branch, too). >> /me is getting more and more annoyed with all those broken deps and >> broken upgrade paths (some of them for months)... > The only hard-coded deps that can't be met at the moment are on the > meta-packages for installing all the beryl bits. As mentioned, the > initial beryl-core package had no unresolved deps, but subsequent > discussion while reviewing other beryl components led to the creation of > some meta-packages to make installing all beryl bits easier for > end-users. I appreciate that idea, but it would have been better if you would have waited realizing this idea until the bits that the meta-packages requires are at least in CVS and ready to build. ;) > I guess I wasn't thinking when I pushed the beryl-core build > w/the meta-packages enabled. My apologies for being "totally stupid". Sorry, maybe I overreacted a bit. But we get more at more of this little mistakes and stuff here and there that don't get fixed. That really annoys me. We really need to be more careful. > Of > course, this would be (mostly) moot by now had cvs not taken a > nose-dive... :) Yeah, bad luck. Anyway, thx for your work on the beryl packages! Cu thl From Jochen at herr-schmitt.de Sun Nov 19 18:51:16 2006 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Sun, 19 Nov 2006 19:51:16 +0100 Subject: Is this content license free enough for FE? In-Reply-To: <455F913E.7010003@hhs.nl> References: <455F913E.7010003@hhs.nl> Message-ID: <0MKwh2-1GlrlH3P9R-0001NS@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 19 Nov 2006 00:03:26 +0100, you wrote: >The relevant quote from the readme is: "You are allowed to redistribute >this work to your heart's content so long as you do not modify its >contents.", That sounds not good. The condtions for free software requires that you have got the right to modify and redistribute the work. But the quoted text says, that you have the right to redistribute the work only in an unmodified state. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.0 (Build 1202) Charset: us-ascii wj8DBQFFYKevT2AHK6txfgwRArV6AJoCrwMIYW3Ac+W+/ZOHAw2W6lkGlQCgyyf1 Gg1HWiF5fKV0/BPh9Trl+SA= =WTaw -----END PGP SIGNATURE----- From j.w.r.degoede at hhs.nl Sun Nov 19 19:14:59 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 19 Nov 2006 20:14:59 +0100 Subject: Is this content license free enough for FE? In-Reply-To: <0MKwh2-1GlrlH3P9R-0001NS@mrelayeu.kundenserver.de> References: <455F913E.7010003@hhs.nl> <0MKwh2-1GlrlH3P9R-0001NS@mrelayeu.kundenserver.de> Message-ID: <4560AD33.4020603@hhs.nl> Jochen Schmitt wrote: > On Sun, 19 Nov 2006 00:03:26 +0100, you wrote: > >>> The relevant quote from the readme is: "You are allowed to redistribute >>> this work to your heart's content so long as you do not modify its >>> contents.", > > That sounds not good. The condtions for free software requires > that you have got the right to modify and redistribute the work. > But the quoted text says, that you have the right to redistribute > the work only in an unmodified state. > this is about content not code, and all we (Fedora) demand for content is that it is freely redistributable. Next time please first get acquainted with what you're commenting on, before shooting a reply from the hip. Regards, Hans From bugs.michael at gmx.net Sun Nov 19 20:09:57 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 19 Nov 2006 21:09:57 +0100 Subject: beryl: missing deps In-Reply-To: <4560A45D.9090708@leemhuis.info> References: <200611191549.45960.clive@vacuumtube.org.uk> <45607EE9.4030003@ioa.s.u-tokyo.ac.jp> <4560875E.2020704@leemhuis.info> <456087CE.5070107@fedoraproject.org> <4560A45D.9090708@leemhuis.info> Message-ID: <20061119210957.a7e6c94b.bugs.michael@gmx.net> On Sun, 19 Nov 2006 19:37:17 +0100, Thorsten Leemhuis wrote: > Rahul Sundaram wrote: > >>> Clive Messer wrote: > >>>> It looks like only some of beryl has been pushed to repo ....... > >>> Missing deps are under FE-Review or are waiting for FE CVS to > >>> come back again to be rebuilt. > >> Then why the heck was beryl build for FC-6 if it was known that some > >> hardcoded deps were not yet in cvs and not ready to be build? People > >> will run into issues that way when using yum and thus the it's just a > >> totally stupid thing to do in a stable branch (and even quite bad in the > >> deel-branch, too). > >> /me is getting more and more annoyed with all those broken deps and > >> broken upgrade paths (some of them for months)... > > It would be better to automate checks so that packages without > > dependencies dont get pushed out in the repositories. [...] > > Sure, but that's easier said then implemented ;) Especially now that we > might need to merge the Extras and Core push scripts... Push scripts like we use currently would be the wrong place where to check dependencies, anyway. Checking all of Fedora Extras 3,4,5,6,devel against all of Fedora Core plus Updates plus Legacy (i.e. what the current broken deps report does) takes a lot of time. Around 45 minutes on the build master. That is with cached metadata. It would need to become a dedicated server process with a queue (possibly a stack), since with every package which builds fine or which breaks dependencies, respectively, there are reoccurring operations. Like putting back in the "publish queue" any packages which have been withdrawn before due to broken deps. Or recalculating the complete repository closure for all pending packages to find out what set of packages is "good to go" after another [possibly related] build job completed. More important, post-build checks add another state to the tuple "failed, needsign" which introduces interactivity and must give the package maintainer a chance to influence the release process. For instance, the tools for an upgraded suite of programs build fine and without breaking any deps, but parts of the run-time components of the upgraded suite break deps inside the repository. That would be a scenario where a package maintainer would need to be able to block an entire group of builds in order to not release only half of it. Also keep in mind that every successfully built package is available to all subsequent build jobs via the "needsign" queue. If such a package is not released, trash in the needsign queue piles up when it is not fixed soon. And the two reports about breakage in Extras and Core show examples, where fixes are missing for a long time. From clive at vacuumtube.org.uk Sun Nov 19 20:30:51 2006 From: clive at vacuumtube.org.uk (Clive Messer) Date: Sun, 19 Nov 2006 20:30:51 +0000 Subject: beryl: missing deps In-Reply-To: <1163959987.20110.10.camel@chronos.wilsonet.com> References: <200611191549.45960.clive@vacuumtube.org.uk> <4560875E.2020704@leemhuis.info> <1163959987.20110.10.camel@chronos.wilsonet.com> Message-ID: <200611192030.51628.clive@vacuumtube.org.uk> On Sunday 19 November 2006 18:13, Jarod Wilson wrote: > On Sun, 2006-11-19 at 17:33 +0100, Thorsten Leemhuis wrote: > > CCing jwilson at redhat.com, owner of beryl > > > > Mamoru Tasaka schrieb: > > > Clive Messer wrote: > > >> It looks like only some of beryl has been pushed to repo ....... > > > > > > Missing deps are under FE-Review or are waiting for FE CVS to > > > come back again to be rebuilt. > > > > Then why the heck was beryl build for FC-6 if it was known that some > > hardcoded deps were not yet in cvs and not ready to be build? People > > will run into issues that way when using yum and thus the it's just a > > totally stupid thing to do in a stable branch (and even quite bad in the > > deel-branch, too). > > > > /me is getting more and more annoyed with all those broken deps and > > broken upgrade paths (some of them for months)... > > The only hard-coded deps that can't be met at the moment are on the > meta-packages for installing all the beryl bits. As mentioned, the > initial beryl-core package had no unresolved deps, but subsequent > discussion while reviewing other beryl components led to the creation of > some meta-packages to make installing all beryl bits easier for > end-users. I guess I wasn't thinking when I pushed the beryl-core build > w/the meta-packages enabled. My apologies for being "totally stupid". Of > course, this would be (mostly) moot by now had cvs not taken a > nose-dive... :) Jarod, I'm not complaining; really! I've been happily following the devel version of these packages from wilson.net and waiting for their official release from extras. Thanks for the work you have put in. But, forgetting the meta packages for the moment, I would expect at the same time as beryl-core was pushed to extras, to at least also be able to pull beryl-manager, beryl-settings, beryl-plugins, emerald and emerald-themes. What is the point of even making beryl-core available without these packages also having been released at the same time? Clive -- Clive Messer From sundaram at fedoraproject.org Sun Nov 19 23:58:49 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 20 Nov 2006 05:28:49 +0530 Subject: Brasero dependencies Message-ID: <4560EFB9.6080006@fedoraproject.org> Hi Why is Brasero, a CD burning application in Fedora Extras dependant on Totem and libbeagle? Does it start Beagle automatically too? Rahul From denis at poolshark.org Mon Nov 20 01:26:36 2006 From: denis at poolshark.org (Denis Leroy) Date: Mon, 20 Nov 2006 02:26:36 +0100 Subject: Brasero dependencies In-Reply-To: <4560EFB9.6080006@fedoraproject.org> References: <4560EFB9.6080006@fedoraproject.org> Message-ID: <4561044C.5000003@poolshark.org> Rahul Sundaram wrote: > Hi > > Why is Brasero, a CD burning application in Fedora Extras dependant on > Totem and libbeagle? http://perso.orange.fr/bonfire/features.htm totem: playlist support beagle: audio files search > Does it start Beagle automatically too? ?? beagled is launched by the Gnome desktop when a user logs in. From sundaram at fedoraproject.org Mon Nov 20 01:35:47 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 20 Nov 2006 07:05:47 +0530 Subject: Brasero dependencies In-Reply-To: <4561044C.5000003@poolshark.org> References: <4560EFB9.6080006@fedoraproject.org> <4561044C.5000003@poolshark.org> Message-ID: <45610673.4000801@fedoraproject.org> Denis Leroy wrote: > Rahul Sundaram wrote: >> Hi >> >> Why is Brasero, a CD burning application in Fedora Extras dependant on >> Totem and libbeagle? > > http://perso.orange.fr/bonfire/features.htm > > totem: playlist support Would it be possible to split the playsupport library from Totem? It doesnt seem right to require a particular video player for a CD burning application. > beagle: audio files search > > > Does it start Beagle automatically too? > > ?? beagled is launched by the Gnome desktop when a user logs in. I am talking about when a user doesnt install Beagle and installs Brasero. Can it support tracker? Rahul From mmcgrath at fedoraproject.org Mon Nov 20 02:26:54 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sun, 19 Nov 2006 20:26:54 -0600 Subject: CVS is busted In-Reply-To: <3237e4410611180928q94fa51fx7f77fdee3f3a0a55@mail.gmail.com> References: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> <455EBFA7.3070400@argo.co.il> <3237e4410611180928q94fa51fx7f77fdee3f3a0a55@mail.gmail.com> Message-ID: <3237e4410611191826hf9b20e3h5a8f108841dcb0f9@mail.gmail.com> On 11/18/06, Mike McGrath wrote: > Bottom line, this sucks but we're working on it. Should be up and > better than ever by Monday. > Buhhh, late monday. -Mike From jspaleta at gmail.com Mon Nov 20 03:58:02 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 19 Nov 2006 18:58:02 -0900 Subject: Progress reports of my students fixing bugs In-Reply-To: <455CD489.4080303@hhs.nl> References: <455CC6A8.5060400@hhs.nl> <455CC813.6070506@avtechpulse.com> <455CD0FA.4040302@hhs.nl> <20061116205625.GA26597@jadzia.bu.edu> <455CD489.4080303@hhs.nl> Message-ID: <604aa7910611191958o5829777o213f5b26af7db79@mail.gmail.com> On 11/16/06, Hans de Goede wrote: > If you say its probably trivial and you can describe it well and in a > reproducable manner then I'm more then willing to feed it to my students :) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213528#c3 I can reproduce the problem with istanbul concerning "too small" of an selection area, regardless of video hardware (at least for the hardware I have access to). It's most likely some sort of inherent limitation in a gstreamer module that istanbul isn't aware of. If I had more time I could track this down building gstramer pipelines outside of istanbul. Have a student track down exactly which gstreamer module is having a problem with the "too small" video capture area, and either have them patch the gstreamer module itself or provide a less technical work around which is istanbul specific to avoid the problematic conditions which gstreamer pipeline doesn't handle. -jef From j.w.r.degoede at hhs.nl Mon Nov 20 12:32:49 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 20 Nov 2006 13:32:49 +0100 Subject: Progress reports of my students fixing bugs In-Reply-To: <20061116230840.GA31585@jadzia.bu.edu> References: <455CC6A8.5060400@hhs.nl> <455CC813.6070506@avtechpulse.com> <455CD0FA.4040302@hhs.nl> <20061116205625.GA26597@jadzia.bu.edu> <26488.65.192.24.190.1163710718.squirrel@mail.jcomserv.net> <20061116230840.GA31585@jadzia.bu.edu> Message-ID: <4561A071.40301@hhs.nl> Matthew Miller wrote: > On Thu, Nov 16, 2006 at 02:58:38PM -0600, Jon Ciesla wrote: >> Provide bug and source code, please. I'm curious. > > Mostly, > > Latest code at: > > > > although there's some stuff languishing in CVS that I haven't touched for a > while. > > The bug is: sometimes, when you complete a line, area which includes a > penguin is calculated as not including one. It's probably a stupid > off-by-one error or something, but I beat my head against it for a while and > stopped. > > Caveat: this is code from several years ago and my pride in it is > mixed. It was the first decent-sized C program I wrote on Linux, and I was a > little intimidated, so I did some clearly odd things, like avoiding > allocating dynamic memory. Plus, the code to make the whole entry screen is > very kludgy and causes other kludges. :) And please don't mention how the > spec file needs cleaning up. :) > Thanks, I've added this to the list for the students under the category difficult, for those who like challenge. Regards, Hans From jwilson at redhat.com Mon Nov 20 14:31:30 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 20 Nov 2006 09:31:30 -0500 Subject: beryl: missing deps In-Reply-To: <200611192030.51628.clive@vacuumtube.org.uk> References: <200611191549.45960.clive@vacuumtube.org.uk> <4560875E.2020704@leemhuis.info> <1163959987.20110.10.camel@chronos.wilsonet.com> <200611192030.51628.clive@vacuumtube.org.uk> Message-ID: <1164033090.31732.7.camel@xavier.boston.redhat.com> On Sun, 2006-11-19 at 20:30 +0000, Clive Messer wrote: > I'm not complaining; really! I've been happily following the devel version of > these packages from wilson.net and waiting for their official release from > extras. Thanks for the work you have put in. Glad to know the work is still appreciated, despite the havoc I've caused. :) > But, forgetting the meta packages for the moment, I would expect at the same > time as beryl-core was pushed to extras, to at least also be able to pull > beryl-manager, beryl-settings, beryl-plugins, emerald and emerald-themes. > What is the point of even making beryl-core available without these packages > also having been released at the same time? Well, beryl-core did need to get pushed first, so as to make beryl-core-devel available somewhere so that all the other packages could get built. If I'm remembering correctly (always a big *if* :), I pushed beryl-core for FC6 on Thursday, with the intention of building all the bits above you mention on Friday morning, but then cvs went bonk... /me anxiously awaits the resurrection of cvs so as to right the wrongs he has (cvs) committed... :) -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mattdm at mattdm.org Mon Nov 20 14:49:10 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 20 Nov 2006 09:49:10 -0500 Subject: Progress reports of my students fixing bugs In-Reply-To: <4561A071.40301@hhs.nl> References: <455CC6A8.5060400@hhs.nl> <455CC813.6070506@avtechpulse.com> <455CD0FA.4040302@hhs.nl> <20061116205625.GA26597@jadzia.bu.edu> <26488.65.192.24.190.1163710718.squirrel@mail.jcomserv.net> <20061116230840.GA31585@jadzia.bu.edu> <4561A071.40301@hhs.nl> Message-ID: <20061120144910.GA19663@jadzia.bu.edu> On Mon, Nov 20, 2006 at 01:32:49PM +0100, Hans de Goede wrote: > I've added this to the list for the students under the category difficult, > for those who like challenge. Excellent. :) I'll have an updated code tarball in a day or two, btw. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fedora at leemhuis.info Mon Nov 20 16:10:08 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 20 Nov 2006 17:10:08 +0100 Subject: FESCo meeting this week on wednesday Message-ID: <4561D360.30905@leemhuis.info> Hi all! Just FYI, we'll run the FESCo meeting this week on Wednesday at 18:00 UTC instead or Thursday due to Thanksgiving/public holiday in the US on Thursday. See you in #fedora-extras on Wednesday! All contributers are invited to participate in the meeting! Meeting rules: http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines Cu thl From jwilson at redhat.com Mon Nov 20 16:19:44 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 20 Nov 2006 11:19:44 -0500 Subject: beryl: missing deps In-Reply-To: <4560A5DC.3060709@leemhuis.info> References: <200611191549.45960.clive@vacuumtube.org.uk> <45607EE9.4030003@ioa.s.u-tokyo.ac.jp> <4560875E.2020704@leemhuis.info> <1163959987.20110.10.camel@chronos.wilsonet.com> <4560A5DC.3060709@leemhuis.info> Message-ID: <1164039584.31732.17.camel@xavier.boston.redhat.com> On Sun, 2006-11-19 at 19:43 +0100, Thorsten Leemhuis wrote: > Jarod Wilson schrieb: > > On Sun, 2006-11-19 at 17:33 +0100, Thorsten Leemhuis wrote: > >> CCing jwilson at redhat.com, owner of beryl > >> Mamoru Tasaka schrieb: > >>> Clive Messer wrote: > >>>> It looks like only some of beryl has been pushed to repo ....... > >>> Missing deps are under FE-Review or are waiting for FE CVS to > >>> come back again to be rebuilt. > >> Then why the heck was beryl build for FC-6 if it was known that some > >> hardcoded deps were not yet in cvs and not ready to be build? People > >> will run into issues that way when using yum and thus the it's just a > >> totally stupid thing to do in a stable branch (and even quite bad in the > >> deel-branch, too). > >> /me is getting more and more annoyed with all those broken deps and > >> broken upgrade paths (some of them for months)... > > The only hard-coded deps that can't be met at the moment are on the > > meta-packages for installing all the beryl bits. As mentioned, the > > initial beryl-core package had no unresolved deps, but subsequent > > discussion while reviewing other beryl components led to the creation of > > some meta-packages to make installing all beryl bits easier for > > end-users. > > I appreciate that idea, but it would have been better if you would have > waited realizing this idea until the bits that the meta-packages > requires are at least in CVS and ready to build. ;) Yeah, definitely. Like I said, I think I just wasn't thinking at the time, too much going on... > > I guess I wasn't thinking when I pushed the beryl-core build > > w/the meta-packages enabled. My apologies for being "totally stupid". > > Sorry, maybe I overreacted a bit. I thought it was maybe a bit harsh for a first offense, but you've been more involved in FE a lot longer than I have, so I took it with a grain of salt. A gentle, "hey, please don't do that" would have achieved the same end -- dialog and education, but no worries. > But we get more at more of this little > mistakes and stuff here and there that don't get fixed. This will definitely get fixed. Once cvs does... :( > That really annoys me. We really need to be more careful. Agreed. > > Of > > course, this would be (mostly) moot by now had cvs not taken a > > nose-dive... :) > > Yeah, bad luck. > > Anyway, thx for your work on the beryl packages! :) -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Home at TimAliBentley.org.uk Mon Nov 20 19:39:39 2006 From: Home at TimAliBentley.org.uk (Tim and Alison Bentley) Date: Mon, 20 Nov 2006 19:39:39 +0000 Subject: MonoDevelop 0.12-7.fc6 Message-ID: <4562047B.2030300@TimAliBentley.org.uk> I was wondering why the current version of Monodevelop was missing the version control functionality: - Version Control provided by Subversion - ASPX development provided by the ASPX plugins. I have attempted to build from source and have problems with every move I make. -- Tim and Alison Bentley Email: Home at TimAliBentley.org.uk From mmcgrath at fedoraproject.org Mon Nov 20 22:34:01 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 20 Nov 2006 16:34:01 -0600 Subject: CVS is busted In-Reply-To: <3237e4410611191826hf9b20e3h5a8f108841dcb0f9@mail.gmail.com> References: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> <455EBFA7.3070400@argo.co.il> <3237e4410611180928q94fa51fx7f77fdee3f3a0a55@mail.gmail.com> <3237e4410611191826hf9b20e3h5a8f108841dcb0f9@mail.gmail.com> Message-ID: <3237e4410611201434h4e687411u56110fc8f8fb355c@mail.gmail.com> On 11/19/06, Mike McGrath wrote: > On 11/18/06, Mike McGrath wrote: > > > Bottom line, this sucks but we're working on it. Should be up and > > better than ever by Monday. > > > > Buhhh, late monday. > > -Mike > We've got the box, restores are happening as we speak, 48G restored so far. I'll be restoring the ssh-host keys last so if you're still getting ssh mismatch errors... its not ready to be logged into. -Mike From paul at all-the-johnsons.co.uk Mon Nov 20 23:39:23 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 20 Nov 2006 23:39:23 +0000 Subject: MonoDevelop 0.12-7.fc6 In-Reply-To: <4562047B.2030300@TimAliBentley.org.uk> References: <4562047B.2030300@TimAliBentley.org.uk> Message-ID: <1164065963.31552.58.camel@T7.Linux> Hi, > I was wondering why the current version of Monodevelop was missing the > version control functionality: > - Version Control provided by Subversion When I built it last using Subversion, it crashed and burned on both x86 and x86_64 > - ASPX development provided by the ASPX plugins. Neither were shipped with the source. > I have attempted to build from source and have problems with every move > I make. Monodevelop can be a bit of swine to build from source. Are you grabbing the sources directly from mono svn or using the src.rpm file? TTFN Paul Monodevelop packager -- Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Tue Nov 21 01:01:30 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 20 Nov 2006 16:01:30 -0900 Subject: Status of any effort to get Scipy into Extras? Message-ID: <604aa7910611201701t3f7620c8lbb3a0473aecc958a@mail.gmail.com> it looks like a previous attempt to get scipy into Extras stalled https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188482 but Neal still seems to be working on making headway on it as of 09-2006 by getting numpy patched. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184504 Anyone have an update as to where scipy is at right now? If I wanted to restart the process, do I do a new review ticket or do I re-open the previous inactive review ticket? -jef From jwilson at redhat.com Tue Nov 21 04:11:46 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 20 Nov 2006 23:11:46 -0500 Subject: Status of any effort to get Scipy into Extras? In-Reply-To: <604aa7910611201701t3f7620c8lbb3a0473aecc958a@mail.gmail.com> References: <604aa7910611201701t3f7620c8lbb3a0473aecc958a@mail.gmail.com> Message-ID: <1164082306.25587.3.camel@chronos.wilsonet.com> On Mon, 2006-11-20 at 16:01 -0900, Jeff Spaleta wrote: > it looks like a previous attempt to get scipy into Extras stalled > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188482 > > but Neal still seems to be working on making headway on it as of > 09-2006 by getting numpy patched. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184504 > > Anyone have an update as to where scipy is at right now? According to Neal, scipy 0.5.1 builds fine against numpy 1.0, which I pushed into rawhide a little while back. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212147 > If I wanted > to restart the process, do I do a new review ticket or do I re-open > the previous inactive review ticket? Dunno... Also, I'm ready to bump FC5 and 6 to numpy 1.0 if there's no reason not to. However, all I've got to go on is one thumbs up and zero thumbs down for the rawhide numpy 1.0 build... -- Jarod Wilson jwilson at redhat.com From jspaleta at gmail.com Tue Nov 21 04:28:57 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 20 Nov 2006 19:28:57 -0900 Subject: Status of any effort to get Scipy into Extras? In-Reply-To: <1164082306.25587.3.camel@chronos.wilsonet.com> References: <604aa7910611201701t3f7620c8lbb3a0473aecc958a@mail.gmail.com> <1164082306.25587.3.camel@chronos.wilsonet.com> Message-ID: <604aa7910611202028h57bc2d9buac4de6650ab53713@mail.gmail.com> On 11/20/06, Jarod Wilson wrote: > Also, I'm ready to bump FC5 and 6 to numpy 1.0 if there's no reason not > to. However, all I've got to go on is one thumbs up and zero thumbs down > for the rawhide numpy 1.0 build... Yes, please do that update. If Neal isn't going to pick up the scipy Extras maintainership effort I think I am going to need to. I'm currently testing scipy using the rawhide package. One thing numpy is throwing warnings about an outdated ctypes module. I'm not sure if that's important or not. Also there appears to be an issue with the current matplotlib in Extras which is fixed if we update to matplotlib release 0.87.7. I need to dig up my bugzilla password so I can file about that. -jef From jspaleta at gmail.com Tue Nov 21 05:59:50 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 20 Nov 2006 20:59:50 -0900 Subject: Status of any effort to get Scipy into Extras? In-Reply-To: <604aa7910611202028h57bc2d9buac4de6650ab53713@mail.gmail.com> References: <604aa7910611201701t3f7620c8lbb3a0473aecc958a@mail.gmail.com> <1164082306.25587.3.camel@chronos.wilsonet.com> <604aa7910611202028h57bc2d9buac4de6650ab53713@mail.gmail.com> Message-ID: <604aa7910611202159n6971dba7we6c4ec08e7ca7e9b@mail.gmail.com> On 11/20/06, Jeff Spaleta wrote: > Also there appears to be an issue with the current matplotlib in > Extras which is fixed if we update to matplotlib release 0.87.7. I > need to dig up my bugzilla password so I can file about that. Okay I've spun up 0.87.7 srpm of matplotlib, and pinged the current maintainer about it and asked if he would like a co-maintainer. Now I need to poke Neal and see if we can get scipy into extras-development and then into fe6. -jef From wtogami at redhat.com Tue Nov 21 06:17:26 2006 From: wtogami at redhat.com (Warren Togami) Date: Tue, 21 Nov 2006 01:17:26 -0500 Subject: CVS Status.... Message-ID: <456299F6.3060601@redhat.com> After restoring the CVS backup onto a new donated server from Dell... and several hours more of attemping to figure out weird problems in the software, mmcgrath and I are *REALLY* close to making it work. We're sleeping for now and giving it another try tomorrow morning. Warren From mmcgrath at fedoraproject.org Tue Nov 21 07:00:42 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 21 Nov 2006 01:00:42 -0600 Subject: CVS is busted In-Reply-To: <3237e4410611201434h4e687411u56110fc8f8fb355c@mail.gmail.com> References: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> <455EBFA7.3070400@argo.co.il> <3237e4410611180928q94fa51fx7f77fdee3f3a0a55@mail.gmail.com> <3237e4410611191826hf9b20e3h5a8f108841dcb0f9@mail.gmail.com> <3237e4410611201434h4e687411u56110fc8f8fb355c@mail.gmail.com> Message-ID: <3237e4410611202300mc20d964s65ef708bd6d1f244@mail.gmail.com> On 11/20/06, Mike McGrath wrote: > On 11/19/06, Mike McGrath wrote: > > On 11/18/06, Mike McGrath wrote: > > > > > Bottom line, this sucks but we're working on it. Should be up and > > > better than ever by Monday. > > > > > > > Buhhh, late monday. > > > > -Mike > > > > > We've got the box, restores are happening as we speak, 48G restored so > far. I'll be restoring the ssh-host keys last so if you're still > getting ssh mismatch errors... its not ready to be logged into. > Alrighty then, new box is up. The following service should be working (if they are not, let me know immediately) legacy - cvs extras - cvs fedora - cvs dist (copy) - cvs docs - cvs font - cvs (whatever that is) viewcvs Services known NOT to work git (needs a new chroot but no data loss) Services in ????: There were a number of web services on the box that were never properly configured in the first place. Let me know if there are services taht don't work now that did before the crash. AFAIK we had no actual data loss except for commits that happened after the last backup and before the failure (which was bout an 8 hour window or so with 10 commits. I believe warren is going to contact these people or already has). I'll be working on getting the git repo back up tomorrow morning and will need someone to test, any volunteers please contact me. CVS is a very strange box in that many people have access to make changes on it (and they do) it could take a while before we get every service back online but we're doing well. Please contact me (or admin at fedoraproject) with any issues or bugs, we'll get to them soon. -Mike From jspaleta at gmail.com Tue Nov 21 07:22:32 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 20 Nov 2006 22:22:32 -0900 Subject: Status of any effort to get Scipy into Extras? In-Reply-To: <604aa7910611202159n6971dba7we6c4ec08e7ca7e9b@mail.gmail.com> References: <604aa7910611201701t3f7620c8lbb3a0473aecc958a@mail.gmail.com> <1164082306.25587.3.camel@chronos.wilsonet.com> <604aa7910611202028h57bc2d9buac4de6650ab53713@mail.gmail.com> <604aa7910611202159n6971dba7we6c4ec08e7ca7e9b@mail.gmail.com> Message-ID: <604aa7910611202322g6613d5b9s855a03653c567771@mail.gmail.com> On 11/20/06, Jeff Spaleta wrote: > Okay I've spun up 0.87.7 srpm of matplotlib, and pinged the current > maintainer about it and asked if he would like a co-maintainer. Everyone feel free to test the updated matplotlib srpm I have spun up. http://jspaleta.thecodergeek.com/Fedora%20SRPMS/python-matplotlib-0.87.7-1.src.rpm This should work with the numpy currently in extras-development and with the numpy currently available in fe6. -jef From dominik at greysector.net Tue Nov 21 07:44:45 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 21 Nov 2006 08:44:45 +0100 Subject: CVS is busted In-Reply-To: <3237e4410611202300mc20d964s65ef708bd6d1f244@mail.gmail.com> References: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> <455EBFA7.3070400@argo.co.il> <3237e4410611180928q94fa51fx7f77fdee3f3a0a55@mail.gmail.com> <3237e4410611191826hf9b20e3h5a8f108841dcb0f9@mail.gmail.com> <3237e4410611201434h4e687411u56110fc8f8fb355c@mail.gmail.com> <3237e4410611202300mc20d964s65ef708bd6d1f244@mail.gmail.com> Message-ID: <20061121074445.GB29948@rathann.pekin.waw.pl> On Tuesday, 21 November 2006 at 08:00, Mike McGrath wrote: [...] > Alrighty then, new box is up. The following service should be working > (if they are not, let me know immediately) > > legacy - cvs > extras - cvs > fedora - cvs > dist (copy) - cvs > docs - cvs > font - cvs (whatever that is) > viewcvs Thank you very much for the hard work! I've just imported and built another package. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From rc040203 at freenet.de Tue Nov 21 08:03:47 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 21 Nov 2006 09:03:47 +0100 Subject: rpms/tracker/devel tracker-desktop.patch, NONE, 1.1 .cvsignore, 1.2, 1.3 sources, 1.2, 1.3 tracker.spec, 1.2, 1.3 trackerd.desktop, 1.1, NONE In-Reply-To: <200611210744.kAL7iTIh008901@cvs-int.fedora.redhat.com> References: <200611210744.kAL7iTIh008901@cvs-int.fedora.redhat.com> Message-ID: <1164096227.7666.3.camel@mccallum.corsepiu.local> On Tue, 2006-11-21 at 02:44 -0500, Deji Akingunola wrote: > Author: deji > > Update of /cvs/extras/rpms/tracker/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv8820/devel > tracker-desktop.patch: > > --- NEW FILE tracker-desktop.patch --- > --- Makefile.in 2006-11-20 13:34:48.000000000 -0500 > +++ Makefile.in.new 2006-11-20 21:21:11.000000000 -0500 You are patching a generated file, without providing the sources. Ralf From dakingun at gmail.com Tue Nov 21 08:24:49 2006 From: dakingun at gmail.com (Deji Akingunola) Date: Tue, 21 Nov 2006 03:24:49 -0500 Subject: rpms/tracker/devel tracker-desktop.patch, NONE, 1.1 .cvsignore, 1.2, 1.3 sources, 1.2, 1.3 tracker.spec, 1.2, 1.3 trackerd.desktop, 1.1, NONE In-Reply-To: <1164096227.7666.3.camel@mccallum.corsepiu.local> References: <200611210744.kAL7iTIh008901@cvs-int.fedora.redhat.com> <1164096227.7666.3.camel@mccallum.corsepiu.local> Message-ID: On 11/21/06, Ralf Corsepius wrote: > On Tue, 2006-11-21 at 02:44 -0500, Deji Akingunola wrote: > > Author: deji > > > > Update of /cvs/extras/rpms/tracker/devel > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv8820/devel > > > tracker-desktop.patch: > > > > --- NEW FILE tracker-desktop.patch --- > > --- Makefile.in 2006-11-20 13:34:48.000000000 -0500 > > +++ Makefile.in.new 2006-11-20 21:21:11.000000000 -0500 > > You are patching a generated file, without providing the sources. > Whoops, I've long been under the impression the ./configure doesn't touch the Makefile.am, that only ./autogen.sh does. I've just satisfied myself I was wrong. Correct patch to Makefile.am has been sent to upstream and should be corrected in the next update. Deji From dakingun at gmail.com Tue Nov 21 09:08:45 2006 From: dakingun at gmail.com (Deji Akingunola) Date: Tue, 21 Nov 2006 04:08:45 -0500 Subject: rpms/tracker/devel tracker-desktop.patch, NONE, 1.1 .cvsignore, 1.2, 1.3 sources, 1.2, 1.3 tracker.spec, 1.2, 1.3 trackerd.desktop, 1.1, NONE In-Reply-To: References: <200611210744.kAL7iTIh008901@cvs-int.fedora.redhat.com> <1164096227.7666.3.camel@mccallum.corsepiu.local> Message-ID: On 11/21/06, Deji Akingunola wrote: > On 11/21/06, Ralf Corsepius wrote: > > On Tue, 2006-11-21 at 02:44 -0500, Deji Akingunola wrote: > > > Author: deji > > > > > > Update of /cvs/extras/rpms/tracker/devel > > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv8820/devel > > > > > tracker-desktop.patch: > > > > > > --- NEW FILE tracker-desktop.patch --- > > > --- Makefile.in 2006-11-20 13:34:48.000000000 -0500 > > > +++ Makefile.in.new 2006-11-20 21:21:11.000000000 -0500 > > > > You are patching a generated file, without providing the sources. > > > Whoops, I've long been under the impression the ./configure doesn't > touch the Makefile.am, that only ./autogen.sh does. I've just > satisfied myself I was wrong. Correct patch to Makefile.am has been > sent to upstream and should be corrected in the next update. > Spoke too soon, patching Makefile.am doesn't work on FC-6; so how am I suppose to achieve what I want to do here without patching the generated Makefile.in? run ./autogen.sh in the spec file? > Deji > From jansen at strw.leidenuniv.nl Tue Nov 21 09:20:13 2006 From: jansen at strw.leidenuniv.nl (David Jansen) Date: Tue, 21 Nov 2006 10:20:13 +0100 Subject: Bug in agrep (x86_64); no bugzilla category Message-ID: <20061121092013.GA12328@strw.leidenuniv.nl> I found a bug in agrep, FC5 x86_64 version, it produces different results than the same invocation on i686 on the same plain text file. However, agrep is not listed in the bugzilla components of Fedora Extras. Where do I file the bug, or how do I request a bugzilla entry for this package? As for the bug: I was looking for info on the network hardware of all our computers and used this query: agrep -d'$-$' 'class: NETWORK' /etc/sysconfig/hwconf It should cut the file in parts separated by lines with just a - on it, and that's just what it does on i686; the x86_64 version finds no matching delimiters so it outputs the whole file (oh, btw, it's not a difference in how hwconf is structured, problem can be reproduced with any text file) David Jansen From rc040203 at freenet.de Tue Nov 21 09:20:43 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 21 Nov 2006 10:20:43 +0100 Subject: rpms/tracker/devel tracker-desktop.patch, NONE, 1.1 .cvsignore, 1.2, 1.3 sources, 1.2, 1.3 tracker.spec, 1.2, 1.3 trackerd.desktop, 1.1, NONE In-Reply-To: References: <200611210744.kAL7iTIh008901@cvs-int.fedora.redhat.com> <1164096227.7666.3.camel@mccallum.corsepiu.local> Message-ID: <1164100843.7666.11.camel@mccallum.corsepiu.local> On Tue, 2006-11-21 at 04:08 -0500, Deji Akingunola wrote: > On 11/21/06, Deji Akingunola wrote: > > On 11/21/06, Ralf Corsepius wrote: > > > On Tue, 2006-11-21 at 02:44 -0500, Deji Akingunola wrote: > > > > Author: deji > > > > > > > > Update of /cvs/extras/rpms/tracker/devel > > > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv8820/devel > > > > > > > tracker-desktop.patch: > > > > > > > > --- NEW FILE tracker-desktop.patch --- > > > > --- Makefile.in 2006-11-20 13:34:48.000000000 -0500 > > > > +++ Makefile.in.new 2006-11-20 21:21:11.000000000 -0500 > > > > > > You are patching a generated file, without providing the sources. > > > > > Whoops, I've long been under the impression the ./configure doesn't > > touch the Makefile.am, that only ./autogen.sh does. I've just > > satisfied myself I was wrong. Correct patch to Makefile.am has been > > sent to upstream and should be corrected in the next update. > > > Spoke too soon, patching Makefile.am doesn't work on FC-6; What doesn't work? > so how am I > suppose to achieve what I want to do here without patching the > generated Makefile.in? In an ideal world you would patch both Makefile.am and Makefile.in and not be running any of the autotools inside of the spec. > run ./autogen.sh in the spec file? Forget about autogen.sh - It's a helper script and actually should not be used at all during building, unless you exactly know what you are doing. Ralf From bugs.michael at gmx.net Tue Nov 21 09:35:39 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 21 Nov 2006 10:35:39 +0100 Subject: Bug in agrep (x86_64); no bugzilla category In-Reply-To: <20061121092013.GA12328@strw.leidenuniv.nl> References: <20061121092013.GA12328@strw.leidenuniv.nl> Message-ID: <20061121103539.0d9c9266.bugs.michael@gmx.net> On Tue, 21 Nov 2006 10:20:13 +0100, David Jansen wrote: > I found a bug in agrep, FC5 x86_64 version, it produces different results > than the same invocation on i686 on the same plain text file. > However, agrep is not listed in the bugzilla components of Fedora > Extras. agrep is not in Fedora Extras. From dominik at greysector.net Tue Nov 21 10:19:15 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 21 Nov 2006 11:19:15 +0100 Subject: Bug in agrep (x86_64); no bugzilla category In-Reply-To: <20061121103539.0d9c9266.bugs.michael@gmx.net> References: <20061121092013.GA12328@strw.leidenuniv.nl> <20061121103539.0d9c9266.bugs.michael@gmx.net> Message-ID: <20061121101915.GA28531@rathann.pekin.waw.pl> On Tuesday, 21 November 2006 at 10:35, Michael Schwendt wrote: > On Tue, 21 Nov 2006 10:20:13 +0100, David Jansen wrote: > > > I found a bug in agrep, FC5 x86_64 version, it produces different results > > than the same invocation on i686 on the same plain text file. > > However, agrep is not listed in the bugzilla components of Fedora > > Extras. > > agrep is not in Fedora Extras. Of course it is. Look at what SRPM it is built from. ;) Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From bugs.michael at gmx.net Tue Nov 21 11:06:15 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 21 Nov 2006 12:06:15 +0100 Subject: Bug in agrep (x86_64); no bugzilla category In-Reply-To: <20061121101915.GA28531@rathann.pekin.waw.pl> References: <20061121092013.GA12328@strw.leidenuniv.nl> <20061121103539.0d9c9266.bugs.michael@gmx.net> <20061121101915.GA28531@rathann.pekin.waw.pl> Message-ID: <20061121120615.68863348.bugs.michael@gmx.net> On Tue, 21 Nov 2006 11:19:15 +0100, Dominik 'Rathann' Mierzejewski wrote: > On Tuesday, 21 November 2006 at 10:35, Michael Schwendt wrote: > > On Tue, 21 Nov 2006 10:20:13 +0100, David Jansen wrote: > > > > > I found a bug in agrep, FC5 x86_64 version, it produces different results > > > than the same invocation on i686 on the same plain text file. > > > However, agrep is not listed in the bugzilla components of Fedora > > > Extras. > > > > agrep is not in Fedora Extras. > > Of course it is. Look at what SRPM it is built from. ;) So? $ cvs co agrep For more information on using the Fedora source code repositories, please visit http://fedoraproject.org/wiki/UsingCvs --- cvs server: cannot find module `agrep' - ignored cvs [checkout aborted]: cannot expand modules $ cd owners/ $ grep agrep owners.list $ From giallu at gmail.com Tue Nov 21 11:17:53 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 21 Nov 2006 12:17:53 +0100 Subject: Bug in agrep (x86_64); no bugzilla category In-Reply-To: <20061121120615.68863348.bugs.michael@gmx.net> References: <20061121092013.GA12328@strw.leidenuniv.nl> <20061121103539.0d9c9266.bugs.michael@gmx.net> <20061121101915.GA28531@rathann.pekin.waw.pl> <20061121120615.68863348.bugs.michael@gmx.net> Message-ID: On 11/21/06, Michael Schwendt wrote: > On Tue, 21 Nov 2006 11:19:15 +0100, Dominik 'Rathann' Mierzejewski wrote: > > > On Tuesday, 21 November 2006 at 10:35, Michael Schwendt wrote: > > > On Tue, 21 Nov 2006 10:20:13 +0100, David Jansen wrote: > > > > > > > I found a bug in agrep, FC5 x86_64 version, it produces different results > > > > than the same invocation on i686 on the same plain text file. > > > > However, agrep is not listed in the bugzilla components of Fedora > > > > Extras. > > > > > > agrep is not in Fedora Extras. > > > > Of course it is. Look at what SRPM it is built from. ;) > > So? > I think he is referring to the "tre" SRPM package: however, I'm not sure what's the command to determine from what SRPM a given RPM is built from... From mtasaka at ioa.s.u-tokyo.ac.jp Tue Nov 21 11:21:54 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 21 Nov 2006 20:21:54 +0900 Subject: Bug in agrep (x86_64); no bugzilla category In-Reply-To: References: <20061121092013.GA12328@strw.leidenuniv.nl> <20061121103539.0d9c9266.bugs.michael@gmx.net> <20061121101915.GA28531@rathann.pekin.waw.pl> <20061121120615.68863348.bugs.michael@gmx.net> Message-ID: <4562E152.2080601@ioa.s.u-tokyo.ac.jp> Gianluca Sforna wrote: > On 11/21/06, Michael Schwendt wrote: >> On Tue, 21 Nov 2006 11:19:15 +0100, Dominik 'Rathann' Mierzejewski wrote: >> >> > On Tuesday, 21 November 2006 at 10:35, Michael Schwendt wrote: >> > > On Tue, 21 Nov 2006 10:20:13 +0100, David Jansen wrote: >> > > >> > > > I found a bug in agrep, FC5 x86_64 version, >> > > >> > > agrep is not in Fedora Extras. >> > >> > Of course it is. Look at what SRPM it is built from. ;) >> >> So? > I think he is referring to the "tre" SRPM package: however, I'm not > sure what's the command to determine from what SRPM a given RPM is > built from... > As Gianluca said, agrep is rebuilt from tre, so a bug report should be filed against tre component (if any). You can simply check the original srpm by 'rpm -qi agrep'. Mamoru Tasaka From bugs.michael at gmx.net Tue Nov 21 12:08:02 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 21 Nov 2006 13:08:02 +0100 Subject: Bug in agrep (x86_64); no bugzilla category In-Reply-To: References: <20061121092013.GA12328@strw.leidenuniv.nl> <20061121103539.0d9c9266.bugs.michael@gmx.net> <20061121101915.GA28531@rathann.pekin.waw.pl> <20061121120615.68863348.bugs.michael@gmx.net> Message-ID: <20061121130802.87a58b71.bugs.michael@gmx.net> On Tue, 21 Nov 2006 12:17:53 +0100, Gianluca Sforna wrote: > > On Tue, 21 Nov 2006 11:19:15 +0100, Dominik 'Rathann' Mierzejewski wrote: > > > > > On Tuesday, 21 November 2006 at 10:35, Michael Schwendt wrote: > > > > On Tue, 21 Nov 2006 10:20:13 +0100, David Jansen wrote: > > > > > > > > > I found a bug in agrep, FC5 x86_64 version, it produces different results > > > > > than the same invocation on i686 on the same plain text file. > > > > > However, agrep is not listed in the bugzilla components of Fedora > > > > > Extras. > > > > > > > > agrep is not in Fedora Extras. > > > > > > Of course it is. Look at what SRPM it is built from. ;) > > > > So? > > > > I think he is referring to the "tre" SRPM package: however, I'm not > sure what's the command to determine from what SRPM a given RPM is > built from... Aha, that's not the original and famous http://en.wikipedia.org/wiki/Agrep which has an incompatible license. From ndbecker2 at gmail.com Tue Nov 21 12:42:02 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 21 Nov 2006 07:42:02 -0500 Subject: Status of any effort to get Scipy into Extras? References: <604aa7910611201701t3f7620c8lbb3a0473aecc958a@mail.gmail.com> <1164082306.25587.3.camel@chronos.wilsonet.com> <604aa7910611202028h57bc2d9buac4de6650ab53713@mail.gmail.com> <604aa7910611202159n6971dba7we6c4ec08e7ca7e9b@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > On 11/20/06, Jeff Spaleta > wrote: >> Also there appears to be an issue with the current matplotlib in >> Extras which is fixed if we update to matplotlib release 0.87.7. I >> need to dig up my bugzilla password so I can file about that. > > > Okay I've spun up 0.87.7 srpm of matplotlib, and pinged the current > maintainer about it and asked if he would like a co-maintainer. > > Now I need to poke Neal and see if we can get scipy into > extras-development and then into fe6. > Sure Jeff. Go ahead. Do you have something I can test? From denis at poolshark.org Tue Nov 21 13:49:02 2006 From: denis at poolshark.org (Denis Leroy) Date: Tue, 21 Nov 2006 14:49:02 +0100 Subject: Brasero dependencies In-Reply-To: <45610673.4000801@fedoraproject.org> References: <4560EFB9.6080006@fedoraproject.org> <4561044C.5000003@poolshark.org> <45610673.4000801@fedoraproject.org> Message-ID: <456303CE.7040801@poolshark.org> Rahul Sundaram wrote: > Would it be possible to split the playsupport library from Totem? It > doesnt seem right to require a particular video player for a CD burning > application. > I am talking about when a user doesnt install Beagle and installs > Brasero. Can it support tracker? Not technically, there is no plugin concept or run-time dependency detection at this point, but I'll pass the message upstream. Brasero is meant to be tightly integrated with Gnome, so what you see as a CD burning application requiring a video player, I see as a well-integrated Gnome application requiring core Gnome components (such as media player and search service) to function correctly. It just so happens that totem and beagle are the current Gnome defauls of said components (and installed by default as well), though of course that might change in the future with the maturation of the tracker project. I do agree things would be simpler if brasero were able to do run-time detection of these components, but I'm not even sure that's technically possible right now. From wtogami at redhat.com Tue Nov 21 15:32:10 2006 From: wtogami at redhat.com (Warren Togami) Date: Tue, 21 Nov 2006 10:32:10 -0500 Subject: CVS Restored, Help Needed in Verification Message-ID: <45631BFA.4030800@redhat.com> Sometime Early Friday, November 17th we suffered some kind of catastrophic multi-disk or SCSI backplane failure accompanied with filesystem corruption in cvs.fedora.redhat.com. Thanks to volunteer efforts of Fedora Infrastructure and tremendous help from Red Hat IS/IT, we are now nearing restoration of cvs.fedora.redhat.com from a backup on a powerful new server graciously donated by Dell. We are restoring from a backup that began November 16th, 2006 at 8:01PM MST (Friday, November 17, 2006 at 03:01) and finished 100 minutes later. Because this backup is not an exact snapshot, it is possible that checkins that happened after 8:01PM are already in the restored data. https://www.redhat.com/archives/fedora-extras-commits/2006-November/date.html We require your help to verify that all checkins are properly in /cvs/extras and everything generally is working as expected. Please pay careful attention to everything that changed in November 16th and 17th according to the mailing list archive. My personal records indicate that no CVS imports happened after this backup, so we are fine in that regard. PACKAGE OWNERS - especially kevin, corsepiu, remi and qspencer are to verify and fix their own CVS modules, or explicitly identify someone else to do it on their behalf. EVERYONE ELSE - please keep an eye on CVS. SCREAM LOUDLY on fedora-extras-list if you see anything that is wrong. Sorry about any inconvenience or disruption that this unexpected problem may have caused. Everyone owes a beer to the Fedora Infrastructure and Red Hat IS/IT teams. =) Thank you for supporting the Fedora Project. Warren Togami wtogami at redhat.com From chris.stone at gmail.com Tue Nov 21 15:41:57 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 21 Nov 2006 07:41:57 -0800 Subject: CVS Restored, Help Needed in Verification In-Reply-To: <45631BFA.4030800@redhat.com> References: <45631BFA.4030800@redhat.com> Message-ID: I could have sworn I put in a cvssync request in for two of my packages: * FC-5 FC-6 php-pear-Structures-DataGrid-Renderer-Pager 212898 * FC-5 FC-6 php-pear-Structures-DataGrid-Renderer-Smarty 212900 However the new directories did not show up. I cannot be 100% certain I requested to sync these, but I usually add a package to the sync page immediately after it builds on devel. Anyway, not a big deal, I re-requested the syncing of these packages, but thought I would let you know about it since you want to know if anything looks amiss with cvs. On 11/21/06, Warren Togami wrote: > Sometime Early Friday, November 17th we suffered some kind of > catastrophic multi-disk or SCSI backplane failure accompanied with > filesystem corruption in cvs.fedora.redhat.com. Thanks to volunteer > efforts of Fedora Infrastructure and tremendous help from Red Hat IS/IT, > we are now nearing restoration of cvs.fedora.redhat.com from a backup on > a powerful new server graciously donated by Dell. > > We are restoring from a backup that began November 16th, 2006 at 8:01PM > MST (Friday, November 17, 2006 at 03:01) and finished 100 minutes later. > Because this backup is not an exact snapshot, it is possible that > checkins that happened after 8:01PM are already in the restored data. > > https://www.redhat.com/archives/fedora-extras-commits/2006-November/date.html > We require your help to verify that all checkins are properly in > /cvs/extras and everything generally is working as expected. Please pay > careful attention to everything that changed in November 16th and 17th > according to the mailing list archive. > > My personal records indicate that no CVS imports happened after this > backup, so we are fine in that regard. > > PACKAGE OWNERS - especially kevin, corsepiu, remi and qspencer are to > verify and fix their own CVS modules, or explicitly identify someone > else to do it on their behalf. > > EVERYONE ELSE - please keep an eye on CVS. SCREAM LOUDLY on > fedora-extras-list if you see anything that is wrong. > > Sorry about any inconvenience or disruption that this unexpected problem > may have caused. Everyone owes a beer to the Fedora Infrastructure and > Red Hat IS/IT teams. =) > > Thank you for supporting the Fedora Project. > > Warren Togami > wtogami at redhat.com > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From rc040203 at freenet.de Tue Nov 21 15:47:51 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 21 Nov 2006 16:47:51 +0100 Subject: CVS Restored, Help Needed in Verification In-Reply-To: <45631BFA.4030800@redhat.com> References: <45631BFA.4030800@redhat.com> Message-ID: <1164124071.5059.47.camel@mccallum.corsepiu.local> On Tue, 2006-11-21 at 10:32 -0500, Warren Togami wrote: > PACKAGE OWNERS - especially kevin, corsepiu, remi and qspencer are to > verify and fix their own CVS modules, or explicitly identify someone > else to do it on their behalf. AFAICT, everything seems to be OK with my packages. Ralf From bugs.michael at gmx.net Tue Nov 21 16:05:38 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 21 Nov 2006 17:05:38 +0100 Subject: CVS Restored, Help Needed in Verification In-Reply-To: References: <45631BFA.4030800@redhat.com> Message-ID: <20061121170538.ac089698.bugs.michael@gmx.net> On Tue, 21 Nov 2006 07:41:57 -0800, Christopher Stone wrote: > I could have sworn I put in a cvssync request in for two of my packages: > * FC-5 FC-6 php-pear-Structures-DataGrid-Renderer-Pager 212898 > * FC-5 FC-6 php-pear-Structures-DataGrid-Renderer-Smarty 212900 > > However the new directories did not show up. I cannot be 100% certain > I requested to sync these, See here, 2006-11-16, #2229 and #2230: http://fedoraproject.org/wiki/Extras/CVSSyncNeeded?action=diff&rev2=2230&rev1=2228 http://fedoraproject.org/wiki/Extras/CVSSyncNeeded?action=info From jspaleta at gmail.com Tue Nov 21 18:22:48 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 21 Nov 2006 09:22:48 -0900 Subject: Status of any effort to get Scipy into Extras? In-Reply-To: References: <604aa7910611201701t3f7620c8lbb3a0473aecc958a@mail.gmail.com> <1164082306.25587.3.camel@chronos.wilsonet.com> <604aa7910611202028h57bc2d9buac4de6650ab53713@mail.gmail.com> <604aa7910611202159n6971dba7we6c4ec08e7ca7e9b@mail.gmail.com> Message-ID: <604aa7910611211022m590a83cha3d7ad34219585e6@mail.gmail.com> On 11/21/06, Neal Becker wrote: > Sure Jeff. Go ahead. Do you have something I can test? Not yet, i will most likely be working on packaging of scipy tonite or tomorrow. Do you have a srpm I can start from? -jef From buildsys at fedoraproject.org Tue Nov 21 18:33:36 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 21 Nov 2006 13:33:36 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-21 Message-ID: <20061121183336.0473415212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 22 chemtool-1.6.9-5.fc7 glom-1.2.1-2.fc7 gnome-translate-0.99-11.fc7 jd-1.8.1-0.1.cvs061120.fc7 libEMF-1.0.3-3.fc7 libpng10-1.0.21-1.fc7 mirage-0.8.1-1.fc7 mod_revocator-1.0.2-1.fc7 ochusha-0.5.99.63.5-0.1.cvs061120.fc7 perl-YAML-Parser-Syck-0.01-7.fc7 php-pear-DB-DataObject-1.8.4-2.fc7 php-pear-DB-DataObject-FormBuilder-1.0.0-0.1.RC5.fc7 php-pear-Structures-DataGrid-DataSource-DataObject-0.1.0-1.fc7 proftpd-1.3.0-10.fc7 python-matplotlib-0.87.7-1.fc7 quodlibet-0.24-1.fc7 stratagus-2.1-11.fc7 sysprof-1.0.7-1.fc7 sysprof-kmod-1.0.7-1.1.2.6.18_1.2849.fc6 tracker-0.5.2-1.fc7 xscreensaver-5.01-5.fc7 xsupplicant-1.2.8-1.fc7.1 Packages built and released for Fedora Extras 6: 17 glom-1.2.1-2.fc6 gnome-translate-0.99-11.fc6 gossip-0.19-1.fc6 libpng10-1.0.21-1.fc6 lilypond-doc-2.10.0-1.fc6 mod_revocator-1.0.2-1.fc6 perl-YAML-Parser-Syck-0.01-7.fc6 php-pear-HTML-QuickForm-3.2.7-2.fc6 quodlibet-0.24-1.fc6 rocksndiamonds-3.2.2-3.fc6 stratagus-2.1-11.fc6 sylpheed-2.2.10-1.fc6.1 sysprof-1.0.7-1.fc6 sysprof-kmod-1.0.7-1.2.6.18_1.2849.fc6 tracker-0.5.2-1.fc6.1 xscreensaver-5.01-5.fc6 xsupplicant-1.2.8-1.fc6.1 Packages built and released for Fedora Extras 5: 12 Invalid rebuild: nagios-2.5-2.fc5 glom-1.2.1-1.fc5 gnome-translate-0.99-11.fc5 mod_revocator-1.0.2-1.fc5 perl-YAML-Parser-Syck-0.01-7.fc5 php-pear-HTML-QuickForm-3.2.7-2.fc5 quodlibet-0.24-1.fc5 rocksndiamonds-3.2.2-3.fc5 stratagus-2.1-11.fc5 sylpheed-2.2.10-1.fc5 tracker-0.5.2-1.fc5 xsupplicant-1.2.8-1.fc5.1 Packages built and released for Fedora Extras 4: 3 rocksndiamonds-3.2.2-2.fc4 stratagus-2.1-11.fc4 xsupplicant-1.2.8-1.fc4.1 Packages built and released for Fedora Extras 3: 0 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From ndbecker2 at gmail.com Tue Nov 21 18:41:36 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 21 Nov 2006 13:41:36 -0500 Subject: Status of any effort to get Scipy into Extras? References: <604aa7910611201701t3f7620c8lbb3a0473aecc958a@mail.gmail.com> <1164082306.25587.3.camel@chronos.wilsonet.com> <604aa7910611202028h57bc2d9buac4de6650ab53713@mail.gmail.com> <604aa7910611202159n6971dba7we6c4ec08e7ca7e9b@mail.gmail.com> <604aa7910611211022m590a83cha3d7ad34219585e6@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > On 11/21/06, Neal Becker > wrote: >> Sure Jeff. Go ahead. Do you have something I can test? > > Not yet, i will most likely be working on packaging of scipy tonite or > tomorrow. Do you have a srpm I can start from? > > -jef > http://nbecker.dyndns.org:8080/RPM/scipy-0.5.1-1.src.rpm From jmp at safe.ca Tue Nov 21 19:02:33 2006 From: jmp at safe.ca (Jean-Marc Pigeon) Date: Tue, 21 Nov 2006 14:02:33 -0500 Subject: Pirut/yum/rpm application group assignation In-Reply-To: <4562E152.2080601@ioa.s.u-tokyo.ac.jp> References: <20061121092013.GA12328@strw.leidenuniv.nl> <20061121103539.0d9c9266.bugs.michael@gmx.net> <20061121101915.GA28531@rathann.pekin.waw.pl> <20061121120615.68863348.bugs.michael@gmx.net> <4562E152.2080601@ioa.s.u-tokyo.ac.jp> Message-ID: <1164135753.18723.24.camel@Montreal.safe.ca> Bonjour a Tous, Worked on FC6 today (a fresh install) and used package update. Pirut found clamav within server -> mail server (this is logical), my worry is clement application (my pet project), which should be side by side with clamav|sendmail|exim. Spec file for clement say "Group: System Environment/Daemons", same as sendmail while clamav is set to "Group: Applications/File" Could somebody tell me how pirut/yum assign the application group?? Is there a liste somewhere to be updated? -- A bient?t ========================================================================== Jean-Marc Pigeon Internet: jmp at safe.ca SAFE Inc. Phone: (514) 493-4280 Fax: (514) 493-1946 Clement, 'a kiss solution' to get rid of SPAM (at last) Clement' Home base <"http://www.clement.safe.ca"> ========================================================================== From jkeating at redhat.com Tue Nov 21 19:12:23 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 21 Nov 2006 14:12:23 -0500 Subject: Pirut/yum/rpm application group assignation In-Reply-To: <1164135753.18723.24.camel@Montreal.safe.ca> References: <20061121092013.GA12328@strw.leidenuniv.nl> <4562E152.2080601@ioa.s.u-tokyo.ac.jp> <1164135753.18723.24.camel@Montreal.safe.ca> Message-ID: <200611211412.23290.jkeating@redhat.com> On Tuesday 21 November 2006 14:02, Jean-Marc Pigeon wrote: > ????????Could somebody tell me how pirut/yum assign the application > ????????group?? ?Is there a liste somewhere to be updated? The comps file for Extras is the real location of group assignments. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Home at TimAliBentley.org.uk Tue Nov 21 19:17:40 2006 From: Home at TimAliBentley.org.uk (Tim and Alison Bentley) Date: Tue, 21 Nov 2006 19:17:40 +0000 Subject: MonoDevelop 0.12-7.fc6 In-Reply-To: <1164065963.31552.58.camel@T7.Linux> References: <4562047B.2030300@TimAliBentley.org.uk> <1164065963.31552.58.camel@T7.Linux> Message-ID: <456350D4.4040106@TimAliBentley.org.uk> An HTML attachment was scrubbed... URL: From jmp at safe.ca Tue Nov 21 19:19:00 2006 From: jmp at safe.ca (Jean-Marc Pigeon) Date: Tue, 21 Nov 2006 14:19:00 -0500 Subject: Pirut/yum/rpm application group assignation In-Reply-To: <200611211412.23290.jkeating@redhat.com> References: <20061121092013.GA12328@strw.leidenuniv.nl> <4562E152.2080601@ioa.s.u-tokyo.ac.jp> <1164135753.18723.24.camel@Montreal.safe.ca> <200611211412.23290.jkeating@redhat.com> Message-ID: <1164136740.18723.26.camel@Montreal.safe.ca> On Tue, 2006-11-21 at 14:12 -0500, Jesse Keating wrote: > On Tuesday 21 November 2006 14:02, Jean-Marc Pigeon wrote: > > Could somebody tell me how pirut/yum assign the application > > group?? Is there a liste somewhere to be updated? > > The comps file for Extras is the real location of group assignments. Sorry, unable to understand the answer... what is the "comps file"? > -- A bient?t ========================================================================== Jean-Marc Pigeon Internet: jmp at safe.ca SAFE Inc. Phone: (514) 493-4280 Fax: (514) 493-1946 Clement, 'a kiss solution' to get rid of SPAM (at last) Clement' Home base <"http://www.clement.safe.ca"> ========================================================================== From mattdm at mattdm.org Tue Nov 21 19:23:23 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 21 Nov 2006 14:23:23 -0500 Subject: Pirut/yum/rpm application group assignation In-Reply-To: <1164135753.18723.24.camel@Montreal.safe.ca> References: <20061121092013.GA12328@strw.leidenuniv.nl> <20061121103539.0d9c9266.bugs.michael@gmx.net> <20061121101915.GA28531@rathann.pekin.waw.pl> <20061121120615.68863348.bugs.michael@gmx.net> <4562E152.2080601@ioa.s.u-tokyo.ac.jp> <1164135753.18723.24.camel@Montreal.safe.ca> Message-ID: <20061121192323.GA24613@jadzia.bu.edu> On Tue, Nov 21, 2006 at 02:02:33PM -0500, Jean-Marc Pigeon wrote: > Spec file for clement say "Group: System Environment/Daemons", > same as sendmail while clamav is set to "Group: > Applications/File" Someday, my dream of killing all use of the Group tag in Fedora spec files will come to pass.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Tue Nov 21 19:27:27 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 21 Nov 2006 14:27:27 -0500 Subject: MonoDevelop 0.12-7.fc6 In-Reply-To: <456350D4.4040106@TimAliBentley.org.uk> References: <4562047B.2030300@TimAliBentley.org.uk> <1164065963.31552.58.camel@T7.Linux> <456350D4.4040106@TimAliBentley.org.uk> Message-ID: <200611211427.27190.jkeating@redhat.com> On Tuesday 21 November 2006 14:17, Tim and Alison Bentley wrote: > > I can't even begin to read this message. The quoting seems to be done with positional indents of one kind or another, there is no plain text part, I have no idea where the actual author's text is, etc.. Please consider using a sane mail client instead of whatever garbage produced this email. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Nov 21 19:28:46 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 21 Nov 2006 14:28:46 -0500 Subject: Pirut/yum/rpm application group assignation In-Reply-To: <1164136740.18723.26.camel@Montreal.safe.ca> References: <20061121092013.GA12328@strw.leidenuniv.nl> <200611211412.23290.jkeating@redhat.com> <1164136740.18723.26.camel@Montreal.safe.ca> Message-ID: <200611211428.47039.jkeating@redhat.com> On Tuesday 21 November 2006 14:19, Jean-Marc Pigeon wrote: > ????????Sorry, unable to understand the answer... > ????????what is the "comps file"? http://fedoraproject.org/wiki/Extras/CompsXml Which is returned by a simple search of "comps" in the wiki. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeff at ocjtech.us Tue Nov 21 19:34:38 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 21 Nov 2006 13:34:38 -0600 Subject: MonoDevelop 0.12-7.fc6 In-Reply-To: <200611211427.27190.jkeating@redhat.com> References: <4562047B.2030300@TimAliBentley.org.uk> <1164065963.31552.58.camel@T7.Linux> <456350D4.4040106@TimAliBentley.org.uk> <200611211427.27190.jkeating@redhat.com> Message-ID: <1164137678.3369.6.camel@lt21223.campus.dmacc.edu> On Tue, 2006-11-21 at 14:27 -0500, Jesse Keating wrote: > On Tuesday 21 November 2006 14:17, Tim and Alison Bentley wrote: > > > > > > I can't even begin to read this message. The quoting seems to be done with > positional indents of one kind or another, there is no plain text part, I > have no idea where the actual author's text is, etc.. Please consider using > a sane mail client instead of whatever garbage produced this email. Thunderbird isn't a sane mail client? > > User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jmp at safe.ca Tue Nov 21 19:35:16 2006 From: jmp at safe.ca (Jean-Marc Pigeon) Date: Tue, 21 Nov 2006 14:35:16 -0500 Subject: Pirut/yum/rpm application group assignation In-Reply-To: <200611211428.47039.jkeating@redhat.com> References: <20061121092013.GA12328@strw.leidenuniv.nl> <200611211412.23290.jkeating@redhat.com> <1164136740.18723.26.camel@Montreal.safe.ca> <200611211428.47039.jkeating@redhat.com> Message-ID: <1164137716.18723.33.camel@Montreal.safe.ca> On Tue, 2006-11-21 at 14:28 -0500, Jesse Keating wrote: > On Tuesday 21 November 2006 14:19, Jean-Marc Pigeon wrote: > > Sorry, unable to understand the answer... > > what is the "comps file"? > > http://fedoraproject.org/wiki/Extras/CompsXml > > Which is returned by a simple search of "comps" in the wiki. Thanks... :-}} I figured it in the mid time, at first understood is was a part of the specs file not aware of.... :-}} 1/2'mean' question,.... as an application maintainer I am required to deliver an 'ultra-clean' specs file... why the comps file is not automatically build from the specs file "Group" field? > -- A bient?t ========================================================================== Jean-Marc Pigeon Internet: jmp at safe.ca SAFE Inc. Phone: (514) 493-4280 Fax: (514) 493-1946 Clement, 'a kiss solution' to get rid of SPAM (at last) Clement' Home base <"http://www.clement.safe.ca"> ========================================================================== From jkeating at redhat.com Tue Nov 21 19:38:24 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 21 Nov 2006 14:38:24 -0500 Subject: MonoDevelop 0.12-7.fc6 In-Reply-To: <1164137678.3369.6.camel@lt21223.campus.dmacc.edu> References: <4562047B.2030300@TimAliBentley.org.uk> <200611211427.27190.jkeating@redhat.com> <1164137678.3369.6.camel@lt21223.campus.dmacc.edu> Message-ID: <200611211438.24429.jkeating@redhat.com> On Tuesday 21 November 2006 14:34, Jeffrey C. Ollie wrote: > Thunderbird isn't a sane mail client? If it produces garbage like the post, I'd say no. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Tue Nov 21 19:43:49 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 21 Nov 2006 19:43:49 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-21 Message-ID: <20061121194349.7648.14893@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 (21 days) centericq - 4.21.0-8.fc6.ppc (21 days) centericq - 4.21.0-8.fc6.x86_64 (21 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (24 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (24 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (24 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (24 days) orange - 0.3-3.cvs20051118.fc6.i386 (28 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (52 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (52 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (52 days) dakingun AT gmail.com gparted - 0.3.1-1.fc6.i386 gparted - 0.3.1-1.fc6.ppc gparted - 0.3.1-1.fc6.x86_64 dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (67 days) plague - 0.4.4.1-2.fc3.noarch (67 days) plague - 0.4.4.1-2.fc4.noarch (67 days) plague - 0.4.4.1-2.fc4.noarch (67 days) plague - 0.4.4.1-2.fc4.noarch (67 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (43 days) linphone - 1.2.0-4.fc5.ppc (43 days) linphone - 1.2.0-4.fc5.x86_64 (43 days) jwilson AT redhat.com beryl - 0.1.2-5.fc6.i386 beryl - 0.1.2-5.fc6.ppc beryl - 0.1.2-5.fc6.x86_64 beryl - 0.1.2-5.fc7.i386 beryl - 0.1.2-5.fc7.ppc beryl - 0.1.2-5.fc7.x86_64 beryl-gnome - 0.1.2-5.fc6.i386 beryl-gnome - 0.1.2-5.fc6.ppc beryl-gnome - 0.1.2-5.fc6.x86_64 beryl-gnome - 0.1.2-5.fc7.i386 beryl-gnome - 0.1.2-5.fc7.ppc beryl-gnome - 0.1.2-5.fc7.x86_64 beryl-kde - 0.1.2-5.fc6.i386 beryl-kde - 0.1.2-5.fc6.ppc beryl-kde - 0.1.2-5.fc6.x86_64 beryl-kde - 0.1.2-5.fc7.i386 beryl-kde - 0.1.2-5.fc7.ppc beryl-kde - 0.1.2-5.fc7.x86_64 matthias AT rpmforge.net php-eaccelerator - 5.1.6_0.9.5-2.fc7.i386 (5 days) php-eaccelerator - 5.1.6_0.9.5-2.fc7.ppc (5 days) php-eaccelerator - 5.1.6_0.9.5-2.fc7.x86_64 (5 days) oliver AT linux-kernel.at syck-php - 0.55-10.fc6.i386 (5 days) syck-php - 0.55-10.fc6.ppc (5 days) syck-php - 0.55-10.fc6.x86_64 (5 days) syck-php - 0.55-9.fc5.i386 (33 days) syck-php - 0.55-9.fc5.ppc (33 days) syck-php - 0.55-9.fc5.x86_64 (33 days) pertusus AT free.fr grads - 1.9b4-19.fc7.i386 (5 days) grads - 1.9b4-19.fc7.ppc (5 days) grads - 1.9b4-19.fc7.x86_64 (5 days) petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 (18 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (18 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (18 days) ghc642-gtk2hs - 0.9.10-4.fc6.i386 (18 days) ghc642-gtk2hs - 0.9.10-4.fc6.ppc (18 days) ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 (18 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 (18 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc (18 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 (18 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (23 days) steve AT silug.org qtparted - 0.4.5-10.fc7.i386 qtparted - 0.4.5-10.fc7.ppc qtparted - 0.4.5-10.fc7.x86_64 Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- beryl-0.1.2-5.fc7.ppc requires bdock >= 0:0.1.2 beryl-gnome-0.1.2-5.fc7.ppc requires heliodor >= 0:0.1.2 beryl-gnome-0.1.2-5.fc7.ppc requires beryl-vidcap >= 0:0.1.2 beryl-gnome-0.1.2-5.fc7.ppc requires beryl-dbus >= 0:0.1.2 beryl-kde-0.1.2-5.fc7.ppc requires beryl-vidcap >= 0:0.1.2 beryl-kde-0.1.2-5.fc7.ppc requires aquamarine >= 0:0.1.2 centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 gparted-0.3.1-1.fc6.ppc requires libparted-1.7.so.1 grads-1.9b4-19.fc7.ppc requires wgrib libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 php-eaccelerator-5.1.6_0.9.5-2.fc7.ppc requires php-common = 0:5.1.6 qtparted-0.4.5-10.fc7.ppc requires libparted-1.7.so.1 syck-php-0.55-10.fc6.ppc requires php = 0:5.1.6 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- beryl-0.1.2-5.fc7.x86_64 requires bdock >= 0:0.1.2 beryl-gnome-0.1.2-5.fc7.x86_64 requires heliodor >= 0:0.1.2 beryl-gnome-0.1.2-5.fc7.x86_64 requires beryl-vidcap >= 0:0.1.2 beryl-gnome-0.1.2-5.fc7.x86_64 requires beryl-dbus >= 0:0.1.2 beryl-kde-0.1.2-5.fc7.x86_64 requires beryl-vidcap >= 0:0.1.2 beryl-kde-0.1.2-5.fc7.x86_64 requires aquamarine >= 0:0.1.2 centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 gparted-0.3.1-1.fc6.x86_64 requires libparted-1.7.so.1()(64bit) grads-1.9b4-19.fc7.x86_64 requires wgrib libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 php-eaccelerator-5.1.6_0.9.5-2.fc7.x86_64 requires php-common = 0:5.1.6 qtparted-0.4.5-10.fc7.x86_64 requires libparted-1.7.so.1()(64bit) syck-php-0.55-10.fc6.x86_64 requires php = 0:5.1.6 Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- beryl-0.1.2-5.fc7.i386 requires bdock >= 0:0.1.2 beryl-gnome-0.1.2-5.fc7.i386 requires heliodor >= 0:0.1.2 beryl-gnome-0.1.2-5.fc7.i386 requires beryl-vidcap >= 0:0.1.2 beryl-gnome-0.1.2-5.fc7.i386 requires beryl-dbus >= 0:0.1.2 beryl-kde-0.1.2-5.fc7.i386 requires beryl-vidcap >= 0:0.1.2 beryl-kde-0.1.2-5.fc7.i386 requires aquamarine >= 0:0.1.2 centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 gparted-0.3.1-1.fc6.i386 requires libparted-1.7.so.1 grads-1.9b4-19.fc7.i386 requires wgrib libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 php-eaccelerator-5.1.6_0.9.5-2.fc7.i386 requires php-common = 0:5.1.6 qtparted-0.4.5-10.fc7.i386 requires libparted-1.7.so.1 syck-php-0.55-10.fc6.i386 requires php = 0:5.1.6 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- beryl-0.1.2-5.fc6.ppc requires bdock >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.ppc requires beryl-plugins >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.ppc requires beryl-manager >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.ppc requires heliodor >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.ppc requires beryl-settings >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.ppc requires beryl-vidcap >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.ppc requires beryl-dbus >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.ppc requires emerald-themes >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.ppc requires emerald >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.ppc requires beryl-plugins >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.ppc requires beryl-manager >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.ppc requires beryl-settings >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.ppc requires beryl-vidcap >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.ppc requires emerald-themes >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.ppc requires aquamarine >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.ppc requires emerald >= 0:0.1.2 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- beryl-0.1.2-5.fc6.x86_64 requires bdock >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.x86_64 requires beryl-plugins >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.x86_64 requires beryl-manager >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.x86_64 requires heliodor >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.x86_64 requires beryl-settings >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.x86_64 requires beryl-vidcap >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.x86_64 requires beryl-dbus >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.x86_64 requires emerald-themes >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.x86_64 requires emerald >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.x86_64 requires beryl-plugins >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.x86_64 requires beryl-manager >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.x86_64 requires beryl-settings >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.x86_64 requires beryl-vidcap >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.x86_64 requires emerald-themes >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.x86_64 requires aquamarine >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.x86_64 requires emerald >= 0:0.1.2 Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- beryl-0.1.2-5.fc6.i386 requires bdock >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.i386 requires beryl-plugins >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.i386 requires beryl-manager >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.i386 requires heliodor >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.i386 requires beryl-settings >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.i386 requires beryl-vidcap >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.i386 requires beryl-dbus >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.i386 requires emerald-themes >= 0:0.1.2 beryl-gnome-0.1.2-5.fc6.i386 requires emerald >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.i386 requires beryl-plugins >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.i386 requires beryl-manager >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.i386 requires beryl-settings >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.i386 requires beryl-vidcap >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.i386 requires emerald-themes >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.i386 requires aquamarine >= 0:0.1.2 beryl-kde-0.1.2-5.fc6.i386 requires emerald >= 0:0.1.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: oliver AT linux-kernel.at package: syck-php - 0.55-9.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.4 package: syck-php - 0.55-9.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.4 package: syck-php - 0.55-9.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.4 ====================================================================== New report for: petersen AT redhat.com package: ghc642-gtk2hs - 0.9.10-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: /usr/bin/ghc-pkg-6.4.2 ghc642 package: ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: /usr/bin/ghc-pkg-6.4.2 ghc642 package: ghc-gtk2hs - 0.9.10-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: ghc = 0:6.4.2 package: ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: /usr/bin/ghc-pkg-6.4.2 ghc642 package: ghc-gtk2hs - 0.9.10-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: ghc = 0:6.4.2 package: ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: /usr/bin/ghc-pkg-6.4.2 ghc642 package: ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: /usr/bin/ghc-pkg-6.4.2 ghc642 package: ghc-gtk2hs - 0.9.10-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: ghc = 0:6.4.2 package: ghc642-gtk2hs - 0.9.10-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: /usr/bin/ghc-pkg-6.4.2 ghc642 ====================================================================== New report for: dakingun AT gmail.com package: gparted - 0.3.1-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libparted-1.7.so.1 package: gparted - 0.3.1-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libparted-1.7.so.1()(64bit) package: gparted - 0.3.1-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libparted-1.7.so.1 ====================================================================== New report for: jeff AT ocjtech.us package: linphone - 1.2.0-4.fc5.ppc from fedora-extras-5-ppc unresolved deps: libortp.so.2 package: linphone - 1.2.0-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libortp.so.2()(64bit) package: linphone - 1.2.0-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libortp.so.2 ====================================================================== New report for: steve AT silug.org package: qtparted - 0.4.5-10.fc7.ppc from fedora-extras-development-ppc unresolved deps: libparted-1.7.so.1 package: qtparted - 0.4.5-10.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libparted-1.7.so.1()(64bit) package: qtparted - 0.4.5-10.fc7.i386 from fedora-extras-development-i386 unresolved deps: libparted-1.7.so.1 ====================================================================== New report for: jwilson AT redhat.com package: beryl - 0.1.2-5.fc7.ppc from fedora-extras-development-ppc unresolved deps: bdock >= 0:0.1.2 package: beryl-kde - 0.1.2-5.fc7.ppc from fedora-extras-development-ppc unresolved deps: beryl-vidcap >= 0:0.1.2 aquamarine >= 0:0.1.2 package: beryl-gnome - 0.1.2-5.fc7.ppc from fedora-extras-development-ppc unresolved deps: heliodor >= 0:0.1.2 beryl-vidcap >= 0:0.1.2 beryl-dbus >= 0:0.1.2 package: beryl - 0.1.2-5.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: bdock >= 0:0.1.2 package: beryl-gnome - 0.1.2-5.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: heliodor >= 0:0.1.2 beryl-vidcap >= 0:0.1.2 beryl-dbus >= 0:0.1.2 package: beryl-kde - 0.1.2-5.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: beryl-vidcap >= 0:0.1.2 aquamarine >= 0:0.1.2 package: beryl-kde - 0.1.2-5.fc7.i386 from fedora-extras-development-i386 unresolved deps: beryl-vidcap >= 0:0.1.2 aquamarine >= 0:0.1.2 package: beryl - 0.1.2-5.fc7.i386 from fedora-extras-development-i386 unresolved deps: bdock >= 0:0.1.2 package: beryl-gnome - 0.1.2-5.fc7.i386 from fedora-extras-development-i386 unresolved deps: heliodor >= 0:0.1.2 beryl-vidcap >= 0:0.1.2 beryl-dbus >= 0:0.1.2 package: beryl-kde - 0.1.2-5.fc6.ppc from fedora-extras-6-ppc unresolved deps: beryl-plugins >= 0:0.1.2 beryl-manager >= 0:0.1.2 beryl-settings >= 0:0.1.2 beryl-vidcap >= 0:0.1.2 emerald-themes >= 0:0.1.2 aquamarine >= 0:0.1.2 emerald >= 0:0.1.2 package: beryl - 0.1.2-5.fc6.ppc from fedora-extras-6-ppc unresolved deps: bdock >= 0:0.1.2 package: beryl-gnome - 0.1.2-5.fc6.ppc from fedora-extras-6-ppc unresolved deps: beryl-plugins >= 0:0.1.2 beryl-manager >= 0:0.1.2 heliodor >= 0:0.1.2 beryl-settings >= 0:0.1.2 beryl-vidcap >= 0:0.1.2 beryl-dbus >= 0:0.1.2 emerald-themes >= 0:0.1.2 emerald >= 0:0.1.2 package: beryl-kde - 0.1.2-5.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: beryl-plugins >= 0:0.1.2 beryl-manager >= 0:0.1.2 beryl-settings >= 0:0.1.2 beryl-vidcap >= 0:0.1.2 emerald-themes >= 0:0.1.2 aquamarine >= 0:0.1.2 emerald >= 0:0.1.2 package: beryl - 0.1.2-5.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: bdock >= 0:0.1.2 package: beryl-gnome - 0.1.2-5.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: beryl-plugins >= 0:0.1.2 beryl-manager >= 0:0.1.2 heliodor >= 0:0.1.2 beryl-settings >= 0:0.1.2 beryl-vidcap >= 0:0.1.2 beryl-dbus >= 0:0.1.2 emerald-themes >= 0:0.1.2 emerald >= 0:0.1.2 package: beryl - 0.1.2-5.fc6.i386 from fedora-extras-6-i386 unresolved deps: bdock >= 0:0.1.2 package: beryl-kde - 0.1.2-5.fc6.i386 from fedora-extras-6-i386 unresolved deps: beryl-plugins >= 0:0.1.2 beryl-manager >= 0:0.1.2 beryl-settings >= 0:0.1.2 beryl-vidcap >= 0:0.1.2 emerald-themes >= 0:0.1.2 aquamarine >= 0:0.1.2 emerald >= 0:0.1.2 package: beryl-gnome - 0.1.2-5.fc6.i386 from fedora-extras-6-i386 unresolved deps: beryl-plugins >= 0:0.1.2 beryl-manager >= 0:0.1.2 heliodor >= 0:0.1.2 beryl-settings >= 0:0.1.2 beryl-vidcap >= 0:0.1.2 beryl-dbus >= 0:0.1.2 emerald-themes >= 0:0.1.2 emerald >= 0:0.1.2 From jkeating at redhat.com Tue Nov 21 19:47:07 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 21 Nov 2006 14:47:07 -0500 Subject: Pirut/yum/rpm application group assignation In-Reply-To: <1164137716.18723.33.camel@Montreal.safe.ca> References: <20061121092013.GA12328@strw.leidenuniv.nl> <200611211428.47039.jkeating@redhat.com> <1164137716.18723.33.camel@Montreal.safe.ca> Message-ID: <200611211447.07693.jkeating@redhat.com> On Tuesday 21 November 2006 14:35, Jean-Marc Pigeon wrote: > ????????why the comps file is not automatically build from > ????????the specs file "Group" field? Because the Group field has no real structure (its just text), has no concept of optional/default/manditory, there is no way to express a package may live in multiple groups, no way to conditional include packages (you select one language, and part of that language is KDE files for that language, but only include the KDE files if you've got KDE itself selected, etc... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jmp at safe.ca Tue Nov 21 19:53:00 2006 From: jmp at safe.ca (Jean-Marc Pigeon) Date: Tue, 21 Nov 2006 14:53:00 -0500 Subject: Pirut/yum/rpm application group assignation In-Reply-To: <200611211447.07693.jkeating@redhat.com> References: <20061121092013.GA12328@strw.leidenuniv.nl> <200611211428.47039.jkeating@redhat.com> <1164137716.18723.33.camel@Montreal.safe.ca> <200611211447.07693.jkeating@redhat.com> Message-ID: <1164138780.18723.41.camel@Montreal.safe.ca> On Tue, 2006-11-21 at 14:47 -0500, Jesse Keating wrote: > On Tuesday 21 November 2006 14:35, Jean-Marc Pigeon wrote: > > why the comps file is not automatically build from > > the specs file "Group" field? > > Because the Group field has no real structure (its just text), has no concept > of optional/default/manditory, there is no way to express a package may live > in multiple groups, no way to conditional include packages (you select one > language, and part of that language is KDE files for that language, but only > include the KDE files if you've got KDE itself selected, etc... Ok... Thanks Updated the comps.fe6 file... cvs didn't complained, lets wait and see... Many thanks for your help... > -- A bient?t ========================================================================== Jean-Marc Pigeon Internet: jmp at safe.ca SAFE Inc. Phone: (514) 493-4280 Fax: (514) 493-1946 Clement, 'a kiss solution' to get rid of SPAM (at last) Clement' Home base <"http://www.clement.safe.ca"> ========================================================================== From jwboyer at jdub.homelinux.org Tue Nov 21 20:08:18 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 21 Nov 2006 14:08:18 -0600 Subject: MonoDevelop 0.12-7.fc6 In-Reply-To: <200611211438.24429.jkeating@redhat.com> References: <4562047B.2030300@TimAliBentley.org.uk> <200611211427.27190.jkeating@redhat.com> <1164137678.3369.6.camel@lt21223.campus.dmacc.edu> <200611211438.24429.jkeating@redhat.com> Message-ID: <1164139699.3580.25.camel@zod.rchland.ibm.com> On Tue, 2006-11-21 at 14:38 -0500, Jesse Keating wrote: > On Tuesday 21 November 2006 14:34, Jeffrey C. Ollie wrote: > > Thunderbird isn't a sane mail client? > > If it produces garbage like the post, I'd say no. Did you ever consider that it may be a bug in your mailer? It shows up just fine in my reader and on the archives. josh From garrick at usc.edu Tue Nov 21 20:13:14 2006 From: garrick at usc.edu (Garrick Staples) Date: Tue, 21 Nov 2006 12:13:14 -0800 Subject: MonoDevelop 0.12-7.fc6 In-Reply-To: <1164139699.3580.25.camel@zod.rchland.ibm.com> References: <4562047B.2030300@TimAliBentley.org.uk> <200611211427.27190.jkeating@redhat.com> <1164137678.3369.6.camel@lt21223.campus.dmacc.edu> <200611211438.24429.jkeating@redhat.com> <1164139699.3580.25.camel@zod.rchland.ibm.com> Message-ID: <20061121201314.GP2297@polop.usc.edu> On Tue, Nov 21, 2006 at 02:08:18PM -0600, Josh Boyer alleged: > On Tue, 2006-11-21 at 14:38 -0500, Jesse Keating wrote: > > On Tuesday 21 November 2006 14:34, Jeffrey C. Ollie wrote: > > > Thunderbird isn't a sane mail client? > > > > If it produces garbage like the post, I'd say no. > > Did you ever consider that it may be a bug in your mailer? It shows up > just fine in my reader and on the archives. It looked like crap in mutt too. Just make sure you are using plain text for public mail lists. -- Garrick Staples, Linux/HPCC Administrator University of Southern California -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Tue Nov 21 20:15:04 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 21 Nov 2006 15:15:04 -0500 Subject: MonoDevelop 0.12-7.fc6 In-Reply-To: <1164139699.3580.25.camel@zod.rchland.ibm.com> References: <4562047B.2030300@TimAliBentley.org.uk> <200611211427.27190.jkeating@redhat.com> <1164137678.3369.6.camel@lt21223.campus.dmacc.edu> <200611211438.24429.jkeating@redhat.com> <1164139699.3580.25.camel@zod.rchland.ibm.com> Message-ID: <20061121201504.GA27440@jadzia.bu.edu> On Tue, Nov 21, 2006 at 02:08:18PM -0600, Josh Boyer wrote: > > > Thunderbird isn't a sane mail client? > > If it produces garbage like the post, I'd say no. > Did you ever consider that it may be a bug in your mailer? It shows up > just fine in my reader and on the archives. It doesn't show up fine in any text-based mailer. And the blockquote=cite html doesn't render in a helpful way in elinks. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jwilson at redhat.com Tue Nov 21 20:36:25 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 21 Nov 2006 15:36:25 -0500 Subject: Status of any effort to get Scipy into Extras? In-Reply-To: <604aa7910611202028h57bc2d9buac4de6650ab53713@mail.gmail.com> References: <604aa7910611201701t3f7620c8lbb3a0473aecc958a@mail.gmail.com> <1164082306.25587.3.camel@chronos.wilsonet.com> <604aa7910611202028h57bc2d9buac4de6650ab53713@mail.gmail.com> Message-ID: <1164141386.20812.5.camel@xavier.boston.redhat.com> On Mon, 2006-11-20 at 19:28 -0900, Jeff Spaleta wrote: > On 11/20/06, Jarod Wilson wrote: > > Also, I'm ready to bump FC5 and 6 to numpy 1.0 if there's no reason not > > to. However, all I've got to go on is one thumbs up and zero thumbs down > > for the rawhide numpy 1.0 build... > > Yes, please do that update. Okay, numpy 1.0 builds have been submitted for both FC5 and FC6. > One thing numpy is throwing warnings about an outdated ctypes module. > I'm not sure if that's important or not. Dunno... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Home at TimAliBentley.org.uk Tue Nov 21 21:56:22 2006 From: Home at TimAliBentley.org.uk (Tim and Alison Bentley) Date: Tue, 21 Nov 2006 21:56:22 +0000 Subject: MonoDevelop 0.12-7.fc6 In-Reply-To: <456350D4.4040106@TimAliBentley.org.uk> References: <4562047B.2030300@TimAliBentley.org.uk><1164065963.31552.58.camel@T7.Linux> <456350D4.4040106@TimAliBentley.org.uk> Message-ID: <45637606.8030005@TimAliBentley.org.uk> Tim and Alison Bentley wrote: > Paul wrote: > > Hi, > > > > I was wondering why the current version of Monodevelop was missing the > version control functionality: > - Version Control provided by Subversion > > > > When I built it last using Subversion, it crashed and burned on both x86 > and x86_64 > > > I tested last week end from Subversion and built it with --VersionControl and -ASPNET. I managed to get it to run. --debugger failed with a code error. I had no luck with the source code from the extras repository but that may be a user error. The APSNETEDIT required JCALLS-SHARP which I got from the mono Subversion repository but had build errors which I seemed to fix. The resulting installed modules could not be found by the monodevelop build. Again a user error. Building from source is not one of my strong points! > > > - ASPX development provided by the ASPX plugins. > > Neither were shipped with the source. > > > These are now available with the source. > > > > I have attempted to build from source and have problems with every move I make. > > Monodevelop can be a bit of swine to build from source. Are you grabbing > the sources directly from mono svn or using the src.rpm file? > Mono svn > TTFN > > Paul > Monodevelop packager > > > > > -- Tim and Alison Bentley Email: Home at TimAliBentley.org.uk From tmz at pobox.com Wed Nov 22 06:07:26 2006 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 22 Nov 2006 01:07:26 -0500 Subject: An updated libgpod for core and python bindings for extras Message-ID: <20061122060726.GP32659@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, There was a discussion on fedora-maintainers the other day about libgpod in core, its age and the status of the python bindings that come with the upstream package.[1] I filed one of the BZ's referenced in that thread.[2] In the comments there and in the thread on maintainers it seems that the likely way to get the python bindings built and available to Fedora users is to build them in extras. Is that something that seems reasonable to the folks here? If not, why not? An updated libgpod (0.4.0) has made it's way into core (sans the python bindings) but due to some API/ABI breakage it'll likely wait for 0.4.1 which bumps the soname of the library and will allow a libgpod compat package to be built (see the BZ for more discussion of those details). In the hopes of getting some testing and stuff worked out until 0.4.1 is released I built a python-gpod package from 0.4.0. Anyone care to rip it apart and tell me what sucks about it? SPEC: http://pobox.com/~tmz/fedora/python-gpod.spec SRPM: http://pobox.com/~tmz/fedora/python-gpod-0.4.0-1.fc6.src.rpm Thanks much, [1] https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00214.html [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211648 - -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== If the world didn't suck, we'd all fall off. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iQFDBAEBAgAtBQJFY+keJhhodHRwOi8vd3d3LnBvYm94LmNvbS9+dG16L3BncC90 bXouYXNjAAoJEEMlk4u+rwzj7UUIALWmKqKpvp+l9kRVZd5L1TH7Y6ZLr08wxJoI 2A3uiS2VBASDJ5X6VZpwAOtlBpYTMPmyWh9EWKerWBMZzxXnqwCkf7MDuWfAF4bQ nt8MdcRl3owiOhhTPEJ2h2Qz/jQ4gl12fEDfoEYGRqdSBy1mcdJI0VRjOvksGZY/ CXGE4FNIpcwVK6oJVkI2jn6VZ/uV/gTXQy8jY47RovKPH54FoWGQ/xaogwLcG+Mf qtl/rDqDf/w76h7ceyP9jC+x/7+YlpCVSBxd7zkriWUn1SIEafOhBf+FPcbPWMc7 31Zg+cW5huUobUJEnZFsZ1QZdgxC+iE4M+5dCxUFcQXfS1zAtxE= =3Vqw -----END PGP SIGNATURE----- From rc040203 at freenet.de Wed Nov 22 11:34:24 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 22 Nov 2006 12:34:24 +0100 Subject: rpms/gparted/devel gparted-configure.patch,NONE,1.1 In-Reply-To: <200611220804.kAM84meI004364@cvs-int.fedora.redhat.com> References: <200611220804.kAM84meI004364@cvs-int.fedora.redhat.com> Message-ID: <1164195264.8385.23.camel@mccallum.corsepiu.local> On Wed, 2006-11-22 at 03:04 -0500, Deji Akingunola wrote: > Author: deji > > Update of /cvs/extras/rpms/gparted/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv4357 > > Added Files: > gparted-configure.patch > Log Message: > * Wed Nov 23 2006 Deji Akingunola - 0.3.1-3 > - Backport a fix from cvs to properly check for libparted version > > > gparted-configure.patch: > > --- NEW FILE gparted-configure.patch --- > --- configure.keep 2006-09-11 05:39:49.000000000 -0400 > +++ configure 2006-11-22 02:46:15.000000000 -0500 The same mistake as yesterday: Patching a generated file. Are you sure you know what you are doing? Ralf From dkovalsk at redhat.com Wed Nov 22 12:21:13 2006 From: dkovalsk at redhat.com (David Kovalsky) Date: Wed, 22 Nov 2006 13:21:13 +0100 Subject: desktop files for dockapp apps? In-Reply-To: <20061015082813.GB2323@free.fr> References: <20061012201411.GC2358@free.fr> <1160704345.2619.598.camel@localhost.localdomain> <20061014181252.GA8216@free.fr> <1160858658.2619.714.camel@localhost.localdomain> <20061015082813.GB2323@free.fr> Message-ID: <456440B9.8000807@redhat.com> Patrice Dumas wrote: > On Sat, Oct 14, 2006 at 03:44:18PM -0500, Tom 'spot' Callaway wrote: >> How do you add a dockapp? Presumably, there is some tool (e.g. to add an > > In the case I know and use, fluxbox, one has to hand-edit the start > script. I tried WindowMaker and I didn't understood how to do. [...] The way I do it in WindowMaker is I start the dockapp from shell, ^C to close it and there's an empty icon left after the app has closed. Then when you click on the icon the dockapp starts automagically. You can then choose in preferences some parameters and that the dockapp starts when WindowMaker is started. -- ================================================== David Kovalsky dkovalsk at redhat.com Quality Engineer IRC: #brno, #errata, #qa, #urt ================================================== From jansen at strw.leidenuniv.nl Wed Nov 22 13:28:23 2006 From: jansen at strw.leidenuniv.nl (David Jansen) Date: Wed, 22 Nov 2006 14:28:23 +0100 Subject: Bug in agrep (x86_64); no bugzilla category In-Reply-To: <4562E152.2080601@ioa.s.u-tokyo.ac.jp> References: <4562E152.2080601@ioa.s.u-tokyo.ac.jp> Message-ID: <20061122132823.GA17032@strw.leidenuniv.nl> On Tue, Nov 21, 2006 at 08:21:54PM +0900, Mamoru Tasaka wrote: [...] > As Gianluca said, agrep is rebuilt from tre, so a bug report should > be filed against tre component (if any). You can simply check the original > srpm by 'rpm -qi agrep'. Thanks, I didn't think to check the rpm -qi output. I'll file the bug for tre. Meanwhile, I have managed to get a working agrep from the Dries repository that solves my immediate needs. David Jansen From bugs.michael at gmx.net Wed Nov 22 14:49:05 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 22 Nov 2006 15:49:05 +0100 Subject: Bug in agrep (x86_64); no bugzilla category In-Reply-To: <20061122132823.GA17032@strw.leidenuniv.nl> References: <4562E152.2080601@ioa.s.u-tokyo.ac.jp> <20061122132823.GA17032@strw.leidenuniv.nl> Message-ID: <20061122154905.3852d360.bugs.michael@gmx.net> On Wed, 22 Nov 2006 14:28:23 +0100, David Jansen wrote: > On Tue, Nov 21, 2006 at 08:21:54PM +0900, Mamoru Tasaka wrote: > [...] > > As Gianluca said, agrep is rebuilt from tre, so a bug report should > > be filed against tre component (if any). You can simply check the original > > srpm by 'rpm -qi agrep'. > > Thanks, I didn't think to check the rpm -qi output. I'll file the bug > for tre. Meanwhile, I have managed to get a working agrep from the Dries > repository that solves my immediate needs. Which is the original agrep, which is not in Fedora Extras. From jmp at safe.ca Wed Nov 22 19:20:40 2006 From: jmp at safe.ca (Jean-Marc Pigeon) Date: Wed, 22 Nov 2006 14:20:40 -0500 Subject: comps.xlm fc6 and devel update In-Reply-To: <200611211447.07693.jkeating@redhat.com> References: <20061121092013.GA12328@strw.leidenuniv.nl> <200611211428.47039.jkeating@redhat.com> <1164137716.18723.33.camel@Montreal.safe.ca> <200611211447.07693.jkeating@redhat.com> Message-ID: <1164223240.18723.71.camel@Montreal.safe.ca> Bonjour a Tous, Updated comps-fe6.xml.in and comps-fe7.xml.in yesterday. done cvs update and cvs commit. Everything seems to be fine, but in http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/ comps.xml is still stamped November 16 (same for fc6 update). Is there a special 'trick' or procedure to have comps updated? Thanks. -- A bient?t ========================================================================== Jean-Marc Pigeon Internet: jmp at safe.ca SAFE Inc. Phone: (514) 493-4280 Fax: (514) 493-1946 Clement, 'a kiss solution' to get rid of SPAM (at last) Clement' Home base <"http://www.clement.safe.ca"> ========================================================================== From fedora at leemhuis.info Wed Nov 22 19:38:56 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 22 Nov 2006 20:38:56 +0100 Subject: An updated libgpod for core and python bindings for extras In-Reply-To: <20061122060726.GP32659@psilocybe.teonanacatl.org> References: <20061122060726.GP32659@psilocybe.teonanacatl.org> Message-ID: <4564A750.8040309@leemhuis.info> Todd Zullinger schrieb: > > There was a discussion on fedora-maintainers the other day about > libgpod in core, its age and the status of the python bindings that > come with the upstream package.[1] > > I filed one of the BZ's referenced in that thread.[2] In the comments > there and in the thread on maintainers it seems that the likely way to > get the python bindings built and available to Fedora users is to > build them in extras. > > Is that something that seems reasonable to the folks here? I don't see any problems here as long as nothing from Core get replaced. Just submit it for review. See http://www.fedoraproject.org/wiki/Extras/Contributors for details. CU thl From chris.stone at gmail.com Wed Nov 22 19:48:24 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 22 Nov 2006 11:48:24 -0800 Subject: comps.xlm fc6 and devel update In-Reply-To: <1164223240.18723.71.camel@Montreal.safe.ca> References: <20061121092013.GA12328@strw.leidenuniv.nl> <200611211428.47039.jkeating@redhat.com> <1164137716.18723.33.camel@Montreal.safe.ca> <200611211447.07693.jkeating@redhat.com> <1164223240.18723.71.camel@Montreal.safe.ca> Message-ID: On 11/22/06, Jean-Marc Pigeon wrote: > Bonjour a Tous, > > > Updated comps-fe6.xml.in and comps-fe7.xml.in yesterday. > done cvs update and cvs commit. > Everything seems to be fine, but in > http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/ > comps.xml is still stamped November 16 (same for fc6 update). > > Is there a special 'trick' or procedure to have comps updated? > > Thanks. I think there is only one person who does this right now, and he does not update it very often, but I think atleast once per release. I'm not sure how difficult it would be to automate the process, or if it's feasable to allow sponsers or anyone in FESCo to update it. I think it would be nice to allow anyone to automatically update comps immediately after they update the .in file. From jmp at safe.ca Wed Nov 22 20:16:42 2006 From: jmp at safe.ca (Jean-Marc Pigeon) Date: Wed, 22 Nov 2006 15:16:42 -0500 Subject: comps.xlm fc6 and devel update In-Reply-To: References: <20061121092013.GA12328@strw.leidenuniv.nl> <200611211428.47039.jkeating@redhat.com> <1164137716.18723.33.camel@Montreal.safe.ca> <200611211447.07693.jkeating@redhat.com> <1164223240.18723.71.camel@Montreal.safe.ca> Message-ID: <1164226602.18723.84.camel@Montreal.safe.ca> On Wed, 2006-11-22 at 11:48 -0800, Christopher Stone wrote: > On 11/22/06, Jean-Marc Pigeon wrote: > > Bonjour a Tous, > > > > > > Updated comps-fe6.xml.in and comps-fe7.xml.in yesterday. > > done cvs update and cvs commit. > > Everything seems to be fine, but in > > http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/ > > comps.xml is still stamped November 16 (same for fc6 update). > > > > Is there a special 'trick' or procedure to have comps updated? > > > > Thanks. > > I think there is only one person who does this right now, and he does > not update it very often, but I think atleast once per release. IMHO, Once per release is very far from enough. > > I'm not sure how difficult it would be to automate the process, or if > it's feasable to allow sponsers or anyone in FESCo to update it. I > think it would be nice to allow anyone to automatically update comps > immediately after they update the .in file. Ideally something as 'make tag' + 'cvs commit would be perfect. But in the mid time may be a cron task to update it every week should be good enough. I checked the comps logs and seems to me a lot of adds/changes... so that file matter to developer... Keeping comps alive AND updated will help every Linux user to spot the needed utility/application rather than brows endlessly within tons of extra applications. My 2 cents. (How can I help on this topics?) > -- A bient?t ========================================================================== Jean-Marc Pigeon Internet: jmp at safe.ca SAFE Inc. Phone: (514) 493-4280 Fax: (514) 493-1946 Clement, 'a kiss solution' to get rid of SPAM (at last) Clement' Home base <"http://www.clement.safe.ca"> ========================================================================== From bugs.michael at gmx.net Wed Nov 22 20:27:25 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 22 Nov 2006 21:27:25 +0100 Subject: comps.xlm fc6 and devel update In-Reply-To: References: <20061121092013.GA12328@strw.leidenuniv.nl> <200611211428.47039.jkeating@redhat.com> <1164137716.18723.33.camel@Montreal.safe.ca> <200611211447.07693.jkeating@redhat.com> <1164223240.18723.71.camel@Montreal.safe.ca> Message-ID: <20061122212725.44e4dae3.bugs.michael@gmx.net> On Wed, 22 Nov 2006 11:48:24 -0800, Christopher Stone wrote: > On 11/22/06, Jean-Marc Pigeon wrote: > > Bonjour a Tous, > > > > > > Updated comps-fe6.xml.in and comps-fe7.xml.in yesterday. > > done cvs update and cvs commit. > > Everything seems to be fine, but in > > http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/ > > comps.xml is still stamped November 16 (same for fc6 update). > > > > Is there a special 'trick' or procedure to have comps updated? > > > > Thanks. > > I think there is only one person who does this right now, and he does > not update it very often, but I think atleast once per release. Not true anymore. The comps.xml files have not been installed since April, btw. But since Nov 8th, all comps.xml are updated on-the-fly with every push of packages, provided that the generated file contains changes and is well-formed. > I'm not sure how difficult it would be to automate the process, or if > it's feasable to allow sponsers or anyone in FESCo to update it. I > think it would be nice to allow anyone to automatically update comps > immediately after they update the .in file. It's not anything like the comps.xml files have such a high priority that it would make sense to update them as often as that. Also, you would want them to be synced to the mirrors, which would not be "immediately" anyway. From nicolas.mailhot at laposte.net Wed Nov 22 21:57:23 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 22 Nov 2006 22:57:23 +0100 Subject: comps.xlm fc6 and devel update In-Reply-To: <20061122212725.44e4dae3.bugs.michael@gmx.net> References: <20061121092013.GA12328@strw.leidenuniv.nl> <200611211428.47039.jkeating@redhat.com> <1164137716.18723.33.camel@Montreal.safe.ca> <200611211447.07693.jkeating@redhat.com> <1164223240.18723.71.camel@Montreal.safe.ca> <20061122212725.44e4dae3.bugs.michael@gmx.net> Message-ID: <1164232649.19448.3.camel@rousalka.dyndns.org> Le mercredi 22 novembre 2006 ? 21:27 +0100, Michael Schwendt a ?crit : > But since Nov 8th, all comps.xml are updated on-the-fly with every push of > packages, provided that the generated file contains changes and is > well-formed. Actually, since the comps wiki page was clarified and the xslt verifier made available, I think every comps.xml.in commit has been well-formed. (I'd even argue the FE comps is a little cleaner than the FC one now). At least I haven't found any pretext to work on the filter for some time. Regards, -- Nicolas Mailhot From triad at df.lth.se Wed Nov 22 22:12:21 2006 From: triad at df.lth.se (Linus Walleij) Date: Wed, 22 Nov 2006 23:12:21 +0100 (CET) Subject: Adoption of alsa-tools Message-ID: I'm picking up the orpaned alsa-tools package. Appears I need it for loading my antique OPL2 chip with sounds. Linus From orion at cora.nwra.com Wed Nov 22 22:42:41 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 22 Nov 2006 15:42:41 -0700 Subject: hammer1 and hammer3 appear to be down Message-ID: <4564D261.1020405@cora.nwra.com> Folks know about that? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jmp at safe.ca Wed Nov 22 23:01:23 2006 From: jmp at safe.ca (Jean-Marc Pigeon) Date: Wed, 22 Nov 2006 18:01:23 -0500 Subject: comps.xlm fc6 and devel update In-Reply-To: <1164232649.19448.3.camel@rousalka.dyndns.org> References: <20061121092013.GA12328@strw.leidenuniv.nl> <200611211428.47039.jkeating@redhat.com> <1164137716.18723.33.camel@Montreal.safe.ca> <200611211447.07693.jkeating@redhat.com> <1164223240.18723.71.camel@Montreal.safe.ca> <20061122212725.44e4dae3.bugs.michael@gmx.net> <1164232649.19448.3.camel@rousalka.dyndns.org> Message-ID: <1164236483.18723.87.camel@Montreal.safe.ca> On Wed, 2006-11-22 at 22:57 +0100, Nicolas Mailhot wrote: > Le mercredi 22 novembre 2006 ? 21:27 +0100, Michael Schwendt a ?crit : > > > But since Nov 8th, all comps.xml are updated on-the-fly with every push of > > packages, provided that the generated file contains changes and is > > well-formed. > > Actually, since the comps wiki page was clarified and the xslt verifier > made available, I think every comps.xml.in commit has been well-formed. > (I'd even argue the FE comps is a little cleaner than the FC one now). > > At least I haven't found any pretext to work on the filter for some > time. So... why the updated comps is not available within FC6 and devel depositories? What is the part I am missing? > > Regards, > > -- > Nicolas Mailhot > -- A bient?t ========================================================================== Jean-Marc Pigeon Internet: jmp at safe.ca SAFE Inc. Phone: (514) 493-4280 Fax: (514) 493-1946 Clement, 'a kiss solution' to get rid of SPAM (at last) Clement' Home base <"http://www.clement.safe.ca"> ========================================================================== From bugs.michael at gmx.net Wed Nov 22 23:09:21 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 23 Nov 2006 00:09:21 +0100 Subject: comps.xlm fc6 and devel update In-Reply-To: <1164236483.18723.87.camel@Montreal.safe.ca> References: <20061121092013.GA12328@strw.leidenuniv.nl> <200611211428.47039.jkeating@redhat.com> <1164137716.18723.33.camel@Montreal.safe.ca> <200611211447.07693.jkeating@redhat.com> <1164223240.18723.71.camel@Montreal.safe.ca> <20061122212725.44e4dae3.bugs.michael@gmx.net> <1164232649.19448.3.camel@rousalka.dyndns.org> <1164236483.18723.87.camel@Montreal.safe.ca> Message-ID: <20061123000921.89b467ca.bugs.michael@gmx.net> On Wed, 22 Nov 2006 18:01:23 -0500, Jean-Marc Pigeon wrote: > On Wed, 2006-11-22 at 22:57 +0100, Nicolas Mailhot wrote: > > Le mercredi 22 novembre 2006 ? 21:27 +0100, Michael Schwendt a ?crit : > > > > > But since Nov 8th, all comps.xml are updated on-the-fly with every push of > > > packages, provided that the generated file contains changes and is > > > well-formed. > > > > Actually, since the comps wiki page was clarified and the xslt verifier > > made available, I think every comps.xml.in commit has been well-formed. > > (I'd even argue the FE comps is a little cleaner than the FC one now). > > > > At least I haven't found any pretext to work on the filter for some > > time. > So... why the updated comps is not available within > FC6 and devel depositories? > What is the part I am missing? Patience? Most likely you've committed your changes _after_ yesterday's push. From dennis at ausil.us Wed Nov 22 23:20:04 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 22 Nov 2006 17:20:04 -0600 Subject: hammer1 and hammer3 appear to be down In-Reply-To: <4564D261.1020405@cora.nwra.com> References: <4564D261.1020405@cora.nwra.com> Message-ID: <200611221720.05167.dennis@ausil.us> On Wednesday 22 November 2006 16:42, Orion Poplawski wrote: > Folks know about that? hammer3 suffered a fatal hardware failure. Dell has donated a replacement and it is on its way now. hammer1 suffered from a blown out chroot and i am in the middle of rebuilding it. its replacement will be known as xenbuilder1 -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From jmp at safe.ca Wed Nov 22 23:29:30 2006 From: jmp at safe.ca (Jean-Marc Pigeon) Date: Wed, 22 Nov 2006 18:29:30 -0500 Subject: comps.xlm fc6 and devel update In-Reply-To: <20061123000921.89b467ca.bugs.michael@gmx.net> References: <20061121092013.GA12328@strw.leidenuniv.nl> <200611211428.47039.jkeating@redhat.com> <1164137716.18723.33.camel@Montreal.safe.ca> <200611211447.07693.jkeating@redhat.com> <1164223240.18723.71.camel@Montreal.safe.ca> <20061122212725.44e4dae3.bugs.michael@gmx.net> <1164232649.19448.3.camel@rousalka.dyndns.org> <1164236483.18723.87.camel@Montreal.safe.ca> <20061123000921.89b467ca.bugs.michael@gmx.net> Message-ID: <1164238170.18723.89.camel@Montreal.safe.ca> On Thu, 2006-11-23 at 00:09 +0100, Michael Schwendt wrote: > > > Actually, since the comps wiki page was clarified and the xslt verifier > > > made available, I think every comps.xml.in commit has been well-formed. > > > (I'd even argue the FE comps is a little cleaner than the FC one now). > > > > > > At least I haven't found any pretext to work on the filter for some > > > time. > > So... why the updated comps is not available within > > FC6 and devel depositories? > > What is the part I am missing? > > Patience? :-}}}} I like this missing part, hopefully you are right :-}}}} > > Most likely you've committed your changes _after_ yesterday's push. > -- A bient?t ========================================================================== Jean-Marc Pigeon Internet: jmp at safe.ca SAFE Inc. Phone: (514) 493-4280 Fax: (514) 493-1946 Clement, 'a kiss solution' to get rid of SPAM (at last) Clement' Home base <"http://www.clement.safe.ca"> ========================================================================== From buildsys at fedoraproject.org Thu Nov 23 00:00:13 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 22 Nov 2006 19:00:13 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-22 Message-ID: <20061123000013.5E08015212F@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 68 TurboGears-1.0b1-3.fc7 Zim-0.17-3.fc7 aquamarine-0.1.2-3.fc7 bdock-0.1.2-4.fc7 beryl-core-0.1.2-6.fc7 beryl-dbus-0.1.2-4.fc7 beryl-manager-0.1.2-4.fc7 bsd-games-2.17-16.fc7 cmake-2.4.4-1.fc7 codeblocks-1.0-0.14.20061121svn3253.fc7 db4o-6.0-3.1.fc7 dd2-0.2.1-1.fc7 dejavu-fonts-2.12-1.rc1.fc7 deskbar-applet-2.17.2-2.fc7 eric-3.9.2-2.fc7 espeak-1.17-1.fc7 farsight-0.1.10-1.fc7 gdl-0.9-0.pre3.2.fc7 glipper-0.95.1-2.fc7 gliv-1.9.6-2.fc7 gnash-0.7.2-1.fc7 gparted-0.3.1-3.fc7 gtkmozembedmm-1.4.2.cvs20060817-5.fc7 heliodor-0.1.2-4.fc7 hfsplus-tools-332.14-4.fc7 id3lib-3.8.3-15.fc7 jd-1.8.1-0.1.cvs061122.fc7 kid3-0.8.1-1.fc7 labyrinth-0.3-1.fc7 lat-1.2.1.1-2.fc7 libosip2-3.0.1-2.fc7 liferea-1.0.26-1.fc7 linphone-1.5.1-1.fc7 mail-notification-3.0-11.fc7 manaworld-0.0.21.1-1.fc7 moodss-21.5-1.fc7 moomps-5.8-1.fc7 openct-0.6.11-2.fc7 ortp-0.12.0-1.fc7 panelfm-1.2-2.fc7 perl-Algorithm-C3-0.06-1.fc7 perl-Email-Address-1.882-1.fc7 perl-ExtUtils-ParseXS-2.17-1.fc7 perl-Glib-1.141-1.fc7 perl-Gnome2-Print-1.000-2.fc7 perl-Gtk2-1.141-1.fc7 perl-HTML-Table-2.04a-1.fc7 perl-HTTP-Server-Simple-0.24-1.fc7 perl-MIME-Types-1.18-1.fc7 perl-Module-ScanDeps-0.70-1.fc7 perl-Net-DBus-0.33.4-3.fc7 perl-PadWalker-1.2-1.fc7 perl-WWW-Myspace-0.60-1.fc7 perl-Wx-0.63-1.fc7 php-pear-MDB2-2.3.0-1.fc7 php-pear-Services-Weather-1.4.0-2.fc7 plt-scheme-360-1.fc7 prboom-2.4.7-1.fc7 python-basemap-0.9.4-1.fc7 python-eyed3-0.6.11-1.fc7 python-xmpp-0.4.0-1.fc7 qtparted-0.4.5-11.fc7 rocksndiamonds-3.2.2-4.fc7 spandsp-0.0.3-1.pre25.fc7 sysprof-kmod-1.0.7-1.2.6.18_1.2849.fc6.1 wxMaxima-0.7.0a-4.fc7 xchm-1.10-1.fc7 zabbix-1.1.4-2.fc7 Packages built and released for Fedora Extras 6: 63 TurboGears-1.0b1-2.fc6 Zim-0.17-3.fc6 aquamarine-0.1.2-3.fc6 bdock-0.1.2-4.fc6 beryl-core-0.1.2-6.fc6 beryl-dbus-0.1.2-4.fc6 beryl-manager-0.1.2-4.fc6 beryl-plugins-0.1.2-2.fc6 beryl-settings-0.1.2-2.fc6 chemtool-1.6.9-5.fc6 codeblocks-1.0-0.14.20061121svn3253.fc6 emerald-0.1.2-3.fc6 emerald-themes-0.1.2-2.fc6 espeak-1.17-1.fc6 fuse-2.6.0-1.fc6 gdl-0.9-0.pre3.2.fc6 glipper-0.95.1-2.fc6 gnash-0.7.2-1.fc6 heliodor-0.1.2-4.fc6 hfsplus-tools-332.14-4.fc6 id3lib-3.8.3-15.fc6 kid3-0.8.1-1.fc6 kleansweep-0.2.9-3.fc6 lat-1.2.1.1-2.fc6 lib3ds-1.2.0-10.fc6 libEMF-1.0.3-3.fc6 libosip2-3.0.1-2.fc6 manaworld-0.0.21.1-1.fc6 mirage-0.8.1-1.fc6 moodss-21.5-1.fc6 moomps-5.8-1.fc6 numpy-1.0-1.fc6 openct-0.6.11-1.fc6 ortp-0.12.0-1.fc6 panelfm-1.2-2.fc6 perl-Algorithm-C3-0.06-1.fc6 perl-Email-Address-1.882-1.fc6 perl-ExtUtils-ParseXS-2.17-1.fc6 perl-Gnome2-Print-1.000-2.fc6 perl-HTML-Table-2.04a-1.fc6 perl-HTTP-Server-Simple-0.24-1.fc6 perl-MIME-Types-1.18-1.fc6 perl-Module-ScanDeps-0.70-1.fc6 perl-Net-DBus-0.33.4-3.fc6 perl-PadWalker-1.2-1.fc6 perl-WWW-Myspace-0.60-1.fc6 perl-Wx-0.63-1.fc6 php-pear-DB-DataObject-1.8.4-2.fc6 php-pear-DB-DataObject-FormBuilder-1.0.0-0.1.RC5.fc6 php-pear-MDB2-2.3.0-1.fc6 php-pear-Services-Weather-1.4.0-2.fc6 php-pear-Structures-DataGrid-DataSource-DataObject-0.1.0-1.fc6 php-pear-Structures-DataGrid-Renderer-Pager-0.1.0-1.fc6 php-pear-Structures-DataGrid-Renderer-Smarty-0.1.2-1.fc6 plone-2.5.1-4.fc6 plt-scheme-360-1.fc6 prboom-2.4.7-1.fc6 python-basemap-0.9.4-1.fc6 python-nltk-1.4.4-3.fc6 python-xmpp-0.4.0-1.fc6 spandsp-0.0.3-1.pre25.fc6 telepathy-butterfly-0.1.3-1.fc6 xchm-1.10-1.fc6 Packages built and released for Fedora Extras 5: 41 Zim-0.17-3.fc5 chemtool-1.6.9-5.fc5 codeblocks-1.0-0.14.20061121svn3253.fc5 espeak-1.17-1.fc5 fuse-2.6.0-1.fc5 hfsplus-tools-332.14-4.fc5 id3lib-3.8.3-15.fc5 kleansweep-0.2.9-3.fc5 lib3ds-1.2.0-10.fc5 libEMF-1.0.3-3.fc5 libosip2-3.0.1-2.fc5 mirage-0.8.1-1.fc5 moodss-21.5-1.fc5 moomps-5.8-1.fc5 numpy-1.0-1.fc5 ortp-0.12.0-1.fc5 panelfm-1.2-2.fc5 perl-Algorithm-C3-0.06-1.fc5 perl-Email-Address-1.882-1.fc5 perl-ExtUtils-ParseXS-2.17-1.fc5 perl-Gnome2-Print-1.000-2.fc5 perl-HTML-Table-2.04a-1.fc5 perl-HTTP-Server-Simple-0.24-1.fc5 perl-Module-ScanDeps-0.70-1.fc5 perl-Net-DBus-0.33.4-3.fc5 perl-PadWalker-1.2-1.fc5 perl-WWW-Myspace-0.60-1.fc5 perl-Wx-0.63-1.fc5 php-pear-DB-DataObject-1.8.4-2.fc5 php-pear-DB-DataObject-FormBuilder-1.0.0-0.1.RC5.fc5 php-pear-MDB2-2.3.0-1.fc5 php-pear-Services-Weather-1.4.0-2.fc5 php-pear-Structures-DataGrid-DataSource-DataObject-0.1.0-1.fc5 php-pear-Structures-DataGrid-Renderer-Pager-0.1.0-1.fc5 php-pear-Structures-DataGrid-Renderer-Smarty-0.1.2-1.fc5 plt-scheme-360-1.fc5 python-xmpp-0.4.0-1.fc5 spandsp-0.0.3-1.pre25.fc5 sysprof-1.0.7-1.fc5 sysprof-kmod-1.0.7-1.2.6.18_1.2239.fc5 xchm-1.10-1.fc5 Packages built and released for Fedora Extras 4: 3 fuse-2.6.0-1.fc4 lib3ds-1.2.0-10.fc4 python-xmpp-0.4.0-1.fc4 Packages built and released for Fedora Extras 3: 0 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From paul at all-the-johnsons.co.uk Thu Nov 23 00:26:25 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 23 Nov 2006 00:26:25 +0000 Subject: Fedora Extras Package Build Report 2006-11-22 In-Reply-To: <20061123000013.5E08015212F@buildsys.fedoraproject.org> References: <20061123000013.5E08015212F@buildsys.fedoraproject.org> Message-ID: <1164241585.8591.39.camel@T7.Linux> Hi, On Wed, 2006-11-22 at 19:00 -0500, buildsys at fedoraproject.org wrote: > Packages built and released for Fedora Extras development: 68 > sysprof-kmod-1.0.7-1.2.6.18_1.2849.fc6.1 Is this a buildsys config problem or a package problem? Why is it fc6 when it's in the rawhide repo? TTFN Paul -- Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dennis at ausil.us Thu Nov 23 00:52:21 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 22 Nov 2006 18:52:21 -0600 Subject: Fedora Extras Package Build Report 2006-11-22 In-Reply-To: <1164241585.8591.39.camel@T7.Linux> References: <20061123000013.5E08015212F@buildsys.fedoraproject.org> <1164241585.8591.39.camel@T7.Linux> Message-ID: <200611221852.21806.dennis@ausil.us> On Wednesday 22 November 2006 18:26, Paul wrote: > Hi, > > On Wed, 2006-11-22 at 19:00 -0500, buildsys at fedoraproject.org wrote: > > Packages built and released for Fedora Extras development: 68 > > > > sysprof-kmod-1.0.7-1.2.6.18_1.2849.fc6.1 > > Is this a buildsys config problem or a package problem? Why is it fc6 > when it's in the rawhide repo? Rawhide has not had a kernel update since targeting Fedora 7, so the kernel in devel has .fc6 in it this is correct -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From buildsys at fedoraproject.org Thu Nov 23 01:15:24 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 23 Nov 2006 01:15:24 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-22 Message-ID: <20061123011524.28979.46807@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 (22 days) centericq - 4.21.0-8.fc6.ppc (22 days) centericq - 4.21.0-8.fc6.x86_64 (22 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (25 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (25 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (25 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (25 days) orange - 0.3-3.cvs20051118.fc6.i386 (29 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (53 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (53 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (53 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (68 days) plague - 0.4.4.1-2.fc3.noarch (68 days) plague - 0.4.4.1-2.fc4.noarch (68 days) plague - 0.4.4.1-2.fc4.noarch (68 days) plague - 0.4.4.1-2.fc4.noarch (68 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (44 days) linphone - 1.2.0-4.fc5.ppc (44 days) linphone - 1.2.0-4.fc5.x86_64 (44 days) karlthered AT gmail.com gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.i386 gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.i386 gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.ppc gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.x86_64 matthias AT rpmforge.net php-eaccelerator - 5.1.6_0.9.5-2.fc7.i386 (6 days) php-eaccelerator - 5.1.6_0.9.5-2.fc7.ppc (6 days) php-eaccelerator - 5.1.6_0.9.5-2.fc7.x86_64 (6 days) oliver AT linux-kernel.at syck-php - 0.55-10.fc6.i386 (6 days) syck-php - 0.55-10.fc6.ppc (6 days) syck-php - 0.55-10.fc6.x86_64 (6 days) syck-php - 0.55-9.fc5.i386 (34 days) syck-php - 0.55-9.fc5.ppc (34 days) syck-php - 0.55-9.fc5.x86_64 (34 days) pertusus AT free.fr grads - 1.9b4-19.fc7.i386 (6 days) grads - 1.9b4-19.fc7.ppc (6 days) grads - 1.9b4-19.fc7.x86_64 (6 days) petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 (19 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (19 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (19 days) ghc642-gtk2hs - 0.9.10-4.fc6.i386 (19 days) ghc642-gtk2hs - 0.9.10-4.fc6.ppc (19 days) ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 (19 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 (19 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc (19 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 (19 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (24 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 grads-1.9b4-19.fc7.ppc requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.ppc requires gecko-libs = 0:2.0 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 php-eaccelerator-5.1.6_0.9.5-2.fc7.ppc requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.ppc requires php = 0:5.1.6 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 grads-1.9b4-19.fc7.x86_64 requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.i386 requires gecko-libs = 0:2.0 gtkmozembedmm-1.4.2.cvs20060817-5.fc7.x86_64 requires gecko-libs = 0:2.0 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 php-eaccelerator-5.1.6_0.9.5-2.fc7.x86_64 requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.x86_64 requires php = 0:5.1.6 Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 grads-1.9b4-19.fc7.i386 requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.i386 requires gecko-libs = 0:2.0 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 php-eaccelerator-5.1.6_0.9.5-2.fc7.i386 requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.i386 requires php = 0:5.1.6 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: orange - 0.3-3.cvs20051118.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libmagic.so.1 ====================================================================== New report for: karlthered AT gmail.com package: gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.ppc from fedora-extras-development-ppc unresolved deps: gecko-libs = 0:2.0 package: gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: gecko-libs = 0:2.0 package: gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: gecko-libs = 0:2.0 package: gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.i386 from fedora-extras-development-i386 unresolved deps: gecko-libs = 0:2.0 From bugs.michael at gmx.net Thu Nov 23 09:28:23 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 23 Nov 2006 10:28:23 +0100 Subject: rpms/streamtuner/devel streamtuner.spec,1.8,1.9 In-Reply-To: <200611230904.kAN94Zrh018861@cvs-int.fedora.redhat.com> References: <200611230904.kAN94Zrh018861@cvs-int.fedora.redhat.com> Message-ID: <20061123102823.11738511.bugs.michael@gmx.net> On Thu, 23 Nov 2006 04:04:35 -0500, Matthias Haase (endur) wrote: > Author: endur > > Update of /cvs/extras/rpms/streamtuner/devel > Modified Files: > streamtuner.spec > Log Message: > FC6 uses audacious instead beep-media-player - dependency changed But this is "devel" -> FC7 development. > %changelog > -* Mon Nov 06 2006 Jindrich Novy - 0.99.99-14 > -- rebuild against new curl > +* Thu Nov 23 2006 Matthias Haase - 0.99.99-14 > +- FC6 uses audacious instead beep-media-player > +- defaultconfig.patch changed > +- dependency changed Why drop Jindrich's entry? http://buildsys.fedoraproject.org/build-status/job.psp?uid=22205 > streamtuner-0_99_99-14_fc6 14_fc6 has been published before. Update your "common" checkout, so %{dist} will expand to ".fc7". From bugs.michael at gmx.net Thu Nov 23 13:52:56 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 23 Nov 2006 14:52:56 +0100 Subject: rpms/streamtuner/FC-6 streamtuner.spec,1.10,1.11 In-Reply-To: <200611231318.kANDIeAu000697@cvs-int.fedora.redhat.com> References: <200611231318.kANDIeAu000697@cvs-int.fedora.redhat.com> Message-ID: <20061123145256.4e6bc426.bugs.michael@gmx.net> On Thu, 23 Nov 2006 08:18:40 -0500, Matthias Haase (endur) wrote: > Author: endur > > Update of /cvs/extras/rpms/streamtuner/FC-6 > Log Message: > bump up release once again proper formated > -Release: 14%{?dist}.1 That one was okay. Most-significant portion left of %dist, least-significant portion to the very right. > +Release: 14.2%{?dist} 14.2 is "higher than" 14.fc and hence not a good idea when using %{?dist} From Christian.Iseli at licr.org Thu Nov 23 14:18:22 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 23 Nov 2006 15:18:22 +0100 Subject: FE Package Status of Nov 23, 2006 Message-ID: <20061123151822.134dcbca@ludwig-alpha.unil.ch> Hi folks, Pushing this out while I can spare a few cycles... I hope I'll have a bit more time to devote to Fedora next month... Cheers, Christian ---- FE Package Status of Nov 23, 2006 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 2558 packages - 111 orphans - 16 packages not available in extras devel or release andreas at bawue dot net ddrescue bdpepple at ameritech dot net galago-filesystem braden at endoframe dot com openvrml cweyl at alumni dot drew dot edu perl-GStreamer gemi at bluewin dot ch TeXmacs ghenry at suretecsystems dot com john j dot w dot r dot degoede at hhs dot nl MagicPoint matthias at rpmforge dot net SDL_pango orion at cora dot nwra dot com netcdf-perl paul at all-the-johnsons dot co dot uk mysql-connector-net paul at all-the-johnsons dot co dot uk gconvert paul at all-the-johnsons dot co dot uk gtksharp pertusus at free dot fr ivman ryo-dairiki at users dot sourceforge dot net VLGothic-fonts thomas at apestaart dot org python-twisted-core triad at df dot lth dot se njb-sharp - 3 packages not available in extras devel but present in release cgoorah at yahoo dot com dot au kleansweep miker5slow at grandecom dot net ruby-bdb twaugh at redhat dot com international-time - 7 packages which have not yet been FE-APPROVE'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=203864,209870,211626,211763,214818 tripwire fedora at theholbrooks.org prozilla kushaldas at gmail.com xtide mtasaka at ioa.s.u-tokyo.ac.jp jikes paul at all-the-johnsons.co.uk audacious redhat-bugzilla at camperquake.de https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=177841,198644 Tracker roozbeh at farsiweb.info new pb at bieringer.de - 9 packages present in the development repo which have no owners entry SDL_Pango eclipse-emf gtk-sharp itpp libopts php-pecl-Fileinfo pungi pygpgme system-switch-im - 21 orphaned packages, yet available in extras devel FreeWnn aspell-mi buildbot doctorj fltk gdk-pixbuf gnofract4d gnome-password-generator gnome-themes-extras gurlchecker imlib leafpad libedit lostirc pam_mount pam_mysql pam_script python-cvstoys screem t1lib t1utils - 43 packages that moved to core FE-ACCEPT packages stats: - 1579 accepted, closed package reviews - 21 accepted, closed package reviews not in repo - 16 accepted, closed package reviews not in owners - 12 accepted, open package reviews older than 4 weeks; - 8 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 96 open tickets - 23 tickets with no activity in eight weeks - 13 tickets with no activity in four weeks - 6 closed tickets FE-NEW packages stats: - 137 open tickets - 24 tickets with no activity in eight weeks - 42 tickets with no activity in four weeks FE-NEEDSPONSOR packages stats: - 36 open tickets - 4 tickets with no activity in eight weeks - 18 tickets with no activity in four weeks FE-LEGAL packages stats: - 1 open tickets FE-GUIDELINES packages stats: - 2 open tickets - 1 tickets with no activity in eight weeks OPEN-BUGS packages stats: - 210 open tickets - 95 tickets with no activity in eight weeks - 32 tickets with no activity in four weeks CVS stats: - 2556 packages with a devel directory - 8 packages with no owners entry SDL_Pango eclipse-emf gtk-sharp itpp libopts php-pecl-Fileinfo pungi pygpgme - 191 packages were dropped from extras Maintainers stats: - 234 maintainers - 2 inactive maintainers with open bugs - 1 inactive maintainers Dropped FC packages: - 282 packages were dropped from core since FC 1 Comps.xml files stats: - 848 packages in comps-fe7 file - 476 packages missing from comps-fe7 file - 848 packages in comps-fe6 file - 467 packages missing from comps-fe6 file - 1 packages in comps-fe6 but not in repo From Christian.Iseli at licr.org Thu Nov 23 14:26:10 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 23 Nov 2006 15:26:10 +0100 Subject: comps.xml is now pushed automatically Message-ID: <20061123152610.65823727@ludwig-alpha.unil.ch> Hi folks, Better late than never, I'd like to announce that the FE comps.xml.in files are now pushed automatically along when there is a package sign/push to the repo. This is all thanks to Michael Schwendt's hard work, so let's have a round of applause to thank him (and a beer or two if I ever meet him in person :-) ) Now that this is done, we could discuss some ideas how to make the comps.xml file even more useful. For instance I'd like to see a few more groups in there, to get a better classification... More on this probably next week from me, but feel free to start a discussion already. Cheers, Christian From chris.stone at gmail.com Thu Nov 23 14:56:59 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 23 Nov 2006 06:56:59 -0800 Subject: comps.xml is now pushed automatically In-Reply-To: <20061123152610.65823727@ludwig-alpha.unil.ch> References: <20061123152610.65823727@ludwig-alpha.unil.ch> Message-ID: On 11/23/06, Christian Iseli wrote: > Hi folks, > > Better late than never, I'd like to announce that the FE comps.xml.in > files are now pushed automatically along when there is a package > sign/push to the repo. > > This is all thanks to Michael Schwendt's hard work, so let's have a > round of applause to thank him (and a beer or two if I ever meet > him in person :-) ) > > Now that this is done, we could discuss some ideas how to make the > comps.xml file even more useful. For instance I'd like to see a few > more groups in there, to get a better classification... > > More on this probably next week from me, but feel free to start a > discussion already. I noticed that the Web Development category is currently empty, and I have a lot of php-pear packages which could be categorized as "Web Development". Personally I think it would be great to have php, perl, python, ruby, etc modules in comps but if people think these packages do not belong in comps that is fine with me (less work for me to do). From nicolas.mailhot at laposte.net Thu Nov 23 15:01:05 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 23 Nov 2006 16:01:05 +0100 (CET) Subject: comps.xml is now pushed automatically In-Reply-To: <20061123152610.65823727@ludwig-alpha.unil.ch> References: <20061123152610.65823727@ludwig-alpha.unil.ch> Message-ID: <9408.192.54.193.51.1164294065.squirrel@rousalka.dyndns.org> Le Jeu 23 novembre 2006 15:26, Christian Iseli a ?crit : > Hi folks, > > Better late than never, I'd like to announce that the FE comps.xml.in > files are now pushed automatically along when there is a package > sign/push to the repo. BTW do we have an authoritative DTD or schema for the comps.xml file somewhere? Would it be worthwile to create one (in relax-ng or XML schema) ? I'me pretty sick of using --novalid in XML tools. Regards, -- Nicolas Mailhot From ville.skytta at iki.fi Thu Nov 23 17:07:45 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 23 Nov 2006 19:07:45 +0200 Subject: Bunch of orphaned/potentially orphaned packages Message-ID: <1164301665.9565.31.camel@viper.local> Due to time constraints and in some cases the fact that I haven't been using said package for some time, the following packages are in need of a new maintainer: Potentially orphaned (will keep an eye on them for now, but a new active maintainer would be welcome): - cabextract - ccid (for < FE6 only, included in FC6+) - ctapi-common - cvsgraph - cvsweb - ksensors - openct - opensc - pcsc-lite (for < FE6 only, included in FC6+) - pcsc-perl - pcsc-tools - perl-IPC-Run - ucl - upx - xmms - xmms-alarm - xmms-modplug Orphaned (won't be looking after these): - gdome2 - perl-String-Ediff - python-htmltmpl - python-id3 More info: http://fedoraproject.org/wiki/Extras/OrphanedPackages From pnasrat at redhat.com Thu Nov 23 17:16:13 2006 From: pnasrat at redhat.com (Paul Nasrat) Date: Thu, 23 Nov 2006 17:16:13 +0000 Subject: comps.xml is now pushed automatically In-Reply-To: <9408.192.54.193.51.1164294065.squirrel@rousalka.dyndns.org> References: <20061123152610.65823727@ludwig-alpha.unil.ch> <9408.192.54.193.51.1164294065.squirrel@rousalka.dyndns.org> Message-ID: <1164302173.1539.88.camel@enki.eridu> On Thu, 2006-11-23 at 16:01 +0100, Nicolas Mailhot wrote: > Le Jeu 23 novembre 2006 15:26, Christian Iseli a ?crit : > > Hi folks, > > > > Better late than never, I'd like to announce that the FE comps.xml.in > > files are now pushed automatically along when there is a package > > sign/push to the repo. > > BTW do we have an authoritative DTD or schema for the comps.xml file > somewhere? Would it be worthwile to create one (in relax-ng or XML schema) > ? I'me pretty sick of using --novalid in XML tools. No we don't. I want to split some of the stuff out into it's own files - eg categories really only apply to display within tools so it's not the right place. yum/rpm repodata supports arbitrary metadata now so I'd like to break things up. Schemas for comps.xml as current and also repomd as generated by createrepo would be welcome. Paul From nicolas.mailhot at laposte.net Thu Nov 23 17:24:00 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 23 Nov 2006 18:24:00 +0100 Subject: comps.xml is now pushed automatically In-Reply-To: <1164302173.1539.88.camel@enki.eridu> References: <20061123152610.65823727@ludwig-alpha.unil.ch> <9408.192.54.193.51.1164294065.squirrel@rousalka.dyndns.org> <1164302173.1539.88.camel@enki.eridu> Message-ID: <1164302650.5701.2.camel@rousalka.dyndns.org> Le jeudi 23 novembre 2006 ? 17:16 +0000, Paul Nasrat a ?crit : > On Thu, 2006-11-23 at 16:01 +0100, Nicolas Mailhot wrote: > > BTW do we have an authoritative DTD or schema for the comps.xml file > > somewhere? Would it be worthwile to create one (in relax-ng or XML schema) > > ? I'me pretty sick of using --novalid in XML tools. > > No we don't. I want to split some of the stuff out into it's own files > - eg categories really only apply to display within tools so it's not > the right place. yum/rpm repodata supports arbitrary metadata now so > I'd like to break things up. > > Schemas for comps.xml as current and also repomd as generated by > createrepo would be welcome. Ok, I'll look at it when I have some free time then (if no one beats me to it) Regards, -- Nicolas Mailhot From nphilipp at redhat.com Thu Nov 23 18:12:52 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 23 Nov 2006 19:12:52 +0100 Subject: Vacation 2006-11-25 - 2006-12-10 Message-ID: <1164305572.16464.1.camel@gibraltar.stuttgart.redhat.com> Hi there, FYI, I'll be on vacation 2006-11-25 - 2006-12-10 and won't be able to access the Internet during the first half. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase 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 veillard at redhat.com Thu Nov 23 18:15:03 2006 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 23 Nov 2006 13:15:03 -0500 Subject: comps.xml is now pushed automatically In-Reply-To: <1164302173.1539.88.camel@enki.eridu> References: <20061123152610.65823727@ludwig-alpha.unil.ch> <9408.192.54.193.51.1164294065.squirrel@rousalka.dyndns.org> <1164302173.1539.88.camel@enki.eridu> Message-ID: <20061123181503.GU26540@redhat.com> On Thu, Nov 23, 2006 at 05:16:13PM +0000, Paul Nasrat wrote: > On Thu, 2006-11-23 at 16:01 +0100, Nicolas Mailhot wrote: > > Le Jeu 23 novembre 2006 15:26, Christian Iseli a ?crit : > > > Hi folks, > > > > > > Better late than never, I'd like to announce that the FE comps.xml.in > > > files are now pushed automatically along when there is a package > > > sign/push to the repo. > > > > BTW do we have an authoritative DTD or schema for the comps.xml file > > somewhere? Would it be worthwile to create one (in relax-ng or XML schema) > > ? I'me pretty sick of using --novalid in XML tools. > > No we don't. I want to split some of the stuff out into it's own files > - eg categories really only apply to display within tools so it's not > the right place. yum/rpm repodata supports arbitrary metadata now so > I'd like to break things up. > > Schemas for comps.xml as current and also repomd as generated by > createrepo would be welcome. A few years ago I created a Relax-NG schemas for comps.xml, it's certainly way out of date but may be used as a starting point, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -------------- next part -------------- true false true false default optional default mandatory optional From gronslet at gmail.com Thu Nov 23 22:22:09 2006 From: gronslet at gmail.com (MartinG) Date: Thu, 23 Nov 2006 23:22:09 +0100 Subject: Would it be possible to put OpenSync (with plugins) in Extras? Message-ID: Hi list. (I have just subscribed, so sorry if this has already been requested.) I repeat my question originally sent to the kde-redhat list (see below): Would it be possible to include opensync (www.opensync.org) in fedora-extras? Original post with answer from the kde-redhat-list: On Thu, 2006-11-23 at 17:41 +0100, MartinG wrote: > Hi list. > > I am trying to make opensync [1] work on my FC6 laptop, but have run > into some problems, and some of them are rpm related. > > OpenSync is a synchronization framework that is platform and > distribution independent. It can be used to synchronize cell phones > with i.e. KDE-PIM (Kontact, Kaddessbook, KNotes, etc) > > Currently, I have tried the FC5 yum repository from opensuse [2], but > not all components will install. For example Kitchensync-opensync will > fail, see the opensync ticket [3]. I believe this is because of a > buggy .spec file. Maybe also this is related to ticket 388 [4]. > > Next week one of the opensync developers will fix the irmc-plugin so > it will work with my SE T610 phone over bluetooth (OBEX), and I would > guess many of the people watching this list also would love to "get > synchronized". Although opensync is not yet a stable release, I think > that if at least the installation is smooth, more people will > contribute with testing, and the job for the developers will be > easier... > > So, would it be possible to build good FC6 rpms for opensync (and the > opensync enabled KDE Kitchensync)? Rex? Why KDE-RedHat? It looks like a prime candidate for fedora-extra? I'd suggest you post a message in fedora-extras-list at redhat.com [1] - Gilboa [1] http://www.redhat.com/mailman/listinfo/fedora-extras-list original refs: From nicolas.mailhot at laposte.net Thu Nov 23 21:18:02 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 23 Nov 2006 22:18:02 +0100 Subject: comps.xml is now pushed automatically In-Reply-To: <20061123181503.GU26540@redhat.com> References: <20061123152610.65823727@ludwig-alpha.unil.ch> <9408.192.54.193.51.1164294065.squirrel@rousalka.dyndns.org> <1164302173.1539.88.camel@enki.eridu> <20061123181503.GU26540@redhat.com> Message-ID: <1164316682.11035.32.camel@rousalka.dyndns.org> Le jeudi 23 novembre 2006 ? 13:15 -0500, Daniel Veillard a ?crit : > A few years ago I created a Relax-NG schemas for comps.xml, it's certainly > way out of date but may be used as a starting point, Thanks Daniel, unfortunately I had already started my own schema, so don't get offended if mine is not derived from yours (I did look at it ? unfortunately it seems you blocked on the same parts as me) Here is a very raw Relax-NG comps schema. Bear in mind I wrote it after skimming 5 min for the first time the Relax NG tutorial, so my style may not be perfect 1. it validates FC-devel and FC-6 x86_64 comps files 2. it does not validate FE-devel and FE-6 x86_64 comps because I've forbidden empty groups. I could allow them but IMHO stricter is better 3. I couldn't find any FC-5 area comps files 4. I fails on FC-4 comps files, as the syntax used at that time was different More testing of other comps files (other arches, repos, comps with mistakes) and with other xml parsers (I used rawhide xmllint) would be appreciated. To test a comps file just change the root element to : (no avoiding it as we've only specified a bogus DTD and no namespace so far) Some questions (ok, a _lot_ of questions) 1. What namespace should comps use? a. a namespace associated to Red Hat, the Fedora project, some other entity (yum, rpm, whatever)? b. should we go URN (compact but requires reclaration of the URN root) or URL for the namespace (if we go URL It'd be real nice to have a persistent URL with the schema and eventually some doc there)? c. do we want to version the schema (the FC4 example shows the comps syntax changed in the past) or will we commit to a stable grammar from now on? 2. do we want to keep the metapackage element? It's used *once* in 6 & devel, and I haven't the faintest idea what its form can be (Daniel's schema shows it was already a big mystery in the past) 3. all the constraints I declared need to be reviewed by an anaconda/yum/createrepo expert. They match what I've seen in actual comps files but the rules the tools want may be slightly different 4. likewise, there are probably other constraints (typing...) I missed 5. is it absolutely necessary to mangle element names in comps.xml.in? That would require a *separate* schema for comps.xml.in and probably namespace change when comps.xml.in is transformed in comps.xml 6. What package should own the schema and install/register it on the system? Regards, -- Nicolas Mailhot From buildsys at fedoraproject.org Thu Nov 23 23:17:46 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 23 Nov 2006 18:17:46 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-23 Message-ID: <20061123231746.91EBD15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 19 apt-0.5.15lorg3.2-8.fc7 celestia-1.4.1-7.fc7 d4x-2.5.7.1-3.fc7 fedora-package-config-apt-6.89-6 gcin-1.3.0.1-2.fc7 jd-1.8.1-0.1.cvs061123.fc7 libtelepathy-0.0.39-1.fc7 linphone-1.5.1-2.fc7 liquidwar-5.6.3-1.fc7 mediawiki-1.8.2-6.fc7 mhonarc-2.6.16-3.fc7 netcdf-perl-1.2.3-2.fc7 openbox-3.3.1-4.fc7 openvrml-0.16.1-4.fc7 perl-Sub-Install-0.924-1.fc7 ppracer-0.3.1-8.fc7 pstoedit-3.44-5.fc7 scorched3d-40.1d-1.fc7 streamtuner-0.99.99-15.fc7 Packages built and released for Fedora Extras 6: 18 apt-0.5.15lorg3.2-8.fc6 bsd-games-2.17-16.fc6 celestia-1.4.1-7.fc6 fedora-package-config-apt-6-5 flow-tools-0.68-12.fc6 gcin-1.3.0.1-2.fc6 gnomesword-2.1.9-1.fc6 labyrinth-0.3-1.fc6 linphone-1.5.1-2.fc6 mediawiki-1.8.2-6.fc6 mhonarc-2.6.16-3.fc6 openvrml-0.16.1-4.fc6 perl-Sub-Install-0.924-1.fc6 pstoedit-3.44-5.fc6 scorched3d-40.1d-1.fc6 streamtuner-0.99.99-14.fc6.1 sword-1.5.9-1.fc6 zope-2.9.5-1.fc6 Packages built and released for Fedora Extras 5: 10 apt-0.5.15lorg3.2-8.fc5 celestia-1.4.1-7.fc5 flow-tools-0.68-12.fc5 gcin-1.3.0.1-1.fc5 gnomesword-2.1.9-1.fc5 mhonarc-2.6.16-3.fc5 perl-Sub-Install-0.924-1.fc5 pstoedit-3.44-4.fc5 scorched3d-40.1d-1.fc5 sword-1.5.9-1.fc5 Packages built and released for Fedora Extras 4: 4 apt-0.5.15lorg3.2-8.fc4 flow-tools-0.68-12.fc4 gcin-1.3.0.1-1.fc4 zope-2.8.3-6.fc4.1 Packages built and released for Fedora Extras 3: 3 flow-tools-0.68-12.fc3 gcin-1.3.0.1-1.fc3 zope-2.8.0-5.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri Nov 24 00:27:03 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 24 Nov 2006 00:27:03 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-23 Message-ID: <20061124002703.26742.13125@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- Axel.Thimm AT ATrpms.net synaptic - 0.57.2-5.1.fc6.i386 synaptic - 0.57.2-5.1.fc6.i386 synaptic - 0.57.2-5.1.fc6.ppc synaptic - 0.57.2-5.1.fc6.ppc synaptic - 0.57.2-5.1.fc6.x86_64 synaptic - 0.57.2-5.1.fc6.x86_64 Jochen AT herr-schmitt.de blender - 2.42a-5.fc7.i386 blender - 2.42a-5.fc7.ppc blender - 2.42a-5.fc7.x86_64 andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 (23 days) centericq - 4.21.0-8.fc6.ppc (23 days) centericq - 4.21.0-8.fc6.x86_64 (23 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (26 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (26 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (26 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (26 days) orange - 0.3-3.cvs20051118.fc6.i386 (30 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (54 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (54 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (54 days) braden AT endoframe.com openvrml - 0.16.1-4.fc7.i386 openvrml - 0.16.1-4.fc7.i386 openvrml - 0.16.1-4.fc7.ppc openvrml - 0.16.1-4.fc7.x86_64 openvrml-devel - 0.16.1-4.fc7.i386 openvrml-devel - 0.16.1-4.fc7.i386 openvrml-devel - 0.16.1-4.fc7.ppc openvrml-devel - 0.16.1-4.fc7.x86_64 dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (69 days) plague - 0.4.4.1-2.fc3.noarch (69 days) plague - 0.4.4.1-2.fc4.noarch (69 days) plague - 0.4.4.1-2.fc4.noarch (69 days) plague - 0.4.4.1-2.fc4.noarch (69 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (45 days) linphone - 1.2.0-4.fc5.ppc (45 days) linphone - 1.2.0-4.fc5.x86_64 (45 days) karlthered AT gmail.com gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.i386 gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.i386 gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.ppc gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.x86_64 matthias AT rpmforge.net php-eaccelerator - 5.1.6_0.9.5-2.fc7.i386 (7 days) php-eaccelerator - 5.1.6_0.9.5-2.fc7.ppc (7 days) php-eaccelerator - 5.1.6_0.9.5-2.fc7.x86_64 (7 days) oliver AT linux-kernel.at syck-php - 0.55-10.fc6.i386 (7 days) syck-php - 0.55-10.fc6.ppc (7 days) syck-php - 0.55-10.fc6.x86_64 (7 days) syck-php - 0.55-9.fc5.i386 (35 days) syck-php - 0.55-9.fc5.ppc (35 days) syck-php - 0.55-9.fc5.x86_64 (35 days) pertusus AT free.fr grads - 1.9b4-19.fc7.i386 (7 days) grads - 1.9b4-19.fc7.ppc (7 days) grads - 1.9b4-19.fc7.x86_64 (7 days) petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 (20 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (20 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (20 days) ghc642-gtk2hs - 0.9.10-4.fc6.i386 (20 days) ghc642-gtk2hs - 0.9.10-4.fc6.ppc (20 days) ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 (20 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 (20 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc (20 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 (20 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (25 days) tcallawa AT redhat.com gambas-runtime - 1.0.17-6.fc7.i386 gambas-runtime - 1.0.17-6.fc7.ppc Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- blender-2.42a-5.fc7.ppc requires libgettextlib-0.15.so centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 gambas-runtime-1.0.17-6.fc7.ppc requires libgettextlib-0.15.so ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 grads-1.9b4-19.fc7.ppc requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.ppc requires gecko-libs = 0:2.0 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 openvrml-0.16.1-4.fc7.ppc requires firefox = 0:1.5.0.8 openvrml-devel-0.16.1-4.fc7.ppc requires firefox-devel = 0:1.5.0.8 php-eaccelerator-5.1.6_0.9.5-2.fc7.ppc requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.ppc requires php = 0:5.1.6 synaptic-0.57.2-5.1.fc6.ppc requires libapt-pkg-libc6.4-6.so.2 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- blender-2.42a-5.fc7.x86_64 requires libgettextlib-0.15.so()(64bit) centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 grads-1.9b4-19.fc7.x86_64 requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.i386 requires gecko-libs = 0:2.0 gtkmozembedmm-1.4.2.cvs20060817-5.fc7.x86_64 requires gecko-libs = 0:2.0 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) openvrml-0.16.1-4.fc7.i386 requires firefox = 0:1.5.0.8 openvrml-0.16.1-4.fc7.x86_64 requires firefox = 0:1.5.0.8 openvrml-devel-0.16.1-4.fc7.i386 requires firefox-devel = 0:1.5.0.8 openvrml-devel-0.16.1-4.fc7.x86_64 requires firefox-devel = 0:1.5.0.8 orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 php-eaccelerator-5.1.6_0.9.5-2.fc7.x86_64 requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.x86_64 requires php = 0:5.1.6 synaptic-0.57.2-5.1.fc6.x86_64 requires libapt-pkg-libc6.4-6.so.2()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- blender-2.42a-5.fc7.i386 requires libgettextlib-0.15.so centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 gambas-runtime-1.0.17-6.fc7.i386 requires libgettextlib-0.15.so ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 grads-1.9b4-19.fc7.i386 requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.i386 requires gecko-libs = 0:2.0 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 openvrml-0.16.1-4.fc7.i386 requires firefox = 0:1.5.0.8 openvrml-devel-0.16.1-4.fc7.i386 requires firefox-devel = 0:1.5.0.8 php-eaccelerator-5.1.6_0.9.5-2.fc7.i386 requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.i386 requires php = 0:5.1.6 synaptic-0.57.2-5.1.fc6.i386 requires libapt-pkg-libc6.4-6.so.2 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- synaptic-0.57.2-5.1.fc6.ppc requires libapt-pkg-libc6.4-6.so.2 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- synaptic-0.57.2-5.1.fc6.x86_64 requires libapt-pkg-libc6.4-6.so.2()(64bit) Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- synaptic-0.57.2-5.1.fc6.i386 requires libapt-pkg-libc6.4-6.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: Axel.Thimm AT ATrpms.net package: synaptic - 0.57.2-5.1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libapt-pkg-libc6.4-6.so.2 package: synaptic - 0.57.2-5.1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libapt-pkg-libc6.4-6.so.2()(64bit) package: synaptic - 0.57.2-5.1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libapt-pkg-libc6.4-6.so.2 package: synaptic - 0.57.2-5.1.fc6.ppc from fedora-extras-6-ppc unresolved deps: libapt-pkg-libc6.4-6.so.2 package: synaptic - 0.57.2-5.1.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: libapt-pkg-libc6.4-6.so.2()(64bit) package: synaptic - 0.57.2-5.1.fc6.i386 from fedora-extras-6-i386 unresolved deps: libapt-pkg-libc6.4-6.so.2 ====================================================================== New report for: braden AT endoframe.com package: openvrml - 0.16.1-4.fc7.ppc from fedora-extras-development-ppc unresolved deps: firefox = 0:1.5.0.8 package: openvrml-devel - 0.16.1-4.fc7.ppc from fedora-extras-development-ppc unresolved deps: firefox-devel = 0:1.5.0.8 package: openvrml - 0.16.1-4.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: firefox = 0:1.5.0.8 package: openvrml-devel - 0.16.1-4.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: firefox-devel = 0:1.5.0.8 package: openvrml-devel - 0.16.1-4.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: firefox-devel = 0:1.5.0.8 package: openvrml - 0.16.1-4.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: firefox = 0:1.5.0.8 package: openvrml-devel - 0.16.1-4.fc7.i386 from fedora-extras-development-i386 unresolved deps: firefox-devel = 0:1.5.0.8 package: openvrml - 0.16.1-4.fc7.i386 from fedora-extras-development-i386 unresolved deps: firefox = 0:1.5.0.8 ====================================================================== New report for: Jochen AT herr-schmitt.de package: blender - 2.42a-5.fc7.ppc from fedora-extras-development-ppc unresolved deps: libgettextlib-0.15.so package: blender - 2.42a-5.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgettextlib-0.15.so()(64bit) package: blender - 2.42a-5.fc7.i386 from fedora-extras-development-i386 unresolved deps: libgettextlib-0.15.so ====================================================================== New report for: tcallawa AT redhat.com package: gambas-runtime - 1.0.17-6.fc7.ppc from fedora-extras-development-ppc unresolved deps: libgettextlib-0.15.so package: gambas-runtime - 1.0.17-6.fc7.i386 from fedora-extras-development-i386 unresolved deps: libgettextlib-0.15.so From tmz at pobox.com Fri Nov 24 04:19:54 2006 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 23 Nov 2006 23:19:54 -0500 Subject: An updated libgpod for core and python bindings for extras In-Reply-To: <4564A750.8040309@leemhuis.info> References: <20061122060726.GP32659@psilocybe.teonanacatl.org> <4564A750.8040309@leemhuis.info> Message-ID: <20061124041954.GA32586@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thorsten Leemhuis wrote: > I don't see any problems here as long as nothing from Core get > replaced. Yes, care will be taken to only package the parts that aren't in core. And as the package will require libgpod from core, I'll track that closely and work with the maintainer there (Alexander Larsson currently). > Just submit it for review. Done[1]. Thanks Thorsten. [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217066 - -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== If God had meant for us to be naked, we would have been born that way. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iQFDBAEBAgAtBQJFZnLqJhhodHRwOi8vd3d3LnBvYm94LmNvbS9+dG16L3BncC90 bXouYXNjAAoJEEMlk4u+rwzjeAUIAJmInrK5kQ53wuJqPdo94QJXyuNML/RN5/nK yZyrd79FvWy21qdpo30LNIsWStZqU7eN5dc4b33JaBD6D9/BUR33Ekd/PEDkA7ud UNtUe8FkCEWJpYZk3hnjeCFbAzgnOYAd1s+HUf6v98a+N4vhtNyBVQUmsidCRYln 1PAyuezrgdeX/313ppfWNypHyhVyRkL9dvXAwNjqjb2a4QokB1S9vfBXysFQVpFQ VPAxG+KORK0lCGBsrAFaX6KFoUdVX5JLa3tGrHHRQy4cu47DbviHg7h711slIRdc iTM3QwA9obrFCj7Mgckb9f4XQ9qL99D8a22O4odQ9rbJTIG38is= =lNaf -----END PGP SIGNATURE----- From giallu at gmail.com Fri Nov 24 07:47:29 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 24 Nov 2006 08:47:29 +0100 Subject: Would it be possible to put OpenSync (with plugins) in Extras? In-Reply-To: References: Message-ID: On 11/23/06, MartinG wrote: > Hi list. > (I have just subscribed, so sorry if this has already been requested.) > > I repeat my question originally sent to the kde-redhat list (see below): > Would it be possible to include opensync (www.opensync.org) in fedora-extras? AFAICS, it is already packaged: yum search opensync show many hits, like: multisync multisync-gui and a bunch of: libopensync-plugin-* Are you looking for something else? From gronslet at gmail.com Fri Nov 24 09:03:39 2006 From: gronslet at gmail.com (MartinG) Date: Fri, 24 Nov 2006 10:03:39 +0100 Subject: Would it be possible to put OpenSync (with plugins) in Extras? In-Reply-To: References: Message-ID: Yes, sorry I actually pressed "send" instead of "save" on my initial post... What I would like to see, is a Kitchensync version that is compatible with opensync. AFAIK, the current Kitchensync does not make use of the new framework. Currently, in the opensuse yum repo [2], this is the info on the package: Name : kitchensync-opensync Arch : i386 Version: 0.01_SVN574743 Release: 2.7 Size : 297 k Repo : OpenSync Summary: Kitchensync - OpenSync integration branch Description: This is a version of Kitchensync using OpenSync as the synchronization engine. I have not been able to install this "kitchensync-opensync" on FC6, see [3]. Also, opensync is now available in version 0.20 (in extras I could only find the 0.19 version) (In particular, I would like to "yum install" everything needed to sync my phone over bluetooth with KDE-PIM, and I believe that opensync 0.20 will make this possible.) By the way, these refs should have been in my original post: [1] OpenSync: http://www.opensync.org/ [2] Opensuse rpms: http://software.opensuse.org/download/OpenSync/Fedora_Core_5/ [3] Kitchensync-opensync build error: http://www.opensync.org/ticket/386 [4] Possible "--prefix" error: http://www.opensync.org/ticket/388 all the best -MartinG On 11/24/06, Gianluca Sforna wrote: > On 11/23/06, MartinG wrote: > > Hi list. > > (I have just subscribed, so sorry if this has already been requested.) > > > > I repeat my question originally sent to the kde-redhat list (see below): > > Would it be possible to include opensync (www.opensync.org) in fedora-extras? > > AFAICS, it is already packaged: > > yum search opensync > > show many hits, like: > multisync > multisync-gui > > and a bunch of: > > libopensync-plugin-* > > Are you looking for something else? > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From laurent.rineau__fedora_extras at normalesup.org Fri Nov 24 10:02:43 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Fri, 24 Nov 2006 11:02:43 +0100 Subject: rpms/streamtuner/FC-6 streamtuner.spec,1.10,1.11 In-Reply-To: <20061123145256.4e6bc426.bugs.michael@gmx.net> References: <200611231318.kANDIeAu000697@cvs-int.fedora.redhat.com> <20061123145256.4e6bc426.bugs.michael@gmx.net> Message-ID: <200611241102.44009@rineau.schtroumpfette> On Thursday 23 November 2006 14:52, Michael Schwendt wrote: > On Thu, 23 Nov 2006 08:18:40 -0500, Matthias Haase (endur) wrote: > > Author: endur > > > > Update of /cvs/extras/rpms/streamtuner/FC-6 > > > > Log Message: > > bump up release once again proper formated > > > > -Release: 14%{?dist}.1 > > That one was okay. Most-significant portion left of %dist, > least-significant portion to the very right. > > > +Release: 14.2%{?dist} > > 14.2 is "higher than" 14.fc and hence not a good idea when using %{?dist} I am not sure to understand. The following guidelines: http://fedoraproject.org/wiki/Packaging/DistTag#head-5fff04551074fb311a96352be7e7cc3006c90f25 indicate to put the dist tag at the very end of the release tag. If the previous release tag of streamtuner had been "14.1%{?dist}", would it have been correct? (sorry if I failed to conjugate that sequence correctly.) From laurent.rineau__fedora_extras at normalesup.org Fri Nov 24 10:05:49 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Fri, 24 Nov 2006 11:05:49 +0100 Subject: Vacation 2006-11-25 - 2006-12-10 In-Reply-To: <1164305572.16464.1.camel@gibraltar.stuttgart.redhat.com> References: <1164305572.16464.1.camel@gibraltar.stuttgart.redhat.com> Message-ID: <200611241105.50091@rineau.schtroumpfette> On Thursday 23 November 2006 19:12, Nils Philippsen wrote: > Hi there, > > FYI, I'll be on vacation 2006-11-25 - 2006-12-10 and won't be able to > access the Internet during the first half. You should have a look at http://fedoraproject.org/wiki/Vacation and fill a row. From j.w.r.degoede at hhs.nl Fri Nov 24 10:15:52 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 24 Nov 2006 11:15:52 +0100 Subject: unowned directory problem with /etc/logrotate.d Message-ID: <4566C658.8060307@hhs.nl> Hi all, Many packages drop config files for logrotate in /etc/logrotate.d. without requiring logrotate, which is the owner of /etc/logrotate.d, thus potentially leading to an unowned /etc/logrotate.d for users who don't want logrotate and thus remove it. I see 2 solutions for this: 1) Add "Requires: logrotate" to all packages which put files in /etc/logrotate.d. IMHO this is not good as the user should be able to choose if he wants logrotate or not. 2) Add /etc/logrotate.d to the filesystem package, this is my preferred solution. I would like to hear what others think, before filing a bug against filesystem requesting 2) . Regards, Hans From enrico.scholz at informatik.tu-chemnitz.de Fri Nov 24 10:47:30 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 24 Nov 2006 11:47:30 +0100 Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: <4566C658.8060307@hhs.nl> (Hans de Goede's message of "Fri, 24 Nov 2006 11:15:52 +0100") References: <4566C658.8060307@hhs.nl> Message-ID: <874pspruil.fsf@kosh.bigo.ensc.de> j.w.r.degoede at hhs.nl (Hans de Goede) writes: > Many packages drop config files for logrotate in > /etc/logrotate.d. without requiring logrotate, which is the owner of > /etc/logrotate.d, thus potentially leading to an unowned > /etc/logrotate.d for users who don't want logrotate and thus remove > it. > > I see 2 solutions for this: > 1) Add "Requires: logrotate" to all packages which put files in > /etc/logrotate.d. IMHO this is not good as the user should be > able to choose if he wants logrotate or not. > 2) Add /etc/logrotate.d to the filesystem package, this is my preferred > solution. or 3) package logrotate files in an own subpackage which has strict Requires: I would tend to 2 or 3; but dirs like /etc/cron.d, /usr/share/aclocal should be handled by 2 too. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Fri Nov 24 10:57:38 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 24 Nov 2006 11:57:38 +0100 Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: <874pspruil.fsf@kosh.bigo.ensc.de> References: <4566C658.8060307@hhs.nl> <874pspruil.fsf@kosh.bigo.ensc.de> Message-ID: <4566D022.2070404@hhs.nl> Enrico Scholz wrote: > j.w.r.degoede at hhs.nl (Hans de Goede) writes: > >> Many packages drop config files for logrotate in >> /etc/logrotate.d. without requiring logrotate, which is the owner of >> /etc/logrotate.d, thus potentially leading to an unowned >> /etc/logrotate.d for users who don't want logrotate and thus remove >> it. >> >> I see 2 solutions for this: > >> 1) Add "Requires: logrotate" to all packages which put files in >> /etc/logrotate.d. IMHO this is not good as the user should be >> able to choose if he wants logrotate or not. >> 2) Add /etc/logrotate.d to the filesystem package, this is my preferred >> solution. > > or > > 3) package logrotate files in an own subpackage which has strict Requires: > > > I would tend to 2 or 3; but dirs like /etc/cron.d, /usr/share/aclocal > should be handled by 2 too. > 3 is rather ugly IMHO, so I still vote for 2, yes we may need this for other dirs too, but those need to be discussed and then filed seperately free feel to start threads for these. Regards, Hans From nicolas.mailhot at laposte.net Fri Nov 24 12:30:56 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 24 Nov 2006 13:30:56 +0100 (CET) Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: <4566C658.8060307@hhs.nl> References: <4566C658.8060307@hhs.nl> Message-ID: <18132.192.54.193.51.1164371456.squirrel@rousalka.dyndns.org> Le Ven 24 novembre 2006 11:15, Hans de Goede a ?crit : > Hi all, > > Many packages drop config files for logrotate in /etc/logrotate.d. without > requiring logrotate, which is the owner of > /etc/logrotate.d, thus potentially leading to an unowned /etc/logrotate.d > for users who don't want logrotate and thus remove it. > > I see 2 solutions for this: > 1) Add "Requires: logrotate" to all packages which put files in > /etc/logrotate.d. IMHO this is not good as the user should be able > to choose if he wants logrotate or not. > 2) Add /etc/logrotate.d to the filesystem package, this is my preferred > solution. 3. add Requires: /etc/logrotate.d to /etc/logrotate.d users -- Nicolas Mailhot From laurent.rineau__fedora_extras at normalesup.org Fri Nov 24 12:31:29 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Fri, 24 Nov 2006 13:31:29 +0100 Subject: how to patch configure.ac and not require autotools In-Reply-To: <448CD02C.2050805@kobold.org> References: <1150017630.3481.22.camel@eagle.danny.cz> <878xo34lpw.fsf@kosh.bigo.ensc.de> <448CD02C.2050805@kobold.org> Message-ID: <200611241331.29447@rineau.schtroumpfette> I would like to revive the following old discussion, five months ago (part of it is quoted bellow). It would be nice to have usefull tips, or perhaps recommendations, in the wiki. On Monday 12 June 2006 04:23, Wart wrote: > Enrico Scholz wrote: > > wart at kobold.org (Wart) writes: > >>'touch', not patch. > >> > >>I run into this quite a lot. In addition to patching both configure.ac > >>and configure.in, you'll need to 'touch' all of the "Makefile.in" files > >>in the package, since they likely have a dependency on configure.in. > > > > That's only needed for projects whose authors do not use > > AM_MAINTAINER_MODE. > > > > Instead of touching all Makefile.in's you could restore the original > > > > timestamp with: > > | touch -r configure configure.stamp > > | ... patch configure ... > > | touch -r configure.stamp configure > > That's an even better solution. Thanks for the tip. > > --Mike From bugs.michael at gmx.net Fri Nov 24 13:00:19 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 24 Nov 2006 14:00:19 +0100 Subject: rpms/streamtuner/FC-6 streamtuner.spec,1.10,1.11 In-Reply-To: <200611241102.44009@rineau.schtroumpfette> References: <200611231318.kANDIeAu000697@cvs-int.fedora.redhat.com> <20061123145256.4e6bc426.bugs.michael@gmx.net> <200611241102.44009@rineau.schtroumpfette> Message-ID: <20061124140019.2f42fdae.bugs.michael@gmx.net> On Fri, 24 Nov 2006 11:02:43 +0100, Laurent Rineau wrote: > > > Update of /cvs/extras/rpms/streamtuner/FC-6 > > > > > > Log Message: > > > bump up release once again proper formated > > > > > > -Release: 14%{?dist}.1 > > > > That one was okay. Most-significant portion left of %dist, > > least-significant portion to the very right. > > > > > +Release: 14.2%{?dist} > > > > 14.2 is "higher than" 14.fc and hence not a good idea when using %{?dist} > > I am not sure to understand. The following guidelines: > http://fedoraproject.org/wiki/Packaging/DistTag#head-5fff04551074fb311a96352be7e7cc3006c90f25 > indicate to put the dist tag at the very end of the release tag. It is assumed that the release tag consists of just a single integer and that %{?dist} is appended to that. > If the previous release tag of streamtuner had been "14.1%{?dist}", would it > have been correct? (sorry if I failed to conjugate that sequence correctly.) 14.1%{?dist} is invalid, too, because "1" is higher than "fc". And due to that, 14.1.fc5 would be higher than 14.fc6 and 14.fc7. Now, if you tried to avoid that by building as 14.1.fcN for all N dists, this would be unnecessary and error-prone inflation of release numbers. Correct would be 14%{?dist} < 15%{?dist} < 16%{?dist} < ... and so on. If there's ever reason to fix something only in release 14.fc6, without bumping release to 15, so that it would be "newer than" 14.fc7, the release tag can be increased at the very _right_: 14%{?dist}.1 < 14%{?dist}.2 < ... resulting in 14.fc6 < 14.fc6.1 < 14.fc6.2 < 14.fc7 From laurent.rineau__fedora_extras at normalesup.org Fri Nov 24 13:04:37 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Fri, 24 Nov 2006 14:04:37 +0100 Subject: Advanced dist tag uses. In-Reply-To: <20061124140019.2f42fdae.bugs.michael@gmx.net> References: <200611231318.kANDIeAu000697@cvs-int.fedora.redhat.com> <200611241102.44009@rineau.schtroumpfette> <20061124140019.2f42fdae.bugs.michael@gmx.net> Message-ID: <200611241404.37253@rineau.schtroumpfette> On Friday 24 November 2006 14:00, Michael Schwendt wrote: > It is assumed that the release tag consists of just a single integer and > that %{?dist} is appended to that. > > > If the previous release tag of streamtuner had been "14.1%{?dist}", would > > it have been correct? (sorry if I failed to conjugate that sequence > > correctly.) > > 14.1%{?dist} is invalid, too, because "1" is higher than "fc". And due to > that, 14.1.fc5 would be higher than 14.fc6 and 14.fc7. > > Now, if you tried to avoid that by building as 14.1.fcN for all N dists, > this would be unnecessary and error-prone inflation of release numbers. > > Correct would be > > 14%{?dist} < 15%{?dist} < 16%{?dist} < ... > > and so on. If there's ever reason to fix something only in release 14.fc6, > without bumping release to 15, so that it would be "newer than" 14.fc7, > the release tag can be increased at the very _right_: > > 14%{?dist}.1 < 14%{?dist}.2 < ... > > resulting in > > 14.fc6 < 14.fc6.1 < 14.fc6.2 < 14.fc7 Nice explanation. Is this too complicated to be explained in the wiki? From fedora at leemhuis.info Fri Nov 24 13:18:47 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 24 Nov 2006 14:18:47 +0100 Subject: Advanced dist tag uses. In-Reply-To: <200611241404.37253@rineau.schtroumpfette> References: <200611231318.kANDIeAu000697@cvs-int.fedora.redhat.com> <200611241102.44009@rineau.schtroumpfette> <20061124140019.2f42fdae.bugs.michael@gmx.net> <200611241404.37253@rineau.schtroumpfette> Message-ID: <4566F137.3000202@leemhuis.info> Laurent Rineau schrieb: > On Friday 24 November 2006 14:00, Michael Schwendt wrote: >> It is assumed that the release tag consists of just a single integer and >> that %{?dist} is appended to that. >> >>> If the previous release tag of streamtuner had been "14.1%{?dist}", would >>> it have been correct? (sorry if I failed to conjugate that sequence >>> correctly.) >> 14.1%{?dist} is invalid, /me wonders if there is a more suitable word for this instead of "invalid"... Well, does not matter much. >> too, because "1" is higher than "fc". And due to >> that, 14.1.fc5 would be higher than 14.fc6 and 14.fc7. >> >> Now, if you tried to avoid that by building as 14.1.fcN for all N dists, >> this would be unnecessary and error-prone inflation of release numbers. >> >> Correct would be >> >> 14%{?dist} < 15%{?dist} < 16%{?dist} < ... >> >> and so on. If there's ever reason to fix something only in release 14.fc6, >> without bumping release to 15, so that it would be "newer than" 14.fc7, >> the release tag can be increased at the very _right_: >> >> 14%{?dist}.1 < 14%{?dist}.2 < ... >> >> resulting in >> >> 14.fc6 < 14.fc6.1 < 14.fc6.2 < 14.fc7 > > Nice explanation. Is this too complicated to be explained in the wiki? I was just about to ask the same. Michael, could you add that please? tia! Cu thl From j.w.r.degoede at hhs.nl Fri Nov 24 14:53:11 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 24 Nov 2006 15:53:11 +0100 Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: <18132.192.54.193.51.1164371456.squirrel@rousalka.dyndns.org> References: <4566C658.8060307@hhs.nl> <18132.192.54.193.51.1164371456.squirrel@rousalka.dyndns.org> Message-ID: <45670757.7050703@hhs.nl> Nicolas Mailhot wrote: > Le Ven 24 novembre 2006 11:15, Hans de Goede a ?crit : >> Hi all, >> >> Many packages drop config files for logrotate in /etc/logrotate.d. without >> requiring logrotate, which is the owner of >> /etc/logrotate.d, thus potentially leading to an unowned /etc/logrotate.d >> for users who don't want logrotate and thus remove it. >> >> I see 2 solutions for this: >> 1) Add "Requires: logrotate" to all packages which put files in >> /etc/logrotate.d. IMHO this is not good as the user should be able >> to choose if he wants logrotate or not. >> 2) Add /etc/logrotate.d to the filesystem package, this is my preferred >> solution. > > 3. add Requires: /etc/logrotate.d to /etc/logrotate.d users > Which effectivly boils down to 1) except that it causes yum to take an extra 5-10 minutes to download file lists for all enabled repos. (on a 1 mbit link) file based dependencies usually are not the answer! Regards, Hans From nicolas.mailhot at laposte.net Fri Nov 24 17:07:49 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 24 Nov 2006 18:07:49 +0100 Subject: comps.xml is now pushed automatically In-Reply-To: <1164316682.11035.32.camel@rousalka.dyndns.org> References: <20061123152610.65823727@ludwig-alpha.unil.ch> <9408.192.54.193.51.1164294065.squirrel@rousalka.dyndns.org> <1164302173.1539.88.camel@enki.eridu> <20061123181503.GU26540@redhat.com> <1164316682.11035.32.camel@rousalka.dyndns.org> Message-ID: <1164388074.21156.1.camel@rousalka.dyndns.org> Le jeudi 23 novembre 2006 ? 22:18 +0100, Nicolas Mailhot a ?crit : > Here is a very raw Relax-NG comps schema. Bear in mind I wrote it after > skimming 5 min for the first time the Relax NG tutorial, so my style may > not be perfect And it works even better with the actual file -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: comps.rng Type: application/xml Size: 4588 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ville.skytta at iki.fi Fri Nov 24 17:26:29 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 24 Nov 2006 19:26:29 +0200 Subject: Advanced dist tag uses. In-Reply-To: <4566F137.3000202@leemhuis.info> References: <200611231318.kANDIeAu000697@cvs-int.fedora.redhat.com> <200611241102.44009@rineau.schtroumpfette> <20061124140019.2f42fdae.bugs.michael@gmx.net> <200611241404.37253@rineau.schtroumpfette> <4566F137.3000202@leemhuis.info> Message-ID: <1164389189.3568.4.camel@viper.local> On Fri, 2006-11-24 at 14:18 +0100, Thorsten Leemhuis wrote: > Laurent Rineau schrieb: > > On Friday 24 November 2006 14:00, Michael Schwendt wrote: [...] > >> resulting in > >> > >> 14.fc6 < 14.fc6.1 < 14.fc6.2 < 14.fc7 > > > > Nice explanation. Is this too complicated to be explained in the wiki? > > I was just about to ask the same. Michael, could you add that please? tia! I think it's already pretty much covered by the "Minor release bumps for old branches" chapter of the naming guidelines: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-378ec5e6a73d5425d55c115ff5d0fa5f5094dcba Wording improvements and/or crosslinks or something to make it easier to find are always welcome. From steve at silug.org Fri Nov 24 18:52:18 2006 From: steve at silug.org (Steven Pritchard) Date: Fri, 24 Nov 2006 12:52:18 -0600 Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: <45670757.7050703@hhs.nl> References: <4566C658.8060307@hhs.nl> <18132.192.54.193.51.1164371456.squirrel@rousalka.dyndns.org> <45670757.7050703@hhs.nl> Message-ID: <20061124185218.GA18856@osiris.silug.org> On Fri, Nov 24, 2006 at 03:53:11PM +0100, Hans de Goede wrote: > Nicolas Mailhot wrote: > >3. add Requires: /etc/logrotate.d to /etc/logrotate.d users > > Which effectivly boils down to 1) except that it causes yum to take an > extra 5-10 minutes to download file lists for all enabled repos. > (on a 1 mbit link) file based dependencies usually are not the answer! But adding "Requires: /etc/logrotate.d" Just Works if the filesystem package starts providing that directory. IMHO file/directory Requires make a *lot* more sense when the thing you require is outside your control. That way package renames/splits and that sort of thing don't break your package (most of the time). If pulling down the file lists is that painful, is there some additional packing that can be done on them? 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 Axel.Thimm at ATrpms.net Fri Nov 24 19:05:52 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 24 Nov 2006 20:05:52 +0100 Subject: buildsys queue Message-ID: <20061124190552.GF31787@neu.nirvana> Hi, the queue seems to be 2+ days large, is that due to some hardware issues mentioned some time ago? If not, could someone please sign/push the packages? Thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Nov 24 19:10:13 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 24 Nov 2006 20:10:13 +0100 Subject: buildsys queue In-Reply-To: <20061124190552.GF31787@neu.nirvana> References: <20061124190552.GF31787@neu.nirvana> Message-ID: <20061124191013.GG31787@neu.nirvana> On Fri, Nov 24, 2006 at 08:05:52PM +0100, Axel Thimm wrote: > the queue seems to be 2+ days large, is that due to some hardware > issues mentioned some time ago? If not, could someone please sign/push > the packages? Thanks! Forget it, I just saw that some packages have been pushed, I just misinterpreted the status on http://buildsys.fedoraproject.org/build-status/success.psp, I thought that if the packages are tagged as "needsign" then they still need to be signed and pushed to the repo. Would it make sense to add a state of "signedandpushed" or similar? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Fri Nov 24 19:25:19 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 24 Nov 2006 20:25:19 +0100 Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: <20061124185218.GA18856@osiris.silug.org> References: <4566C658.8060307@hhs.nl> <18132.192.54.193.51.1164371456.squirrel@rousalka.dyndns.org> <45670757.7050703@hhs.nl> <20061124185218.GA18856@osiris.silug.org> Message-ID: <4567471F.7080704@hhs.nl> Steven Pritchard wrote: > On Fri, Nov 24, 2006 at 03:53:11PM +0100, Hans de Goede wrote: >> Nicolas Mailhot wrote: >>> 3. add Requires: /etc/logrotate.d to /etc/logrotate.d users >> Which effectivly boils down to 1) except that it causes yum to take an >> extra 5-10 minutes to download file lists for all enabled repos. >> (on a 1 mbit link) file based dependencies usually are not the answer! > > But adding "Requires: /etc/logrotate.d" Just Works if the filesystem > package starts providing that directory. > No it won't because both the filesystem package and logrotate will provide it. and since logrotate is the shorter name logrotate will get chosen. > If pulling down the file lists is that painful, is there some > additional packing that can be done on them? > It is, and not that I know of. Regards, Hans From j.w.r.degoede at hhs.nl Fri Nov 24 19:40:33 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 24 Nov 2006 20:40:33 +0100 Subject: gltron / armagetronad suitable for FE Message-ID: <45674AB1.3020605@hhs.nl> Hi, I was wondering if gltron / armagetronad are suitable for inclusion to FE? I'm asking because both are popular tron lightcycle games and both are freesoftware, but I'm not sure if they are ok as they are clearly inspired by tron the movie and I'm afraid they might conflict with certain tron (the movie) related copyrights / trademarks. Thanks & Regards, Hans From pertusus at free.fr Fri Nov 24 20:34:18 2006 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 24 Nov 2006 21:34:18 +0100 Subject: R packagers, please help! Message-ID: <20061124203418.GB4309@free.fr> Hello, I have submitted a bug for a R template in rpmdevtools: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215927 However I am not really qualified on R packaging ;-). So please R packagers have a look! -- Pat From tmus at tmus.dk Fri Nov 24 22:02:34 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 24 Nov 2006 23:02:34 +0100 Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: <4566C658.8060307@hhs.nl> References: <4566C658.8060307@hhs.nl> Message-ID: Hans de Goede wrote: > Hi all, > > Many packages drop config files for logrotate in /etc/logrotate.d. > without requiring logrotate, which is the owner of > /etc/logrotate.d, thus potentially leading to an unowned > /etc/logrotate.d for users who don't want logrotate and thus remove it. > > I see 2 solutions for this: > 1) Add "Requires: logrotate" to all packages which put files in > /etc/logrotate.d. IMHO this is not good as the user should be able > to choose if he wants logrotate or not. > 2) Add /etc/logrotate.d to the filesystem package, this is my preferred > solution. > > I would like to hear what others think, before filing a bug against > filesystem requesting 2) . > > Regards, > > Hans > Requiring logrotate is not really preferred, since people may choose to remove logrotate and it does not make any real sense that you can't install httpd or cups or others without a pre-chosen log-management package (exactly as you point out). On the other hand, putting /etc/logrotate.d in the filesystem package is probably not a too much better, since we will still be installing stuff for a particular log-management package, that may not even be there. This seems wrong to me. So since we're already discussing this, what if all packages that put stuff in logrotate.d, do so from a sub-package... httpd-logrotate (or something)... The -logrotate sub packages should require logrotate and of-course the main package (httpd in this case). Users can remove logrotate and with it, all the -logrotate subpackages from cups, httpd and the rest, but the software will still install and run just fine. This method has the added benefit of giving us a cleaner way to provide log-management for everything, based on an entirely different log-management tool. Put in extras and provide a http- package and all is good. Just my .5?s worth /Thomas From chris.stone at gmail.com Fri Nov 24 22:31:29 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 24 Nov 2006 14:31:29 -0800 Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: References: <4566C658.8060307@hhs.nl> Message-ID: On 11/24/06, Thomas M Steenholdt wrote: > Hans de Goede wrote: > > Hi all, > > > > Many packages drop config files for logrotate in /etc/logrotate.d. > > without requiring logrotate, which is the owner of > > /etc/logrotate.d, thus potentially leading to an unowned > > /etc/logrotate.d for users who don't want logrotate and thus remove it. > > > > I see 2 solutions for this: > > 1) Add "Requires: logrotate" to all packages which put files in > > /etc/logrotate.d. IMHO this is not good as the user should be able > > to choose if he wants logrotate or not. > > 2) Add /etc/logrotate.d to the filesystem package, this is my preferred > > solution. > > > > I would like to hear what others think, before filing a bug against > > filesystem requesting 2) . > > > > Regards, > > > > Hans > > > > Requiring logrotate is not really preferred, since people may choose to > remove logrotate and it does not make any real sense that you can't > install httpd or cups or others without a pre-chosen log-management > package (exactly as you point out). > > On the other hand, putting /etc/logrotate.d in the filesystem package is > probably not a too much better, since we will still be installing stuff > for a particular log-management package, that may not even be there. > This seems wrong to me. > > So since we're already discussing this, what if all packages that put > stuff in logrotate.d, do so from a sub-package... httpd-logrotate (or > something)... The -logrotate sub packages should require logrotate and > of-course the main package (httpd in this case). Users can remove > logrotate and with it, all the -logrotate subpackages from cups, httpd > and the rest, but the software will still install and run just fine. > This method has the added benefit of giving us a cleaner way to provide > log-management for everything, based on an entirely different > log-management tool. Put in extras and provide a > http- package and all is good. > > Just my .5?s worth > > /Thomas +1 From steve at silug.org Fri Nov 24 22:46:03 2006 From: steve at silug.org (Steven Pritchard) Date: Fri, 24 Nov 2006 16:46:03 -0600 Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: <4567471F.7080704@hhs.nl> References: <4566C658.8060307@hhs.nl> <18132.192.54.193.51.1164371456.squirrel@rousalka.dyndns.org> <45670757.7050703@hhs.nl> <20061124185218.GA18856@osiris.silug.org> <4567471F.7080704@hhs.nl> Message-ID: <20061124224603.GA3904@osiris.silug.org> On Fri, Nov 24, 2006 at 08:25:19PM +0100, Hans de Goede wrote: > Steven Pritchard wrote: > > But adding "Requires: /etc/logrotate.d" Just Works if the filesystem > > package starts providing that directory. > > No it won't because both the filesystem package and logrotate will > provide it. and since logrotate is the shorter name logrotate will get > chosen. I meant "if the filesystem package starts providing that directory instead of logrotate". :-) 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 buildsys at fedoraproject.org Fri Nov 24 23:14:59 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 24 Nov 2006 18:14:59 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-24 Message-ID: <20061124231459.A141A15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 14 Django-0.95-1.fc7 gq-1.2.2-2.fc7 jd-1.8.1-0.1.cvs061124.fc7 libast-0.7.1-0.1.20060818cvs.fc7 liquidwar-5.6.3-2.fc7 magicor-1.0-0.2.rc2.fc7 php-idn-1.2-1.fc7 php-pear-Date-1.4.7-1.fc7 python-nose-0.9.1-1.fc7 python-simplejson-1.4-1.fc7 python-telepathy-0.13.7-2.fc7 sdparm-1.00-4.fc7 snort-2.6.1.1-1.fc7 synaptic-0.57.2-5.2.fc7 Packages built and released for Fedora Extras 6: 5 magicor-1.0-0.2.rc2.fc6 php-idn-1.2-1.fc6 php-pear-Date-1.4.7-1.fc6 ppracer-0.3.1-8.fc6 synaptic-0.57.2-5.2.fc6 Packages built and released for Fedora Extras 5: 4 magicor-1.0-0.2.rc2.fc5 php-idn-1.2-1.fc5 php-pear-Date-1.4.7-1.fc5 ppracer-0.3.1-8.fc5 Packages built and released for Fedora Extras 4: 0 Packages built and released for Fedora Extras 3: 0 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From steve at silug.org Sat Nov 25 00:16:08 2006 From: steve at silug.org (Steven Pritchard) Date: Fri, 24 Nov 2006 18:16:08 -0600 Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: References: <4566C658.8060307@hhs.nl> Message-ID: <20061125001608.GB3904@osiris.silug.org> On Fri, Nov 24, 2006 at 11:02:34PM +0100, Thomas M Steenholdt wrote: > On the other hand, putting /etc/logrotate.d in the filesystem package is > probably not a too much better, since we will still be installing stuff > for a particular log-management package, that may not even be there. > This seems wrong to me. Why? We install a lot of stuff to get extra functionality when $foo is present. > So since we're already discussing this, what if all packages that put > stuff in logrotate.d, do so from a sub-package... httpd-logrotate (or > something)... The -logrotate sub packages should require logrotate and > of-course the main package (httpd in this case). Users can remove > logrotate and with it, all the -logrotate subpackages from cups, httpd > and the rest, but the software will still install and run just fine. But what makes you think users will ask to install all that to begin with? That's just begging for a million "/var filled up" bugzilla tickets. 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 buildsys at fedoraproject.org Sat Nov 25 00:19:03 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 25 Nov 2006 00:19:03 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 Message-ID: <20061125001903.19894.81471@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- Jochen AT herr-schmitt.de blender - 2.42a-5.fc7.i386 blender - 2.42a-5.fc7.ppc blender - 2.42a-5.fc7.x86_64 andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 (24 days) centericq - 4.21.0-8.fc6.ppc (24 days) centericq - 4.21.0-8.fc6.x86_64 (24 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (27 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (27 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (27 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (27 days) orange - 0.3-3.cvs20051118.fc6.i386 (31 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (55 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (55 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (55 days) braden AT endoframe.com openvrml - 0.16.1-4.fc7.i386 openvrml - 0.16.1-4.fc7.i386 openvrml - 0.16.1-4.fc7.ppc openvrml - 0.16.1-4.fc7.x86_64 openvrml-devel - 0.16.1-4.fc7.i386 openvrml-devel - 0.16.1-4.fc7.i386 openvrml-devel - 0.16.1-4.fc7.ppc openvrml-devel - 0.16.1-4.fc7.x86_64 dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (70 days) plague - 0.4.4.1-2.fc3.noarch (70 days) plague - 0.4.4.1-2.fc4.noarch (70 days) plague - 0.4.4.1-2.fc4.noarch (70 days) plague - 0.4.4.1-2.fc4.noarch (70 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (46 days) linphone - 1.2.0-4.fc5.ppc (46 days) linphone - 1.2.0-4.fc5.x86_64 (46 days) karlthered AT gmail.com gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.i386 (2 days) gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.i386 (2 days) gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.ppc (2 days) gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.x86_64 (2 days) matthias AT rpmforge.net php-eaccelerator - 5.1.6_0.9.5-2.fc7.i386 (8 days) php-eaccelerator - 5.1.6_0.9.5-2.fc7.ppc (8 days) php-eaccelerator - 5.1.6_0.9.5-2.fc7.x86_64 (8 days) oliver AT linux-kernel.at syck-php - 0.55-10.fc6.i386 (8 days) syck-php - 0.55-10.fc6.ppc (8 days) syck-php - 0.55-10.fc6.x86_64 (8 days) syck-php - 0.55-9.fc5.i386 (36 days) syck-php - 0.55-9.fc5.ppc (36 days) syck-php - 0.55-9.fc5.x86_64 (36 days) pertusus AT free.fr grads - 1.9b4-19.fc7.i386 (8 days) grads - 1.9b4-19.fc7.ppc (8 days) grads - 1.9b4-19.fc7.x86_64 (8 days) petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 (21 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (21 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (21 days) ghc642-gtk2hs - 0.9.10-4.fc6.i386 (21 days) ghc642-gtk2hs - 0.9.10-4.fc6.ppc (21 days) ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 (21 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 (21 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc (21 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 (21 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (26 days) tcallawa AT redhat.com gambas-runtime - 1.0.17-6.fc7.i386 gambas-runtime - 1.0.17-6.fc7.ppc Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- blender-2.42a-5.fc7.ppc requires libgettextlib-0.15.so centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 gambas-runtime-1.0.17-6.fc7.ppc requires libgettextlib-0.15.so ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 grads-1.9b4-19.fc7.ppc requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.ppc requires gecko-libs = 0:2.0 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 openvrml-0.16.1-4.fc7.ppc requires firefox = 0:1.5.0.8 openvrml-devel-0.16.1-4.fc7.ppc requires firefox-devel = 0:1.5.0.8 php-eaccelerator-5.1.6_0.9.5-2.fc7.ppc requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.ppc requires php = 0:5.1.6 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- blender-2.42a-5.fc7.x86_64 requires libgettextlib-0.15.so()(64bit) centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 grads-1.9b4-19.fc7.x86_64 requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.i386 requires gecko-libs = 0:2.0 gtkmozembedmm-1.4.2.cvs20060817-5.fc7.x86_64 requires gecko-libs = 0:2.0 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) openvrml-0.16.1-4.fc7.i386 requires firefox = 0:1.5.0.8 openvrml-0.16.1-4.fc7.x86_64 requires firefox = 0:1.5.0.8 openvrml-devel-0.16.1-4.fc7.i386 requires firefox-devel = 0:1.5.0.8 openvrml-devel-0.16.1-4.fc7.x86_64 requires firefox-devel = 0:1.5.0.8 orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 php-eaccelerator-5.1.6_0.9.5-2.fc7.x86_64 requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.x86_64 requires php = 0:5.1.6 Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- blender-2.42a-5.fc7.i386 requires libgettextlib-0.15.so centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 gambas-runtime-1.0.17-6.fc7.i386 requires libgettextlib-0.15.so ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 grads-1.9b4-19.fc7.i386 requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.i386 requires gecko-libs = 0:2.0 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 openvrml-0.16.1-4.fc7.i386 requires firefox = 0:1.5.0.8 openvrml-devel-0.16.1-4.fc7.i386 requires firefox-devel = 0:1.5.0.8 php-eaccelerator-5.1.6_0.9.5-2.fc7.i386 requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.i386 requires php = 0:5.1.6 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 From rdieter at math.unl.edu Sat Nov 25 01:25:52 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 24 Nov 2006 19:25:52 -0600 Subject: unowned directory problem with /etc/logrotate.d References: <4566C658.8060307@hhs.nl> <18132.192.54.193.51.1164371456.squirrel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot wrote: > > Le Ven 24 novembre 2006 11:15, Hans de Goede a ?crit : >> Hi all, >> >> Many packages drop config files for logrotate in /etc/logrotate.d. >> without requiring logrotate, which is the owner of >> /etc/logrotate.d, thus potentially leading to an unowned /etc/logrotate.d >> for users who don't want logrotate and thus remove it. >> >> I see 2 solutions for this: >> 1) Add "Requires: logrotate" to all packages which put files in >> /etc/logrotate.d. IMHO this is not good as the user should be able >> to choose if he wants logrotate or not. >> 2) Add /etc/logrotate.d to the filesystem package, this is my preferred >> solution. > > 3. add Requires: /etc/logrotate.d to /etc/logrotate.d users That's not really all that different than 1. For now, imo, the only viable alternative is 1. Requires: logrotate -- Rex From garrick at usc.edu Sat Nov 25 02:38:35 2006 From: garrick at usc.edu (Garrick Staples) Date: Fri, 24 Nov 2006 18:38:35 -0800 Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: References: <4566C658.8060307@hhs.nl> <18132.192.54.193.51.1164371456.squirrel@rousalka.dyndns.org> Message-ID: <20061125023835.GC2297@polop.usc.edu> On Fri, Nov 24, 2006 at 07:25:52PM -0600, Rex Dieter alleged: > Nicolas Mailhot wrote: > > > > > Le Ven 24 novembre 2006 11:15, Hans de Goede a ??crit : > >> Hi all, > >> > >> Many packages drop config files for logrotate in /etc/logrotate.d. > >> without requiring logrotate, which is the owner of > >> /etc/logrotate.d, thus potentially leading to an unowned /etc/logrotate.d > >> for users who don't want logrotate and thus remove it. > >> > >> I see 2 solutions for this: > >> 1) Add "Requires: logrotate" to all packages which put files in > >> /etc/logrotate.d. IMHO this is not good as the user should be able > >> to choose if he wants logrotate or not. > >> 2) Add /etc/logrotate.d to the filesystem package, this is my preferred > >> solution. > > > > 3. add Requires: /etc/logrotate.d to /etc/logrotate.d users > > That's not really all that different than 1. > > For now, imo, the only viable alternative is 1. Requires: logrotate 4. Split logrotate to have a filesystem subpackage that just owns the directories and have everything Require: logrotate-filesystem. -- Garrick Staples, Linux/HPCC Administrator University of Southern California -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dcbw at redhat.com Sat Nov 25 03:27:21 2006 From: dcbw at redhat.com (Dan Williams) Date: Fri, 24 Nov 2006 22:27:21 -0500 Subject: buildsys queue In-Reply-To: <20061124191013.GG31787@neu.nirvana> References: <20061124190552.GF31787@neu.nirvana> <20061124191013.GG31787@neu.nirvana> Message-ID: <1164425241.2637.0.camel@localhost.localdomain> On Fri, 2006-11-24 at 20:10 +0100, Axel Thimm wrote: > On Fri, Nov 24, 2006 at 08:05:52PM +0100, Axel Thimm wrote: > > the queue seems to be 2+ days large, is that due to some hardware > > issues mentioned some time ago? If not, could someone please sign/push > > the packages? Thanks! > > Forget it, I just saw that some packages have been pushed, I just > misinterpreted the status on > http://buildsys.fedoraproject.org/build-status/success.psp, I thought > that if the packages are tagged as "needsign" then they still need to > be signed and pushed to the repo. > > Would it make sense to add a state of "signedandpushed" or similar? That state exists, but nobody bothers to move then from 'needsign' to 'finished'. Technically the push scripts could do this, but they don't. Dan From jspaleta at gmail.com Sat Nov 25 03:37:59 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 24 Nov 2006 18:37:59 -0900 Subject: An updated libgpod for core and python bindings for extras In-Reply-To: <4564A750.8040309@leemhuis.info> References: <20061122060726.GP32659@psilocybe.teonanacatl.org> <4564A750.8040309@leemhuis.info> Message-ID: <604aa7910611241937ube5348ke1e81f6d76276daf@mail.gmail.com> On 11/22/06, Thorsten Leemhuis wrote: > I don't see any problems here as long as nothing from Core get replaced. > Just submit it for review. See > http://www.fedoraproject.org/wiki/Extras/Contributors > for details. I don't have sponsor ability, but I can run through the review items for this package tonite to help shave some time off for a potential sponser, since this is Todd's first package. If there is an unexpected hold-up on Todd's sponsorship I am willing to take maintainership of the package in the interum. -jef From alain.portal at free.fr Sat Nov 25 03:57:13 2006 From: alain.portal at free.fr (Alain PORTAL) Date: Sat, 25 Nov 2006 04:57:13 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <20061125001903.19894.81471@extras64.linux.duke.edu> References: <20061125001903.19894.81471@extras64.linux.duke.edu> Message-ID: <200611250457.16799.alain.portal@free.fr> Le samedi 25 novembre 2006 01:19, Fedora Extras repoclosure a ?crit : > Broken packages in fedora-extras-4-ppc: > ---------------------------------------------------------------------- > plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 > > Broken packages in fedora-extras-4-x86_64: > ---------------------------------------------------------------------- > plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 > > Broken packages in fedora-extras-4-i386: > ---------------------------------------------------------------------- > plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 > > Broken packages in fedora-extras-3-x86_64: > ---------------------------------------------------------------------- > plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 > > Broken packages in fedora-extras-3-i386: > ---------------------------------------------------------------------- > plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 How long whe have to endure these messages? That been going on for more than 8 months... Haven't we had about enough of this? If there is no packager, orphan it! -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Sat Nov 25 03:42:12 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 24 Nov 2006 21:42:12 -0600 Subject: hammer1 and hammer3 appear to be down In-Reply-To: <200611221720.05167.dennis@ausil.us> References: <4564D261.1020405@cora.nwra.com> <200611221720.05167.dennis@ausil.us> Message-ID: <200611242142.14023.dennis@ausil.us> On Wednesday 22 November 2006 17:20, Dennis Gilmore wrote: > On Wednesday 22 November 2006 16:42, Orion Poplawski wrote: > > Folks know about that? > > hammer3 suffered a fatal hardware failure. Dell has donated a replacement > and it is on its way now. > > hammer1 suffered from a blown out chroot and i am in the middle of > rebuilding it. its replacement will be known as xenbuilder1 As an update for everyone xenbuilder1 now lives as a xen guest on the hardware that was hammer1. and xenbuilder2 will come online when the new hardware that dell has donated arrives. -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From jspaleta at gmail.com Sat Nov 25 04:45:23 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 24 Nov 2006 19:45:23 -0900 Subject: An updated libgpod for core and python bindings for extras In-Reply-To: <604aa7910611241937ube5348ke1e81f6d76276daf@mail.gmail.com> References: <20061122060726.GP32659@psilocybe.teonanacatl.org> <4564A750.8040309@leemhuis.info> <604aa7910611241937ube5348ke1e81f6d76276daf@mail.gmail.com> Message-ID: <604aa7910611242045y2ba0203g9b752359a572eada@mail.gmail.com> On 11/24/06, Jeff Spaleta wrote: > I don't have sponsor ability, but I can run through the review items > for this package tonite to help shave some time off for a potential > sponser, since this is Todd's first package. If there is an > unexpected hold-up on Todd's sponsorship I am willing to take > maintainership of the package in the interum. Okay I ran through the informal review, and I don't see any blockers. Time for me to poke some sponsors in the eye. Luckily I have a whole new set of eye-poking sticks fashioned from the skeletal remains of yesterday's turkey. -jef"my doctor told me not to get wishbones in my eye"spaleta From tmz at pobox.com Sat Nov 25 05:31:29 2006 From: tmz at pobox.com (Todd Zullinger) Date: Sat, 25 Nov 2006 00:31:29 -0500 Subject: An updated libgpod for core and python bindings for extras In-Reply-To: <604aa7910611241937ube5348ke1e81f6d76276daf@mail.gmail.com> References: <20061122060726.GP32659@psilocybe.teonanacatl.org> <4564A750.8040309@leemhuis.info> <604aa7910611241937ube5348ke1e81f6d76276daf@mail.gmail.com> Message-ID: <20061125053129.GU32659@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeff Spaleta wrote: > I don't have sponsor ability, but I can run through the review items > for this package tonite to help shave some time off for a potential > sponser, since this is Todd's first package. If there is an > unexpected hold-up on Todd's sponsorship I am willing to take > maintainership of the package in the interum. Thanks Jef, for the pre-review and the offer to take maintainership. Whatever gets the package into extras where folks can take advantage of it is fine by me. - -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== Subtlety is the art of saying what you think and getting out of the way before it is understood. -- Anonymous -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iQFDBAEBAgAtBQJFZ9UxJhhodHRwOi8vd3d3LnBvYm94LmNvbS9+dG16L3BncC90 bXouYXNjAAoJEEMlk4u+rwzj2icIAJRkj92ENsEFB1LI+kuH2v3ikbytMlX7ukNy dFUo7ChjyZxUK/UL0hjs/rO3xK6nSnA4jq2f+cmoK1HKg85KICe1lso631P3BjFT wyGRVZgEr6WsosX1gsd+qMbJpDfXfjWJ1TUz5vxE9p7FZWTrZ2yNNacRXdO6dd5h bhwftLMg14VbeboSFnvk6Ji3sVOa1I55oXlwO01r32/8IuAxyXx57yjKF1QY7dXo g1TF2QJ4lnotbFhzCgsDfsLOOYefQ7yB95tJf1oS4joCumexcCHSDPgaRH0Nnoao OUja20xu2IFhGkyttgxe/3eLE0oRmGsflBrvear8qxGRsRkP4bE= =MFbc -----END PGP SIGNATURE----- From mastahnke at gmail.com Sat Nov 25 05:34:10 2006 From: mastahnke at gmail.com (Michael Stahnke) Date: Fri, 24 Nov 2006 23:34:10 -0600 Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: <20061125023835.GC2297@polop.usc.edu> References: <4566C658.8060307@hhs.nl> <18132.192.54.193.51.1164371456.squirrel@rousalka.dyndns.org> <20061125023835.GC2297@polop.usc.edu> Message-ID: <7874d9dd0611242134l3d3f7862yecc3aa8f5cc88e3c@mail.gmail.com> Do a lot of people actually remove logrotate? I find it quite handy on every system I have. I guess I vote for Requires: logrotate. If you don't want logrotate, won't that mess up several other packages also? -------------- next part -------------- An HTML attachment was scrubbed... URL: From garrick at usc.edu Sat Nov 25 06:02:27 2006 From: garrick at usc.edu (Garrick Staples) Date: Fri, 24 Nov 2006 22:02:27 -0800 Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: <7874d9dd0611242134l3d3f7862yecc3aa8f5cc88e3c@mail.gmail.com> References: <4566C658.8060307@hhs.nl> <18132.192.54.193.51.1164371456.squirrel@rousalka.dyndns.org> <20061125023835.GC2297@polop.usc.edu> <7874d9dd0611242134l3d3f7862yecc3aa8f5cc88e3c@mail.gmail.com> Message-ID: <20061125060227.GD2297@polop.usc.edu> On Fri, Nov 24, 2006 at 11:34:10PM -0600, Michael Stahnke alleged: > Do a lot of people actually remove logrotate? I find it quite handy on > every system I have. I guess I vote for Requires: logrotate. If you don't > want logrotate, won't that mess up several other packages also? I remove it on my research computing cluster, where I have a different system to collect everything back to a head node. -- Garrick Staples, Linux/HPCC Administrator University of Southern California -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Sat Nov 25 06:03:52 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 25 Nov 2006 00:03:52 -0600 Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: <20061125001608.GB3904@osiris.silug.org> References: <4566C658.8060307@hhs.nl> <20061125001608.GB3904@osiris.silug.org> Message-ID: <200611250003.53152.dennis@ausil.us> On Friday 24 November 2006 18:16, Steven Pritchard wrote: > On Fri, Nov 24, 2006 at 11:02:34PM +0100, Thomas M Steenholdt wrote: > > > So since we're already discussing this, what if all packages that put > > stuff in logrotate.d, do so from a sub-package... httpd-logrotate (or > > something)... The -logrotate sub packages should require logrotate and > > of-course the main package (httpd in this case). Users can remove > > logrotate and with it, all the -logrotate subpackages from cups, httpd > > and the rest, but the software will still install and run just fine. > > But what makes you think users will ask to install all that to begin > with? > > That's just begging for a million "/var filled up" bugzilla tickets. not that its a huge deal either way but if im using central log servers only then there will be nothing to rotate. however Disk is cheap and users who don't really know what they are doing will fill up /var with huge log files and users who should know better could slip up at some time. so we really expect and want log rotation for the most part. the only viable solution is to have those packages Requires: logrotate -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From dennis at ausil.us Sat Nov 25 06:15:27 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 25 Nov 2006 00:15:27 -0600 Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: <7874d9dd0611242134l3d3f7862yecc3aa8f5cc88e3c@mail.gmail.com> References: <4566C658.8060307@hhs.nl> <20061125023835.GC2297@polop.usc.edu> <7874d9dd0611242134l3d3f7862yecc3aa8f5cc88e3c@mail.gmail.com> Message-ID: <200611250015.28912.dennis@ausil.us> On Friday 24 November 2006 23:34, Michael Stahnke wrote: > Do a lot of people actually remove logrotate? I find it quite handy on > every system I have. I guess I vote for Requires: logrotate. If you don't > want logrotate, won't that mess up several other packages also? if you have packages require logrotate and some one wants to remove it it will pull alot of stuff out. logrotate itself really doesn't take up much room on my desktop about 160K the files dropped in /etc/logrotate.d take up 232K and if the packages that put things there required logrotate it would remove cups yum acpid BackupPC kdebase mgetty bind rpm samba net-snmp syslog tomcat httpd to name a few. realistically if you make the packages start to require logrotate you wont be able to remove it. and as i said before Disk is cheap. and it really is small. -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From chitlesh at fedoraproject.org Sat Nov 25 10:24:07 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sat, 25 Nov 2006 11:24:07 +0100 Subject: desktop-file-install provokes corruption Message-ID: <13dbfe4f0611250224x39ea9a01j9a0bc0fbab892993@mail.gmail.com> Hello there, I'm packaging keurocalc packaging. Desktop-file install in my spec file is provoking corruption of %{name}.desktop. + desktop-file-install --vendor '' --dir /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications --add-category Office --delete-original /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applnk/Applications/keurocalc.desktop /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "DocPath", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: error: invalid characters in value of key "Keywords[ar]", keys of type string may contain ASCII characters except control characters /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: error: invalid characters in value of key "Keywords[cs]", keys of type string may contain ASCII characters except control characters /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: error: invalid characters in value of key "Keywords[de]", keys of type string may contain ASCII characters except control characters /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: error: invalid characters in value of key "Keywords[el]", keys of type string may contain ASCII characters except control characters /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: error: invalid characters in value of key "Keywords[ga]", keys of type string may contain ASCII characters except control characters /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: error: invalid characters in value of key "Keywords[gl]", keys of type string may contain ASCII characters except control characters /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: error: invalid characters in value of key "Keywords[ja]", keys of type string may contain ASCII characters except control characters /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: error: invalid characters in value of key "Keywords[ka]", keys of type string may contain ASCII characters except control characters /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: error: invalid characters in value of key "Keywords[ru]", keys of type string may contain ASCII characters except control characters /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: error: invalid characters in value of key "Keywords[sv]", keys of type string may contain ASCII characters except control characters /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: error: invalid characters in value of key "Keywords[ta]", keys of type string may contain ASCII characters except control characters /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: error: invalid characters in value of key "Keywords[tr]", keys of type string may contain ASCII characters except control characters /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: warning: file contains key "Keywords", this key is currently reserved for use within KDE, and should in the future KDE releases be prefixed by "X-" desktop-file-install created an invalid desktop file! error: Bad exit status from /var/tmp/rpm-tmp.11497 (%install) To me, it has something to do with the non ascii caracters, so in order to rpmbuild successfully, I'm using this instead: # to skip the Lost&Found menu echo "Categories=Application;Office;" >> \ %{buildroot}%{_datadir}/applnk/Applications/%{name}.desktop Anyone has a clean solution to propose ? you can find my spec file here: http://chitlesh.funpic.de/fedora/SPECS/keurocalc.spec PS: it fails on mock, i need to work on it. chitlesh -- http://clunixchit.blogspot.com From bugs.michael at gmx.net Sat Nov 25 10:42:37 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 25 Nov 2006 11:42:37 +0100 Subject: buildsys queue In-Reply-To: <1164425241.2637.0.camel@localhost.localdomain> References: <20061124190552.GF31787@neu.nirvana> <20061124191013.GG31787@neu.nirvana> <1164425241.2637.0.camel@localhost.localdomain> Message-ID: <20061125114237.e06286b0.bugs.michael@gmx.net> On Fri, 24 Nov 2006 22:27:21 -0500, Dan Williams wrote: > On Fri, 2006-11-24 at 20:10 +0100, Axel Thimm wrote: > > On Fri, Nov 24, 2006 at 08:05:52PM +0100, Axel Thimm wrote: > > > the queue seems to be 2+ days large, is that due to some hardware > > > issues mentioned some time ago? If not, could someone please sign/push > > > the packages? Thanks! > > > > Forget it, I just saw that some packages have been pushed, I just > > misinterpreted the status on > > http://buildsys.fedoraproject.org/build-status/success.psp, I thought > > that if the packages are tagged as "needsign" then they still need to > > be signed and pushed to the repo. > > > > Would it make sense to add a state of "signedandpushed" or similar? > > That state exists, but nobody bothers to move then from 'needsign' to > 'finished'. Technically the push scripts could do this, but they don't. What is needed to get it done? The push script does not interface with plague in any way yet, so it does not know anything about build job numbers. It could reconstruct the build job tag from the name/version directory entries in the needsign repo. Is that worth anything? A quick grep on the plague server code returns: # Marking 'needsign' jobs as finished requires admin privs Sounds like a first roadblock. What kind of "admin privs" would we need? From ville.skytta at iki.fi Sat Nov 25 10:40:19 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 25 Nov 2006 12:40:19 +0200 Subject: desktop-file-install provokes corruption In-Reply-To: <13dbfe4f0611250224x39ea9a01j9a0bc0fbab892993@mail.gmail.com> References: <13dbfe4f0611250224x39ea9a01j9a0bc0fbab892993@mail.gmail.com> Message-ID: <1164451219.3568.25.camel@viper.local> On Sat, 2006-11-25 at 11:24 +0100, Chitlesh GOORAH wrote: [...] > /var/tmp/keurocalc-0.9.7-0.1-root-chitlesh/usr/share/applications/keurocalc.desktop: > error: invalid characters in value of key "Keywords[tr]", keys of type > string may contain ASCII characters except control characters [...] That's a desktop-file-{install,validate} issue which should have been fixed in recent versions: https://bugzilla.redhat.com/172423 > To me, it has something to do with the non ascii caracters, so in > order to rpmbuild successfully, I'm using this instead: > > # to skip the Lost&Found menu > echo "Categories=Application;Office;" >> \ > %{buildroot}%{_datadir}/applnk/Applications/%{name}.desktop > > Anyone has a clean solution to propose ? The above looks like an acceptable workaround to me, assuming it does what's intended. By the way, the "Application" category is non-standard and AFAIK there shouldn't be any need to use it nowadays, and you should be installing the .desktop file to /usr/share/applications, not /usr/share/applnk/Applications From chitlesh at fedoraproject.org Sat Nov 25 10:44:29 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sat, 25 Nov 2006 11:44:29 +0100 Subject: desktop-file-install provokes corruption In-Reply-To: <1164451219.3568.25.camel@viper.local> References: <13dbfe4f0611250224x39ea9a01j9a0bc0fbab892993@mail.gmail.com> <1164451219.3568.25.camel@viper.local> Message-ID: <13dbfe4f0611250244p2b3494b1l769077823bac94ea@mail.gmail.com> On 11/25/06, Ville Skytt? wrote: > On Sat, 2006-11-25 at 11:24 +0100, Chitlesh GOORAH wrote: > By the way, the "Application" category is non-standard and AFAIK there > shouldn't be any need to use it nowadays, and you should be installing > the .desktop file to /usr/share/applications, > not /usr/share/applnk/Applications I haven't copy/paste the whole thing. Yes I did move it appropriately. :) -- http://clunixchit.blogspot.com From paul at all-the-johnsons.co.uk Sat Nov 25 12:27:06 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 25 Nov 2006 12:27:06 +0000 Subject: An apology Message-ID: <1164457627.8591.91.camel@T7.Linux> Hi, I seem to have a bit of backlog of packages I'm to go through for acceptance into FE. I can only apologise for this, but events here have somewhat overtaken me and I had to turn to the darkside for a while on my buildsys. Having boiled the buildsys in acid for a week and then subjected it to high field beta particle bombardment, it's now back working as a buildsys, so I should be able to hack on at some point today (Saturday) with an aim of giving feedback to the majority of the packages I'm doing by the end of tomorrow. Sorry about this :-( TTFN Paul -- Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Sat Nov 25 14:18:26 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 25 Nov 2006 15:18:26 +0100 Subject: Adding (parts of) gstreamer-plugins-bad to FE? Message-ID: <456850B2.2050402@hhs.nl> Hi all, I'm currently working on getting gstreamer-plugins-bad into that other repo, and I was thinking that it could actually be a good idea to put it in FE and only put the parts with troublesome dependencies in FE. Here is a list of all the plugins in gstreamer-plugins-bad and where the should / could go: bz2 Support for bzip2 decompression -> FE cdxaparse Supports extracting mpeg1 stream from cdxa cd's, resulting in a raw mpeg1 stream, doesn't do anything with the actual mpeg data except for removing the additional headers / info from the cdxa format -> FE faac AAC audio support, has a non FE external dep -> other repo faad AAC audio support, has a non FE external dep -> other repo freeze Make a stream from from buffers of data -> FE glimagesink OpenGL video sink -> FE gsm GSM audio support, has a non FE external dep -> other repo mms MMS microsoft server streaming protocol support, has a non FE external dep -> other repo modplug Supports playing .mod .x3m and other modtracker files through modplug -> FE musepack Musepack audio decoding support, needed lib is in FE -> FE neonhttpsrc HTTP server support -> FE pitch Control pitch of audio through soundtouch, which is in FE -> FE qt Quicktime container format support, through own gst code (no libs used), this one is trouble some. I would really like to see this in FE as this adds supports for videos made with many digital photo cameras to gstreamer using applications (usually these camera's just dump a raw audio stream and a serie of jpeg images into a .mov file. So where should this one go? I really don't know. Can anyone help here? sdlvideosink SDL video sink -> FE speed modify speed of a stream -> FE theoraexp play theora files with support for the full theora standard through the experimental version of the xiph decoder -> FE trm musicbrainz support through libmusizbrainz -> FE tta TTA lossless audio format handling -> No idea help needed video4linux2 video4linux2 input/output device support -> FE wavpack WavPack support, wavpack itself is in FE -> FE xingheader Adds a Xing header to the beginning of a VBR MP3 file -> No idea help needed xvid divx support -> other repo So summarising most of gst-plugins-bad can go into FE, except: faac faad gsm mms xvid And we have 3 still open: qt tta xingheader So I would like to suggest for now that I submit a gstreamer-plugins-bad package to FE with the 5 not ok and 3 question mark plugins ommited. And one to that other repo with these 5 + 3 in. Although I would like to see the 3 questionmarks resolved eventually and the qt one soon if possible. Regards, Hans From chris.stone at gmail.com Sat Nov 25 14:12:08 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 25 Nov 2006 06:12:08 -0800 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <200611250457.16799.alain.portal@free.fr> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611250457.16799.alain.portal@free.fr> Message-ID: On 11/24/06, Alain PORTAL wrote: > Le samedi 25 novembre 2006 01:19, Fedora Extras repoclosure a ?crit : > > > Broken packages in fedora-extras-4-ppc: > > ---------------------------------------------------------------------- > > plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 > > > > Broken packages in fedora-extras-4-x86_64: > > ---------------------------------------------------------------------- > > plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 > > > > Broken packages in fedora-extras-4-i386: > > ---------------------------------------------------------------------- > > plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 > > > > Broken packages in fedora-extras-3-x86_64: > > ---------------------------------------------------------------------- > > plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 > > > > Broken packages in fedora-extras-3-i386: > > ---------------------------------------------------------------------- > > plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 > > How long whe have to endure these messages? > That been going on for more than 8 months... > Haven't we had about enough of this? > > If there is no packager, orphan it! Personally I don't see any point in flooding the mailing lists each and every day with this stuff. If you already have the maintainers e-mail addresses then use those, don't spam everyone else on the list.... From bugs.michael at gmx.net Sat Nov 25 15:06:42 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 25 Nov 2006 16:06:42 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611250457.16799.alain.portal@free.fr> Message-ID: <20061125160642.72184410.bugs.michael@gmx.net> On Sat, 25 Nov 2006 06:12:08 -0800, Christopher Stone wrote: > On 11/24/06, Alain PORTAL wrote: > > > > > Broken packages in fedora-extras-4-ppc: > > > plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 > > How long whe have to endure these messages? > > That been going on for more than 8 months... > > Haven't we had about enough of this? > > > > If there is no packager, orphan it! > > Personally I don't see any point in flooding the mailing lists each > and every day with this stuff. If you already have the maintainers > e-mail addresses then use those, don't spam everyone else on the > list.... Well, I think you misunderstood what Alain tried to point out. There are packages in FE which are broken for a very long time. Meanwhile, FC3 and FC4 have been transferred to Fedora Legacy, and since not even FESCO cares about this, they remain broken. Btw, the report could be appended to the build report (although that would delay the mail by approximately an hour and would create a not so nice dependency between push scripts and broken deps report). The report is not "spam", and one message per day is far from a flood. It is just one report some packagers hate, because it shows where FE sucks quite a lot (ABI breakage, e.g.). From chris.stone at gmail.com Sat Nov 25 15:11:15 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 25 Nov 2006 07:11:15 -0800 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <20061125160642.72184410.bugs.michael@gmx.net> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611250457.16799.alain.portal@free.fr> <20061125160642.72184410.bugs.michael@gmx.net> Message-ID: On 11/25/06, Michael Schwendt wrote: > On Sat, 25 Nov 2006 06:12:08 -0800, Christopher Stone wrote: > > > On 11/24/06, Alain PORTAL wrote: > > > > > > > Broken packages in fedora-extras-4-ppc: > > > > > plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 > > > > How long whe have to endure these messages? > > > That been going on for more than 8 months... > > > Haven't we had about enough of this? > > > > > > If there is no packager, orphan it! > > > > Personally I don't see any point in flooding the mailing lists each > > and every day with this stuff. If you already have the maintainers > > e-mail addresses then use those, don't spam everyone else on the > > list.... > > Well, I think you misunderstood what Alain tried to point out. There are > packages in FE which are broken for a very long time. Meanwhile, FC3 and > FC4 have been transferred to Fedora Legacy, and since not even FESCO cares > about this, they remain broken. > > Btw, the report could be appended to the build report (although that would > delay the mail by approximately an hour and would create a not so nice > dependency between push scripts and broken deps report). > > The report is not "spam", and one message per day is far from a flood. > It is just one report some packagers hate, because it shows where FE sucks > quite a lot (ABI breakage, e.g.). Could you have the FC3/4 breakage parts split up into another e-mail and send that part to a fedora legacy mailing list? From eamitdey at yahoo.com Sat Nov 25 15:15:23 2006 From: eamitdey at yahoo.com (Amit Dey) Date: Sat, 25 Nov 2006 07:15:23 -0800 (PST) Subject: new to open source Message-ID: <20061125151523.37764.qmail@web36807.mail.mud.yahoo.com> Hi everyone. I have never ever done any open source development before. And i would really like to start. I have some ideas about some application in my mind n I would like to implement them. Fedora extras seems to be a good place for this. But please tell me guys what exactly needs to be done to make sure that my application would be bundled with the next fedora core release. I just need some tips, that's all. I can make an application and submit it to fedora extras but will that be good enough. Will anyone even care to look at my app...? Is this the only way to do open source development in fedora. Thanks a lot. Regards Amit Dey. --------------------------------- Everyone is raving about the all-new Yahoo! Mail beta. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugs.michael at gmx.net Sat Nov 25 15:28:26 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 25 Nov 2006 16:28:26 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611250457.16799.alain.portal@free.fr> <20061125160642.72184410.bugs.michael@gmx.net> Message-ID: <20061125162826.c1418048.bugs.michael@gmx.net> On Sat, 25 Nov 2006 07:11:15 -0800, Christopher Stone wrote: > > The report is not "spam", and one message per day is far from a flood. > > It is just one report some packagers hate, because it shows where FE sucks > > quite a lot (ABI breakage, e.g.). > > Could you have the FC3/4 breakage parts split up into another e-mail > and send that part to a fedora legacy mailing list? Breakage in Extras is of interest to us, since usually it can be fixed with updates, rebuilds, and so on. If help from Core/Legacy is needed, bugzilla is the place where to ask for that. What to report where is just a matter of running a different report script. Repoclosure is run on all of Core + Updates + Legacy + Extras from FC-3 to Rawhide, but only broken packages in Extras are reported to this list. The full repoclosure output is not lost, as it's kept on disk for 14 days. From fedora at leemhuis.info Sat Nov 25 15:47:48 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 25 Nov 2006 16:47:48 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <20061125160642.72184410.bugs.michael@gmx.net> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611250457.16799.alain.portal@free.fr> <20061125160642.72184410.bugs.michael@gmx.net> Message-ID: <456865A4.2000603@leemhuis.info> Michael Schwendt schrieb: > On Sat, 25 Nov 2006 06:12:08 -0800, Christopher Stone wrote: >> On 11/24/06, Alain PORTAL wrote: >>>> Broken packages in fedora-extras-4-ppc: >>>> plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 >>> How long whe have to endure these messages? >>> That been going on for more than 8 months... >>> Haven't we had about enough of this? >>> If there is no packager, orphan it! >> Personally I don't see any point in flooding the mailing lists each >> and every day with this stuff. If you already have the maintainers >> e-mail addresses then use those, don't spam everyone else on the >> list.... > Well, I think you misunderstood what Alain tried to point out. There are > packages in FE which are broken for a very long time. Meanwhile, FC3 and > FC4 have been transferred to Fedora Legacy, and since not even FESCO cares > about this, they remain broken. It looks like FE3 and FE4 will soon be dropped quite soon. Some details at http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20061122 (search for the first occurrence of FE3). More will follow in a mail from bpepple -- he wanted to work out the details and post a RFC to f-e-l/f-maintainers. BTW, FESCo has to set priorities, too. The above problem (and all those packagers which have broken deps for quite some time) really annoys me a lot (and they make the reports quite useless because they are so long that probably nobody reads them anymore) -- but I and FESCo can't do everything alone (FESCo members do their FESCo work in their spare time, too) and there are IMHO things on the FESCo todo-list that are more important currently. I'd really like it if someone that cares (in an ideal world: the QA-Sig) and has some spare cycles just would step up and fix all those stuff that easily fixable -- this policy allow that: http://www.fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages The above problem is not easily fixable. My vote is to simply ship a update createrepo in Extras or ignore it for now as the dists are probably EOL soon. But the real solution is to prevent in the future that a package with broken deps ever hit the repo (that would afaics have prevented this particular problem) . CU thl From chris.stone at gmail.com Sat Nov 25 15:48:31 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 25 Nov 2006 07:48:31 -0800 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <20061125162826.c1418048.bugs.michael@gmx.net> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611250457.16799.alain.portal@free.fr> <20061125160642.72184410.bugs.michael@gmx.net> <20061125162826.c1418048.bugs.michael@gmx.net> Message-ID: On 11/25/06, Michael Schwendt wrote: > On Sat, 25 Nov 2006 07:11:15 -0800, Christopher Stone wrote: > > > > The report is not "spam", and one message per day is far from a flood. > > > It is just one report some packagers hate, because it shows where FE sucks > > > quite a lot (ABI breakage, e.g.). > > > > Could you have the FC3/4 breakage parts split up into another e-mail > > and send that part to a fedora legacy mailing list? > > Breakage in Extras is of interest to us, since usually it can be fixed > with updates, rebuilds, and so on. If help from Core/Legacy is needed, > bugzilla is the place where to ask for that. > > What to report where is just a matter of running a different report > script. Okay here is the problem I see from my perspective: Every single day I see this report come in, and every single day I do not see any of my packages listed. - This is tedious, I do not want to have to read a report every day to see if any of my packages are broken. Instead I should be notified via e-mail or bugzilla about breakage of my package. - Because after 100s report readings I have never seen any of my packages being broken, I tend to want to stop reading the reports. I'm sure others feel the same way. Eventually over time the number of people who actually read these reports diminishes thus reducing the effectiveness of the report. - Some packages in the report cannot be fixed or are simply ignored because the breakage exists in legacy. There needs to be a way to blacklist these packages from showing up in the report or else send them to another interested party such as fedora-legacy While I agree this is useful information for Fedora Extras, perhaps it would be better to email this list on a weekly basis instead of daily, and email the actual maintainers on a daily basis instead, or even come up with a sophisticated artificially intelligent automated way to file bugzilla reports on these issues. Just my (often ignored) opinion. From bugs.michael at gmx.net Sat Nov 25 16:22:06 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 25 Nov 2006 17:22:06 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611250457.16799.alain.portal@free.fr> <20061125160642.72184410.bugs.michael@gmx.net> <20061125162826.c1418048.bugs.michael@gmx.net> Message-ID: <20061125172206.633586a4.bugs.michael@gmx.net> On Sat, 25 Nov 2006 07:48:31 -0800, Christopher Stone wrote: > Okay here is the problem I see from my perspective: > > Every single day I see this report come in, and every single day I do > not see any of my packages listed. > > - This is tedious, I do not want to have to read a report every day to > see if any of my packages are broken. Instead I should be notified > via e-mail or bugzilla about breakage of my package. ??? That sounds as if you don't know that package owners do receive a private email when their package is broken. The mail is sent again every 14 days as long as the package remains broken. Those private messages are also summed up at the bottom of the big report to this list. It is just a "summary", not a report you must read everytime. > - Some packages in the report cannot be fixed or are simply ignored > because the breakage exists in legacy. No. The breakage is in either Extras or Core and ages until Core is so old that it is transferred to Legacy. > There needs to be a way to > blacklist these packages from showing up in the report or else send > them to another interested party such as fedora-legacy I've suggested a black-list several times before without clear feedback. Black-listing packages is like hiding something under the carpet. I can implement that if that is what we want. One step closer to the infamous dumping-ground of poorly maintained packages. From bugs.michael at gmx.net Sat Nov 25 16:28:38 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 25 Nov 2006 17:28:38 +0100 Subject: rpms/kile/devel .cvsignore, 1.7, 1.8 kile.spec, 1.30, 1.31 sources, 1.7, 1.8 In-Reply-To: <200611251555.kAPFtbSI017828@cvs-int.fedora.redhat.com> References: <200611251555.kAPFtbSI017828@cvs-int.fedora.redhat.com> Message-ID: <20061125172838.f7dbbc2b.bugs.michael@gmx.net> On Sat, 25 Nov 2006 10:55:37 -0500, Rex Dieter (rdieter) wrote: > Author: rdieter > > Update of /cvs/extras/rpms/kile/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv17809 > > Modified Files: > .cvsignore kile.spec sources > Log Message: > * Sat Nov 25 2006 Rex Dieter 1.9.3-1 > - kile-1.9.3, CVE-2006-6085 (#217238) http://buildsys.fedoraproject.org/build-status/job.psp?uid=22292 22292: kile-1.9.3-1.fc7 (needsign) Source: kile-1_9_3-1_fc6 Did you forget to update "common", or is this another case of buildsys misconfiguration? (see today's message to buildsys-list) From fedora at leemhuis.info Sat Nov 25 16:42:39 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 25 Nov 2006 17:42:39 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <20061125172206.633586a4.bugs.michael@gmx.net> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611250457.16799.alain.portal@free.fr> <20061125160642.72184410.bugs.michael@gmx.net> <20061125162826.c1418048.bugs.michael@gmx.net> <20061125172206.633586a4.bugs.michael@gmx.net> Message-ID: <4568727F.5080306@leemhuis.info> Michael Schwendt schrieb: > On Sat, 25 Nov 2006 07:48:31 -0800, Christopher Stone wrote: >[...] >> There needs to be a way to >> blacklist these packages from showing up in the report or else send >> them to another interested party such as fedora-legacy > I've suggested a black-list several times before without clear > feedback. Black-listing packages is like hiding something under the > carpet. Agreed, until now I don't see any good reason for a blacklist. > [...] CU thl From opensource at till.name Sat Nov 25 17:08:17 2006 From: opensource at till.name (Till Maas) Date: Sat, 25 Nov 2006 18:08:17 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <20061125172206.633586a4.bugs.michael@gmx.net> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <20061125172206.633586a4.bugs.michael@gmx.net> Message-ID: <200611251808.25697.opensource@till.name> On Saturday 25 November 2006 17:22, Michael Schwendt wrote: > That sounds as if you don't know that package owners do receive a private > email when their package is broken. The mail is sent again every 14 days > as long as the package remains broken. Those private messages are also > summed up at the bottom of the big report to this list. It is just > a "summary", not a report you must read everytime. How about a weekly summary of every broken dependency and a daily report of new broken dependencies? Maybe with a reference of how many broken dependencies a certain maintainer already has if there is one new and how many other packages have the same broken dependency? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alain.portal at free.fr Sat Nov 25 18:38:37 2006 From: alain.portal at free.fr (Alain PORTAL) Date: Sat, 25 Nov 2006 19:38:37 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <20061125160642.72184410.bugs.michael@gmx.net> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <20061125160642.72184410.bugs.michael@gmx.net> Message-ID: <200611251938.38139.alain.portal@free.fr> Hi, Le samedi 25 novembre 2006 16:06, Michael Schwendt a ?crit : > On Sat, 25 Nov 2006 06:12:08 -0800, Christopher Stone wrote: > > On 11/24/06, Alain PORTAL wrote: > > > > Broken packages in fedora-extras-4-ppc: > > > > > > > > plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 > > > > > > How long whe have to endure these messages? > > > That been going on for more than 8 months... > > > Haven't we had about enough of this? > > > > > > If there is no packager, orphan it! > > > > Personally I don't see any point in flooding the mailing lists each > > and every day with this stuff. If you already have the maintainers > > e-mail addresses then use those, don't spam everyone else on the > > list.... > > Well, I think you misunderstood what Alain tried to point out. There are > packages in FE which are broken for a very long time. Meanwhile, FC3 and > FC4 have been transferred to Fedora Legacy, and since not even FESCO cares > about this, they remain broken. That is exactly what I wanted to say. A daily report is really not a problem for me. What that make me crazy is the fact that this broken dependency isn't yet fixed and exist since before the FC-5 release. I think that is unacceptable for a tool used by packagers. Sorry for that slanging match, but I think I'm right... Yours sincerely, Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Sat Nov 25 19:01:48 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sat, 25 Nov 2006 14:01:48 -0500 Subject: EOL for FE3 and FE4 Message-ID: <1164481308.3417.9.camel@Chuck> In the recent Fedora Summit, it was decided that Fedora Core releases would be supported for 13 months (1). The main reason for this was that Fedora Legacy was not working properly for FC3 and FC4 due to a lack of manpower. In light of this, FESCo is planning to EOL for FE3 and FE4 to line-up our maintenance support length with Fedora Core's. Provided the community doesn't have any problems with this, we are planning to implement this in one month. (1) http://fedoraproject.org/wiki/FedoraSummit/SummitIRCLog 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 triad at df.lth.se Sat Nov 25 20:23:27 2006 From: triad at df.lth.se (Linus Walleij) Date: Sat, 25 Nov 2006 21:23:27 +0100 (CET) Subject: Adding (parts of) gstreamer-plugins-bad to FE? In-Reply-To: <456850B2.2050402@hhs.nl> References: <456850B2.2050402@hhs.nl> Message-ID: On Sat, 25 Nov 2006, Hans de Goede wrote: > qt > Quicktime container format support, through own gst code (no libs used), > this one is trouble some. I would really like to see this in FE as this > adds supports for videos made with many digital photo cameras to > gstreamer using applications (usually these camera's just dump a raw > audio stream and a serie of jpeg images into a .mov file. > > So where should this one go? I really don't know. Can anyone help here? AFAIK there are no patents surrounding the QuickTime stream format (probably they knew very well that there was prior art) so it could just be included. There are patents on other technology under the QuickTime umbrella (this is a blanket name) but not for the stream format itself. Linus From rdieter at math.unl.edu Sat Nov 25 20:41:28 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 25 Nov 2006 14:41:28 -0600 Subject: rpms/kile/devel .cvsignore, 1.7, 1.8 kile.spec, 1.30, 1.31 sources, 1.7, 1.8 References: <200611251555.kAPFtbSI017828@cvs-int.fedora.redhat.com> <20061125172838.f7dbbc2b.bugs.michael@gmx.net> Message-ID: Michael Schwendt wrote: > On Sat, 25 Nov 2006 10:55:37 -0500, Rex Dieter (rdieter) wrote: > >> Author: rdieter >> >> Update of /cvs/extras/rpms/kile/devel >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv17809 >> >> Modified Files: >> .cvsignore kile.spec sources >> Log Message: >> * Sat Nov 25 2006 Rex Dieter 1.9.3-1 >> - kile-1.9.3, CVE-2006-6085 (#217238) > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=22292 > > 22292: kile-1.9.3-1.fc7 (needsign) > > Source: kile-1_9_3-1_fc6 > > Did you forget to update "common", or is this another case of buildsys > misconfiguration? (see today's message to buildsys-list) Most likely (my) human error. -- Rex From j.w.r.degoede at hhs.nl Sat Nov 25 21:00:14 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 25 Nov 2006 22:00:14 +0100 Subject: lbreakout in fedora extras? Message-ID: <4568AEDE.1040703@hhs.nl> Hi all, I'm concidering packaging lbreakout for FE, but I think the name is a problem, so some days ago I send a kind request to upstream to change the name, of which I'll reproduce a part here as it decribes the issue at hand: "There currently is one problem with lbreakout (and other lgames) at the moment though, their names. We at Fedora try to be very carefully to make a 100% Free distro which isn't "tainted" in anyway. Sticking to lbreakout as example, the original breakout game is copyrighted by Atari which still exists, and breakout clearly qualifies as a trademark. If I'm to believe Atari's website its even a registered trademark, see: http://www.atari.com/us/games/atari_anniversary/pc And look at the "Breakout?" text." Thus I believe lbreakout cannot be included as is however Debian does have it in main. My guess is Debian just overlooked this and this cannot go into FE as is. Opinions anyone? Regards, Hans p.s. Chances are high that if the concensus is this cannot go in as is I'll do a rebranded version and package that. From bugs.michael at gmx.net Sat Nov 25 20:54:07 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 25 Nov 2006 21:54:07 +0100 Subject: EOL for FE3 and FE4 In-Reply-To: <1164481308.3417.9.camel@Chuck> References: <1164481308.3417.9.camel@Chuck> Message-ID: <20061125215407.7741360d.bugs.michael@gmx.net> On Sat, 25 Nov 2006 14:01:48 -0500, Brian Pepple wrote: > In the recent Fedora Summit, it was decided that Fedora Core releases > would be supported for 13 months (1). The main reason for this was that > Fedora Legacy was not working properly for FC3 and FC4 due to a lack of > manpower. > > In light of this, FESCo is planning to EOL for FE3 and FE4 to line-up > our maintenance support length with Fedora Core's. Provided the > community doesn't have any problems with this, we are planning to > implement this in one month. > > (1) http://fedoraproject.org/wiki/FedoraSummit/SummitIRCLog > > Thanks, > /B What does that mean (without reading that huge IRC log)? EOL as in stop-ship? As in close the build servers for FC-3 and FC-4 and make the push script disable FC-3 and FC-4, too? From buildsys at fedoraproject.org Sat Nov 25 21:20:42 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 25 Nov 2006 16:20:42 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-25 Message-ID: <20061125212042.3A53815212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 17 VLGothic-fonts-20061026-3 fontforge-20061025-1.fc7 fuse-2.6.0-2.fc7 gnupg2-2.0.1-0.3.rc1.fc7 jd-1.8.1-0.1.cvs061125.fc7 kile-1.9.3-1.fc7 libassuan-1.0.1-1.fc7 mlton-20061107-2.fc7 mod_mono-1.2.1-1.fc7 monodoc-1.2.1-1.fc7 ochusha-0.5.99.63.6-0.1.cvs061125.fc7 perl-Apache-DBI-1.05-2.fc7 perl-IPC-Cmd-0.36-1.fc7 pth-2.0.7-1.fc7 xerces-c-2.7.0-6.fc7 xfce4-diskperf-plugin-2.0-4.fc7 xsp-1.2.1-1.fc7 Packages built and released for Fedora Extras 6: 6 fontforge-20061025-1.fc6 fuse-2.6.0-2.fc6 kile-1.9.3-1.fc6.1 mlton-20061107-2.fc6 smart-0.42-40.fc6 xfce4-diskperf-plugin-2.0-4.fc6 Packages built and released for Fedora Extras 5: 4 fontforge-20061025-1.fc5 fuse-2.6.0-2.fc5 kile-1.9.3-1.fc5 smart-0.42-40.fc5 Packages built and released for Fedora Extras 4: 3 fuse-2.6.0-2.fc4 kile-1.9.3-1.fc4 smart-0.42-40.fc4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat Nov 25 22:31:14 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 25 Nov 2006 22:31:14 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-25 Message-ID: <20061125223114.19358.6992@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- Jochen AT herr-schmitt.de blender - 2.42a-5.fc7.i386 (2 days) blender - 2.42a-5.fc7.ppc (2 days) blender - 2.42a-5.fc7.x86_64 (2 days) andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 (25 days) centericq - 4.21.0-8.fc6.ppc (25 days) centericq - 4.21.0-8.fc6.x86_64 (25 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (28 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (28 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (28 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (28 days) orange - 0.3-3.cvs20051118.fc6.i386 (32 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (56 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (56 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (56 days) braden AT endoframe.com openvrml - 0.16.1-4.fc7.i386 (2 days) openvrml - 0.16.1-4.fc7.i386 (2 days) openvrml - 0.16.1-4.fc7.ppc (2 days) openvrml - 0.16.1-4.fc7.x86_64 (2 days) openvrml-devel - 0.16.1-4.fc7.i386 (2 days) openvrml-devel - 0.16.1-4.fc7.i386 (2 days) openvrml-devel - 0.16.1-4.fc7.ppc (2 days) openvrml-devel - 0.16.1-4.fc7.x86_64 (2 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (71 days) plague - 0.4.4.1-2.fc3.noarch (71 days) plague - 0.4.4.1-2.fc4.noarch (71 days) plague - 0.4.4.1-2.fc4.noarch (71 days) plague - 0.4.4.1-2.fc4.noarch (71 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (47 days) linphone - 1.2.0-4.fc5.ppc (47 days) linphone - 1.2.0-4.fc5.x86_64 (47 days) karlthered AT gmail.com gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.i386 (3 days) gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.i386 (3 days) gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.ppc (3 days) gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.x86_64 (3 days) matthias AT rpmforge.net php-eaccelerator - 5.1.6_0.9.5-2.fc7.i386 (9 days) php-eaccelerator - 5.1.6_0.9.5-2.fc7.ppc (9 days) php-eaccelerator - 5.1.6_0.9.5-2.fc7.x86_64 (9 days) oliver AT linux-kernel.at syck-php - 0.55-10.fc6.i386 (9 days) syck-php - 0.55-10.fc6.ppc (9 days) syck-php - 0.55-10.fc6.x86_64 (9 days) syck-php - 0.55-9.fc5.i386 (37 days) syck-php - 0.55-9.fc5.ppc (37 days) syck-php - 0.55-9.fc5.x86_64 (37 days) pertusus AT free.fr grads - 1.9b4-19.fc7.i386 (9 days) grads - 1.9b4-19.fc7.ppc (9 days) grads - 1.9b4-19.fc7.x86_64 (9 days) petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 (22 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (22 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (22 days) ghc642-gtk2hs - 0.9.10-4.fc6.i386 (22 days) ghc642-gtk2hs - 0.9.10-4.fc6.ppc (22 days) ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 (22 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 (22 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc (22 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 (22 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (27 days) tcallawa AT redhat.com gambas-runtime - 1.0.17-6.fc7.i386 (2 days) gambas-runtime - 1.0.17-6.fc7.ppc (2 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- blender-2.42a-5.fc7.ppc requires libgettextlib-0.15.so centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 gambas-runtime-1.0.17-6.fc7.ppc requires libgettextlib-0.15.so ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 grads-1.9b4-19.fc7.ppc requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.ppc requires gecko-libs = 0:2.0 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 openvrml-0.16.1-4.fc7.ppc requires firefox = 0:1.5.0.8 openvrml-devel-0.16.1-4.fc7.ppc requires firefox-devel = 0:1.5.0.8 php-eaccelerator-5.1.6_0.9.5-2.fc7.ppc requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.ppc requires php = 0:5.1.6 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- blender-2.42a-5.fc7.x86_64 requires libgettextlib-0.15.so()(64bit) centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 grads-1.9b4-19.fc7.x86_64 requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.i386 requires gecko-libs = 0:2.0 gtkmozembedmm-1.4.2.cvs20060817-5.fc7.x86_64 requires gecko-libs = 0:2.0 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) openvrml-0.16.1-4.fc7.i386 requires firefox = 0:1.5.0.8 openvrml-0.16.1-4.fc7.x86_64 requires firefox = 0:1.5.0.8 openvrml-devel-0.16.1-4.fc7.i386 requires firefox-devel = 0:1.5.0.8 openvrml-devel-0.16.1-4.fc7.x86_64 requires firefox-devel = 0:1.5.0.8 orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 php-eaccelerator-5.1.6_0.9.5-2.fc7.x86_64 requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.x86_64 requires php = 0:5.1.6 Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- blender-2.42a-5.fc7.i386 requires libgettextlib-0.15.so centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 gambas-runtime-1.0.17-6.fc7.i386 requires libgettextlib-0.15.so ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 grads-1.9b4-19.fc7.i386 requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.i386 requires gecko-libs = 0:2.0 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 openvrml-0.16.1-4.fc7.i386 requires firefox = 0:1.5.0.8 openvrml-devel-0.16.1-4.fc7.i386 requires firefox-devel = 0:1.5.0.8 php-eaccelerator-5.1.6_0.9.5-2.fc7.i386 requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.i386 requires php = 0:5.1.6 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: dcbw AT redhat.com package: plague - 0.4.4.1-2.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-2.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-2.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-2.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-2.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: libopensync-plugin-evolution2 - 0.19-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libedataserver-1.2.so.7 package: libopensync-plugin-evolution2 - 0.19-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libedataserver-1.2.so.7 package: libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libedataserver-1.2.so.7()(64bit) package: libopensync-plugin-evolution2 - 0.19-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libedataserver-1.2.so.7 package: sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: libetpan.so.6 package: sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libetpan.so.6()(64bit) package: sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: libetpan.so.6 From buildsys at fedoraproject.org Sat Nov 25 22:36:34 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 25 Nov 2006 17:36:34 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-25 Message-ID: <20061125223634.A291315212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 1 kile-1.9.3-1.fc3.2 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From lists at timj.co.uk Sat Nov 25 23:01:26 2006 From: lists at timj.co.uk (Tim Jackson) Date: Sat, 25 Nov 2006 23:01:26 +0000 Subject: Atmel binary firmware Message-ID: <4568CB46.1050608@timj.co.uk> Can anyone (spot?) confirm whether this: http://atmelwlandriver.sourceforge.net/license.txt is acceptable for FE? To my eyes it meets the "Binary Firmware" Guidelines. Thanks Tim From bugs.michael at gmx.net Sat Nov 25 23:47:51 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 26 Nov 2006 00:47:51 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <456865A4.2000603@leemhuis.info> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611250457.16799.alain.portal@free.fr> <20061125160642.72184410.bugs.michael@gmx.net> <456865A4.2000603@leemhuis.info> Message-ID: <20061126004751.ead52491.bugs.michael@gmx.net> On Sat, 25 Nov 2006 16:47:48 +0100, Thorsten Leemhuis wrote: > > Well, I think you misunderstood what Alain tried to point out. There are > > packages in FE which are broken for a very long time. Meanwhile, FC3 and > > FC4 have been transferred to Fedora Legacy, and since not even FESCO cares > > about this, they remain broken. > BTW, FESCo has to set priorities, too. The above problem (and all those > packagers which have broken deps for quite some time) really annoys me a > lot Some packages are broken for two months or more. Some even belong to FESCO members. One thing for sure, I have not created the repoclosure report scripts to become the grunt who enters all that breakage into bugzilla, just because some FE packagers prefer to ignore the broken deps report and/or the bi-weekly emails they receive. One option that is left: running a different script on the repoclosure reports and opening bugzilla tickets automatically. I can do that, I've done it before, but I don't like to do that with my own bugzilla account too often (I have enough open tickets like #216007). And I don't want to be the one to maintain the growing list of tickets as quite often packagers don't maintain their tickets themselves and apparently expect reporters to verify the fix. > (and they make the reports quite useless because they are so long > that probably nobody reads them anymore) -- but I and FESCo can't do > everything alone (FESCo members do their FESCo work in their spare time, > too) and there are IMHO things on the FESCo todo-list that are more > important currently. FESCO consists of 13 members. Not even an official statement has been made. It is questionable what FESCO's point of view is with regard to the growing list of problems. I don't ask you, Thorsten, to fix the crap. I just wonder where the steering is? FESCO should have the courage to contact a FE Contributor officially and request action, stop a contributor from adding further packages to FE prior to fixing published builds, or requiring a packager to name a co-maintainer. It would also be interested from a "steering" point of view, why packagers don't keep their packages in a working shape. > I'd really like it if someone that cares (in an > ideal world: the QA-Sig) and has some spare cycles just would step up > and fix all those stuff that easily fixable -- this policy allow that: > http://www.fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages > This doesn't fit too well into your scheme, as it results in some volunteers breaking stuff, other volunteers trying to fix the breakage. When the community gets > The above problem is not easily fixable. My vote is to simply ship a > update createrepo in Extras or ignore it for now as the dists are > probably EOL soon. Back when I was still in FESCO, we've removed the broken packages after a long time of waiting for a fix in Core. We could do that again (and e.g. only remove "plague" for FE3/FE4), but again as a last resort only. > But the real solution is to prevent in the future > that a package with broken deps ever hit the repo (that would afaics > have prevented this particular problem) . A theoretical and long-term solution which requires a lot of work and testing, as else it opens the infamous queue that leads to a growing pile of wreckage. From paul at all-the-johnsons.co.uk Sat Nov 25 23:47:51 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 25 Nov 2006 23:47:51 +0000 Subject: lbreakout in fedora extras? In-Reply-To: <4568AEDE.1040703@hhs.nl> References: <4568AEDE.1040703@hhs.nl> Message-ID: <1164498471.8591.126.camel@T7.Linux> Hi, > Thus I believe lbreakout cannot be included as is however Debian does > have it in main. My guess is Debian just overlooked this and this cannot > go into FE as is. Opinions anyone? I don't give a toss what the other distros do to be honest. If we're infringing on a registered name, it doesn't go in. Simple as that. TTFN Paul -- Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dennis at ausil.us Sat Nov 25 23:53:53 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 25 Nov 2006 17:53:53 -0600 Subject: EOL for FE3 and FE4 In-Reply-To: <20061125215407.7741360d.bugs.michael@gmx.net> References: <1164481308.3417.9.camel@Chuck> <20061125215407.7741360d.bugs.michael@gmx.net> Message-ID: <200611251753.53992.dennis@ausil.us> Once upon a time Saturday 25 November 2006 2:54 pm, Michael Schwendt wrote: > On Sat, 25 Nov 2006 14:01:48 -0500, Brian Pepple wrote: > > In the recent Fedora Summit, it was decided that Fedora Core releases > > would be supported for 13 months (1). The main reason for this was that > > Fedora Legacy was not working properly for FC3 and FC4 due to a lack of > > manpower. > > > > In light of this, FESCo is planning to EOL for FE3 and FE4 to line-up > > our maintenance support length with Fedora Core's. Provided the > > community doesn't have any problems with this, we are planning to > > implement this in one month. > > > > (1) http://fedoraproject.org/wiki/FedoraSummit/SummitIRCLog > > > > Thanks, > > /B > > What does that mean (without reading that huge IRC log)? > > EOL as in stop-ship? As in close the build servers for FC-3 and FC-4 and > make the push script disable FC-3 and FC-4, too? I would guess so. I must have missed that part of the FESCo meeting. AFAIK Legacy still has to decide what they are going to do. i dont think we should do anything until They decide. From bugs.michael at gmx.net Sun Nov 26 00:08:05 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 26 Nov 2006 01:08:05 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <200611251808.25697.opensource@till.name> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <20061125172206.633586a4.bugs.michael@gmx.net> <200611251808.25697.opensource@till.name> Message-ID: <20061126010805.05c31524.bugs.michael@gmx.net> On Sat, 25 Nov 2006 18:08:17 +0100, Till Maas wrote: > On Saturday 25 November 2006 17:22, Michael Schwendt wrote: > > > That sounds as if you don't know that package owners do receive a private > > email when their package is broken. The mail is sent again every 14 days > > as long as the package remains broken. Those private messages are also > > summed up at the bottom of the big report to this list. It is just > > a "summary", not a report you must read everytime. > > How about a weekly summary of every broken dependency and a daily report of > new broken dependencies? Yes. At least put the new breakage at the top of the report. And if there is no new breakage, the summary report won't be sent more often than every week or so. The EVR upgrade problems report to maintainers-list is too often, too. There is no visibile interest either in fixing that breakage, not even in response to bugzilla tickets. > Maybe with a reference of how many broken > dependencies a certain maintainer already has if there is one new and how > many other packages have the same broken dependency? Everybody is free to write code that creates different reports and different statistics. But more important is to reduce the number of broken packages. When the community gets larger and the number of problems increases, this asks for adjusted guidelines/policies. From mattdm at mattdm.org Sun Nov 26 01:50:13 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 25 Nov 2006 20:50:13 -0500 Subject: new to open source In-Reply-To: <20061125151523.37764.qmail@web36807.mail.mud.yahoo.com> References: <20061125151523.37764.qmail@web36807.mail.mud.yahoo.com> Message-ID: <20061126015013.GA14037@jadzia.bu.edu> On Sat, Nov 25, 2006 at 07:15:23AM -0800, Amit Dey wrote: > But please tell me guys what exactly needs to be done to make sure that > my application would be bundled with the next fedora core release. > I just need some tips, that's all. Cart before the horse. Make your application, make it useful (or interesting in some other way). > I can make an application and submit it to fedora extras but will that > be good enough. Will anyone even care to look at my app...? If there's a compelling reason for someone to be interested, yes, it will be good enough. > Is this the only way to do open source development in fedora. How else would there be? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Sun Nov 26 01:51:20 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 25 Nov 2006 20:51:20 -0500 Subject: EOL for FE3 and FE4 In-Reply-To: <200611251753.53992.dennis@ausil.us> References: <1164481308.3417.9.camel@Chuck> <20061125215407.7741360d.bugs.michael@gmx.net> <200611251753.53992.dennis@ausil.us> Message-ID: <20061126015120.GB14037@jadzia.bu.edu> On Sat, Nov 25, 2006 at 05:53:53PM -0600, Dennis Gilmore wrote: > AFAIK Legacy still has to decide what they are going to do. i dont think we > should do anything until They decide. I think the decision is defacto already made. It's just waiting on the 13-month thing to be official. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rc040203 at freenet.de Sun Nov 26 05:35:45 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 26 Nov 2006 06:35:45 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <4568727F.5080306@leemhuis.info> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611250457.16799.alain.portal@free.fr> <20061125160642.72184410.bugs.michael@gmx.net> <20061125162826.c1418048.bugs.michael@gmx.net> <20061125172206.633586a4.bugs.michael@gmx.net> <4568727F.5080306@leemhuis.info> Message-ID: <1164519346.29498.4.camel@mccallum.corsepiu.local> On Sat, 2006-11-25 at 17:42 +0100, Thorsten Leemhuis wrote: > Michael Schwendt schrieb: > > On Sat, 25 Nov 2006 07:48:31 -0800, Christopher Stone wrote: > >[...] > >> There needs to be a way to > >> blacklist these packages from showing up in the report or else send > >> them to another interested party such as fedora-legacy > > I've suggested a black-list several times before without clear > > feedback. Black-listing packages is like hiding something under the > > carpet. > > Agreed, until now I don't see any good reason for a blacklist. How about FESCO implementing some rules on "taking consequences" from EVR issues in FE not being taken care about? E.g. "broken deps > 4weeks", and the package will be automatically orphaned plus the maintainer's account will be withdrawn/canceled? Ralf From j.w.r.degoede at hhs.nl Sun Nov 26 07:10:36 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 26 Nov 2006 08:10:36 +0100 Subject: Atmel binary firmware In-Reply-To: <4568CB46.1050608@timj.co.uk> References: <4568CB46.1050608@timj.co.uk> Message-ID: <45693DEC.7000200@hhs.nl> Tim Jackson wrote: > Can anyone (spot?) confirm whether this: > > http://atmelwlandriver.sourceforge.net/license.txt > > is acceptable for FE? To my eyes it meets the "Binary Firmware" Guidelines. > Looks BSD except for the object code only thing, I can see nothing wrong with this, if I were you I would start packaging it up. You could wait for some official blessing if that gives you a warm fuzzy feeling though :) Regards, Hans From giallu at gmail.com Sun Nov 26 07:42:00 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 26 Nov 2006 08:42:00 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <1164519346.29498.4.camel@mccallum.corsepiu.local> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611250457.16799.alain.portal@free.fr> <20061125160642.72184410.bugs.michael@gmx.net> <20061125162826.c1418048.bugs.michael@gmx.net> <20061125172206.633586a4.bugs.michael@gmx.net> <4568727F.5080306@leemhuis.info> <1164519346.29498.4.camel@mccallum.corsepiu.local> Message-ID: On 11/26/06, Ralf Corsepius wrote: > On Sat, 2006-11-25 at 17:42 +0100, Thorsten Leemhuis wrote: > > Michael Schwendt schrieb: > > > On Sat, 25 Nov 2006 07:48:31 -0800, Christopher Stone wrote: > > >[...] > > >> There needs to be a way to > > >> blacklist these packages from showing up in the report or else send > > >> them to another interested party such as fedora-legacy > > > I've suggested a black-list several times before without clear > > > feedback. Black-listing packages is like hiding something under the > > > carpet. > > > > Agreed, until now I don't see any good reason for a blacklist. > > How about FESCO implementing some rules on "taking consequences" from > EVR issues in FE not being taken care about? > > E.g. "broken deps > 4weeks", and the package will be automatically > orphaned plus the maintainer's account will be withdrawn/canceled? > This sounds a little overkill (despite I agree 4 weeks are plenty of time to fix broken deps). Wouldn't be enough to remove the offending package from the repo? From giallu at gmail.com Sun Nov 26 07:47:39 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 26 Nov 2006 08:47:39 +0100 Subject: Atmel binary firmware In-Reply-To: <4568CB46.1050608@timj.co.uk> References: <4568CB46.1050608@timj.co.uk> Message-ID: On 11/26/06, Tim Jackson wrote: > Can anyone (spot?) confirm whether this: > > http://atmelwlandriver.sourceforge.net/license.txt > > is acceptable for FE? To my eyes it meets the "Binary Firmware" Guidelines. > We allows binary only firmwares into Fedora? I overlooked that one :) So which of those points prevents us from having the wireless ipw firmwares in Extras? From eamitdey at yahoo.com Sun Nov 26 08:14:15 2006 From: eamitdey at yahoo.com (Amit Dey) Date: Sun, 26 Nov 2006 00:14:15 -0800 (PST) Subject: UML Generating tool ? Message-ID: <4865.14102.qm@web36801.mail.mud.yahoo.com> Hello everyone... I was wondering whether there is a UML Modelling tool available in Fedora ? I did not find anything in fedora extras. Is there in fedora core. I did not install it with all the packages ? In case there isn't then I would like to start developing one. Any suggestions... Thanks. --------------------------------- Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: From panemade at gmail.com Sun Nov 26 08:36:08 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Sun, 26 Nov 2006 14:06:08 +0530 Subject: UML Generating tool ? In-Reply-To: <4865.14102.qm@web36801.mail.mud.yahoo.com> References: <4865.14102.qm@web36801.mail.mud.yahoo.com> Message-ID: Hi, On 11/26/06, Amit Dey wrote: > Hello everyone... > > I was wondering whether there is a UML Modelling tool available in Fedora ? > > I did not find anything in fedora extras. Is there in fedora core. I did not > install it with all the packages ? Check for Umbrello. Its in Fedora Core. You can find it under Applications->Programming. Regards, Parag. From bugs.michael at gmx.net Sun Nov 26 09:29:16 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 26 Nov 2006 10:29:16 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611250457.16799.alain.portal@free.fr> <20061125160642.72184410.bugs.michael@gmx.net> <20061125162826.c1418048.bugs.michael@gmx.net> <20061125172206.633586a4.bugs.michael@gmx.net> <4568727F.5080306@leemhuis.info> <1164519346.29498.4.camel@mccallum.corsepiu.local> Message-ID: <20061126102916.066e291e.bugs.michael@gmx.net> On Sun, 26 Nov 2006 08:42:00 +0100, Gianluca Sforna wrote: > > On Sat, 2006-11-25 at 17:42 +0100, Thorsten Leemhuis wrote: > > > Michael Schwendt schrieb: > > > > On Sat, 25 Nov 2006 07:48:31 -0800, Christopher Stone wrote: > > > >[...] > > > >> There needs to be a way to > > > >> blacklist these packages from showing up in the report or else send > > > >> them to another interested party such as fedora-legacy > > > > I've suggested a black-list several times before without clear > > > > feedback. Black-listing packages is like hiding something under the > > > > carpet. > > > > > > Agreed, until now I don't see any good reason for a blacklist. > > > > How about FESCO implementing some rules on "taking consequences" from > > EVR issues in FE not being taken care about? > > > > E.g. "broken deps > 4weeks", and the package will be automatically > > orphaned plus the maintainer's account will be withdrawn/canceled? > > > > This sounds a little overkill (despite I agree 4 weeks are plenty of > time to fix broken deps). We should stop considering anything like real QA if we are one step closer already to creating an non-healthy community environment where everything is based on "either shut up or fix the crap yourself" or where apparently things slip through because "nobody cares". Keep in mind that, preferably, every growth of the packager community should _reduce_ the load on individuals and increase the availability of human resources, which in turn increase the possibilities for team-work or even redundancy. The opposite is when growth of the community increases the load on some individuals (Security Team, QA Sig, other packagers who suddenly are confronted with a broken dep-chain). Since you cannot force volunteers to become co-maintainers of an arbitrary package, other actions are needed. To make sure that long-time broken packages don't pop up like mushrooms. Perhaps because some contributors try to take care of too many packages. And to make sure that trying to clean up the dist of fire'n'forget packages and AWOL maintainers shortly before the next release doesn't require increased efforts. > Wouldn't be enough to remove the offending package from the repo? WRT plague it didn't take long until somebody reported the missing packages as a bug. ;) In general, it is more interesting to learn why packages in "stable releases" of the dist remain broken for such a long time and whether some packagers are overloaded and should not add further packages. As an example: jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (46 days) linphone - 1.2.0-4.fc5.ppc (46 days) linphone - 1.2.0-4.fc5.x86_64 (46 days) ABI breakage in a library upgrade that was pushed to Extras. There is a chain of bug reports about it, including complaints of users. From dragoran at feuerpokemon.de Sun Nov 26 11:05:19 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 26 Nov 2006 12:05:19 +0100 Subject: Atmel binary firmware In-Reply-To: References: <4568CB46.1050608@timj.co.uk> Message-ID: <456974EF.8000106@feuerpokemon.de> Gianluca Sforna wrote: > On 11/26/06, Tim Jackson wrote: >> Can anyone (spot?) confirm whether this: >> >> http://atmelwlandriver.sourceforge.net/license.txt >> >> is acceptable for FE? To my eyes it meets the "Binary Firmware" >> Guidelines. >> > > We allows binary only firmwares into Fedora? I overlooked that one :) > So which of those points prevents us from having the wireless ipw > firmwares in Extras? > was about to ask the same, intel allows it, but for the in kernel drivers the firmware should be in core so that the hw works out of the box (this is solved by fedora 7 does not have core/extras) From mitr at volny.cz Sun Nov 26 11:11:31 2006 From: mitr at volny.cz (Miloslav Trmac) Date: Sun, 26 Nov 2006 12:11:31 +0100 Subject: Atmel binary firmware In-Reply-To: References: <4568CB46.1050608@timj.co.uk> Message-ID: <45697663.5040200@volny.cz> Gianluca Sforna napsal(a): > We allows binary only firmwares into Fedora? I overlooked that one :) > So which of those points prevents us from having the wireless ipw > firmwares in Extras? The specific license of the ipw firmware. IIRC it doesn't allow redistribution without some sort of click-through "I agree" step. Mirek From dragoran at feuerpokemon.de Sun Nov 26 11:14:05 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 26 Nov 2006 12:14:05 +0100 Subject: Atmel binary firmware In-Reply-To: <45697663.5040200@volny.cz> References: <4568CB46.1050608@timj.co.uk> <45697663.5040200@volny.cz> Message-ID: <456976FD.20107@feuerpokemon.de> Miloslav Trmac wrote: > > The specific license of the ipw firmware. IIRC it doesn't allow > redistribution without some sort of click-through "I agree" step. > Mirek > > http://bughost.org/ipw3945/LICENSE seems like we only need to ship this file From fedora at leemhuis.info Sun Nov 26 12:06:57 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 26 Nov 2006 13:06:57 +0100 Subject: EOL for FE3 and FE4 In-Reply-To: <20061125215407.7741360d.bugs.michael@gmx.net> References: <1164481308.3417.9.camel@Chuck> <20061125215407.7741360d.bugs.michael@gmx.net> Message-ID: <45698361.2060908@leemhuis.info> Michael Schwendt schrieb: > On Sat, 25 Nov 2006 14:01:48 -0500, Brian Pepple wrote: >> In the recent Fedora Summit, it was decided that Fedora Core releases >> would be supported for 13 months (1). The main reason for this was that >> Fedora Legacy was not working properly for FC3 and FC4 due to a lack of >> manpower. >> >> In light of this, FESCo is planning to EOL for FE3 and FE4 to line-up >> our maintenance support length with Fedora Core's. Provided the >> community doesn't have any problems with this, we are planning to >> implement this in one month. >> >> (1) http://fedoraproject.org/wiki/FedoraSummit/SummitIRCLog > > What does that mean (without reading that huge IRC log)? > > EOL as in stop-ship? As in close the build servers for FC-3 and FC-4 and > make the push script disable FC-3 and FC-4, too? This was simply not discussed yet -- just the idea "let's drop FE3 and FE4" came up so we said "yeah, let's discuss this on f-e-l and see what people think of it." So Michael (and everybody else): What would you like? CU thl From fedora at leemhuis.info Sun Nov 26 12:13:57 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 26 Nov 2006 13:13:57 +0100 Subject: ipw2[12]00 firmware (was: Re: Atmel binary firmware) In-Reply-To: References: <4568CB46.1050608@timj.co.uk> Message-ID: <45698505.2050103@leemhuis.info> Gianluca Sforna schrieb: > So which of those points prevents us from having the wireless ipw > firmwares in Extras? I asked a fedora licensing expert some weeks ago in private for his opinion on moving my ipw2[12]00-firmware packages from another 3rd-party repo to FE. I didn't get an answer yet. :-( If anyone wants to submit those firmware packages to Extras feel free to take my packages up and submit them for FE-review. CU thl From fedora at leemhuis.info Sun Nov 26 12:36:15 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 26 Nov 2006 13:36:15 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <20061126004751.ead52491.bugs.michael@gmx.net> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611250457.16799.alain.portal@free.fr> <20061125160642.72184410.bugs.michael@gmx.net> <456865A4.2000603@leemhuis.info> <20061126004751.ead52491.bugs.michael@gmx.net> Message-ID: <45698A3F.2000708@leemhuis.info> Michael Schwendt schrieb: > On Sat, 25 Nov 2006 16:47:48 +0100, Thorsten Leemhuis wrote: >>> Well, I think you misunderstood what Alain tried to point out. There are >>> packages in FE which are broken for a very long time. Meanwhile, FC3 and >>> FC4 have been transferred to Fedora Legacy, and since not even FESCO cares >>> about this, they remain broken. >> BTW, FESCo has to set priorities, too. The above problem (and all those >> packagers which have broken deps for quite some time) really annoys me a >> lot > Some packages are broken for two months or more. Some even belong to > FESCO members. > > One thing for sure, I have not created the repoclosure report scripts to > become the grunt who enters all that breakage into bugzilla, just because > some FE packagers prefer to ignore the broken deps report and/or the > bi-weekly emails they receive. > > One option that is left: running a different script on the repoclosure > reports and opening bugzilla tickets automatically. Well, they ignore the mails so I'd assume most will ignore the bugzilla reports, too. But if people disagree with that: Yeah, why not. > I can do that, I've > done it before, but I don't like to do that with my own bugzilla account > too often (I have enough open tickets like #216007). We could use "nobody at fedoraproject.org" for that. Just ask for the password and I'll tell you. Or setup a special e-mail address + bugzilla account for that. > [...] >> (and they make the reports quite useless because they are so long >> that probably nobody reads them anymore) -- but I and FESCo can't do >> everything alone (FESCo members do their FESCo work in their spare time, >> too) and there are IMHO things on the FESCo todo-list that are more >> important currently. > FESCO consists of 13 members. Not even an official statement has been > made. If you want a statement propose one, put it up for discussion on this list, integrate feedback you received on the list, show it to FESCo and we'll probably ACK it (FESCo members are encouraged to participate in the public discussion if they don't like major parts of the proposal) Otherwise you have to wait until somebody else (inside or outside of FESCO) finds time to do what I described above. > It is questionable what FESCO's point of view is with regard to the > growing list of problems. I don't ask you, Thorsten, to fix the crap. Well, I had planed to simply go trough the whole list and fix in CVS what I could fix easily. But I did not find the time yet. > I > just wonder where the steering is? FESCO should have the courage to > contact a FE Contributor officially and request action, stop a contributor > from adding further packages to FE prior to fixing published builds, or > requiring a packager to name a co-maintainer. I agree that we probably need something like what you outlined above, but somebody just has to work out a policy for that first (how many broken deps are okay, ...). FESCo has a lot to do already and I simply found no time for that yet (and I can't do anything alone). I don't know about the other FESCo members think about this. But you seemed to be interested in it, so it would be the best if you could work something out and propose it for FESCo (see above). > [...] >> I'd really like it if someone that cares (in an >> ideal world: the QA-Sig) and has some spare cycles just would step up >> and fix all those stuff that easily fixable -- this policy allow that: >> http://www.fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages > This doesn't fit too well into your scheme, as it results in some > volunteers breaking stuff, other volunteers trying to fix the breakage. > When the community gets Well, I think we need someone like a QA group to fix things for other people now and then. But the QA Sig could also handle what you outlined above, e.g. somehow put pressure on the contributors so they fix their stuff on their own. >> The above problem is not easily fixable. My vote is to simply ship a >> update createrepo in Extras or ignore it for now as the dists are >> probably EOL soon. > Back when I was still in FESCO, we've removed the broken packages after a > long time of waiting for a fix in Core. We could do that again (and > e.g. only remove "plague" for FE3/FE4), but again as a last resort only. Well, they are not installable in any case, so I think removing them is okay. I think just do it. Maybe someone steps up to work out a propsoe solution then. > [...] CU thl From fedora at leemhuis.info Sun Nov 26 12:43:09 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 26 Nov 2006 13:43:09 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <1164519346.29498.4.camel@mccallum.corsepiu.local> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611250457.16799.alain.portal@free.fr> <20061125160642.72184410.bugs.michael@gmx.net> <20061125162826.c1418048.bugs.michael@gmx.net> <20061125172206.633586a4.bugs.michael@gmx.net> <4568727F.5080306@leemhuis.info> <1164519346.29498.4.camel@mccallum.corsepiu.local> Message-ID: <45698BDD.1090106@leemhuis.info> Ralf Corsepius schrieb: > On Sat, 2006-11-25 at 17:42 +0100, Thorsten Leemhuis wrote: >> Michael Schwendt schrieb: >>> On Sat, 25 Nov 2006 07:48:31 -0800, Christopher Stone wrote: >>> [...] >>>> There needs to be a way to >>>> blacklist these packages from showing up in the report or else send >>>> them to another interested party such as fedora-legacy >>> I've suggested a black-list several times before without clear >>> feedback. Black-listing packages is like hiding something under the >>> carpet. >> Agreed, until now I don't see any good reason for a blacklist. > How about FESCO implementing some rules on "taking consequences" from > EVR issues in FE not being taken care about? Sounds like a good idea -- but you don't have to wait for FESCo -- the Committee has a lot of stuff to do already and the members to the work in their spare time, too. Someone inside or outside of FESCo that cares about this particular problem could just work out a detailed plan what to do. Then FESCo will probably simply ACK it and say "thanks for your help. > E.g. "broken deps > 4weeks", and the package will be automatically > orphaned plus the maintainer's account will be withdrawn/canceled? I agree with Gianluca: That's a bit overkill. But yes, something in that direction. CU thl From chris.stone at gmail.com Sun Nov 26 12:54:30 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 26 Nov 2006 04:54:30 -0800 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <45698A3F.2000708@leemhuis.info> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611250457.16799.alain.portal@free.fr> <20061125160642.72184410.bugs.michael@gmx.net> <456865A4.2000603@leemhuis.info> <20061126004751.ead52491.bugs.michael@gmx.net> <45698A3F.2000708@leemhuis.info> Message-ID: On 11/26/06, Thorsten Leemhuis wrote: > > [...] > >> I'd really like it if someone that cares (in an > >> ideal world: the QA-Sig) and has some spare cycles just would step up > >> and fix all those stuff that easily fixable -- this policy allow that: > >> http://www.fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages > > This doesn't fit too well into your scheme, as it results in some > > volunteers breaking stuff, other volunteers trying to fix the breakage. > > When the community gets > > Well, I think we need someone like a QA group to fix things for other > people now and then. But the QA Sig could also handle what you outlined > above, e.g. somehow put pressure on the contributors so they fix their > stuff on their own. IIRC, tibbs did this a few months ago on a package that was in the report for months and after he launched a rebuild the maintainer came on this message list and lambasted tibbs for launching a rebuild. tibbs then got upset and said he would never attempt to help out in this regard again. I think there was some technical reason why the rebuild should not have been done, so there needs to be a way for a developer to say, I cannot fix this dependency problem because of some other issue, and request QA SIGs to not push rebuilds. From fedora at leemhuis.info Sun Nov 26 13:06:05 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 26 Nov 2006 14:06:05 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611250457.16799.alain.portal@free.fr> <20061125160642.72184410.bugs.michael@gmx.net> <456865A4.2000603@leemhuis.info> <20061126004751.ead52491.bugs.michael@gmx.net> <45698A3F.2000708@leemhuis.info> Message-ID: <4569913D.7030104@leemhuis.info> Christopher Stone schrieb: > On 11/26/06, Thorsten Leemhuis wrote: >>> [...] >>>> I'd really like it if someone that cares (in an >>>> ideal world: the QA-Sig) and has some spare cycles just would step up >>>> and fix all those stuff that easily fixable -- this policy allow that: >>>> http://www.fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages >>> This doesn't fit too well into your scheme, as it results in some >>> volunteers breaking stuff, other volunteers trying to fix the breakage. >>> When the community gets >> Well, I think we need someone like a QA group to fix things for other >> people now and then. But the QA Sig could also handle what you outlined >> above, e.g. somehow put pressure on the contributors so they fix their >> stuff on their own. > IIRC, tibbs did this a few months ago on a package that was in the > report for months and after he launched a rebuild the maintainer came > on this message list and lambasted tibbs for launching a rebuild. > tibbs then got upset and said he would never attempt to help out in > this regard again. Yeah, I remember. > I think there was some technical reason why the rebuild should not > have been done, so there needs to be a way for a developer to say, I > cannot fix this dependency problem because of some other issue, and > request QA SIGs to not push rebuilds. A open bug should be enough as the one that does the update and rebuild should look at the open bugs before requesting the rebuild. CU thl From chris.stone at gmail.com Sun Nov 26 13:07:44 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 26 Nov 2006 05:07:44 -0800 Subject: New Comps Groups Message-ID: I plan on adding a couple new groups to comps under the main "Development" group. I am going to add "PHP Development", "Python Development", and "Perl Development" where all the php, python, and perl modules can go. This is basically part of the movement to add *everything* to comps. Normal C libraries will go under the already existing "Development Libraries" group. If you disagree with this move, scream bloody murder now. :) From chitlesh at fedoraproject.org Sun Nov 26 13:31:49 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 26 Nov 2006 14:31:49 +0100 Subject: mock and autoconf Broken pipe Message-ID: <13dbfe4f0611260531w3667f5apae1dcf18aad968f1@mail.gmail.com> Hai there I'm trying to mock my src.rpm: http://chitlesh.funpic.de/fedora/SRPM/keurocalc-0.9.7-0.1.src.rpm mock fails with /usr/bin/autoconf: line 493: echo: write error: Broken pipe see the build.log http://chitlesh.funpic.de/fedora/SPEC/build.log SPEC:http://chitlesh.funpic.de/fedora/SPEC/keurocalc.spec However what is strange is that on my system it compiles with : [...] + /usr/bin/make -f admin/Makefile.common cvs *** automake (GNU automake) 1.9.6 found. *** Creating acinclude.m4 make[1]: Entering directory `/home/chitlesh/rpmbuild/BUILD/keurocalc' [...] but on mock it compiles with: [...] + /usr/bin/make -f admin/Makefile.common cvs /usr/bin/autoconf: line 493: echo: write error: Broken pipe *** YOU'RE USING autoconf (GNU Autoconf) 2.61. *** KDE requires autoconf 2.53 or newer make: *** [cvs] Error 1 [...] Can anyone put some light on this, plz ? chitlsh -- http://clunixchit.blogspot.com From paul at all-the-johnsons.co.uk Sun Nov 26 13:46:02 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 26 Nov 2006 13:46:02 +0000 Subject: New Comps Groups In-Reply-To: References: Message-ID: <1164548762.13455.12.camel@T7.Linux> Hi, > If you disagree with this move, scream bloody murder now. :) Are you going to do the same with anything mono? It would makes sense to. TTFN Paul -- Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From chris.stone at gmail.com Sun Nov 26 13:56:11 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 26 Nov 2006 05:56:11 -0800 Subject: New Comps Groups In-Reply-To: <1164548762.13455.12.camel@T7.Linux> References: <1164548762.13455.12.camel@T7.Linux> Message-ID: On 11/26/06, Paul wrote: > Hi, > > > If you disagree with this move, scream bloody murder now. :) > > Are you going to do the same with anything mono? It would makes sense > to. Sure, I can add a "Mono Development" group as well. From rdieter at math.unl.edu Sun Nov 26 14:28:26 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 26 Nov 2006 08:28:26 -0600 Subject: mock and autoconf Broken pipe In-Reply-To: <13dbfe4f0611260531w3667f5apae1dcf18aad968f1@mail.gmail.com> References: <13dbfe4f0611260531w3667f5apae1dcf18aad968f1@mail.gmail.com> Message-ID: Chitlesh GOORAH wrote: > Hai there > I'm trying to mock my src.rpm: > http://chitlesh.funpic.de/fedora/SRPM/keurocalc-0.9.7-0.1.src.rpm > > mock fails with /usr/bin/autoconf: line 493: echo: write error: Broken pipe > see the build.log > http://chitlesh.funpic.de/fedora/SPEC/build.log > SPEC:http://chitlesh.funpic.de/fedora/SPEC/keurocalc.spec > > However what is strange is that on my system it compiles with : > [...] > + /usr/bin/make -f admin/Makefile.common cvs > *** automake (GNU automake) 1.9.6 found. > *** Creating acinclude.m4 > make[1]: Entering directory `/home/chitlesh/rpmbuild/BUILD/keurocalc' > [...] > > but on mock it compiles with: > [...] > + /usr/bin/make -f admin/Makefile.common cvs > /usr/bin/autoconf: line 493: echo: write error: Broken pipe > *** YOU'RE USING autoconf (GNU Autoconf) 2.61. > *** KDE requires autoconf 2.53 or newer > make: *** [cvs] Error 1 > [...] > > Can anyone put some light on this, plz ? Your own box works because it is fc6 which works. Your mock build is against devel (with autoconf-2.61) which doesn't. That's the (most likely) difference here. -- Rex From opensource at till.name Sun Nov 26 13:42:47 2006 From: opensource at till.name (Till Maas) Date: Sun, 26 Nov 2006 14:42:47 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <20061126010805.05c31524.bugs.michael@gmx.net> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611251808.25697.opensource@till.name> <20061126010805.05c31524.bugs.michael@gmx.net> Message-ID: <200611261442.55878.opensource@till.name> On Sunday 26 November 2006 01:08, Michael Schwendt wrote: > Everybody is free to write code that creates different reports and > different statistics. Is there any documentation about this? Another improvement for the broken dependencies and any other reports is a header with an URL to the wiki where the report is described, e.g. I do not really know how to interpret the broken dependencies reports and how one can fix this if ones packages show up there. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Sun Nov 26 13:56:48 2006 From: opensource at till.name (Till Maas) Date: Sun, 26 Nov 2006 14:56:48 +0100 Subject: repoview for debuginfo packages? In-Reply-To: <20061028031427.3ae5df5d.bugs.michael@gmx.net> References: <20061028031427.3ae5df5d.bugs.michael@gmx.net> Message-ID: <200611261456.57308.opensource@till.name> On Saturday 28 October 2006 03:14, Michael Schwendt wrote: > Do we really want or need extra repoview pages for debuginfo packages? > Who browses them in addition to the repoview pages for normal packages? I find it quite useful to get packages by hand from repositories I normally do not have enabled. In my bookmarks I have links to all the relevant repodata directories, so this works a lot faster than using yum, too. An improvement would be to have all flavors of a package linked within repoview (I don't know, whether or not this is supported, though). On the freshrpms homepage for example one can browse from a rpm to the src.rpm and from there to every build rpm. Btw. Is there a reason why repoview is not used in Core? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dan at danny.cz Sun Nov 26 14:37:58 2006 From: dan at danny.cz (Dan Horak) Date: Sun, 26 Nov 2006 15:37:58 +0100 Subject: mock and autoconf Broken pipe In-Reply-To: References: <13dbfe4f0611260531w3667f5apae1dcf18aad968f1@mail.gmail.com> Message-ID: <1164551878.3443.9.camel@eagle.danny.cz> Rex Dieter p??e v Ne 26. 11. 2006 v 08:28 -0600: > Chitlesh GOORAH wrote: > > Hai there > > I'm trying to mock my src.rpm: > > http://chitlesh.funpic.de/fedora/SRPM/keurocalc-0.9.7-0.1.src.rpm > > > > mock fails with /usr/bin/autoconf: line 493: echo: write error: Broken pipe > > see the build.log > > http://chitlesh.funpic.de/fedora/SPEC/build.log > > SPEC:http://chitlesh.funpic.de/fedora/SPEC/keurocalc.spec > > > > However what is strange is that on my system it compiles with : > > [...] > > + /usr/bin/make -f admin/Makefile.common cvs > > *** automake (GNU automake) 1.9.6 found. > > *** Creating acinclude.m4 > > make[1]: Entering directory `/home/chitlesh/rpmbuild/BUILD/keurocalc' > > [...] > > > > but on mock it compiles with: > > [...] > > + /usr/bin/make -f admin/Makefile.common cvs > > /usr/bin/autoconf: line 493: echo: write error: Broken pipe > > *** YOU'RE USING autoconf (GNU Autoconf) 2.61. > > *** KDE requires autoconf 2.53 or newer > > make: *** [cvs] Error 1 > > [...] > > > > Can anyone put some light on this, plz ? > > Your own box works because it is fc6 which works. Your mock build is > against devel (with autoconf-2.61) which doesn't. That's the (most > likely) difference here. There is probably a wrong check for the autoconf version. I had to solve similar problem for codeblocks where were wrong regular expressions doing the check. Dan From mtasaka at ioa.s.u-tokyo.ac.jp Sun Nov 26 14:42:45 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 26 Nov 2006 23:42:45 +0900 Subject: mock and autoconf Broken pipe In-Reply-To: <13dbfe4f0611260531w3667f5apae1dcf18aad968f1@mail.gmail.com> References: <13dbfe4f0611260531w3667f5apae1dcf18aad968f1@mail.gmail.com> Message-ID: <4569A7E5.7030000@ioa.s.u-tokyo.ac.jp> Chitlesh GOORAH wrote: > Hai there > I'm trying to mock my src.rpm: > http://chitlesh.funpic.de/fedora/SRPM/keurocalc-0.9.7-0.1.src.rpm > > mock fails with /usr/bin/autoconf: line 493: echo: write error: Broken pipe > see the build.log > http://chitlesh.funpic.de/fedora/SPEC/build.log > SPEC:http://chitlesh.funpic.de/fedora/SPEC/keurocalc.spec > > Can anyone put some light on this, plz ? > > chitlsh Check around the lines 35, 50 of admin/cvs.sh . This requires autoconf 2.5?, however, rawhide autoconf is 2.61. Mamoru Tasaka From chitlesh at fedoraproject.org Sun Nov 26 14:45:50 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 26 Nov 2006 15:45:50 +0100 Subject: mock and autoconf Broken pipe In-Reply-To: <4569A7E5.7030000@ioa.s.u-tokyo.ac.jp> References: <13dbfe4f0611260531w3667f5apae1dcf18aad968f1@mail.gmail.com> <4569A7E5.7030000@ioa.s.u-tokyo.ac.jp> Message-ID: <13dbfe4f0611260645g7d191c8dq71f1a2ea9c34a1b6@mail.gmail.com> On 11/26/06, Mamoru Tasaka < hidden > wrote: > Check around the lines 35, 50 of admin/cvs.sh . > This requires autoconf 2.5?, however, rawhide autoconf is 2.61. > > Mamoru Tasaka > However shouldn't it grab automake instead of autoconf in mock ? chitlesh -- http://clunixchit.blogspot.com From mtasaka at ioa.s.u-tokyo.ac.jp Sun Nov 26 15:10:04 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 27 Nov 2006 00:10:04 +0900 Subject: mock and autoconf Broken pipe In-Reply-To: <13dbfe4f0611260645g7d191c8dq71f1a2ea9c34a1b6@mail.gmail.com> References: <13dbfe4f0611260531w3667f5apae1dcf18aad968f1@mail.gmail.com> <4569A7E5.7030000@ioa.s.u-tokyo.ac.jp> <13dbfe4f0611260645g7d191c8dq71f1a2ea9c34a1b6@mail.gmail.com> Message-ID: <4569AE4C.3040000@ioa.s.u-tokyo.ac.jp> Chitlesh GOORAH wrote: > On 11/26/06, Mamoru Tasaka < hidden > wrote: >> Check around the lines 35, 50 of admin/cvs.sh . >> This requires autoconf 2.5?, however, rawhide autoconf is 2.61. >> >> Mamoru Tasaka >> > > However shouldn't it grab automake instead of autoconf in mock ? Ah, I found what you mean. For this case * admin/Makefile.common calls admin/cvs.sh * Then admin/cvs.sh 1. check autoconf, then autoheader. If version check succeeds, then no output is printed. When version check fails, it complains as you are seeing. 2. next check automake. When this succeeds, admin/cvs.sh reports what type of automake is found. What I did is just I read admin/cvs.sh and checked what are actually done. These behavior are written in the function check_autotool_versions() in admin/cvs.sh. Mamoru From dcbw at redhat.com Sun Nov 26 15:51:22 2006 From: dcbw at redhat.com (Dan Williams) Date: Sun, 26 Nov 2006 10:51:22 -0500 Subject: buildsys queue In-Reply-To: <20061125114237.e06286b0.bugs.michael@gmx.net> References: <20061124190552.GF31787@neu.nirvana> <20061124191013.GG31787@neu.nirvana> <1164425241.2637.0.camel@localhost.localdomain> <20061125114237.e06286b0.bugs.michael@gmx.net> Message-ID: <1164556282.4059.8.camel@localhost.localdomain> On Sat, 2006-11-25 at 11:42 +0100, Michael Schwendt wrote: > On Fri, 24 Nov 2006 22:27:21 -0500, Dan Williams wrote: > > > On Fri, 2006-11-24 at 20:10 +0100, Axel Thimm wrote: > > > On Fri, Nov 24, 2006 at 08:05:52PM +0100, Axel Thimm wrote: > > > > the queue seems to be 2+ days large, is that due to some hardware > > > > issues mentioned some time ago? If not, could someone please sign/push > > > > the packages? Thanks! > > > > > > Forget it, I just saw that some packages have been pushed, I just > > > misinterpreted the status on > > > http://buildsys.fedoraproject.org/build-status/success.psp, I thought > > > that if the packages are tagged as "needsign" then they still need to > > > be signed and pushed to the repo. > > > > > > Would it make sense to add a state of "signedandpushed" or similar? > > > > That state exists, but nobody bothers to move then from 'needsign' to > > 'finished'. Technically the push scripts could do this, but they don't. > > What is needed to get it done? > > The push script does not interface with plague in any way yet, so it does > not know anything about build job numbers. It could reconstruct the build > job tag from the name/version directory entries in the needsign repo. Is > that worth anything? Well, you'll need job #s from the server. Essentially, you could query the server for all jobs in 'needsign' state (which means they are done of course) and grab the package name and version, and then reconstruct the path to each package's finished RPM directory, and then do whatever the script normally does. If the script is successful for that package, it tells the build server to mark the job as 'finished'. The 'finished' calls can be batched up for speed (up to a certain request length dictated by SQL request length sizes). > A quick grep on the plague server code returns: > > # Marking 'needsign' jobs as finished requires admin privs > > Sounds like a first roadblock. What kind of "admin privs" would we need? Whoever runs the push scripts will need their plague account marked with admin privs. The plague client will talk to the server using the certificate in ~/.plague-client.cfg (the "user-cert" option in there), or will use the certificate in whatever file is pointed to by the PLAGUE_CLIENT_CONFIG environment variable. Whatever user the cert is for needs the admin privs. In the end, I don't really think it's worth spending a lot of time on this unless you're really interested. Everything seems to be going fine already, we've got 22,000+ jobs in needsign state and it's not a problem :) If somebody is really interested in the "correctness" of the process, then they could implement this. Otherwise I don't think there's a burning need. Dan From giallu at gmail.com Sun Nov 26 16:04:02 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 26 Nov 2006 17:04:02 +0100 Subject: UML Generating tool ? In-Reply-To: References: <4865.14102.qm@web36801.mail.mud.yahoo.com> Message-ID: On 11/26/06, Parag N(????) wrote: > Hi, > On 11/26/06, Amit Dey wrote: > > Hello everyone... > > > > I was wondering whether there is a UML Modelling tool available in Fedora ? > > > > I did not find anything in fedora extras. Is there in fedora core. I did not > > install it with all the packages ? > Check for Umbrello. Its in Fedora Core. You can find it under > Applications->Programming. But only if you installed kdesdk... From eamitdey at yahoo.com Sun Nov 26 17:33:47 2006 From: eamitdey at yahoo.com (Amit Dey) Date: Sun, 26 Nov 2006 09:33:47 -0800 (PST) Subject: uml generating tool Message-ID: <20061126173347.12546.qmail@web36807.mail.mud.yahoo.com> Well Parag...I undertand that Ubmrello is an UML Modelling tool. But is a KDE based application. How about if I make something for GNOME. Would that be useful ? Or is there a similar application for GNOME too ( God...i wish you say no ). Regards. Amit Dey. ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited -------------- next part -------------- An HTML attachment was scrubbed... URL: From wart at kobold.org Sun Nov 26 18:44:43 2006 From: wart at kobold.org (Wart) Date: Sun, 26 Nov 2006 10:44:43 -0800 Subject: New Comps Groups In-Reply-To: References: Message-ID: <4569E09B.3010107@kobold.org> Christopher Stone wrote: > I plan on adding a couple new groups to comps under the main > "Development" group. I am going to add "PHP Development", "Python > Development", and "Perl Development" where all the php, python, and > perl modules can go. > > This is basically part of the movement to add *everything* to comps. > Normal C libraries will go under the already existing "Development > Libraries" group. > > If you disagree with this move, scream bloody murder now. :) If we're going to move to " Development" groups for language-specific development modules, then I'd also like to ask for a "Tcl Development" group for the 18+ Tcl modules in FE. --Wart From chris.stone at gmail.com Sun Nov 26 18:47:38 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 26 Nov 2006 10:47:38 -0800 Subject: New Comps Groups In-Reply-To: <4569E09B.3010107@kobold.org> References: <4569E09B.3010107@kobold.org> Message-ID: On 11/26/06, Wart wrote: > Christopher Stone wrote: > > I plan on adding a couple new groups to comps under the main > > "Development" group. I am going to add "PHP Development", "Python > > Development", and "Perl Development" where all the php, python, and > > perl modules can go. > > > > This is basically part of the movement to add *everything* to comps. > > Normal C libraries will go under the already existing "Development > > Libraries" group. > > > > If you disagree with this move, scream bloody murder now. :) > > If we're going to move to " Development" groups for > language-specific development modules, then I'd also like to ask for a > "Tcl Development" group for the 18+ Tcl modules in FE. Would perhaps "Tcl/Tk Development" be better? From vonbrand at inf.utfsm.cl Sun Nov 26 18:58:26 2006 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 26 Nov 2006 15:58:26 -0300 Subject: New Comps Groups In-Reply-To: Your message of "Sun, 26 Nov 2006 10:44:43 -0800." <4569E09B.3010107@kobold.org> Message-ID: <200611261858.kAQIwQgr015046@laptop13.inf.utfsm.cl> Wart wrote: [...] > If we're going to move to " Development" groups for > language-specific development modules, then I'd also like to ask for a > "Tcl Development" group for the 18+ Tcl modules in FE. What about Ruby, C++, ...? Tk (yes, that one is usable from a variety of languages)? The various RDBMses? This will give a huge list of new groups. I'd vote for a system based on /functionality/ first, not implementation details like language. And I fail to see what good it could do to "Pull in all Perl related stuff", you probably need just a spattering of CPAN anyway. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From chris.stone at gmail.com Sun Nov 26 19:12:58 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 26 Nov 2006 11:12:58 -0800 Subject: New Comps Groups In-Reply-To: <200611261858.kAQIwQgr015046@laptop13.inf.utfsm.cl> References: <4569E09B.3010107@kobold.org> <200611261858.kAQIwQgr015046@laptop13.inf.utfsm.cl> Message-ID: On 11/26/06, Horst H. von Brand wrote: > Wart wrote: > > [...] > > > If we're going to move to " Development" groups for > > language-specific development modules, then I'd also like to ask for a > > "Tcl Development" group for the 18+ Tcl modules in FE. > > What about Ruby, C++, ...? Tk (yes, that one is usable from a variety of > languages)? The various RDBMses? This will give a huge list of new groups. There already exists a group for Ruby, C++ libraries would just go in the generalized "Development Libraries" group, and I proposed combining Tcl with Tk. I'm not sure what you mean by the various RDBMses, can you give an example? > > I'd vote for a system based on /functionality/ first, not implementation > details like language. And I fail to see what good it could do to "Pull in > all Perl related stuff", you probably need just a spattering of CPAN > anyway. The purpose of this is not to pull in every single Perl module. The main purpose is to make it easier for people to find packages. I believe that if we use a system based on functionality we would end up with a lot more groups and you end up with tons of packages that cross over until multiple functionality groups. We want people to be able to find packages easily. So if you are a developer using pirut, you already know what language you are using, and you want to know what packages are available for your language. I believe end-users want to know for example what PHP modules are available to them, it is easy to find out this information when grouped by language. Ofcourse we do have some functionality groups such as "Web Development", "GNOME Development" and you can easily place your libraries or modules in multiple groups if you wish. Please mention any functionality groups you think are missing, but keep in mind it should be a group that has a lot of packages. The "Web Development" group currently has zero packages in it, so I question its usefulness. From wart at kobold.org Sun Nov 26 20:17:38 2006 From: wart at kobold.org (Wart) Date: Sun, 26 Nov 2006 12:17:38 -0800 Subject: New Comps Groups In-Reply-To: References: <4569E09B.3010107@kobold.org> Message-ID: <4569F662.3070602@kobold.org> Christopher Stone wrote: > On 11/26/06, Wart wrote: >> Christopher Stone wrote: >> > I plan on adding a couple new groups to comps under the main >> > "Development" group. I am going to add "PHP Development", "Python >> > Development", and "Perl Development" where all the php, python, and >> > perl modules can go. >> > >> > This is basically part of the movement to add *everything* to comps. >> > Normal C libraries will go under the already existing "Development >> > Libraries" group. >> > >> > If you disagree with this move, scream bloody murder now. :) >> >> If we're going to move to " Development" groups for >> language-specific development modules, then I'd also like to ask for a >> "Tcl Development" group for the 18+ Tcl modules in FE. > > Would perhaps "Tcl/Tk Development" be better? Probably, since most people don't make the distinction between Tcl and Tk in many cases. --Wart From bugs.michael at gmx.net Sun Nov 26 21:24:37 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 26 Nov 2006 22:24:37 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <200611261442.55878.opensource@till.name> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611251808.25697.opensource@till.name> <20061126010805.05c31524.bugs.michael@gmx.net> <200611261442.55878.opensource@till.name> Message-ID: <20061126222437.256cc0a9.bugs.michael@gmx.net> On Sun, 26 Nov 2006 14:42:47 +0100, Till Maas wrote: > On Sunday 26 November 2006 01:08, Michael Schwendt wrote: > > > Everybody is free to write code that creates different reports and > > different statistics. > > Is there any documentation about this? Nothing beyond code in "fedora" cvs: http://cvs.fedora.redhat.com/viewcvs/?root=fedora > Another improvement for the broken dependencies and any other reports is a > header with an URL to the wiki where the report is described, e.g. I do not > really know how to interpret the broken dependencies reports and how one can > fix this if ones packages show up there. If you query your binary rpm like rpm --query --requires --package foo-1.0-1.i386.rpm you get a list of what things your package depends on (library SONAMEs, other packages' names, interpreter programs, e.g.). If anything of that is not provided by any package in the repository, the report lists what is missing: blender-2.42a-5.fc7.i386 requires libgettextlib-0.15.so means "blender" is broken because no package provides the needed "libgettextlib-0.15.so". From opensource at till.name Sun Nov 26 21:59:17 2006 From: opensource at till.name (Till Maas) Date: Sun, 26 Nov 2006 22:59:17 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <20061126222437.256cc0a9.bugs.michael@gmx.net> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611261442.55878.opensource@till.name> <20061126222437.256cc0a9.bugs.michael@gmx.net> Message-ID: <200611262259.25815.opensource@till.name> On Sunday 26 November 2006 22:24, Michael Schwendt wrote: > blender-2.42a-5.fc7.i386 requires libgettextlib-0.15.so > > means "blender" is broken because no package provides the needed > "libgettextlib-0.15.so". And what is it the maintainer of blender can do about this? Doesn't this mean, that the maintainer of libgettext needs to do something? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Sun Nov 26 22:17:18 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 26 Nov 2006 23:17:18 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <200611262259.25815.opensource@till.name> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611261442.55878.opensource@till.name> <20061126222437.256cc0a9.bugs.michael@gmx.net> <200611262259.25815.opensource@till.name> Message-ID: <20061126231718.d31a91b4.bugs.michael@gmx.net> On Sun, 26 Nov 2006 22:59:17 +0100, Till Maas wrote: > On Sunday 26 November 2006 22:24, Michael Schwendt wrote: > > > blender-2.42a-5.fc7.i386 requires libgettextlib-0.15.so > > > > means "blender" is broken because no package provides the needed > > "libgettextlib-0.15.so". > > And what is it the maintainer of blender can do about this? Doesn't this mean, > that the maintainer of libgettext needs to do something? In this case it means that "gettext" in Fedora Core Development was upgraded in an incompatible way and provides a newer libgettextlib with a new SONAME (on FC6 it is still "libgettextlib-0.14.6.so") and that "blender" must be updated and compiled/linked with the upgraded "gettext" and "gettext-devel" packages. Dependencies on library SONAMEs are found by rpmbuild at build-time. When "blender" was built, it was built against libgettextlib-0.15.so. That library is no longer available, because "gettext" was upgraded. HTH. From triad at df.lth.se Sun Nov 26 22:18:14 2006 From: triad at df.lth.se (Linus Walleij) Date: Sun, 26 Nov 2006 23:18:14 +0100 (CET) Subject: UML Generating tool ? In-Reply-To: <4865.14102.qm@web36801.mail.mud.yahoo.com> References: <4865.14102.qm@web36801.mail.mud.yahoo.com> Message-ID: On Sun, 26 Nov 2006, Amit Dey wrote: > I was wondering whether there is a UML Modelling tool available in > Fedora ? I always use Dia for creating UML charts. That's one of the real good Dia features. Linus From lists at timj.co.uk Sun Nov 26 22:21:40 2006 From: lists at timj.co.uk (Tim Jackson) Date: Sun, 26 Nov 2006 22:21:40 +0000 Subject: UML Generating tool ? In-Reply-To: References: <4865.14102.qm@web36801.mail.mud.yahoo.com> Message-ID: <456A1374.3020707@timj.co.uk> Linus Walleij wrote: > I always use Dia for creating UML charts. That's one of the real good > Dia features. and with the script "tedia2sql" (tedia2sql.tigris.org) you can auto-convert the diagrams to SQL too. Handy. Tim From paul at xelerance.com Sun Nov 26 22:32:52 2006 From: paul at xelerance.com (Paul Wouters) Date: Sun, 26 Nov 2006 23:32:52 +0100 (CET) Subject: l2tpd to xl2tpd request Message-ID: Hi, I am currently the maintainer of l2tpd, an L2TP daemon for use with IPsec. Upstream has stopped about a year ago with maintaining this version. Xelerance (which is my other hat) has forked this source into xl2tpd in August this year. Since then, the l2tpd package in FE has more or less been our xl2tpd package - that is l2tpd-0.69 with the Xelerance patches. These are not just bugfixes (for Windows XP tunnel closing bugs), but also feature enhancements, such as IPsec Security Association tracking to support multiple l2tp/ipsec clients behind the same NAT router, and different l2tp/ipsec clients using the same internal NAT'ed IP behind different NAT routers. It does not seem to make much sense to me to support xl2tpd in two versions. One from Xelerance and one as a diff set to the original for FE. xl2tpd is a superset of l2tpd features - no functionality is lost. I would like to replace the l2tpd package with the xl2tpd package. Since I am usptream for xl2tpd, there is a formal conflict of interest, so I would like to get the green light from people on the list here. xl2tpd-1.1.06 completes the migration and rename of config files and binaries. It also supports migrating existing configurations from /etc/l2tpd/ to /etc/xl2tpd/ The xl2tpd package is a continuation of the FE aproved l2tpd package and can be checkd at: ftp://ftp.xelerance.com/xl2tpd/xl2tpd.spec ftp://ftp.xelerance.com/xl2tpd/xl2tpd-1.1.06-1.src.rpm The Changelog upto the original changelog follows. Note that part of this was already in the FE l2tpd package as patches to the original l2tpd source. I would really prefer to obsolete l2tpd for xl2tpd, but if someone is set on maintaining the l2tpd package, I see no problem in handing it over. Paul v1.1.06 * Build xl2tpd and use /etc/xl2tpd/xl2tpd.* configuration files with fallback to /etc/l2tpd/l2tpd.* configuration files. * Support for pppol2tp's kernel mode L2TP. Patch by Cedric Schieli * Documented IPsec SA reference tracking for usewith Openswan * Added patents documentation. * Migration support on xl2tpd.spec for l2tpd -> xl2tpd * Moved to use /etc/xl2tpd/ and /usr/sbin/xl2tpd v1.1.05 * Changed versioning scheme to match Xelerance standards * IPsec SA reference tracking added (used with Openswan's IPsec transport mode) This adds support for multiple clients behind the same NAT router, and multiple clients on the same internal IP behind different NAT routers. * Fix for Windows clients that send the wrong tunnel ID for closing tunnels v1.04 * actually, 1.03 tag in GIT was in the wrong place. This is the right release. v1.03 * fixes for gcc 4.xx compilation v1.02 * udpated CHNANGELOG v1.01 * various debugging added, but debugging should not be on by default * async/sync conversion routines must be ready for possibility that the read will block due to routing loops * refactored control socket handling. * use man page in doc/ * move all logic about pty usage to pty.c try ptmx first. if it fails try legacy ptys * rename log() to l2tp_log(), as "log" is a math function. v1.00 * First version managed by Xelerance, called xl2tpd. * If we aren't deamonized, then log to stderr. * added install: and DESTDIR support From opensource at till.name Sun Nov 26 22:41:17 2006 From: opensource at till.name (Till Maas) Date: Sun, 26 Nov 2006 23:41:17 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <20061126231718.d31a91b4.bugs.michael@gmx.net> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611262259.25815.opensource@till.name> <20061126231718.d31a91b4.bugs.michael@gmx.net> Message-ID: <200611262341.42841.opensource@till.name> On Sunday 26 November 2006 23:17, Michael Schwendt wrote: > In this case it means that "gettext" in Fedora Core Development was > upgraded in an incompatible way and provides a newer libgettextlib with a > new SONAME (on FC6 it is still "libgettextlib-0.14.6.so") and that > "blender" must be updated and compiled/linked with the upgraded > "gettext" and "gettext-devel" packages. So in fedora terms one only needs to bump the release and run another "make build" to fix this? Or does this need an upstream update as well? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Sun Nov 26 22:43:38 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 26 Nov 2006 16:43:38 -0600 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <200611262341.42841.opensource@till.name> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <20061126231718.d31a91b4.bugs.michael@gmx.net> <200611262341.42841.opensource@till.name> Message-ID: <200611261643.39355.dennis@ausil.us> On Sunday 26 November 2006 4:41 pm, Till Maas wrote: > On Sunday 26 November 2006 23:17, Michael Schwendt wrote: > > In this case it means that "gettext" in Fedora Core Development was > > upgraded in an incompatible way and provides a newer libgettextlib with a > > new SONAME (on FC6 it is still "libgettextlib-0.14.6.so") and that > > "blender" must be updated and compiled/linked with the upgraded > > "gettext" and "gettext-devel" packages. > > So in fedora terms one only needs to bump the release and run another "make > build" to fix this? Or does this need an upstream update as well? in theory all thats needed is the rebuild if gettext changed in a incompatible way then blander will need patching -- Dennis Gilmore, RHCE Proud Australian From vonbrand at inf.utfsm.cl Sun Nov 26 22:59:57 2006 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 26 Nov 2006 19:59:57 -0300 Subject: New Comps Groups In-Reply-To: Your message of "Sun, 26 Nov 2006 11:12:58 -0800." Message-ID: <200611262259.kAQMxvZc016153@laptop13.inf.utfsm.cl> Christopher Stone wrote: > On 11/26/06, Horst H. von Brand wrote: > > Wart wrote: > > > > [...] > > > > > If we're going to move to " Development" groups for > > > language-specific development modules, then I'd also like to ask for a > > > "Tcl Development" group for the 18+ Tcl modules in FE. > > What about Ruby, C++, ...? Tk (yes, that one is usable from a variety of > > languages)? The various RDBMses? This will give a huge list of new groups. > There already exists a group for Ruby, C++ libraries would just go in > the generalized "Development Libraries" group, and I proposed > combining Tcl with Tk. I'm not sure what you mean by the various > RDBMses, can you give an example? There are packages for working with MySQL, Postgres, ... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From chris.stone at gmail.com Sun Nov 26 23:10:26 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 26 Nov 2006 15:10:26 -0800 Subject: New Comps Groups In-Reply-To: <200611262259.kAQMxvZc016153@laptop13.inf.utfsm.cl> References: <200611262259.kAQMxvZc016153@laptop13.inf.utfsm.cl> Message-ID: On 11/26/06, Horst H. von Brand wrote: > Christopher Stone wrote: > > On 11/26/06, Horst H. von Brand wrote: > > > Wart wrote: > > > > > > [...] > > > > > > > If we're going to move to " Development" groups for > > > > language-specific development modules, then I'd also like to ask for a > > > > "Tcl Development" group for the 18+ Tcl modules in FE. > > > > What about Ruby, C++, ...? Tk (yes, that one is usable from a variety of > > > languages)? The various RDBMses? This will give a huge list of new groups. > > > There already exists a group for Ruby, C++ libraries would just go in > > the generalized "Development Libraries" group, and I proposed > > combining Tcl with Tk. I'm not sure what you mean by the various > > RDBMses, can you give an example? > > There are packages for working with MySQL, Postgres, ... heh, I didn't mean examples of databases, but example of packages that you are referring to. There already is a MySQL/Postgres group in the Servers section, so I need to make sure the packages you are referring to are not better suited to go there. From jkeating at redhat.com Sun Nov 26 23:12:03 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 26 Nov 2006 18:12:03 -0500 Subject: repoview for debuginfo packages? In-Reply-To: <200611261456.57308.opensource@till.name> References: <20061028031427.3ae5df5d.bugs.michael@gmx.net> <200611261456.57308.opensource@till.name> Message-ID: <200611261812.06700.jkeating@redhat.com> On Sunday 26 November 2006 08:56, Till Maas wrote: > Btw. Is there a reason why repoview is not used in Core? It was used for a short period of time, and near the FC6 release it broke, and I didn't take the time to fix it. I only got one report of it not working so I felt it wasn't all that well used. I decided to wait until we merge core/extras and then have it fixed there. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwizart at gmail.com Sun Nov 26 23:32:01 2006 From: kwizart at gmail.com (KH KH) Date: Mon, 27 Nov 2006 00:32:01 +0100 Subject: ipw2[12]00 firmware (was: Re: Atmel binary firmware) In-Reply-To: <45698505.2050103@leemhuis.info> References: <4568CB46.1050608@timj.co.uk> <45698505.2050103@leemhuis.info> Message-ID: 2006/11/26, Thorsten Leemhuis : > > Gianluca Sforna schrieb: > > So which of those points prevents us from having the wireless ipw > > firmwares in Extras? > > I asked a fedora licensing expert some weeks ago in private for his > opinion on moving my ipw2[12]00-firmware packages from another 3rd-party > repo to FE. I didn't get an answer yet. :-( > > If anyone wants to submit those firmware packages to Extras feel free to > take my packages up and submit them for FE-review. > > CU > thl > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > I have also used ipw2200-firmware scheme to make an ipw2200-ap-fw But i didn't riched to build the kmod yet for ipw2200-ap witch should allow master mode on centrino! but this is far from been integrated on extras for now... I have also build zd1211-firmware which driver (zd1211rw and zd1211) are included in linux. Users seem to report firmware errors when they do not have this firmware (which is normal!). But I do not have much feedback when providing this solution...users don't came back like if it naturally work. I connot test it myself so, you can pick it here: http://kwizart.free.fr/fedora/6/i386/zd1211-firmware-1.2-1.kwizart.fc6.noarch.rpm Does this firmware can be allowed on FE ? I will submit it then! -------------- next part -------------- An HTML attachment was scrubbed... URL: From buildsys at fedoraproject.org Mon Nov 27 01:01:53 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 26 Nov 2006 20:01:53 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-26 Message-ID: <20061127010153.BA33815212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 34 SDL_image-1.2.5-3.fc7 arrows-0.6-2.fc7 atomorun-1.1-0.2.pre2.fc7 audacious-1.2.1-1.fc7 audacious-plugins-1.2.2-1.fc7 buoh-0.8.2-2 eterm-0.9.4-4.fc7 gaim-meanwhile-2.0.0-0.5.beta5.fc7 grhino-0.16.0-1.fc7 jd-1.8.1-0.1.cvs061126.fc7 libmpd-0.12.0-3.fc7 libtcd-2.2-1.fc7 libtorrent-0.10.4-1.fc7 mlmmj-1.2.12-1.fc7 mod_cband-0.9.7.5-1.fc7 ochusha-0.5.99.63.6-0.1.cvs061126.fc7 pcsc-tools-1.4.8-1.fc7 perl-Email-Address-1.883-1.fc7 perl-Email-MIME-ContentType-1.012-1.fc7 perl-Log-Dispatch-2.14-2.fc7 perl-Log-Dispatch-FileRotate-1.16-1.fc7 perl-Log-Log4perl-1.08-1.fc7 python-alsaaudio-0.2-1.fc7 python-vobject-0.4.4-1.fc7 quarry-0.2.0-1.fc7 rtorrent-0.6.4-2.fc7 tcd-utils-20061120-1.fc7 tclchecker-1.4-1.20061030cvs.fc7 tcldebugger-1.4-1.20061030cvs.fc7 tclparser-1.4-1.20061030cvs.fc7 tclpro-1.5.0-6.20061030cvs.fc7 testdisk-6.5-2.fc7 xfce4-notes-plugin-1.4-1.fc7 xtide-2.9-0.2.date20061122.fc7 Packages built and released for Fedora Extras 6: 19 SDL_image-1.2.5-3.fc6 buoh-0.8.2-2.fc6 codeblocks-1.0-0.15.20061125svn3268.fc6 gaim-meanwhile-2.0.0-0.5.beta5.fc6 grhino-0.16.0-1.fc6 libtorrent-0.10.4-1.fc6 liferea-1.0.26-1.fc6 mlmmj-1.2.12-1.fc6 mod_cband-0.9.7.5-1.fc6 pcsc-tools-1.4.8-1.fc6 perl-Email-Address-1.883-1.fc6 perl-Email-MIME-ContentType-1.012-1.fc6 perl-Log-Dispatch-FileRotate-1.16-1.fc6 perl-Log-Log4perl-1.08-1.fc6 python-vobject-0.4.4-1.fc6 quarry-0.2.0-1.fc6 rtorrent-0.6.4-2.fc6 testdisk-6.5-2.fc6 xfce4-notes-plugin-1.4-1.fc6 Packages built and released for Fedora Extras 5: 11 codeblocks-1.0-0.15.20061125svn3268.fc5 grhino-0.16.0-1.fc5 mlmmj-1.2.12-1.fc5 mlton-20061107-2.fc5 mod_cband-0.9.7.5-1.fc5 perl-Email-Address-1.883-1.fc5 perl-Email-MIME-ContentType-1.012-1.fc5 perl-Log-Dispatch-FileRotate-1.16-1.fc5 perl-Log-Log4perl-1.08-1.fc5 quarry-0.2.0-1.fc5 testdisk-6.5-2.fc5 Packages built and released for Fedora Extras 4: 3 mod_cband-0.9.7.5-1.fc4 perl-Log-Dispatch-FileRotate-1.16-1.fc4 perl-Log-Log4perl-1.08-1.fc4 Packages built and released for Fedora Extras 3: 0 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon Nov 27 02:11:48 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 27 Nov 2006 02:11:48 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-26 Message-ID: <20061127021148.17606.50945@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- Jochen AT herr-schmitt.de blender - 2.42a-5.fc7.i386 (3 days) blender - 2.42a-5.fc7.ppc (3 days) blender - 2.42a-5.fc7.x86_64 (3 days) andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 (26 days) centericq - 4.21.0-8.fc6.ppc (26 days) centericq - 4.21.0-8.fc6.x86_64 (26 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (29 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (29 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (29 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (29 days) orange - 0.3-3.cvs20051118.fc6.i386 (33 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (57 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (57 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (57 days) braden AT endoframe.com openvrml - 0.16.1-4.fc7.i386 (3 days) openvrml - 0.16.1-4.fc7.i386 (3 days) openvrml - 0.16.1-4.fc7.ppc (3 days) openvrml - 0.16.1-4.fc7.x86_64 (3 days) openvrml-devel - 0.16.1-4.fc7.i386 (3 days) openvrml-devel - 0.16.1-4.fc7.i386 (3 days) openvrml-devel - 0.16.1-4.fc7.ppc (3 days) openvrml-devel - 0.16.1-4.fc7.x86_64 (3 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (72 days) plague - 0.4.4.1-2.fc3.noarch (72 days) plague - 0.4.4.1-2.fc4.noarch (72 days) plague - 0.4.4.1-2.fc4.noarch (72 days) plague - 0.4.4.1-2.fc4.noarch (72 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (48 days) linphone - 1.2.0-4.fc5.ppc (48 days) linphone - 1.2.0-4.fc5.x86_64 (48 days) karlthered AT gmail.com gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.i386 (4 days) gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.i386 (4 days) gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.ppc (4 days) gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.x86_64 (4 days) matthias AT rpmforge.net php-eaccelerator - 5.1.6_0.9.5-2.fc7.i386 (10 days) php-eaccelerator - 5.1.6_0.9.5-2.fc7.ppc (10 days) php-eaccelerator - 5.1.6_0.9.5-2.fc7.x86_64 (10 days) oliver AT linux-kernel.at syck-php - 0.55-10.fc6.i386 (10 days) syck-php - 0.55-10.fc6.ppc (10 days) syck-php - 0.55-10.fc6.x86_64 (10 days) syck-php - 0.55-9.fc5.i386 (38 days) syck-php - 0.55-9.fc5.ppc (38 days) syck-php - 0.55-9.fc5.x86_64 (38 days) pertusus AT free.fr grads - 1.9b4-19.fc7.i386 (10 days) grads - 1.9b4-19.fc7.ppc (10 days) grads - 1.9b4-19.fc7.x86_64 (10 days) petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 (23 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (23 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (23 days) ghc642-gtk2hs - 0.9.10-4.fc6.i386 (23 days) ghc642-gtk2hs - 0.9.10-4.fc6.ppc (23 days) ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 (23 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 (23 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc (23 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 (23 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (28 days) tcallawa AT redhat.com gambas-runtime - 1.0.17-6.fc7.i386 (3 days) gambas-runtime - 1.0.17-6.fc7.ppc (3 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- blender-2.42a-5.fc7.ppc requires libgettextlib-0.15.so centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 gambas-runtime-1.0.17-6.fc7.ppc requires libgettextlib-0.15.so ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 grads-1.9b4-19.fc7.ppc requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.ppc requires gecko-libs = 0:2.0 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 openvrml-0.16.1-4.fc7.ppc requires firefox = 0:1.5.0.8 openvrml-devel-0.16.1-4.fc7.ppc requires firefox-devel = 0:1.5.0.8 php-eaccelerator-5.1.6_0.9.5-2.fc7.ppc requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.ppc requires php = 0:5.1.6 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- blender-2.42a-5.fc7.x86_64 requires libgettextlib-0.15.so()(64bit) centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 grads-1.9b4-19.fc7.x86_64 requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.i386 requires gecko-libs = 0:2.0 gtkmozembedmm-1.4.2.cvs20060817-5.fc7.x86_64 requires gecko-libs = 0:2.0 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) openvrml-0.16.1-4.fc7.i386 requires firefox = 0:1.5.0.8 openvrml-0.16.1-4.fc7.x86_64 requires firefox = 0:1.5.0.8 openvrml-devel-0.16.1-4.fc7.i386 requires firefox-devel = 0:1.5.0.8 openvrml-devel-0.16.1-4.fc7.x86_64 requires firefox-devel = 0:1.5.0.8 orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 php-eaccelerator-5.1.6_0.9.5-2.fc7.x86_64 requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.x86_64 requires php = 0:5.1.6 Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- blender-2.42a-5.fc7.i386 requires libgettextlib-0.15.so centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 gambas-runtime-1.0.17-6.fc7.i386 requires libgettextlib-0.15.so ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 grads-1.9b4-19.fc7.i386 requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.i386 requires gecko-libs = 0:2.0 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 openvrml-0.16.1-4.fc7.i386 requires firefox = 0:1.5.0.8 openvrml-devel-0.16.1-4.fc7.i386 requires firefox-devel = 0:1.5.0.8 php-eaccelerator-5.1.6_0.9.5-2.fc7.i386 requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.i386 requires php = 0:5.1.6 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: rdieter AT math.unl.edu package: gift - 0.11.8.1-6.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libmagic.so.1 From rc040203 at freenet.de Mon Nov 27 04:47:54 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 27 Nov 2006 05:47:54 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: <45698BDD.1090106@leemhuis.info> References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611250457.16799.alain.portal@free.fr> <20061125160642.72184410.bugs.michael@gmx.net> <20061125162826.c1418048.bugs.michael@gmx.net> <20061125172206.633586a4.bugs.michael@gmx.net> <4568727F.5080306@leemhuis.info> <1164519346.29498.4.camel@mccallum.corsepiu.local> <45698BDD.1090106@leemhuis.info> Message-ID: <1164602874.29498.27.camel@mccallum.corsepiu.local> On Sun, 2006-11-26 at 13:43 +0100, Thorsten Leemhuis wrote: > Ralf Corsepius schrieb: > > On Sat, 2006-11-25 at 17:42 +0100, Thorsten Leemhuis wrote: > >> Michael Schwendt schrieb: > >>> On Sat, 25 Nov 2006 07:48:31 -0800, Christopher Stone wrote: > >>> [...] > >>>> There needs to be a way to > >>>> blacklist these packages from showing up in the report or else send > >>>> them to another interested party such as fedora-legacy > >>> I've suggested a black-list several times before without clear > >>> feedback. Black-listing packages is like hiding something under the > >>> carpet. > >> Agreed, until now I don't see any good reason for a blacklist. > > How about FESCO implementing some rules on "taking consequences" from > > EVR issues in FE not being taken care about? > > Sounds like a good idea -- but you don't have to wait for FESCo -- the > Committee has a lot of stuff to do already and the members to the work > in their spare time, too. > > Someone inside or outside of FESCo that cares about this particular > problem could just work out a detailed plan what to do. Then FESCo will > probably simply ACK it and say "thanks for your help. > > > E.g. "broken deps > 4weeks", and the package will be automatically > > orphaned plus the maintainer's account will be withdrawn/canceled? > > I agree with Gianluca: That's a bit overkill. Why would that be overkill? Broken EVRs break upgrades. Something I consider to be "serious packaging bugs". I consider maintainers not being able to address a severe issue within "a reasonable timeframe" as "these persons not doing there job". I don't see what would be wrong in confronting them with sanctions. Mistakes happens, oversights happen, but not at least _trying_ to address them without any doubt is beyond reason and let's appear these folks in a "special light". > But yes, something in that direction. Ralf From jurgen at botz.org Mon Nov 27 09:25:44 2006 From: jurgen at botz.org (Juergen Botz) Date: Mon, 27 Nov 2006 06:25:44 -0300 Subject: fuse-encfs broken with new fuse Message-ID: With the update to fuse-2.6.0-2.fc6 fuse-encfs appears to be broken. Can anyone else confirm this? :j From adellam at sevenseas.org Mon Nov 27 10:14:43 2006 From: adellam at sevenseas.org (Andrea Dell'Amico) Date: Mon, 27 Nov 2006 11:14:43 +0100 Subject: fuse-encfs broken with new fuse In-Reply-To: References: Message-ID: <1164622483.3120.1.camel@altrove.nowhere.net> On Mon, 2006-11-27 at 06:25 -0300, Juergen Botz wrote: > With the update to fuse-2.6.0-2.fc6 fuse-encfs appears to be > broken. Can anyone else confirm this? Yes, I just opened bug #217343: > > :j > ciao ad -- "Thinking meat! You're asking me to believe in thinking meat!" - Terry Bisson From jamatos at fc.up.pt Mon Nov 27 11:25:48 2006 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Mon, 27 Nov 2006 11:25:48 +0000 Subject: New Comps Groups In-Reply-To: References: Message-ID: <200611271125.48568.jamatos@fc.up.pt> On Sunday 26 November 2006 1:07 pm, Christopher Stone wrote: > I plan on adding a couple new groups to comps under the main > "Development" group. I am going to add "PHP Development", "Python > Development", and "Perl Development" where all the php, python, and > perl modules can go. > > This is basically part of the movement to add *everything* to comps. > Normal C libraries will go under the already existing "Development > Libraries" group. Can I ask for R development? :-) > If you disagree with this move, scream bloody murder now. :) -- Jos? Ab?lio From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Nov 27 12:06:20 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 27 Nov 2006 13:06:20 +0100 Subject: ipw2[12]00 firmware (was: Re: Atmel binary firmware) In-Reply-To: <45698505.2050103@leemhuis.info> References: <4568CB46.1050608@timj.co.uk> <45698505.2050103@leemhuis.info> Message-ID: <20061127130620.6846e94c@python3.es.egwn.lan> Thorsten Leemhuis wrote : > Gianluca Sforna schrieb: > > So which of those points prevents us from having the wireless ipw > > firmwares in Extras? > > I asked a fedora licensing expert some weeks ago in private for his > opinion on moving my ipw2[12]00-firmware packages from another 3rd-party > repo to FE. I didn't get an answer yet. :-( > > If anyone wants to submit those firmware packages to Extras feel free to > take my packages up and submit them for FE-review. Yeah, these seem to meet the requirements to get into Extras and have been waiting too long already. Submitted here : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217350 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217351 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.18-1.2849.fc6 Load : 0.31 0.48 0.46 From dominik at greysector.net Mon Nov 27 12:36:08 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 27 Nov 2006 13:36:08 +0100 Subject: ipw2[12]00 firmware (was: Re: Atmel binary firmware) In-Reply-To: <20061127130620.6846e94c@python3.es.egwn.lan> References: <4568CB46.1050608@timj.co.uk> <45698505.2050103@leemhuis.info> <20061127130620.6846e94c@python3.es.egwn.lan> Message-ID: <20061127123608.GD4522@rathann.pekin.waw.pl> On Monday, 27 November 2006 at 13:06, Matthias Saou wrote: > Thorsten Leemhuis wrote : > > > Gianluca Sforna schrieb: > > > So which of those points prevents us from having the wireless ipw > > > firmwares in Extras? > > > > I asked a fedora licensing expert some weeks ago in private for his > > opinion on moving my ipw2[12]00-firmware packages from another 3rd-party > > repo to FE. I didn't get an answer yet. :-( > > > > If anyone wants to submit those firmware packages to Extras feel free to > > take my packages up and submit them for FE-review. > > Yeah, these seem to meet the requirements to get into Extras and have > been waiting too long already. Submitted here : > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217350 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217351 Looks that way. I'll take those. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From mattdm at mattdm.org Mon Nov 27 13:37:29 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 27 Nov 2006 08:37:29 -0500 Subject: New Comps Groups In-Reply-To: <200611271125.48568.jamatos@fc.up.pt> References: <200611271125.48568.jamatos@fc.up.pt> Message-ID: <20061127133729.GA28307@jadzia.bu.edu> On Mon, Nov 27, 2006 at 11:25:48AM +0000, Jos? Matos wrote: > Can I ask for R development? :-) Shouldn't this go in "Math and Statistics" or somesuch? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From bugs.michael at gmx.net Mon Nov 27 13:58:24 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 27 Nov 2006 14:58:24 +0100 Subject: rpms/GraphicsMagick/devel GraphicsMagick-gslib.patch, NONE, 1.1 GraphicsMagick.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <200611271338.kARDcB8x009924@cvs-int.fedora.redhat.com> References: <200611271338.kARDcB8x009924@cvs-int.fedora.redhat.com> Message-ID: <20061127145824.360e0331.bugs.michael@gmx.net> On Mon, 27 Nov 2006 08:38:11 -0500, Andreas Thienemann (ixs) wrote: > Author: ixs > > Update of /cvs/extras/rpms/GraphicsMagick/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv9887/devel > > Modified Files: > .cvsignore sources > Added Files: > GraphicsMagick-gslib.patch GraphicsMagick.spec > Log Message: > auto-import GraphicsMagick-1.1.7-2 on branch devel from GraphicsMagick-1.1.7-2.src.rpm > %package perl > Summary: GraphicsMagick perl bindings > Group: System Environment/Libraries > Requires: %{name} = %{version}-%{release} > Requires: perl >= 5.6.0 > %define perl_vendorarch %(perl -MConfig -le 'print $Config{installvendorarch}') > BuildRequires: %{perl_vendorarch} Where's...? Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) You BR a directory and install into it, but an insufficient version of Perl may not have that directory in its search path. From laurent.rineau__fedora_extras at normalesup.org Mon Nov 27 16:07:02 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Mon, 27 Nov 2006 17:07:02 +0100 Subject: Unorphaning wbxml2 Message-ID: <200611271707.02208@rineau.schtroumpfette> I am taking the ownership of *wbxml2*, which is a retired package (because its maintainer could not sign the Fedora CLA due to its company policy). wbxml2 is a requirement of libsyncml, which I would like to get into Fedora Extras as well. Actually, I failed to detect that wbxml2 was orphaned. I thought it was not in Fedora Extras at all. I have submitted a Review Request, which is already accepted. See: https://bugzilla.redhat.com/217180 I will merge the previous changelog into my spec file before submitting it. -- Laurent Rineau From notting at redhat.com Mon Nov 27 16:54:31 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 11:54:31 -0500 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611250457.16799.alain.portal@free.fr> <20061125160642.72184410.bugs.michael@gmx.net> <456865A4.2000603@leemhuis.info> <20061126004751.ead52491.bugs.michael@gmx.net> <45698A3F.2000708@leemhuis.info> Message-ID: <20061127165431.GH29814@nostromo.devel.redhat.com> Christopher Stone (chris.stone at gmail.com) said: > IIRC, tibbs did this a few months ago on a package that was in the > report for months and after he launched a rebuild the maintainer came > on this message list and lambasted tibbs for launching a rebuild. > tibbs then got upset and said he would never attempt to help out in > this regard again. > > I think there was some technical reason why the rebuild should not > have been done, so there needs to be a way for a developer to say, I > cannot fix this dependency problem because of some other issue, and > request QA SIGs to not push rebuilds. Sure, but without such a thing, just fix the damn problem. Bill From gemi at bluewin.ch Mon Nov 27 16:56:19 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 27 Nov 2006 17:56:19 +0100 Subject: .h files in non-devel package? Message-ID: <1164646579.5460.3.camel@scriabin.tannenrauch.ch> Is it absolutely necessary, that .h files go into a -devel package? I have a package stklos, which is a scheme interpreter, that does not contain any shared (or static) libraries, but some header files in /usr/share/stklos which are necessary if an extension is to be installed. I believe that it is confusing to split the header files off into an stklos-devel package, since stklos is a development package itself and not a library. We used this approach before for Scheme and Lisp packages. However the reviewers of my package do not agree with me. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From notting at redhat.com Mon Nov 27 16:56:08 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 11:56:08 -0500 Subject: Adding (parts of) gstreamer-plugins-bad to FE? In-Reply-To: <456850B2.2050402@hhs.nl> References: <456850B2.2050402@hhs.nl> Message-ID: <20061127165608.GI29814@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > qt > Quicktime container format support, through own gst code (no libs used), > this one is trouble some. I would really like to see this in FE as this > adds supports for videos made with many digital photo cameras to > gstreamer using applications (usually these camera's just dump a raw > audio stream and a serie of jpeg images into a .mov file. > > So where should this one go? I really don't know. Can anyone help here? I'm not 100% sure, but I believe the quicktime *container* format is open; it's just that most of the things put in it usually aren't. Bill From notting at redhat.com Mon Nov 27 16:58:31 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 11:58:31 -0500 Subject: Atmel binary firmware In-Reply-To: <456976FD.20107@feuerpokemon.de> References: <4568CB46.1050608@timj.co.uk> <45697663.5040200@volny.cz> <456976FD.20107@feuerpokemon.de> Message-ID: <20061127165831.GK29814@nostromo.devel.redhat.com> dragoran (dragoran at feuerpokemon.de) said: > http://bughost.org/ipw3945/LICENSE > seems like we only need to ship this file No, we need the prior firmware released with *that* license, instead of the one currently on it... Bill From notting at redhat.com Mon Nov 27 16:59:25 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 11:59:25 -0500 Subject: ipw2[12]00 firmware (was: Re: Atmel binary firmware) In-Reply-To: <45698505.2050103@leemhuis.info> References: <4568CB46.1050608@timj.co.uk> <45698505.2050103@leemhuis.info> Message-ID: <20061127165925.GL29814@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > Gianluca Sforna schrieb: > > So which of those points prevents us from having the wireless ipw > > firmwares in Extras? > > I asked a fedora licensing expert some weeks ago in private for his > opinion on moving my ipw2[12]00-firmware packages from another 3rd-party > repo to FE. I didn't get an answer yet. :-( > > If anyone wants to submit those firmware packages to Extras feel free to > take my packages up and submit them for FE-review. The issue is redistribution, as stated above - they need released with a separate license/clarification. Bill From notting at redhat.com Mon Nov 27 17:02:20 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 12:02:20 -0500 Subject: New Comps Groups In-Reply-To: References: Message-ID: <20061127170220.GM29814@nostromo.devel.redhat.com> Christopher Stone (chris.stone at gmail.com) said: > I plan on adding a couple new groups to comps under the main > "Development" group. I am going to add "PHP Development", "Python > Development", and "Perl Development" where all the php, python, and > perl modules can go. > > This is basically part of the movement to add *everything* to comps. Why, out of curiosity? In what cases are these something that a user wants to explicitly wade through 100 listings for? Bill From rc040203 at freenet.de Mon Nov 27 17:08:36 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 27 Nov 2006 18:08:36 +0100 Subject: .h files in non-devel package? In-Reply-To: <1164646579.5460.3.camel@scriabin.tannenrauch.ch> References: <1164646579.5460.3.camel@scriabin.tannenrauch.ch> Message-ID: <1164647316.6317.122.camel@mccallum.corsepiu.local> On Mon, 2006-11-27 at 17:56 +0100, G?rard Milmeister wrote: > Is it absolutely necessary, that .h files go into a -devel package? I > have a package stklos, which is a scheme interpreter, that does not > contain any shared (or static) libraries, but some header files > in /usr/share/stklos which are necessary if an extension is to be > installed. I believe that it is confusing to split the header files off > into an stklos-devel package, since stklos is a development package > itself and not a library. Why didn't you say so before? ;) In general, *.h files belong into "development packages" containing the libraries they specify the API of. The actual name of this package is secondary. I'd recommend to use "*-devel" if it's really a mere devel package, not containing any apps, to prevent future conflicts should a package be added applications in futures. If you really want to name the package "" only, then I'd recommend to at least add "Provides: %{name}-devel = %{version}-%{release}" to cater users expecting development files in "*-devel" packages. > However the reviewers of my package do not agree with me. ;) Ralf From opensource at till.name Mon Nov 27 17:15:56 2006 From: opensource at till.name (Till Maas) Date: Mon, 27 Nov 2006 18:15:56 +0100 Subject: fuse-encfs broken with new fuse In-Reply-To: References: Message-ID: <200611271816.17398.opensource@till.name> On Monday 27 November 2006 10:25, Juergen Botz wrote: > With the update to fuse-2.6.0-2.fc6 fuse-encfs appears to be > broken. Can anyone else confirm this? sshfs does not work, here, too. Did not look further into it, though. Regards, Till From mr.ecik at gmail.com Mon Nov 27 17:18:52 2006 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Mon, 27 Nov 2006 18:18:52 +0100 Subject: .h files in non-devel package? In-Reply-To: <1164647316.6317.122.camel@mccallum.corsepiu.local> References: <1164646579.5460.3.camel@scriabin.tannenrauch.ch> <1164647316.6317.122.camel@mccallum.corsepiu.local> Message-ID: <668bb39a0611270918q7bf8688dm7b6839397bfd988b@mail.gmail.com> 2006/11/27, Ralf Corsepius : > If you really want to name the package "" only, then I'd recommend > to at least add "Provides: %{name}-devel = %{version}-%{release}" to > cater users expecting development files in "*-devel" packages. In my opinion it's not a good solution. ReviewGuidelines says that: "The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb." - it concerns .pc files but I think that solution should be applied in all packages which are only development packages. Thus G?rard is right, -devel subpackage is not needed. Regards. Micha?. From tibbs at math.uh.edu Mon Nov 27 17:55:08 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 Nov 2006 11:55:08 -0600 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-24 In-Reply-To: References: <20061125001903.19894.81471@extras64.linux.duke.edu> <200611250457.16799.alain.portal@free.fr> <20061125160642.72184410.bugs.michael@gmx.net> <456865A4.2000603@leemhuis.info> <20061126004751.ead52491.bugs.michael@gmx.net> <45698A3F.2000708@leemhuis.info> Message-ID: >>>>> "CS" == Christopher Stone writes: CS> IIRC, tibbs did this a few months ago on a package that was in the CS> report for months and after he launched a rebuild the maintainer CS> came on this message list and lambasted tibbs for launching a CS> rebuild. Note that it wasn't just the maintainer; I recall that others also joined in the flaming, saying that we need maintainers instead of people who just rebuild packages. Yes, I did just a rebuild, because I thought it would fix the problem. When I saw that it didn't (because the issue ended up being more complicated in that it only appeared on one arch I did not initially test with) I fixed the problem appropriately. Sadly, the flamers simply couldn't wait to jump in. I think this is the case far too often. - J< From chris.stone at gmail.com Mon Nov 27 18:16:18 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 27 Nov 2006 10:16:18 -0800 Subject: New Comps Groups In-Reply-To: <20061127170220.GM29814@nostromo.devel.redhat.com> References: <20061127170220.GM29814@nostromo.devel.redhat.com> Message-ID: On 11/27/06, Bill Nottingham wrote: > Christopher Stone (chris.stone at gmail.com) said: > > I plan on adding a couple new groups to comps under the main > > "Development" group. I am going to add "PHP Development", "Python > > Development", and "Perl Development" where all the php, python, and > > perl modules can go. > > > > This is basically part of the movement to add *everything* to comps. > > Why, out of curiosity? In what cases are these something that a user > wants to explicitly wade through 100 listings for? I do not understand this question? Is it somehow better to wade through 1000s of packages to find something instead? Please rephrase your question to be more specific. From notting at redhat.com Mon Nov 27 18:24:08 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 13:24:08 -0500 Subject: New Comps Groups In-Reply-To: References: <20061127170220.GM29814@nostromo.devel.redhat.com> Message-ID: <20061127182408.GC32187@nostromo.devel.redhat.com> Christopher Stone (chris.stone at gmail.com) said: > >Why, out of curiosity? In what cases are these something that a user > >wants to explicitly wade through 100 listings for? > > I do not understand this question? Is it somehow better to wade > through 1000s of packages to find something instead? Please rephrase > your question to be more specific. We already have a 'package search' interface for finding packages - is listing 100 (or however many) python-* packages better than this? In what way? Are they not getting pulled in for dependencies when necessary? Basically, what's the use case for when a user would want to scroll through all of python-* or perl-* looking for a package? Bill From j.w.r.degoede at hhs.nl Mon Nov 27 18:58:48 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 27 Nov 2006 19:58:48 +0100 Subject: Adding (parts of) gstreamer-plugins-bad to FE? In-Reply-To: <20061127165608.GI29814@nostromo.devel.redhat.com> References: <456850B2.2050402@hhs.nl> <20061127165608.GI29814@nostromo.devel.redhat.com> Message-ID: <456B3568.7020903@hhs.nl> Bill Nottingham wrote: > Hans de Goede (j.w.r.degoede at hhs.nl) said: >> qt >> Quicktime container format support, through own gst code (no libs used), >> this one is trouble some. I would really like to see this in FE as this >> adds supports for videos made with many digital photo cameras to >> gstreamer using applications (usually these camera's just dump a raw >> audio stream and a serie of jpeg images into a .mov file. >> >> So where should this one go? I really don't know. Can anyone help here? > > I'm not 100% sure, but I believe the quicktime *container* format is open; > it's just that most of the things put in it usually aren't. > So that makes 2 votes in favor of qt container support in FE, rest assured I'm only talking about *container* support here. Are there any nay-sayers? Should we pass this through legal first? (no please). Anyone who can give a definite YES? Regards, Hans From dominik at greysector.net Mon Nov 27 20:07:07 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 27 Nov 2006 21:07:07 +0100 Subject: .h files in non-devel package? In-Reply-To: <668bb39a0611270918q7bf8688dm7b6839397bfd988b@mail.gmail.com> References: <1164646579.5460.3.camel@scriabin.tannenrauch.ch> <1164647316.6317.122.camel@mccallum.corsepiu.local> <668bb39a0611270918q7bf8688dm7b6839397bfd988b@mail.gmail.com> Message-ID: <20061127200707.GA10795@rathann.pekin.waw.pl> On Monday, 27 November 2006 at 18:18, Micha? Bentkowski wrote: > 2006/11/27, Ralf Corsepius : > >If you really want to name the package "" only, then I'd recommend > >to at least add "Provides: %{name}-devel = %{version}-%{release}" to > >cater users expecting development files in "*-devel" packages. > > In my opinion it's not a good solution. ReviewGuidelines says that: > "The placement of pkgconfig(.pc) files depends on their usecase, and > this is usually for development purposes, so should be placed in a > -devel pkg. A reasonable exception is that the main pkg itself is a > devel tool not installed in a user runtime, e.g. gcc or gdb." - it > concerns .pc files but I think that solution should be applied in all > packages which are only development packages. > > Thus G?rard is right, -devel subpackage is not needed. Why not call the main package -devel and forget the whole issue? Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From bpepple at fedoraproject.org Mon Nov 27 20:33:31 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 27 Nov 2006 15:33:31 -0500 Subject: New Comps Groups In-Reply-To: <20061127182408.GC32187@nostromo.devel.redhat.com> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> Message-ID: <1164659611.2890.1.camel@Chuck> On Mon, 2006-11-27 at 13:24 -0500, Bill Nottingham wrote: > We already have a 'package search' interface for finding packages - is > listing 100 (or however many) python-* packages better than this? In > what way? Are they not getting pulled in for dependencies when necessary? I'm in agreement with Bill on this. Pretty much all the python-* packages should be pulled in as dependencies. Am I missing something here? /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 nicolas.mailhot at laposte.net Mon Nov 27 20:52:08 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 27 Nov 2006 21:52:08 +0100 Subject: New Comps Groups In-Reply-To: <1164659611.2890.1.camel@Chuck> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> Message-ID: <1164660729.3195.8.camel@rousalka.dyndns.org> Le lundi 27 novembre 2006 ? 15:33 -0500, Brian Pepple a ?crit : > On Mon, 2006-11-27 at 13:24 -0500, Bill Nottingham wrote: > > We already have a 'package search' interface for finding packages - is > > listing 100 (or however many) python-* packages better than this? In > > what way? Are they not getting pulled in for dependencies when necessary? > > I'm in agreement with Bill on this. Pretty much all the python-* > packages should be pulled in as dependencies. Am I missing something > here? It's pretty much impossible to autodetect missing comps entries unless every package is systematically put in comps. No autochecking means low QA. Also if a group is too big it should be broken up in lighter finer-grained ones IMHO. Choosing the right group is much less work than writing the package description, and often more useful for users. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From katzj at redhat.com Mon Nov 27 20:55:29 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 27 Nov 2006 15:55:29 -0500 Subject: New Comps Groups In-Reply-To: References: Message-ID: <1164660930.22125.103.camel@aglarond.local> On Sun, 2006-11-26 at 05:07 -0800, Christopher Stone wrote: > I plan on adding a couple new groups to comps under the main > "Development" group. I am going to add "PHP Development", "Python > Development", and "Perl Development" where all the php, python, and > perl modules can go. > > This is basically part of the movement to add *everything* to comps. > Normal C libraries will go under the already existing "Development > Libraries" group. > > If you disagree with this move, scream bloody murder now. :) The question is "what makes these interesting things for a _user_ to select"? Realistically, the fact that "development" stuff is implemented as groups is a hack. Really, you want to say "I'm interested in doing software development" and then get a) a group of development tools and b) the devel bits for the software you have installed. Jeremy From notting at redhat.com Mon Nov 27 20:57:25 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 15:57:25 -0500 Subject: New Comps Groups In-Reply-To: <1164660729.3195.8.camel@rousalka.dyndns.org> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> Message-ID: <20061127205725.GA24223@nostromo.devel.redhat.com> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > > I'm in agreement with Bill on this. Pretty much all the python-* > > packages should be pulled in as dependencies. Am I missing something > > here? > > It's pretty much impossible to autodetect missing comps entries unless > every package is systematically put in comps. No autochecking means low > QA. What constitutes 'missing'? Just something that should be selectable but isn't there? I would hope that those sorts of things would become apparent. Bill From katzj at redhat.com Mon Nov 27 20:58:51 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 27 Nov 2006 15:58:51 -0500 Subject: New Comps Groups In-Reply-To: <1164660729.3195.8.camel@rousalka.dyndns.org> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> Message-ID: <1164661131.22125.106.camel@aglarond.local> On Mon, 2006-11-27 at 21:52 +0100, Nicolas Mailhot wrote: > Le lundi 27 novembre 2006 ? 15:33 -0500, Brian Pepple a ?crit : > > On Mon, 2006-11-27 at 13:24 -0500, Bill Nottingham wrote: > > > We already have a 'package search' interface for finding packages - is > > > listing 100 (or however many) python-* packages better than this? In > > > what way? Are they not getting pulled in for dependencies when necessary? > > > > I'm in agreement with Bill on this. Pretty much all the python-* > > packages should be pulled in as dependencies. Am I missing something > > here? > > It's pretty much impossible to autodetect missing comps entries unless > every package is systematically put in comps. No autochecking means low > QA. But the entire point is that everything _SHOULDN'T_ be there. If so, then it's no better than a list[1] > Also if a group is too big it should be broken up in lighter > finer-grained ones IMHO. Choosing the right group is much less work than > writing the package description, and often more useful for users. And when a user now has to go through 100 groups to find the one they want? Jeremy [1] Grouping is somewhat arbitrary by nature and different people will have different ideas on how packages should be grouped. By your argument, I could just as well make the categories letters of the alphabet and group based on the first letter of the package name. But that *doesn't* provide anything useful for users. From mattdm at mattdm.org Mon Nov 27 21:43:07 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 27 Nov 2006 16:43:07 -0500 Subject: uml generating tool In-Reply-To: <20061126173347.12546.qmail@web36807.mail.mud.yahoo.com> References: <20061126173347.12546.qmail@web36807.mail.mud.yahoo.com> Message-ID: <20061127214307.GA22484@jadzia.bu.edu> On Sun, Nov 26, 2006 at 09:33:47AM -0800, Amit Dey wrote: > How about if I make something for GNOME. Would that be useful ? Or is > there a similar application for GNOME too ( God...i wish you say no ). Rather than hoping for a "no", if the answer is "yes", and it's something you're interested in, why not look at what exists and try to improve it? To answer the question, I don't think there's such a thing in Fedora right now, but a quick search reveals a couple of candidates: Gaphor, a python-based GTK+ app: Jupe, an Eclipse plugin: -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sundaram at fedoraproject.org Mon Nov 27 21:55:51 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 28 Nov 2006 03:25:51 +0530 Subject: lbreakout in fedora extras? In-Reply-To: <4568AEDE.1040703@hhs.nl> References: <4568AEDE.1040703@hhs.nl> Message-ID: <456B5EE7.9050302@fedoraproject.org> Hans de Goede wrote: > Hi all, > > I'm concidering packaging lbreakout for FE, but I think the name is a > problem, so some days ago I send a kind request to upstream to change > the name, of which I'll reproduce a part here as it decribes the issue > at hand: > > "There currently is one problem with lbreakout (and other lgames) at the > moment though, their names. We at Fedora try to be very carefully to > make a 100% Free distro which isn't "tainted" in anyway. Sticking to > lbreakout as example, the original breakout game is copyrighted by Atari > which still exists, and breakout clearly qualifies as a trademark. If > I'm to believe Atari's website its even a registered trademark, see: > http://www.atari.com/us/games/atari_anniversary/pc > > And look at the "Breakout?" text." > > Thus I believe lbreakout cannot be included as is however Debian does > have it in main. My guess is Debian just overlooked this and this cannot > go into FE as is. Opinions anyone? > > Regards, > > Hans > > > p.s. > > Chances are high that if the concensus is this cannot go in as is I'll > do a rebranded version and package that. Have you tried contacting upstream and pointing out this potential trademark issue with them? A Fedora rebranded version will cause confusion similar to Firefox/Iceweasel. Rahul From overholt at redhat.com Mon Nov 27 21:58:21 2006 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 27 Nov 2006 16:58:21 -0500 Subject: uml generating tool In-Reply-To: <20061127214307.GA22484@jadzia.bu.edu> References: <20061126173347.12546.qmail@web36807.mail.mud.yahoo.com> <20061127214307.GA22484@jadzia.bu.edu> Message-ID: <1164664701.5407.25.camel@toxic.toronto.redhat.com> On Mon, 2006-27-11 at 16:43 -0500, Matthew Miller wrote: > Jupe, an Eclipse plugin: It looks like it requires GEF and UML2. GEF is already in Extras and I'm willing to bet that UML2 only required EMF -- which is also in Extras. Contact me if you want to go this route. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From chris.stone at gmail.com Mon Nov 27 21:52:06 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 27 Nov 2006 13:52:06 -0800 Subject: New Comps Groups In-Reply-To: <20061127182408.GC32187@nostromo.devel.redhat.com> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> Message-ID: On 11/27/06, Bill Nottingham wrote: > Christopher Stone (chris.stone at gmail.com) said: > > >Why, out of curiosity? In what cases are these something that a user > > >wants to explicitly wade through 100 listings for? > > > > I do not understand this question? Is it somehow better to wade > > through 1000s of packages to find something instead? Please rephrase > > your question to be more specific. > > We already have a 'package search' interface for finding packages - is > listing 100 (or however many) python-* packages better than this? In > what way? Are they not getting pulled in for dependencies when necessary? > > Basically, what's the use case for when a user would want to scroll through > all of python-* or perl-* looking for a package? When the user is a developer, and that developer want to see what python/perl modules are available to her. If you ask what good it provides, then I have to ask what harm would it cause? If there was a "Perl Develoment" group added to the Development comps category how would that make things more difficult for users? A user isn't going to be looking in the development part of comps unless she is a developer, or clicked there by accident. If it makes everyone happy, I can not add a perl or python development group, but I dont see any harm in doing so. From notting at redhat.com Mon Nov 27 22:10:01 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 17:10:01 -0500 Subject: New Comps Groups In-Reply-To: References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> Message-ID: <20061127221001.GA19234@nostromo.devel.redhat.com> Christopher Stone (chris.stone at gmail.com) said: > If you ask what good it provides, then I have to ask what harm would > it cause? That's not how good engineering is done, generally - it's based on 'Why?', not 'Why not?' Any bit of new code: 1) can add bugs 2) adds a maintenance load 3) adds complexity The idea is to figure out the scenarios and personas you're trying to design for, and then figure out how to meet those needs. How does a checkbox list of 589 packages (roughly the number of perl-* packages) make someone's life easier? Is this better done via searching for 'perl' in the package search interface, for example? Playing devil's advocate, if you go this way, wouldn't the better way be to automatically tag packages that install files in /usr/lib/python-2.4/site-packages as 'python modules', and generate the comps file from a database? Bill From chris.stone at gmail.com Mon Nov 27 22:19:55 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 27 Nov 2006 14:19:55 -0800 Subject: New Comps Groups In-Reply-To: <1164661131.22125.106.camel@aglarond.local> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <1164661131.22125.106.camel@aglarond.local> Message-ID: On 11/27/06, Jeremy Katz wrote: > On Mon, 2006-11-27 at 21:52 +0100, Nicolas Mailhot wrote: > > Le lundi 27 novembre 2006 ? 15:33 -0500, Brian Pepple a ?crit : > > > On Mon, 2006-11-27 at 13:24 -0500, Bill Nottingham wrote: > > > > We already have a 'package search' interface for finding packages - is > > > > listing 100 (or however many) python-* packages better than this? In > > > > what way? Are they not getting pulled in for dependencies when necessary? > > > > > > I'm in agreement with Bill on this. Pretty much all the python-* > > > packages should be pulled in as dependencies. Am I missing something > > > here? > > > > It's pretty much impossible to autodetect missing comps entries unless > > every package is systematically put in comps. No autochecking means low > > QA. > > But the entire point is that everything _SHOULDN'T_ be there. If so, > then it's no better than a list[1] How is adding a half dozen new groups to Development in comps going to reduce comps to be noting better than yum list '*'? > > > Also if a group is too big it should be broken up in lighter > > finer-grained ones IMHO. Choosing the right group is much less work than > > writing the package description, and often more useful for users. > > And when a user now has to go through 100 groups to find the one they > want? I have no plans to add 100 new groups. > > Jeremy > > [1] Grouping is somewhat arbitrary by nature and different people will > have different ideas on how packages should be grouped. By your > argument, I could just as well make the categories letters of the > alphabet and group based on the first letter of the package name. But > that *doesn't* provide anything useful for users. No one is suggesting to change comps to just have groups based on the alphabet. Yes, grouping by alphabet provides nothing useful, but that doesnt mean other grouping methods are not useful. By your argument, we should eliminate the concept of a group from human society all together because no one would be able to agree on any grouping. This ofcouse makes absolutely no sense. From chris.stone at gmail.com Mon Nov 27 22:27:16 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 27 Nov 2006 14:27:16 -0800 Subject: New Comps Groups In-Reply-To: <20061127221001.GA19234@nostromo.devel.redhat.com> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <20061127221001.GA19234@nostromo.devel.redhat.com> Message-ID: On 11/27/06, Bill Nottingham wrote: > Christopher Stone (chris.stone at gmail.com) said: > > If you ask what good it provides, then I have to ask what harm would > > it cause? > > That's not how good engineering is done, generally - it's based > on 'Why?', not 'Why not?' Any bit of new code: > > 1) can add bugs > 2) adds a maintenance load > 3) adds complexity > > The idea is to figure out the scenarios and personas you're trying > to design for, and then figure out how to meet those needs. > > How does a checkbox list of 589 packages (roughly the number of > perl-* packages) make someone's life easier? Is this better done > via searching for 'perl' in the package search interface, for example? I would say no. Take for example python packages. Some are called python-* some are called py* some are called Py* some are called *py, etc. > > Playing devil's advocate, if you go this way, wouldn't the better way be > to automatically tag packages that install files in > /usr/lib/python-2.4/site-packages as 'python modules', and generate the > comps file from a database? Yea, if you can autogenerate comps files that would be great! From nicolas.mailhot at laposte.net Mon Nov 27 22:43:10 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 27 Nov 2006 23:43:10 +0100 Subject: New Comps Groups In-Reply-To: <20061127205725.GA24223@nostromo.devel.redhat.com> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <20061127205725.GA24223@nostromo.devel.redhat.com> Message-ID: <1164667391.3195.10.camel@rousalka.dyndns.org> Le lundi 27 novembre 2006 ? 15:57 -0500, Bill Nottingham a ?crit : > Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > > > I'm in agreement with Bill on this. Pretty much all the python-* > > > packages should be pulled in as dependencies. Am I missing something > > > here? > > > > It's pretty much impossible to autodetect missing comps entries unless > > every package is systematically put in comps. No autochecking means low > > QA. > > What constitutes 'missing'? Just something that should be selectable but > isn't there? I would hope that those sorts of things would become apparent. A new package which has not been classified at all (ie the contributor "forgot" to think about comps at all) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Mon Nov 27 22:45:58 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 27 Nov 2006 23:45:58 +0100 Subject: New Comps Groups In-Reply-To: <1164661131.22125.106.camel@aglarond.local> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <1164661131.22125.106.camel@aglarond.local> Message-ID: <1164667559.3195.14.camel@rousalka.dyndns.org> Le lundi 27 novembre 2006 ? 15:58 -0500, Jeremy Katz a ?crit : > On Mon, 2006-11-27 at 21:52 +0100, Nicolas Mailhot wrote: > > Le lundi 27 novembre 2006 ? 15:33 -0500, Brian Pepple a ?crit : > > > On Mon, 2006-11-27 at 13:24 -0500, Bill Nottingham wrote: > > > > We already have a 'package search' interface for finding packages - is > > > > listing 100 (or however many) python-* packages better than this? In > > > > what way? Are they not getting pulled in for dependencies when necessary? > > > > > > I'm in agreement with Bill on this. Pretty much all the python-* > > > packages should be pulled in as dependencies. Am I missing something > > > here? > > > > It's pretty much impossible to autodetect missing comps entries unless > > every package is systematically put in comps. No autochecking means low > > QA. > > But the entire point is that everything _SHOULDN'T_ be there. If so, > then it's no better than a list[1] But the entire point is unless packages show up in comps, we have no idea if they're missing because they should not be exposed or because someone forgot to think about it. explicit "this package is in a group most users don't care about" is very different from "this package is not in any group, so probably users do not need to see it" -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From notting at redhat.com Mon Nov 27 22:49:01 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 17:49:01 -0500 Subject: New Comps Groups In-Reply-To: <1164667391.3195.10.camel@rousalka.dyndns.org> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <20061127205725.GA24223@nostromo.devel.redhat.com> <1164667391.3195.10.camel@rousalka.dyndns.org> Message-ID: <20061127224901.GA2729@nostromo.devel.redhat.com> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > > What constitutes 'missing'? Just something that should be selectable but > > isn't there? I would hope that those sorts of things would become apparent. > > A new package which has not been classified at all (ie the contributor > "forgot" to think about comps at all) So, does this need to be part of the review process? Bill From katzj at redhat.com Mon Nov 27 23:16:18 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 27 Nov 2006 18:16:18 -0500 Subject: New Comps Groups In-Reply-To: References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <20061127221001.GA19234@nostromo.devel.redhat.com> Message-ID: <1164669378.28835.16.camel@aglarond.local> On Mon, 2006-11-27 at 14:27 -0800, Christopher Stone wrote: > On 11/27/06, Bill Nottingham wrote: > > Christopher Stone (chris.stone at gmail.com) said: > > > If you ask what good it provides, then I have to ask what harm would > > > it cause? > > > > That's not how good engineering is done, generally - it's based > > on 'Why?', not 'Why not?' Any bit of new code: > > > > 1) can add bugs > > 2) adds a maintenance load > > 3) adds complexity > > > > The idea is to figure out the scenarios and personas you're trying > > to design for, and then figure out how to meet those needs. > > > > How does a checkbox list of 589 packages (roughly the number of > > perl-* packages) make someone's life easier? Is this better done > > via searching for 'perl' in the package search interface, for example? > > I would say no. Take for example python packages. Some are called > python-* some are called py* some are called Py* some are called *py, > etc. Yet for all of them, you can just as well do the search for python and find 99% of them since they'll say that they're a python module in their description or summary. And what's "better" about searching through a long list via browse than search? I say search is better as you can add _other_ qualifiers. Jeremy From katzj at redhat.com Mon Nov 27 23:19:00 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 27 Nov 2006 18:19:00 -0500 Subject: New Comps Groups In-Reply-To: References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <1164661131.22125.106.camel@aglarond.local> Message-ID: <1164669540.28835.20.camel@aglarond.local> On Mon, 2006-11-27 at 14:19 -0800, Christopher Stone wrote: > On 11/27/06, Jeremy Katz wrote: > > On Mon, 2006-11-27 at 21:52 +0100, Nicolas Mailhot wrote: > > > Le lundi 27 novembre 2006 ? 15:33 -0500, Brian Pepple a ?crit : > > > > On Mon, 2006-11-27 at 13:24 -0500, Bill Nottingham wrote: > > > > > We already have a 'package search' interface for finding packages - is > > > > > listing 100 (or however many) python-* packages better than this? In > > > > > what way? Are they not getting pulled in for dependencies when necessary? > > > > > > > > I'm in agreement with Bill on this. Pretty much all the python-* > > > > packages should be pulled in as dependencies. Am I missing something > > > > here? > > > > > > It's pretty much impossible to autodetect missing comps entries unless > > > every package is systematically put in comps. No autochecking means low > > > QA. > > > > But the entire point is that everything _SHOULDN'T_ be there. If so, > > then it's no better than a list[1] > > How is adding a half dozen new groups to Development in comps going to > reduce comps to be noting better than yum list '*'? The problem is that you're using the argument of "all packages need to be in comps, so we need to add groups" when comps was _never_ intended to be an exhaustive list of every package. Trying to solve "forgotten" packages by making _every_ package be listed is a losing battle and makes comps far less useful than it was intended to be. You'd be better off solving that problem with a) include it as a step in the review process and b) integration with the push scripts to provide notification/questioning when a new package is added to the repository and isn't listed in comps. Jeremy From nicolas.mailhot at laposte.net Tue Nov 28 00:01:01 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 28 Nov 2006 01:01:01 +0100 Subject: New Comps Groups In-Reply-To: <1164669540.28835.20.camel@aglarond.local> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <1164661131.22125.106.camel@aglarond.local> <1164669540.28835.20.camel@aglarond.local> Message-ID: <1164672066.3195.76.camel@rousalka.dyndns.org> Le lundi 27 novembre 2006 ? 18:19 -0500, Jeremy Katz a ?crit : > The problem is that you're using the argument of "all packages need to > be in comps, so we need to add groups" when comps was _never_ intended > to be an exhaustive list of every package. Well, maybe comps was not intended to be a lot of things, but when it was decided not to fix rpm groups and use comps as the only classification method of yum repositories, comps graduated to another level. > You'd be better off solving that problem with a) include it as a > step in the review process and b) integration with the push scripts to > provide notification/questioning when a new package is added to the > repository and isn't listed in comps. This may scale at the redhat level but in a community context it doesn't. Automation is a lifesaver. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From mastahnke at gmail.com Tue Nov 28 00:01:11 2006 From: mastahnke at gmail.com (Michael Stahnke) Date: Mon, 27 Nov 2006 18:01:11 -0600 Subject: New Comps Groups In-Reply-To: <1164660729.3195.8.camel@rousalka.dyndns.org> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> Message-ID: <7874d9dd0611271601h2b9ccf35j8574a2177c11e363@mail.gmail.com> On 11/27/06, Nicolas Mailhot wrote: > > Le lundi 27 novembre 2006 ? 15:33 -0500, Brian Pepple a ?crit : > > On Mon, 2006-11-27 at 13:24 -0500, Bill Nottingham wrote: > > > We already have a 'package search' interface for finding packages - is > > > listing 100 (or however many) python-* packages better than this? In > > > what way? Are they not getting pulled in for dependencies when > necessary? > > > > I'm in agreement with Bill on this. Pretty much all the python-* > > packages should be pulled in as dependencies. Am I missing something > > here? > > It's pretty much impossible to autodetect missing comps entries unless > every package is systematically put in comps. No autochecking means low > QA. I tend to agree here. When I want to develop PHP, I would like the option of "just install all the php stuff." It's easier than doing yum list available > file; grep -i php file. Does that make sense? Here I am an end-user who does development and find it difficult to find packages. This is especially true since yum search lists the package and the description, even if you already have it installed. I find the whole process rather frustrating...at least from time to time. If could just select PHP Packages, I would be a happy camper. I understand that might be a big group, but could you make 'meta group' that would be a pointer to all PHP packages? And of course something similar for the other major languages. MIKE Also if a group is too big it should be broken up in lighter > finer-grained ones IMHO. Choosing the right group is much less work than > writing the package description, and often more useful for users. > > -- > Nicolas Mailhot > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvinyard at cs.nmsu.edu Tue Nov 28 01:33:33 2006 From: rvinyard at cs.nmsu.edu (Rick L Vinyard Jr) Date: Mon, 27 Nov 2006 18:33:33 -0700 Subject: New Comps Groups In-Reply-To: <20061127182408.GC32187@nostromo.devel.redhat.com> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> Message-ID: <456B91ED.3000509@cs.nmsu.edu> Bill Nottingham wrote: > Christopher Stone (chris.stone at gmail.com) said: > >>> Why, out of curiosity? In what cases are these something that a user >>> wants to explicitly wade through 100 listings for? >>> >> I do not understand this question? Is it somehow better to wade >> through 1000s of packages to find something instead? Please rephrase >> your question to be more specific. >> > > We already have a 'package search' interface for finding packages - is > listing 100 (or however many) python-* packages better than this? In > what way? Are they not getting pulled in for dependencies when necessary? > > Basically, what's the use case for when a user would want to scroll through > all of python-* or perl-* looking for a package? > > Discovery... as a user two of the things I miss most about the available package managers that I loved in aptitude are: 1) Categorized packages 2) 'New' packages When I'm writing an application in language L and need some functionality X, browsing through the devel packages for package P that provides X in L is pretty handy. As a user (developer's are users too) I like it. From rvinyard at cs.nmsu.edu Tue Nov 28 01:39:20 2006 From: rvinyard at cs.nmsu.edu (Rick L Vinyard Jr) Date: Mon, 27 Nov 2006 18:39:20 -0700 Subject: New Comps Groups In-Reply-To: <20061127221001.GA19234@nostromo.devel.redhat.com> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <20061127221001.GA19234@nostromo.devel.redhat.com> Message-ID: <456B9348.8070002@cs.nmsu.edu> Bill Nottingham wrote: > How does a checkbox list of 589 packages (roughly the number of > perl-* packages) make someone's life easier? Is this better done > via searching for 'perl' in the package search interface, for example? > > That's actually an area I'd like to see improved, especially for C/C++ libraries... multi-level taxonomies. Many users find taxonomies useful in more ways than one. By grouping related items together often users looking for one item discover another similar item that they weren't looking for, but need. From buildsys at fedoraproject.org Tue Nov 28 01:41:27 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 27 Nov 2006 20:41:27 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-27 Message-ID: <20061128014127.E3FE115212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 24 GeoIP-1.4.0-4.fc7 GraphicsMagick-1.1.7-2.fc7 Invalid rebuild: perl-File-Remove-0.34-1.fc7 clement-2.1-241.fc7 clipsmm-0.0.7-1.fc7 firefox-32-0.0.1-5.fc7 gparted-0.3.1-5.fc7 gramps-2.2.3-1.fc7 gwenview-1.4.1-2.fc7 jd-1.8.1-0.1.cvs061127.fc7 kaffeine-0.8.3-1.fc7 libdvdread-0.9.7-1.fc7 nsd-3.0.2-1.fc7 ochusha-0.5.99.63.6-0.1.cvs061127.fc7 openpbx-1.2-3.rc2.svn2135.fc7 perl-Cache-Simple-TimedExpiry-0.27-1.fc7 perl-Gtk2-Notify-0.02-4.fc7 proftpd-1.3.0a-1.fc7 smb4k-0.7.5-1.fc7 spandsp-0.0.3-1.pre26.fc7 tcd-utils-20061127-1.fc7 tideEditor-1.3.12-3.fc7 tracker-0.5.2-3.fc7 xdms-1.3.2-3.fc7 Packages built and released for Fedora Extras 6: 34 GeoIP-1.4.0-4.fc6 Invalid rebuild: SDL_image-1.2.5-3.fc6 Invalid rebuild: perl-File-Remove-0.34-1.fc6 arrows-0.6-2.fc6 atomorun-1.1-0.2.pre2.fc6 clement-2.1-241.fc6 clipsmm-0.0.7-1.fc6 cmake-2.4.4-1.fc6 dar-2.3.1-4.fc6 dd2-0.2.1-1.fc6 e2tools-0.0.16-5.fc6 eterm-0.9.4-4.fc6 firefox-32-0.0.1-5.fc6 gliv-1.9.6-2.fc6 gq-1.2.2-2.fc6 gwenview-1.4.1-2.fc6 libast-0.7.1-0.1.20060818cvs.fc6 libmpd-0.12.0-3.fc6 libtcd-2.2-1.fc6 liquidwar-5.6.3-2.fc6 netcdf-perl-1.2.3-2.fc6 perl-Apache-DBI-1.05-2.fc6 perl-Cache-Simple-TimedExpiry-0.27-1.fc6 sdparm-1.00-4.fc6 seahorse-0.8.2-1.fc6 smb4k-0.7.5-1.fc6 spandsp-0.0.3-1.pre26.fc6 tclchecker-1.4-1.20061030cvs.fc6 tcldebugger-1.4-1.20061030cvs.fc6 tclparser-1.4-1.20061030cvs.fc6 tclpro-1.5.0-6.20061030cvs.fc6 xdms-1.3.2-3.fc6 xerces-c-2.7.0-6.fc6 zabbix-1.1.4-2.fc6 Packages built and released for Fedora Extras 5: 25 GeoIP-1.4.0-1.fc5 Invalid rebuild: perl-File-Remove-0.34-1.fc5 arrows-0.6-2.fc5 atomorun-1.1-0.2.pre2.fc5 clipsmm-0.0.7-1.fc5 cmake-2.4.4-1.fc5 dar-2.3.1-4.fc5 dd2-0.2.1-1.fc5 gnash-0.7.2-1.fc5 libmpd-0.12.0-3.fc5 libtcd-2.2-1.fc5 liquidwar-5.6.3-2.fc5 netcdf-perl-1.2.3-2.fc5 perl-Apache-DBI-1.05-2.fc5 perl-Cache-Simple-TimedExpiry-0.27-1.fc5 smb4k-0.7.5-1.fc5 spandsp-0.0.3-1.pre26.fc5 tclchecker-1.4-1.20061030cvs.fc5 tcldebugger-1.4-1.20061030cvs.fc5 tclparser-1.4-1.20061030cvs.fc5 tclpro-1.5.0-6.20061030cvs.fc5 tin-1.8.2-1.fc5 xdms-1.3.2-3.fc5 xerces-c-2.7.0-6.fc5 zabbix-1.1.4-2.fc5 Packages built and released for Fedora Extras 4: 6 GeoIP-1.4.0-1.fc4 Invalid rebuild: perl-File-Remove-0.34-1.fc4 cmake-2.4.4-1.fc4 mlmmj-1.2.12-1.fc4 perl-Cache-Simple-TimedExpiry-0.27-1.fc4 tin-1.8.2-1.fc4 Packages built and released for Fedora Extras 3: 2 mlmmj-1.2.12-1.fc3 tin-1.8.2-1.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From rvinyard at cs.nmsu.edu Tue Nov 28 01:44:58 2006 From: rvinyard at cs.nmsu.edu (Rick L Vinyard Jr) Date: Mon, 27 Nov 2006 18:44:58 -0700 Subject: New Comps Groups In-Reply-To: <1164669378.28835.16.camel@aglarond.local> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <20061127221001.GA19234@nostromo.devel.redhat.com> <1164669378.28835.16.camel@aglarond.local> Message-ID: <456B949A.8090501@cs.nmsu.edu> Jeremy Katz wrote: > Yet for all of them, you can just as well do the search for python and > find 99% of them since they'll say that they're a python module in their > description or summary. If you do that, you end up with python editors, games written in python, etc. which is probably an even longer list. Then, try that with a search query of 'c'. > And what's "better" about searching through a > long list via browse than search? I say search is better as you can add > _other_ qualifiers. > There aren't any restrictions on searching within a category either. In fact, I'd much rather see an interface that supports both. From buildsys at fedoraproject.org Tue Nov 28 02:39:15 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 28 Nov 2006 02:39:15 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-27 Message-ID: <20061128023915.25150.7613@extras64.linux.duke.edu> ERROR: GraphicsMagick not in owners.list ERROR: source rpm is GraphicsMagick-1.1.7-2.fc7.src.rpm ERROR: GraphicsMagick not in owners.list ERROR: source rpm is GraphicsMagick-1.1.7-2.fc7.src.rpm ERROR: GraphicsMagick not in owners.list ERROR: source rpm is GraphicsMagick-1.1.7-2.fc7.src.rpm ERROR: GraphicsMagick not in owners.list ERROR: source rpm is GraphicsMagick-1.1.7-2.fc7.src.rpm New report for: UNKNOWN OWNER package: GraphicsMagick-c++-devel - 1.1.7-2.fc7.ppc from fedora-extras-development-ppc unresolved deps: GraphicsMagick-devel = 0:1.1.72.fc7 package: GraphicsMagick-c++-devel - 1.1.7-2.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: GraphicsMagick-devel = 0:1.1.72.fc7 package: GraphicsMagick-c++-devel - 1.1.7-2.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: GraphicsMagick-devel = 0:1.1.72.fc7 package: GraphicsMagick-c++-devel - 1.1.7-2.fc7.i386 from fedora-extras-development-i386 unresolved deps: GraphicsMagick-devel = 0:1.1.72.fc7 ====================================================================== Summary of broken packages (by owner): Jochen AT herr-schmitt.de blender - 2.42a-5.fc7.i386 (4 days) blender - 2.42a-5.fc7.ppc (4 days) blender - 2.42a-5.fc7.x86_64 (4 days) UNKNOWN OWNER GraphicsMagick-c++-devel - 1.1.7-2.fc7.i386 GraphicsMagick-c++-devel - 1.1.7-2.fc7.i386 GraphicsMagick-c++-devel - 1.1.7-2.fc7.ppc GraphicsMagick-c++-devel - 1.1.7-2.fc7.x86_64 andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 (27 days) centericq - 4.21.0-8.fc6.ppc (27 days) centericq - 4.21.0-8.fc6.x86_64 (27 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (30 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (30 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (30 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (30 days) orange - 0.3-3.cvs20051118.fc6.i386 (34 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (58 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (58 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (58 days) braden AT endoframe.com openvrml - 0.16.1-4.fc7.i386 (4 days) openvrml - 0.16.1-4.fc7.i386 (4 days) openvrml - 0.16.1-4.fc7.ppc (4 days) openvrml - 0.16.1-4.fc7.x86_64 (4 days) openvrml-devel - 0.16.1-4.fc7.i386 (4 days) openvrml-devel - 0.16.1-4.fc7.i386 (4 days) openvrml-devel - 0.16.1-4.fc7.ppc (4 days) openvrml-devel - 0.16.1-4.fc7.x86_64 (4 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (73 days) plague - 0.4.4.1-2.fc3.noarch (73 days) plague - 0.4.4.1-2.fc4.noarch (73 days) plague - 0.4.4.1-2.fc4.noarch (73 days) plague - 0.4.4.1-2.fc4.noarch (73 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (49 days) linphone - 1.2.0-4.fc5.ppc (49 days) linphone - 1.2.0-4.fc5.x86_64 (49 days) karlthered AT gmail.com gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.i386 (5 days) gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.i386 (5 days) gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.ppc (5 days) gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.x86_64 (5 days) matthias AT rpmforge.net php-eaccelerator - 5.1.6_0.9.5-2.fc7.i386 (11 days) php-eaccelerator - 5.1.6_0.9.5-2.fc7.ppc (11 days) php-eaccelerator - 5.1.6_0.9.5-2.fc7.x86_64 (11 days) oliver AT linux-kernel.at syck-php - 0.55-10.fc6.i386 (11 days) syck-php - 0.55-10.fc6.ppc (11 days) syck-php - 0.55-10.fc6.x86_64 (11 days) syck-php - 0.55-9.fc5.i386 (39 days) syck-php - 0.55-9.fc5.ppc (39 days) syck-php - 0.55-9.fc5.x86_64 (39 days) pertusus AT free.fr grads - 1.9b4-19.fc7.i386 (11 days) grads - 1.9b4-19.fc7.ppc (11 days) grads - 1.9b4-19.fc7.x86_64 (11 days) petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 (24 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (24 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (24 days) ghc642-gtk2hs - 0.9.10-4.fc6.i386 (24 days) ghc642-gtk2hs - 0.9.10-4.fc6.ppc (24 days) ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 (24 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 (24 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc (24 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 (24 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (29 days) tcallawa AT redhat.com gambas-runtime - 1.0.17-6.fc7.i386 (4 days) gambas-runtime - 1.0.17-6.fc7.ppc (4 days) ====================================================================== Broken packages in fedora-extras-development-ppc: GraphicsMagick-c++-devel-1.1.7-2.fc7.ppc requires GraphicsMagick-devel = 0:1.1.72.fc7 blender-2.42a-5.fc7.ppc requires libgettextlib-0.15.so centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 gambas-runtime-1.0.17-6.fc7.ppc requires libgettextlib-0.15.so ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 grads-1.9b4-19.fc7.ppc requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.ppc requires gecko-libs = 0:2.0 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 openvrml-0.16.1-4.fc7.ppc requires firefox = 0:1.5.0.8 openvrml-devel-0.16.1-4.fc7.ppc requires firefox-devel = 0:1.5.0.8 php-eaccelerator-5.1.6_0.9.5-2.fc7.ppc requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.ppc requires php = 0:5.1.6 ====================================================================== Broken packages in fedora-extras-development-x86_64: GraphicsMagick-c++-devel-1.1.7-2.fc7.i386 requires GraphicsMagick-devel = 0:1.1.72.fc7 GraphicsMagick-c++-devel-1.1.7-2.fc7.x86_64 requires GraphicsMagick-devel = 0:1.1.72.fc7 blender-2.42a-5.fc7.x86_64 requires libgettextlib-0.15.so()(64bit) centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 grads-1.9b4-19.fc7.x86_64 requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.i386 requires gecko-libs = 0:2.0 gtkmozembedmm-1.4.2.cvs20060817-5.fc7.x86_64 requires gecko-libs = 0:2.0 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) openvrml-0.16.1-4.fc7.i386 requires firefox = 0:1.5.0.8 openvrml-0.16.1-4.fc7.x86_64 requires firefox = 0:1.5.0.8 openvrml-devel-0.16.1-4.fc7.i386 requires firefox-devel = 0:1.5.0.8 openvrml-devel-0.16.1-4.fc7.x86_64 requires firefox-devel = 0:1.5.0.8 orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 php-eaccelerator-5.1.6_0.9.5-2.fc7.x86_64 requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.x86_64 requires php = 0:5.1.6 ====================================================================== Broken packages in fedora-extras-development-i386: GraphicsMagick-c++-devel-1.1.7-2.fc7.i386 requires GraphicsMagick-devel = 0:1.1.72.fc7 blender-2.42a-5.fc7.i386 requires libgettextlib-0.15.so centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 gambas-runtime-1.0.17-6.fc7.i386 requires libgettextlib-0.15.so ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 grads-1.9b4-19.fc7.i386 requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.i386 requires gecko-libs = 0:2.0 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 openvrml-0.16.1-4.fc7.i386 requires firefox = 0:1.5.0.8 openvrml-devel-0.16.1-4.fc7.i386 requires firefox-devel = 0:1.5.0.8 php-eaccelerator-5.1.6_0.9.5-2.fc7.i386 requires php-common = 0:5.1.6 syck-php-0.55-10.fc6.i386 requires php = 0:5.1.6 ====================================================================== Broken packages in fedora-extras-5-ppc: linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 ====================================================================== Broken packages in fedora-extras-5-x86_64: linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 ====================================================================== Broken packages in fedora-extras-5-i386: linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 ====================================================================== Broken packages in fedora-extras-4-ppc: plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 ====================================================================== Broken packages in fedora-extras-4-x86_64: plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) ====================================================================== Broken packages in fedora-extras-4-i386: plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 ====================================================================== Broken packages in fedora-extras-3-x86_64: plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== Broken packages in fedora-extras-3-i386: plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 From mattdm at mattdm.org Tue Nov 28 03:05:57 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 27 Nov 2006 22:05:57 -0500 Subject: New Comps Groups In-Reply-To: <20061127221001.GA19234@nostromo.devel.redhat.com> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <20061127221001.GA19234@nostromo.devel.redhat.com> Message-ID: <20061128030557.GA3156@jadzia.bu.edu> On Mon, Nov 27, 2006 at 05:10:01PM -0500, Bill Nottingham wrote: > How does a checkbox list of 589 packages (roughly the number of > perl-* packages) make someone's life easier? Is this better done > via searching for 'perl' in the package search interface, for example? I did this at BU, on request from several perl developers here. And I've gotten positive feedback about "all the perl modules you include" -- even though we have very little that's not in Extras. But, personally, I find it annoying, because if I'm doing an install and accidentally check that box, it takes, like, five minutes for Anaconda to compute the implications. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Nov 28 03:44:28 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 27 Nov 2006 22:44:28 -0500 Subject: New Comps Groups In-Reply-To: <456B9348.8070002@cs.nmsu.edu> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <20061127221001.GA19234@nostromo.devel.redhat.com> <456B9348.8070002@cs.nmsu.edu> Message-ID: <20061128034428.GA4994@jadzia.bu.edu> On Mon, Nov 27, 2006 at 06:39:20PM -0700, Rick L Vinyard Jr wrote: > That's actually an area I'd like to see improved, especially for C/C++ > libraries... multi-level taxonomies. Many users find taxonomies useful > in more ways than one. By grouping related items together often users > looking for one item discover another similar item that they weren't > looking for, but need. Sure, adding in some kinda package tagging scheme could make sense. This would be particularly useful for repoview. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Nov 28 03:47:47 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 27 Nov 2006 22:47:47 -0500 Subject: New Comps Groups In-Reply-To: <7874d9dd0611271601h2b9ccf35j8574a2177c11e363@mail.gmail.com> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <7874d9dd0611271601h2b9ccf35j8574a2177c11e363@mail.gmail.com> Message-ID: <20061128034747.GB4994@jadzia.bu.edu> On Mon, Nov 27, 2006 at 06:01:11PM -0600, Michael Stahnke wrote: > end-user who does development and find it difficult to find packages. This > is especially true since yum search lists the package and the description, > even if you already have it installed. I find the whole process rather I don't think "yum search" is the answer. Repoview is the answer. But there's still the question of how to organize that usefully and automatically. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rc040203 at freenet.de Tue Nov 28 04:17:30 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 28 Nov 2006 05:17:30 +0100 Subject: .h files in non-devel package? In-Reply-To: <668bb39a0611270918q7bf8688dm7b6839397bfd988b@mail.gmail.com> References: <1164646579.5460.3.camel@scriabin.tannenrauch.ch> <1164647316.6317.122.camel@mccallum.corsepiu.local> <668bb39a0611270918q7bf8688dm7b6839397bfd988b@mail.gmail.com> Message-ID: <1164687450.6317.175.camel@mccallum.corsepiu.local> On Mon, 2006-11-27 at 18:18 +0100, Micha? Bentkowski wrote: > 2006/11/27, Ralf Corsepius : > > If you really want to name the package "" only, then I'd recommend > > to at least add "Provides: %{name}-devel = %{version}-%{release}" to > > cater users expecting development files in "*-devel" packages. > > In my opinion it's not a good solution. ReviewGuidelines says that: > "The placement of pkgconfig(.pc) files depends on their usecase, and > this is usually for development purposes, so should be placed in a > -devel pkg. A reasonable exception is that the main pkg itself is a > devel tool not installed in a user runtime, e.g. gcc or gdb." - it > concerns .pc files but I think that solution should be applied in all > packages which are only development packages. > Thus G?rard is right, -devel subpackage is not needed. How does this contradict to what I said? Ralf From peter at thecodergeek.com Tue Nov 28 05:38:45 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 27 Nov 2006 21:38:45 -0800 Subject: rpms/GraphicsMagick/devel GraphicsMagick-gslib.patch, NONE, 1.1 GraphicsMagick.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <20061127145824.360e0331.bugs.michael@gmx.net> References: <200611271338.kARDcB8x009924@cvs-int.fedora.redhat.com> <20061127145824.360e0331.bugs.michael@gmx.net> Message-ID: <1164692325.3284.9.camel@tuxhugger> On Mon, 2006-11-27 at 14:58 +0100, Michael Schwendt wrote: > > %package perl > > Summary: GraphicsMagick perl bindings > > Group: System Environment/Libraries > > Requires: %{name} = %{version}-%{release} > > Requires: perl >= 5.6.0 > > %define perl_vendorarch %(perl -MConfig -le 'print $Config{installvendorarch}') > > BuildRequires: %{perl_vendorarch} > > Where's...? > > Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) > > You BR a directory and install into it, but an insufficient version of > Perl may not have that directory in its search path. I may be mistaken (in which case the rest of this message may be safely ignored) but it seems to me that this requirement is taken care of by the 'perl >= 5.6.0' Requires tag. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From michel.salim at gmail.com Tue Nov 28 05:44:49 2006 From: michel.salim at gmail.com (Michel Salim) Date: Tue, 28 Nov 2006 00:44:49 -0500 Subject: Unorphaning wbxml2 In-Reply-To: <200611271707.02208@rineau.schtroumpfette> References: <200611271707.02208@rineau.schtroumpfette> Message-ID: <883cfe6d0611272144p3d3d510eyc9ba4126244249ee@mail.gmail.com> 2006/11/27, Laurent Rineau : > I am taking the ownership of *wbxml2*, which is a retired package (because its > maintainer could not sign the Fedora CLA due to its company policy). > Nice. I was contemplating maintaining it, because it's needed by the SyncML plugin for libopensync, but that plugin is not production-quality yet, unfortunately. -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From peter at thecodergeek.com Tue Nov 28 05:48:35 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 27 Nov 2006 21:48:35 -0800 Subject: .h files in non-devel package? In-Reply-To: <20061127200707.GA10795@rathann.pekin.waw.pl> References: <1164646579.5460.3.camel@scriabin.tannenrauch.ch> <1164647316.6317.122.camel@mccallum.corsepiu.local> <668bb39a0611270918q7bf8688dm7b6839397bfd988b@mail.gmail.com> <20061127200707.GA10795@rathann.pekin.waw.pl> Message-ID: <1164692915.3284.20.camel@tuxhugger> On Mon, 2006-11-27 at 21:07 +0100, Dominik 'Rathann' Mierzejewski wrote: > > Thus G?rard is right, -devel subpackage is not needed. > > Why not call the main package -devel and forget the whole issue? In and of itself, it is *only* a development package, similar to the GNU toolchain (gcc/binutils/etc). Hence, (as I see it) there is no need for the -devel naming since it does not have a corresponding runtime-only component. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tmz at pobox.com Tue Nov 28 05:51:21 2006 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 28 Nov 2006 00:51:21 -0500 Subject: rpms/GraphicsMagick/devel GraphicsMagick-gslib.patch, NONE, 1.1 GraphicsMagick.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <1164692325.3284.9.camel@tuxhugger> References: <200611271338.kARDcB8x009924@cvs-int.fedora.redhat.com> <20061127145824.360e0331.bugs.michael@gmx.net> <1164692325.3284.9.camel@tuxhugger> Message-ID: <20061128055121.GA25532@psilocybe.teonanacatl.org> Peter Gordon wrote: > On Mon, 2006-11-27 at 14:58 +0100, Michael Schwendt wrote: >>> %package perl >>> Summary: GraphicsMagick perl bindings >>> Group: System Environment/Libraries >>> Requires: %{name} = %{version}-%{release} >>> Requires: perl>= 5.6.0 >>> %define perl_vendorarch %(perl -MConfig -le 'print $Config{installvendorarch}') >>> BuildRequires: %{perl_vendorarch} >> >> Where's...? >> >> Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) >> >> You BR a directory and install into it, but an insufficient version of >> Perl may not have that directory in its search path. > > I may be mistaken (in which case the rest of this message may be safely > ignored) but it seems to me that this requirement is taken care of by > the 'perl>= 5.6.0' Requires tag. The Requires: perl will only take care of requires for installation. BuildRequires are needed to ensure that the build environment is complete. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== I would rather be exposed to the inconveniences attending too much liberty than those attending too small a degree of it. -- Thomas Jefferson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From peter at thecodergeek.com Tue Nov 28 06:10:33 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 27 Nov 2006 22:10:33 -0800 Subject: rpms/GraphicsMagick/devel GraphicsMagick-gslib.patch, NONE, 1.1 GraphicsMagick.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <20061128055121.GA25532@psilocybe.teonanacatl.org> References: <200611271338.kARDcB8x009924@cvs-int.fedora.redhat.com> <20061127145824.360e0331.bugs.michael@gmx.net> <1164692325.3284.9.camel@tuxhugger> <20061128055121.GA25532@psilocybe.teonanacatl.org> Message-ID: <1164694233.3284.22.camel@tuxhugger> On Tue, 2006-11-28 at 00:51 -0500, Todd Zullinger wrote: > The Requires: perl will only take care of requires for installation. > BuildRequires are needed to ensure that the build environment is > complete. Baah. I was looking at it and didn't see notice BR/Requires separation. Apologies for the confusion (and thanks for the clarification). -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Tue Nov 28 06:29:10 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 28 Nov 2006 07:29:10 +0100 Subject: .h files in non-devel package? In-Reply-To: <1164692915.3284.20.camel@tuxhugger> References: <1164646579.5460.3.camel@scriabin.tannenrauch.ch> <1164647316.6317.122.camel@mccallum.corsepiu.local> <668bb39a0611270918q7bf8688dm7b6839397bfd988b@mail.gmail.com> <20061127200707.GA10795@rathann.pekin.waw.pl> <1164692915.3284.20.camel@tuxhugger> Message-ID: <1164695351.6317.238.camel@mccallum.corsepiu.local> On Mon, 2006-11-27 at 21:48 -0800, Peter Gordon wrote: > On Mon, 2006-11-27 at 21:07 +0100, Dominik 'Rathann' Mierzejewski wrote: > > > Thus G?rard is right, -devel subpackage is not needed. > > > > Why not call the main package -devel and forget the whole issue? > > In and of itself, it is *only* a development package, similar to the GNU > toolchain (gcc/binutils/etc). Hence, (as I see it) there is no need for > the -devel naming since it does not have a corresponding runtime-only > component. Right. Problems only arise in longer terms, if this package is being added apps. Then, a split into '*-devel" and 'nondevel" is helpful to avoid the apps pulling in other deps. Example: Imagine a c-library, being added c++ apps. If the "devel" and "nondevel" are not split, the package will unnecessarily pull in the c++-runtime deps (which could be a long chain of run-time libraries) Therefore, my recommendation is to name a "development" package "*-devel", though it's not technically strictly required. The GNU-toolchain is a bit different. It basically is a set of applications (Note applications, not libraries), being accompanied with some libraries packaged outside of the application packages. To the library packages, the same general considerations as to other libraries apply. They should be split into devel and non-devel. Ralf From j.w.r.degoede at hhs.nl Tue Nov 28 08:06:38 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 28 Nov 2006 09:06:38 +0100 Subject: lbreakout in fedora extras? In-Reply-To: <456B5EE7.9050302@fedoraproject.org> References: <4568AEDE.1040703@hhs.nl> <456B5EE7.9050302@fedoraproject.org> Message-ID: <456BEE0E.2000405@hhs.nl> Rahul Sundaram wrote: > Hans de Goede wrote: >> Hi all, >> >> I'm concidering packaging lbreakout for FE, but I think the name is a >> problem, so some days ago I send a kind request to upstream to change >> the name, of which I'll reproduce a part here as it decribes the issue >> at hand: >> >> "There currently is one problem with lbreakout (and other lgames) at the >> moment though, their names. We at Fedora try to be very carefully to >> make a 100% Free distro which isn't "tainted" in anyway. Sticking to >> lbreakout as example, the original breakout game is copyrighted by Atari >> which still exists, and breakout clearly qualifies as a trademark. If >> I'm to believe Atari's website its even a registered trademark, see: >> http://www.atari.com/us/games/atari_anniversary/pc >> >> And look at the "Breakout?" text." >> >> Thus I believe lbreakout cannot be included as is however Debian does >> have it in main. My guess is Debian just overlooked this and this cannot >> go into FE as is. Opinions anyone? >> >> Regards, >> >> Hans >> >> >> p.s. >> >> Chances are high that if the concensus is this cannot go in as is I'll >> do a rebranded version and package that. > > Have you tried contacting upstream and pointing out this potential > trademark issue with them? A Fedora rebranded version will cause > confusion similar to Firefox/Iceweasel. > > Rahul > Erm, which part of "so some days ago I send a kind request to upstream to change the name" as you can read in my original mail (above) wasn't / isn't clear? Regards, Hans From jspaleta at gmail.com Tue Nov 28 09:19:16 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 28 Nov 2006 00:19:16 -0900 Subject: Anyone seeing problems with cvs-import.sh? Message-ID: <604aa7910611280119u2094ee1qff1e3926b3df3927@mail.gmail.com> Im getting errors when trying to use cvs-import.sh not sure what to check. Please tell me if I'm doing something boneheaded. The error messages appear to be a failure in make upload. Is there something actually busted at the moment.. or is it just me? Here's what I'm running into ./cvs-import.sh -b FC-6 -m "update to 0.87.7 now that numpy has been updated" /var/lib/mock/fedora-6-i386-core/result/python-matplotlib-0.87.7-1.fc6.src.rpm Checking out the modules file... Module 'python-matplotlib' already exists... Checking out module: 'python-matplotlib' Unpacking source package: python-matplotlib-0.87.7-1.fc6.src.rpm... R matplotlib-0.87-matplotlibrc.patch A matplotlib-0.87.7-matplotlibrc.patch A matplotlib-0.87.7-tkagg-check.patch L matplotlib-0.87.7.tar.gz U python-matplotlib.spec Checking : matplotlib-0.87.7.tar.gz on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... ERROR: could not check remote file status make: *** [upload] Error 255 ERROR: Uploading the source tarballs failed! -jef From gemi at bluewin.ch Tue Nov 28 09:53:33 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Tue, 28 Nov 2006 10:53:33 +0100 Subject: .h files in non-devel package? In-Reply-To: <20061127200707.GA10795@rathann.pekin.waw.pl> References: <1164646579.5460.3.camel@scriabin.tannenrauch.ch> <1164647316.6317.122.camel@mccallum.corsepiu.local> <668bb39a0611270918q7bf8688dm7b6839397bfd988b@mail.gmail.com> <20061127200707.GA10795@rathann.pekin.waw.pl> Message-ID: <1164707613.3772.0.camel@scriabin.tannenrauch.ch> On Mon, 2006-11-27 at 21:07 +0100, Dominik 'Rathann' Mierzejewski wrote: > Why not call the main package -devel and forget the whole issue? That would be a little like calling the gcc package gcc-devel. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From paul at city-fan.org Tue Nov 28 11:02:13 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 28 Nov 2006 11:02:13 +0000 Subject: New Comps Groups In-Reply-To: <1164667559.3195.14.camel@rousalka.dyndns.org> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <1164661131.22125.106.camel@aglarond.local> <1164667559.3195.14.camel@rousalka.dyndns.org> Message-ID: <456C1735.2020706@city-fan.org> Nicolas Mailhot wrote: > Le lundi 27 novembre 2006 ? 15:58 -0500, Jeremy Katz a ?crit : >> On Mon, 2006-11-27 at 21:52 +0100, Nicolas Mailhot wrote: >>> Le lundi 27 novembre 2006 ? 15:33 -0500, Brian Pepple a ?crit : >>>> On Mon, 2006-11-27 at 13:24 -0500, Bill Nottingham wrote: >>>>> We already have a 'package search' interface for finding packages - is >>>>> listing 100 (or however many) python-* packages better than this? In >>>>> what way? Are they not getting pulled in for dependencies when necessary? >>>> I'm in agreement with Bill on this. Pretty much all the python-* >>>> packages should be pulled in as dependencies. Am I missing something >>>> here? >>> It's pretty much impossible to autodetect missing comps entries unless >>> every package is systematically put in comps. No autochecking means low >>> QA. >> But the entire point is that everything _SHOULDN'T_ be there. If so, >> then it's no better than a list[1] > > But the entire point is unless packages show up in comps, we have no > idea if they're missing because they should not be exposed or because > someone forgot to think about it. > > explicit "this package is in a group most users don't care about" is > very different from "this package is not in any group, so probably users > do not need to see it" Can't the package checking problem be solved by adding packages that are deliberately not intended to be in comps either to a group that is defined not to show up in the UI (that might need some extra work on the schema and the tools though), or in a completely separate file from the comps file that exists for the purpose of doing this checking? Paul. From laurent.rineau__fedora_extras at normalesup.org Tue Nov 28 11:33:46 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Tue, 28 Nov 2006 12:33:46 +0100 Subject: Unorphaning wbxml2 In-Reply-To: <883cfe6d0611272144p3d3d510eyc9ba4126244249ee@mail.gmail.com> References: <200611271707.02208@rineau.schtroumpfette> <883cfe6d0611272144p3d3d510eyc9ba4126244249ee@mail.gmail.com> Message-ID: <200611281233.46302@rineau.schtroumpfette> On Tuesday 28 November 2006 06:44, Michel Salim wrote: > 2006/11/27, Laurent Rineau : > > I am taking the ownership of *wbxml2*, which is a retired package > > (because its maintainer could not sign the Fedora CLA due to its company > > policy). > > Nice. I was contemplating maintaining it, because it's needed by the > SyncML plugin for libopensync, but that plugin is not > production-quality yet, unfortunately. Would you like to co-maintain it, as well as SyncML? As for libopensync-plugin-syncml, I am willing improve it as much as possible and submit patches to upstream developpers. From jkeating at redhat.com Tue Nov 28 13:23:56 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 28 Nov 2006 08:23:56 -0500 Subject: .h files in non-devel package? In-Reply-To: <1164692915.3284.20.camel@tuxhugger> References: <1164646579.5460.3.camel@scriabin.tannenrauch.ch> <20061127200707.GA10795@rathann.pekin.waw.pl> <1164692915.3284.20.camel@tuxhugger> Message-ID: <200611280823.59158.jkeating@redhat.com> On Tuesday 28 November 2006 00:48, Peter Gordon wrote: > In and of itself, it is *only* a development package, similar to the GNU > toolchain (gcc/binutils/etc). Hence, (as I see it) there is no need for > the -devel naming since it does not have a corresponding runtime-only > component. Except that we use the -devel packages as indications of what should be multilib. Since your package could be used in multilib development, perhaps it would be better to name it -devel. As it stands we have to maintain a whitelist of things that don't have a -devel name in order to make them multilib. Such hand done lists are surely to break (as they have in the past) or fall out of sync between tools such as push scripts and update tools, etc... -- Jesse Keating Release Engineer: Fedora -------------- 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 Tue Nov 28 13:30:15 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 28 Nov 2006 14:30:15 +0100 Subject: Anyone seeing problems with cvs-import.sh? In-Reply-To: <604aa7910611280119u2094ee1qff1e3926b3df3927@mail.gmail.com> References: <604aa7910611280119u2094ee1qff1e3926b3df3927@mail.gmail.com> Message-ID: <20061128143015.8f62306a.bugs.michael@gmx.net> On Tue, 28 Nov 2006 00:19:16 -0900, Jeff Spaleta wrote: > Im getting errors when trying to use cvs-import.sh not sure what to check. > Please tell me if I'm doing something boneheaded. The error messages > appear to be a failure in make upload. Is there something actually > busted at the moment.. or is it just me? > > Here's what I'm running into > ./cvs-import.sh -b FC-6 -m "update to 0.87.7 now that numpy has been > updated" /var/lib/mock/fedora-6-i386-core/result/python-matplotlib-0.87.7-1.fc6.src.rpm > > Checking out the modules file... > Module 'python-matplotlib' already exists... > Checking out module: 'python-matplotlib' > Unpacking source package: python-matplotlib-0.87.7-1.fc6.src.rpm... > R matplotlib-0.87-matplotlibrc.patch > A matplotlib-0.87.7-matplotlibrc.patch > A matplotlib-0.87.7-tkagg-check.patch > L matplotlib-0.87.7.tar.gz > U python-matplotlib.spec > > Checking : matplotlib-0.87.7.tar.gz on > https://cvs.fedora.redhat.com/repo/extras/upload.cgi... > ERROR: could not check remote file status > make: *** [upload] Error 255 > ERROR: Uploading the source tarballs failed! If you can't upload the tarball with "make new-sources FILES=..." either, maybe your certificate has expired. In that case generate a new one via the accounts system. From mattdm at mattdm.org Tue Nov 28 13:34:22 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 28 Nov 2006 08:34:22 -0500 Subject: New Comps Groups In-Reply-To: <456C1735.2020706@city-fan.org> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <1164661131.22125.106.camel@aglarond.local> <1164667559.3195.14.camel@rousalka.dyndns.org> <456C1735.2020706@city-fan.org> Message-ID: <20061128133422.GA23075@jadzia.bu.edu> On Tue, Nov 28, 2006 at 11:02:13AM +0000, Paul Howarth wrote: > Can't the package checking problem be solved by adding packages that are > deliberately not intended to be in comps either to a group that is > defined not to show up in the UI (that might need some extra work on the > schema and the tools though), or in a completely separate file from the > comps file that exists for the purpose of doing this checking? hidden groups already exist. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From paul at city-fan.org Tue Nov 28 13:37:26 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 28 Nov 2006 13:37:26 +0000 Subject: New Comps Groups In-Reply-To: <20061128133422.GA23075@jadzia.bu.edu> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <1164661131.22125.106.camel@aglarond.local> <1164667559.3195.14.camel@rousalka.dyndns.org> <456C1735.2020706@city-fan.org> <20061128133422.GA23075@jadzia.bu.edu> Message-ID: <456C3B96.8040208@city-fan.org> Matthew Miller wrote: > On Tue, Nov 28, 2006 at 11:02:13AM +0000, Paul Howarth wrote: >> Can't the package checking problem be solved by adding packages that are >> deliberately not intended to be in comps either to a group that is >> defined not to show up in the UI (that might need some extra work on the >> schema and the tools though), or in a completely separate file from the >> comps file that exists for the purpose of doing this checking? > > hidden groups already exist. Isn't this a no-brainer then? Paul. From mclasen at redhat.com Tue Nov 28 13:49:31 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 28 Nov 2006 08:49:31 -0500 Subject: New Comps Groups In-Reply-To: <456C3B96.8040208@city-fan.org> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <1164661131.22125.106.camel@aglarond.local> <1164667559.3195.14.camel@rousalka.dyndns.org> <456C1735.2020706@city-fan.org> <20061128133422.GA23075@jadzia.bu.edu> <456C3B96.8040208@city-fan.org> Message-ID: <1164721772.3640.1.camel@golem.boston.devel.redhat.com> On Tue, 2006-11-28 at 13:37 +0000, Paul Howarth wrote: > Matthew Miller wrote: > > On Tue, Nov 28, 2006 at 11:02:13AM +0000, Paul Howarth wrote: > >> Can't the package checking problem be solved by adding packages that are > >> deliberately not intended to be in comps either to a group that is > >> defined not to show up in the UI (that might need some extra work on the > >> schema and the tools though), or in a completely separate file from the > >> comps file that exists for the purpose of doing this checking? > > > > hidden groups already exist. > > Isn't this a no-brainer then? > Only if you assume that it is a good idea to list all packages in comps. Some people disagree with that. From dominik at greysector.net Tue Nov 28 14:13:33 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 28 Nov 2006 15:13:33 +0100 Subject: .h files in non-devel package? In-Reply-To: <1164707613.3772.0.camel@scriabin.tannenrauch.ch> References: <1164646579.5460.3.camel@scriabin.tannenrauch.ch> <1164647316.6317.122.camel@mccallum.corsepiu.local> <668bb39a0611270918q7bf8688dm7b6839397bfd988b@mail.gmail.com> <20061127200707.GA10795@rathann.pekin.waw.pl> <1164707613.3772.0.camel@scriabin.tannenrauch.ch> Message-ID: <20061128141333.GB19109@rathann.pekin.waw.pl> On Tuesday, 28 November 2006 at 10:53, G?rard Milmeister wrote: > On Mon, 2006-11-27 at 21:07 +0100, Dominik 'Rathann' Mierzejewski wrote: > > Why not call the main package -devel and forget the whole issue? > > That would be a little like calling the gcc package gcc-devel. So this package is a compiler? Which package is it? Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From gemi at bluewin.ch Tue Nov 28 14:50:12 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Tue, 28 Nov 2006 15:50:12 +0100 Subject: .h files in non-devel package? In-Reply-To: <20061128141333.GB19109@rathann.pekin.waw.pl> References: <1164646579.5460.3.camel@scriabin.tannenrauch.ch> <1164647316.6317.122.camel@mccallum.corsepiu.local> <668bb39a0611270918q7bf8688dm7b6839397bfd988b@mail.gmail.com> <20061127200707.GA10795@rathann.pekin.waw.pl> <1164707613.3772.0.camel@scriabin.tannenrauch.ch> <20061128141333.GB19109@rathann.pekin.waw.pl> Message-ID: <1164725412.13630.0.camel@scriabin.tannenrauch.ch> On Tue, 2006-11-28 at 15:13 +0100, Dominik 'Rathann' Mierzejewski wrote: > So this package is a compiler? Which package is it? It is STklos, a Scheme interpreter and bytecode compiler. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From paul at city-fan.org Tue Nov 28 14:59:57 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 28 Nov 2006 14:59:57 +0000 Subject: New Comps Groups In-Reply-To: <1164721772.3640.1.camel@golem.boston.devel.redhat.com> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <1164661131.22125.106.camel@aglarond.local> <1164667559.3195.14.camel@rousalka.dyndns.org> <456C1735.2020706@city-fan.org> <20061128133422.GA23075@jadzia.bu.edu> <456C3B96.8040208@city-fan.org> <1164721772.3640.1.camel@golem.boston.devel.redhat.com> Message-ID: <456C4EED.2010100@city-fan.org> Matthias Clasen wrote: > On Tue, 2006-11-28 at 13:37 +0000, Paul Howarth wrote: >> Matthew Miller wrote: >>> On Tue, Nov 28, 2006 at 11:02:13AM +0000, Paul Howarth wrote: >>>> Can't the package checking problem be solved by adding packages that are >>>> deliberately not intended to be in comps either to a group that is >>>> defined not to show up in the UI (that might need some extra work on the >>>> schema and the tools though), or in a completely separate file from the >>>> comps file that exists for the purpose of doing this checking? >>> hidden groups already exist. >> Isn't this a no-brainer then? >> > > Only if you assume that it is a good idea to list all packages in comps. > Some people disagree with that. The only underlying objection I recall seeing is that adding all packages to comps presents too many choices to users, and that problem doesn't happen if hidden groups are used; did I miss some other reason? Paul. From michel.salim at gmail.com Tue Nov 28 15:11:12 2006 From: michel.salim at gmail.com (Michel Salim) Date: Tue, 28 Nov 2006 10:11:12 -0500 Subject: Unorphaning wbxml2 In-Reply-To: <200611281233.46302@rineau.schtroumpfette> References: <200611271707.02208@rineau.schtroumpfette> <883cfe6d0611272144p3d3d510eyc9ba4126244249ee@mail.gmail.com> <200611281233.46302@rineau.schtroumpfette> Message-ID: <883cfe6d0611280711j11139c8doe2a7d36cde65ce79@mail.gmail.com> 2006/11/28, Laurent Rineau : > On Tuesday 28 November 2006 06:44, Michel Salim wrote: > > 2006/11/27, Laurent Rineau : > > > I am taking the ownership of *wbxml2*, which is a retired package > > > (because its maintainer could not sign the Fedora CLA due to its company > > > policy). > > > > Nice. I was contemplating maintaining it, because it's needed by the > > SyncML plugin for libopensync, but that plugin is not > > production-quality yet, unfortunately. > > Would you like to co-maintain it, as well as SyncML? > Certainly. I'll have more time for it two weeks from now (end of semester approaching). Regards, -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From pertusus at free.fr Tue Nov 28 15:13:58 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 28 Nov 2006 16:13:58 +0100 Subject: New Comps Groups In-Reply-To: <456C4EED.2010100@city-fan.org> References: <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <1164661131.22125.106.camel@aglarond.local> <1164667559.3195.14.camel@rousalka.dyndns.org> <456C1735.2020706@city-fan.org> <20061128133422.GA23075@jadzia.bu.edu> <456C3B96.8040208@city-fan.org> <1164721772.3640.1.camel@golem.boston.devel.redhat.com> <456C4EED.2010100@city-fan.org> Message-ID: <20061128151358.GC3447@free.fr> On Tue, Nov 28, 2006 at 02:59:57PM +0000, Paul Howarth wrote: > > The only underlying objection I recall seeing is that adding all > packages to comps presents too many choices to users, and that problem > doesn't happen if hidden groups are used; did I miss some other reason? I think there is also the time used in editing comps file. Maybe this also could be alleviated by generating some parts of the comps file automatically (for perl, python modules, and -devel packages, for example). -- Pat From michel.salim at gmail.com Tue Nov 28 15:14:47 2006 From: michel.salim at gmail.com (Michel Salim) Date: Tue, 28 Nov 2006 10:14:47 -0500 Subject: Adding (parts of) gstreamer-plugins-bad to FE? In-Reply-To: <456B3568.7020903@hhs.nl> References: <456850B2.2050402@hhs.nl> <20061127165608.GI29814@nostromo.devel.redhat.com> <456B3568.7020903@hhs.nl> Message-ID: <883cfe6d0611280714l1f644019wbaacf930562dc780@mail.gmail.com> 2006/11/27, Hans de Goede : > > > Bill Nottingham wrote: > > Hans de Goede (j.w.r.degoede at hhs.nl) said: > >> qt > >> Quicktime container format support, through own gst code (no libs used), > >> this one is trouble some. I would really like to see this in FE as this > >> adds supports for videos made with many digital photo cameras to > >> gstreamer using applications (usually these camera's just dump a raw > >> audio stream and a serie of jpeg images into a .mov file. > >> > >> So where should this one go? I really don't know. Can anyone help here? > > > > I'm not 100% sure, but I believe the quicktime *container* format is open; > > it's just that most of the things put in it usually aren't. > > > > So that makes 2 votes in favor of qt container support in FE, rest > assured I'm only talking about *container* support here. > > Are there any nay-sayers? Should we pass this through legal first? (no > please). Anyone who can give a definite YES? > I'm not too familiar with the QT container format, but here's an Apple developer talking about parts of QuickTime that is patented: http://lists.xiph.org/pipermail/vorbis-dev/2001-October/004846.html Whether the patent is still valid, or whether it's implemented in gstreamer-plugins-bad, I don't know. -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From paul at city-fan.org Tue Nov 28 15:47:27 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 28 Nov 2006 15:47:27 +0000 Subject: New Comps Groups In-Reply-To: <20061128151358.GC3447@free.fr> References: <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <1164661131.22125.106.camel@aglarond.local> <1164667559.3195.14.camel@rousalka.dyndns.org> <456C1735.2020706@city-fan.org> <20061128133422.GA23075@jadzia.bu.edu> <456C3B96.8040208@city-fan.org> <1164721772.3640.1.camel@golem.boston.devel.redhat.com> <456C4EED.2010100@city-fan.org> <20061128151358.GC3447@free.fr> Message-ID: <456C5A0F.2030402@city-fan.org> Patrice Dumas wrote: > On Tue, Nov 28, 2006 at 02:59:57PM +0000, Paul Howarth wrote: >> The only underlying objection I recall seeing is that adding all >> packages to comps presents too many choices to users, and that problem >> doesn't happen if hidden groups are used; did I miss some other reason? > > I think there is also the time used in editing comps file. Maybe this also > could be alleviated by generating some parts of the comps file automatically > (for perl, python modules, and -devel packages, for example). The editing of the comps file is a one-time thing though (first import time) really, that goes along with the editing of owners.list, importing the SRPM into cvs etc. Not a big deal once the backlog of existing packages was cleared I'd have thought. Paul. From j.w.r.degoede at hhs.nl Tue Nov 28 15:51:32 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 28 Nov 2006 16:51:32 +0100 Subject: Adding (parts of) gstreamer-plugins-bad to FE? In-Reply-To: <883cfe6d0611280714l1f644019wbaacf930562dc780@mail.gmail.com> References: <456850B2.2050402@hhs.nl> <20061127165608.GI29814@nostromo.devel.redhat.com> <456B3568.7020903@hhs.nl> <883cfe6d0611280714l1f644019wbaacf930562dc780@mail.gmail.com> Message-ID: <456C5B04.3080108@hhs.nl> Michel Salim wrote: > 2006/11/27, Hans de Goede : >> >> >> Bill Nottingham wrote: >> > Hans de Goede (j.w.r.degoede at hhs.nl) said: >> >> qt >> >> Quicktime container format support, through own gst code (no libs >> used), >> >> this one is trouble some. I would really like to see this in FE as >> this >> >> adds supports for videos made with many digital photo cameras to >> >> gstreamer using applications (usually these camera's just dump a raw >> >> audio stream and a serie of jpeg images into a .mov file. >> >> >> >> So where should this one go? I really don't know. Can anyone help >> here? >> > >> > I'm not 100% sure, but I believe the quicktime *container* format is >> open; >> > it's just that most of the things put in it usually aren't. >> > >> >> So that makes 2 votes in favor of qt container support in FE, rest >> assured I'm only talking about *container* support here. >> >> Are there any nay-sayers? Should we pass this through legal first? (no >> please). Anyone who can give a definite YES? >> > I'm not too familiar with the QT container format, but here's an Apple > developer talking about parts of QuickTime that is patented: > > http://lists.xiph.org/pipermail/vorbis-dev/2001-October/004846.html > > Whether the patent is still valid, or whether it's implemented in > gstreamer-plugins-bad, I don't know. > > IANAL, but the patent referenced there if I understand the mail correctly is about optimising a file when creating one so that it can be easily streamed, that doesn't seem relevant for qt-reading code. Regards, Hans From dominik at greysector.net Tue Nov 28 15:56:17 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 28 Nov 2006 16:56:17 +0100 Subject: Adding (parts of) gstreamer-plugins-bad to FE? In-Reply-To: <883cfe6d0611280714l1f644019wbaacf930562dc780@mail.gmail.com> References: <456850B2.2050402@hhs.nl> <20061127165608.GI29814@nostromo.devel.redhat.com> <456B3568.7020903@hhs.nl> <883cfe6d0611280714l1f644019wbaacf930562dc780@mail.gmail.com> Message-ID: <20061128155617.GD19109@rathann.pekin.waw.pl> On Tuesday, 28 November 2006 at 16:14, Michel Salim wrote: > 2006/11/27, Hans de Goede : > > > > > >Bill Nottingham wrote: > >> Hans de Goede (j.w.r.degoede at hhs.nl) said: > >>> qt > >>> Quicktime container format support, through own gst code (no libs used), > >>> this one is trouble some. I would really like to see this in FE as this > >>> adds supports for videos made with many digital photo cameras to > >>> gstreamer using applications (usually these camera's just dump a raw > >>> audio stream and a serie of jpeg images into a .mov file. > >>> > >>> So where should this one go? I really don't know. Can anyone help here? > >> > >> I'm not 100% sure, but I believe the quicktime *container* format is > >open; > >> it's just that most of the things put in it usually aren't. > >> > > > >So that makes 2 votes in favor of qt container support in FE, rest > >assured I'm only talking about *container* support here. > > > >Are there any nay-sayers? Should we pass this through legal first? (no > >please). Anyone who can give a definite YES? > > > I'm not too familiar with the QT container format, but here's an Apple > developer talking about parts of QuickTime that is patented: > > http://lists.xiph.org/pipermail/vorbis-dev/2001-October/004846.html > > Whether the patent is still valid, or whether it's implemented in > gstreamer-plugins-bad, I don't know. [...] The hint track notion, (which I think is the patented part) provides a way to construct packets to stream over RTP by reading existing media data. [...] And he's not even sure about that. What patent would that be? Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jkeating at redhat.com Tue Nov 28 17:09:21 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 28 Nov 2006 12:09:21 -0500 Subject: New Comps Groups In-Reply-To: <456C4EED.2010100@city-fan.org> References: <1164721772.3640.1.camel@golem.boston.devel.redhat.com> <456C4EED.2010100@city-fan.org> Message-ID: <200611281209.21318.jkeating@redhat.com> On Tuesday 28 November 2006 09:59, Paul Howarth wrote: > > Only if you assume that it is a good idea to list all packages in comps. > > Some people disagree with that. > > The only underlying objection I recall seeing is that adding all > packages to comps presents too many choices to users, and that problem > doesn't happen if hidden groups are used; did I miss some other reason? Whats the point of adding it to comps if you're making it hidden? From my point of view, Comps is a file that tells the installer and yum what to expose to the user as installable options. Just adding all the packages to comps to be visible isn't the right thing, but if you're concerned about the packages being visible (which would be the point of putting them in comps), why add them to a hidden section? You're going to still have to answer the question at review time, should this be exposed to end users as an installable choice within a group? Whether the package gets added to a hidden group, or whether the package doesn't get added at all seems pretty irrelevant. Adding it into comps into a hidden view just is one more complicated step, makes comps generation time that much longer, and provides no improvement to end users. I'm also using comps as a method to determine what packages to gather up and put onto a CD. It really doesn't make sense to put packages on CDs that aren't installable options, or aren't deps of installable options. My tool reads comps for packages, then depsolves, and then spins CDs based on the results. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Tue Nov 28 17:11:22 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 28 Nov 2006 12:11:22 -0500 Subject: New Comps Groups In-Reply-To: <200611281209.21318.jkeating@redhat.com> References: <1164721772.3640.1.camel@golem.boston.devel.redhat.com> <456C4EED.2010100@city-fan.org> <200611281209.21318.jkeating@redhat.com> Message-ID: <20061128171122.GA587@jadzia.bu.edu> On Tue, Nov 28, 2006 at 12:09:21PM -0500, Jesse Keating wrote: > Whats the point of adding it to comps if you're making it hidden? From my > point of view, Comps is a file that tells the installer and yum what to Going in circles here. The point would be to have them listed *somewhere*, so you can tell the difference between "intentionally not made visible" and "forgot to consider if this should be categorized". I'm not sure this is the right approach, just explaining. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Tue Nov 28 17:21:50 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 28 Nov 2006 12:21:50 -0500 Subject: New Comps Groups In-Reply-To: <20061128171122.GA587@jadzia.bu.edu> References: <200611281209.21318.jkeating@redhat.com> <20061128171122.GA587@jadzia.bu.edu> Message-ID: <200611281221.50373.jkeating@redhat.com> On Tuesday 28 November 2006 12:11, Matthew Miller wrote: > Going in circles here. The point would be to have them listed *somewhere*, > so you can tell the difference between "intentionally not made visible" and > "forgot to consider if this should be categorized". > > I'm not sure this is the right approach, just explaining. Sure. They're listed in owners (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Tue Nov 28 17:31:53 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 28 Nov 2006 08:31:53 -0900 Subject: Anyone seeing problems with cvs-import.sh? In-Reply-To: <20061128143015.8f62306a.bugs.michael@gmx.net> References: <604aa7910611280119u2094ee1qff1e3926b3df3927@mail.gmail.com> <20061128143015.8f62306a.bugs.michael@gmx.net> Message-ID: <604aa7910611280931x4727b881ufb8079ec9395e7da@mail.gmail.com> On 11/28/06, Michael Schwendt wrote: > If you can't upload the tarball with "make new-sources FILES=..." either, > maybe your certificate has expired. In that case generate a new one via > the accounts system. I thought about the cert being expired, so I did generate a new one. I'll attempt the make new-sources command tonite. -jef From notting at redhat.com Tue Nov 28 18:06:50 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 28 Nov 2006 13:06:50 -0500 Subject: pacakge classification and selection (was Re: New Comps Groups) In-Reply-To: <1164672066.3195.76.camel@rousalka.dyndns.org> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <1164661131.22125.106.camel@aglarond.local> <1164669540.28835.20.camel@aglarond.local> <1164672066.3195.76.camel@rousalka.dyndns.org> Message-ID: <20061128180650.GH4246@nostromo.devel.redhat.com> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > Well, maybe comps was not intended to be a lot of things, but when it > was decided not to fix rpm groups and use comps as the only > classification method of yum repositories, comps graduated to another > level. Then perhaps it's time to revisit that problem. (insert dream sequence music here) Say I'm a generic Fedora user. I want to install a music player. I fire up the software tool. I now have the choice of *78* different packages under sound and video. First, I have to sort through the packages that aren't music players, by reading to see what they are... -'A Better CD Encoder'? No. - 'Audio mixer that uses ncurses'? No. And what's a ncurses? - 'An AdLib (OPL2) music player'? Maybe that's what I want - I wonder what AdLib is? Is that like an iPod? - 'Rewrite of the xawtv webcam app, which adds imlib2 support'? Why do I care? - 'The Jack Audio Connection Kit'? Well, I'm sure that means something to someone. Now, that I can sort of pick out 10-20 packages that might be want I want, how can I make a good decision? How do I choose between 'Media player for KDE' 'Xine-based media player' 'Multimedia applications for the K Desktop Environment' 'Music Management Application' 'Free multimedia player' 'The X MultiMedia System, a media player' Ideally, I'd get information like screenshots, user ratings, reviews, descriptions of specific features. But that's all the information I have. So I sit there confused, pick one at random, or install them all. I then hop on my handy dandy Fedora forum somewhere, and ask why one of them doesn't work for me, and someone says: don't use that, that sucks! why would you pick that! And I am now sad. And that's *with* a list of culled and vetted packages. Perhaps I could use the 'search' interface for packages. So I search for 'music player'. It includes some of the same results (but not most of them, including pretty much any that you'd want), and such gems as: hfsplus-tools - Tools to create/check Apple HFS+ filesystems Yes, that's it! (As an aside, I'd say that if you wanted a text-based mixer, searching for 'text mixer' is an infinitely better way to do it than browsing a list for aumix. And the search doesn't find it.) Let's try a different example. I'm a python coder, and I want to find a library for doing cryptography and hashing - MD5, SSL, etc. So, I go to the 'Python Development' Group in pirut. I scroll through the list, looking for something that looks relevant. (See above). This is even better now, because there are 500 sets of python bindings. Ideally, we'd have a browsing interface that states things like: API Categories: Network connections Cryptography Graphics Processing Applied Math Besides Those Two Non-Applied Math Math Is Hard - Shopping Cart Handling and each of them would have links to various packages, which would include: - API reference - API/ABI stability - standardization (is this core python? Is it in the LSB? Is it a recommended API by Fedora) - reviews, examples, etc. Again, comps does not help you here. Now, I could search, again. But "python crypto" yields nothing. So, in short, I think the comps push, while fitting in our current infrastructure, isn't really solving the *right* problem. We need a better interface... something like Amazon or freshmeat or . And, we need better search. Right now, it looks like it's doing direct globs without wildcards - i.e., if you enter 'foo bar' on a line, it needs to match *exactly* 'foo bar' in either the summary or description. Ideally, it should be more like google - split the query into words, find what matches those words, sort by number of words matched and proximity. Simple google-like matching (+,-, quoting) would make it simpler, and fit the methods people are used to. Bill From jamatos at fc.up.pt Tue Nov 28 18:12:37 2006 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Tue, 28 Nov 2006 18:12:37 +0000 Subject: pacakge classification and selection (was Re: New Comps Groups) In-Reply-To: <20061128180650.GH4246@nostromo.devel.redhat.com> References: <1164672066.3195.76.camel@rousalka.dyndns.org> <20061128180650.GH4246@nostromo.devel.redhat.com> Message-ID: <200611281812.37962.jamatos@fc.up.pt> On Tuesday 28 November 2006 6:06 pm, Bill Nottingham wrote: > So, in short, I think the comps push, while fitting in our current > infrastructure, isn't really solving the *right* problem. We need a > better interface... something like Amazon or freshmeat or handwaving>. I could not agree more. -- Jos? Ab?lio From chris.stone at gmail.com Tue Nov 28 18:15:51 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 28 Nov 2006 10:15:51 -0800 Subject: pacakge classification and selection (was Re: New Comps Groups) In-Reply-To: <20061128180650.GH4246@nostromo.devel.redhat.com> References: <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <1164661131.22125.106.camel@aglarond.local> <1164669540.28835.20.camel@aglarond.local> <1164672066.3195.76.camel@rousalka.dyndns.org> <20061128180650.GH4246@nostromo.devel.redhat.com> Message-ID: On 11/28/06, Bill Nottingham wrote: > So, in short, I think the comps push, while fitting in our current > infrastructure, isn't really solving the *right* problem. We need a > better interface... something like Amazon or freshmeat or handwaving>. I seem to recall some discussion a while back about replacing owners.list with a database, perhaps this could be the first step in this direction. We could add keywords to each package which a user could search. From katzj at redhat.com Tue Nov 28 18:57:41 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 28 Nov 2006 13:57:41 -0500 Subject: New Comps Groups In-Reply-To: <1164672066.3195.76.camel@rousalka.dyndns.org> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <1164661131.22125.106.camel@aglarond.local> <1164669540.28835.20.camel@aglarond.local> <1164672066.3195.76.camel@rousalka.dyndns.org> Message-ID: <1164740261.7713.21.camel@aglarond.local> On Tue, 2006-11-28 at 01:01 +0100, Nicolas Mailhot wrote: > Le lundi 27 novembre 2006 ? 18:19 -0500, Jeremy Katz a ?crit : > > The problem is that you're using the argument of "all packages need to > > be in comps, so we need to add groups" when comps was _never_ intended > > to be an exhaustive list of every package. > > Well, maybe comps was not intended to be a lot of things, but when it > was decided not to fix rpm groups and use comps as the only > classification method of yum repositories, comps graduated to another > level. Who said only? comps provides a browsing interface for things which are "interesting"... there are lots of other criteria that are interesting and good to explore. repoview gives one, for example. And the key is that with everything sitting on top of the same infrastructure, if someone comes up with something that works better, it's relatively easy to adopt it. comps is about browsing and finding interesting things. Not (fundamentally) about classification. > > You'd be better off solving that problem with a) include it as a > > step in the review process and b) integration with the push scripts to > > provide notification/questioning when a new package is added to the > > repository and isn't listed in comps. > > This may scale at the redhat level but in a community context it > doesn't. Automation is a lifesaver. So, how do the rest of the package review steps which are manual work? Why is it hard to hook into an automated script and send an automated nag mail (heck, it could even auto-file a bug!) Jeremy From michel.salim at gmail.com Tue Nov 28 18:59:19 2006 From: michel.salim at gmail.com (Michel Salim) Date: Tue, 28 Nov 2006 13:59:19 -0500 Subject: Adding (parts of) gstreamer-plugins-bad to FE? In-Reply-To: <456C5B04.3080108@hhs.nl> References: <456850B2.2050402@hhs.nl> <20061127165608.GI29814@nostromo.devel.redhat.com> <456B3568.7020903@hhs.nl> <883cfe6d0611280714l1f644019wbaacf930562dc780@mail.gmail.com> <456C5B04.3080108@hhs.nl> Message-ID: <883cfe6d0611281059l71e11190o487b58738e60a384@mail.gmail.com> 2006/11/28, Hans de Goede : > > > Michel Salim wrote: > > 2006/11/27, Hans de Goede : > >> > >> > >> Bill Nottingham wrote: > >> > Hans de Goede (j.w.r.degoede at hhs.nl) said: > >> >> qt > >> >> Quicktime container format support, through own gst code (no libs > >> used), > >> >> this one is trouble some. I would really like to see this in FE as > >> this > >> >> adds supports for videos made with many digital photo cameras to > >> >> gstreamer using applications (usually these camera's just dump a raw > >> >> audio stream and a serie of jpeg images into a .mov file. > >> >> > >> >> So where should this one go? I really don't know. Can anyone help > >> here? > >> > > >> > I'm not 100% sure, but I believe the quicktime *container* format is > >> open; > >> > it's just that most of the things put in it usually aren't. > >> > > >> > >> So that makes 2 votes in favor of qt container support in FE, rest > >> assured I'm only talking about *container* support here. > >> > >> Are there any nay-sayers? Should we pass this through legal first? (no > >> please). Anyone who can give a definite YES? > >> > > I'm not too familiar with the QT container format, but here's an Apple > > developer talking about parts of QuickTime that is patented: > > > > http://lists.xiph.org/pipermail/vorbis-dev/2001-October/004846.html > > > > Whether the patent is still valid, or whether it's implemented in > > gstreamer-plugins-bad, I don't know. > > > > > > IANAL, but the patent referenced there if I understand the mail correctly is about optimising a file when creating one so that it can be easily streamed, that doesn't seem relevant for qt-reading code. > Ah, true. In that case, I'm all for having more Gstreamer plugins made available out-of-the-box. Is the intention to put them in one RPM or split them out one-per-plugin? The former seems better, but what do you want to call it - gstreamer-plugins-not-so-bad does not really appeal. Regards, -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From mihamina.rakotomandimby at etu.univ-orleans.fr Tue Nov 28 19:19:29 2006 From: mihamina.rakotomandimby at etu.univ-orleans.fr (Mihamina Rakotomandimby) Date: Tue, 28 Nov 2006 20:19:29 +0100 Subject: Mioga2 on Fedora Core 5 (or 6) Message-ID: <1164741569.4740.12.camel@r4000> Hi, I am going to install Mioga2 on a fedora core 5 box, using a full rpm installation. I am going to build missing RPMs. Is there any volunteers to work together with me? Thank you. We will work on this list (mioga2 install list [1]) to discuss on the spec file. I made some search, I found no old spec file to start with. We will start from scratch, then. [1] Just send an empty mail to install-subscribe at mioga2.org to subscribe. From nicolas.mailhot at laposte.net Tue Nov 28 19:22:54 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 28 Nov 2006 20:22:54 +0100 Subject: New Comps Groups In-Reply-To: <20061128151358.GC3447@free.fr> References: <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <1164661131.22125.106.camel@aglarond.local> <1164667559.3195.14.camel@rousalka.dyndns.org> <456C1735.2020706@city-fan.org> <20061128133422.GA23075@jadzia.bu.edu> <456C3B96.8040208@city-fan.org> <1164721772.3640.1.camel@golem.boston.devel.redhat.com> <456C4EED.2010100@city-fan.org> <20061128151358.GC3447@free.fr> Message-ID: <1164741775.22549.20.camel@rousalka.dyndns.org> Le mardi 28 novembre 2006 ? 16:13 +0100, Patrice Dumas a ?crit : > On Tue, Nov 28, 2006 at 02:59:57PM +0000, Paul Howarth wrote: > > > > The only underlying objection I recall seeing is that adding all > > packages to comps presents too many choices to users, and that problem > > doesn't happen if hidden groups are used; did I miss some other reason? > > I think there is also the time used in editing comps file. How is adding one line per package in a comps file time consuming ? It's far less time consuming than manually checking all the packages not present there. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Tue Nov 28 19:31:51 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 28 Nov 2006 20:31:51 +0100 Subject: New Comps Groups In-Reply-To: <200611281209.21318.jkeating@redhat.com> References: <1164721772.3640.1.camel@golem.boston.devel.redhat.com> <456C4EED.2010100@city-fan.org> <200611281209.21318.jkeating@redhat.com> Message-ID: <1164742312.22549.30.camel@rousalka.dyndns.org> Le mardi 28 novembre 2006 ? 12:09 -0500, Jesse Keating a ?crit : > On Tuesday 28 November 2006 09:59, Paul Howarth wrote: > > > Only if you assume that it is a good idea to list all packages in comps. > > > Some people disagree with that. > > > > The only underlying objection I recall seeing is that adding all > > packages to comps presents too many choices to users, and that problem > > doesn't happen if hidden groups are used; did I miss some other reason? > > Whats the point of adding it to comps if you're making it hidden? The point is, people can classify properly packages, and apps choose to show more or less groups depending on the target audience. For example repoview will typically show all groups, anaconda the most important ones, yum something in between > You're going to still have to answer the > question at review time, Actually one of the big arguments of the comps vs rpm group crowd was that comps classification could happen at a different level than the packaging. If we want to bolt compsifying so hard to packages at review time, I don't see the point of choosing an out-of-package metadata format > Adding it into comps into a hidden view just is one more > complicated step, makes comps generation time that much longer, and provides > no improvement to end users. I can only strongly disagree with every single statement in this ? > I'm also using comps as a method to determine what packages to gather up and > put onto a CD. It really doesn't make sense to put packages on CDs that > aren't installable options, or aren't deps of installable options. My tool > reads comps for packages, then depsolves, and then spins CDs based on the > results. Well your tool only needs to learn selecting a group subset, which you'll have to anyway, as the Fedora universe is quickly moving out of single-disc space. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Tue Nov 28 19:36:01 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 28 Nov 2006 20:36:01 +0100 Subject: pacakge classification and selection (was Re: New Comps Groups) In-Reply-To: <200611281812.37962.jamatos@fc.up.pt> References: <1164672066.3195.76.camel@rousalka.dyndns.org> <20061128180650.GH4246@nostromo.devel.redhat.com> <200611281812.37962.jamatos@fc.up.pt> Message-ID: <1164742562.22549.34.camel@rousalka.dyndns.org> > On Tuesday 28 November 2006 6:06 pm, Bill Nottingham wrote: > > So, in short, I think the comps push, while fitting in our current > > infrastructure, isn't really solving the *right* problem. It's kind'of sad we've replaced a strictly hierarchical system (rpm groups) with another strictly hierarchical system (well, not 100% hierarchical as you can fill packages in several groups but that's almost never done), and that after all the noise around loosely organised keywords being the future -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jkeating at redhat.com Tue Nov 28 19:52:58 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 28 Nov 2006 14:52:58 -0500 Subject: New Comps Groups In-Reply-To: <1164742312.22549.30.camel@rousalka.dyndns.org> References: <200611281209.21318.jkeating@redhat.com> <1164742312.22549.30.camel@rousalka.dyndns.org> Message-ID: <200611281452.58273.jkeating@redhat.com> On Tuesday 28 November 2006 14:31, Nicolas Mailhot wrote: > The point is, people can classify properly packages, and apps choose to > show more or less groups depending on the target audience. > > For example repoview will typically show all groups, anaconda the most > important ones, yum something in between But your hiding the package so NO tool will see it. What is the point there? > > You're going to still have to answer the > > question at review time, > > Actually one of the big arguments of the comps vs rpm group crowd was > that comps classification could happen at a different level than the > packaging. If we want to bolt compsifying so hard to packages at review > time, I don't see the point of choosing an out-of-package metadata > format I'm the one making that argument. Package grouping is really dependent upon the people putting together the repository and the metadata. I want to be able to take the built packages, put them in another repo with a different comps file that groups them how _I_ see fit, and how my users will see fit, which may be vastly different from how upstream Fedora sees fit. Forcing it into the package itself locks downstream into one narrow view of the package grouping. > > Adding it into comps into a hidden view just is one more > > complicated step, makes comps generation time that much longer, and > > provides no improvement to end users. > > I can only strongly disagree with every single statement in this ? > > > I'm also using comps as a method to determine what packages to gather up > > and put onto a CD. ?It really doesn't make sense to put packages on CDs > > that aren't installable options, or aren't deps of installable options. > > ?My tool reads comps for packages, then depsolves, and then spins CDs > > based on the results. > > Well your tool only needs to learn selecting a group subset, which > you'll have to anyway, as the Fedora universe is quickly moving out of > single-disc space. What file my tool uses in the future is to be decided, but the idea now is that you can create your _own_ comps file and group things how _you_ want them grouped for _your_ spin of Fedora. Yes, there will still need to be something of a 'master' comps file so that tools that choose to point back to the Fedora freeverse of packages will still get proper groupings, but even then just dropping all packages as hidden in comps HELPS NOTHING! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Tue Nov 28 20:15:59 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 28 Nov 2006 15:15:59 -0500 Subject: New Comps Groups In-Reply-To: <1164740261.7713.21.camel@aglarond.local> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <1164661131.22125.106.camel@aglarond.local> <1164669540.28835.20.camel@aglarond.local> <1164672066.3195.76.camel@rousalka.dyndns.org> <1164740261.7713.21.camel@aglarond.local> Message-ID: <20061128201559.GC7567@nostromo.devel.redhat.com> Jeremy Katz (katzj at redhat.com) said: > Who said only? comps provides a browsing interface for things which are > "interesting"... there are lots of other criteria that are interesting > and good to explore. repoview gives one, for example. Isn't repoview just comps? Bill From jon at fedoraunity.org Tue Nov 28 20:25:50 2006 From: jon at fedoraunity.org (Jon Steffan) Date: Tue, 28 Nov 2006 13:25:50 -0700 Subject: Plone - Zope on Fedora Core 4 Message-ID: <456C9B4E.8020004@fedoraunity.org> Team, I've been pushing updates to plone and zope and would like to get FC4 updated as FC4 is still offered by many hosting companies. The Plone migration from 2.1.2 -> 2.5.1 does not work. So I am stuck either waiting for a patch from the Plone devs that would include a fix to get migration working or I need start a new package stream. I don't expect much from the Plone guys, they are also looking more upstream. Am I allowed to create new packages for this updated stream and leave the 'plone' and 'zope' packages as they are, maybe add some security patches that are needed. Something like 'plone-new' and 'zope-new' for FC4? Please advise. Jon From jkeating at redhat.com Tue Nov 28 20:32:50 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 28 Nov 2006 15:32:50 -0500 Subject: New Comps Groups In-Reply-To: <20061128201559.GC7567@nostromo.devel.redhat.com> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <1164740261.7713.21.camel@aglarond.local> <20061128201559.GC7567@nostromo.devel.redhat.com> Message-ID: <200611281532.50385.jkeating@redhat.com> On Tuesday 28 November 2006 15:15, Bill Nottingham wrote: > Isn't repoview just comps? Repoview can use comps or the rpm Group. Or whatever we point repoview at to group packages should we extend repoview. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Tue Nov 28 20:41:31 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 28 Nov 2006 15:41:31 -0500 Subject: New Comps Groups In-Reply-To: <20061128201559.GC7567@nostromo.devel.redhat.com> References: <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <1164661131.22125.106.camel@aglarond.local> <1164669540.28835.20.camel@aglarond.local> <1164672066.3195.76.camel@rousalka.dyndns.org> <1164740261.7713.21.camel@aglarond.local> <20061128201559.GC7567@nostromo.devel.redhat.com> Message-ID: <20061128204131.GA12089@jadzia.bu.edu> On Tue, Nov 28, 2006 at 03:15:59PM -0500, Bill Nottingham wrote: > > Who said only? comps provides a browsing interface for things which are > > "interesting"... there are lots of other criteria that are interesting > > and good to explore. repoview gives one, for example. > Isn't repoview just comps? Right now. It's not clear at all that it *should* be (although it's clear enough why it is -- use the data that you've got). -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mjc at avtechpulse.com Tue Nov 28 20:47:14 2006 From: mjc at avtechpulse.com (Dr. Michael J. Chudobiak) Date: Tue, 28 Nov 2006 15:47:14 -0500 Subject: Plone - Zope on Fedora Core 4 In-Reply-To: <456C9B4E.8020004@fedoraunity.org> References: <456C9B4E.8020004@fedoraunity.org> Message-ID: <456CA052.2020006@avtechpulse.com> Jon Steffan wrote: > Team, > > I've been pushing updates to plone and zope and would like to get > FC4 updated as FC4 is still offered by many hosting companies. The Plone > migration from 2.1.2 -> 2.5.1 does not work. So I am stuck either > waiting for a patch from the Plone devs that would include a fix to get > migration working or I need start a new package stream. I don't expect > much from the Plone guys, they are also looking more upstream. > > Am I allowed to create new packages for this updated stream and leave > the 'plone' and 'zope' packages as they are, maybe add some security > patches that are needed. Something like 'plone-new' and 'zope-new' for > FC4? Please advise. > > Jon What didn't work in the migration? There is a known problem with the 2.5.1 rpm - you have to uninstall the "Five" product and re-install the correct version (see http://comments.gmane.org/gmane.comp.web.zope.plone.user/60692). See also http://lists.plone.org/pipermail/setup/2006-November/002608.html. The zope and plone packages were orphaned a few weeks ago. I don't know what there current status is. - Mike From j.w.r.degoede at hhs.nl Tue Nov 28 21:26:53 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 28 Nov 2006 22:26:53 +0100 Subject: Adding (parts of) gstreamer-plugins-bad to FE? In-Reply-To: <883cfe6d0611281059l71e11190o487b58738e60a384@mail.gmail.com> References: <456850B2.2050402@hhs.nl> <20061127165608.GI29814@nostromo.devel.redhat.com> <456B3568.7020903@hhs.nl> <883cfe6d0611280714l1f644019wbaacf930562dc780@mail.gmail.com> <456C5B04.3080108@hhs.nl> <883cfe6d0611281059l71e11190o487b58738e60a384@mail.gmail.com> Message-ID: <456CA99D.4070803@hhs.nl> Michel Salim wrote: > 2006/11/28, Hans de Goede : >> >> >> Michel Salim wrote: >> > 2006/11/27, Hans de Goede : >> >> >> >> >> >> Bill Nottingham wrote: >> >> > Hans de Goede (j.w.r.degoede at hhs.nl) said: >> >> >> qt >> >> >> Quicktime container format support, through own gst code (no libs >> >> used), >> >> >> this one is trouble some. I would really like to see this in FE as >> >> this >> >> >> adds supports for videos made with many digital photo cameras to >> >> >> gstreamer using applications (usually these camera's just dump a >> raw >> >> >> audio stream and a serie of jpeg images into a .mov file. >> >> >> >> >> >> So where should this one go? I really don't know. Can anyone help >> >> here? >> >> > >> >> > I'm not 100% sure, but I believe the quicktime *container* format is >> >> open; >> >> > it's just that most of the things put in it usually aren't. >> >> > >> >> >> >> So that makes 2 votes in favor of qt container support in FE, rest >> >> assured I'm only talking about *container* support here. >> >> >> >> Are there any nay-sayers? Should we pass this through legal first? (no >> >> please). Anyone who can give a definite YES? >> >> >> > I'm not too familiar with the QT container format, but here's an Apple >> > developer talking about parts of QuickTime that is patented: >> > >> > http://lists.xiph.org/pipermail/vorbis-dev/2001-October/004846.html >> > >> > Whether the patent is still valid, or whether it's implemented in >> > gstreamer-plugins-bad, I don't know. >> > >> > >> >> IANAL, but the patent referenced there if I understand the mail >> correctly is about optimising a file when creating one so that it can >> be easily streamed, that doesn't seem relevant for qt-reading code. >> > Ah, true. In that case, I'm all for having more Gstreamer plugins made > available out-of-the-box. > > Is the intention to put them in one RPM or split them out > one-per-plugin? The former seems better, but what do you want to call > it - gstreamer-plugins-not-so-bad does not really appeal. > The bad references mainly to the code quality, not to licensing issues, so I'm planning on: gstreamer-plugins-bad: important bad quality plugins, destined for the new desktop CD (atleast qt if qt is admissable at all) gstreamer-plugins-bad-extras: bad quality plugins, which really aren't all that interesting like speed and pitch change plugins gstreamer-plugins-bad-extras-non-free: plugins which are both bad and ugly (licensing wise), this would go in that other repo. Regards, Hans From mattdm at mattdm.org Tue Nov 28 21:15:44 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 28 Nov 2006 16:15:44 -0500 Subject: Plone - Zope on Fedora Core 4 In-Reply-To: <456C9B4E.8020004@fedoraunity.org> References: <456C9B4E.8020004@fedoraunity.org> Message-ID: <20061128211544.GB12089@jadzia.bu.edu> On Tue, Nov 28, 2006 at 01:25:50PM -0700, Jon Steffan wrote: > I've been pushing updates to plone and zope and would like to get > FC4 updated as FC4 is still offered by many hosting companies. The Plone We need to push those hosting companies to upgrade. FC4 is not safe for server systems. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dan at danny.cz Tue Nov 28 21:42:05 2006 From: dan at danny.cz (Dan Horak) Date: Tue, 28 Nov 2006 22:42:05 +0100 Subject: build system - kill job 22533 Message-ID: <1164750125.3427.12.camel@eagle.danny.cz> Hello, please, can someone kill my job 22533, which is doing a checkout for about one hour? Running "plague-client kill 22533" has no effect. Thanks Dan From jon at fedoraunity.org Tue Nov 28 21:45:41 2006 From: jon at fedoraunity.org (Jon Steffan) Date: Tue, 28 Nov 2006 14:45:41 -0700 Subject: Plone - Zope on Fedora Core 4 In-Reply-To: <456CA052.2020006@avtechpulse.com> References: <456C9B4E.8020004@fedoraunity.org> <456CA052.2020006@avtechpulse.com> Message-ID: <456CAE05.5000104@fedoraunity.org> Dr. Michael J. Chudobiak wrote: > Jon Steffan wrote: >> Team, >> >> I've been pushing updates to plone and zope and would like to get >> FC4 updated as FC4 is still offered by many hosting companies. The Plone >> migration from 2.1.2 -> 2.5.1 does not work. So I am stuck either >> waiting for a patch from the Plone devs that would include a fix to get >> migration working or I need start a new package stream. I don't expect >> much from the Plone guys, they are also looking more upstream. >> >> Am I allowed to create new packages for this updated stream and leave >> the 'plone' and 'zope' packages as they are, maybe add some security >> patches that are needed. Something like 'plone-new' and 'zope-new' for >> FC4? Please advise. >> >> Jon > > What didn't work in the migration? * Starting the migration from version: 2.1.2 * Attempting to upgrade from: 2.1.2 * Removed vcXMLRPC.js * Reindexed portal_catalog. * Recataloged Members folder. * Added icons for copy, cut, paste and delete * Upgrade to: 2.1.3-rc1, completed * Attempting to upgrade from: 2.1.3-rc1 * Upgrade to: 2.1.3, completed * Attempting to upgrade from: 2.1.3 * Installed CMFPlacefulWorkflow. * Upgrade to: 2.5-alpha1, completed * Attempting to upgrade from: 2.5-alpha1 * Upgrade aborted * Error type: exceptions.AttributeError * Error value: has_key * File "/usr/lib/zope/lib/python/Products/CMFPlone/MigrationTool.py", line 307, in upgrade newv, msgs = self._upgrade(newv) * File "/usr/lib/zope/lib/python/Products/CMFPlone/MigrationTool.py", line 404, in _upgrade res = function(self.aq_parent) * File "/usr/lib/zope/lib/python/Products/CMFPlone/migrations/v2_5/alphas.py", line 24, in alpha1_alpha2 installPlonePAS(portal, out) * File "/usr/lib/zope/lib/python/Products/CMFPlone/migrations/v2_5/alphas.py", line 43, in installPlonePAS installOrReinstallProduct(portal, 'PlonePAS', out) * File "/usr/lib/zope/lib/python/Products/CMFPlone/migrations/migration_util.py", line 82, in installOrReinstallProduct qi.installProduct(product_name) * File "/usr/lib/zope/lib/python/Products/CMFQuickInstallerTool/QuickInstallerTool.py", line 322, in installProduct res=install(portal) * File "/usr/lib/zope/lib/python/Products/ExternalMethod/ExternalMethod.py", line 225, in __call__ try: return f(*args, **kw) * File "/usr/lib/zope/lib/python/Products/PlonePAS/Extensions/Install.py", line 843, in install restoreUserData(portal, out, userdata) * File "/usr/lib/zope/lib/python/Products/PlonePAS/Extensions/Install.py", line 328, in restoreUserData member.setMemberProperties(u[-1]) * File "/usr/lib/zope/lib/python/Products/PlonePAS/tools/memberdata.py", line 144, in setMemberProperties return BaseMemberData.setMemberProperties(self, mapping) * File "/usr/lib/zope/lib/python/Products/CMFCore/MemberDataTool.py", line 314, in setMemberProperties if mapping.has_key(id): * End of upgrade path, migration has finished * The upgrade path did NOT reach current version * Migration has failed If the acl_users folder from 2.1.2 is removed, the upgrade works. However, that is not a solution as you lose users or have to migrate them manually. > There is a known problem with the 2.5.1 rpm - you have to uninstall > the "Five" product and re-install the correct version (see > http://comments.gmane.org/gmane.comp.web.zope.plone.user/60692). Well, I fixed that. View the changelog(s). > > See also > http://lists.plone.org/pipermail/setup/2006-November/002608.html. Also, fixed. (same issue it seems) > > The zope and plone packages were orphaned a few weeks ago. I don't > know what there current status is. I am maintaining them now. > > - Mike > > Jonathan From dwmw2 at infradead.org Tue Nov 28 21:56:08 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 28 Nov 2006 21:56:08 +0000 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <454375C3.5020507@leemhuis.info> <20061028211022.GB19403@neu.nirvana> <1162071820.3139.39.camel@vader.jdub.homelinux.org> Message-ID: <1164750968.14595.11.camel@pmac.infradead.org> On Sat, 2006-10-28 at 15:53 -0700, Christopher Stone wrote: > I *think* the point he is trying to make is that some people don't > like 3rd party repositories overriding Fedora Extras without good > reason and some other people dont like Fedora Extras maintainers > adding packages in Fedora Extras without first consulting with the 3rd > party repositories. > > Which goes back to my original idea of having an official Fedora wiki > page that lists 3rd party repositories. Fedora Extras maintainers > could then check this wiki page to find out which repositories might > already have a package available for the package they want to submit. I don't really understand. Whenever I want a package to be available, I make sure it gets into Core or Extras? Why would I look elsewhere, except in the special case of something that goes in Livna? I'm no more interested in packages from outside Core/Extras/Livna than I am in installing Debian packages with Alien. Why is it interesting? -- dwmw2 From jamatos at fc.up.pt Tue Nov 28 22:47:41 2006 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Tue, 28 Nov 2006 22:47:41 +0000 Subject: New Comps Groups In-Reply-To: <20061127133729.GA28307@jadzia.bu.edu> References: <200611271125.48568.jamatos@fc.up.pt> <20061127133729.GA28307@jadzia.bu.edu> Message-ID: <200611282247.42176.jamatos@fc.up.pt> On Monday 27 November 2006 1:37 pm, Matthew Miller wrote: > On Mon, Nov 27, 2006 at 11:25:48AM +0000, Jos? Matos wrote: > > Can I ask for R development? :-) > > Shouldn't this go in "Math and Statistics" or somesuch? Something like <_name>Engineering and Scientific? That group has so many entries that it is useless, IMHO. > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> -- Jos? Ab?lio From seg at haxxed.com Wed Nov 29 05:34:33 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 28 Nov 2006 23:34:33 -0600 Subject: pacakge classification and selection (was Re: New Comps Groups) In-Reply-To: <20061128180650.GH4246@nostromo.devel.redhat.com> References: <20061127170220.GM29814@nostromo.devel.redhat.com> <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <1164661131.22125.106.camel@aglarond.local> <1164669540.28835.20.camel@aglarond.local> <1164672066.3195.76.camel@rousalka.dyndns.org> <20061128180650.GH4246@nostromo.devel.redhat.com> Message-ID: <1164778474.5452.91.camel@max.booze> On Tue, 2006-11-28 at 13:06 -0500, Bill Nottingham wrote: > Ideally, I'd get information like screenshots, user ratings, reviews, > descriptions of specific features. But that's all the information I have. > So I sit there confused, pick one at random, or install them all. I > then hop on my handy dandy Fedora forum somewhere, and ask why one of them > doesn't work for me, and someone says: > > So, in short, I think the comps push, while fitting in our current > infrastructure, isn't really solving the *right* problem. We need a > better interface... something like Amazon or freshmeat or handwaving>. I think you're talking about Click-N-Run. Check it out: http://www.linspire.com/lindows_products_categories.php We could easily do something similar to CNR if we had the yum install list thing I proposed during the Great ESR FC5 Release Flamewar of 2006. (3-28-2006 NEVER FORGET) http://article.gmane.org/gmane.linux.redhat.fedora.devel/37254 The Extras Games SIG has a games list on the wiki, about half of which link to a dedicated page with screenshots and install instructions. This is a good start: http://fedoraproject.org/wiki/Games -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Wed Nov 29 06:41:15 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 28 Nov 2006 21:41:15 -0900 Subject: Anyone seeing problems with cvs-import.sh? In-Reply-To: <20061128143015.8f62306a.bugs.michael@gmx.net> References: <604aa7910611280119u2094ee1qff1e3926b3df3927@mail.gmail.com> <20061128143015.8f62306a.bugs.michael@gmx.net> Message-ID: <604aa7910611282241j2d929fd6p198483d2a399a894@mail.gmail.com> On 11/28/06, Michael Schwendt wrote: > If you can't upload the tarball with "make new-sources FILES=..." either, > maybe your certificate has expired. In that case generate a new one via > the accounts system. And today... it just magically works without making a single system change since I tried to do it last night. -jef"I'll send this mystery in to SciFi Investages, I'm sure Boston Rob's power of deductive reasoning will solve the mystery of the cvs-import.sh errors"spaleta From paul at city-fan.org Wed Nov 29 08:59:16 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 29 Nov 2006 08:59:16 +0000 Subject: New Comps Groups In-Reply-To: <200611281452.58273.jkeating@redhat.com> References: <200611281209.21318.jkeating@redhat.com> <1164742312.22549.30.camel@rousalka.dyndns.org> <200611281452.58273.jkeating@redhat.com> Message-ID: <1164790756.30297.7.camel@metropolis.intra.city-fan.org> On Tue, 2006-11-28 at 14:52 -0500, Jesse Keating wrote: > On Tuesday 28 November 2006 14:31, Nicolas Mailhot wrote: > > The point is, people can classify properly packages, and apps choose to > > show more or less groups depending on the target audience. > > > > For example repoview will typically show all groups, anaconda the most > > important ones, yum something in between > > But your hiding the package so NO tool will see it. What is the point there? The point is to be able to distinguish in a machine-parsable way the difference between a package whose owner thinks that its purpose is as a dependency of other packages and hence doesn't need to be visible to users at package selection time (this sort of package would be in a hidden group in the master comps file) and a package whose owner hasn't thought about classification or has forgotten to enter the package in the comps file for any other reason (such a package wouldn't be in the master comps file at all). This allows easy checking for the latter case by scripts (and subsequent nag mails or bug reports), which is not currently possible. Paul. From paul at city-fan.org Wed Nov 29 09:10:02 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 29 Nov 2006 09:10:02 +0000 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1164750968.14595.11.camel@pmac.infradead.org> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <454375C3.5020507@leemhuis.info> <20061028211022.GB19403@neu.nirvana> <1162071820.3139.39.camel@vader.jdub.homelinux.org> <1164750968.14595.11.camel@pmac.infradead.org> Message-ID: <1164791402.30297.15.camel@metropolis.intra.city-fan.org> On Tue, 2006-11-28 at 21:56 +0000, David Woodhouse wrote: > On Sat, 2006-10-28 at 15:53 -0700, Christopher Stone wrote: > > I *think* the point he is trying to make is that some people don't > > like 3rd party repositories overriding Fedora Extras without good > > reason and some other people dont like Fedora Extras maintainers > > adding packages in Fedora Extras without first consulting with the 3rd > > party repositories. > > > > Which goes back to my original idea of having an official Fedora wiki > > page that lists 3rd party repositories. Fedora Extras maintainers > > could then check this wiki page to find out which repositories might > > already have a package available for the package they want to submit. > > I don't really understand. Whenever I want a package to be available, I > make sure it gets into Core or Extras? Why would I look elsewhere, > except in the special case of something that goes in Livna? > > I'm no more interested in packages from outside Core/Extras/Livna than I > am in installing Debian packages with Alien. Why is it interesting? End users may already be using packages from third-party repos, and may have issues if new and incompatible packages of those applications subsequently appear in Extras. The Extras packager could save their potential users some grief if they took notice of what's already available elsewhere and tried to avoid breaking upgrade paths between their package and others' (and vice versa). Of course if the third-party packager has done something stupid with their package, it doesn't mean that the Extras packager should follow suit, but at least as a courtesy to users try to avoid breaking things unnecessarily. Paul. From buildsys at fedoraproject.org Wed Nov 29 10:54:37 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 29 Nov 2006 05:54:37 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-29 Message-ID: <20061129105437.62B5515212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 25 VLGothic-fonts-20061026-4.fc7 allegro-4.2.1-1.fc7 digikam-0.9.0-0.2.rc1.fc7 exiv2-0.12-1.fc7 glest-2.0.0-2.fc7 glest-data-2.0.0-2.fc7 gnonlin-0.10.6-1.fc7 gtkwave-3.0.17-1.fc7 heartbeat-2.0.7-4.fc7 jd-1.8.1-0.1.cvs061128.fc7 k3d-0.6.4.0-1.fc7 kphotoalbum-2.2-7.fc7 libsyncml-0.4.2-1.fc7 libtcd-2.2.0.2-1.fc7 mail-notification-4.0-0.1.fc7.rc1 memchan-2.2.1-1.fc7 njb-sharp-0.3.0-5.fc7 openvrml-0.16.1-5.fc7 rlwrap-0.28-1.fc7 ruby-bdb-0.6.0-1.fc7 ssmtp-2.61-10.fc7 tideEditor-1.3.12.0.2-1.fc7 trac-0.10.2-1.fc7 wbxml2-0.9.2-4.fc7 xfce4-session-4.3.99.2-2.fc7 Packages built and released for Fedora Extras 6: 23 Django-0.95-1.fc6 GraphicsMagick-1.1.7-2.fc6 VLGothic-fonts-20061026-4.fc6 exiv2-0.12-1.fc6 glest-2.0.0-2.fc6 glest-data-2.0.0-2.fc6 gnupg2-2.0.1-0.3.rc1.fc6 gtkwave-3.0.17-1.fc6 kaffeine-0.8.3-1.fc6 kphotoalbum-2.2-7.fc6 libassuan-1.0.1-1.fc6 libtcd-2.2.0.2-1.fc6 njb-sharp-0.3.0-5.fc6 openvrml-0.16.1-5.fc6 perl-Gtk2-Notify-0.02-4.fc6 python-alsaaudio-0.2-1.fc6 python-matplotlib-0.87.7-1.fc6 ruby-bdb-0.6.0-1.fc6 tcd-utils-20061127-1.fc6 tideEditor-1.3.12.0.2-1.fc6 trac-0.10.2-1.fc6 xfce4-session-4.3.99.2-2.fc6 xtide-2.9-0.2.date20061122.fc6 Packages built and released for Fedora Extras 5: 16 Django-0.95-1.fc5 GraphicsMagick-1.1.7-2.fc5 VLGothic-fonts-20061026-4.fc5 codeblocks-1.0-0.16.20061128svn3295.fc5 exiv2-0.12-1.fc5 gtkwave-3.0.17-1.fc5 kaffeine-0.8.3-1.fc5 kphotoalbum-2.2-7.fc5 libtcd-2.2.0.2-1.fc5 plone-2.5.1-4.fc5 ruby-bdb-0.6.0-1.fc5 tcd-utils-20061127-1.fc5 tideEditor-1.3.12.0.2-1.fc5 trac-0.10.2-1.fc5 wbxml2-0.9.2-4.fc5 zope-2.9.5-1.fc5 Packages built and released for Fedora Extras 4: 2 gtkwave-3.0.17-1.fc4 trac-0.10.2-1.fc4 Packages built and released for Fedora Extras 3: 0 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed Nov 29 11:56:18 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 29 Nov 2006 11:56:18 -0000 Subject: (1/2) Summary - Broken dependencies in Fedora Extras - 2006-11-29 Message-ID: <20061129115618.10302.67208@extras64.linux.duke.edu> New report for: kevin-redhat-bugzilla AT tummy.com package: p0f - 2.0.8-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: p0f - 2.0.8-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: p0f - 2.0.8-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 ====================================================================== New report for: rdieter AT math.unl.edu package: libmal - 0.31-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libpisock.so.8 package: libmal - 0.31-4.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libpisock.so.8 package: libmal - 0.31-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpisock.so.8()(64bit) package: libmal - 0.31-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libpisock.so.8 ====================================================================== New report for: jwilson AT redhat.com package: ip6sic - 0.1-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: zabbix - 1.1.4-2.fc7.ppc from fedora-extras-development-ppc unresolved deps: libnetsnmp.so.10 package: ip6sic - 0.1-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: zabbix - 1.1.4-2.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libnetsnmp.so.10()(64bit) package: zabbix - 1.1.4-2.fc7.i386 from fedora-extras-development-i386 unresolved deps: libnetsnmp.so.10 package: ip6sic - 0.1-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 ====================================================================== New report for: jima AT beer.tclug.org package: ngrep - 1.44-7.fc6.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: scanssh - 2.1-9.fc6.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: scanssh - 2.1-9.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: ngrep - 1.44-7.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: ngrep - 1.44-7.fc6.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 package: scanssh - 2.1-9.fc6.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 ====================================================================== New report for: dennis AT ausil.us package: snort-postgresql+flexresp - 2.6.1.1-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: snort - 2.6.1.1-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: snort-bloat - 2.6.1.1-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: snort-mysql - 2.6.1.1-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: snort-snmp+flexresp - 2.6.1.1-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: snort-snmp - 2.6.1.1-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: snort-mysql+flexresp - 2.6.1.1-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: snort-plain+flexresp - 2.6.1.1-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: snort-postgresql - 2.6.1.1-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: snort-mysql+flexresp - 2.6.1.1-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: snort-bloat - 2.6.1.1-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: snort-mysql - 2.6.1.1-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: snort-snmp - 2.6.1.1-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: snort-snmp+flexresp - 2.6.1.1-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: snort-postgresql+flexresp - 2.6.1.1-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: snort - 2.6.1.1-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: snort-plain+flexresp - 2.6.1.1-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: snort-postgresql - 2.6.1.1-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: snort-snmp - 2.6.1.1-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 package: snort-snmp+flexresp - 2.6.1.1-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 package: snort-mysql+flexresp - 2.6.1.1-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 package: snort-mysql - 2.6.1.1-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 package: snort-bloat - 2.6.1.1-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 package: snort - 2.6.1.1-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 package: snort-postgresql - 2.6.1.1-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 package: snort-plain+flexresp - 2.6.1.1-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 package: snort-postgresql+flexresp - 2.6.1.1-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 ====================================================================== New report for: pertusus AT free.fr package: intuitively - 0.7-10.fc6.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: intuitively - 0.7-10.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: intuitively - 0.7-10.fc6.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 ====================================================================== New report for: paul AT xelerance.com package: hping3 - 0.0.20051105-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: hping3 - 0.0.20051105-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: hping3 - 0.0.20051105-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 ====================================================================== New report for: bnocera AT redhat.com package: driftnet - 0.1.6-11.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: driftnet - 0.1.6-11.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: driftnet - 0.1.6-11.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 ====================================================================== New report for: jpo AT di.uminho.pt package: nagios-plugins-snmp-disk-proc - 1.0-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libnetsnmp.so.10 package: nagios-plugins-snmp-disk-proc - 1.0-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libnetsnmp.so.10()(64bit) package: nagios-plugins-snmp-disk-proc - 1.0-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libnetsnmp.so.10 ====================================================================== New report for: somlo AT cmu.edu package: argus - 2.0.6.fixes.1-12.fc6.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: argus - 2.0.6.fixes.1-12.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: argus - 2.0.6.fixes.1-12.fc6.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 ====================================================================== New report for: joost.soeterbroek AT gmail.com package: stonith - 2.0.7-4.fc7.ppc from fedora-extras-development-ppc unresolved deps: libnetsnmp.so.10 package: stonith - 2.0.7-4.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libnetsnmp.so.10 package: stonith - 2.0.7-4.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libnetsnmp.so.10()(64bit) package: stonith - 2.0.7-4.fc7.i386 from fedora-extras-development-i386 unresolved deps: libnetsnmp.so.10 ====================================================================== New report for: andreas AT bawue.net package: GraphicsMagick-c++-devel - 1.1.7-2.fc6.ppc from fedora-extras-6-ppc unresolved deps: GraphicsMagick-devel = 0:1.1.72.fc6 package: GraphicsMagick-c++-devel - 1.1.7-2.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: GraphicsMagick-devel = 0:1.1.72.fc6 package: GraphicsMagick-c++-devel - 1.1.7-2.fc6.i386 from fedora-extras-6-i386 unresolved deps: GraphicsMagick-devel = 0:1.1.72.fc6 package: GraphicsMagick-c++-devel - 1.1.7-2.fc5.ppc from fedora-extras-5-ppc unresolved deps: GraphicsMagick-devel = 0:1.1.72.fc5 package: GraphicsMagick-c++-devel - 1.1.7-2.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: GraphicsMagick-devel = 0:1.1.72.fc5 package: GraphicsMagick-c++-devel - 1.1.7-2.fc5.i386 from fedora-extras-5-i386 unresolved deps: GraphicsMagick-devel = 0:1.1.72.fc5 ====================================================================== New report for: gauret AT free.fr package: gwenview - 1.4.1-2.fc7.ppc from fedora-extras-development-ppc unresolved deps: libexiv2-0.11.so package: iftop - 0.17-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: iftop - 0.17-3.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: gwenview - 1.4.1-2.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libexiv2-0.11.so()(64bit) package: iftop - 0.17-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 package: gwenview - 1.4.1-2.fc7.i386 from fedora-extras-development-i386 unresolved deps: libexiv2-0.11.so package: gwenview - 1.4.1-2.fc6.ppc from fedora-extras-6-ppc unresolved deps: libexiv2-0.11.so package: gwenview - 1.4.1-2.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: libexiv2-0.11.so()(64bit) package: gwenview - 1.4.1-2.fc6.i386 from fedora-extras-6-i386 unresolved deps: libexiv2-0.11.so ====================================================================== New report for: matthias AT rpmforge.net package: ucarp - 1.2-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: ucarp - 1.2-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: ucarp - 1.2-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: libopensync-plugin-palm - 0.19-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libpisock.so.8 package: nessus-client - 2.2.7-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: nessus-server - 2.2.7-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: libnasl - 2.2.8-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: airsnort - 0.2.7e-10.fc6.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: nessus-gui - 2.2.7-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: sylpheed-claws - 2.6.0-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libpisock.so.8 package: centericq - 4.21.0-8.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: nessus-gui - 2.2.7-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: libnasl - 2.2.8-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: sylpheed-claws - 2.6.0-1.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libpisock.so.8 package: nessus-server - 2.2.7-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: airsnort - 0.2.7e-10.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: centericq - 4.21.0-8.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: sylpheed-claws - 2.6.0-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpisock.so.8()(64bit) package: libopensync-plugin-palm - 0.19-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libpisock.so.8 package: libopensync-plugin-palm - 0.19-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpisock.so.8()(64bit) package: nessus-client - 2.2.7-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: libnasl - 2.2.8-2.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4 package: sylpheed-claws - 2.6.0-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libpisock.so.8 package: libnasl - 2.2.8-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 package: nessus-client - 2.2.7-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 package: nessus-gui - 2.2.7-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 package: nessus-server - 2.2.7-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 package: airsnort - 0.2.7e-10.fc6.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 package: centericq - 4.21.0-8.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 package: libopensync-plugin-palm - 0.19-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libpisock.so.8 ====================================================================== New report for: mtasaka AT ioa.s.u-tokyo.ac.jp package: tideEditor - 1.3.12.0.2-1.fc5.ppc from fedora-extras-5-ppc unresolved deps: xtide-common package: tideEditor - 1.3.12.0.2-1.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: xtide-common package: tideEditor - 1.3.12.0.2-1.fc5.i386 from fedora-extras-5-i386 unresolved deps: xtide-common ====================================================================== New report for: mgarski AT post.pl package: digikam-doc - 0.8.2-3.fc6.noarch from fedora-extras-development-ppc unresolved deps: digikam = 0:0.8.2 package: digikam-doc - 0.8.2-3.fc6.noarch from fedora-extras-development-x86_64 unresolved deps: digikam = 0:0.8.2 package: digikam-doc - 0.8.2-3.fc6.noarch from fedora-extras-development-i386 unresolved deps: digikam = 0:0.8.2 ====================================================================== New report for: tibbs AT math.uh.edu package: lft - 1:2.5-6.fc6.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: lft - 1:2.5-6.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: lft - 1:2.5-6.fc6.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 ====================================================================== New report for: orion AT cora.nwra.com package: apcupsd - 3.12.4-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libnetsnmp.so.10 package: apcupsd-cgi - 3.12.4-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libnetsnmp.so.10 package: apcupsd-cgi - 3.12.4-3.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libnetsnmp.so.10()(64bit) package: apcupsd - 3.12.4-3.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libnetsnmp.so.10()(64bit) package: apcupsd-cgi - 3.12.4-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: libnetsnmp.so.10 package: apcupsd - 3.12.4-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: libnetsnmp.so.10 ====================================================================== New report for: redhat-bugzilla AT linuxnetz.de package: tcpick - 0.2.1-10.fc6.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: tcpick - 0.2.1-10.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) package: tcpick - 0.2.1-10.fc6.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 ====================================================================== New report for: jdennis AT redhat.com package: cyrus-imapd - 2.3.7-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libnetsnmpmibs.so.10 libnetsnmphelpers.so.10 libnetsnmp.so.10 libnetsnmpagent.so.10 package: cyrus-imapd - 2.3.7-4.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libnetsnmpmibs.so.10 libnetsnmphelpers.so.10 libnetsnmp.so.10 libnetsnmpagent.so.10 package: cyrus-imapd - 2.3.7-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libnetsnmpmibs.so.10()(64bit) libnetsnmp.so.10()(64bit) libnetsnmphelpers.so.10()(64bit) libnetsnmpagent.so.10()(64bit) package: cyrus-imapd - 2.3.7-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libnetsnmpmibs.so.10 libnetsnmphelpers.so.10 libnetsnmp.so.10 libnetsnmpagent.so.10 ====================================================================== New report for: lmacken AT redhat.com package: xprobe2 - 0.3-8.fc6.ppc from fedora-extras-development-ppc unresolved deps: libpcap.so.0.9.4 package: xprobe2 - 0.3-8.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpcap.so.0.9.4()(64bit) From buildsys at fedoraproject.org Wed Nov 29 11:56:19 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 29 Nov 2006 11:56:19 -0000 Subject: (2/2) Summary - Broken dependencies in Fedora Extras - 2006-11-29 Message-ID: <20061129115619.10302.65880@extras64.linux.duke.edu> package: xprobe2 - 0.3-8.fc6.i386 from fedora-extras-development-i386 unresolved deps: libpcap.so.0.9.4 ====================================================================== Summary of broken packages (by owner): Jochen AT herr-schmitt.de blender - 2.42a-5.fc7.i386 (6 days) blender - 2.42a-5.fc7.ppc (6 days) blender - 2.42a-5.fc7.x86_64 (6 days) andreas.bierfert AT lowlatency.de airsnort - 0.2.7e-10.fc6.i386 airsnort - 0.2.7e-10.fc6.ppc airsnort - 0.2.7e-10.fc6.x86_64 centericq - 4.21.0-8.fc6.i386 (29 days) centericq - 4.21.0-8.fc6.ppc (29 days) centericq - 4.21.0-8.fc6.x86_64 (29 days) libnasl - 2.2.8-2.fc6.i386 libnasl - 2.2.8-2.fc6.i386 libnasl - 2.2.8-2.fc6.ppc libnasl - 2.2.8-2.fc6.x86_64 libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (32 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (32 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (32 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (32 days) libopensync-plugin-palm - 0.19-1.fc6.i386 libopensync-plugin-palm - 0.19-1.fc6.i386 libopensync-plugin-palm - 0.19-1.fc6.ppc libopensync-plugin-palm - 0.19-1.fc6.x86_64 nessus-client - 2.2.7-2.fc6.i386 nessus-client - 2.2.7-2.fc6.ppc nessus-client - 2.2.7-2.fc6.x86_64 nessus-gui - 2.2.7-2.fc6.i386 nessus-gui - 2.2.7-2.fc6.ppc nessus-gui - 2.2.7-2.fc6.x86_64 nessus-server - 2.2.7-2.fc6.i386 nessus-server - 2.2.7-2.fc6.ppc nessus-server - 2.2.7-2.fc6.x86_64 orange - 0.3-3.cvs20051118.fc6.i386 (36 days) sylpheed-claws - 2.6.0-1.fc7.i386 sylpheed-claws - 2.6.0-1.fc7.i386 sylpheed-claws - 2.6.0-1.fc7.ppc sylpheed-claws - 2.6.0-1.fc7.x86_64 sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (60 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (60 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (60 days) andreas AT bawue.net GraphicsMagick-c++-devel - 1.1.7-2.fc5.i386 GraphicsMagick-c++-devel - 1.1.7-2.fc5.ppc GraphicsMagick-c++-devel - 1.1.7-2.fc5.x86_64 GraphicsMagick-c++-devel - 1.1.7-2.fc6.i386 GraphicsMagick-c++-devel - 1.1.7-2.fc6.ppc GraphicsMagick-c++-devel - 1.1.7-2.fc6.x86_64 GraphicsMagick-c++-devel - 1.1.7-2.fc7.i386 (2 days) GraphicsMagick-c++-devel - 1.1.7-2.fc7.i386 (2 days) GraphicsMagick-c++-devel - 1.1.7-2.fc7.ppc (2 days) GraphicsMagick-c++-devel - 1.1.7-2.fc7.x86_64 (2 days) bnocera AT redhat.com driftnet - 0.1.6-11.i386 driftnet - 0.1.6-11.ppc driftnet - 0.1.6-11.x86_64 dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (75 days) plague - 0.4.4.1-2.fc3.noarch (75 days) plague - 0.4.4.1-2.fc4.noarch (75 days) plague - 0.4.4.1-2.fc4.noarch (75 days) plague - 0.4.4.1-2.fc4.noarch (75 days) dennis AT ausil.us snort - 2.6.1.1-1.fc7.i386 snort - 2.6.1.1-1.fc7.ppc snort - 2.6.1.1-1.fc7.x86_64 snort-bloat - 2.6.1.1-1.fc7.i386 snort-bloat - 2.6.1.1-1.fc7.ppc snort-bloat - 2.6.1.1-1.fc7.x86_64 snort-mysql - 2.6.1.1-1.fc7.i386 snort-mysql - 2.6.1.1-1.fc7.ppc snort-mysql - 2.6.1.1-1.fc7.x86_64 snort-mysql+flexresp - 2.6.1.1-1.fc7.i386 snort-mysql+flexresp - 2.6.1.1-1.fc7.ppc snort-mysql+flexresp - 2.6.1.1-1.fc7.x86_64 snort-plain+flexresp - 2.6.1.1-1.fc7.i386 snort-plain+flexresp - 2.6.1.1-1.fc7.ppc snort-plain+flexresp - 2.6.1.1-1.fc7.x86_64 snort-postgresql - 2.6.1.1-1.fc7.i386 snort-postgresql - 2.6.1.1-1.fc7.ppc snort-postgresql - 2.6.1.1-1.fc7.x86_64 snort-postgresql+flexresp - 2.6.1.1-1.fc7.i386 snort-postgresql+flexresp - 2.6.1.1-1.fc7.ppc snort-postgresql+flexresp - 2.6.1.1-1.fc7.x86_64 snort-snmp - 2.6.1.1-1.fc7.i386 snort-snmp - 2.6.1.1-1.fc7.ppc snort-snmp - 2.6.1.1-1.fc7.x86_64 snort-snmp+flexresp - 2.6.1.1-1.fc7.i386 snort-snmp+flexresp - 2.6.1.1-1.fc7.ppc snort-snmp+flexresp - 2.6.1.1-1.fc7.x86_64 gauret AT free.fr gwenview - 1.4.1-2.fc6.i386 gwenview - 1.4.1-2.fc6.ppc gwenview - 1.4.1-2.fc6.x86_64 gwenview - 1.4.1-2.fc7.i386 gwenview - 1.4.1-2.fc7.ppc gwenview - 1.4.1-2.fc7.x86_64 iftop - 0.17-3.fc6.i386 iftop - 0.17-3.fc6.ppc iftop - 0.17-3.fc6.x86_64 jdennis AT redhat.com cyrus-imapd - 2.3.7-4.fc6.i386 cyrus-imapd - 2.3.7-4.fc6.i386 cyrus-imapd - 2.3.7-4.fc6.ppc cyrus-imapd - 2.3.7-4.fc6.x86_64 jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (51 days) linphone - 1.2.0-4.fc5.ppc (51 days) linphone - 1.2.0-4.fc5.x86_64 (51 days) jima AT beer.tclug.org ngrep - 1.44-7.fc6.i386 ngrep - 1.44-7.fc6.ppc ngrep - 1.44-7.fc6.x86_64 scanssh - 2.1-9.fc6.i386 scanssh - 2.1-9.fc6.ppc scanssh - 2.1-9.fc6.x86_64 joost.soeterbroek AT gmail.com stonith - 2.0.7-4.fc7.i386 stonith - 2.0.7-4.fc7.i386 stonith - 2.0.7-4.fc7.ppc stonith - 2.0.7-4.fc7.x86_64 jpo AT di.uminho.pt nagios-plugins-snmp-disk-proc - 1.0-1.fc6.i386 nagios-plugins-snmp-disk-proc - 1.0-1.fc6.ppc nagios-plugins-snmp-disk-proc - 1.0-1.fc6.x86_64 jwilson AT redhat.com ip6sic - 0.1-4.fc6.i386 ip6sic - 0.1-4.fc6.ppc ip6sic - 0.1-4.fc6.x86_64 zabbix - 1.1.4-2.fc7.i386 zabbix - 1.1.4-2.fc7.ppc zabbix - 1.1.4-2.fc7.x86_64 karlthered AT gmail.com gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.i386 (7 days) gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.i386 (7 days) gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.ppc (7 days) gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.x86_64 (7 days) kevin-redhat-bugzilla AT tummy.com p0f - 2.0.8-1.fc7.i386 p0f - 2.0.8-1.fc7.ppc p0f - 2.0.8-1.fc7.x86_64 lmacken AT redhat.com xprobe2 - 0.3-8.fc6.i386 xprobe2 - 0.3-8.fc6.ppc xprobe2 - 0.3-8.fc6.x86_64 matthias AT rpmforge.net php-eaccelerator - 5.1.6_0.9.5-2.fc7.i386 (13 days) php-eaccelerator - 5.1.6_0.9.5-2.fc7.ppc (13 days) php-eaccelerator - 5.1.6_0.9.5-2.fc7.x86_64 (13 days) ucarp - 1.2-4.fc6.i386 ucarp - 1.2-4.fc6.ppc ucarp - 1.2-4.fc6.x86_64 mgarski AT post.pl digikam-doc - 0.8.2-3.fc6.noarch digikam-doc - 0.8.2-3.fc6.noarch digikam-doc - 0.8.2-3.fc6.noarch mtasaka AT ioa.s.u-tokyo.ac.jp tideEditor - 1.3.12.0.2-1.fc5.i386 tideEditor - 1.3.12.0.2-1.fc5.ppc tideEditor - 1.3.12.0.2-1.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-10.fc6.i386 (13 days) syck-php - 0.55-10.fc6.ppc (13 days) syck-php - 0.55-10.fc6.x86_64 (13 days) syck-php - 0.55-9.fc5.i386 (41 days) syck-php - 0.55-9.fc5.ppc (41 days) syck-php - 0.55-9.fc5.x86_64 (41 days) orion AT cora.nwra.com apcupsd - 3.12.4-3.fc6.i386 apcupsd - 3.12.4-3.fc6.ppc apcupsd - 3.12.4-3.fc6.x86_64 apcupsd-cgi - 3.12.4-3.fc6.i386 apcupsd-cgi - 3.12.4-3.fc6.ppc apcupsd-cgi - 3.12.4-3.fc6.x86_64 paul AT xelerance.com hping3 - 0.0.20051105-4.fc6.i386 hping3 - 0.0.20051105-4.fc6.ppc hping3 - 0.0.20051105-4.fc6.x86_64 pertusus AT free.fr grads - 1.9b4-19.fc7.i386 (13 days) grads - 1.9b4-19.fc7.ppc (13 days) grads - 1.9b4-19.fc7.x86_64 (13 days) intuitively - 0.7-10.fc6.i386 intuitively - 0.7-10.fc6.ppc intuitively - 0.7-10.fc6.x86_64 petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 (26 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (26 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (26 days) ghc642-gtk2hs - 0.9.10-4.fc6.i386 (26 days) ghc642-gtk2hs - 0.9.10-4.fc6.ppc (26 days) ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 (26 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 (26 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc (26 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 (26 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (31 days) libmal - 0.31-4.fc6.i386 libmal - 0.31-4.fc6.i386 libmal - 0.31-4.fc6.ppc libmal - 0.31-4.fc6.x86_64 redhat-bugzilla AT linuxnetz.de tcpick - 0.2.1-10.fc6.i386 tcpick - 0.2.1-10.fc6.ppc tcpick - 0.2.1-10.fc6.x86_64 somlo AT cmu.edu argus - 2.0.6.fixes.1-12.fc6.i386 argus - 2.0.6.fixes.1-12.fc6.ppc argus - 2.0.6.fixes.1-12.fc6.x86_64 tcallawa AT redhat.com gambas-runtime - 1.0.17-6.fc7.i386 (6 days) gambas-runtime - 1.0.17-6.fc7.ppc (6 days) tibbs AT math.uh.edu lft - 1:2.5-6.fc6.i386 lft - 1:2.5-6.fc6.ppc lft - 1:2.5-6.fc6.x86_64 ====================================================================== Broken packages in fedora-extras-development-ppc: GraphicsMagick-c++-devel-1.1.7-2.fc7.ppc requires GraphicsMagick-devel = 0:1.1.72.fc7 airsnort-0.2.7e-10.fc6.ppc requires libpcap.so.0.9.4 apcupsd-3.12.4-3.fc6.ppc requires libnetsnmp.so.10 apcupsd-cgi-3.12.4-3.fc6.ppc requires libnetsnmp.so.10 argus-2.0.6.fixes.1-12.fc6.ppc requires libpcap.so.0.9.4 blender-2.42a-5.fc7.ppc requires libgettextlib-0.15.so centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 cyrus-imapd-2.3.7-4.fc6.ppc requires libnetsnmpmibs.so.10 cyrus-imapd-2.3.7-4.fc6.ppc requires libnetsnmphelpers.so.10 cyrus-imapd-2.3.7-4.fc6.ppc requires libnetsnmp.so.10 cyrus-imapd-2.3.7-4.fc6.ppc requires libnetsnmpagent.so.10 digikam-doc-0.8.2-3.fc6.noarch requires digikam = 0:0.8.2 driftnet-0.1.6-11.ppc requires libpcap.so.0.9.4 gambas-runtime-1.0.17-6.fc7.ppc requires libgettextlib-0.15.so ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 grads-1.9b4-19.fc7.ppc requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.ppc requires gecko-libs = 0:2.0 gwenview-1.4.1-2.fc7.ppc requires libexiv2-0.11.so hping3-0.0.20051105-4.fc6.ppc requires libpcap.so.0.9.4 iftop-0.17-3.fc6.ppc requires libpcap.so.0.9.4 intuitively-0.7-10.fc6.ppc requires libpcap.so.0.9.4 ip6sic-0.1-4.fc6.ppc requires libpcap.so.0.9.4 lft-1:2.5-6.fc6.ppc requires libpcap.so.0.9.4 libmal-0.31-4.fc6.ppc requires libpisock.so.8 libnasl-2.2.8-2.fc6.ppc requires libpcap.so.0.9.4 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 libopensync-plugin-palm-0.19-1.fc6.ppc requires libpisock.so.8 nagios-plugins-snmp-disk-proc-1.0-1.fc6.ppc requires libnetsnmp.so.10 nessus-client-2.2.7-2.fc6.ppc requires libpcap.so.0.9.4 nessus-gui-2.2.7-2.fc6.ppc requires libpcap.so.0.9.4 nessus-server-2.2.7-2.fc6.ppc requires libpcap.so.0.9.4 ngrep-1.44-7.fc6.ppc requires libpcap.so.0.9.4 p0f-2.0.8-1.fc7.ppc requires libpcap.so.0.9.4 php-eaccelerator-5.1.6_0.9.5-2.fc7.ppc requires php-common = 0:5.1.6 scanssh-2.1-9.fc6.ppc requires libpcap.so.0.9.4 snort-2.6.1.1-1.fc7.ppc requires libpcap.so.0.9.4 snort-bloat-2.6.1.1-1.fc7.ppc requires libpcap.so.0.9.4 snort-mysql+flexresp-2.6.1.1-1.fc7.ppc requires libpcap.so.0.9.4 snort-mysql-2.6.1.1-1.fc7.ppc requires libpcap.so.0.9.4 snort-plain+flexresp-2.6.1.1-1.fc7.ppc requires libpcap.so.0.9.4 snort-postgresql+flexresp-2.6.1.1-1.fc7.ppc requires libpcap.so.0.9.4 snort-postgresql-2.6.1.1-1.fc7.ppc requires libpcap.so.0.9.4 snort-snmp+flexresp-2.6.1.1-1.fc7.ppc requires libpcap.so.0.9.4 snort-snmp-2.6.1.1-1.fc7.ppc requires libpcap.so.0.9.4 stonith-2.0.7-4.fc7.ppc requires libnetsnmp.so.10 syck-php-0.55-10.fc6.ppc requires php = 0:5.1.6 sylpheed-claws-2.6.0-1.fc7.ppc requires libpisock.so.8 tcpick-0.2.1-10.fc6.ppc requires libpcap.so.0.9.4 ucarp-1.2-4.fc6.ppc requires libpcap.so.0.9.4 xprobe2-0.3-8.fc6.ppc requires libpcap.so.0.9.4 zabbix-1.1.4-2.fc7.ppc requires libnetsnmp.so.10 ====================================================================== Broken packages in fedora-extras-development-x86_64: GraphicsMagick-c++-devel-1.1.7-2.fc7.i386 requires GraphicsMagick-devel = 0:1.1.72.fc7 GraphicsMagick-c++-devel-1.1.7-2.fc7.x86_64 requires GraphicsMagick-devel = 0:1.1.72.fc7 airsnort-0.2.7e-10.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) apcupsd-3.12.4-3.fc6.x86_64 requires libnetsnmp.so.10()(64bit) apcupsd-cgi-3.12.4-3.fc6.x86_64 requires libnetsnmp.so.10()(64bit) argus-2.0.6.fixes.1-12.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) blender-2.42a-5.fc7.x86_64 requires libgettextlib-0.15.so()(64bit) centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) cyrus-imapd-2.3.7-4.fc6.i386 requires libnetsnmpmibs.so.10 cyrus-imapd-2.3.7-4.fc6.i386 requires libnetsnmphelpers.so.10 cyrus-imapd-2.3.7-4.fc6.i386 requires libnetsnmp.so.10 cyrus-imapd-2.3.7-4.fc6.i386 requires libnetsnmpagent.so.10 cyrus-imapd-2.3.7-4.fc6.x86_64 requires libnetsnmpmibs.so.10()(64bit) cyrus-imapd-2.3.7-4.fc6.x86_64 requires libnetsnmp.so.10()(64bit) cyrus-imapd-2.3.7-4.fc6.x86_64 requires libnetsnmphelpers.so.10()(64bit) cyrus-imapd-2.3.7-4.fc6.x86_64 requires libnetsnmpagent.so.10()(64bit) digikam-doc-0.8.2-3.fc6.noarch requires digikam = 0:0.8.2 driftnet-0.1.6-11.x86_64 requires libpcap.so.0.9.4()(64bit) ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 grads-1.9b4-19.fc7.x86_64 requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.i386 requires gecko-libs = 0:2.0 gtkmozembedmm-1.4.2.cvs20060817-5.fc7.x86_64 requires gecko-libs = 0:2.0 gwenview-1.4.1-2.fc7.x86_64 requires libexiv2-0.11.so()(64bit) hping3-0.0.20051105-4.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) iftop-0.17-3.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) intuitively-0.7-10.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) ip6sic-0.1-4.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) lft-1:2.5-6.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) libmal-0.31-4.fc6.i386 requires libpisock.so.8 libmal-0.31-4.fc6.x86_64 requires libpisock.so.8()(64bit) libnasl-2.2.8-2.fc6.i386 requires libpcap.so.0.9.4 libnasl-2.2.8-2.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) libopensync-plugin-palm-0.19-1.fc6.i386 requires libpisock.so.8 libopensync-plugin-palm-0.19-1.fc6.x86_64 requires libpisock.so.8()(64bit) nagios-plugins-snmp-disk-proc-1.0-1.fc6.x86_64 requires libnetsnmp.so.10()(64bit) nessus-client-2.2.7-2.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) nessus-gui-2.2.7-2.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) nessus-server-2.2.7-2.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) ngrep-1.44-7.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 p0f-2.0.8-1.fc7.x86_64 requires libpcap.so.0.9.4()(64bit) php-eaccelerator-5.1.6_0.9.5-2.fc7.x86_64 requires php-common = 0:5.1.6 scanssh-2.1-9.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) snort-2.6.1.1-1.fc7.x86_64 requires libpcap.so.0.9.4()(64bit) snort-bloat-2.6.1.1-1.fc7.x86_64 requires libpcap.so.0.9.4()(64bit) snort-mysql+flexresp-2.6.1.1-1.fc7.x86_64 requires libpcap.so.0.9.4()(64bit) snort-mysql-2.6.1.1-1.fc7.x86_64 requires libpcap.so.0.9.4()(64bit) snort-plain+flexresp-2.6.1.1-1.fc7.x86_64 requires libpcap.so.0.9.4()(64bit) snort-postgresql+flexresp-2.6.1.1-1.fc7.x86_64 requires libpcap.so.0.9.4()(64bit) snort-postgresql-2.6.1.1-1.fc7.x86_64 requires libpcap.so.0.9.4()(64bit) snort-snmp+flexresp-2.6.1.1-1.fc7.x86_64 requires libpcap.so.0.9.4()(64bit) snort-snmp-2.6.1.1-1.fc7.x86_64 requires libpcap.so.0.9.4()(64bit) stonith-2.0.7-4.fc7.i386 requires libnetsnmp.so.10 stonith-2.0.7-4.fc7.x86_64 requires libnetsnmp.so.10()(64bit) syck-php-0.55-10.fc6.x86_64 requires php = 0:5.1.6 sylpheed-claws-2.6.0-1.fc7.i386 requires libpisock.so.8 sylpheed-claws-2.6.0-1.fc7.x86_64 requires libpisock.so.8()(64bit) tcpick-0.2.1-10.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) ucarp-1.2-4.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) xprobe2-0.3-8.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) zabbix-1.1.4-2.fc7.x86_64 requires libnetsnmp.so.10()(64bit) ====================================================================== Broken packages in fedora-extras-development-i386: GraphicsMagick-c++-devel-1.1.7-2.fc7.i386 requires GraphicsMagick-devel = 0:1.1.72.fc7 airsnort-0.2.7e-10.fc6.i386 requires libpcap.so.0.9.4 apcupsd-3.12.4-3.fc6.i386 requires libnetsnmp.so.10 apcupsd-cgi-3.12.4-3.fc6.i386 requires libnetsnmp.so.10 argus-2.0.6.fixes.1-12.fc6.i386 requires libpcap.so.0.9.4 blender-2.42a-5.fc7.i386 requires libgettextlib-0.15.so centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 cyrus-imapd-2.3.7-4.fc6.i386 requires libnetsnmpmibs.so.10 cyrus-imapd-2.3.7-4.fc6.i386 requires libnetsnmphelpers.so.10 cyrus-imapd-2.3.7-4.fc6.i386 requires libnetsnmp.so.10 cyrus-imapd-2.3.7-4.fc6.i386 requires libnetsnmpagent.so.10 digikam-doc-0.8.2-3.fc6.noarch requires digikam = 0:0.8.2 driftnet-0.1.6-11.i386 requires libpcap.so.0.9.4 gambas-runtime-1.0.17-6.fc7.i386 requires libgettextlib-0.15.so ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 grads-1.9b4-19.fc7.i386 requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.i386 requires gecko-libs = 0:2.0 gwenview-1.4.1-2.fc7.i386 requires libexiv2-0.11.so hping3-0.0.20051105-4.fc6.i386 requires libpcap.so.0.9.4 iftop-0.17-3.fc6.i386 requires libpcap.so.0.9.4 intuitively-0.7-10.fc6.i386 requires libpcap.so.0.9.4 ip6sic-0.1-4.fc6.i386 requires libpcap.so.0.9.4 lft-1:2.5-6.fc6.i386 requires libpcap.so.0.9.4 libmal-0.31-4.fc6.i386 requires libpisock.so.8 libnasl-2.2.8-2.fc6.i386 requires libpcap.so.0.9.4 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-palm-0.19-1.fc6.i386 requires libpisock.so.8 nagios-plugins-snmp-disk-proc-1.0-1.fc6.i386 requires libnetsnmp.so.10 nessus-client-2.2.7-2.fc6.i386 requires libpcap.so.0.9.4 nessus-gui-2.2.7-2.fc6.i386 requires libpcap.so.0.9.4 nessus-server-2.2.7-2.fc6.i386 requires libpcap.so.0.9.4 ngrep-1.44-7.fc6.i386 requires libpcap.so.0.9.4 p0f-2.0.8-1.fc7.i386 requires libpcap.so.0.9.4 php-eaccelerator-5.1.6_0.9.5-2.fc7.i386 requires php-common = 0:5.1.6 scanssh-2.1-9.fc6.i386 requires libpcap.so.0.9.4 snort-2.6.1.1-1.fc7.i386 requires libpcap.so.0.9.4 snort-bloat-2.6.1.1-1.fc7.i386 requires libpcap.so.0.9.4 snort-mysql+flexresp-2.6.1.1-1.fc7.i386 requires libpcap.so.0.9.4 snort-mysql-2.6.1.1-1.fc7.i386 requires libpcap.so.0.9.4 snort-plain+flexresp-2.6.1.1-1.fc7.i386 requires libpcap.so.0.9.4 snort-postgresql+flexresp-2.6.1.1-1.fc7.i386 requires libpcap.so.0.9.4 snort-postgresql-2.6.1.1-1.fc7.i386 requires libpcap.so.0.9.4 snort-snmp+flexresp-2.6.1.1-1.fc7.i386 requires libpcap.so.0.9.4 snort-snmp-2.6.1.1-1.fc7.i386 requires libpcap.so.0.9.4 stonith-2.0.7-4.fc7.i386 requires libnetsnmp.so.10 syck-php-0.55-10.fc6.i386 requires php = 0:5.1.6 sylpheed-claws-2.6.0-1.fc7.i386 requires libpisock.so.8 tcpick-0.2.1-10.fc6.i386 requires libpcap.so.0.9.4 ucarp-1.2-4.fc6.i386 requires libpcap.so.0.9.4 xprobe2-0.3-8.fc6.i386 requires libpcap.so.0.9.4 zabbix-1.1.4-2.fc7.i386 requires libnetsnmp.so.10 ====================================================================== Broken packages in fedora-extras-6-ppc: GraphicsMagick-c++-devel-1.1.7-2.fc6.ppc requires GraphicsMagick-devel = 0:1.1.72.fc6 gwenview-1.4.1-2.fc6.ppc requires libexiv2-0.11.so ====================================================================== Broken packages in fedora-extras-6-x86_64: GraphicsMagick-c++-devel-1.1.7-2.fc6.x86_64 requires GraphicsMagick-devel = 0:1.1.72.fc6 gwenview-1.4.1-2.fc6.x86_64 requires libexiv2-0.11.so()(64bit) ====================================================================== Broken packages in fedora-extras-6-i386: GraphicsMagick-c++-devel-1.1.7-2.fc6.i386 requires GraphicsMagick-devel = 0:1.1.72.fc6 gwenview-1.4.1-2.fc6.i386 requires libexiv2-0.11.so ====================================================================== Broken packages in fedora-extras-5-ppc: GraphicsMagick-c++-devel-1.1.7-2.fc5.ppc requires GraphicsMagick-devel = 0:1.1.72.fc5 linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 tideEditor-1.3.12.0.2-1.fc5.ppc requires xtide-common ====================================================================== Broken packages in fedora-extras-5-x86_64: GraphicsMagick-c++-devel-1.1.7-2.fc5.x86_64 requires GraphicsMagick-devel = 0:1.1.72.fc5 linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 tideEditor-1.3.12.0.2-1.fc5.x86_64 requires xtide-common ====================================================================== Broken packages in fedora-extras-5-i386: GraphicsMagick-c++-devel-1.1.7-2.fc5.i386 requires GraphicsMagick-devel = 0:1.1.72.fc5 linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 tideEditor-1.3.12.0.2-1.fc5.i386 requires xtide-common ====================================================================== Broken packages in fedora-extras-4-ppc: plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 ====================================================================== Broken packages in fedora-extras-4-x86_64: plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) ====================================================================== Broken packages in fedora-extras-4-i386: plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 ====================================================================== Broken packages in fedora-extras-3-x86_64: plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== Broken packages in fedora-extras-3-i386: plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 From chris.stone at gmail.com Wed Nov 29 13:13:01 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 29 Nov 2006 05:13:01 -0800 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1164791402.30297.15.camel@metropolis.intra.city-fan.org> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <454375C3.5020507@leemhuis.info> <20061028211022.GB19403@neu.nirvana> <1162071820.3139.39.camel@vader.jdub.homelinux.org> <1164750968.14595.11.camel@pmac.infradead.org> <1164791402.30297.15.camel@metropolis.intra.city-fan.org> Message-ID: On 11/29/06, Paul Howarth wrote: > On Tue, 2006-11-28 at 21:56 +0000, David Woodhouse wrote: > > On Sat, 2006-10-28 at 15:53 -0700, Christopher Stone wrote: > > > I *think* the point he is trying to make is that some people don't > > > like 3rd party repositories overriding Fedora Extras without good > > > reason and some other people dont like Fedora Extras maintainers > > > adding packages in Fedora Extras without first consulting with the 3rd > > > party repositories. > > > > > > Which goes back to my original idea of having an official Fedora wiki > > > page that lists 3rd party repositories. Fedora Extras maintainers > > > could then check this wiki page to find out which repositories might > > > already have a package available for the package they want to submit. > > > > I don't really understand. Whenever I want a package to be available, I > > make sure it gets into Core or Extras? Why would I look elsewhere, > > except in the special case of something that goes in Livna? > > > > I'm no more interested in packages from outside Core/Extras/Livna than I > > am in installing Debian packages with Alien. Why is it interesting? > > End users may already be using packages from third-party repos, and may > have issues if new and incompatible packages of those applications > subsequently appear in Extras. The Extras packager could save their > potential users some grief if they took notice of what's already > available elsewhere and tried to avoid breaking upgrade paths between > their package and others' (and vice versa). Of course if the third-party > packager has done something stupid with their package, it doesn't mean > that the Extras packager should follow suit, but at least as a courtesy > to users try to avoid breaking things unnecessarily. It has to go both ways. I have a package (sdlmame) on Dribble which is now also available on Freshrpms. Yet the Freshrpms packager did not bother to check my package before making his. Seems pointless to try and blame packagers for something like this when every packager from every repo. is doing the same thing... From dwmw2 at infradead.org Wed Nov 29 16:32:08 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 29 Nov 2006 16:32:08 +0000 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1164791402.30297.15.camel@metropolis.intra.city-fan.org> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <454375C3.5020507@leemhuis.info> <20061028211022.GB19403@neu.nirvana> <1162071820.3139.39.camel@vader.jdub.homelinux.org> <1164750968.14595.11.camel@pmac.infradead.org> <1164791402.30297.15.camel@metropolis.intra.city-fan.org> Message-ID: <1164817928.14595.78.camel@pmac.infradead.org> On Wed, 2006-11-29 at 09:10 +0000, Paul Howarth wrote: > End users may already be using packages from third-party repos, and may > have issues if new and incompatible packages of those applications > subsequently appear in Extras. The Extras packager could save their > potential users some grief if they took notice of what's already > available elsewhere and tried to avoid breaking upgrade paths between > their package and others' (and vice versa). Of course if the third-party > packager has done something stupid with their package, it doesn't mean > that the Extras packager should follow suit, but at least as a courtesy > to users try to avoid breaking things unnecessarily. My point was that if the third-party packager has built the package and put it anywhere _other_ than Core, Extras or Livna, they've already done something stupid. Or at least suboptimal. And if the end user is using a package from a repo other than Core, Extras and Livna, then they can expect trouble too. Yes, people do all kinds of strange things -- why do we care? -- dwmw2 From mattdm at mattdm.org Wed Nov 29 16:54:03 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Nov 2006 11:54:03 -0500 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1164817928.14595.78.camel@pmac.infradead.org> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <454375C3.5020507@leemhuis.info> <20061028211022.GB19403@neu.nirvana> <1162071820.3139.39.camel@vader.jdub.homelinux.org> <1164750968.14595.11.camel@pmac.infradead.org> <1164791402.30297.15.camel@metropolis.intra.city-fan.org> <1164817928.14595.78.camel@pmac.infradead.org> Message-ID: <20061129165403.GA27634@jadzia.bu.edu> On Wed, Nov 29, 2006 at 04:32:08PM +0000, David Woodhouse wrote: > My point was that if the third-party packager has built the package and > put it anywhere _other_ than Core, Extras or Livna, they've already done > something stupid. Or at least suboptimal. Many of these repositories have been around longer than Core, Extras, or Livna. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rc040203 at freenet.de Wed Nov 29 18:38:35 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 29 Nov 2006 19:38:35 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1164817928.14595.78.camel@pmac.infradead.org> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <454375C3.5020507@leemhuis.info> <20061028211022.GB19403@neu.nirvana> <1162071820.3139.39.camel@vader.jdub.homelinux.org> <1164750968.14595.11.camel@pmac.infradead.org> <1164791402.30297.15.camel@metropolis.intra.city-fan.org> <1164817928.14595.78.camel@pmac.infradead.org> Message-ID: <1164825515.22954.61.camel@mccallum.corsepiu.local> On Wed, 2006-11-29 at 16:32 +0000, David Woodhouse wrote: > On Wed, 2006-11-29 at 09:10 +0000, Paul Howarth wrote: > > End users may already be using packages from third-party repos, and may > > have issues if new and incompatible packages of those applications > > subsequently appear in Extras. The Extras packager could save their > > potential users some grief if they took notice of what's already > > available elsewhere and tried to avoid breaking upgrade paths between > > their package and others' (and vice versa). Of course if the third-party > > packager has done something stupid with their package, it doesn't mean > > that the Extras packager should follow suit, but at least as a courtesy > > to users try to avoid breaking things unnecessarily. > > My point was that if the third-party packager has built the package and > put it anywhere _other_ than Core, Extras or Livna, they've already done > something stupid. ... you definitely know, there are plenty of reasons to use 3rd party repos. > Or at least suboptimal. ... as if things were so easy ... ;) Ralf From smooge at gmail.com Wed Nov 29 21:23:05 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 29 Nov 2006 14:23:05 -0700 Subject: Plone - Zope on Fedora Core 4 In-Reply-To: <20061128211544.GB12089@jadzia.bu.edu> References: <456C9B4E.8020004@fedoraunity.org> <20061128211544.GB12089@jadzia.bu.edu> Message-ID: <80d7e4090611291323h50bf69ffo95d70f89d67552e@mail.gmail.com> On 11/28/06, Matthew Miller wrote: > On Tue, Nov 28, 2006 at 01:25:50PM -0700, Jon Steffan wrote: > > I've been pushing updates to plone and zope and would like to get > > FC4 updated as FC4 is still offered by many hosting companies. The Plone > > We need to push those hosting companies to upgrade. FC4 is not safe for > server systems. > It would be nice if we had any leverage.. but there are still large ones that still run FC2. The fact is that a lot of these companies have minimal technical staff who can set up an upgrade process where they are going to be able to upgrade every 6-9 months.. and to be honest a lot of their customers don't want to. What they and their customers are wanting is that somm items like Apache/MySQL/PHP/Plone could be the latest.. but the rest don't touch. E.G. For a lot of stuff, Fedora is not what hosting companies are wanting, but something like Centos or RHEL. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From dwmw2 at infradead.org Wed Nov 29 22:13:52 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 29 Nov 2006 22:13:52 +0000 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1164825515.22954.61.camel@mccallum.corsepiu.local> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <454375C3.5020507@leemhuis.info> <20061028211022.GB19403@neu.nirvana> <1162071820.3139.39.camel@vader.jdub.homelinux.org> <1164750968.14595.11.camel@pmac.infradead.org> <1164791402.30297.15.camel@metropolis.intra.city-fan.org> <1164817928.14595.78.camel@pmac.infradead.org> <1164825515.22954.61.camel@mccallum.corsepiu.local> Message-ID: <1164838432.14595.207.camel@pmac.infradead.org> On Wed, 2006-11-29 at 19:38 +0100, Ralf Corsepius wrote: > ... you definitely know, there are plenty of reasons to use 3rd party > repos. Actually, I don't. Well, I suppose there's my private repo at ftp://ftp.infradead.org/pub/dwmw2-fc$releasever which has some improvements on openssh and some fixes to make Evolution just about usable, but those are things I hope will get upstream eventually -- it's not really a 'public' repository. I'd never dream of doing stuff like that with a new package where I could just get it into Extras or Livna. Why would I? -- dwmw2 From a.badger at gmail.com Wed Nov 29 23:42:32 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 29 Nov 2006 15:42:32 -0800 Subject: pacakge classification and selection (was Re: New Comps Groups) In-Reply-To: References: <20061127182408.GC32187@nostromo.devel.redhat.com> <1164659611.2890.1.camel@Chuck> <1164660729.3195.8.camel@rousalka.dyndns.org> <1164661131.22125.106.camel@aglarond.local> <1164669540.28835.20.camel@aglarond.local> <1164672066.3195.76.camel@rousalka.dyndns.org> <20061128180650.GH4246@nostromo.devel.redhat.com> Message-ID: <1164843752.11786.7.camel@localhost.localdomain> On Tue, 2006-11-28 at 10:15 -0800, Christopher Stone wrote: > On 11/28/06, Bill Nottingham wrote: > > So, in short, I think the comps push, while fitting in our current > > infrastructure, isn't really solving the *right* problem. We need a > > better interface... something like Amazon or freshmeat or > handwaving>. > > I seem to recall some discussion a while back about replacing > owners.list with a database, perhaps this could be the first step in > this direction. We could add keywords to each package which a user > could search. > Currently, this is a later step rather than a first step. The conversion of owners.list has immediate application to the new buildsystem and other infrastructure that we want to have ready for FC7 so it's getting priority. If someone wants to code some proof of concept around this it's welcome, though. It doesn't even have to be integrated into the main packagedb testing as the information can be merged at a later date. -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 a.badger at gmail.com Wed Nov 29 23:59:24 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 29 Nov 2006 15:59:24 -0800 Subject: New Comps Groups In-Reply-To: <200611281452.58273.jkeating@redhat.com> References: <200611281209.21318.jkeating@redhat.com> <1164742312.22549.30.camel@rousalka.dyndns.org> <200611281452.58273.jkeating@redhat.com> Message-ID: <1164844764.11786.15.camel@localhost.localdomain> On Tue, 2006-11-28 at 14:52 -0500, Jesse Keating wrote: > On Tuesday 28 November 2006 14:31, Nicolas Mailhot wrote: > > The point is, people can classify properly packages, and apps choose to > > show more or less groups depending on the target audience. > > > > For example repoview will typically show all groups, anaconda the most > > important ones, yum something in between > > But your hiding the package so NO tool will see it. What is the point there? That's not true. If it's in the xml file, the tools see it. The tool then decides whether to show it to the user. Just because anaconda decides not to use the information based on the hidden-property doesn't prevent yumex, apt, smart, or another package manager from using the classification to show the packages in a category view. If we are making the RPM Group field optional in the spec file, then we have to allow equivalent information to be stored and retrieved from somewhere. In the Packaging Meeting, this somewhere was comps. If comps is not the place for it then we have a bit of a problem. -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 jkeating at redhat.com Thu Nov 30 02:39:40 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 29 Nov 2006 21:39:40 -0500 Subject: New Comps Groups In-Reply-To: <1164844764.11786.15.camel@localhost.localdomain> References: <200611281452.58273.jkeating@redhat.com> <1164844764.11786.15.camel@localhost.localdomain> Message-ID: <200611292139.43243.jkeating@redhat.com> On Wednesday 29 November 2006 18:59, Toshio Kuratomi wrote: > If we are making the RPM Group field optional in the spec file, then we > have to allow equivalent information to be stored and retrieved from > somewhere. ?In the Packaging Meeting, this somewhere was comps. ?If > comps is not the place for it then we have a bit of a problem. The repodata itself can list the rest of the packages. The tool can list the grouped packages, and packages that aren't listed in any group can fall under 'ungrouped packages'. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Thu Nov 30 03:19:42 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 29 Nov 2006 19:19:42 -0800 Subject: New Comps Groups In-Reply-To: <200611292139.43243.jkeating@redhat.com> References: <200611281452.58273.jkeating@redhat.com> <1164844764.11786.15.camel@localhost.localdomain> <200611292139.43243.jkeating@redhat.com> Message-ID: <1164856782.11786.101.camel@localhost.localdomain> On Wed, 2006-11-29 at 21:39 -0500, Jesse Keating wrote: > On Wednesday 29 November 2006 18:59, Toshio Kuratomi wrote: > > If we are making the RPM Group field optional in the spec file, then we > > have to allow equivalent information to be stored and retrieved from > > somewhere. In the Packaging Meeting, this somewhere was comps. If > > comps is not the place for it then we have a bit of a problem. > > The repodata itself can list the rest of the packages. The tool can list the > grouped packages, and packages that aren't listed in any group can fall > under 'ungrouped packages'. > "ungrouped packages" is horrible. If I'm looking for a python module to help me write an email signing plugin I certainly don't want to browse all the C libraries, command line tools, and other things someone A) thought shouldn't be listed by the installer or B) didn't have time to add to comps.xml. As Bill said, I probably don't even want to browse all of the python module packages, but it's better than nothing. comps may not be ideal for this but unless we go back to making the rpm group mandatory, it's the only thing we have ATM. Maybe the installer needs to have a comps.xml file that's separate from the repository comps.xml file. Maybe the hidden attribute is just what we need. Maybe we need attributes to specify who'd be interested in this (audience="programmer" audience="enduser" audience="administrator") Maybe we have to bite the bullet and come up with something better than comps. -Toshio PS. When we design something new, it should have multicategory support: python-gpgme /Language/Python /Security/Cryptography /Development/Library /Internet/CertificateManagement So I can search for the intersection of /Language/Python, /Development/Library, and /Security/Cryptography to find things closer to what I want. -------------- next part -------------- A non-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 Thu Nov 30 03:35:51 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 30 Nov 2006 04:35:51 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1164838432.14595.207.camel@pmac.infradead.org> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <454375C3.5020507@leemhuis.info> <20061028211022.GB19403@neu.nirvana> <1162071820.3139.39.camel@vader.jdub.homelinux.org> <1164750968.14595.11.camel@pmac.infradead.org> <1164791402.30297.15.camel@metropolis.intra.city-fan.org> <1164817928.14595.78.camel@pmac.infradead.org> <1164825515.22954.61.camel@mccallum.corsepiu.local> <1164838432.14595.207.camel@pmac.infradead.org> Message-ID: <1164857751.22954.79.camel@mccallum.corsepiu.local> On Wed, 2006-11-29 at 22:13 +0000, David Woodhouse wrote: > On Wed, 2006-11-29 at 19:38 +0100, Ralf Corsepius wrote: > > ... you definitely know, there are plenty of reasons to use 3rd party > > repos. > > Actually, I don't. * licenses/US laws/Fedora conventions closing out packages from FE * Legal concerns against Livna. * Stuck reviews (FE, Livna) * Packages containing contents. * Lack of general interest * Fedora/Livna shipping versions not matching user demands (Too old, ... too new, ...) * Fedora/Livna shipping broken/non-functional/unusable packages. * Simplicity of access. ... > I'd never dream of doing stuff like that with a new package where I > could just get it into Extras or Livna. Why would I? I am involved into several 3rd party repos for one or more reasons from the list above. Ralf From skvidal at linux.duke.edu Thu Nov 30 03:49:11 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 29 Nov 2006 22:49:11 -0500 Subject: New Comps Groups In-Reply-To: <1164856782.11786.101.camel@localhost.localdomain> References: <200611281452.58273.jkeating@redhat.com> <1164844764.11786.15.camel@localhost.localdomain> <200611292139.43243.jkeating@redhat.com> <1164856782.11786.101.camel@localhost.localdomain> Message-ID: <1164858551.7311.112.camel@cutter> On Wed, 2006-11-29 at 19:19 -0800, Toshio Kuratomi wrote: > -Toshio > > PS. When we design something new, it should have multicategory support: > > > python-gpgme > /Language/Python > /Security/Cryptography > /Development/Library > /Internet/CertificateManagement > > > So I can search for the intersection > of /Language/Python, /Development/Library, and /Security/Cryptography to > find things closer to what I want. I don't see anything stopping that from happening now. Either: 1. write the above interface for repodata and then have yum be able to understand that info 2. use the existing comps format and just have yum be able to look up pkgs by the group they belong to. So for the above you would do: Take the intersection of /Language/Python, /Development/Library, and /Security/Cryptography and display those pkgs. Then comps looks like: /Security/Cryptography python-gpgme gpgme gnupg /Development/Library python-gpgme gpgme -sv From a.badger at gmail.com Thu Nov 30 04:20:35 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 29 Nov 2006 20:20:35 -0800 Subject: New Comps Groups In-Reply-To: <1164858551.7311.112.camel@cutter> References: <200611281452.58273.jkeating@redhat.com> <1164844764.11786.15.camel@localhost.localdomain> <200611292139.43243.jkeating@redhat.com> <1164856782.11786.101.camel@localhost.localdomain> <1164858551.7311.112.camel@cutter> Message-ID: <1164860435.11786.107.camel@localhost.localdomain> On Wed, 2006-11-29 at 22:49 -0500, seth vidal wrote: > I don't see anything stopping that from happening now. > > Either: > 1. write the above interface for repodata and then have yum be able to > understand that info > 2. use the existing comps format and just have yum be able to look up > pkgs by the group they belong to. So for the above you would do: > Take the intersection of /Language/Python, /Development/Library, > and /Security/Cryptography and display those pkgs. > Then comps looks like: > > > /Security/Cryptography > python-gpgme > gpgme > gnupg > > > /Development/Library > python-gpgme > gpgme > > So perhaps all we need is free reign to do this in comps. Which, from previous messages from jeremy, seems to imply we would need to have separate comps.xml files for the installer and for the repo. -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 skvidal at linux.duke.edu Thu Nov 30 04:37:33 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 29 Nov 2006 23:37:33 -0500 Subject: New Comps Groups In-Reply-To: <1164860435.11786.107.camel@localhost.localdomain> References: <200611281452.58273.jkeating@redhat.com> <1164844764.11786.15.camel@localhost.localdomain> <200611292139.43243.jkeating@redhat.com> <1164856782.11786.101.camel@localhost.localdomain> <1164858551.7311.112.camel@cutter> <1164860435.11786.107.camel@localhost.localdomain> Message-ID: <1164861453.7311.125.camel@cutter> On Wed, 2006-11-29 at 20:20 -0800, Toshio Kuratomi wrote: > On Wed, 2006-11-29 at 22:49 -0500, seth vidal wrote: > > I don't see anything stopping that from happening now. > > > > Either: > > 1. write the above interface for repodata and then have yum be able to > > understand that info > > 2. use the existing comps format and just have yum be able to look up > > pkgs by the group they belong to. So for the above you would do: > > Take the intersection of /Language/Python, /Development/Library, > > and /Security/Cryptography and display those pkgs. > > Then comps looks like: > > > > > > /Security/Cryptography > > python-gpgme > > gpgme > > gnupg > > > > > > /Development/Library > > python-gpgme > > gpgme > > > > > So perhaps all we need is free reign to do this in comps. Which, from > previous messages from jeremy, seems to imply we would need to have > separate comps.xml files for the installer and for the repo. Well that's actually not hard to do. yum concatenates comps contents across repos. So you could have a grouping-only repo that is only hit post-install. The grouping-only repo would have nothing besides a comps file in it. spiffy, huh? :) -sv From dominik at greysector.net Thu Nov 30 11:33:26 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 30 Nov 2006 12:33:26 +0100 Subject: .h files in non-devel package? In-Reply-To: <1164725412.13630.0.camel@scriabin.tannenrauch.ch> References: <1164646579.5460.3.camel@scriabin.tannenrauch.ch> <1164647316.6317.122.camel@mccallum.corsepiu.local> <668bb39a0611270918q7bf8688dm7b6839397bfd988b@mail.gmail.com> <20061127200707.GA10795@rathann.pekin.waw.pl> <1164707613.3772.0.camel@scriabin.tannenrauch.ch> <20061128141333.GB19109@rathann.pekin.waw.pl> <1164725412.13630.0.camel@scriabin.tannenrauch.ch> Message-ID: <20061130113325.GA19753@rathann.pekin.waw.pl> On Tuesday, 28 November 2006 at 15:50, G?rard Milmeister wrote: > On Tue, 2006-11-28 at 15:13 +0100, Dominik 'Rathann' Mierzejewski wrote: > > So this package is a compiler? Which package is it? > > It is STklos, a Scheme interpreter and bytecode compiler. I am undecided. On one hand, we have gcc (but it's only a compiler, not interpreter and there is libgcc package, too), but on the other hand we have java and java-devel. I'm leaning towards a separate -devel package for the compiler bits. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From buildsys at fedoraproject.org Thu Nov 30 11:49:26 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 30 Nov 2006 06:49:26 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-11-30 Message-ID: <20061130114926.CD8F615212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 36 GraphicsMagick-1.1.7-3.fc7 argus-2.0.6.fixes.1-13.fc7 audacious-1.2.2-1.fc7 audacious-plugins-1.2.5-1.fc7 blender-2.42a-6.fc7 dirmngr-1.0.0-2.fc7 frozen-bubble-2.1.0-1.fc7 fwbuilder-2.1.7-1.fc7 gaim-gaym-0.96-3.7.293svn.fc7 gwenview-1.4.1-3.fc7 hping3-0.0.20051105-5.fc7 iftop-0.17-4.fc7 intuitively-0.7-12.fc7 kaffeine-0.8.3-2.fc7 lft-2.5-7.fc7 libdvdread-0.9.7-2.fc7 libfwbuilder-2.1.7-1.fc7 libmal-0.31-5.fc7 libtunepimp-0.5.3-1.fc7 memchan-2.2.1-2.fc7 ngrep-1.45-1.fc7 ochusha-0.5.99.63.7-0.1.cvs061129.fc7 ocsinventory-client-1.0-0.6.RC3.fc7 NEW optipng-0.5.4-4.fc7 p0f-2.0.8-2.fc7 pdftk-1.41-2.fc7 perl-Gtk2-Ex-Dialogs-0.11-2.fc7 NEW perl-Gtk2-Ex-Utils-0.09-2.fc7 NEW php-eaccelerator-5.2.0_0.9.5-1.fc7 rssowl-1.2.3-1.fc7 scanssh-2.1-10.fc7 ucarp-1.2-6.fc7 urlgfe-1.0-1.fc7 NEW wbxml2-0.9.2-5.fc7 xprobe2-0.3-8.fc7 zabbix-1.1.4-3.fc7 Packages built and released for Fedora Extras 6: 19 GraphicsMagick-1.1.7-3.fc6 codeblocks-1.0-0.16.20061128svn3295.fc6 frozen-bubble-2.1.0-1.fc6 gaim-gaym-0.96-3.7.293svn.fc6 gwenview-1.4.1-3.fc6 hping3-0.0.20051105-5.fc6 ip6sic-0.1-5.fc6 k3d-0.6.4.0-1.fc6 kaffeine-0.8.3-2.fc6 libdvdread-0.9.7-2.fc6 NEW libsyncml-0.4.2-1.fc6 NEW memchan-2.2.1-2.fc6 NEW optipng-0.5.4-4.fc6 pdftk-1.41-2.fc6 proftpd-1.3.0a-1.fc6 python-eyed3-0.6.11-1.fc6 ssmtp-2.61-10.fc6 urlgfe-1.0-1.fc6 NEW wbxml2-0.9.2-5.fc6 NEW Packages built and released for Fedora Extras 5: 13 GraphicsMagick-1.1.7-3.fc5 OpenSceneGraph-1.2-1.fc5 frozen-bubble-2.1.0-1.fc5 kaffeine-0.8.3-2.fc5 libdvdread-0.9.7-2.fc5 NEW libsyncml-0.4.2-1.fc5 NEW memchan-2.2.1-2.fc5 NEW pdftk-1.41-2.fc5 proftpd-1.3.0a-1.fc5 ssmtp-2.61-10.fc5 urlgfe-1.0-1.fc5 NEW wbxml2-0.9.2-5.fc5 xtide-2.9-0.2.date20061122.fc5.1 NEW Packages built and released for Fedora Extras 4: 0 Packages built and released for Fedora Extras 3: 0 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From mattdm at mattdm.org Thu Nov 30 12:20:37 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 30 Nov 2006 07:20:37 -0500 Subject: New Comps Groups In-Reply-To: <1164861453.7311.125.camel@cutter> References: <200611281452.58273.jkeating@redhat.com> <1164844764.11786.15.camel@localhost.localdomain> <200611292139.43243.jkeating@redhat.com> <1164856782.11786.101.camel@localhost.localdomain> <1164858551.7311.112.camel@cutter> <1164860435.11786.107.camel@localhost.localdomain> <1164861453.7311.125.camel@cutter> Message-ID: <20061130122037.GA8103@jadzia.bu.edu> On Wed, Nov 29, 2006 at 11:37:33PM -0500, seth vidal wrote: > yum concatenates comps contents across repos. So you could have a > grouping-only repo that is only hit post-install. > The grouping-only repo would have nothing besides a comps file in it. > spiffy, huh? :) Also, bear in mind that the true options are overidden. Hey Jeremy -- is it time to entirely move the installclasses/*.py to living in the repo tree yet? Then, get rid of the tag entirely so this decision is clearly made in only one place? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jamatos at fc.up.pt Thu Nov 30 12:20:45 2006 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Thu, 30 Nov 2006 12:20:45 +0000 Subject: R packagers, please help! In-Reply-To: <20061124203418.GB4309@free.fr> References: <20061124203418.GB4309@free.fr> Message-ID: <200611301220.45980.jamatos@fc.up.pt> On Friday 24 November 2006 8:34 pm, Patrice Dumas wrote: > Hello, > > I have submitted a bug for a R template in rpmdevtools: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215927 > > However I am not really qualified on R packaging ;-). So please R packagers > have a look! I will have a look into it soon. > -- > Pat -- Jos? Ab?lio From dennis at ausil.us Thu Nov 30 12:33:11 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 30 Nov 2006 06:33:11 -0600 Subject: extras-buildsys/utils/pushscript Push.py,1.19,1.20 In-Reply-To: <200611301056.kAUAunBl005002@cvs-int.fedora.redhat.com> References: <200611301056.kAUAunBl005002@cvs-int.fedora.redhat.com> Message-ID: <200611300633.12318.dennis@ausil.us> On Thursday 30 November 2006 4:56 am, Michael Schwendt wrote: > Author: mschwendt > > Update of /cvs/fedora/extras-buildsys/utils/pushscript > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv4987 > > Modified Files: > Push.py > Log Message: > trying something Michael, I really like that thanks. -- Dennis Gilmore, RHCE Proud Australian From buildsys at fedoraproject.org Thu Nov 30 12:46:37 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 30 Nov 2006 12:46:37 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-11-30 Message-ID: <20061130124637.14626.78104@extras64.linux.duke.edu> New report for: oliver AT linux-kernel.at package: syck-php - 0.55-10.fc6.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.6 package: syck-php - 0.55-10.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.6 package: syck-php - 0.55-10.fc6.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.6 ====================================================================== New report for: pertusus AT free.fr package: grads - 1.9b4-19.fc7.ppc from fedora-extras-development-ppc unresolved deps: wgrib package: grads - 1.9b4-19.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: wgrib package: grads - 1.9b4-19.fc7.i386 from fedora-extras-development-i386 unresolved deps: wgrib ====================================================================== New report for: dakingun AT gmail.com package: gparted - 0.3.1-1.fc6.ppc from fedora-extras-6-ppc unresolved deps: libparted-1.7.so.1 package: gparted - 0.3.1-1.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: libparted-1.7.so.1()(64bit) package: gparted - 0.3.1-1.fc6.i386 from fedora-extras-6-i386 unresolved deps: libparted-1.7.so.1 package: gparted - 0.3.1-1.fc5.ppc from fedora-extras-5-ppc unresolved deps: libparted-1.7.so.1 package: gparted - 0.3.1-1.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libparted-1.7.so.1()(64bit) package: gparted - 0.3.1-1.fc5.i386 from fedora-extras-5-i386 unresolved deps: libparted-1.7.so.1 ====================================================================== New report for: steve AT silug.org package: qtparted - 0.4.5-9.fc6.ppc from fedora-extras-6-ppc unresolved deps: libparted-1.7.so.1 package: qtparted - 0.4.5-9.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: libparted-1.7.so.1()(64bit) package: qtparted - 0.4.5-9.fc6.i386 from fedora-extras-6-i386 unresolved deps: libparted-1.7.so.1 package: qtparted - 0.4.5-9.fc5.ppc from fedora-extras-5-ppc unresolved deps: libparted-1.7.so.1 package: qtparted - 0.4.5-9.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libparted-1.7.so.1()(64bit) package: qtparted - 0.4.5-9.fc5.i386 from fedora-extras-5-i386 unresolved deps: libparted-1.7.so.1 ====================================================================== Summary of broken packages (by owner): andreas.bierfert AT lowlatency.de airsnort - 0.2.7e-10.fc6.i386 airsnort - 0.2.7e-10.fc6.ppc airsnort - 0.2.7e-10.fc6.x86_64 centericq - 4.21.0-8.fc6.i386 (30 days) centericq - 4.21.0-8.fc6.ppc (30 days) centericq - 4.21.0-8.fc6.x86_64 (30 days) libnasl - 2.2.8-2.fc6.i386 libnasl - 2.2.8-2.fc6.i386 libnasl - 2.2.8-2.fc6.ppc libnasl - 2.2.8-2.fc6.x86_64 libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (33 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (33 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (33 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (33 days) libopensync-plugin-palm - 0.19-1.fc6.i386 libopensync-plugin-palm - 0.19-1.fc6.i386 libopensync-plugin-palm - 0.19-1.fc6.ppc libopensync-plugin-palm - 0.19-1.fc6.x86_64 nessus-client - 2.2.7-2.fc6.i386 nessus-client - 2.2.7-2.fc6.ppc nessus-client - 2.2.7-2.fc6.x86_64 nessus-gui - 2.2.7-2.fc6.i386 nessus-gui - 2.2.7-2.fc6.ppc nessus-gui - 2.2.7-2.fc6.x86_64 nessus-server - 2.2.7-2.fc6.i386 nessus-server - 2.2.7-2.fc6.ppc nessus-server - 2.2.7-2.fc6.x86_64 orange - 0.3-3.cvs20051118.fc6.i386 (37 days) sylpheed-claws - 2.6.0-1.fc7.i386 sylpheed-claws - 2.6.0-1.fc7.i386 sylpheed-claws - 2.6.0-1.fc7.ppc sylpheed-claws - 2.6.0-1.fc7.x86_64 sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (61 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (61 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (61 days) bnocera AT redhat.com driftnet - 0.1.6-11.i386 driftnet - 0.1.6-11.ppc driftnet - 0.1.6-11.x86_64 dakingun AT gmail.com gparted - 0.3.1-1.fc5.i386 gparted - 0.3.1-1.fc5.ppc gparted - 0.3.1-1.fc5.x86_64 gparted - 0.3.1-1.fc6.i386 gparted - 0.3.1-1.fc6.ppc gparted - 0.3.1-1.fc6.x86_64 dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (76 days) plague - 0.4.4.1-2.fc3.noarch (76 days) plague - 0.4.4.1-2.fc4.noarch (76 days) plague - 0.4.4.1-2.fc4.noarch (76 days) plague - 0.4.4.1-2.fc4.noarch (76 days) dennis AT ausil.us snort - 2.6.1.1-1.fc7.i386 snort - 2.6.1.1-1.fc7.ppc snort - 2.6.1.1-1.fc7.x86_64 snort-bloat - 2.6.1.1-1.fc7.i386 snort-bloat - 2.6.1.1-1.fc7.ppc snort-bloat - 2.6.1.1-1.fc7.x86_64 snort-mysql - 2.6.1.1-1.fc7.i386 snort-mysql - 2.6.1.1-1.fc7.ppc snort-mysql - 2.6.1.1-1.fc7.x86_64 snort-mysql+flexresp - 2.6.1.1-1.fc7.i386 snort-mysql+flexresp - 2.6.1.1-1.fc7.ppc snort-mysql+flexresp - 2.6.1.1-1.fc7.x86_64 snort-plain+flexresp - 2.6.1.1-1.fc7.i386 snort-plain+flexresp - 2.6.1.1-1.fc7.ppc snort-plain+flexresp - 2.6.1.1-1.fc7.x86_64 snort-postgresql - 2.6.1.1-1.fc7.i386 snort-postgresql - 2.6.1.1-1.fc7.ppc snort-postgresql - 2.6.1.1-1.fc7.x86_64 snort-postgresql+flexresp - 2.6.1.1-1.fc7.i386 snort-postgresql+flexresp - 2.6.1.1-1.fc7.ppc snort-postgresql+flexresp - 2.6.1.1-1.fc7.x86_64 snort-snmp - 2.6.1.1-1.fc7.i386 snort-snmp - 2.6.1.1-1.fc7.ppc snort-snmp - 2.6.1.1-1.fc7.x86_64 snort-snmp+flexresp - 2.6.1.1-1.fc7.i386 snort-snmp+flexresp - 2.6.1.1-1.fc7.ppc snort-snmp+flexresp - 2.6.1.1-1.fc7.x86_64 jdennis AT redhat.com cyrus-imapd - 2.3.7-4.fc6.i386 cyrus-imapd - 2.3.7-4.fc6.i386 cyrus-imapd - 2.3.7-4.fc6.ppc cyrus-imapd - 2.3.7-4.fc6.x86_64 jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (52 days) linphone - 1.2.0-4.fc5.ppc (52 days) linphone - 1.2.0-4.fc5.x86_64 (52 days) joost.soeterbroek AT gmail.com stonith - 2.0.7-4.fc7.i386 stonith - 2.0.7-4.fc7.i386 stonith - 2.0.7-4.fc7.ppc stonith - 2.0.7-4.fc7.x86_64 jpo AT di.uminho.pt nagios-plugins-snmp-disk-proc - 1.0-1.fc6.i386 nagios-plugins-snmp-disk-proc - 1.0-1.fc6.ppc nagios-plugins-snmp-disk-proc - 1.0-1.fc6.x86_64 jwilson AT redhat.com ip6sic - 0.1-4.fc6.i386 ip6sic - 0.1-4.fc6.ppc ip6sic - 0.1-4.fc6.x86_64 karlthered AT gmail.com gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.i386 (8 days) gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.i386 (8 days) gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.ppc (8 days) gtkmozembedmm - 1.4.2.cvs20060817-5.fc7.x86_64 (8 days) mgarski AT post.pl digikam-doc - 0.8.2-3.fc6.noarch digikam-doc - 0.8.2-3.fc6.noarch digikam-doc - 0.8.2-3.fc6.noarch oliver AT linux-kernel.at syck-php - 0.55-10.fc6.i386 (14 days) syck-php - 0.55-10.fc6.ppc (14 days) syck-php - 0.55-10.fc6.x86_64 (14 days) syck-php - 0.55-9.fc5.i386 (42 days) syck-php - 0.55-9.fc5.ppc (42 days) syck-php - 0.55-9.fc5.x86_64 (42 days) orion AT cora.nwra.com apcupsd - 3.12.4-3.fc6.i386 apcupsd - 3.12.4-3.fc6.ppc apcupsd - 3.12.4-3.fc6.x86_64 apcupsd-cgi - 3.12.4-3.fc6.i386 apcupsd-cgi - 3.12.4-3.fc6.ppc apcupsd-cgi - 3.12.4-3.fc6.x86_64 pertusus AT free.fr grads - 1.9b4-19.fc7.i386 (14 days) grads - 1.9b4-19.fc7.ppc (14 days) grads - 1.9b4-19.fc7.x86_64 (14 days) petersen AT redhat.com ghc-gtk2hs - 0.9.10-4.fc6.i386 (27 days) ghc-gtk2hs - 0.9.10-4.fc6.ppc (27 days) ghc-gtk2hs - 0.9.10-4.fc6.x86_64 (27 days) ghc642-gtk2hs - 0.9.10-4.fc6.i386 (27 days) ghc642-gtk2hs - 0.9.10-4.fc6.ppc (27 days) ghc642-gtk2hs - 0.9.10-4.fc6.x86_64 (27 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.i386 (27 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.ppc (27 days) ghc642-gtk2hs-mozembed - 0.9.10-4.fc6.x86_64 (27 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (32 days) redhat-bugzilla AT linuxnetz.de tcpick - 0.2.1-10.fc6.i386 tcpick - 0.2.1-10.fc6.ppc tcpick - 0.2.1-10.fc6.x86_64 steve AT silug.org qtparted - 0.4.5-9.fc5.i386 qtparted - 0.4.5-9.fc5.ppc qtparted - 0.4.5-9.fc5.x86_64 qtparted - 0.4.5-9.fc6.i386 qtparted - 0.4.5-9.fc6.ppc qtparted - 0.4.5-9.fc6.x86_64 tcallawa AT redhat.com gambas-runtime - 1.0.17-6.fc7.i386 (7 days) gambas-runtime - 1.0.17-6.fc7.ppc (7 days) ====================================================================== Broken packages in fedora-extras-development-ppc: airsnort-0.2.7e-10.fc6.ppc requires libpcap.so.0.9.4 apcupsd-3.12.4-3.fc6.ppc requires libnetsnmp.so.10 apcupsd-cgi-3.12.4-3.fc6.ppc requires libnetsnmp.so.10 centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 cyrus-imapd-2.3.7-4.fc6.ppc requires libnetsnmpmibs.so.10 cyrus-imapd-2.3.7-4.fc6.ppc requires libnetsnmphelpers.so.10 cyrus-imapd-2.3.7-4.fc6.ppc requires libnetsnmp.so.10 cyrus-imapd-2.3.7-4.fc6.ppc requires libnetsnmpagent.so.10 digikam-doc-0.8.2-3.fc6.noarch requires digikam = 0:0.8.2 driftnet-0.1.6-11.ppc requires libpcap.so.0.9.4 gambas-runtime-1.0.17-6.fc7.ppc requires libgettextlib-0.15.so ghc-gtk2hs-0.9.10-4.fc6.ppc requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.ppc requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.ppc requires ghc642 grads-1.9b4-19.fc7.ppc requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.ppc requires gecko-libs = 0:2.0 ip6sic-0.1-4.fc6.ppc requires libpcap.so.0.9.4 libnasl-2.2.8-2.fc6.ppc requires libpcap.so.0.9.4 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 libopensync-plugin-palm-0.19-1.fc6.ppc requires libpisock.so.8 nagios-plugins-snmp-disk-proc-1.0-1.fc6.ppc requires libnetsnmp.so.10 nessus-client-2.2.7-2.fc6.ppc requires libpcap.so.0.9.4 nessus-gui-2.2.7-2.fc6.ppc requires libpcap.so.0.9.4 nessus-server-2.2.7-2.fc6.ppc requires libpcap.so.0.9.4 snort-2.6.1.1-1.fc7.ppc requires libpcap.so.0.9.4 snort-bloat-2.6.1.1-1.fc7.ppc requires libpcap.so.0.9.4 snort-mysql+flexresp-2.6.1.1-1.fc7.ppc requires libpcap.so.0.9.4 snort-mysql-2.6.1.1-1.fc7.ppc requires libpcap.so.0.9.4 snort-plain+flexresp-2.6.1.1-1.fc7.ppc requires libpcap.so.0.9.4 snort-postgresql+flexresp-2.6.1.1-1.fc7.ppc requires libpcap.so.0.9.4 snort-postgresql-2.6.1.1-1.fc7.ppc requires libpcap.so.0.9.4 snort-snmp+flexresp-2.6.1.1-1.fc7.ppc requires libpcap.so.0.9.4 snort-snmp-2.6.1.1-1.fc7.ppc requires libpcap.so.0.9.4 stonith-2.0.7-4.fc7.ppc requires libnetsnmp.so.10 syck-php-0.55-10.fc6.ppc requires php = 0:5.1.6 sylpheed-claws-2.6.0-1.fc7.ppc requires libpisock.so.8 tcpick-0.2.1-10.fc6.ppc requires libpcap.so.0.9.4 ====================================================================== Broken packages in fedora-extras-development-x86_64: airsnort-0.2.7e-10.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) apcupsd-3.12.4-3.fc6.x86_64 requires libnetsnmp.so.10()(64bit) apcupsd-cgi-3.12.4-3.fc6.x86_64 requires libnetsnmp.so.10()(64bit) centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) cyrus-imapd-2.3.7-4.fc6.i386 requires libnetsnmpmibs.so.10 cyrus-imapd-2.3.7-4.fc6.i386 requires libnetsnmphelpers.so.10 cyrus-imapd-2.3.7-4.fc6.i386 requires libnetsnmp.so.10 cyrus-imapd-2.3.7-4.fc6.i386 requires libnetsnmpagent.so.10 cyrus-imapd-2.3.7-4.fc6.x86_64 requires libnetsnmpmibs.so.10()(64bit) cyrus-imapd-2.3.7-4.fc6.x86_64 requires libnetsnmp.so.10()(64bit) cyrus-imapd-2.3.7-4.fc6.x86_64 requires libnetsnmphelpers.so.10()(64bit) cyrus-imapd-2.3.7-4.fc6.x86_64 requires libnetsnmpagent.so.10()(64bit) digikam-doc-0.8.2-3.fc6.noarch requires digikam = 0:0.8.2 driftnet-0.1.6-11.x86_64 requires libpcap.so.0.9.4()(64bit) ghc-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.x86_64 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.x86_64 requires ghc642 gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 grads-1.9b4-19.fc7.x86_64 requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.i386 requires gecko-libs = 0:2.0 gtkmozembedmm-1.4.2.cvs20060817-5.fc7.x86_64 requires gecko-libs = 0:2.0 ip6sic-0.1-4.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) libnasl-2.2.8-2.fc6.i386 requires libpcap.so.0.9.4 libnasl-2.2.8-2.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) libopensync-plugin-palm-0.19-1.fc6.i386 requires libpisock.so.8 libopensync-plugin-palm-0.19-1.fc6.x86_64 requires libpisock.so.8()(64bit) nagios-plugins-snmp-disk-proc-1.0-1.fc6.x86_64 requires libnetsnmp.so.10()(64bit) nessus-client-2.2.7-2.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) nessus-gui-2.2.7-2.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) nessus-server-2.2.7-2.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 snort-2.6.1.1-1.fc7.x86_64 requires libpcap.so.0.9.4()(64bit) snort-bloat-2.6.1.1-1.fc7.x86_64 requires libpcap.so.0.9.4()(64bit) snort-mysql+flexresp-2.6.1.1-1.fc7.x86_64 requires libpcap.so.0.9.4()(64bit) snort-mysql-2.6.1.1-1.fc7.x86_64 requires libpcap.so.0.9.4()(64bit) snort-plain+flexresp-2.6.1.1-1.fc7.x86_64 requires libpcap.so.0.9.4()(64bit) snort-postgresql+flexresp-2.6.1.1-1.fc7.x86_64 requires libpcap.so.0.9.4()(64bit) snort-postgresql-2.6.1.1-1.fc7.x86_64 requires libpcap.so.0.9.4()(64bit) snort-snmp+flexresp-2.6.1.1-1.fc7.x86_64 requires libpcap.so.0.9.4()(64bit) snort-snmp-2.6.1.1-1.fc7.x86_64 requires libpcap.so.0.9.4()(64bit) stonith-2.0.7-4.fc7.i386 requires libnetsnmp.so.10 stonith-2.0.7-4.fc7.x86_64 requires libnetsnmp.so.10()(64bit) syck-php-0.55-10.fc6.x86_64 requires php = 0:5.1.6 sylpheed-claws-2.6.0-1.fc7.i386 requires libpisock.so.8 sylpheed-claws-2.6.0-1.fc7.x86_64 requires libpisock.so.8()(64bit) tcpick-0.2.1-10.fc6.x86_64 requires libpcap.so.0.9.4()(64bit) ====================================================================== Broken packages in fedora-extras-development-i386: airsnort-0.2.7e-10.fc6.i386 requires libpcap.so.0.9.4 apcupsd-3.12.4-3.fc6.i386 requires libnetsnmp.so.10 apcupsd-cgi-3.12.4-3.fc6.i386 requires libnetsnmp.so.10 centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 cyrus-imapd-2.3.7-4.fc6.i386 requires libnetsnmpmibs.so.10 cyrus-imapd-2.3.7-4.fc6.i386 requires libnetsnmphelpers.so.10 cyrus-imapd-2.3.7-4.fc6.i386 requires libnetsnmp.so.10 cyrus-imapd-2.3.7-4.fc6.i386 requires libnetsnmpagent.so.10 digikam-doc-0.8.2-3.fc6.noarch requires digikam = 0:0.8.2 driftnet-0.1.6-11.i386 requires libpcap.so.0.9.4 gambas-runtime-1.0.17-6.fc7.i386 requires libgettextlib-0.15.so ghc-gtk2hs-0.9.10-4.fc6.i386 requires ghc = 0:6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-0.9.10-4.fc6.i386 requires ghc642 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires /usr/bin/ghc-pkg-6.4.2 ghc642-gtk2hs-mozembed-0.9.10-4.fc6.i386 requires ghc642 grads-1.9b4-19.fc7.i386 requires wgrib gtkmozembedmm-1.4.2.cvs20060817-5.fc7.i386 requires gecko-libs = 0:2.0 ip6sic-0.1-4.fc6.i386 requires libpcap.so.0.9.4 libnasl-2.2.8-2.fc6.i386 requires libpcap.so.0.9.4 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-palm-0.19-1.fc6.i386 requires libpisock.so.8 nagios-plugins-snmp-disk-proc-1.0-1.fc6.i386 requires libnetsnmp.so.10 nessus-client-2.2.7-2.fc6.i386 requires libpcap.so.0.9.4 nessus-gui-2.2.7-2.fc6.i386 requires libpcap.so.0.9.4 nessus-server-2.2.7-2.fc6.i386 requires libpcap.so.0.9.4 snort-2.6.1.1-1.fc7.i386 requires libpcap.so.0.9.4 snort-bloat-2.6.1.1-1.fc7.i386 requires libpcap.so.0.9.4 snort-mysql+flexresp-2.6.1.1-1.fc7.i386 requires libpcap.so.0.9.4 snort-mysql-2.6.1.1-1.fc7.i386 requires libpcap.so.0.9.4 snort-plain+flexresp-2.6.1.1-1.fc7.i386 requires libpcap.so.0.9.4 snort-postgresql+flexresp-2.6.1.1-1.fc7.i386 requires libpcap.so.0.9.4 snort-postgresql-2.6.1.1-1.fc7.i386 requires libpcap.so.0.9.4 snort-snmp+flexresp-2.6.1.1-1.fc7.i386 requires libpcap.so.0.9.4 snort-snmp-2.6.1.1-1.fc7.i386 requires libpcap.so.0.9.4 stonith-2.0.7-4.fc7.i386 requires libnetsnmp.so.10 syck-php-0.55-10.fc6.i386 requires php = 0:5.1.6 sylpheed-claws-2.6.0-1.fc7.i386 requires libpisock.so.8 tcpick-0.2.1-10.fc6.i386 requires libpcap.so.0.9.4 ====================================================================== Broken packages in fedora-extras-6-ppc: gparted-0.3.1-1.fc6.ppc requires libparted-1.7.so.1 qtparted-0.4.5-9.fc6.ppc requires libparted-1.7.so.1 ====================================================================== Broken packages in fedora-extras-6-x86_64: gparted-0.3.1-1.fc6.x86_64 requires libparted-1.7.so.1()(64bit) qtparted-0.4.5-9.fc6.x86_64 requires libparted-1.7.so.1()(64bit) ====================================================================== Broken packages in fedora-extras-6-i386: gparted-0.3.1-1.fc6.i386 requires libparted-1.7.so.1 qtparted-0.4.5-9.fc6.i386 requires libparted-1.7.so.1 ====================================================================== Broken packages in fedora-extras-5-ppc: gparted-0.3.1-1.fc5.ppc requires libparted-1.7.so.1 linphone-1.2.0-4.fc5.ppc requires libortp.so.2 qtparted-0.4.5-9.fc5.ppc requires libparted-1.7.so.1 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 ====================================================================== Broken packages in fedora-extras-5-x86_64: gparted-0.3.1-1.fc5.x86_64 requires libparted-1.7.so.1()(64bit) linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) qtparted-0.4.5-9.fc5.x86_64 requires libparted-1.7.so.1()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 ====================================================================== Broken packages in fedora-extras-5-i386: gparted-0.3.1-1.fc5.i386 requires libparted-1.7.so.1 linphone-1.2.0-4.fc5.i386 requires libortp.so.2 qtparted-0.4.5-9.fc5.i386 requires libparted-1.7.so.1 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 ====================================================================== Broken packages in fedora-extras-4-ppc: plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 ====================================================================== Broken packages in fedora-extras-4-x86_64: plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) ====================================================================== Broken packages in fedora-extras-4-i386: plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 ====================================================================== Broken packages in fedora-extras-3-x86_64: plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== Broken packages in fedora-extras-3-i386: plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 From jamatos at fc.up.pt Thu Nov 30 12:54:01 2006 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Thu, 30 Nov 2006 12:54:01 +0000 Subject: extras-buildsys/utils/pushscript Push.py,1.19,1.20 In-Reply-To: <200611300633.12318.dennis@ausil.us> References: <200611301056.kAUAunBl005002@cvs-int.fedora.redhat.com> <200611300633.12318.dennis@ausil.us> Message-ID: <200611301254.02705.jamatos@fc.up.pt> On Thursday 30 November 2006 12:33 pm, Dennis Gilmore wrote: > > Michael, > > I really like that thanks. Me too, thanks Michael. :-) > -- > Dennis Gilmore, RHCE > Proud Australian -- Jos? Ab?lio From katzj at redhat.com Thu Nov 30 15:52:45 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 30 Nov 2006 10:52:45 -0500 Subject: New Comps Groups In-Reply-To: <1164860435.11786.107.camel@localhost.localdomain> References: <200611281452.58273.jkeating@redhat.com> <1164844764.11786.15.camel@localhost.localdomain> <200611292139.43243.jkeating@redhat.com> <1164856782.11786.101.camel@localhost.localdomain> <1164858551.7311.112.camel@cutter> <1164860435.11786.107.camel@localhost.localdomain> Message-ID: <1164901965.12591.9.camel@aglarond.local> On Wed, 2006-11-29 at 20:20 -0800, Toshio Kuratomi wrote: > On Wed, 2006-11-29 at 22:49 -0500, seth vidal wrote: > > I don't see anything stopping that from happening now. > > > > Either: > > 1. write the above interface for repodata and then have yum be able to > > understand that info > > 2. use the existing comps format and just have yum be able to look up > > pkgs by the group they belong to. So for the above you would do: > > Take the intersection of /Language/Python, /Development/Library, > > and /Security/Cryptography and display those pkgs. > > Then comps looks like: > > > > > > /Security/Cryptography > > python-gpgme > > gpgme > > gnupg > > > > > > /Development/Library > > python-gpgme > > gpgme > > > > > So perhaps all we need is free reign to do this in comps. Which, from > previous messages from jeremy, seems to imply we would need to have > separate comps.xml files for the installer and for the repo. The "problem" is that if you do something like this, you _really_ don't want to be using the current UI. Rather than focusing on the question of "how do I fit this in comps" or "how do I list every package because oh my god, how else do I find something", the _real_ question is trying to figure out what the user experience we're trying to get at is, get some mock ups and then figure out what the "right" implementation path is from there. Jeremy From katzj at redhat.com Thu Nov 30 15:53:48 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 30 Nov 2006 10:53:48 -0500 Subject: New Comps Groups In-Reply-To: <20061130122037.GA8103@jadzia.bu.edu> References: <200611281452.58273.jkeating@redhat.com> <1164844764.11786.15.camel@localhost.localdomain> <200611292139.43243.jkeating@redhat.com> <1164856782.11786.101.camel@localhost.localdomain> <1164858551.7311.112.camel@cutter> <1164860435.11786.107.camel@localhost.localdomain> <1164861453.7311.125.camel@cutter> <20061130122037.GA8103@jadzia.bu.edu> Message-ID: <1164902028.12591.11.camel@aglarond.local> (are we off-topic for extras-list yet? :) On Thu, 2006-11-30 at 07:20 -0500, Matthew Miller wrote: > On Wed, Nov 29, 2006 at 11:37:33PM -0500, seth vidal wrote: > > yum concatenates comps contents across repos. So you could have a > > grouping-only repo that is only hit post-install. > > The grouping-only repo would have nothing besides a comps file in it. > > spiffy, huh? :) > > Also, bear in mind that the true options are overidden. > > Hey Jeremy -- is it time to entirely move the installclasses/*.py to living > in the repo tree yet? Then, get rid of the tag entirely so this > decision is clearly made in only one place? There are definitely changes that need to happen with how the install classes work... moving the python files into the repo tree isn't the answer, though, as that introduces whole new problems :) Jeremy From mattdm at mattdm.org Thu Nov 30 16:10:51 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 30 Nov 2006 11:10:51 -0500 Subject: New Comps Groups In-Reply-To: <1164902028.12591.11.camel@aglarond.local> References: <200611281452.58273.jkeating@redhat.com> <1164844764.11786.15.camel@localhost.localdomain> <200611292139.43243.jkeating@redhat.com> <1164856782.11786.101.camel@localhost.localdomain> <1164858551.7311.112.camel@cutter> <1164860435.11786.107.camel@localhost.localdomain> <1164861453.7311.125.camel@cutter> <20061130122037.GA8103@jadzia.bu.edu> <1164902028.12591.11.camel@aglarond.local> Message-ID: <20061130161051.GA18057@jadzia.bu.edu> On Thu, Nov 30, 2006 at 10:53:48AM -0500, Jeremy Katz wrote: > (are we off-topic for extras-list yet? :) Maybe a little. We can take this anywhere you like. :) > There are definitely changes that need to happen with how the install > classes work... moving the python files into the repo tree isn't the > answer, though, as that introduces whole new problems :) Yeah, but I think those are better problems :) It means that you can make install-policy changes without needing to rebuild any packages. Same logic as for moving group information out of spec files. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From notting at redhat.com Thu Nov 30 16:27:59 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 30 Nov 2006 11:27:59 -0500 Subject: New Comps Groups In-Reply-To: <20061130161051.GA18057@jadzia.bu.edu> References: <200611281452.58273.jkeating@redhat.com> <1164844764.11786.15.camel@localhost.localdomain> <200611292139.43243.jkeating@redhat.com> <1164856782.11786.101.camel@localhost.localdomain> <1164858551.7311.112.camel@cutter> <1164860435.11786.107.camel@localhost.localdomain> <1164861453.7311.125.camel@cutter> <20061130122037.GA8103@jadzia.bu.edu> <1164902028.12591.11.camel@aglarond.local> <20061130161051.GA18057@jadzia.bu.edu> Message-ID: <20061130162759.GA23978@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > > There are definitely changes that need to happen with how the install > > classes work... moving the python files into the repo tree isn't the > > answer, though, as that introduces whole new problems :) > > Yeah, but I think those are better problems :) > > It means that you can make install-policy changes without needing to rebuild > any packages. Same logic as for moving group information out of spec files. Ah, but what if you have more information than is just encoded in comps? Say a default list of services to start, or something. Bill From cweyl at alumni.drew.edu Thu Nov 30 16:45:53 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 30 Nov 2006 08:45:53 -0800 Subject: cvs flags for comps? Message-ID: <7dd7ab490611300845i72813b16pebd76b5dc2b5fd@mail.gmail.com> Ok, so after reading through the (rather long) threads on comps.xml, autogeneration, etc, etc, two things stuck in my head from it. 1) It's not always desirable for all packages to be in comps (perl-*, python-*, etc). 2) We need an automated way to tell if a package should be left out of comps, or if its omission was an oversight. So... while waiting for the package db, would it be possible to use a cvs "flag" file along the lines of what we do with needs.rebuild? e.g., a branch directory contains: * 'no.comps' as an empty (or containing reason why) file if it should not be listed in comps, or * 'comps' as a file with the groups (one per line) it should be listed under. This would give an easy, per branch way to determine if a package should be listed in comps, if so where, or if it's being intentionally left out by the maintainer. Automated scripts can look for these to add packages or rebuild comps*.in; branches missing the file can have "huh?" notes generated to owners or summary to extras list. It has the added advantage of allowing maintainers to keep this info directly with the package. Thoughts? Good / bad / crazy? -Chris -- Chris Weyl Ex astris, scientia From notting at redhat.com Thu Nov 30 16:50:15 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 30 Nov 2006 11:50:15 -0500 Subject: cvs flags for comps? In-Reply-To: <7dd7ab490611300845i72813b16pebd76b5dc2b5fd@mail.gmail.com> References: <7dd7ab490611300845i72813b16pebd76b5dc2b5fd@mail.gmail.com> Message-ID: <20061130165015.GA24367@nostromo.devel.redhat.com> Chris Weyl (cweyl at alumni.drew.edu) said: > This would give an easy, per branch way to determine if a package > should be listed in comps, if so where, or if it's being intentionally > left out by the maintainer. Automated scripts can look for these to > add packages or rebuild comps*.in; branches missing the file can have > "huh?" notes generated to owners or summary to extras list. It has > the added advantage of allowing maintainers to keep this info directly > with the package. > > Thoughts? Good / bad / crazy? It doesn't necessarily help keyword-based organization, but it could be useful. The idea that hit me today was that, more than *-devel, or apps, or any other groups, the groups that need to be maintained in as automated a fashion as possible are the langsupport groups. (dictionaries, fonts, OO.o/KDE langpacks.) Bill From a.badger at gmail.com Thu Nov 30 17:29:52 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 30 Nov 2006 09:29:52 -0800 Subject: New Comps Groups In-Reply-To: <1164901965.12591.9.camel@aglarond.local> References: <200611281452.58273.jkeating@redhat.com> <1164844764.11786.15.camel@localhost.localdomain> <200611292139.43243.jkeating@redhat.com> <1164856782.11786.101.camel@localhost.localdomain> <1164858551.7311.112.camel@cutter> <1164860435.11786.107.camel@localhost.localdomain> <1164901965.12591.9.camel@aglarond.local> Message-ID: <1164907792.11786.176.camel@localhost.localdomain> On Thu, 2006-11-30 at 10:52 -0500, Jeremy Katz wrote: > On Wed, 2006-11-29 at 20:20 -0800, Toshio Kuratomi wrote: > > On Wed, 2006-11-29 at 22:49 -0500, seth vidal wrote: > > > I don't see anything stopping that from happening now. > > > > > > Either: > > > 1. write the above interface for repodata and then have yum be able to > > > understand that info > > > 2. use the existing comps format and just have yum be able to look up > > > pkgs by the group they belong to. So for the above you would do: > > > Take the intersection of /Language/Python, /Development/Library, > > > and /Security/Cryptography and display those pkgs. > > > Then comps looks like: > > > > > > > > > /Security/Cryptography > > > python-gpgme > > > gpgme > > > gnupg > > > > > > > > > /Development/Library > > > python-gpgme > > > gpgme > > > > > > > > So perhaps all we need is free reign to do this in comps. Which, from > > previous messages from jeremy, seems to imply we would need to have > > separate comps.xml files for the installer and for the repo. > > The "problem" is that if you do something like this, you _really_ don't > want to be using the current UI. There's an assumption here of what the current UI is. From your background and the background of comps I would assume that "current UI" means anaconda's interface. However, comps.xml has been proposed as a replacement for the rpm group tag in general. Repoview already attempts to do this (with a horrible number of entries in the uncategorized listing). apt/synaptic and smart currently use the rpm group tag and it was proposed that they should be ported to use comps instead of rpm::group. I would say that apt and smart's UI would not suffer from a migration to comps provided that comps lists all the packages in the repository. > Rather than focusing on the question > of "how do I fit this in comps" or "how do I list every package because > oh my god, how else do I find something", the _real_ question is trying > to figure out what the user experience we're trying to get at is, get > some mock ups and then figure out what the "right" implementation path > is from there. > User Experience Objective Allow a user to view a subset of packages in a set of repositories that matches categories of software that they are interested in installing. This allows the user to more quickly discover a package that fills a need for them. Interface1 1) Select a group from all groups valid for the repository 2) List all packages which match that group. 3) Allow the user to select another group from the groups that these packages have. Repeat from 2 until A) the list of other groups would have a single entry, B) there's only a single package in the package list. C) User has left this interface Interface2 yum groupsearch Development Python Cryptography Finds all packages in the repositories whose group information contains all of those patterns. -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 mattdm at mattdm.org Thu Nov 30 18:14:32 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 30 Nov 2006 13:14:32 -0500 Subject: New Comps Groups In-Reply-To: <20061130162759.GA23978@nostromo.devel.redhat.com> References: <1164844764.11786.15.camel@localhost.localdomain> <200611292139.43243.jkeating@redhat.com> <1164856782.11786.101.camel@localhost.localdomain> <1164858551.7311.112.camel@cutter> <1164860435.11786.107.camel@localhost.localdomain> <1164861453.7311.125.camel@cutter> <20061130122037.GA8103@jadzia.bu.edu> <1164902028.12591.11.camel@aglarond.local> <20061130161051.GA18057@jadzia.bu.edu> <20061130162759.GA23978@nostromo.devel.redhat.com> Message-ID: <20061130181432.GA22301@jadzia.bu.edu> On Thu, Nov 30, 2006 at 11:27:59AM -0500, Bill Nottingham wrote: > > > There are definitely changes that need to happen with how the install > > > classes work... moving the python files into the repo tree isn't the > > > answer, though, as that introduces whole new problems :) > > Yeah, but I think those are better problems :) > > It means that you can make install-policy changes without needing to rebuild > > any packages. Same logic as for moving group information out of spec files. > Ah, but what if you have more information than is just encoded in comps? > Say a default list of services to start, or something. Well, exactly -- more good stuff to move out of hard-coding into anaconda. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From kevin.kofler at chello.at Thu Nov 30 18:40:35 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 30 Nov 2006 18:40:35 +0000 (UTC) Subject: UML Generating tool ? References: <4865.14102.qm@web36801.mail.mud.yahoo.com> Message-ID: Linus Walleij writes: > I always use Dia for creating UML charts. That's one of the real good Dia > features. However, Dia is a generic diagram program and doesn't offer all the UML-specific features Umbrello offers, such as code generation and parsing (reverse-engineering a diagram from some code). I also believe Umbrello supports a bigger subset of UML. On the other hand, Dia is more flexible, e.g. you can get away with mixing in non-standard notations (whether that's a good thing or not depends on what the UML is being used for ;-) ) or simply drawing standard-compliant notations outside the supported subset of UML (neither Dia nor Umbrello support all of UML) by hand. But that flexibility also means you have to draw some stuff by hand which Umbrello figures out automatically for you. Kevin Kofler From jkeating at redhat.com Thu Nov 30 18:45:20 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 30 Nov 2006 13:45:20 -0500 Subject: New Comps Groups In-Reply-To: <1164907792.11786.176.camel@localhost.localdomain> References: <1164901965.12591.9.camel@aglarond.local> <1164907792.11786.176.camel@localhost.localdomain> Message-ID: <200611301345.24020.jkeating@redhat.com> On Thursday 30 November 2006 12:29, Toshio Kuratomi wrote: > I would say that apt and smart's UI would not suffer from a > migration to comps provided that comps lists all the packages in the > repository. Why do all packages have to be listed in comps? The grouping metadata can list packages being in some groups, and then if a package isn't in any group, the tool (apt/smart) could represent that as 'Ungrouped' or however you want to phrase it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Thu Nov 30 18:58:07 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 30 Nov 2006 18:58:07 +0000 (UTC) Subject: uml generating tool References: <20061126173347.12546.qmail@web36807.mail.mud.yahoo.com> Message-ID: Amit Dey writes: > Well Parag...I undertand that Ubmrello is an UML Modelling tool. But is a KDE based application. > ? > How about if I make something for GNOME. Would that be useful ? No. You can use Umbrello just fine under GNOME, apps from any X11-based desktop work on any other. Sure, you have to install kdesdk and its dependencies, but disk space is cheap. It would be much more productive to work on common widget themes. For example, if you're a GNOME developer, start by doing a Plastik-like theme for GNOME - Clearlooks is a good starting point, but there are noticeable differences, so a theme based on the Clearlooks engine modified to match the Plastik look would be great. Similarly, a Clearlooks-like theme for Qt/KDE 3 would also be useful (Qt 4 has one already: Cleanlooks). Right now, Bluecurve is pretty much the only option for a consistent theme, and AFAIK it doesn't have a Qt 4 port available as of now (only GTK+/GNOME 2 and Qt/KDE 3, and a GTK+ 1 version showing GTK+ 1's limitations). It would be great to have more. With a common widget theme, you might not even _notice_ anymore whether the apps you use are GNOME or KDE apps, so there's no need to reinvent applications. (And yes, I'm still using Bluecurve throughout. IMHO, consistency is more important than looking "cool" or "modern". The big problem with all those new themes is that they're all developed with a single toolkit/desktop in mind, so each time they leave behind both the other big desktop and all the apps which use non-mainstream or legacy toolkits. There are still several toolkits around supporting only Motif-style look!) Kevin Kofler From a.badger at gmail.com Thu Nov 30 19:32:11 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 30 Nov 2006 11:32:11 -0800 Subject: New Comps Groups In-Reply-To: <200611301345.24020.jkeating@redhat.com> References: <1164901965.12591.9.camel@aglarond.local> <1164907792.11786.176.camel@localhost.localdomain> <200611301345.24020.jkeating@redhat.com> Message-ID: <1164915131.11786.194.camel@localhost.localdomain> On Thu, 2006-11-30 at 13:45 -0500, Jesse Keating wrote: > On Thursday 30 November 2006 12:29, Toshio Kuratomi wrote: > > I would say that apt and smart's UI would not suffer from a > > migration to comps provided that comps lists all the packages in the > > repository. > > Why do all packages have to be listed in comps? The grouping metadata can > list packages being in some groups, and then if a package isn't in any group, > the tool (apt/smart) could represent that as 'Ungrouped' or however you want > to phrase it. > http://fedoraproject.org/extras/6/x86_64/repodata/repoview/__nogroup__.group.html I'm writing an email application and want to find a library to help me do signing and encryption. Do you know if Fedora includes one? I'm looking for something that I can use to make rpms in a clean chroot. Is there a package for something like that in Fedora? I'm working on some surveying software and I need to do a lot of work with maps, coordinate plotting, etc. What libraries are available in Fedora to help me get my work done? There is software to answer all these questions in Fedora but it's not listed in comps. Just look at the repoview page and you'll see why Ungrouped leads to a horrible end-user experience. -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 nicolas.mailhot at laposte.net Thu Nov 30 19:51:34 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 30 Nov 2006 20:51:34 +0100 Subject: New Comps Groups In-Reply-To: <200611301345.24020.jkeating@redhat.com> References: <1164901965.12591.9.camel@aglarond.local> <1164907792.11786.176.camel@localhost.localdomain> <200611301345.24020.jkeating@redhat.com> Message-ID: <1164916295.8160.74.camel@rousalka.dyndns.org> Le jeudi 30 novembre 2006 ? 13:45 -0500, Jesse Keating a ?crit : > On Thursday 30 November 2006 12:29, Toshio Kuratomi wrote: > > I would say that apt and smart's UI would not suffer from a > > migration to comps provided that comps lists all the packages in the > > repository. > > Why do all packages have to be listed in comps? The grouping metadata can > list packages being in some groups, and then if a package isn't in any group, > the tool (apt/smart) could represent that as 'Ungrouped' or however you want > to phrase it. Why to you want to impose the policy of one user of this file (anaconda) on others ? Defining groups for anaconda use and lumping everything else in an anaconda-does-not-care limbo is not the answer. The answer is to categorise everything, and let apps define the filtering they want separately. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From wtogami at redhat.com Thu Nov 30 19:56:26 2006 From: wtogami at redhat.com (Warren Togami) Date: Thu, 30 Nov 2006 14:56:26 -0500 Subject: Orphan Colin Charles packages? Message-ID: <456F376A.7070705@redhat.com> It seems that Colin Charles' last CVS commit was August, 2005. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212742 Perhaps time to orphan his packages? Warren Togami wtogami at redhat.com From nicolas.mailhot at laposte.net Thu Nov 30 20:00:38 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 30 Nov 2006 21:00:38 +0100 Subject: cvs flags for comps? In-Reply-To: <7dd7ab490611300845i72813b16pebd76b5dc2b5fd@mail.gmail.com> References: <7dd7ab490611300845i72813b16pebd76b5dc2b5fd@mail.gmail.com> Message-ID: <1164916841.8160.83.camel@rousalka.dyndns.org> Le jeudi 30 novembre 2006 ? 08:45 -0800, Chris Weyl a ?crit : > Ok, so after reading through the (rather long) threads on comps.xml, > autogeneration, etc, etc, two things stuck in my head from it. ... > Thoughts? Good / bad / crazy? If things come to this, I'd tend to totally ignore comps and let the people who want to restrict comps use to a few select apps maintain it alone. If they don't want to share their toy I don't see why the rest of the project should do their work for them. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jon at fedoraunity.org Thu Nov 30 20:09:06 2006 From: jon at fedoraunity.org (Jon Steffan) Date: Thu, 30 Nov 2006 13:09:06 -0700 Subject: Plone - Zope on Fedora Core 4 In-Reply-To: <80d7e4090611291323h50bf69ffo95d70f89d67552e@mail.gmail.com> References: <456C9B4E.8020004@fedoraunity.org> <20061128211544.GB12089@jadzia.bu.edu> <80d7e4090611291323h50bf69ffo95d70f89d67552e@mail.gmail.com> Message-ID: <456F3A62.5070004@fedoraunity.org> Stephen John Smoogen wrote: > On 11/28/06, Matthew Miller wrote: >> On Tue, Nov 28, 2006 at 01:25:50PM -0700, Jon Steffan wrote: >> > I've been pushing updates to plone and zope and would like to get >> > FC4 updated as FC4 is still offered by many hosting companies. The >> Plone >> >> We need to push those hosting companies to upgrade. FC4 is not safe for >> server systems. >> > > It would be nice if we had any leverage.. but there are still large > ones that still run FC2. The fact is that a lot of these companies > have minimal technical staff who can set up an upgrade process where > they are going to be able to upgrade every 6-9 months.. and to be > honest a lot of their customers don't want to. What they and their > customers are wanting is that somm items like Apache/MySQL/PHP/Plone > could be the latest.. but the rest don't touch. > > E.G. For a lot of stuff, Fedora is not what hosting companies are > wanting, but something like Centos or RHEL. > So this thread has seemed to die. Who am I supposed to ask for approval for a new package? I really want to see 'stable' plone and zope in FC4. Jon From fedora at leemhuis.info Thu Nov 30 20:22:52 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 30 Nov 2006 21:22:52 +0100 Subject: Plone - Zope on Fedora Core 4 In-Reply-To: <456F3A62.5070004@fedoraunity.org> References: <456C9B4E.8020004@fedoraunity.org> <20061128211544.GB12089@jadzia.bu.edu> <80d7e4090611291323h50bf69ffo95d70f89d67552e@mail.gmail.com> <456F3A62.5070004@fedoraunity.org> Message-ID: <456F3D9C.9040707@leemhuis.info> Jon Steffan schrieb: > Stephen John Smoogen wrote: >> On 11/28/06, Matthew Miller wrote: >>> On Tue, Nov 28, 2006 at 01:25:50PM -0700, Jon Steffan wrote: >>>> I've been pushing updates to plone and zope and would like to get >>>> FC4 updated [...] > So this thread has seemed to die. Who am I supposed to ask for approval > for a new package? I really want to see 'stable' plone and zope in FC4. Zope and Plone were shipped for FC4 afaics. So according to http://www.fedoraproject.org/wiki/Extras/Policy/EOL it's just fine to build updates for FC4 if there is a good reason for the update. Cu thl From jon at fedoraunity.org Thu Nov 30 20:25:31 2006 From: jon at fedoraunity.org (Jon Steffan) Date: Thu, 30 Nov 2006 13:25:31 -0700 Subject: Plone - Zope on Fedora Core 4 In-Reply-To: <456F3D9C.9040707@leemhuis.info> References: <456C9B4E.8020004@fedoraunity.org> <20061128211544.GB12089@jadzia.bu.edu> <80d7e4090611291323h50bf69ffo95d70f89d67552e@mail.gmail.com> <456F3A62.5070004@fedoraunity.org> <456F3D9C.9040707@leemhuis.info> Message-ID: <456F3E3B.5090704@fedoraunity.org> Thorsten Leemhuis wrote: > Jon Steffan schrieb: > >> Stephen John Smoogen wrote: >> >>> On 11/28/06, Matthew Miller wrote: >>> >>>> On Tue, Nov 28, 2006 at 01:25:50PM -0700, Jon Steffan wrote: >>>> >>>>> I've been pushing updates to plone and zope and would like to get >>>>> FC4 updated [...] >>>>> >> So this thread has seemed to die. Who am I supposed to ask for approval >> for a new package? I really want to see 'stable' plone and zope in FC4. >> > > Zope and Plone were shipped for FC4 afaics. So according to > http://www.fedoraproject.org/wiki/Extras/Policy/EOL > it's just fine to build updates for FC4 if there is a good reason for > the update. > > Cu > thl > > Thl, The issue is that current (plone 2.1.2) will not migrate to the newest version correctly. So, I can just dump in an update. It will break sites. Jon From fedora at leemhuis.info Thu Nov 30 20:40:38 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 30 Nov 2006 21:40:38 +0100 Subject: Plone - Zope on Fedora Core 4 In-Reply-To: <456F3E3B.5090704@fedoraunity.org> References: <456C9B4E.8020004@fedoraunity.org> <20061128211544.GB12089@jadzia.bu.edu> <80d7e4090611291323h50bf69ffo95d70f89d67552e@mail.gmail.com> <456F3A62.5070004@fedoraunity.org> <456F3D9C.9040707@leemhuis.info> <456F3E3B.5090704@fedoraunity.org> Message-ID: <456F41C6.5050704@leemhuis.info> Jon Steffan schrieb: > Thorsten Leemhuis wrote: >> Jon Steffan schrieb: >>> Stephen John Smoogen wrote: >>>> On 11/28/06, Matthew Miller wrote: >>>>> On Tue, Nov 28, 2006 at 01:25:50PM -0700, Jon Steffan wrote: >>>>>> I've been pushing updates to plone and zope and would like to get >>>>>> FC4 updated [...] >>> So this thread has seemed to die. Who am I supposed to ask for approval >>> for a new package? I really want to see 'stable' plone and zope in FC4. >> Zope and Plone were shipped for FC4 afaics. So according to >> http://www.fedoraproject.org/wiki/Extras/Policy/EOL >> it's just fine to build updates for FC4 if there is a good reason for >> the update. > The issue is that current (plone 2.1.2) will not migrate to the > newest version correctly. So, I can just dump in an update. It will > break sites. Okay, sorry, I missed that info from the beginning of this thread (would have been good if that would have been included again, but never mind). Hmm, well, I don't think it makes much sense to ship the two in packages with different names in FC-4 then -- people would have to install/update them manually and I bet most people won't do that (they could/should update to a complete new FC release in that case in any way). But if people really disagree with the my evaluation of the issue let's just ship the packages with different names after FESCo approved the branches and a review happened. CU thl From jon at fedoraunity.org Thu Nov 30 20:46:36 2006 From: jon at fedoraunity.org (Jon Steffan) Date: Thu, 30 Nov 2006 13:46:36 -0700 Subject: Plone - Zope on Fedora Core 4 In-Reply-To: <456F41C6.5050704@leemhuis.info> References: <456C9B4E.8020004@fedoraunity.org> <20061128211544.GB12089@jadzia.bu.edu> <80d7e4090611291323h50bf69ffo95d70f89d67552e@mail.gmail.com> <456F3A62.5070004@fedoraunity.org> <456F3D9C.9040707@leemhuis.info> <456F3E3B.5090704@fedoraunity.org> <456F41C6.5050704@leemhuis.info> Message-ID: <456F432C.3000506@fedoraunity.org> Thorsten Leemhuis wrote: > Jon Steffan schrieb: > >> Thorsten Leemhuis wrote: >> >>> Jon Steffan schrieb: >>> >>>> Stephen John Smoogen wrote: >>>> >>>>> On 11/28/06, Matthew Miller wrote: >>>>> >>>>>> On Tue, Nov 28, 2006 at 01:25:50PM -0700, Jon Steffan wrote: >>>>>> >>>>>>> I've been pushing updates to plone and zope and would like to get >>>>>>> FC4 updated [...] >>>>>>> >>>> So this thread has seemed to die. Who am I supposed to ask for approval >>>> for a new package? I really want to see 'stable' plone and zope in FC4. >>>> >>> Zope and Plone were shipped for FC4 afaics. So according to >>> http://www.fedoraproject.org/wiki/Extras/Policy/EOL >>> it's just fine to build updates for FC4 if there is a good reason for >>> the update. >>> >> The issue is that current (plone 2.1.2) will not migrate to the >> newest version correctly. So, I can just dump in an update. It will >> break sites. >> > > Okay, sorry, I missed that info from the beginning of this thread (would > have been good if that would have been included again, but never mind). > Hmm, well, I don't think it makes much sense to ship the two in packages > with different names in FC-4 then -- people would have to install/update > them manually and I bet most people won't do that (they could/should > update to a complete new FC release in that case in any way). > > But if people really disagree with the my evaluation of the issue let's > just ship the packages with different names after FESCo approved the > branches and a review happened. > > CU > thl > > Ok. The other issue is that fc4->fc5+ will fail an upgrade for plone. What should I look at doing for solving this issue? Just find the latest zope and plone that the current packages will migrate to and leave it at that? This will not ensure that upgrades would work indefinitely, but would at least get them working for the time being. Jon From nicolas.mailhot at laposte.net Thu Nov 30 19:46:46 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 30 Nov 2006 20:46:46 +0100 Subject: New Comps Groups In-Reply-To: <1164856782.11786.101.camel@localhost.localdomain> References: <200611281452.58273.jkeating@redhat.com> <1164844764.11786.15.camel@localhost.localdomain> <200611292139.43243.jkeating@redhat.com> <1164856782.11786.101.camel@localhost.localdomain> Message-ID: <1164916007.8160.69.camel@rousalka.dyndns.org> Le mercredi 29 novembre 2006 ? 19:19 -0800, Toshio Kuratomi a ?crit : > PS. When we design something new, it should have multicategory support: > > > python-gpgme > /Language/Python > /Security/Cryptography > /Development/Library > /Internet/CertificateManagement > Actually, if I had to redesign the comps model (which probably needs to be done someday) I'd aim for something like this: ... ... ... ... ... ... ... ... ... ... -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jkeating at redhat.com Thu Nov 30 21:11:00 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 30 Nov 2006 16:11:00 -0500 Subject: New Comps Groups In-Reply-To: <1164916007.8160.69.camel@rousalka.dyndns.org> References: <1164856782.11786.101.camel@localhost.localdomain> <1164916007.8160.69.camel@rousalka.dyndns.org> Message-ID: <200611301611.03683.jkeating@redhat.com> On Thursday 30 November 2006 14:46, Nicolas Mailhot wrote: > Actually, if I had to redesign the comps model (which probably needs to > be done someday) I'd aim for something like this: Yeah, because that's easy for a packager to know where to put things... (not that comps is right now, but I'm fully in favor of making it EASIER rather than harder) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Thu Nov 30 22:18:23 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 30 Nov 2006 23:18:23 +0100 Subject: New Comps Groups In-Reply-To: <200611301611.03683.jkeating@redhat.com> References: <1164856782.11786.101.camel@localhost.localdomain> <1164916007.8160.69.camel@rousalka.dyndns.org> <200611301611.03683.jkeating@redhat.com> Message-ID: <1164925104.8160.132.camel@rousalka.dyndns.org> Le jeudi 30 novembre 2006 ? 16:11 -0500, Jesse Keating a ?crit : > On Thursday 30 November 2006 14:46, Nicolas Mailhot wrote: > > Actually, if I had to redesign the comps model (which probably needs to > > be done someday) I'd aim for something like this: > > Yeah, because that's easy for a packager to know where to put things... It *does* make it easier for packagers. An individual packager only needs to add one block for each of his packages, fill it with references to all the categories the package belongs to, and he's done. For example: could be All the complex application policy stuff happens in the profiles, and it's not something most packagers care about: 1. every FE comps addition I've seen so far has optional state, 2. the current groups are inherited from FC 2. and we're seing fierce opposition to adding the groups FE contributors propose What I'm actually proposing is : 1. let the community define as many categories it feels interesting 2. let individual packagers be responsible for tagging their packages with all the relevant categories (not difficult, read the category list and reference the ones you want, which will usually translate in copy the category list of a similar package) 3. let each team using comps define whatever profile its app needs using the complete categorisation provided to it by the project For example gnome-desktop ... NetworkManager-gnome alacarte at-spi beagle-gui beagle-evolution control-center dasher desktop-printing eog esc evince file-roller gconf-editor gedit gimp-print-utils gnome-applets (+ all the fedora-extras stuff) Would become something like ... ... -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jkeating at redhat.com Thu Nov 30 22:39:18 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 30 Nov 2006 17:39:18 -0500 Subject: New Comps Groups In-Reply-To: <1164925104.8160.132.camel@rousalka.dyndns.org> References: <200611301611.03683.jkeating@redhat.com> <1164925104.8160.132.camel@rousalka.dyndns.org> Message-ID: <200611301739.18920.jkeating@redhat.com> On Thursday 30 November 2006 17:18, Nicolas Mailhot wrote: > For example Interesting. Something to mull over I suppose... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mcepl at redhat.com Thu Nov 30 19:21:58 2006 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 30 Nov 2006 19:21:58 +0000 (UTC) Subject: uml generating tool References: <20061126173347.12546.qmail@web36807.mail.mud.yahoo.com> Message-ID: Kevin Kofler scripst: > be great. Similarly, a Clearlooks-like theme for Qt/KDE 3 would also be useful http://www.kde-look.org/content/show.php?content=31717 I used to be its maintainer on Debian, but now I had to switch to Gnome, so I won't make a package for Fedora. Mat?j -- http://www.ceplovi.cz/matej/blog/, Jabber: ceplmajabber.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC This conversation can serve no purpose anymore. Good bye. -- HAL9000 in 2001: Space Odyssea